關于電梯遠程監控系統與電梯之間通用通訊協議的研究

史 新/范麗麗

1. 中國電子工程設計院， 北京 100840； 2. 北京市建筑設計研究院， 北京 100045

1 引言

隨著高層建筑的大量涌現, 電梯的使用也日益廣泛與普及, 怎樣保證電梯能夠安全高效的運行, 不僅越來越多地引起了維護保養業界人士的關注, 也成了眾多電梯用戶關心的焦點。基于這種現實的需求及伴隨著計算機控制技術和網絡技術的發展，電梯遠程監控技術應運而生。

所謂電梯遠程監控系統（Elevator Remote Central Control and Monitoring System），是指建筑物內安裝多部電梯后,對這些電梯進行遠程監控、數據管理、維護、統計、分析、故障報警及救援。其目的是對電梯進行遠程數據維護、故障報警，以及對電梯的運行性能（群控效果、使用頻率、故障次數及故障類型） 進行統計與分析,并在分析的基礎之上輔助專業人員選擇合理的派梯方案[1]。

但在現實應用中，電梯遠程監控系統都是由電梯廠家自己開發的，只針對自己廠家的電梯，而對其他公司電梯的監控則無能為力。其根源在于每個電梯廠家采集數據的通訊協議都是自己廠家的專用協議，不具有開放性。這樣就導致從底層電梯控制系統到上層監控系統都由一個廠家生產，易形成壟斷，市場上表現為監控系統的價格比較昂貴，一般用戶難以承受。

在IT行業，通用協議很早就已開始使用，用來保證不同廠家的產品可以自由通訊。在樓宇自動化行業，BACnet、LonWorks、Konnex 等開放協議也已廣泛使用。通過使用通用協議，不同廠商的產品可以互相通訊，為系統集成提供便利。但在電梯行業還未采用通用協議。

目前，市場上有很多基于通用協議的組態軟件和基于網絡（web）的瀏覽器和技術，如何將電梯數據采集的協議通用化，即，將電梯運行的各個現場數據統一成通用的格式，是需要解決的問題。一旦電梯數據格式具有通用性、開放性，這樣就有利于監管部門的管理，更有利于電梯遠程監控系統的發展與應用。

2 通用協議的采用

所謂通用協議必須是世界上廣泛接受的技術，具有開放性的特點，市場上必須有足夠多的廠家使用該項技術。本文選用三種世界通用的標準協議（XML、BACnet、LonWorks）作為研究對象，將電梯廠家的專有協議轉化為上述三種協議，提供通用的接口，便于上層監控軟件的二次開發。

2.1 XML

XML（The Extensible Markup Language） 即可擴展標記語言。標記是指計算機所能理解的信息符號，通過此種標記，計算機之間可以處理包含各種信息的文章等。定義這些標記，既可以選擇國際通用的標記語言，比如HTML，也可以使用諸如XML這樣由相關人士自由決定的標記語言，這就是語言的可擴展性。

XML應用面主要分為文檔型和數據型兩種類型，幾種常見的XML應用有：

1）自定義XML+XSLT=>HTML，最常見的文檔型應用之一。XML存放整個文檔的XML數據，然后XSLT將XML轉換、解析，結合XSLT中的HTML標簽，最終成為HTML，顯示在瀏覽器上。

2） XML作為微型數據庫，這是最常見的數據型應用之一。利用相關的XML API（MSXML DOM、JAVA DOM等）對XML進行存取和查詢。

3）作為信息傳遞的載體，盡管這些應用還是以XML為基本形態，但均已經發展出具有特定意義的格式形態。最典型的就是WEB SERVICE，將數據包裝成XML來傳遞，但是這里的XML已經有了特定的規格，即SOAP。

本研究中就是使用XML作為信息傳遞的載體，將電梯的現場數據轉化為XML格式、利用TCP/IP來傳遞的。

2.2 BACnet

BACnet是由美國供熱、制冷與空調工程師協會組織（ASHRAE）的標準項目委員會（SPC）于1995年6月正式通過制定的。標準編號為ANSI/ASHRAE Standard 135-1995，現在標準已發展到ANSI/ASHRAE Standard 135-2004版本。

一般樓宇自控設備從功能上分為兩部分：一部分專門處理設備的控制功能；另一部處理其數據通信功能。而BACnet就是要建立一種統一的數據通信標準，使得設備可以互操作。BACnet協議只是規定了設備之間通信的規則，并不涉及實現細節。

