基于物聯網的電梯安管系統通信模塊①

馮 雪, 孫丙宇, 方 薇, 吳 斌(中國科學技術大學 信息科學技術學院, 合肥 006)(中國科學院合肥智能機械研究所, 合肥 00)(安徽中科智能高技術有限責任公司, 合肥 0088)

基于物聯網的電梯安管系統通信模塊①

馮 雪1,2, 孫丙宇2, 方 薇2, 吳 斌31(中國科學技術大學 信息科學技術學院, 合肥 230026)2(中國科學院合肥智能機械研究所, 合肥 230031)3(安徽中科智能高技術有限責任公司, 合肥 230088)

電梯安管系統是采用多個獨立傳感器24小時不間斷采集電梯運行數據, 通過無線實時上傳到電梯運行監管平臺, 實現對電梯的全天候運行監測、故障信息記錄、報警預警處理和維保管理等功能的系統. 針對傳統電梯安管系統傳輸響應時間過長的問題, 設計實現了一套基于物聯網的新型電梯安管系統. 系統在管理平臺上設計了一套新型的數據傳輸通信模型, 該通信模型向下通過GPRS與底層網關交互, 向上利用基于JMS的ActiveMQ消息隊列服務與業務層交互, 大大縮短了響應時間.

物聯網; 電梯安管系統; ZigBee; GPRS; ActiveMQ; 消息隊列

物聯網(M2M)作為掀起我國第三次信息革命浪潮的主導技術, 是一種以機器終端智能交互為核心的,網絡化的應用與服務. 通過在機器內部嵌入無線通信模塊, 以光纖. 無線通信等為接入手段, 為客戶提供綜合的信息化解決方案, 以滿足客戶對監控指揮調度、數據采集和測量等方面的信息化需求[1]. 電梯安管系統(即電梯物聯網安全監管系統, 以下簡稱安管系統)是采用獨立于電梯品牌的外置多個傳感器采集電梯運行數據, 通過無線GPRS實時上傳到電梯運行管理平臺, 從而實現對電梯的全天候運行監測、故障信息記錄和維保管理等功能的系統[2-4]. 系統通過全天候監測電梯運行數據, 可及時發現電梯隱藏的問題, 予以預警和報警, 同時當電梯發生故障時, 及時保障受困人員的人身安全. 因此是否能實時、有效的傳遞電梯數據, 縮短響應時間, 通知相關電梯安管人員進行故障解除, 降低事故升級的風險, 則擁有至關重要的意義.

目前, 國內外已經有較多機構開始電梯安全運行監管系統的研發工作[5], 如美國OTIS電梯有限公司電梯監控系統. OTIS電梯監控系統可連續不斷監視電梯所有數據, 針對特定狀況預測發出警告信息, 在北美取得了很好的監控效果. 但是國外的系統普遍的特點是專用性很強, 開放性、通用性和其功能發展程度不匹配, 無法支持其他公司的電梯系統, 大大增加了監控系統區域運營的成本.

基于以上情況, 本文設計實現的安管系統完全獨立于電梯品牌, 采用獨立分布于各地的電梯傳感器采集數據, 同時設計實現了一套基于物聯網的新型的數據傳輸通信模型. 該通信模型利用GPRS與底層網關ZigBee[6,7]進行交互, 同時通過基于JMS[8]的ActiveMQ[9]消息隊列服務[10,11]與業務層進行交互, 大大縮短了響應時間. 此外, 該系統在可擴展性和數據傳輸效率上都得到了明顯的提升.

1 電梯安管系統總體架構設計

安管系統的網絡拓撲結構圖如圖1所示. 系統網絡拓撲結構可分為四部分: 感知層、通信層、數據處理層和用戶層.

1.1 感知層

感知層是指安裝在電梯內部的獨立的傳感器, 全天候不停地對電梯進行實時監測, 獲取電梯的各種運行指標, 如: 運行速度、運行方向、運行加速度、是否有人、當前樓層等20多項數據, 并將這些數據通過傳感器ZigBee通信模塊傳遞給傳送給小區網關的ZigBee通信模塊的過程.

圖1 網絡拓撲結構圖

考慮到電梯運行的特點, 不方便采用電纜連接,故本系統采用無線網絡進行數據的傳遞, 通信標準采用目前流行的ZigBee技術[12,13]. 電梯內部的傳感器實時監測電梯的運行狀況, 得到運行參數后通過傳感器的ZigBee模塊把數據傳送到通信層. 感知層的結構圖如圖2所示.

圖2 感知層結構圖

