煤礦監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)設(shè)備研究

前言：想要寫出一篇引人入勝的文章？我們特意為您整理了煤礦監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)設(shè)備研究范文，希望能給你帶來靈感和參考，敬請閱讀。

摘要：以工業(yè)互聯(lián)網(wǎng)二級子節(jié)點(diǎn)系統(tǒng)為平臺，煤礦監(jiān)控系統(tǒng)為接入對象，分析了工業(yè)互聯(lián)網(wǎng)系統(tǒng)結(jié)構(gòu)以及監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)所需關(guān)鍵技術(shù)后，設(shè)計(jì)并開發(fā)了一種分布式計(jì)算網(wǎng)關(guān)，此網(wǎng)關(guān)應(yīng)用在監(jiān)控系統(tǒng)交換機(jī)與工業(yè)互聯(lián)網(wǎng)連接端，對交換機(jī)下屬的監(jiān)控分站發(fā)來的數(shù)據(jù)進(jìn)行解析處理后封裝JSON格式，通過MQTT協(xié)議傳入工業(yè)互聯(lián)網(wǎng)云端軟件。實(shí)際應(yīng)用表明：該方案架構(gòu)設(shè)計(jì)合理，穩(wěn)定性較好、性能較優(yōu)越，為監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)提供了一種可行方案。

關(guān)鍵詞：監(jiān)控系統(tǒng)；工業(yè)互聯(lián)網(wǎng)；JSON格式；MQTT協(xié)議；網(wǎng)關(guān)

工業(yè)互聯(lián)網(wǎng)[1]對數(shù)據(jù)扁平化要求較高，提倡信息端與生產(chǎn)現(xiàn)場協(xié)同制造。在煤礦安全監(jiān)控系統(tǒng)[2]中，1個煤礦按照40臺分站布局來計(jì)算，可安裝1000～1200臺傳感器，每個傳感器節(jié)點(diǎn)在不停的更新數(shù)據(jù)。由于傳感器完全分散，如果完全采用云計(jì)算[3]方式不對數(shù)據(jù)進(jìn)行分布式采集處理，隨著傳感器不斷增加時(shí)，當(dāng)前網(wǎng)絡(luò)逐漸臃腫，傳輸效率與信息安全均得不到有效保障，大量的數(shù)據(jù)給數(shù)據(jù)庫存取技術(shù)以及數(shù)據(jù)查詢帶來挑戰(zhàn)；另外由于工業(yè)互聯(lián)網(wǎng)二級節(jié)點(diǎn)系統(tǒng)軟件與煤礦監(jiān)控系統(tǒng)在上層協(xié)議、格式一般是不同的，所以煤礦監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)還需要在監(jiān)控系統(tǒng)的交換機(jī)端在進(jìn)入工業(yè)互聯(lián)網(wǎng)時(shí)進(jìn)行格式封裝與協(xié)議轉(zhuǎn)換；另一方面，對于一些實(shí)時(shí)性要求高的工業(yè)現(xiàn)場，云計(jì)算過度依賴服務(wù)器，一旦出現(xiàn)宕機(jī)、網(wǎng)絡(luò)異常等，都將造成不可以估計(jì)的損失。鑒于此，提出并設(shè)計(jì)了一種具備分布式計(jì)算能力且通用性強(qiáng)[4]的網(wǎng)關(guān)方案，協(xié)議層建立在由MQTT協(xié)議[5]構(gòu)建的完整消息分發(fā)系統(tǒng)，實(shí)現(xiàn)分布式計(jì)算、編譯部署的完整消息分發(fā)系統(tǒng)，可實(shí)現(xiàn)數(shù)據(jù)采集與分布以及煤礦監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)功能。

1網(wǎng)關(guān)總體架構(gòu)

