劉宇輝，周祖壽，李杭

（筑博設(shè)計-智慧建筑研究中心）

1 智能建筑的痛點

建筑智能化工程技術(shù)起源于自動控制技術(shù)、計算機(jī)技術(shù)、通信技術(shù)在建筑工程領(lǐng)域的應(yīng)用。在其二十多年的發(fā)展歷程中，不斷吸收ICT行業(yè)的科技成果優(yōu)化和豐富自身，它曾經(jīng)歷過標(biāo)準(zhǔn)化、數(shù)字化、網(wǎng)絡(luò)化的發(fā)展與演變，伴隨近年來物聯(lián)網(wǎng)、大數(shù)據(jù)、云計算、AI、5G的興起，業(yè)已朝向泛在化、協(xié)同化、智慧化演進(jìn)。然而，由于智能化工程的各組成子系統(tǒng)是獨立設(shè)計研發(fā)的，整體上缺乏頂層設(shè)計，且各子系統(tǒng)的技術(shù)革新程度差異懸殊，其結(jié)果是子系統(tǒng)之間協(xié)同性差、難以發(fā)揮工程的整體效益與優(yōu)勢。

智能建筑中的近三四十個子系統(tǒng)，皆是應(yīng)當(dāng)時的市場需求而被陸續(xù)一一創(chuàng)生的。智能建筑產(chǎn)品供應(yīng)商為了解決現(xiàn)代建筑某一方面的管理問題，采取傳統(tǒng)的垂直系統(tǒng)架構(gòu)，配制服務(wù)器和數(shù)據(jù)庫、架設(shè)網(wǎng)絡(luò)連接設(shè)備、建模型，采用面向過程的程序設(shè)計實現(xiàn)業(yè)務(wù)邏輯，基本上都是垂直地搭建封閉的應(yīng)用系統(tǒng)。

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

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

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

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

①系統(tǒng)未采用分布式架構(gòu)，無法擴(kuò)展、升級；

②缺乏全面而完整的數(shù)據(jù)標(biāo)準(zhǔn)，各系統(tǒng)之間仍然無法有效地交換數(shù)據(jù)；

③各子系統(tǒng)分別建模，沒有統(tǒng)一的建模方法和命名方法，沒有命名空間的概念，缺乏對技術(shù)、業(yè)務(wù)、生產(chǎn)、管理、經(jīng)營五個平面的統(tǒng)一建模；

④各系統(tǒng)數(shù)據(jù)結(jié)構(gòu)不同，缺乏統(tǒng)一的規(guī)劃、設(shè)計和關(guān)系關(guān)聯(lián)定義，導(dǎo)致一些必要的數(shù)據(jù)維度缺失或無法有效記錄與利用；

⑤各系統(tǒng)產(chǎn)生的數(shù)據(jù)以及人機(jī)物之間互動的數(shù)據(jù)，往往在一次性使用后即被拋棄，缺乏數(shù)據(jù)沉淀，潛在價值無法被進(jìn)一步挖掘；

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

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

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

2 基于物聯(lián)網(wǎng)的奧卡姆剃刀

那么，在當(dāng)前ICT技術(shù)日新月異、信息化正助力各行各業(yè)數(shù)字化轉(zhuǎn)型的時代大背景下，有沒有一套完整的思維方法和工具來協(xié)助我們，去實踐建筑智能化行業(yè)的數(shù)字化轉(zhuǎn)型，去進(jìn)行“科學(xué)的頂層設(shè)計”呢？答案是肯定的，它正是“物聯(lián)網(wǎng)”。物聯(lián)網(wǎng)以信息統(tǒng)一、網(wǎng)絡(luò)融合、資源共享、應(yīng)用互通以及終端復(fù)用的方式，實現(xiàn)了將相關(guān)的信息服務(wù)融合在一起。

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

表1 物聯(lián)網(wǎng)視角下智能建筑常用子系統(tǒng)分類表

其中，歸屬物聯(lián)網(wǎng)的網(wǎng)絡(luò)本身的通信類子系統(tǒng)如表2所示（見表2）。

表2 歸屬物聯(lián)網(wǎng)傳輸網(wǎng)絡(luò)的通信類子系統(tǒng)

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

圖1 智能化工程架構(gòu)規(guī)劃圖

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

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

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

3 物聯(lián)網(wǎng)智慧云平臺的實現(xiàn)

