基于物聯(lián)網(wǎng)的電梯安管系統(tǒng)通信模塊①

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

基于物聯(lián)網(wǎng)的電梯安管系統(tǒng)通信模塊①

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

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

物聯(lián)網(wǎng); 電梯安管系統(tǒng); ZigBee; GPRS; ActiveMQ; 消息隊列

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

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

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

1 電梯安管系統(tǒng)總體架構(gòu)設(shè)計

安管系統(tǒng)的網(wǎng)絡(luò)拓撲結(jié)構(gòu)圖如圖1所示. 系統(tǒng)網(wǎng)絡(luò)拓撲結(jié)構(gòu)可分為四部分: 感知層、通信層、數(shù)據(jù)處理層和用戶層.

1.1 感知層

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

圖1 網(wǎng)絡(luò)拓撲結(jié)構(gòu)圖

考慮到電梯運行的特點, 不方便采用電纜連接,故本系統(tǒng)采用無線網(wǎng)絡(luò)進行數(shù)據(jù)的傳遞, 通信標(biāo)準(zhǔn)采用目前流行的ZigBee技術(shù)[12,13]. 電梯內(nèi)部的傳感器實時監(jiān)測電梯的運行狀況, 得到運行參數(shù)后通過傳感器的ZigBee模塊把數(shù)據(jù)傳送到通信層. 感知層的結(jié)構(gòu)圖如圖2所示.

圖2 感知層結(jié)構(gòu)圖

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

1.2 通信層

通信層包括兩部分: 小區(qū)網(wǎng)關(guān)與傳感器數(shù)據(jù)采集服務(wù)器之間的通信、傳感器數(shù)據(jù)采集服務(wù)器與城域監(jiān)管云平臺(以下簡稱云平臺)之間的通信, 及云平臺與用戶層的通信. 通信層的結(jié)構(gòu)如圖3所示. 其中, 傳感器數(shù)據(jù)采集服務(wù)器、云平臺和ActiveMQ均獨立位于外網(wǎng), DB數(shù)據(jù)庫則位于小區(qū)內(nèi)部局域網(wǎng), 但對云平臺開放.

圖3 通信層結(jié)構(gòu)圖

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

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

1.3 數(shù)據(jù)處理層

數(shù)據(jù)處理層包括數(shù)據(jù)采集服務(wù)器和云平臺. 數(shù)據(jù)處理層和通信層包含的結(jié)構(gòu)類似, 但是與通信層的數(shù)據(jù)傳輸不同, 數(shù)據(jù)處理層所做的是數(shù)據(jù)采集服務(wù)器和云平臺內(nèi)部處理數(shù)據(jù)和請求的過程. 系統(tǒng)數(shù)據(jù)處理主要包括: 預(yù)警報警處理、實時請求處理等模塊.

1.4 用戶層

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

2 電梯安全運行監(jiān)管系統(tǒng)通信層實現(xiàn)

2.1 傳感器數(shù)據(jù)采集服務(wù)器與感知層的交互

2.1.1 連接方式的選擇

目前常用的網(wǎng)絡(luò)通信連接方式有兩種: 短連接和長連接.

① 短連接是指每進行一次通信, 就建立一個連接, 數(shù)據(jù)傳輸結(jié)束連接關(guān)閉.

② 長連接則是在建立連接之后, 一直保持連接狀態(tài), 數(shù)據(jù)一直通過該連接傳遞數(shù)據(jù). 長連接可以省去較多建立和關(guān)閉連接的操作, 節(jié)約了大量的時間,適合操作較頻繁的情況.

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

圖4 連接握手示意圖

2.1.2 通信協(xié)議

系統(tǒng)傳輸中共有兩種協(xié)議包: 傳感器向服務(wù)器發(fā)送的預(yù)警報警通知包和服務(wù)器向傳感器發(fā)送的報警預(yù)警響應(yīng)包.

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

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

圖5 通知包數(shù)據(jù)內(nèi)容

圖6 響應(yīng)包數(shù)據(jù)內(nèi)容

2.1.3 傳輸問題及其解決方法

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

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

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

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

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

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

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

以上分包算法, 可以很好地解決黏包拆包現(xiàn)象,并正確進行數(shù)據(jù)處理.

2.2 傳感器數(shù)據(jù)采集服務(wù)器與城域監(jiān)管云平臺交互

如上圖3所示, 傳感器數(shù)據(jù)采集服務(wù)器與云平臺之間的交互通過基于JMS的ActiveMQ消息隊列實現(xiàn)間接通信. 采集服務(wù)器、云平臺和ActiveMQ均位于外網(wǎng), 通過網(wǎng)絡(luò)進行數(shù)據(jù)傳輸.

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

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

圖7 報警預(yù)警模塊流程圖

2.3 城域監(jiān)管云平臺與用戶層交互

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

圖8 實時請求模塊流程圖

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

3 結(jié)語

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

1 祝尊震,蘇宇,張玉亮,等.基于物聯(lián)網(wǎng)技術(shù)的電梯安全管理系統(tǒng).微型機與應(yīng)用,2015,34(1):72–74.

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

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

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

5 劉明.基于GPRS的電梯遠程監(jiān)控系統(tǒng)研究[碩士學(xué)位論文].武漢:華中科技大學(xué),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的電梯遠程監(jiān)控系統(tǒng)的設(shè)計.測控技術(shù),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 閆學(xué)勤,謝麗蓉,程志江,等.ZigBee+3G網(wǎng)絡(luò)在新型井道式電梯監(jiān)控系統(tǒng)中的應(yīng)用.自動化儀表,2015,36(1):1–4.

14 劉安厚.基于GPRS的電梯遠程監(jiān)控系統(tǒng)[碩士學(xué)位論文].重慶:重慶大學(xué),2009.

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

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

17 薛津,葉少珍.GPS車輛監(jiān)控系統(tǒng)服務(wù)器性能優(yōu)化與實現(xiàn).微型機與應(yīng)用,2013,(24):60–63.

18 王成良.基于JMS的分布式事務(wù)處理系統(tǒng)的研究與實現(xiàn)[碩士學(xué)位論文].鄭州:解放軍信息工程大學(xué),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

國家創(chuàng)新基金(13C26213402619)

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

10.15888/j.cnki.csa.005727