網(wǎng)關(guān)具備2種功能：一是協(xié)議轉(zhuǎn)換，對遠(yuǎn)端云平臺指令分析下發(fā)以及對下行監(jiān)控分站數(shù)據(jù)計(jì)算與處理后上傳；二是接入工業(yè)互聯(lián)網(wǎng)二級子節(jié)點(diǎn)系統(tǒng)。從硬件通信接口來看，監(jiān)控分站對上層設(shè)計(jì)一般采用以太網(wǎng)、LONWORKS、CAN、485等總線；從軟件協(xié)議看，各個協(xié)同廠家的通信協(xié)議均為自定義非標(biāo)協(xié)議，協(xié)議不統(tǒng)一的；從AQ6201—2019行業(yè)標(biāo)準(zhǔn)[6]來看，對數(shù)據(jù)處理時(shí)間，上層指令響應(yīng)速度均有嚴(yán)格要求。因此網(wǎng)關(guān)硬件架構(gòu)要圍繞多接口來設(shè)計(jì)，軟件架構(gòu)要圍繞“強(qiáng)實(shí)時(shí)性”以及協(xié)議統(tǒng)一設(shè)計(jì)。

1.1硬件體系結(jié)構(gòu)

根據(jù)需求分析確定硬件架構(gòu)設(shè)計(jì)需要融合多總線，網(wǎng)關(guān)硬件架構(gòu)圖如圖1，系統(tǒng)使用STM32F429RCT6作為主控芯片，該芯片主頻可達(dá)到180MHz,具有8路UART，1路以太網(wǎng)控制器，2路CAN總線控制器。主控芯片通過UART外掛4片MAX3845芯片實(shí)現(xiàn)4路RS485總線通信，2路CAN總線通過內(nèi)置CAN1、CAN2控制器外加2片CTM1051收發(fā)器實(shí)現(xiàn)，以太網(wǎng)接口通過內(nèi)置以太網(wǎng)控制器加外置DP83848C網(wǎng)卡實(shí)現(xiàn)，WIFI、4G、5G等模塊通過UART加相應(yīng)通信模塊實(shí)現(xiàn)。需要強(qiáng)調(diào)下，因?yàn)槟壳按蟛糠帜K，設(shè)備中RS485、LONWORKS、LIN總線、WIFI、4G等，廠家為了兼容性以及使用方便性考慮，往往設(shè)計(jì)成UART接口，所以選擇主控芯片時(shí)，具備UART的數(shù)量往往是優(yōu)先考慮的。

1.2軟件體系結(jié)構(gòu)

網(wǎng)關(guān)軟件主要負(fù)責(zé)監(jiān)控系統(tǒng)與工業(yè)互聯(lián)網(wǎng)二級子節(jié)點(diǎn)系統(tǒng)之間的指令處理和數(shù)據(jù)轉(zhuǎn)發(fā)傳輸，是下行系統(tǒng)和遠(yuǎn)端云服務(wù)器之間的橋梁，軟件體系結(jié)構(gòu)如圖2。協(xié)議轉(zhuǎn)換模塊在網(wǎng)關(guān)的軟件結(jié)構(gòu)中起著承上啟下作用：可根據(jù)總線接口的不同自適應(yīng)加載相關(guān)通訊協(xié)議并且將下行系統(tǒng)上傳的數(shù)據(jù)、指令應(yīng)答等信息保存到臨時(shí)數(shù)據(jù)存儲區(qū)，主控上傳模塊負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)緩存區(qū)的數(shù)據(jù)、狀態(tài)是否改變，如改變立即上傳，否則周期性上傳，上傳時(shí)先封裝JSON格式后再上報(bào)MQTT客戶端。驅(qū)動讀寫模塊實(shí)現(xiàn)各個硬件操作，如RS485、4G等。網(wǎng)口模塊比較繁瑣，不僅要操作內(nèi)部控制器還有移植第三方開源TCP\IP協(xié)議棧，如LwIP協(xié)議棧[7]。MQTT模塊構(gòu)建了發(fā)布/訂閱消息的轉(zhuǎn)發(fā)模型，實(shí)現(xiàn)不同的客戶端的即時(shí)通信。分布式計(jì)算模塊屬于軟件架構(gòu)中僅次于協(xié)議轉(zhuǎn)換的核心模塊，負(fù)責(zé)實(shí)現(xiàn)邊緣計(jì)算功能，不僅實(shí)時(shí)分析云端服務(wù)器發(fā)出的請求指令與對下行設(shè)備的控制指令，而且還需要計(jì)算處理上行數(shù)據(jù)后上報(bào)云服務(wù)器，連通監(jiān)控系統(tǒng)和工業(yè)互聯(lián)網(wǎng)。為了加強(qiáng)系統(tǒng)的實(shí)時(shí)性，網(wǎng)關(guān)使用FreeRtos嵌入式實(shí)時(shí)操作系統(tǒng)作為任務(wù)調(diào)度的總管。使用RTOS后，網(wǎng)關(guān)的應(yīng)用程序由一系列獨(dú)立的任務(wù)組成，每個任務(wù)之間有操作系統(tǒng)內(nèi)核完成調(diào)度，不用開發(fā)者再使用定時(shí)器模擬調(diào)度，減少了開發(fā)周期并且避免了不必要的錯誤產(chǎn)生。

