建筑中設備通信協議及數據融合處理方法

陳勤平，嚴 敏（.上海市建筑科學研究院有限公司， 0008； . 上海建科商務服務有限公司， 上海 0003）

通過研究建筑設備通信協議，應用物聯網技術將分散的設備系統進行集成，建立建筑物聯網基礎平臺。將多系統數據進行融合，打通設備和系統的壁壘，為設備協調優化和建筑能源的智能管控奠定技術基礎。

1 設備通信協議

建筑內部設備類型種類繁多，通信協議和現場總線也多種多樣，但目前樓宇中以 BACnet、Modbus 和 M-Bus 應用最為廣泛。

1.1 BACnet

BACnet 是一種用于樓宇自動化和控制網絡的數據通信協議，由美國采暖、制冷和空調工程師協會（American Society of Heating, Refrigerating and Air-Conditioning Engineers ，ASHRAE）主持開發，是美國等 30 多個國家的國家標準，也是歐洲標準和 ISO 全球標準，在樓宇設備自控系統（BA 系統）中廣泛應用。BACnet 通信協議中定義了幾種不同的數據鏈接層/物理層，包括 ARCNET、RS-232/RS-485、LonTalk。目前應用最為廣泛的是基于以太網的BACnet/IP。

BACnet 是一種開放性協議，提供了不同廠商 BACnet設備之間的互操作性，通過 BACnet 協議，可將基于此協議的暖通空調系統、照明控制、門禁系統、火警偵測系統及其相關設備進行集成，實現數據互聯互通和設備互操作。

1.2 Modbus

據 GB/T 19582.1—2008《基于 Modbus 協議的工業自動化網絡規范》，Modbus 是 OSI (Open System Interconnection，開放系統互聯)參考模型第 7 層上的應用層報文傳輸協議，其連接至不同類型總線或網絡的設備，并未這些設備之間提供客戶機/服務器通信。Modbus 簡單易用，已經成為工業領域通信協議的標準協議，是工業電子設備之間常用的連接方式。在樓宇設備如電表、空調機組等設備中也廣泛應用。Modbus 可基于串口和以太網進行通信，目前常用的是基于串口的 Modbus RTU 和基于以太網的 Modbus TCP 協議。

1.3 M-Bus

M-Bus 專門為測量儀器和計數器傳送信息設計的數據總線，采用二線制，可以同時實現供電和傳輸數據。因此成本較低，支持星形、環形和總線結構，在冷熱計量表水表、燃氣表等計量器具的數據通信領域應用廣泛。

2 建筑物聯網平臺

按 GB/T 51243—2017《物聯網應用支撐平臺工程技術標準物》的定義，聯網是通過感知設備，按照約定協議，連接物、人、系統和信息資源，實現對物理和虛擬世界的信息進行處理并做出反應的智能服務系統。在云端設置建筑物聯網平臺，通過物聯網網關連接終端設備，可對多種建筑或建筑群進行數據集成和融合處理。

2.1 平臺架構

平臺結構如圖 1 所示。

圖1 建筑物聯網平臺架構圖

在建筑或建筑群中設置物聯網網關，支持 Modbus、M-Bus、BACnet 等常用通信協議，通過以太網、雙絞線、LoRa （遠距離無線電）等多種通信方式連接智能化系統或智能設備，將數據轉換成 MQTT （消息隊列遙測傳輸）等標準協議，傳輸到云端的物聯網平臺。在平臺上對數據進行融合處理，為各種物聯網應用提供技術支撐，同時可將物聯網應用的下發數據傳輸到物聯網網關，再轉換成各種系統和設備的協議對設備進行控制，在雙向通信的基礎上實現設備間的協調優化控制。

2.2 通信方式

通信方式可分為有線通信、WLAN （無線局域網）類通信和蜂窩類通信。

（1）有線通信：BACnet、Modbus、M-Bus 等協議一般采用基于雙絞線、網線等通信介質的有線通信方式。

（2）WLAN 類通信：包括 WiFi、藍牙、Zigbee 等通信方式，在傳感器、智能終端等設備中應用較多，無需布線，位置靈活，但通信距離較短。

