曹現(xiàn)剛， 段欣宇， 張夢園， 雷卓， 李彥川

(1.西安科技大學 機械工程學院， 陜西 西安 710054；2.陜西省礦山機電裝備智能檢測重點實驗室， 陜西 西安 710054)

0 引言

煤礦設備工作環(huán)境惡劣，連續(xù)作業(yè)時間長，對設備健康狀態(tài)要求苛刻。準確高效地獲取煤礦設備主要工作部件狀態(tài)信息，對設備故障診斷有重要意義[1-3]。汪杰等[4]基于B/S多層架構(gòu)設計了煤礦設備狀態(tài)監(jiān)測系統(tǒng)，實現(xiàn)了煤礦設備運行狀態(tài)實時顯示、歷史數(shù)據(jù)統(tǒng)計和查詢、故障報警等功能。張都[5]利用物聯(lián)網(wǎng)與BP神經(jīng)網(wǎng)絡建立了煤礦井下機電設備狀態(tài)監(jiān)測系統(tǒng)，實現(xiàn)了煤礦井下機電設備安全穩(wěn)定運行。魏昊然等[6]研制了以無線監(jiān)測裝置為數(shù)據(jù)傳輸紐帶的采煤機無線狀態(tài)監(jiān)測系統(tǒng)和基于LabVIEW的采煤機狀態(tài)監(jiān)測軟件平臺，實現(xiàn)了采煤機運行狀態(tài)的無線監(jiān)測及故障的診斷分析。甄智強[7]設計了一套以MCU(Microcontroller Unit)為核心的掘進設備遠程監(jiān)測系統(tǒng)，對掘進設備和運行環(huán)境的狀態(tài)進行監(jiān)測，并在設備發(fā)生故障時實現(xiàn)預警?，F(xiàn)有研究大多是針對單一設備進行監(jiān)測，對井下設備群同時作業(yè)時設備監(jiān)測數(shù)據(jù)高并發(fā)[8]導致傳輸效率低的問題缺乏考慮。本文提出一種煤礦設備狀態(tài)監(jiān)測系統(tǒng)。該系統(tǒng)通過數(shù)據(jù)集成網(wǎng)關(guān)有效消除傳感器網(wǎng)絡的異構(gòu)性；采用Netty網(wǎng)絡傳輸模型，避免空輪詢導致的服務器負載增加，提高系統(tǒng)的高并發(fā)處理能力和穩(wěn)定性。

1 系統(tǒng)架構(gòu)

煤礦設備狀態(tài)監(jiān)測系統(tǒng)采用傳統(tǒng)物聯(lián)網(wǎng)架構(gòu)[9]，包括感知層、網(wǎng)絡層、應用層，如圖1所示。

圖1 煤礦設備狀態(tài)監(jiān)測系統(tǒng)總體架構(gòu)Fig.1 Overall framework of coal mine equipment condition monitoring system

感知層負責底層數(shù)據(jù)采集，包括各種傳感器和無線采集模塊。在煤礦設備上安裝振動、電壓、電流、轉(zhuǎn)速和轉(zhuǎn)矩等傳感器采集設備狀態(tài)數(shù)據(jù)，并通過ZigBee模塊進行數(shù)據(jù)傳輸。通過紅外成像傳感器、溫度傳感器采集環(huán)境數(shù)據(jù)，并通過4G DTU模塊進行傳輸。

網(wǎng)絡層負責數(shù)據(jù)統(tǒng)一接入和高并發(fā)傳輸，包括數(shù)據(jù)集成網(wǎng)關(guān)和網(wǎng)絡傳輸模型2個部分。

應用層負責將采集的數(shù)據(jù)進行存儲及分析處理。采用標準化、中心化、歸一化等方法[10]對振動和噪聲等時序信號進行數(shù)據(jù)清洗，使偏態(tài)分布的序列呈對稱分布，消除序列中的異方差，將變量間的非線性關(guān)系轉(zhuǎn)換成線性關(guān)系，從而在數(shù)據(jù)量突增時改善計算精度。

2 系統(tǒng)關(guān)鍵技術(shù)

2.1 數(shù)據(jù)集成網(wǎng)關(guān)