云端服務(wù)的物聯(lián)網(wǎng)云平臺由服務(wù)器、容器基礎(chǔ)設(shè)施、物聯(lián)網(wǎng)中臺、智能化中臺服務(wù)、智能化服務(wù)與應(yīng)用、運營管理應(yīng)用構(gòu)成。智能化中臺服務(wù)對資源模型和資源數(shù)據(jù)進(jìn)行統(tǒng)一管理，對各專業(yè)設(shè)備的實時運行數(shù)據(jù)進(jìn)行融合，為上層的智能化服務(wù)和應(yīng)用提供支撐，而智能化服務(wù)和應(yīng)用是為物聯(lián)網(wǎng)云平臺運營管理應(yīng)用場景提供技術(shù)支撐的。

1）云腦基礎(chǔ)設(shè)施

宜采用基于容器技術(shù)搭建統(tǒng)一的私有云服務(wù)器集群，具體如下。

①采用不少于兩臺通用服務(wù)器構(gòu)成物聯(lián)網(wǎng)平臺服務(wù)器集群，采用負(fù)載均衡技術(shù)和高可用技術(shù)，通過寬帶物聯(lián)網(wǎng)與部署在各樓層的邊緣網(wǎng)關(guān)通信，實現(xiàn)對現(xiàn)場機(jī)電設(shè)備的接入和控制。

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

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

④采用兩臺通用服務(wù)器構(gòu)成應(yīng)用服務(wù)器集群，運行智能化服務(wù)、運營管理服務(wù)和應(yīng)用。

⑤采用兩臺通用服務(wù)器構(gòu)成數(shù)據(jù)庫服務(wù)器集群，采用負(fù)載均衡技術(shù)和高可用技術(shù)，實現(xiàn)對各種資源、配置、性能、空間、告警數(shù)據(jù)的存儲、查詢、統(tǒng)計等相關(guān)處理。

2）容器云基礎(chǔ)設(shè)施

容器已經(jīng)在生產(chǎn)環(huán)境中被廣泛采用，以實現(xiàn)資源的動態(tài)分配和彈性伸縮，因此推薦采用開源K8s管理平臺Rancher，在生產(chǎn)環(huán)境中實現(xiàn)Docker的全?；萜鞑渴鹋c管理。

3）綜合呈現(xiàn)系統(tǒng)

采用LED顯示屏及相應(yīng)的編解碼器和控制器，搭建綜合呈現(xiàn)系統(tǒng)。配套數(shù)據(jù)計算、數(shù)據(jù)分析服務(wù)、平臺門戶服務(wù)等，為管控營人員提供大數(shù)據(jù)的多維呈現(xiàn)。

注意在建筑規(guī)模較小、實際接入終端較少的情況下，上述服務(wù)器可以進(jìn)行合并簡化、減少初投資，一般建議將物聯(lián)網(wǎng)平臺服務(wù)器、應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器合并在同一臺物理服務(wù)器中。

3.1 軟件架構(gòu)設(shè)計

信息系統(tǒng)的本質(zhì)在于以業(yè)務(wù)應(yīng)用為目的，對所獲取的信息進(jìn)行處理和加工。硬件設(shè)施是整個系統(tǒng)所有數(shù)據(jù)生產(chǎn)、傳輸、處理、存儲的載體，而各種數(shù)據(jù)信息的處理過程則是由軟件技術(shù)架構(gòu)來承載的。

3.1.1 設(shè)計指導(dǎo)思想

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

①首要的目標(biāo)是終結(jié)以往孤島叢生的多系統(tǒng)集成態(tài)勢，鍛造大一統(tǒng)的建筑操作系統(tǒng)。

②解決溝通障礙和信息割裂的前提在于做好底層的數(shù)據(jù)通信、數(shù)據(jù)采集、指令下發(fā)和數(shù)據(jù)建模。因此要搭建統(tǒng)一的動態(tài)數(shù)據(jù)建模平臺，統(tǒng)一實現(xiàn)各種數(shù)據(jù)的建模、關(guān)系建模、數(shù)據(jù)結(jié)構(gòu)設(shè)計、數(shù)據(jù)字典以及元數(shù)據(jù)管理，從而實現(xiàn)“書同文”。

③通過統(tǒng)一的通信協(xié)議選擇、統(tǒng)一的組網(wǎng)設(shè)計、統(tǒng)一的服務(wù)器部署、統(tǒng)一的信息安全及權(quán)限管理，實現(xiàn)“車同軌”。