（3）蜂窩類通信：包括 2G/3G/4G/5G、NB-IoT、eMTC、LoRa 等。2G/3G/4G/5G、NB-IoT、eMTC 等均依托于移動運營商網絡，適合于多種應用場景。LoRa 是低功耗廣域網無線通信技術，傳輸速率從幾百到幾十 Kbps，工作在非授權頻段，在應用場景上有一些限制。

2.3 物聯網通信協議

常用的物聯網通信協議有 CoAP、DDS、XMPP、MQTT。目前以 MQTT 應用最為廣泛，一般物聯網平臺如阿里巴巴、騰訊、百度的物聯網平臺均支持。

（1）CoAP 協議：CoAP（Constrained Application Protocol，受限應用協議）是一個基于表述性狀態轉移（Representational State Transfer，REST） 模型的網絡傳輸協議，適用于在資源受限的通信的 IP 網絡，傳輸層使用 UDP協議，以減少開銷和支持組播功能，支持異步通信。

（2）DDS 協議：面向實時系統的數據分布服務，適用于分布式高可靠性、實時傳輸設備數據通信，在服務質量（QoS）上提供非常多的保障途徑。

（3）XMPP 協議：一個開源形式組織產生的網絡即時通信協議，是基于 XML 的協議，在互聯網及時通信應用中運用廣泛。

（4）MQTT 協議：基于“發布-訂閱”模式的輕量級通信協議，已經成為 OASIS（結構信息標準化促進組織）標準，是物聯網的重要組成部分，適合于低帶寬、不可靠連接、嵌入式設備、CPU 內存資源緊張的場景。

MQTT 協議可以作為網關和物聯網平臺之間的標準通信協議，JSON (JavaScript Object Notation) 作為數據傳輸格式。JSON 是一種輕量級的數據交換格式，具有良好的可讀和便于快速編寫的特性，可在不同平臺之間進行數據交換。JSON 比 XML 更加小巧、簡潔，格式簡單，占用帶寬少，處理性能要求低，更適用于網絡數據傳輸領域，如果對傳輸數據量有較高的要求，可在傳輸前進行壓縮。為保障數據傳輸安全，應基于安全傳輸層協議 (Transport Layer Security Protocol，TLS)進行數據傳輸。

網關和物聯網平臺之間通過 MQTT 協議的“發布-訂閱”模式實現雙向通信。網關向平臺 MQTT Server 的數據傳輸Topic（主題）發布采集的設備數據，平臺的消息處理程序訂閱 MQTT Server 的數據傳輸 Topic 進行消息處理。平臺的物聯網應用向 MQTT Server 的控制命令 Topic 發布控制命令，網關訂閱 MQTT Server 的控制命令 Topic 獲得控制消息并執行，從而實現數據傳輸和控制命令執行的雙向通信。有多種消息中間件支持 MQTT 協議，可作為 MQTT Server，如 Apollo、ActiveMQ、Mosquitto、RabbitMQ、EMQ X 等。

2.4 消息和事件流

物聯網通常需要處理大量數據，而且有時有明顯的數據洪峰效應，在采集時間周期附近，會有大量數據涌入。因此，需要引入分布式消息中間件處理事件流。Kafka 和Pulsar 是常用的大數據組件，Kafka 是一個分布式消息中間件，也是一個開源的分布式事件流平臺，高吞吐、低延遲，支持熱擴展，數據多副本，支持高并發讀寫。 Pulsar 不僅可以像 Kafka 那樣處理高速的實時場景，還能支持標準的消息隊列模式。通過引入 Kafka 或 Pulsar，不僅進行數據的“削鋒填谷”，大幅度提供系統處理能力，同時也可以降低系統之間的耦合。

2.5 數據存儲

常用的 MySQL、Oracle、SQL Server 等單機關系型數據庫并不適合存儲海量的物聯網數據。單機數據庫很難水平擴展，即使通過主從復制、集群和分片等方式進行擴展也有很多限制。近年來出現的 Mongodb、HBase 等 NoSQL 數據庫可以很好支持海量數據擴展，但不支持事務，不支持ACID（原子性、一致性、隔離性和持久性）特性，不支持SQL，同時原有開發模式需要做較大地改變。

