





摘" 要: 建筑管理系統(BMS)、能源管理系統(EMS)、物聯網設備、建筑信息模型(BIM)、電網及氣象服務等多元信息系統是有效支撐由數據驅動的智能建筑軟件高效運行的關鍵。然而,這些由不同開發商提供的系統之間缺乏統一且明確界定的程序接口與標準,這已成為制約應用程序在模塊開發、可擴展性及重用性上進一步發展的主要障礙。為增強云環境下智能建筑系統對需求和技術變化的適應能力,提出一個優化的端到端實現架構。該架構以Zachman框架為基礎,通過符合MACH原則的微服務、API和基于云的組件來確保整個系統的高靈活性、可擴展性以及向前兼容能力。為了驗證所提優化方法的有效性,以某高校工程實訓中心為案例,開發了一套智能建筑應用程序。經過一年多的實際運行,該程序充分展示了傳感器數據與BIM模型集成的數字孿生應用、基于事件驅動的實時傳感器數據與建模分析等先進功能,不僅證明了所提方法的前瞻性和兼容性,同時也展現了其應對不斷變化的需求和挑戰的能力。
關鍵詞: 智能建筑; 面向服務的架構(SOA); 建筑軟件; Zachman框架; MACH框架; 微服務架構
中圖分類號: TN911?34; TP39" " " " " " " " " " "文獻標識碼: A" " " " " " " " " " " 文章編號: 1004?373X(2024)16?0110?07
Research on service?oriented software framework for intelligent buildings
ZHANG Tianfan1, CHEN Ximo2
(1. School of Mathematics and Statistics, Hubei Engineering University, Xiaogan 432000, China;
2. Intelligent Building College, Zhejiang Institute of Security Technology, Wenzhou 325000, China)
Abstract: The multiple information systems such as building management system (BMS), energy management system (EMS), Internet of Things devices, building information modeling (BIM), power grids and meteorological services are crucial for effectively supporting the efficient operation of data?driven intelligent building software. However, the lack of unified and clearly defined program interfaces and standards among these systems provided by different developers has become a major obstacle to the further development of application programs in module development, scalability and reusability. In order to enhance the adaptability of intelligent building systems to demand and technological changes in cloud environments, an optimized end?to?end implementation architecture is proposed. This architecture is based on the Zachman framework, and the high flexibility, scalability, and forward compatibility of the entire system can be ensured by means of microservices, APIs, and cloud?based components that comply with the MACH (microservices, API?first, cloud native, headless) principle. In order to verify the effectiveness of the proposed optimization method, a set of intelligent building application program is developed by taking an engineering training center of a university as an example. After more than a year of practical operation, this program fully demonstrates advanced features such as digital twin applications integrating sensor data with BIM model, real?time sensor data based on event driven and modeling analysis. It not only proves the foresight and compatibility of the proposed method, but also demonstrates its ability to respond to constantly changing needs and challenges.
Keywords: intelligent building; service oriented architecture (SOA); building software; Zachman framework; MACH framework; microservice architecture
智能建筑作為現代建筑發展的重要方向,致力于通過技術手段實現能源效率、靈活性、室內環境質量及居住者舒適度的全面優化。其發展的核心驅動力在于數據驅動的智能應用,這些應用依賴于來自建筑管理系統(BMS)、能源管理系統(EMS)、物聯網設備、建筑信息模型(BIM)、電網及氣象服務等多元信息系統的操作數據和上下文數據。然而,當前智能建筑在整合這些多源數據以驅動新應用時,面臨著諸多挑戰。數據的提取、標記、組織、共享和集成等過程異常復雜,尤其是在各系統由不同開發商獨立開發、缺乏統一且明確界定的程序接口與標準的情況下。這些問題不僅導致數據整合困難,也極大地限制了數據驅動應用的可重用性、模塊化和擴展性。盡管智能建筑對數據驅動的明確定義架構和標準化API有著迫切的需求,但每棟建筑的獨特性使得制定統一的架構變得異常困難。現有的建筑信息技術架構和模式往往難以直接應用于智能建筑,這種缺失進一步加劇了可重用、模塊化和可擴展應用開發的難度。因此,如何有效地整合和管理來自不同源頭的多源數據,以支持智能建筑軟件的高效運行,同時確保系統的靈活性、可擴展性和向前兼容性,成為了當前智能建筑領域亟待解決的問題。
本研究通過提出一個優化的端到端實現架構,為解決上述難題提供新的思路和方法。同時,通過重點聚焦在數據集成和系統集成領域,結合軟件定義服務(SOA),提出了一種符合MACH原則的智能建筑體系結構,旨在通過重用、模塊化和可擴展性來開發數據驅動的應用程序。
1) 基于Zachman框架為數據驅動的智能建筑系統,開發了一種滿足功能性需求和非功能性需求的體系結構。該結構在邏輯上分為七個部分,涵蓋業務應用、微服務、數據庫、集成軟件、基礎設施、共享服務和用戶界面。
2) 詳細闡釋了如何將語義技術無縫融入智能建筑軟件體系結構中,實現了對現有本體和語義技術的有效重用,以加強元數據集成。
3) 實現了該體系結構的一個具體實例,并通過該案例中三個用例的成功應用,展示了其端到端解決方案的能力。這些用例不僅驗證了體系結構的可行性和有效性,還為其在實際智能建筑項目中的應用提供了有力的實踐支撐。
1" 背景和相關工作
隨著大數據技術的崛起,軟件開發技術的重大變化正在深刻影響著智能建筑領域的發展,持續交付可用軟件并迅速響應業務需求的變化已成為至關重要的能力。為了提高系統的可維護性和擴展性,面向服務的架構(SOA)和微服務架構逐漸成為主流選擇。這些架構模式通過解耦服務實現服務的獨立性和可重用性,從而允許系統更加靈活地適應業務和技術的發展。無服務器架構作為新興的軟件開發范式,也逐漸成為軟件開發的重要組成部分。它允許軟件開發者將應用程序部署到云端,通過事件觸發的方式自動啟動和終止計算資源,極大地提高了資源的利用率和系統的可擴展性。
更為復雜的智能建筑系統也在利用類似的技術以應對這一變化。MATRYCS[1]是一個重要的嘗試,它通過微服務實現模塊化、云虛擬化、開放性和數據共享,同時在確保安全性和無供應商鎖定的六個原則的條件下,構建了一個分布式的數據生態框架,但在具體實施和細節上仍有待完善。文獻[2?3]中為智慧城市提出了一種受面向服務架構(SOA)啟發的數據驅動參考架構,但僅限于UML元模型的展示,缺乏實施細節。文獻[4]提出的智能建筑ICT參考架構,從硬件、網絡、管理、應用與服務四個層面進行了全面考慮。但這一架構更多地停留在理論層面,缺乏具體解決方案的詳細闡述。BuildingDepot架構[5]則側重于在大型商業建筑中實現可移植的數據驅動應用,但在元數據管理、外部服務集成和用戶界面等方面存在不足。B. C. Chevalliera等人的研究關注于傳感器數據與智能建筑本體的集成,但其僅覆蓋了智能建筑生態系統的一個方面。文獻[7]提出一種B?SMART概念分層架構,旨在促進智能建筑的自主優化,但缺乏具體的實施策略。文獻[8]提出的IBDMA參考架構雖然使用了標準驅動程序來獲取數據,但在數據集成和雙向通信方面仍有待加強。
綜上所述,當前智能建筑架構的研究在整合最佳架構框架、現有架構模式以及語義技術等方面仍存在不足。元數據集成作為智能建筑體系結構的關鍵組成部分,需要得到更深入的探索和實施。為推動智能建筑的發展,需要一種更加全面、具體且實用的體系結構,并通過端到端的解決方案來加深對其的理解和提高可用性。
2" 研究方法
2.1" Zachman框架
Zachman框架是一個用于描述和規劃企業信息系統的結構化框架,它提供了一個全面的視角來分析和設計復雜的信息系統。由于智慧建筑信息系統涉及多個子系統和設備的集成與交互,以及復雜的物理環境和安全要求,因此需要一個全面、結構化的框架來分析和設計系統。而Zachman框架可以提供這樣的框架,幫助開發人員從多個視角和建模類別出發,全面考慮系統的各個方面,從而確保系統的設計和實施能夠滿足復雜性和特殊性的要求。因此,Zachman框架可以作為SOA有效的補充[3],從宏觀層面提供一個全面、結構化的視角,以支持企業從多個角度理解和設計其信息系統。
Zachman框架通過其6行6列的矩陣形式,覆蓋了從業務戰略到技術實現的各個方面,從而幫助企業更好地整合業務與IT,確保信息系統能夠滿足整體業務需求,并為企業創造更大的價值。
2.2" MACH框架
MACH(Microservices, API?First, Cloud Native, Headless)框架[9]是一種新興的以客戶為中心、面向未來的軟件架構。它基于微服務、API優先、云原生和無頭化(Headless)等原則,旨在構建敏捷、可擴展、靈活且以客戶為中心的軟件系統。盡管Zachman框架和SOA在企業架構設計中扮演了重要角色,但MACH框架特別關注業務的快速演進和變化,并強調通過模塊化、可擴展性和靈活性等技術來支撐這種變化,能夠提供更加個性化、便捷和高效的服務。
2.3" 研究方法流程
本節設計和實現智能建筑架構相關的六步研究方法,具體流程如圖1所示。
步驟1:根據來自關鍵涉眾的多樣化需求來理解現有建筑生態系統的數據驅動控制域。這一步建立在調查智能建筑數據需求和要求的基礎上。
步驟2:定義系統的功能性和非功能性需求。調研面談和行業內最先進的審查中收集到的需求,有助于確定體系結構模式和體系結構的軟件組成。
步驟3:根據生態系統特性及明確需求,篩選與之相匹配的體系結構模式。此決策過程受到智能建筑生態系統本質屬性的顯著影響。
步驟4:定義體系結構的組件,具體內容如下。
1) 識別建筑物中的現有系統。
2) 通過研究其他領域中可用的參考體系結構與模式來識別公共組件。
3) 根據步驟2的需求和步驟3的體系結構模式,確定智能建筑領域還需要哪些新的和獨特的組件。
步驟5:設計一種綜合性解決方案架構,核心聚焦于技術架構的精心設計與開發。
步驟6:實現所設計的智能建筑部署體系結構,并通過在一個智能建筑應用中的展示,驗證其可行性和效果。
3" 面向服務的數據驅動智能建筑軟件框架設計
圖1給出了總體設計流程,在此基礎上,首先需要根據Zachman框架,在考慮36個維度的要求下實現數據驅動的智能建筑生態系統映射到Zachman框架,從而將業務、技術和部署三維關鍵組件都放置在相應的單元中,并最終封裝在一個框架內;然后再來確定如表1所示的功能性和非功能性需求。
基于上述分析,給出符合Zachman架構的面向服務的數據驅動智能建筑軟件框架,如圖2所示。圖2中明確了七個軟件組件及其內部服務,并揭示了這些組件服務如何協同工作,共同構建一個全面整合的系統架構。該體系結構設計需要支持對各種現有數據(FR1~FR3)的無障礙訪問與高效集成(FR4),并兼容新部署的服務(NFR2)。微服務架構因其模塊化特性,在促進系統可擴展性、可重用性以及可維護性(NFR1~NFR3)方面展現出顯著優勢,因此被認定為新型應用開發的優選方案。此外,該架構還要支持服務間命令與消息的傳遞(FR5、FR6),主要通過提供高效的傳輸機制滿足這一需求。在復雜的控制策略中,如模型預測控制(MPC),服務間的消息傳輸尤為重要,它允許一個服務根據另一服務的輸出觸發響應。此類協調機制通常通過微服務框架內的“基于事件的消息傳遞”機制實現。此外,在模塊化方式下添加新服務(NFR2)時,擴展微服務架構的功能通常是一個高效且便捷的過程,包括新服務的創建、容器化封裝、API端點的建立以及最終部署等步驟,確保系統功能的靈活擴展與更新[10]。
4" 關鍵組件設計與系統實現
為進一步闡述圖2所示的軟件框架中的關鍵組件,本文結合某高校工程實訓中心智慧建筑設計項目進行說明。該項目包含Sub1~Sub3三個子部分,分別對應數字孿生(DT)[11]、物聯網集成(IoT)[12]和BIM集成。
關鍵軟件組件一部分來自于經典SOA框架,另外一部分是數據驅動的建筑領域特有的。本文主要考慮以下七個關鍵組件:現有業務應用程序、新的基于微服務的業務應用程序、數據庫、集成軟件、基礎設施服務、共享服務、用戶界面。
4.1" 現有業務應用
符合基本規范的現有業務應用主要由BMS、BIM和IoT來實現。在本文框架中,與BMS交互的目的僅在于提取歷史數據,而BIM模型被用于創建數字孿生應用。其他來源系統包括提供實時傳感器數據的IoT設備。為整合這些已有系統,需要使用多種驅動程序。
4.2" 基于微服務的新應用
新應用主要位于集成軟件和新業務應用類別中。在當前框架中,這些服務包括IoT驅動程序、BMS驅動程序、文件轉換器和ETL工具,這些工具為上層應用提供數據。而建筑中的MPC等數據驅動的應用則可根據實際需要實裝。
4.3" 數據庫
圖2中所示的四類數據庫是這些應用實現的基礎。其中,MongoDB時間序列集合用于存儲時間序列數據,而MongoDB文檔集合用于存儲關于用戶和項目的其他數據[13];GraphDB數據庫存儲描述建筑物元數據的語義圖;作為對象存儲,使用Minio來存儲IFC文件、轉換后的xkt文件以及大型時間序列數據集合等。
為了方便統一動態管理,四類數據庫都安裝在Docker環境中。
代碼1展示了Sub1中時間序列數據示例:
{\"_id\":ObjectId(\"xxxx\")
\"sensor_id\":\"xxxx\"
\"timestamp\":ISODate(\"2024?06?10T9:00:00Z\")
\"value\":31.5}
代碼2展示了Sub1中對象數據示例:
{\"id\":ObjectId(\"xxxx\"),
\"title\":\"HBEU\",
\"description\":\"ET_Center\",
\"xktFiles\":[\"ET_Center.xkt\"],
\"rdfFiles\":[\"\"ET_Center.ttl\"],
\"queries\":[]
\"__v\":1}
代碼3展示了Sub1和Sub2的GraphDB數據庫中的RDF語法語義建筑圖的一部分(Brick本體論版本v1.3),具體內容如下:
{inst:08BEAC0A1C04 Edimax a brick:Sensor;
rdfs:label \"EDIMAX air quality sensor\";
brick:hasPoint
inst:08BEAC0A1C04Edimaxco2;
inst:08BEAC0A1C04 Edimaxh;
brick:hasLocationinst:space892;
ref:hasExternalReference[
a ref:TimeseriesReference;
ref:hasTimeseriesId \"edimax/08BEAC0A1C04/pub\";
ref:storedAtinst:mongo?timeseries;].
inst:11NR00STE?001TRL Sensor a brick:Temperature_Sensor;
rdfs:label \"TEMPERATURE 8128\";
brick:hasLocationinst:space 892;
ref:hasExternalReference[
a ref:TimeseriesReference;
ref:hasTimeseriesId \"11NR00STE?001TRL\";
ref:storedAtinst:mongo?timeseries;].
inst:space_892
a bot:Space,brick:Room;
bot:hasGuid \"1456e859?2e9e?4e70?9341?f073adb2dbb0\";
props:hasCompressedGuid \"0KLkXPBfvES9D1y7Ejijkm\".
inst:mongo?timeseriesaref:Database;
rdfs:label \"MongoDB Timeseries Collection\".}
4.4" 集成軟件
1) BMS集成。在示例中使用BMS中的歷史數據來支持用Sub1和Sub3,通過ETL將傳入數據轉換為邏輯數據模型中定義的MongoDB模式。
2) 物聯網集成。在IoT示例中使用了三種類型的物聯網設備。一種是空氣質量傳感器,該設備每10 s從物聯網平臺獲取傳感器數據,并將其發布到MQTT代理;另一種是智能插座,該設備的物聯網驅動程序采用了一個已有的連接器,以將這些消息轉發到MQTT代理;還有一種為自定義的直接與MQTT代理通信的設備。這樣,所有實時數據都可以通過單一的MQTT消息代理訪問。每個物聯網設備ID(如果可用,則可選為MAC地址)都包含在MQTT?Topic中,傳感器讀數則包含在MQTT有效負載中。由服務產生的空氣質量傳感器的物理數據模型代碼4所示:
{topic:'esp32/xxxxx/pub',
keys:['co2','tvoc','te','rh','lux','vbat'],
values:[721,72,26.141,55.942,587.1000,4.1000]
timestamp:1662299568432}
這些統一的數據也記錄在時間序列數據庫中以便后續使用。
3) BIM集成。BIM集成在用Sub1中的ET_Center建筑時使用,其依賴于xeokit SDK。在這種情況下,需要另一個驅動程序將IFC文件轉換為與Web兼容的xkt格式,轉換后的文件存儲在可通過API訪問的對象存儲中。
4) 元數據集成。上述所有應用實現都依賴于元數據集成服務。元數據圖的目標是標準化語義,并在不同的數據源之間建立聯系。最重要的三個數據源是BMS(建筑管理系統)、IoT(物聯網)和BIM(建筑信息模型),因為它們包含大量元數據,使得數據驅動的應用能夠進行上下文表示。在這方面,本文實現了兩種元數據驅動程序,一種用于IFC到RDF的轉換,另一種是基于BMS和IoT傳感器生成元數據模式。
從BMS的元數據源(如數據字典和設備規格)中提取語義,以創建元數據模式。這些圖形存儲在GraphDB圖形數據庫中,通過API在圖形數據庫上執行SPARQL查詢,可以根據傳感器類型、位置或其他關系發現傳感器和觀測值。為了提高應用程序的整體可重用性,將可重用的SPARQL查詢編程到API中。圖3展示了代碼4所示傳感器和空間的結果。
5) API:REST API的目的是促進智能建筑應用程序與架構中其他組件之間的通信。本文三個用例都使用相同的API,目的是使API更加通用,適用于任何數據驅動的建筑,而不局限于一個特定用例的建筑。API使用Node.js的Nest.js框架實現,它允許應用程序與各種服務進行交互,并對可用的4個數據庫執行創建?讀取?更新?刪除(CRUD)操作。
4.5" 基礎設施服務
使用Docker作為容器化環境,因為較新的應用程序(如IoT驅動程序、API和數據庫)都在Docker上運行。
4.6" 共享服務
所有服務共有的功能被識別為共享服務,包括安全性、治理、監控和自動化。
4.7" 用戶界面
用戶界面展示了針對Sub1和Sub2的兩個Web應用程序以及針對Sub3的Grafana儀表板的實現,所有應用程序都是基于所提出和實現的架構開發的。
圖4為Sub1和Sub2的應用示例,其中主界面為數字孿生頁面,使用了React前端框架和xeokit SDK。該應用程序允許用戶通過Web瀏覽器瀏覽BIM模型,并查看與其空間相關的傳感器數據。REST API將Web應用程序連接到語義圖、時間序列數據(歷史和實時)以及BIM模型。
圖4中展示了與BIM模型相關聯的歷史傳感器數據,并在Web應用程序中進行了可視化;還展示了IoT集成的案例(Sub2)傳感器節點信息查看。該應用程序也使用React前端框架,該模塊允許用戶與實訓中心建筑的元數據圖進行交互,探索其IoT設備并接收實時數據。
圖5所示為Sub3的應用示例。基于BMS歷史數據開發了一個基于元數據模式的應用,通過Grafana儀表板將其與時間序列數據庫集成,提供了高效查詢時間序列數據的能力,包括按設備或點類型查詢數據的能力,以及通過圖表對數據獲得初步見解。
用戶可以在圖5所示的下拉列表選擇設備類型來查詢感興趣的BMS點。其中的時間序列圖展示了一個被選擇為brick:Equipment的空氣處理單元(AHU)的示例,通過SPARQL查詢請求與該brick:AHU在元數據模式中相關的數據點的唯一標識符。
5" 結" 語
本文提出一種面向服務的數據驅動建筑體系結構,旨在解決當前系統架構缺乏集成、不依賴語義技術且多為概念性的不足等問題。通過采用Zachman框架、行業需求和經過測試的IT架構模式,結合MACH原則和可擴展元數據方案,顯著提升了體系結構的可擴展性、模塊化和可重用性。該體系結構包含特定于建筑領域的組件,支持微服務架構,并通過API和消息總線實現組件間通信。
利用語義技術,本文體系結構能在不同數據庫中維護數據類型,通過開放元數據模型和本體保證數據模型的靈活性和可擴展性。通過智慧校園智能建筑應用案例驗證了體系結構的可重用性和模塊化,適用于為智能建筑構建解決方案的架構師、業務主管和服務提供商,有助于數據和系統訪問,并減少實現新應用時的歧義。
這種軟件架構的實際實現對于智能建筑生態系統中的多個利益相關者至關重要。未來工作主要是使用提議的體系結構將DSM應用程序(如MPC)實現為基于微服務的應用程序。
注:本文通訊作者為陳惜墨。
參考文獻
[1] PAU M, KAPSALIS P, PAN Z, et al. MATRYCS: a big data architecture for advanced services in the building domain [J]. Energies, 2022, 15(7): 2568.
[2] MATAR M A. Towards a software defined reference architec?ture for smart city ecosystems [C]// 2016 IEEE International Smart Cities Conference (ISC2). Trento, Italy: IEEE, 2016: 1?6.
[3] LI X, WU P, SHEN G Q, et al. Mapping the knowledge domains
of building information modeling (BIM): a bibliometric approach[J]. Automation in construction, 2017, 84: 195?206.
[4] MAZZARA M, AFANASYEV I, SARANGI S R, et al. A reference architecture for smart and software?defined buildings [C]// 2019 IEEE International Conference on Smart Computing. Washington, DC, USA: IEEE, 2019: 167?172.
[5] LIU H Y, BALAJI B, GAO S, et al. Safe HVAC control via batch reinforcement learning [C]// 2022 ACM/IEEE 13th International Conference on Cyber?Physical Systems. [S.l.]: IEEE, 2022: 181?192.
[6] BOULAKIA B C, BEATRICE F, CHEVALLIER Z. A reference architecture for smart building digital twin [EB/OL]. [2023?07?18]. https://www.xueshufan.com/publication/3036551559.
[7] GENKIN M, MCARTHUR J J. B?SMART: a reference archi?tecture for autonomic smart buildings [J]. IOP conference series: earth and environmental science, 2022, 1101: 092036.
[8] BASHIR M R, GILL A Q, BEYDOUN G. A reference archi?tecture for IoT?enabled smart buildings [J]. SN computer science, 2022, 3(6): 493.
[9] ROBEY Ruissaard. MACH architecture: discover the principles and benefits [EB/OL]. [2023?07?11]. https://www.incentro.com/en/blog/mach?architecture?discover?principles?and?benefits.
[10] RICHARDS M. Software architecture patterns [M]. Sebastopol, CA, USA: O’Reilly Media, Inc., 2015.
[11] 劉剛,馬智亮,曾勃,等.數字孿生技術在建筑工程中的應用研究綜述[J].土木建筑工程信息技術,2023,15(6):1?8.
[12] 商開友.數字化技術在裝配式建筑施工中的應用前景探討[J].工程與建設,2024,38(1):172?174.
[13] 宗平,李雷.PostgreSQL與MongoDB處理非結構化數據性能比較[J].計算機工程與應用,2017,53(7):104?108.