煤礦設(shè)備狀態(tài)監(jiān)測系統(tǒng)設(shè)計(jì)

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

(1.西安科技大學(xué) 機(jī)械工程學(xué)院， 陜西 西安 710054；2.陜西省礦山機(jī)電裝備智能檢測重點(diǎn)實(shí)驗(yàn)室， 陜西 西安 710054)

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)語

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