如果需要數據強一致性，需要支持事務還需要很強的彈性擴容能力，可以采用類似 TiDB、OceanBase 這樣的NewSQL 新型分布式關系型數據庫，將 NoSQL 數據庫的強水平擴展能力和關系數據庫的強一致性、SQL 支持等特性很好地進行了融合。如果需要支持視頻、圖片、語音等非結構化數據，可以構建基于大數據技術的數據湖，從而能以任意規模存儲結構化和非結構化數據,管理各類數據相關的要素，并在此基礎上形成批處理、流式計算、交互式分析以及機器學習等多樣化的分析能力。

3 數據融合處理

接收數據后通常需要對數據進行融合處理，從多個維度、多個指標反映事物特征。常規的單機數據處理技術已無法滿足海量數據處理要求。分布式計算將一個大的計算任務劃分為若干個子任務，然后為計算機網絡中的計算節點分別分配一部分子任務，通過并行處理提高數據處理效率，最后整理、綜合各部分的計算數據，得到最終的計算結果。

3.1 大數據處理架構

分布式計算按類型可分為批處理、流處理（流式計算、實時計算）。批處理是對一批數據聚合后進行處理，基本流程是收集數據→放到數據庫中→取出來進行計算。在計算時效性要求高的場景下，無法滿足實時性要求。流式計算持續接收發來的數據流，實時地進行處理與分析，并及時反饋結果，以滿足對數據處理有較高實時性要求的場景。其特點是實時、低延遲，數據持續不斷，無終止，計算持續進行，計算完之后數據即丟棄。

最早的批處理采用 Hadoop MapReduce（映射歸約），MapReduce是一種編程模型，用于大規模數據集的并行運算。相比于基于磁盤計算的 Hadoop，Spark基于內存進行計算，速度要快得多（最多可比 Hadoop 的MapReduce 快 100 倍)，同時有 Spark SQL（分布式 SQL引擎）、Spark Streaming（流處理）、Spark MLlib（機器學習庫）、GraphX（圖計算）等多種組件，已經基本取代Hadoop MapReduce，成為Hadoop 生態中的重要成員。

目前大數據處理架構可分為 Lambda 架構和 Kappa架構。

（1）Lambda 架構。Lambda 架構分為批處理層（Batch Layer）、實時處理層（Speed Layer）、服務層（Serving Layer）。數據分別進入批處理層和實時處理層，批處理層將數據存儲到主數據集，并對主數據集進行匯總計算。實時處理層針對增量數據進行實時處理，服務層可以將批處理層和批處理層的結果進行匯聚，為上層應用提供數據。

（2）Kappa 架構。Lambda 需要將算法實現 2 次，一次是為批處理系統，另一次是為實時系統。為此 Kappa 架構對流處理進行改進，取代了批處理。需對全量數據進行重新計算時，用 Kafka 或類似的分布式隊列保存需要時長的數據，重新啟動起一個流計算實例進行計算。但是，因為所有的數據都通過流式計算，如果歷史數據規模很大，很難適應物聯網時代對數據查詢響應的即時性要求。

目前批處理以 Spark 為代表，流處理以 Flink 為主，但二者相互也在融合對方特點，Spark Streaming 以微批方式實現流式處理，Flink 以流處理為基礎實現流批一體。

3.2 建筑數據的融合處理方法

建筑數據的處理分為 2 種類型，接收數據進行實時處理，如超限報警、異常判定等。在數據庫層需要進行時、日、月、年等時間維度的 多種指標匯總計算，如統計能耗指標、設備運行指標等。

在數據匯聚到 Kafka/Pulsar 等分布式流系統后，可采用 Flink 進行實時處理，計算參數超限報警、異常判定等，如果對實時要求不是非常高，也可采用 Spark Streaming。在數據庫層，可采用 Spark/Flink 進行匯總計算。

針對建筑數據的處理，目前 Lambda 架構更合適些。一方面隨著建筑數量和采集數據的增多，數據量會急劇增大，并且時、日、月、年等時間維度的指標匯總計算和實時計算的邏輯并不一致，不能使用同一套代碼；另一方面需要使用歷史數據進行機器學習，使用批處理來反復驗證不同的算法。但是，可以統一分布式計算引擎，在實時計算和流處理統一使用 Spark 或者 Flink，實現流批一體。

4 結 語

公共建筑中存在著大量數據，通過和建筑設備建立通信協議，應用物聯網技術將設備數據進行集成，應用大數據技術對數據進行融合處理和分析，可以為建筑精細化管理、能源智慧化管控奠定技術基礎，提供數據支撐。