每個電梯傳感器和網關都有唯一的4字節ZigBee編碼地址. 傳感器向網關發送注冊包, 得到網關的注冊成功確認后, 兩者就可以進行數據傳輸. 小區網關則向傳感器數據采集服務器發送注冊包, 服務器通過固定間隔不斷向網關發送7字節的心跳包, 確認網關是否在線. 該心跳包包含兩字節的數據頭、4字節的網關ZigBee地址和1字節的數據尾. 若網關有回應則代表其在線, 連接正常. 若網關超過一定的時間沒有回應, 則服務器默認網關掉線, 將其剔除. 網關則會在自動上線之后重新向服務器發送注冊請求.

1.2 通信層

通信層包括兩部分: 小區網關與傳感器數據采集服務器之間的通信、傳感器數據采集服務器與城域監管云平臺(以下簡稱云平臺)之間的通信, 及云平臺與用戶層的通信. 通信層的結構如圖3所示. 其中, 傳感器數據采集服務器、云平臺和ActiveMQ均獨立位于外網, DB數據庫則位于小區內部局域網, 但對云平臺開放.

圖3 通信層結構圖

通信數據傳輸分為數據主動發送和用戶主動獲取.數據主動推送是小區網關把從傳感器接收到的電梯運行參數數據, 通過GPRS發送到傳感器數據采集服務器[14], 傳感器數據采集服務器接收到來自網關的數據后把數據存儲到數據庫中保存. 特別的, 當數據為預警報警數據時, 則同時將其發送給云平臺并通知到相應的維保人員. 用戶主動獲取是用戶請求通過云平臺發送給傳感器數據采集服務器, 傳感器數據采集服務器根據請求的具體內容, 主動獲取某個電梯的傳感器數據, 并將其返回.

傳感器數據采集服務器與云平臺之間通過ActiveMQ提供的消息隊列來進行通信, 接收線程包括輪詢線程和主動接收線程兩個, 輪詢線程采用同步監聽模式[15], 每天定時三次輪詢電梯狀態, 而當監聽到傳來的數據為報警或預警數據時, 主動接收線程會采用中斷優先策略傳遞異常狀態, 即優先中斷輪詢間隔,并及時推送警示給用戶.

1.3 數據處理層

數據處理層包括數據采集服務器和云平臺. 數據處理層和通信層包含的結構類似, 但是與通信層的數據傳輸不同, 數據處理層所做的是數據采集服務器和云平臺內部處理數據和請求的過程. 系統數據處理主要包括: 預警報警處理、實時請求處理等模塊.

1.4 用戶層

用戶層包括兩類: 固定用戶和移動用戶, 固定用戶是指Web客戶端注冊的用戶, 移動用戶則是智能手機App端注冊用戶. 針對省/市中心用戶、物業用戶、維保用戶和檢驗用戶五類用戶群體, 將通訊層數據傳輸到服務器后, 可根據分級權限查看相應內容, 對電梯進行管理維護, 同時還可以針對報警或預警做出相應處理.

2 電梯安全運行監管系統通信層實現

2.1 傳感器數據采集服務器與感知層的交互

2.1.1 連接方式的選擇

目前常用的網絡通信連接方式有兩種: 短連接和長連接.

① 短連接是指每進行一次通信, 就建立一個連接, 數據傳輸結束連接關閉.

② 長連接則是在建立連接之后, 一直保持連接狀態, 數據一直通過該連接傳遞數據. 長連接可以省去較多建立和關閉連接的操作, 節約了大量的時間,適合操作較頻繁的情況.

安管系統要求監控必須是連續的, 不可間斷的,同時監控所得的數據也必須及時傳遞到服務器進行梳理, 故小區網關與傳感器數據采集服務器之間的連接采用長連接方式[16]. 連接握手示意圖如圖4. 網關向傳感器數據采集服務器發送連接請求, 傳感器數據采集服務器返回心跳響應, 網關再次向服務器發送確認信息, 連接成功. 之后網關可以在連接保持期間持續發送數據到服務器, 不需要再次連接.

圖4 連接握手示意圖

2.1.2 通信協議

系統傳輸中共有兩種協議包: 傳感器向服務器發送的預警報警通知包和服務器向傳感器發送的報警預警響應包.

(1) 通知包是傳感器向服務器發送的報警預警指令, 指令內容如圖5. 指令內容包括: 固定頭(每個通知包相同), 定長(每個通知包固定長度), 數據頭, 網關、電梯ZigBee地址, 保留字, 傳感器參數, 消息類型, 校驗位, 數據尾. 其中校驗方式采用奇偶校驗, 即從數據頭到數據尾, 包括數據頭和數據尾, 不包括檢驗位, 數據中“1”的個數是奇數還是偶數. 奇數時校驗位為“0”, 偶數時為“1”, 用以保證數據傳輸過程的準確性. 消息類型為是用來區分該信息是預警信息還是報警信息, 以選擇處理方式.

