開源建筑智能化系統
——Honeycomb

文/王燦

今天，中國的一切都發生了翻天覆地的變化。而越來越智能的建筑，則成為了時代進步與發展的“名片”。被廣泛應用于工礦企業、商業中心、辦公樓、會展中心、體育館、醫院、學校、住宅小區等各類建筑物的樓宇自動化技術，也因此備受關注。然而，現有樓宇自動化技術普遍存在部署困難，系統穩定性差，能耗高等問題。為了填補這一研究空白，趙千川團隊受群體智能的啟發提出了一個將分布式技術與智能建筑相結合的開源的系統，名為“Honeycomb”。

作為清華大學智能與網絡化系統研究中心（CFINS）教授，趙千川長期奮斗在網絡化動態系統建模、分析、控制與優化的理論及應用領域。由于其出色的科研探索，更是獲得多項榮譽，2005 年，榮獲美國聯合技術研究中心年度杰出貢獻獎；2010 年，榮獲國家自然科學二等獎；2019 年，榮獲國家自然科學二等獎；2019 年，榮獲甘肅省自然科學二等獎。而當他將目光鎖定在開源建筑智能化系統之時，“Honeycomb”誕生了。

眾所周知，在自然界中，蜂巢由若干形狀和功能一致的蜂室組成，蜂群中的蜜蜂受基因的控制完成個體任務，并通過信息素與其他蜜蜂進行通訊，進而完成蜂群的總體任務。受這一機制的啟發，團隊將建筑內的各區域類比為“蜂室”，部署在區域塊中的智能節點類比為“蜜蜂”，各種分布式應用程序作為智能節點的“基因”，連接智能節點的本地通訊網絡作為“信息素”，系統整體通過群體智能模式來完成建筑的運行需求。

團隊的Honeycomb 方案主要涉及三個研究領域，即，建筑自動化系統（BAS），物聯網（IoT）和分布式技術。其中，BAS 包含了與建筑物中的物理環境相互作用的各類機電、傳感和控制系統。物聯網為自動化設備和用戶提供通信、云服務和應用程序等。而分布式技術包括分布式算法，例如多智能體、群體智能、機器學習，交叉方向乘子方法 (ADMM)，（次）梯度算法，以及用于實現它們的分布式平臺架構。這三種技術互相交叉又產生了智能建筑、邊緣計算以及分布式室內環境和設備系統優化等技術。

圖1 Honeycomb靈感來源及生物學類比

系統架構

知己知彼，百戰不殆。因此，在創新之前，對現有的方案進行深度分析，十分必要。傳統的智能建筑方案主要采用分層的集中式架構。底層的各類傳感和執行器件將各自信息發送到對應邊緣設備，經過初步處理后通過交換機和無線網關發送到云端數據庫。建筑系統內的所有信息經過云端的服務匹配和驗證后，依靠廠商或平臺定制化開發的各類應用程序（apps）進行集中處理和調度。

圖2 系統架構對比（子圖（A）為分層集中式智能建筑系統架構；子圖（B）為Honeycomb系統和架構）

這樣的系統架構為建筑系統的運行帶來了諸多不便：首先，中心（服務器或云）是整個系統的唯一“大腦”，并只能通過綁定的靜態IP 訪問對象，這導致系統的靈活性低，無法適應多變的建筑運行環境，只能按照已經完成的配置工作；其次，建筑內的不同子系統間被完全隔離，使得現有的智能建筑系統功能單一，跨系統協同能力弱；此外，由于系統是高度定制化的，部署和配置門檻高，效率低，升級改造和維護困難，從而極大的提高了系統的整體成本。

發現問題，就要解決問題，所以Honeycomb誕生了，它將智能建筑的運行管理任務從云端下放到了本地的邊緣設備網絡中，并采用基于群體智能的分布式架構實現對建筑的管控。首先，Honeycomb 面向的對象不再只是具體的某個傳感設備，而是部署于同一建筑區域內，協同完成區域控制的設備集合（稱為“區域塊”），這種控制單元的選擇更加契合實際的建筑需求和控制特點。每個區域塊由一個邊緣硬件設備進行綜合管理，相比于傳統的邊緣計算，Honeycomb 的方案中的邊緣設備不再只是收集和上傳數據，也通過本地網絡進行組網形成分布式智能建筑網絡（DSBN），并通過分布式運行環境（DAOE）中的各類分布式應用完成全部的建筑運行任務。系統不再需要一個遠程的“中心”，通過本地局域網通訊即可自組織地運行。此外，用戶可以通過網絡界面（UI）或分布式平臺（DASP）方便地對系統進行遠程監控和手動干預。圖2對比了兩種架構的不同。

綜合以上特點，Honeycomb 作為一種新型智能建筑系統，對比傳統的樓宇自動化方案，具有以下三個突出優勢：

