“集成”還是“融合”
——論IBMS與物聯網智慧云平臺的選擇

劉宇輝，周祖壽，李杭

（筑博設計-智慧建筑研究中心）

1 智能建筑的痛點

建筑智能化工程技術起源于自動控制技術、計算機技術、通信技術在建筑工程領域的應用。在其二十多年的發展歷程中，不斷吸收ICT行業的科技成果優化和豐富自身，它曾經歷過標準化、數字化、網絡化的發展與演變，伴隨近年來物聯網、大數據、云計算、AI、5G的興起，業已朝向泛在化、協同化、智慧化演進。然而，由于智能化工程的各組成子系統是獨立設計研發的，整體上缺乏頂層設計，且各子系統的技術革新程度差異懸殊，其結果是子系統之間協同性差、難以發揮工程的整體效益與優勢。

智能建筑中的近三四十個子系統，皆是應當時的市場需求而被陸續一一創生的。智能建筑產品供應商為了解決現代建筑某一方面的管理問題，采取傳統的垂直系統架構，配制服務器和數據庫、架設網絡連接設備、建模型，采用面向過程的程序設計實現業務邏輯，基本上都是垂直地搭建封閉的應用系統。

而各個系統創生年代不同、設計生產的廠商不同，數據格式、編程思想、遵循協議均不相同。為了滿足智能建筑的功能需要，智能化工程的實施單位在同一建筑中將它們生硬地匯集在一起，交付給建筑管理方，構建出一種煙囪叢林式的智能化工程架構。在這種構架之中，各個子系統都是完整獨立的，在硬件軟件體系、數據結構上都是各自為政，從終端、管線到后臺服務器與存儲均相對獨立。既沒有統一的數據格式、語義標準，也沒有實現數據互聯互通，形成多個信息孤島。

為解決各子系統之間的互聯互通問題，傳統辦法是在眾煙囪之上疊加智能化集成系統IBMS。然而，這種基于外部數據庫的集成方案，數據既不及時也不完整，數據通道的可靠性、安全性也得不到障，大多只能起到信息集中展示的功用，難以實現稍復雜的系統間聯動，難以達到系統整合的目的。同時，由于其開發、維護、管理的難度高，該集成系統往往建成不久即被閑置，各子系統又回復到一盤散沙或煙囪叢林的狀態。

需要指出的是，上述這些子系統均沒有采用分布式架構和高可用技術，一旦系統服務器故障，這個子系統的服務也就全部中斷或喪失。由于沒有定義統一的資源命名、數據模型、關系模型，各個子系統之間的數據并沒有真正打通，不能實現“如身使臂，如臂使指”的效用。因而難以支撐現代建筑的各類智慧化應用。

具體來說，傳統的基于系統集成的智能建筑有如下問題：

①系統未采用分布式架構，無法擴展、升級；

②缺乏全面而完整的數據標準，各系統之間仍然無法有效地交換數據；

③各子系統分別建模，沒有統一的建模方法和命名方法，沒有命名空間的概念，缺乏對技術、業務、生產、管理、經營五個平面的統一建模；

④各系統數據結構不同，缺乏統一的規劃、設計和關系關聯定義，導致一些必要的數據維度缺失或無法有效記錄與利用；

⑤各系統產生的數據以及人機物之間互動的數據，往往在一次性使用后即被拋棄，缺乏數據沉淀，潛在價值無法被進一步挖掘；

⑥缺少智慧建筑的數據中臺，無法進行大數據分析利用，無法在此之上體系化地推進人工智能，推理、判斷和決策的綜合智慧能力無從談起；

⑦系統集成項目缺乏可復制性，每個項目分別定制化開發和集成，一次性投入，往往由于趕工而需求分析不夠、軟件測試不足，系統穩定性差、功能實現率低；

⑧無法交付全生命周期的產品，建成交付即被遺棄，二年維保期過后幾成擺設，未實現輔助建筑運維的初衷。

2 基于物聯網的奧卡姆剃刀

那么，在當前ICT技術日新月異、信息化正助力各行各業數字化轉型的時代大背景下，有沒有一套完整的思維方法和工具來協助我們，去實踐建筑智能化行業的數字化轉型，去進行“科學的頂層設計”呢？答案是肯定的，它正是“物聯網”。物聯網以信息統一、網絡融合、資源共享、應用互通以及終端復用的方式，實現了將相關的信息服務融合在一起。