數(shù)據(jù)集成網(wǎng)關(guān)包括傳感器網(wǎng)絡協(xié)議適配器、消息推送服務和數(shù)據(jù)傳輸服務3個模塊，如圖2所示。數(shù)據(jù)集成網(wǎng)關(guān)主要完成以下任務：① 實現(xiàn)對異構(gòu)傳感器網(wǎng)絡協(xié)議的適配工作；② 為數(shù)據(jù)傳輸提供統(tǒng)一格式和服務接口；③ 通過發(fā)布和訂閱模式實現(xiàn)上位機和服務器之間雙向通信，通過異步非阻塞模式提供有效的數(shù)據(jù)傳輸和安全認證。

圖2 數(shù)據(jù)集成網(wǎng)關(guān)組成Fig.2 Composition of the data integration gateway

在上位機部署數(shù)據(jù)集成網(wǎng)關(guān)服務接口，將不同傳感器在網(wǎng)關(guān)中進行注冊，選擇相應的網(wǎng)關(guān)編號、傳感器類型、數(shù)據(jù)協(xié)議等，如圖3所示。對傳輸控制協(xié)議(Transmission Control Protocol，TCP)、端口號等通信參數(shù)進行配置并啟動監(jiān)聽。

圖3 數(shù)據(jù)集成網(wǎng)關(guān)服務接口Fig.3 Data integration gateway service interface

傳感器網(wǎng)絡協(xié)議適配器可將不同傳感器網(wǎng)絡的數(shù)據(jù)統(tǒng)一接入服務器，如圖4所示。該傳感器網(wǎng)絡協(xié)議適配器集成了多種傳感器網(wǎng)絡(如ZigBee，WiFi，4G DTU等)協(xié)議的解析jar包，將各種協(xié)議的解析jar包封裝成各傳感器網(wǎng)絡協(xié)議解析接口，通過調(diào)用不同傳感器網(wǎng)絡協(xié)議解析接口來消除傳感器網(wǎng)絡的異構(gòu)性，生成統(tǒng)一格式的Java Script Object Notation(JSON)數(shù)據(jù)。數(shù)據(jù)格式見表1。

圖4 傳感器網(wǎng)絡協(xié)議適配器Fig.4 Network protocol adapter

表1 自定義數(shù)據(jù)格式Table 1 Custom data format

解析后的JSON數(shù)據(jù)推送過程如圖5所示。當有監(jiān)測數(shù)據(jù)接入時，消息推送服務將數(shù)據(jù)通過ActiveMQ消息隊列[11]中創(chuàng)建的Queue通道進行點對點傳輸，保證監(jiān)測數(shù)據(jù)的實時性和可靠性。數(shù)據(jù)傳輸服務實時監(jiān)聽Queue通道，當有消息到達時，將消息實時推送到網(wǎng)絡傳輸模型中，從而實現(xiàn)設備狀態(tài)數(shù)據(jù)的高并發(fā)傳輸。

圖5 數(shù)據(jù)推送過程Fig.5 Data push process

2.2 網(wǎng)絡傳輸模型

傳統(tǒng)獲取實時狀態(tài)數(shù)據(jù)的方式是通過Java Non-blocking I/O(NIO)網(wǎng)絡傳輸模型對上位機與服務器建立長輪詢來收發(fā)數(shù)據(jù)。Java NIO模型采用Reactor模式，對多路復用器(Selector)進行復用，使1個線程能對大量的Socket線程進行監(jiān)聽、連接、讀寫、輪詢等操作[12]，如圖6所示。如果井下大量設備同時作業(yè)，存在待機設備與服務器保持數(shù)據(jù)連接，可能出現(xiàn)Selector空輪詢現(xiàn)象[9]，導致服務器負載增加，使CPU始終處于高負載狀態(tài)。

圖6 Java NIO網(wǎng)絡傳輸模型Fig.6 Java NIO network transmission model

為有效避免空輪詢帶來的服務器負載增加問題，本文采用Netty作為網(wǎng)絡傳輸模型。Netty是在Java NIO的基礎上改進的，采用I/O多路復用技術(shù)，在單線程條件下處理多個I/O連接的請求[13]。在數(shù)據(jù)采集過程中，多個設備同時作業(yè)導致數(shù)據(jù)采樣頻率和傳感器終端的并發(fā)請求數(shù)量增加，Netty中的Epoll模式優(yōu)先處理已就緒的I/O連接，從而減少空輪詢現(xiàn)象[14]。