BACnet 的靈魂是它的互操作性，即不同廠家的設備能夠很好的互聯互通。從而在一定層面上實現了體系結構的統一, 這主要是由它的協議體系結構決定的[2,3]。BACnet 參照 ISO/OSI 的 7 層標準協議模型，并根據控制系統本身的特點，對它進行了簡化和改進。考慮到控制系統本身要求快速、簡捷，將原來的 7 層模型改為 4 層，如圖1所示[2]。協議定義了自己的網絡層和應用層，從而將控制體系在一個較高層面上統一起來。在數據鏈路層和物理層，考慮到現存各種網絡的既定事實；同時也是為了使協議具有更好的兼容性、開放性，并兼顧各標準的優點和特點，協議提供了5 種不同的選擇方案。包括以太網、ARCnet、MS/TP、RS485、RS232、LonTalk[2]等，并為每種方式提供了相應的標準。其中 LonTalk 的使用必須得到 Echelon 公司的OEM 許可，并且要做一個 BACnet原語到 LonTalk 應用層接口的映射。通過以上設計，使得 BACnet 協議在體系結構上保證了標準性和開放性。

圖1 BACnet 4層ISO/OSI協議模型

2.3 LonWorks

LonWorks技術由美國埃施朗（Echelon）公司研發，已成為國際控制網絡的通用標準。LonWorks協議，也稱為LonTalk協議和ANSI/EIA 709.1控制聯網標準，是LonWorks系統的核心。該協議是一個分層的以數據包為基礎的對等（Peer to Peer）通信協議。如同相關的以太網和因特網協議一樣，它是一個遵守國際標準化組織（ISO）開放系統互連（OSI）參考模型的分層體系結構準則的、公開的標準[4]。

LonWorks技術中的核心是神經元芯片與收發器，每一個神經元芯片構成的控制器為網絡中的一個節點，不同的節點之間通過收發器對等的進行通訊。LonWorks網絡支持多種介質的傳輸，包括：雙絞線、電力線、同軸電纜、光纖等。網絡變量、配置屬性與功能塊是數據的體現形式：網絡變量通過虛擬連接的方式實現了不同節點、不同變量之間的通訊；配置屬性定義了變量、功能塊等的屬性；功能塊可以理解為一個實現某個功能的函數。

LonMark互操作協會定義了標準的網絡變量、配置屬性、功能塊，實現不同廠家產品的互操作性與通用性。

3 研究中需要限定的問題

從電梯生產廠家的立場出發，首先，他們不反對電梯遠程監控系統，但是，他們對電梯的遠程控制仍持保留意見。我們也有同樣的觀點，在不知道現場情況的條件下，進行電梯的遠程控制是相當危險的。所以，電梯的遠程控制一定要慎重。只有那些不涉及到乘梯人安全的操作才可以遠程操作。故在本文中的協議轉化數據僅限于電梯的監視數據，不涉及到電梯的控制命令。

另外，電梯廠家仍然不愿意將他們的專有協議公開，所以我們提供協議轉換的方案和數據格式，可由電梯廠家來實現他們自己的專有協議到通用協議的轉換。也就是說，電梯廠家自己生產網關。但是，這勢必會增加電梯廠家的成本，現階段可能很多廠家不愿意做這件事情。但是從電梯監管部門來講，一個統一的通用協議有利于電梯監控系統的發展，有利于電梯數據的記錄、統計、分析和故障情況報警及救援。本研究為電梯監管部門提供了通用的電梯數據格式和協議轉換的方案，幫助他們向電梯廠家推廣。

4 協議轉化

電梯有很多種類型的數據和信息，本文重點研究電梯廠家、電梯安裝公司、業主、電梯使用者和電梯遠程監控系統廠家關心的數據，即電梯運行的原始數據。對于由原始數據衍生出來的其他數據，本文中不作定義。這些數據可利用原始數據在上層監控端生成，供管理人員進行數據統計分析。

4.1 轉化框圖

為了實現協議轉化，首先要采集電梯現場數據。現在電梯廠家常用的協議為Modbus，采集數據后進行轉換，然后封裝成TCP/IP格式提供給遠程監控系統。如圖2所示。

4.2 硬件支持

針對不同廠家的專有協議，最好的方法是開發一個網關，實現協議的翻譯功能。如圖2所示，ULEG（Universal Lift and Escalator Gateway）即為用來實現轉化功能的設備，本研究中用一臺電腦來實現。網關的下層接口通過RS232接口與電梯控制器連接，讀取電梯的數據。三種協議（XML、BACnet、LonWorks）報告單元通過局域網或廣域網與上層監控軟件實現通訊。測試成功后，這臺電腦不是必需的，可以由電梯廠家根據自己的協議生產自己的監控級控制器，即網關。

