以IP化服務平台 建立智慧建築樞紐 智慧應用 影音
Event
榮耀會員

以IP化服務平台 建立智慧建築樞紐

  • DIGITIMES企劃

隨著高科技資訊化時代的來臨及經濟發展,人們對於「高資訊科技化」與「人性化」空間與環境之渴望,正在不斷攀升;因此如何在建築物內引入多元的科技服務,並藉由不同系統設備之間的協調互動,營造智慧化機能,可謂當前重大課題。

深究智慧建築之核心價值,即是善用資通訊技術觸動智慧化機能,藉以實現安全防災、舒適便利、健康照護、節能減碳等各項願景;然眾多的價值主張,彼此牽涉到的弱電子系統、機電設備種類繁多,各自對應不同標準協定,導致系統整合難度與風險不低,而且客製成本偏高、後續維護不易。因此如何建立一個能夠整合異質標準的匯流平台,實為首要之務。

智慧建築服務平台架構之比較。

智慧建築服務平台架構之比較。

如同政府制定的「智慧建築標章」八大指標,箇中所涵蓋的系統整合項目,即是以建築自動化系統(Building Automation System;BAS)為核心範圍,一舉統整電梯監控、門禁監控、保全監控、對講系統、消防監控、停車管理、監視系統、家庭自動化、能源管理、設施管理、其他弱電系統等眾多項目。

在此前提下,不僅所有機電設備,都應留設可供中央監控管理之輸出入介面,至於各個弱電子系統,基於彼此之間的訊息資源共享,亦應支援產業通用之開放性軟體通訊協定、及標準化硬體接口,藉以留設訊息連結的管道,如此一來,才得以讓BAS順利整合多樣自動化設施與系統。緊接著,以BAS為骨幹,再加入譬如建築環境感知、能源感測、照明管理、空間管理、設施管理…等多項服務分析功能,即可匯聚為完整的建築智慧化服務平台,在智慧建築內扮演中樞神經。

Gateway串接模式  不利長遠發展

不可諱言,無論是HVAC、Lighting、Access Control或各項環境應測器,諸如此類的傳統自動化子系統,彼此都對應不同的標準協定,有的可能適用於BACnet、LonWorks、Modbus等現場總線(Fieldbus),有的可能走Z-Wave、Zigbee或Wi-Fi等無線通訊技術,面對琳瑯滿目的標準,用戶必須先設法營造資訊互通的環境,才能維繫建築智慧化服務平台之正常運作,此時少不得需要借助閘道器(Gateway)與中介軟體(Middleware),作為不同語言的轉譯橋樑。

這般整合方式的好處,在於可讓現存一個個訊息「孤島」,都能接入建築智慧化服務平台,不再各自單兵作戰,看似是實踐智慧建築的最短路徑,但對於長遠的應用發展,卻未必有利。主因在於,中介軟體為了媒合各種端末與通訊方式,即需透過頻繁的轉換與解譯,將所有異質標準封裝成為一致語意,才能化異求同;可想而知,倘若中介軟體需要整合的協定種類愈龐雜,也意謂骨子裡所應具備的「轉譯器」就愈多,容易淪為體態肥大的重度系統,運作效率必然大受影響。

另外,要在中介軟體中塞入這麼多轉譯器,勢必得仰賴高度的客製化,如此不僅導致開發成本偏高、開發時程延宕,也不利於日後維護;更有甚者,藉由層層的標準互換,能否確保最終轉譯結果正確無誤?亦是一個值得商榷的課題。

採用IP化架構  系統整合無障礙

相形之下,若是改以輕量化IP、UDP及應用層通訊協定為架構基礎,繼而整合建築物內有線及無線通訊環境,即可化解上述諸多疑慮;而居間媒合各項子系統的中介軟體,因為不須揹負輾轉換置的繁重任務,體態必然輕盈,不但有助於提升系統的可靠性、互通性,也易於展現較為優異的執行效能。

更重要的,推展智慧建築應用,乃是可長可久的進程,往往並非一步到位,舉例來說,今天可能串聯了A、B、C、D等四套子系統,明天難保不會再追加E、F或G等其他項目,試想,如果每次都需要因應這些新進者,大費周章地造橋鋪路,不論對於最終用戶或系統整合商,恐怕都是永無止盡的夢魘!很顯然的,唯有訴諸全面IP化,才能確保各項子系統皆可隨插即用。

值得一提的,因應物聯網、智慧建築的訊息互通,業界已有OPC、oBix及OSGI等開放式標準協定,用以串聯各個智慧分析服務套件,也唯有憑藉IP化連結架構,方能確保順利接軌這些產業標準。

關於智慧建築專欄

隨著ICT產業邁入智能化應用新藍海,為加速台灣智慧應用創新服務之發展,建構產業全球發展之能量,特別企劃智慧建築之系列專欄,分別就「技術與標準」、「導入及運用」以及「案例分享」進行系列報導,並定期於每周三上刊,若讀者對文章內容有任何建議,或希望投稿,請聯繫:elisha.hung@digitimes.com洪小姐收。


關鍵字