在GB/T33474-2016《物聯網參考體系結構》及GB/T35319-2017《物聯網系統接口要求》中，將物聯網概念模型規定為六個域，即用戶域、目標對象域、感知控制域、服務提供域和運維管控域。其中，感知控制域中的實體又分為傳感網系統、智能化設備接口系統、標簽識別系統、位置信息系統與音視頻系統[1-3]。透過現象看本質，我們在物聯網的視角下，重新審視GB 50314歸納的智能建筑常用子系統，并將它們分為物聯網網絡、運維系統、物聯網對象（音視頻）、物聯網對象（傳感網）、物聯網服務、物聯網環境設施共五種類別（見表1）。

表1 物聯網視角下智能建筑常用子系統分類表

其中，歸屬物聯網的網絡本身的通信類子系統如表2所示（見表2）。

表2 歸屬物聯網傳輸網絡的通信類子系統

基于上述梳理，我們不難得出采用新一代ICT技術解構與重構后的全新“智能化工程架構規劃圖”（見圖1）。

圖1 智能化工程架構規劃圖

在此圖表中，我們依托物聯網六域模型給出的所謂工程架構，實際上正是智慧建筑操作系統的雛形，它已綜合了智慧建筑操作系統的硬件架構和業務邏輯。將原有眾多的子系統解體，消弭其疆界、融合其數據、統一其流程，將整個大系統規范為“云—管—端”的簡潔架構，云即云平臺、管即物聯網網絡、端即物聯網終端。其革新意義在于采用物聯網思維及其工具解構與重構了傳統智能化系統，將各系統的硬件與業務邏輯分離、對各系統原本封閉的IT架構進行功能解耦，打造全新的涵蓋數據、模型和APP的水平架構層，把通用的東西平臺化，把業務功能API化。其結果是用“融合”替代了“集成”，實現整個建筑數據、資源、功能的統一和深度融合，實現數據高可用，并以此作為大數據應用、AI應用的基礎。將之與建筑智能化工程類比，我們把這種具備“云—管—端”簡潔工程架構、深度融合的一體化系統工程稱之為建筑物聯網工程，簡稱建筑物聯網。

在物聯網視角之下，傳統智能化系統的前端現場設備，各傳感、控制、顯示單元等都屬于建筑物聯網前端。如果將智慧建筑類比于人體，這些前端就是眼、鼻、耳、手、口、面。它們經由物聯網這一張“神經網絡”與智慧建筑的“大腦”暨管控營一體化云平臺實時連接，共同組成完整的“智慧生命體”（見圖2）。它不僅能實現智能化功能，還能依托場景、依據用戶身份提供差異化的智慧服務。

圖2 建筑智慧生命體示意圖

3 物聯網智慧云平臺的實現

云端服務的物聯網云平臺由服務器、容器基礎設施、物聯網中臺、智能化中臺服務、智能化服務與應用、運營管理應用構成。智能化中臺服務對資源模型和資源數據進行統一管理，對各專業設備的實時運行數據進行融合，為上層的智能化服務和應用提供支撐，而智能化服務和應用是為物聯網云平臺運營管理應用場景提供技術支撐的。

1）云腦基礎設施

宜采用基于容器技術搭建統一的私有云服務器集群，具體如下。

①采用不少于兩臺通用服務器構成物聯網平臺服務器集群，采用負載均衡技術和高可用技術，通過寬帶物聯網與部署在各樓層的邊緣網關通信，實現對現場機電設備的接入和控制。

②采用不少于兩臺存儲和計算一體化通用服務器構成視頻管理服務器集群，同樣采用負載均衡技術和高可用技術，通過寬帶物聯網與部署在各樓層的攝像機和地下空間的停車場車位引導攝像頭通信，負責收取各攝像頭實時上傳的碼流數據，并進行解碼、存儲、推流等操作。

③采用不少于兩臺帶有GPU的通用服務器（數量按路數定）構成視頻分析服務器集群，對實時視頻數據進行人員行為識別、車牌識別、交通事件和交通參數識別以及人流統計等功能。

④采用兩臺通用服務器構成應用服務器集群，運行智能化服務、運營管理服務和應用。

⑤采用兩臺通用服務器構成數據庫服務器集群，采用負載均衡技術和高可用技術，實現對各種資源、配置、性能、空間、告警數據的存儲、查詢、統計等相關處理。

2）容器云基礎設施

容器已經在生產環境中被廣泛采用，以實現資源的動態分配和彈性伸縮，因此推薦采用開源K8s管理平臺Rancher，在生產環境中實現Docker的全棧化容器部署與管理。

3）綜合呈現系統