4.3 軟件結構

1） 數據格式定義（DP message definition）

各個廠家不同的協議需要統一數據格式，我們定義了數據協議消息的格式：G,C,E,參數1[,參數2[,參數3]],參數4

其中: [ ]表示可選項,可以省略

G —表示電梯分組（Group），用1 9 的ASCII代碼表示，0表示不屬于電梯組的事件。

C —表示電梯（Car）編號，用1 9 的ASCII代碼表示，0表示不屬于本電梯的事件。

E —表示事件（Event）類型，用01到99的ASCII代碼表示。

參數 —表示事件各個參數。

例如 ：“1,0,1,1,14,2, 2006-05-10 22:40:50.123” 表示第一組電梯在14層有向下的呼梯。

Group = 1

Lift = 0 （即表示組事件）

Event Type = 01

State = 1

Floor = 14

Direction = Down

Time = 2006-05-10 22:40:50.123

表1列舉了其中一個事件的參數定義，本研究中定義了電梯各種數據的數據類型。DP是數據轉換的中間格式，通過XML、BACnet和LonWorks的報告單元（Reporter）轉換成相應的XML、BACnet和LonWorks協議供監控系統使用。

2） XML通用協議

通過XML報告單元，轉化成TCP/IP格式，基于網絡服務技術和XML圖表，可以顯示電梯的靜態和動態數據。XML數據格式定義如下：

例如：DP: 1,0,1,1,9,2,2006-07-25 14:41:47.203

XML數 據 格 式:

3） BACnet通用協議

在ULEG內部，數據經過掃描器、轉換器后生成DP的格式，由BACnet報告單元生成BACnet對象格式，供BACnet CCMS使用。BACnet對象定義格式如下：

DP event type 01 （Landing Call） （normal control system）

Object_Identifier BACnetObjectIdentifier

Object_Name CharacterString

Object_Type Muti DataInputObjectType

Present_Value BACnetARRAY[N]of

表1 事件參數定義舉例

BACnetLndCallStatus

BACnetLndCallStatus::= SEQUENCE {

Floor_number Unsigned8,

command CHOICE {

direction BACnetLiftDirection,

destination Unsigned8

},

}

BACnetLiftDirection ::= ENUMERATED {

Up （1）, Down （2）, Up and down （3）,

}

4） LonWorks通用協議

LonWorks通用協議需要依賴于硬件，如圖2中RS232-LON網關即為LonWorks協議的承載體。在RS232-LON網關上需要載入功能塊、網絡變量、配置屬性。根據電梯的消息類型來定義LonWorks協議下的數據類型。如圖3所示為電梯故障情況信號功能塊，表2定義了該變量的數據格式。除了這個變量，電梯的每一個數據本研究都作了定義。

表2 電梯故障情況功能塊中網絡變量定義

5 系統測試

針對上述設計思路和實現方式，我們對兩個不同廠家的電梯進行了測試。連接電梯系統的RS232接口到ULEG，通過Internet或Intranet連接電梯遠程監控系統主機，觀察電梯數據上傳的速度和監測數據的準確性。此項測試與原有電梯廠家的監控系統對比，可以完全達到一致的顯示。

6 研究成果與進一步研究方向

本研究定義了電梯需要監控的數據，并且將其轉化為通用協議，提供給業主、用戶、監管部門一個開放的接口，方便上層監控軟件公司開發二次監控軟件。本研究中提供了ULEG的硬件設備用于測試，我們建議以后由電梯廠家生產這個網關，本研究項目能提供數據定義、轉換方法及轉換源代碼，電梯廠家不用自己開發，可以利用這個研究項目生產。

但是，現實的問題是電梯廠家仍然不愿意將他們的專有協議公開，這就需要監管部門提出通用協議的概念，推動電梯遠程監控的發展。

對于電梯協議標準化的問題，需要與美國供熱、制冷與空調工程師協會組織（ASHRAE）與LonMark協會聯系，將電梯的BACnet與LonWorks標準數據格式納入到標準中。

參考資料

[1]John Bashford （J Bashford & Associates）. CIBSE Guide D Transportation Systems in Buildings[DB].

[2]ANSI/ASHRAE Standard 135-2001: BACnet-A Data Communication Protocol for Building Automation and Control Networks[S]. ASHRAE, Atlanta,Georgia, USA, 2001.

[3]董春橋. 智能樓宇BACnet原理與應用[M]. 北京：電子工業出版社，2003.

[4]美國埃施朗公司北京代表處.LonWorks系統介紹（1版）[DB].http://wenku.baidu.com/view/be6947c4bb4cf7ec4afed05e.html，2005.