2網(wǎng)關(guān)關(guān)鍵技術(shù)

2.1數(shù)據(jù)處理技術(shù)

網(wǎng)關(guān)需要處理的數(shù)據(jù)很多，為了保證處理的實(shí)時(shí)性與正確性，需要考慮各個線程之間保證互不干擾和同一個內(nèi)存空間當(dāng)多個線程同時(shí)訪問時(shí)數(shù)據(jù)完整性與正確性。另外，為了實(shí)現(xiàn)網(wǎng)關(guān)的內(nèi)部系統(tǒng)資源與用戶數(shù)據(jù)的隔離，數(shù)據(jù)處理中的各個線程間通信的同步與互斥采用信號量和事件組實(shí)現(xiàn)，采用共享內(nèi)存實(shí)現(xiàn)不同任務(wù)間數(shù)據(jù)交互，提高了分布式計(jì)算的抗干擾性、增加了網(wǎng)關(guān)的可用性。另外新標(biāo)準(zhǔn)下，煤礦監(jiān)控系統(tǒng)交換機(jī)一般都是以太網(wǎng)傳輸，并且本方案中的網(wǎng)關(guān)設(shè)備具備TCP/IP的支持，網(wǎng)關(guān)可以與交換機(jī)進(jìn)行通信，為了減少軟件修改加快應(yīng)用進(jìn)度，網(wǎng)關(guān)采用Modbus協(xié)議，這樣下行系統(tǒng)只需少量修改便可直接應(yīng)用。根據(jù)傳輸數(shù)據(jù)的格式、物理接口等條件的不同，Modbus通信協(xié)議可以分為適用于串行鏈路的Mod－busRTU、ModbusASCII，以及通過TCP/IP傳輸?shù)腗odbus/TCP等多種模式。為了方便在不同模式下的數(shù)據(jù)傳輸，Modbus通信協(xié)議定義了1個與基礎(chǔ)通信層無關(guān)的數(shù)據(jù)應(yīng)用單元在不同的傳輸模式下，只需要在其首位加上相應(yīng)的附加域，便可以正常的傳輸數(shù)據(jù)信息。ModbusTCP通信協(xié)議[8]是建立在物理層為以太網(wǎng)，并且取消校驗(yàn)和與地址等信息的Modbus協(xié)議簇中的一種，采用主機(jī)主動發(fā)送請求指令查詢從設(shè)備，從設(shè)備被動應(yīng)答的一主多從的通訊模式。ModbusTCP協(xié)議為了實(shí)現(xiàn)相同IP段的多個獨(dú)立終端同時(shí)工作時(shí)的不沖突，協(xié)議頭由4個域（7個字節(jié)）組成（簡稱為MBAP）。另外當(dāng)網(wǎng)關(guān)故障時(shí)，新接入的網(wǎng)關(guān)能否無縫鏈接，不需要重新進(jìn)行配置，本設(shè)計(jì)采用STM32F429芯片內(nèi)置全球唯一ID碼可以做標(biāo)識識別主鍵，當(dāng)設(shè)備更換時(shí)，云端服務(wù)器可以導(dǎo)入歷史配置，靈活可擴(kuò)展。工業(yè)互聯(lián)網(wǎng)為了有效地管理和監(jiān)控各個節(jié)點(diǎn)的數(shù)據(jù)，通過將部分計(jì)算能力遷移到網(wǎng)關(guān)，網(wǎng)關(guān)分擔(dān)了繁重的計(jì)算任務(wù)，達(dá)到了提高工業(yè)互聯(lián)網(wǎng)對設(shè)備的管理能力，使系統(tǒng)具有有很高開放性，提高了效率。