(2) 響應包是服務器向傳感器發送的應答指令,其指令內容如圖6. 指令內容包括: 固定頭、定長(消息長度)、機房和網關ZigBee地址、數據頭、消息模式(預警和報警)和數據尾. 傳感器接收消息的校驗依據為:固定長度, 校驗頭尾.

圖5 通知包數據內容

圖6 響應包數據內容

2.1.3 傳輸問題及其解決方法

傳輸過程中存在一些不可避免的問題需要注意,如黏包、拆包問題.

(1) 黏包: 黏包是指通信時由于某種原因, 導致兩個包同時傳入服務器接收緩沖區, 即兩個不同的包粘結在一起, 這種情況下需要對這兩個包按照某種規則進行分包處理.

(2) 拆包: 拆包是指傳輸過程中由于網速不穩定或者突然斷網, 導致某個包只有一部分傳遞到服務器接收緩沖區, 另一部分在重新建立連接后才傳遞過去,本來屬于一個包的數據被分成兩個包, 這種情況需要進行拼包處理.

針對上述問題, 系統給出如下分包算法[17]. 假設接收數據長度為M, 數據采集服務器會首先將數據轉換成自定義協議格式, 然后讀取信息固定頭部數據,判斷屬于那種信息, 然后獲取信息定長L, 并做如下比較:

(1) 若L=M, 則表明該數據為完整的數據包, 直接處理;

(2) 若L＜M, 則表明該數據發生黏包, 截取L長度進行處理, 后繼續按照該方式截取, 直至結束;

(3) 若L＞M, 則表明該數據發生拆包, 等待接收下一個數據包合并.

以上分包算法, 可以很好地解決黏包拆包現象,并正確進行數據處理.

2.2 傳感器數據采集服務器與城域監管云平臺交互

如上圖3所示, 傳感器數據采集服務器與云平臺之間的交互通過基于JMS的ActiveMQ消息隊列實現間接通信. 采集服務器、云平臺和ActiveMQ均位于外網, 通過網絡進行數據傳輸.

報警預警是安管系統需要實現的一個重要功能之一, 報警是電梯出現事故造成人員被困時, 系統及時向管理人員做出報警提示, 從而及時采取拯救措施的情況. 預警則是一種防范措施. 為了保證信息傳遞效率, 結合JMS通信協議, 對系統通信過程進行了優化,具體流程如圖7所示.

信息從底層電梯傳感器發出, 經傳輸層到達采集服務器(生產端), 然后進入ActiveMQ的消息隊列排隊,等候云平臺(消費端)處理. 消息從生產端到消費端的傳輸過程按照JMS協議進行通信, 為了保證通信效率,系統為消費端設置一個消息監聽器, 用來監測消息隊列內部消息是否到達.當有消息到達時監聽器的onMessage()方法會被調用, 讀取消息類型, 進行具體數據處理. 若消息類型為THREAD_PROCESS_TYPE,則繼續該線程, 若消息類型為SELF_PROCESS_TYPE,則表明監聽到的為報警預警消息, 優先處理. 若無消息到達則繼續檢測. 該方法提高了消費端的工作效率,使消息傳輸時間縮短至3秒左右.

圖7 報警預警模塊流程圖

2.3 城域監管云平臺與用戶層交互

云平臺與用戶層的交互包括主動推送模塊和實時請求模塊, 前者是指云平臺每隔固定間隔不斷向客戶端發送傳感器采集的電梯運行數據, 后者則指用戶層客戶端向云平臺發送查詢某個電梯運行狀況的實時請求. 限于篇幅, 本文僅介紹實時請求模塊, 實時請求模塊流程圖如圖8所示.

圖8 實時請求模塊流程圖

用戶通過頁面前端向云平臺發送訪問電梯運行數據實時請求, 云平臺作為消息生產端將消息傳送到ActiveMQ消息隊列中排隊, 等候消息消費端即傳感器數據采集服務器接收消息. 傳感器數據采集服務器接收到消息之后再通過傳輸層傳遞到小區網關, 小區網關根據具體指令調用某個電梯的傳感器數據響應. 實時請求過程需要保證傳遞數據包的順序性, 當同一時刻請求很多時, 為了避免消息混亂, 系統使用ActiveMQ提供的sendAndReceive流程進行處理, 通過建立臨時通道, 保證消息傳遞的有序進行[18]. 同樣,因為消息隊列的引入, 使得該流程信息傳輸效率得到改進, 效率提升至2-5秒.