④通過統(tǒng)一的算法框架、統(tǒng)一的規(guī)則引擎、統(tǒng)一的調(diào)度引擎、統(tǒng)一的流程引擎、統(tǒng)一的數(shù)據(jù)呈現(xiàn)，規(guī)約數(shù)據(jù)的處理和驅(qū)動模式，實現(xiàn)“行同倫”。

2）開源與開放性

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

②保持?jǐn)?shù)據(jù)的開放性，也就是一定要使用通用的通信協(xié)議。

3.1.2 架構(gòu)設(shè)計

關(guān)注整個架構(gòu)的穩(wěn)定、持續(xù)、健壯和可擴(kuò)展能力。在軟件架構(gòu)設(shè)計中應(yīng)綜合運用現(xiàn)有ICT成熟技術(shù)，包括數(shù)據(jù)建模、多協(xié)議適配的物聯(lián)網(wǎng)平臺、算法引擎、規(guī)則引擎、調(diào)度引擎、負(fù)載均衡及高可用、軟件容器技術(shù)等。在整體技術(shù)架構(gòu)上，我們選擇SpringCloud（云計算）框架技術(shù)來實現(xiàn)基于容器技術(shù)和微服務(wù)的云平臺架構(gòu)（見圖3）。

圖3 軟件技術(shù)架構(gòu)圖

1）微服務(wù)架構(gòu)

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

邏輯集中的服務(wù)調(diào)度管理平臺Rancher，對系統(tǒng)各個服務(wù)的狀態(tài)進(jìn)行監(jiān)控，快速進(jìn)行故障切換和服務(wù)恢復(fù)，具備秒級的服務(wù)故障自愈能力。

2）數(shù)據(jù)庫服務(wù)與緩存服務(wù)

從圖3中可以看出，系統(tǒng)采用了redis的內(nèi)存數(shù)據(jù)存儲、Postgresql進(jìn)行時序數(shù)據(jù)、結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的統(tǒng)一存儲。

3）消息服務(wù)

在微服務(wù)架構(gòu)中，服務(wù)之間是松耦合，主要采用消息訂閱方式發(fā)布數(shù)據(jù)，以達(dá)到前后端應(yīng)用的分離。服務(wù)內(nèi)部通信需要依賴消息總線，系統(tǒng)采用RabbitMQ作為消息服務(wù)總線。

4）負(fù)載均衡服務(wù)

對負(fù)載較大的前端WEB服務(wù)、數(shù)據(jù)計算服務(wù)、資源服務(wù)，系統(tǒng)采用了Spring‐Cloud的Ribbon組件實現(xiàn)負(fù)載均衡服務(wù)。

5）多協(xié)議適配引擎

需采用多協(xié)議適配引擎來支持多種協(xié)議和規(guī)約，如BACNET、MODBUS、CBUS、EIB、ZigBee協(xié)議IEC102、104規(guī)約等等，能夠與各相關(guān)廠家的終端設(shè)備通信，解析采集到的數(shù)據(jù)，遠(yuǎn)程調(diào)用相應(yīng)指令對這些設(shè)備進(jìn)行監(jiān)控等。

多協(xié)議適配引擎內(nèi)部基于模塊化設(shè)計，支持動態(tài)網(wǎng)絡(luò)協(xié)議解析腳本的加載和適配，可以將封裝在以太幀中的異構(gòu)協(xié)議數(shù)據(jù)正確獲取和解析，歸一化為標(biāo)準(zhǔn)的數(shù)據(jù)格式（JSON），以便上位系統(tǒng)能正常處理。反之，系統(tǒng)的聯(lián)動或控制指令由協(xié)議適配引擎翻譯為受控對象及設(shè)備的協(xié)議指令格式，由邊緣網(wǎng)關(guān)下發(fā)到受控對象及設(shè)備，以便其正確執(zhí)行。

6）算法引擎、規(guī)則引擎與調(diào)度引擎

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

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

3.2 云平臺功能模塊

3.2.1 物聯(lián)網(wǎng)中臺

物聯(lián)網(wǎng)中臺是智慧建筑操作系統(tǒng)的基座，物聯(lián)網(wǎng)平臺負(fù)責(zé)虛擬設(shè)備對象（數(shù)字孿生體或設(shè)備影子）的生命周期管理，借助虛擬設(shè)備對象實現(xiàn)對實體設(shè)備的管控，并為上層平臺提供統(tǒng)一的接口。具體功能包括設(shè)備注冊和認(rèn)證、同步資源模型和資源數(shù)據(jù)、虛擬設(shè)備對象生命周期管理、虛實對象狀態(tài)同步等。