2.2MQTT通信

針對煤礦監(jiān)控系統(tǒng)使用環(huán)境，為了達(dá)到對監(jiān)控系統(tǒng)井下現(xiàn)場設(shè)備數(shù)據(jù)采集與控制，采用了MQTT協(xié)議構(gòu)建了完整的消息轉(zhuǎn)發(fā)系統(tǒng)。MQTT協(xié)議是最初是由IBM于20世紀(jì)90年代主導(dǎo)開發(fā)的物聯(lián)網(wǎng)傳輸協(xié)議。它是一個開源、可靠的網(wǎng)絡(luò)傳輸協(xié)議，采用輕量級的發(fā)布／訂閱式消息[9]傳輸模式，可提供可靠的網(wǎng)絡(luò)服務(wù)給低帶寬和不穩(wěn)定的網(wǎng)絡(luò)環(huán)境中的物聯(lián)網(wǎng)設(shè)備。MQTT應(yīng)用于TCP/IP的應(yīng)用層，為了減少資源開銷以及保證訂閱/發(fā)布圖題消息的實(shí)時(shí)性，MQTT使用TCP的長連接。MQTT屬于1對多消息，有3種身份：發(fā)布者、訂閱者以及消息代理。每一條MQTT命令消息都包含1個只有2個字節(jié)的固定報(bào)頭，有些消息會攜帶1個可變報(bào)頭或有效載荷，為了實(shí)現(xiàn)在相同數(shù)據(jù)量條件下流量消耗最小，MQTT基于二進(jìn)制形式實(shí)現(xiàn)的。MQTT協(xié)議報(bào)頭見表1。Byte1用于表示MQTT消息的報(bào)文類型以及某些類型的控制標(biāo)記，高4位（bit7~bit4）表示協(xié)議類型，總共可以表示16種協(xié)議類型，其中0000和1111是保留字段。首字節(jié)的低4位（bit3~bit0）用來表示某些報(bào)文類型的控制字段，實(shí)際上只有少數(shù)報(bào)文類型有控制位。剩余長度從Byte2開始，最長可達(dá)4字節(jié)。所以剩余長度范圍是Byte2-Byte5。協(xié)議頭中的服務(wù)質(zhì)量字段決定了網(wǎng)關(guān)與工業(yè)互聯(lián)網(wǎng)之間的通信質(zhì)量。QoS[10]是發(fā)送者和接收者之間對于消息傳遞的可靠程度的協(xié)商，旨在協(xié)議層解決傳輸質(zhì)量問題。QoS可根據(jù)分發(fā)次數(shù)分3個等級：QoS0至多發(fā)送1次，QoS1至少分發(fā)1次，QoS2僅分發(fā)1次。設(shè)計(jì)的網(wǎng)關(guān)為了保證效率以及準(zhǔn)確性，選擇QoS1服務(wù)質(zhì)量等級。QoS1存在可能出現(xiàn)重復(fù)的問題，所以需要在應(yīng)用里手動對消息進(jìn)行去重設(shè)置，芯片的唯一ID是網(wǎng)關(guān)與工業(yè)互聯(lián)網(wǎng)之間的通信主鍵，當(dāng)收到新消息的時(shí)候，通過消息的ID來判斷是否是重復(fù)的消息，如果重復(fù)丟棄，否則更新消息ID并存儲數(shù)據(jù)包。這樣做就可以保證消息的可靠性和準(zhǔn)確性的同時(shí)不會出現(xiàn)重復(fù)的問題，該算法適用于在使用MQTT時(shí)需要保證數(shù)據(jù)的準(zhǔn)確性的同時(shí)又要兼顧傳輸速度的情況，在應(yīng)用程序客戶端進(jìn)行去重處理，就減少了對數(shù)據(jù)傳輸速度的影響。為了實(shí)現(xiàn)準(zhǔn)確高效的訂閱，每個客戶端可設(shè)定不同主題進(jìn)行消息過濾，當(dāng)網(wǎng)關(guān)接收到帶有確定的發(fā)布消息服務(wù)質(zhì)量等級的發(fā)布消息后，主動將消息發(fā)送到消息代理服務(wù)器，消息代理服務(wù)器收到消息后按照內(nèi)部的消息隊(duì)列排列次序發(fā)送主題消息。

