煤礦設備狀態監測系統設計

曹現剛， 段欣宇， 張夢園， 雷卓， 李彥川

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

0 引言

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

1 系統架構

煤礦設備狀態監測系統采用傳統物聯網架構[9]，包括感知層、網絡層、應用層，如圖1所示。

圖1 煤礦設備狀態監測系統總體架構Fig.1 Overall framework of coal mine equipment condition monitoring system

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

網絡層負責數據統一接入和高并發傳輸，包括數據集成網關和網絡傳輸模型2個部分。

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

2 系統關鍵技術

2.1 數據集成網關

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

圖2 數據集成網關組成Fig.2 Composition of the data integration gateway

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

圖3 數據集成網關服務接口Fig.3 Data integration gateway service interface

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

圖4 傳感器網絡協議適配器Fig.4 Network protocol adapter

表1 自定義數據格式Table 1 Custom data format

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

圖5 數據推送過程Fig.5 Data push process

2.2 網絡傳輸模型

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

圖6 Java NIO網絡傳輸模型Fig.6 Java NIO network transmission model

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

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

圖7 Netty網絡傳輸模型Fig.7 Netty network transmission model

3 測試與結果分析

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

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

圖8 系統CPU使用率測試結果Fig.8 System CPU usage test results

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

圖9 系統平均響應時間測試結果Fig.9 System average response time test results

4 結語

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