3 結語

本文首先簡要介紹了電梯安管系統整體架構設計,然后重點闡述了一種新型的通信設計模型和實現方法.該通信模型使得傳感器數據采集服務器與網關和城域監管云平臺之間的通信更加有序、安全和高效. 據實踐統計, 該方法實現的電梯安管系統把常規的安管系統通信響應時間有效的縮短到10秒左右, 使得當發生報警預警狀況時, 能夠給電梯管理人員足夠的時間來及時采取補救措施, 具有重要的意義. 此外, 該系統還具有手機客戶端推送功能, 更加方便用戶及時查詢、更新數據. 但是, 目前該安管系統仍有一定的缺陷.比如針對注冊電梯所在區域出現大面積斷電, 或者服務器同時接收大量注冊包等大數據處理問題, 該通信模型還沒有足夠的能力來應對. 大數據處理問題是是整個系統面臨的考驗, 也是之后努力的重點.

1 祝尊震,蘇宇,張玉亮,等.基于物聯網技術的電梯安全管理系統.微型機與應用,2015,34(1):72–74.

2 程峰.電梯遠程監控技術及其發展.科技信息,2010,(18): 728–729.

3 葉安麗,李惠升.電梯遠程監控系統.北京建筑工程學院學報, 2000,16(4):42–47.

4 劉寶迅,周慧娟.電梯遠程監控系統研究進展.自動化儀表, 2014,35(3):12–16.

5 劉明.基于GPRS的電梯遠程監控系統研究[碩士學位論文].武漢:華中科技大學,2006.

6 Kalden R, Meirick I, Meyer M. Wireless Internet access based on GPRS. IEEE Personal Communications, 2000, 7(2): 8–18.

7 王勝賢,高天生.基于ZigBee和GPRS的電梯遠程監控系統的設計.測控技術,2016,35(3):149–151.

8 Happner M, Burridge R, Happner M, et al. Java message service specification. Sun Microsystems, 2002, (3-4): 79–195.

9 Snyder B, Bosnanac D, Davies R. ActiveMQ in action. Manning, 2011.

10 張燕,徐立新.ActiveMQ特性與配置研究.電腦編程技巧與維護,2011,(12):6–13.

11 Esposito C, Ficco M, Palmieri F, et al. Interconnecting federated clouds by using publish-subscribe service. Cluster Computing, 2013, 16(4): 1–17.

12 Kinney P. ZigBee Technology: Wireless control that simply works. Researchgate, 2003.

13 閆學勤,謝麗蓉,程志江,等.ZigBee+3G網絡在新型井道式電梯監控系統中的應用.自動化儀表,2015,36(1):1–4.

14 劉安厚.基于GPRS的電梯遠程監控系統[碩士學位論文].重慶:重慶大學,2009.

15 吳高峰,丁君輝,徐遠兵.基于JMS的分布式數據同步.計算機系統應用,2015,24(1):171–175.

16 沈曉.TCP 異步長連接的選擇及心跳處理機制的實現.中國金融電腦,2014,(4):37–39.

17 薛津,葉少珍.GPS車輛監控系統服務器性能優化與實現.微型機與應用,2013,(24):60–63.

18 王成良.基于JMS的分布式事務處理系統的研究與實現[碩士學位論文].鄭州:解放軍信息工程大學,2010.

Communication Module of Elevator Safety Supervision System Based on the Internet of Things

FENG Xue1, SUN Bing-Yu2, FANG Wei2, WU Bin31(School of Information Science and Technology, University of Science and Technology of China, Hefei 230026, China)2(Institute of Intelligent Machines, Chinese Academy of Sciences, Hefei 230031, China)3(Science and Technology Intelligent High Technology Co., Ltd., Hefei 230088, China)

Elevator safety supervision system is the system aiming at implementing all-weather operation monitoring, fault information recording, alarm-and-warn processing, maintenance management, and other functions of the elevators, using several independent sensors which collects the running data of the elevators uninterruptedly all-day, and then uploads these data to the operation monitoring platform of the elevators real-timely through wireless module. Focused on this issue of long response time of traditional elevator safety system, a new type of elevator security system based on the Internet of things is designed and implemented. In the system, a new high speed data transmission communication model is designed on the platform of management. This model interacts down with the underlying gateway by GPRS, and interacts up with the business layer by message queuing service of ActiveMQ based on JMS, greatly shortening the response time.

Internet of things; elevator safety supervision system; ZigBee; GPRS; ActiveMQ; message queue

國家創新基金(13C26213402619)

2016-07-28;收到修改稿時間:2016-09-20

10.15888/j.cnki.csa.005727