3仿真試驗(yàn)

試驗(yàn)平臺采用中煤科工集團(tuán)沈陽研究院KJ1177X監(jiān)控系統(tǒng)與工業(yè)互聯(lián)網(wǎng)二級子節(jié)點(diǎn)接入云平臺（目前處于調(diào)試階段沒有正式運(yùn)行），準(zhǔn)備2臺KJ1177X-F1監(jiān)控分站，1臺通過以太網(wǎng)與網(wǎng)關(guān)連接，1臺通過CAN總線與網(wǎng)關(guān)連接，在云端服務(wù)器打開WireShark軟件進(jìn)行抓包測試延時(shí)與觀察數(shù)據(jù)，發(fā)布端每100ms發(fā)送1次數(shù)據(jù)，共進(jìn)行100次試驗(yàn)，延時(shí)結(jié)果取平均值范圍在12～16ms之間波動，符合AQ6201—2019標(biāo)準(zhǔn)巡檢周期以及異控?cái)嚯姇r(shí)間要求。另外，分別進(jìn)行10、15、20、30kB數(shù)據(jù)負(fù)載測試，試驗(yàn)結(jié)果可表明所在負(fù)載增加延時(shí)可控制在500ms以內(nèi)，由于監(jiān)控系統(tǒng)單次上傳數(shù)據(jù)不可能達(dá)到10KB量級，所以實(shí)時(shí)性達(dá)到AQ6201—2019標(biāo)準(zhǔn)要求。

4結(jié)語

以工業(yè)互聯(lián)網(wǎng)二級子節(jié)點(diǎn)系統(tǒng)為平臺，煤礦監(jiān)控系統(tǒng)為接入對象，分析了工業(yè)互聯(lián)網(wǎng)系統(tǒng)結(jié)構(gòu)以及煤礦監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)所需關(guān)鍵技術(shù)后，設(shè)計(jì)并開發(fā)了一種分布式計(jì)算網(wǎng)關(guān)，此網(wǎng)關(guān)應(yīng)用在監(jiān)控系統(tǒng)交換機(jī)與工業(yè)互聯(lián)網(wǎng)連接端，對交換機(jī)下屬的監(jiān)控分站發(fā)來的數(shù)據(jù)進(jìn)行解析處理后封裝JSON格式，通過MQTT協(xié)議傳入工業(yè)互聯(lián)網(wǎng)云端軟件。該方案有效的解決了煤礦監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)平臺的問題，通過采用QoS1服務(wù)質(zhì)量解決了數(shù)據(jù)傳輸過程中存在的丟包問題，通過設(shè)計(jì)去重算法解決了QoS1重復(fù)包的問題，仿真測試結(jié)果表明此方法在數(shù)據(jù)傳輸壓力測試過程中沒有出現(xiàn)丟幀情況，并且延時(shí)造成的影響在AQ6201—2019標(biāo)準(zhǔn)要求的巡檢周期以及異控時(shí)間范圍內(nèi)，滿足傳輸效率要求達(dá)到設(shè)計(jì)的預(yù)期效果。

作者:丁遠(yuǎn) 單位:中煤科工集團(tuán)沈陽研究院有限公司 煤礦安全技術(shù)國家重點(diǎn)實(shí)驗(yàn)室