1.更強的靈活性和魯棒性：Honeycomb 采用完全分布式架構，沒有全局領導者，不依賴固定拓撲。系統的智能節點只與它們的鄰居通信，系統組網后，所有本地和全局協作任務均在智能節點網絡中完成，無需遠程中心。因此，系統在運行過程中支持即插即用功能，即新節點可以動態加入Honeycomb 網絡，各類分布式應用下載即運行。此外，得益于拓撲維護機制，即使原來的通信拓撲因節點故障而發生變化，系統也能自動生成新的拓撲而不至于崩潰。這些特點顯著地提高了系統的靈活性和魯棒性。

2.更多樣化的系統功能：Honeycomb 中區域的所有建筑子系統集成在同一本地智能節點中，智能節點網絡不僅完成了傳感信息采集和控制指令下發，也執行著分布式存儲、計算、決策等各類運行任務。同時，不同建筑子系統之間的跨系統協作可以更加直接地進行，降低了集中通信造成的延遲，更減少了在緊急情況下（火災，服務器故障，等）的運行風險。極端情況下，只要部分智能節點能夠聯網，這些區域的功能仍然可以正常工作。

3.更便捷的方案移植和部署：Honeycomb 的硬件系統可以良好地兼容現有的樓宇自動化硬件，智能節點和操作系統均可采用開源的通用軟硬件設備，節點內運行的各類分布式應用程序可以從已有的庫中直接下載運行。因此，Honeycomb 方案的移植和部署過程沒有過高的技術門檻，對已有的樓控系統只需進行輕量化改造，無需過高的改造成本。

系統建設

有了方案，就要實施。畢竟，實踐才是檢驗科研成果的唯一標志。因此，趙千川團隊將Honeycomb 方案部署在了一棟辦公樓建筑中，該建筑有5 個辦公區域，并將南側大辦公區按照空調設備（FCU）進行了虛擬分割，共形成了7 個室內區域塊，制冷站區域塊包含循環水泵和空氣源熱泵。

在原有的BAS系統基礎上，團隊方案將樹莓派開發板作為智能節點硬件，部署到各室內區域塊，水泵節點和熱泵節點中，并搭建了本地局域無線網，用于實現智能節點的通訊。各智能節點與區域塊內所有的傳感器（溫濕度、壓差、流量等）和執行器（FCU控制面板、水泵變頻器等）連接，相鄰智能節點通過無線網絡進行通訊。

用戶反饋

Honeycomb 是為建筑的使用者設計的，用戶的反饋才是趙千川團隊關注的重中之重。2021 年夏季（7 月~8月），Honeycomb 系統開始運行，運行結束后，團隊向用戶（16 名男性，4 名女性）發放了調查問卷以獲取用戶對系統的反饋。依據平均熱感覺指標（PMV）用戶的熱感受被分為了7 個等級。其中，“適中”是最舒適的狀態，而微涼和微暖狀態也是可以接受的，這三個等級為舒適區。同理，我們對用戶的濕感受也進行了統計。結果顯示，90%的用戶熱感覺投票在舒適區，寒冷和涼各1 票。所有用戶都對濕度感到舒適，其中分別有 25% 和 10% 的用戶感到輕微潮濕和干燥。

此外，團隊從用戶操作的便捷性，系統運行的合理性，以及用戶感受的舒適性三個方面調研了用戶對于Honeycomb改造前后的使用體驗。對比結果顯示，“運行合理”選項獲得最多票數，其次是“更舒適”和“使用方便”，“運行混亂”選項獲得了3票，值得關注的是“使用不便”或“不舒適”得票數為零，此外，“無變化”有4票。這一表明，大多數用戶對Honeycomb持積極態度，特別是在舒適性和便捷性方面沒有收到負面的投票。通過回訪和數據調查發現，由于基于視頻的人員檢測算法存在一定誤差，控制算法偶爾會因為人數檢測錯誤而給出錯誤的運行指令，這是“運行混亂”獲得3個投票的主要原因。

最后，團隊邀請受訪者對Honeycomb 的整體性能進行評分。評分范圍為0-10 分。分數越高，用戶對系統的升級越滿意，其中，30%的用戶給出了滿分，60%的用戶評分高于8，最低評分為 5，占全部用戶的10%，總體平均分為 7.85，中位數為 8。這表明 Honeycomb 原型具有較高的用戶接受度。

由此可見，Honeycomb 系統，解決了傳統智能系統的諸多運行不變，讓使用者有了更好的使用體驗，從科技的角度，提升了建筑的智能化水平，其發展前景，不可限量。

該技術的詳細情況請參考趙千川教授團隊近期發表在國際期刊Patterns 上的論文“Honeycomb: An opensource distributed system for smart buildings”。