采用LED顯示屏及相應的編解碼器和控制器，搭建綜合呈現系統。配套數據計算、數據分析服務、平臺門戶服務等，為管控營人員提供大數據的多維呈現。

注意在建筑規模較小、實際接入終端較少的情況下，上述服務器可以進行合并簡化、減少初投資，一般建議將物聯網平臺服務器、應用服務器和數據庫服務器合并在同一臺物理服務器中。

3.1 軟件架構設計

信息系統的本質在于以業務應用為目的，對所獲取的信息進行處理和加工。硬件設施是整個系統所有數據生產、傳輸、處理、存儲的載體，而各種數據信息的處理過程則是由軟件技術架構來承載的。

3.1.1 設計指導思想

1）“書同文、車同軌、行同倫”

①首要的目標是終結以往孤島叢生的多系統集成態勢，鍛造大一統的建筑操作系統。

②解決溝通障礙和信息割裂的前提在于做好底層的數據通信、數據采集、指令下發和數據建模。因此要搭建統一的動態數據建模平臺，統一實現各種數據的建模、關系建模、數據結構設計、數據字典以及元數據管理，從而實現“書同文”。

③通過統一的通信協議選擇、統一的組網設計、統一的服務器部署、統一的信息安全及權限管理，實現“車同軌”。

④通過統一的算法框架、統一的規則引擎、統一的調度引擎、統一的流程引擎、統一的數據呈現，規約數據的處理和驅動模式，實現“行同倫”。

2）開源與開放性

①采用通用技術或者是與通用技術兼容，避免單一來源的問題。

②保持數據的開放性，也就是一定要使用通用的通信協議。

3.1.2 架構設計

關注整個架構的穩定、持續、健壯和可擴展能力。在軟件架構設計中應綜合運用現有ICT成熟技術，包括數據建模、多協議適配的物聯網平臺、算法引擎、規則引擎、調度引擎、負載均衡及高可用、軟件容器技術等。在整體技術架構上，我們選擇SpringCloud（云計算）框架技術來實現基于容器技術和微服務的云平臺架構（見圖3）。

圖3 軟件技術架構圖

1）微服務架構

采用傳統軟件的單體應用模式，而是基于服務和功能組件，將應用拆分為多個小的、互相連接的微服務，微服務之間基于輕量級的REST-API接口方式互聯和調用，使各個微服務既有獨立完成服務的能力，又能高效地與其他服務基于業務邏輯完成特定業務功能。采用Docker容器云架構較好地整合了分布式系統的系統層面功能，包括服務路由、服務網關、服務發現、鏈路跟蹤等全要素。對于本系統要求的高可用、可擴展、快速部署、快速升級、服務切換等有較好的支持。當外部的系統需要調用微服務中的一些功能的時候，需要通過框架對外暴露的接口——微服務網關Spring Cloud Gateway來訪問。

邏輯集中的服務調度管理平臺Rancher，對系統各個服務的狀態進行監控，快速進行故障切換和服務恢復，具備秒級的服務故障自愈能力。

2）數據庫服務與緩存服務

從圖3中可以看出，系統采用了redis的內存數據存儲、Postgresql進行時序數據、結構化和非結構化數據的統一存儲。

3）消息服務

在微服務架構中，服務之間是松耦合，主要采用消息訂閱方式發布數據，以達到前后端應用的分離。服務內部通信需要依賴消息總線，系統采用RabbitMQ作為消息服務總線。

4）負載均衡服務

對負載較大的前端WEB服務、數據計算服務、資源服務，系統采用了Spring‐Cloud的Ribbon組件實現負載均衡服務。

5）多協議適配引擎

需采用多協議適配引擎來支持多種協議和規約，如BACNET、MODBUS、CBUS、EIB、ZigBee協議IEC102、104規約等等，能夠與各相關廠家的終端設備通信，解析采集到的數據，遠程調用相應指令對這些設備進行監控等。

多協議適配引擎內部基于模塊化設計，支持動態網絡協議解析腳本的加載和適配，可以將封裝在以太幀中的異構協議數據正確獲取和解析，歸一化為標準的數據格式（JSON），以便上位系統能正常處理。反之，系統的聯動或控制指令由協議適配引擎翻譯為受控對象及設備的協議指令格式，由邊緣網關下發到受控對象及設備，以便其正確執行。

6）算法引擎、規則引擎與調度引擎

通過平臺的多協議適配引擎打通了與各種終端設備之間的數據通道，從而獲取各種實時的運行數據，然后通過算法引擎驅動各種算法框架和算法對這些數據進行相應處理，這些算法形成的結果會被各種規則利用，對這些過程數據進行進一步的處理，然后再通過規則引擎管理各種規則的正常運行。