Netty網(wǎng)絡傳輸模型如圖7所示，Netty中1個EventLoopGroup(線程池)可以包含1個或多個EventLoop(線程)，1個EventLoop包含多個Channel(通道)。為了降低系統(tǒng)資源的使用率和減少線程的切換，在設計Netty網(wǎng)絡傳輸模型時選擇復用同一個EventLoopGroup，由于CPU處理速度遠大于網(wǎng)絡傳輸速度，所以1個EventLoopGroup就可以實現(xiàn)客戶端連接服務器的操作,從而提高模型效率。

圖7 Netty網(wǎng)絡傳輸模型Fig.7 Netty network transmission model

3 測試與結(jié)果分析

采用Apache JMeter工具進行煤礦設備狀態(tài)監(jiān)測系統(tǒng)性能測試，每秒向服務器發(fā)送1個長度為180 Byte的數(shù)據(jù)，即為1次并發(fā)請求。通過增加系統(tǒng)的并發(fā)請求次數(shù)，對比分別采用Java NIO模型和Netty模型的系統(tǒng)CPU使用率及系統(tǒng)平均響應時間。

系統(tǒng)CPU使用率測試結(jié)果如圖8所示。可看出同一時刻系統(tǒng)并發(fā)請求次數(shù)達到3 000時，采用Java NIO模型的系統(tǒng)CPU使用率比采用Netty模型的系統(tǒng)高28%。這是由于Java NIO模型連接時會定期進行輪詢，當有新消息返回時會響應消息并關(guān)閉連接，處理完后再重新發(fā)送新的請求，每次建立連接都會影響CPU性能；而Netty模型只需建立1次長連接，提高了系統(tǒng)效率。

圖8 系統(tǒng)CPU使用率測試結(jié)果Fig.8 System CPU usage test results

系統(tǒng)平均響應時間測試結(jié)果如圖9所示。可看出隨著系統(tǒng)并發(fā)請求次數(shù)增加，系統(tǒng)平均響應時間不斷增大；當系統(tǒng)并發(fā)請求次數(shù)大于1 400時，采用Java NIO模型的系統(tǒng)平均響應時間急劇增大，當并發(fā)請求次數(shù)達到3 000時，采用Java NIO模型的系統(tǒng)平均響應時間達1 230 ms；而采用Netty模型的系統(tǒng)平均響應時間較平穩(wěn)，始終在500 ms以下。

圖9 系統(tǒng)平均響應時間測試結(jié)果Fig.9 System average response time test results

4 結(jié)語

煤礦設備狀態(tài)監(jiān)測系統(tǒng)采用傳統(tǒng)物聯(lián)網(wǎng)架構(gòu)對數(shù)據(jù)進行采集、傳輸、存儲及分析。該系統(tǒng)在數(shù)據(jù)集成網(wǎng)關(guān)中對不同傳感器進行注冊，利用傳感器網(wǎng)絡協(xié)議適配器調(diào)用不同傳感器網(wǎng)絡協(xié)議解析接口生成統(tǒng)一格式的JSON數(shù)據(jù)，并將數(shù)據(jù)發(fā)送到對應的消息推送服務中，通過ActiveMQ消息隊列中的Queue通道進行點對點傳輸，數(shù)據(jù)傳輸服務將消息實時推送到網(wǎng)絡傳輸模型中，實現(xiàn)設備狀態(tài)數(shù)據(jù)的高并發(fā)傳輸，保證監(jiān)測數(shù)據(jù)傳輸實時性和可靠性；采用Netty網(wǎng)絡傳輸模型，避免空輪詢導致服務器負載增加，提高監(jiān)測數(shù)據(jù)傳輸效率。測試結(jié)果表明，隨著系統(tǒng)并發(fā)請求次數(shù)增加，采用Java NIO模型比采用Netty模型的系統(tǒng)CPU使用率高28%；在系統(tǒng)并發(fā)請求次數(shù)相同的情況下，采用Java NIO模型的系統(tǒng)平均響應時間大于采用Netty模型的系統(tǒng)。采用Netty模型能有效提升煤礦設備狀態(tài)監(jiān)測系統(tǒng)的高并發(fā)處理能力，滿足設備監(jiān)測數(shù)據(jù)高效傳輸要求。