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

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

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

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

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

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

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

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

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

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

1.1 感知層

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

圖1 網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖

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

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

每個(gè)電梯傳感器和網(wǎng)關(guān)都有唯一的4字節(jié)ZigBee編碼地址. 傳感器向網(wǎng)關(guān)發(fā)送注冊(cè)包, 得到網(wǎng)關(guān)的注冊(cè)成功確認(rèn)后, 兩者就可以進(jìn)行數(shù)據(jù)傳輸. 小區(qū)網(wǎng)關(guān)則向傳感器數(shù)據(jù)采集服務(wù)器發(fā)送注冊(cè)包, 服務(wù)器通過(guò)固定間隔不斷向網(wǎng)關(guān)發(fā)送7字節(jié)的心跳包, 確認(rèn)網(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)超過(guò)一定的時(shí)間沒(méi)有回應(yīng), 則服務(wù)器默認(rèn)網(wǎng)關(guān)掉線, 將其剔除. 網(wǎng)關(guān)則會(huì)在自動(dòng)上線之后重新向服務(wù)器發(fā)送注冊(cè)請(qǐng)求.

1.2 通信層

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

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

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

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

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

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

1.4 用戶層

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

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

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

2.1.1 連接方式的選擇

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

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

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

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

圖4 連接握手示意圖

2.1.2 通信協(xié)議

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

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

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

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

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

2.1.3 傳輸問(wèn)題及其解決方法

傳輸過(guò)程中存在一些不可避免的問(wèn)題需要注意,如黏包、拆包問(wèn)題.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖8 實(shí)時(shí)請(qǐng)求模塊流程圖

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

3 結(jié)語(yǔ)

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

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

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

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

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

5 劉明.基于GPRS的電梯遠(yuǎn)程監(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的電梯遠(yuǎn)程監(jiān)控系統(tǒng)的設(shè)計(jì).測(cè)控技術(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特性與配置研究.電腦編程技巧與維護(hù),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)用.自動(dòng)化儀表,2015,36(1):1–4.

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

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

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

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

18 王成良.基于JMS的分布式事務(wù)處理系統(tǒng)的研究與實(shí)現(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

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

2016-07-28;收到修改稿時(shí)間:2016-09-20

10.15888/j.cnki.csa.005727