時間和空間在建筑智能化中有著重要作用，既需要基于不同的時間段（如上班前、上班期間、午休期間、周末、節假日等），也需要基于不同的空間（如大堂、食堂、會議室、獨立辦公室等）定制智能化場景，然后基于這些場景做功能和數據的聯動。調度引擎就是用來定義場景，并串聯各種功能和數據的。調度引擎支撐了人與設備、人與空間、人與建筑的互動，展現出智慧平臺的人性化與智能化。

3.2 云平臺功能模塊

3.2.1 物聯網中臺

物聯網中臺是智慧建筑操作系統的基座，物聯網平臺負責虛擬設備對象（數字孿生體或設備影子）的生命周期管理，借助虛擬設備對象實現對實體設備的管控，并為上層平臺提供統一的接口。具體功能包括設備注冊和認證、同步資源模型和資源數據、虛擬設備對象生命周期管理、虛實對象狀態同步等。

3.2.2 智能化中臺

智能化中臺可分為數據中臺和業務中臺，數據中臺側重于數據服務，業務中臺側重于業務應用支持。智能化數據中臺對資源模型和資源數據進行統一管理，對各專業設備的實時運行數據進行融合，為上層的智能化服務和應用提供支撐；而業務中臺的服務又可細分為前端應用服務和后端應用服務。

后端應用服務包括資源服務、數據計算服務、監控告警服務、事件服務等，它們處理感知系統和交互系統產生的各種數據，使其成為標準格式，增加業務的可理解性，以共享的數據服務構成智慧建筑數據中臺，向前端各類應用服務提供訂閱調用。

上層應用服務需要統一使用的中臺支撐，包括API網關服務、數據訪問服務、負載均衡服務、消息服務、緩存服務、日志服務、監控服務、數據庫服務等。這些前端應用服務是為了讓應用系統其他服務得以正常工作、互相訪問、提供可維護性而存在的平臺級服務。

3.2.3 智能化服務與應用

智慧建筑場景下的應用系統在統一的數據模型、網絡架構、技術架構下，基于統一的服務框架構建上層應用的組合，且服務間能通過內部API接口互訪。實現靈活適配業主多樣化需求、基于場景的跨應用調用與融合，比之前的智能化工程展現出超強的靈活性、可擴展與可實施性。

如圖4所示，鑒于當前用戶的使用習慣，平臺提供的智能化服務主要涵蓋了GB 50314中智能建筑常見通用功能服務（子系統），如物業管理應用、一庫（卡）通應用、各項信息設施系統服務、各項建筑設備管理服務、各項公共安全管理服務等；以及面向專業場景的服務，如客流統計、資產管理、位置服務、智能家居、智慧醫療、訪客管理與車位引導。

圖4 物聯網應用支撐平臺功能架構

3.2.4 運營管理應用

通過采用“云、管、端”的技術架構，實現了對基礎設施的一體化接入和管理。接下來可將基礎設施的能力進行封裝和編排，以“空間、時間、設施、規則”作為關鍵要素，為上層業務運營管理系統提供可標準化描述，可自動化開通、智能化運行、定義服務水平、實時精確計量和計費的基礎設施服務，從而實現“建筑即服務”。

依托建筑智慧平臺實現基于數據、事實和理性分析的精細化管理，打通建筑運營過程中涉及的客服接待、運維管理、設備監控、事務響應、計劃安排、任務管控、人力資源、大數據分析、商業智能諸多業務領域，可全面提高業主和用戶的工作、生活體驗，大幅提升物業服務的品質、提升人員的工作效率，節能降耗、提升收益。

4 結語

伴隨建筑規模的增大和子系統的增長，傳統智能建筑管理難度越來越大、管理成本不斷提高，越來越難以適應當代建筑智慧化管理、人性化服務的需要。“BAT”等互聯網領軍企業跨界試水智慧建筑與智慧園區，取得較好效果；于是智能建筑界紛紛跟風上陣。然而，基于“BAT”自身稟賦與基因的智慧建筑方案往往讓地產界難以削足適履。我們有必要透析其方案本質、辯證地”揚與棄”，采用通用技術破解行業難題。為了避免未來對項目的智能化系統進行傷筋動骨的改造，做好技術路線選擇，考察案例實效，從項目的全生命周期考慮，采納當下成本可控、經濟實效的智慧建筑操作系統是項目建設方的明智之選。