樓宇自控系統的集成技術及未來發展方向
自上世紀80年代引入微處理器(micro processor)技術以來,樓宇自控技術的發展已走過了20多年的歷程。樓宇自控設備從沒有通信功能的獨立控制器發展成為具有通信功能的網絡控制器,樓宇自控系統從樓宇設備的控制系統(BAS)發展到樓宇設備控制系統與火災報警消防聯動、安全防范的集成控制系統(BMS),隨著智能建筑的進一步發展,不僅要求樓宇自控系統本身高效、集成,而且還要求與其他系統(如物業管理系統)高效集成,稱為建筑集成管理系統(IBMS)。因此,樓宇自控系統(BMS)的集成直接關系到智能建筑集成系統的成敗。
回顧樓宇自控系統集成技術的發展歷程,并對不同發展階段的集成技術進行分析,既可以恰當地利用好當前的集成技術,又可以把握樓宇自控系統集成技術的發展方向,及時掌握新技術,以迎接新時代的挑戰。本文根據樓宇自控系統的發展過程,結合IT技術的發展,對樓宇自控系統集成技術進行了如下3個方面的分析和展望,以供參考。
1、面向協議的集成技術
從第一個基于微處理器的樓宇控制器出現以來,樓宇自控的發展就與IT技術的發展密切相關,可以說,IT技術的發展是推動樓宇自控發展的動力。最初,樓宇自控設備是沒有通信功能的孤立控制器,其作用只是對某一個樓宇設備或幾個設備進行監控。當對樓宇自控設備的要求提高后,如能量管理等,樓宇自控設備必須加入通信功能,樓宇自控就引入了網絡技術,從而形成了采用網絡通信的樓宇自控系統。在采用網絡通信的樓宇自控系統中,通信協議(communication protocol)是樓宇自控系統通信技術的關鍵。最初的通信協議是專用的(proprietary)通信協議,由各生產廠商單獨制定,專用于自己的樓宇自控產品,不對外開放,甚至將專用通信協議作為技術或商業秘密加以保護。
隨著市場的發展,業界認識到通用型開放性通信協議對用戶的重要性。于是有些具有實力的廠商或公司向業界公開自己的通信協議,希望得到業界的大量采用而成為事實上的標準。時至今日,已有不少于10種通信協議“粉墨登場”。眾多公開的通信協議給樓宇自控系統集成帶來了困難。在市場和技術競爭的機制下,得到業界公認的通信協議標準只有BACnet標準和LonWorks標準。根據工業控制領域的經驗,樓宇自控行業在短期內不可能出現統一的協議標準,多種公開的協議標準仍將并存。
在多標準并存的樓宇自控系統中,最早出現的系統集成技術就是面向協議(protocol-oriented)的集成技術。這種集成技術的核心就是通信協議的轉換,實現通信協議轉換的互連設備往往稱為“網關(gateway)”。圖1是這種集成技術的基本結構圖,其中,運行集成系統主界面的工作站通常是基于集成系統中的主通信協議的。這種集成技術在目前已得到了廣泛的應用,尤其在已建系統中用另一種不同協議標準擴展時就必須采用這種技術進行系統集成。
從系統集成的層次來看,樓宇自控網絡通信協議是對樓宇自控設備(即通信實體)的抽象描述。不同的通信協議通常采用不同的描述方式和信息模型,有的通信協議采用面向對象的信息模型(objectoriented information model),這種信息模型具有一定層次的數據結構,如BACnet和EIB-OBIS(European Installation Bus Object Interface Specification)標準,而有的通信協議采用面向寄存器的模型(register-oriented information model),這種信息模型是“扁平(flat)”的,不具有層次化的數據結構,如Modbus和LonTalk標準。因此,面向協議的集成技術是以“描述信息模型”為中心的,實質上是協議描述信息模型的轉換,并且這種信息模型轉換是在二進制編碼(binary encoding)的層面上進行的。
由于這種集成技術是在二進制編碼基礎上進行的轉換,當集成系統中存在多種通信協議標準時,這種集成技術的代價就會太大,并且存在模型轉換不完全的現象。另外,當非集成主標準系統(次協議系統)擴展時,升級網關的代價較大。隨著IT技術的發展,為了克服這種集成技術的缺點,出現了“面向平臺(platform-oriented)”的集成技術。
2、面向平臺的集成技術
面向平臺的集成技術是以“信息集成”為核心的,通過定義自控網絡中通信實體信息交換的標準接(interface),以屏蔽不同通信協議對通信實體信息模型的差異。不論通信協議對通信實體進行何種模型描述,只要描述的信息模型提供標準的信息集成接口,則可以在這個標準接口上實現信息的集成,從而實現控制系統信息共享和互操作的集成目標。與面向協議集成技術相比,這種集成技術是一種較高層次上的集成技術。
另外,通過信息交換的標準接口還可以實現控制系統與辦公管理系統(OAS)的集成。這種優點正好符合控制系統與信息管理系統集成的發展趨勢,因而這種技術目前正處于高速發展和成熟的階段。面向平臺的集成技術雖然屏蔽了信息模型的差異,但標準接口的實現是與信息集成平臺密切相關的。也就是說,不同的集成平臺具有不同的信息接口和實現機制,例如,可以通過“協議設備驅動器(protocol deviced river)”的內核接口進行系統集成。在各種不同的信息集成方法中,最為著名的是OPC(OLEfor Process Control)技術。
OPC技術是由Microsoft公司發起的一個工業標準,目前由OPC基金維護。這個標準定義了Windows系統中應用程序與各種設備驅動程序交換控制信息的標準接口。它采用客戶/服務器(C/S)體系,包括OPC服務器和OPC客戶兩個部分。其中,應用程序作為OPC接口中的客戶端,硬件驅動程序作為OPC接口中的服務器端。在OPC技術中,每一個OPC客戶端應用程序可以連接多個OPC服務器,反過來,每一個OPC服務器可以為若干個OPC客戶端應用程序提供數據。圖2為利用OPC技術的集成系統結構圖。
OPC技術是面向平臺集成技術的典型范例,這種集成技術廣泛應用于各種自控領域,在樓宇自控領域,Siemens公司的APOGEE系統就采用了這種集成技術。
面向平臺的集成技術雖然在較高層次上實現了控制系統的集成,但這種集成技術與平臺相關。為了實現跨平臺的系統集成,又出現了如下“面向Web”的集成技術。
3、面向Web的集成技術
提到Web,我們既熟悉,又感到陌生。我們幾乎每天都離不開Web,但對Web的內涵卻不甚了解。我們常用Web瀏覽器(browser),就以為瀏覽器是Web的全部內涵,從而導致有些人認為基于Web瀏覽器的樓宇自控系統就是“面向Web集成技術”的集成系統。確實,Web瀏覽器利用HTML技術極大地改變了我們使用Web的方法,但Web瀏覽器只是Web內涵的一個極小部分,目前絕大部分基于Web瀏覽器的樓宇自控系統實質上并不是面向Web集成技術的集成系統。面向Web的集成技術是當前所有系統集成領域正在經歷的革命性技術。
現階段大多數基于Web瀏覽器的樓宇自控系統之所以不是面向Web集成技術的系統,主要原因有兩點,一是這種系統只是利用Web瀏覽器訪問靜態數據,而這種靜態數據通常早已存儲在某個數據庫(布置在Web上)之中。二是數據庫中存儲的數據是由其他集成技術(通常為上述兩種集成技術)所產生或生成的。因此,基于Web瀏覽器的樓宇自控系統只是在其他集成技術建立的集成系統之上加入Web瀏覽器作為人-機操作界面的系統。雖然目前絕大部分基于Web瀏覽器的系統不是面向Web集成技術的系統,但這種系統提供統一的人-機界面,還可以利用Web瀏覽器的客戶/服務器模式在Web上進行布置,實現遠程、無線等監控功能。因而在面向Web集成技術的集成系統中也通常采用Web瀏覽器作為人-機主界面。
面向Web的集成技術是利用Web Services技術進行系統集成的技術。Web Services技術是一系列Web應用技術,這些Web應用具有“自包含、自描述和模塊化”的特點,可以在Web上發布、布置和調用。通過定義可以看出Web Services為復數形式的原因。Web Services技術是當今IT業界的焦點,其主要目標是在現有各種異構平臺的基礎上構筑一個平臺無關、語言無關,協議無關的通用技術層,通過這個技術層各種平臺上的應用可以互相連接和集成,從而實現互操作功能。
Web Services作為一種IT技術,以其開放性、標準性和簡便性在IT業界得到了廣泛應用,并正向自控領域及其系統集成應用高速滲透。利用WebServices技術進行樓宇自控系統集成正是這種發展趨勢的具體表現,代表著樓宇自控系統集成技術的發展方向。
Web Services技術包括許多高新技術,但其核心技術主要是XML(eXtensible Markup Language:可擴展標記語言)和SOAP(Simple Object Access Protocol:簡單對象訪問協議)。這兩項技術同樣也包含很多內容,但其作用可以簡單地總結為,XML用于數據描述,SOAP用于數據訪問。根據這兩項技術的作用,可以粗略地推導出利用Web Services技術進行多協議系統集成的基本原理:首先,利用XML數據描述功能將某個具體協議所描述的樓宇自控設備信息模型進行轉換或映射,形成一種具有“自包含和自描述”的信息模型。然后利用SOAP數據訪問功能對XML模型進行訪問,從而實現多協議系統的系統集成。圖3是利用這種技術進行系統集成的基本結構圖。
目前樓宇自控領域的兩大標準(BACnet和LonWorks)均定義了WebServices接口,北美大陸樓宇自動化協會(CABA:Continental Automated Buildings Association)也發起了制定Web Services接口的開放標準——oBIX(Open Building Informatione X change:開放樓宇信息交換)。以上述三個主要Web Services接口定義的文體來看,由于BACnet標準已是ISO標準,其Web Services接口將成為ISO標準的可能性較大。而CABA為了使oBIX標準得到更大范圍的認可和應用于2004年將制定和維護oBIX規范的工作移交給OASIS(the Organization for the Advancement of Structured Information Standards,一個全球非盈利組織,致力于制定和發展電子商務的標準)。目前基于Web Services技術較為成熟的樓宇自控集成系統產品是由美國ALC公司開發的WebCTRL系統。從上面的分析可以看出,面向Web的集成技術也是一種信息模型轉換技術,但這種集成技術是高層次上對信息模型進行轉換,并且轉換后的信息模型是用XML描述的。XML描述是一種自包含和自描述的“文本”文件,與平臺和語言無關,并獨立于底層具體協議,不僅自然直觀,具有“人可讀性(human —readable)”,而且更重要的是具有“計算機可讀性(machine —readable)”,即XML模型是“計算機-計算機(machine —to-machine)”的信息模型,是計算機可以“理解”的模型。從而使這種信息模型擺脫了與平臺和協議有關的專用格式的束縛,實現了與平臺無關、語言無關、協議無關的目標。
由于WebServices技術具有平臺無關、語言無關、協議無關的特性,不僅可以用于樓宇自控系統的集成,還可以用于樓宇自控系統與智能建筑中其他智能子系統的集成,實現所有建筑智能系統的集成。也正是由于這種技術具有“眾所周知和開放”的特點,這種技術也是建設“數字城市”的基礎。
值得指出的是,從理論上可以直接利用Web Services技術對樓宇自控設備進行模型描述和數據通信。但這種技術的編碼格式比具體協議所定義的專用格式靈活,且編碼效率低。這表明這種技術需要較多的計算資源,較大的傳輸帶寬和較強的處理能力。這種需求進而說明,在目前狀況下這種技術不太適用于現場級的應用或直接對樓宇自控設備進行模型描述。因此,在目前狀況下,Web Services技術不會取代BACnet或LonWorks等具體標準,只是具體通信標準的補充和擴展。盡管如此,在國外已有這方面大量的研究和嘗試。隨著IT技術的發展,尤其是微電子技術的發展,當處理成本、傳輸成本和存儲成本降低到一定程度的時候,也許這種技術會延伸至樓宇自控系統的最底層,從而成為真正的“統一標準”。
4、結論
綜上所述,IT技術的發展是樓宇自控系統集成技術的發展基礎。只有了解IT技術的發展方向和應用動態,才能把握樓宇自控系統集成技術的發展方向,為掌握新技術作好準備。
隨著IT技術的發展,面向Web的集成技術不僅是未來樓宇自控系統集成的主流技術,而且也是目前“數字城市”建設的主流技術。也許如Web業界預言一樣,Web Services將“玩轉”“數字地球”。
摘自《慧聰網》