3.2.2 智能化中臺

智能化中臺可分為數(shù)據(jù)中臺和業(yè)務(wù)中臺，數(shù)據(jù)中臺側(cè)重于數(shù)據(jù)服務(wù)，業(yè)務(wù)中臺側(cè)重于業(yè)務(wù)應(yīng)用支持。智能化數(shù)據(jù)中臺對資源模型和資源數(shù)據(jù)進(jìn)行統(tǒng)一管理，對各專業(yè)設(shè)備的實時運行數(shù)據(jù)進(jìn)行融合，為上層的智能化服務(wù)和應(yīng)用提供支撐；而業(yè)務(wù)中臺的服務(wù)又可細(xì)分為前端應(yīng)用服務(wù)和后端應(yīng)用服務(wù)。

后端應(yīng)用服務(wù)包括資源服務(wù)、數(shù)據(jù)計算服務(wù)、監(jiān)控告警服務(wù)、事件服務(wù)等，它們處理感知系統(tǒng)和交互系統(tǒng)產(chǎn)生的各種數(shù)據(jù)，使其成為標(biāo)準(zhǔn)格式，增加業(yè)務(wù)的可理解性，以共享的數(shù)據(jù)服務(wù)構(gòu)成智慧建筑數(shù)據(jù)中臺，向前端各類應(yīng)用服務(wù)提供訂閱調(diào)用。

上層應(yīng)用服務(wù)需要統(tǒng)一使用的中臺支撐，包括API網(wǎng)關(guān)服務(wù)、數(shù)據(jù)訪問服務(wù)、負(fù)載均衡服務(wù)、消息服務(wù)、緩存服務(wù)、日志服務(wù)、監(jiān)控服務(wù)、數(shù)據(jù)庫服務(wù)等。這些前端應(yīng)用服務(wù)是為了讓應(yīng)用系統(tǒng)其他服務(wù)得以正常工作、互相訪問、提供可維護(hù)性而存在的平臺級服務(wù)。

3.2.3 智能化服務(wù)與應(yīng)用

智慧建筑場景下的應(yīng)用系統(tǒng)在統(tǒng)一的數(shù)據(jù)模型、網(wǎng)絡(luò)架構(gòu)、技術(shù)架構(gòu)下，基于統(tǒng)一的服務(wù)框架構(gòu)建上層應(yīng)用的組合，且服務(wù)間能通過內(nèi)部API接口互訪。實現(xiàn)靈活適配業(yè)主多樣化需求、基于場景的跨應(yīng)用調(diào)用與融合，比之前的智能化工程展現(xiàn)出超強(qiáng)的靈活性、可擴(kuò)展與可實施性。

如圖4所示，鑒于當(dāng)前用戶的使用習(xí)慣，平臺提供的智能化服務(wù)主要涵蓋了GB 50314中智能建筑常見通用功能服務(wù)（子系統(tǒng)），如物業(yè)管理應(yīng)用、一庫（卡）通應(yīng)用、各項信息設(shè)施系統(tǒng)服務(wù)、各項建筑設(shè)備管理服務(wù)、各項公共安全管理服務(wù)等；以及面向?qū)I(yè)場景的服務(wù)，如客流統(tǒng)計、資產(chǎn)管理、位置服務(wù)、智能家居、智慧醫(yī)療、訪客管理與車位引導(dǎo)。

圖4 物聯(lián)網(wǎng)應(yīng)用支撐平臺功能架構(gòu)

3.2.4 運營管理應(yīng)用

通過采用“云、管、端”的技術(shù)架構(gòu)，實現(xiàn)了對基礎(chǔ)設(shè)施的一體化接入和管理。接下來可將基礎(chǔ)設(shè)施的能力進(jìn)行封裝和編排，以“空間、時間、設(shè)施、規(guī)則”作為關(guān)鍵要素，為上層業(yè)務(wù)運營管理系統(tǒng)提供可標(biāo)準(zhǔn)化描述，可自動化開通、智能化運行、定義服務(wù)水平、實時精確計量和計費的基礎(chǔ)設(shè)施服務(wù)，從而實現(xiàn)“建筑即服務(wù)”。

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

4 結(jié)語

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