煤礦監(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é)點系統(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è)計并開發(fā)了一種分布式計算網(wǎng)關(guān)，此網(wǎng)關(guān)應(yīng)用在監(jiān)控系統(tǒng)交換機與工業(yè)互聯(lián)網(wǎng)連接端，對交換機下屬的監(jiān)控分站發(fā)來的數(shù)據(jù)進行解析處理后封裝JSON格式，通過MQTT協(xié)議傳入工業(yè)互聯(lián)網(wǎng)云端軟件。實際應(yīng)用表明：該方案架構(gòu)設(shè)計合理，穩(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臺分站布局來計算，可安裝1000～1200臺傳感器，每個傳感器節(jié)點在不停的更新數(shù)據(jù)。由于傳感器完全分散，如果完全采用云計算[3]方式不對數(shù)據(jù)進行分布式采集處理，隨著傳感器不斷增加時，當前網(wǎng)絡(luò)逐漸臃腫，傳輸效率與信息安全均得不到有效保障，大量的數(shù)據(jù)給數(shù)據(jù)庫存取技術(shù)以及數(shù)據(jù)查詢帶來挑戰(zhàn)；另外由于工業(yè)互聯(lián)網(wǎng)二級節(jié)點系統(tǒng)軟件與煤礦監(jiān)控系統(tǒng)在上層協(xié)議、格式一般是不同的，所以煤礦監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)還需要在監(jiān)控系統(tǒng)的交換機端在進入工業(yè)互聯(lián)網(wǎng)時進行格式封裝與協(xié)議轉(zhuǎn)換；另一方面，對于一些實時性要求高的工業(yè)現(xiàn)場，云計算過度依賴服務(wù)器，一旦出現(xiàn)宕機、網(wǎng)絡(luò)異常等，都將造成不可以估計的損失。鑒于此，提出并設(shè)計了一種具備分布式計算能力且通用性強[4]的網(wǎng)關(guān)方案，協(xié)議層建立在由MQTT協(xié)議[5]構(gòu)建的完整消息分發(fā)系統(tǒng)，實現(xiàn)分布式計算、編譯部署的完整消息分發(fā)系統(tǒng)，可實現(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)換，對遠端云平臺指令分析下發(fā)以及對下行監(jiān)控分站數(shù)據(jù)計算與處理后上傳；二是接入工業(yè)互聯(lián)網(wǎng)二級子節(jié)點系統(tǒng)。從硬件通信接口來看，監(jiān)控分站對上層設(shè)計一般采用以太網(wǎng)、LONWORKS、CAN、485等總線；從軟件協(xié)議看，各個協(xié)同廠家的通信協(xié)議均為自定義非標協(xié)議，協(xié)議不統(tǒng)一的；從AQ6201—2019行業(yè)標準[6]來看，對數(shù)據(jù)處理時間，上層指令響應(yīng)速度均有嚴格要求。因此網(wǎng)關(guān)硬件架構(gòu)要圍繞多接口來設(shè)計，軟件架構(gòu)要圍繞“強實時性”以及協(xié)議統(tǒng)一設(shè)計。
1.1硬件體系結(jié)構(gòu)
根據(jù)需求分析確定硬件架構(gòu)設(shè)計需要融合多總線，網(wǎng)關(guān)硬件架構(gòu)圖如圖1，系統(tǒng)使用STM32F429RCT6作為主控芯片，該芯片主頻可達到180MHz,具有8路UART，1路以太網(wǎng)控制器，2路CAN總線控制器。主控芯片通過UART外掛4片MAX3845芯片實現(xiàn)4路RS485總線通信，2路CAN總線通過內(nèi)置CAN1、CAN2控制器外加2片CTM1051收發(fā)器實現(xiàn)，以太網(wǎng)接口通過內(nèi)置以太網(wǎng)控制器加外置DP83848C網(wǎng)卡實現(xiàn)，WIFI、4G、5G等模塊通過UART加相應(yīng)通信模塊實現(xiàn)。需要強調(diào)下，因為目前大部分模塊，設(shè)備中RS485、LONWORKS、LIN總線、WIFI、4G等，廠家為了兼容性以及使用方便性考慮，往往設(shè)計成UART接口，所以選擇主控芯片時，具備UART的數(shù)量往往是優(yōu)先考慮的。
1.2軟件體系結(jié)構(gòu)
網(wǎng)關(guān)軟件主要負責(zé)監(jiān)控系統(tǒng)與工業(yè)互聯(lián)網(wǎng)二級子節(jié)點系統(tǒng)之間的指令處理和數(shù)據(jù)轉(zhuǎn)發(fā)傳輸，是下行系統(tǒng)和遠端云服務(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ù)據(jù)存儲區(qū)，主控上傳模塊負責(zé)監(jiān)控數(shù)據(jù)緩存區(qū)的數(shù)據(jù)、狀態(tài)是否改變，如改變立即上傳，否則周期性上傳，上傳時先封裝JSON格式后再上報MQTT客戶端。驅(qū)動讀寫模塊實現(xiàn)各個硬件操作，如RS485、4G等。網(wǎng)口模塊比較繁瑣，不僅要操作內(nèi)部控制器還有移植第三方開源TCP\IP協(xié)議棧，如LwIP協(xié)議棧[7]。MQTT模塊構(gòu)建了發(fā)布/訂閱消息的轉(zhuǎn)發(fā)模型，實現(xiàn)不同的客戶端的即時通信。分布式計算模塊屬于軟件架構(gòu)中僅次于協(xié)議轉(zhuǎn)換的核心模塊，負責(zé)實現(xiàn)邊緣計算功能，不僅實時分析云端服務(wù)器發(fā)出的請求指令與對下行設(shè)備的控制指令，而且還需要計算處理上行數(shù)據(jù)后上報云服務(wù)器，連通監(jiān)控系統(tǒng)和工業(yè)互聯(lián)網(wǎng)。為了加強系統(tǒng)的實時性，網(wǎng)關(guān)使用FreeRtos嵌入式實時操作系統(tǒng)作為任務(wù)調(diào)度的總管。使用RTOS后，網(wǎng)關(guān)的應(yīng)用程序由一系列獨立的任務(wù)組成，每個任務(wù)之間有操作系統(tǒng)內(nèi)核完成調(diào)度，不用開發(fā)者再使用定時器模擬調(diào)度，減少了開發(fā)周期并且避免了不必要的錯誤產(chǎn)生。
2網(wǎng)關(guān)關(guān)鍵技術(shù)
2.1數(shù)據(jù)處理技術(shù)
網(wǎng)關(guān)需要處理的數(shù)據(jù)很多，為了保證處理的實時性與正確性，需要考慮各個線程之間保證互不干擾和同一個內(nèi)存空間當多個線程同時訪問時數(shù)據(jù)完整性與正確性。另外，為了實現(xiàn)網(wǎng)關(guān)的內(nèi)部系統(tǒng)資源與用戶數(shù)據(jù)的隔離，數(shù)據(jù)處理中的各個線程間通信的同步與互斥采用信號量和事件組實現(xiàn)，采用共享內(nèi)存實現(xiàn)不同任務(wù)間數(shù)據(jù)交互，提高了分布式計算的抗干擾性、增加了網(wǎng)關(guān)的可用性。另外新標準下，煤礦監(jiān)控系統(tǒng)交換機一般都是以太網(wǎng)傳輸，并且本方案中的網(wǎng)關(guān)設(shè)備具備TCP/IP的支持，網(wǎng)關(guān)可以與交換機進行通信，為了減少軟件修改加快應(yīng)用進度，網(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)，并且取消校驗和與地址等信息的Modbus協(xié)議簇中的一種，采用主機主動發(fā)送請求指令查詢從設(shè)備，從設(shè)備被動應(yīng)答的一主多從的通訊模式。ModbusTCP協(xié)議為了實現(xiàn)相同IP段的多個獨立終端同時工作時的不沖突，協(xié)議頭由4個域（7個字節(jié)）組成（簡稱為MBAP）。另外當網(wǎng)關(guān)故障時，新接入的網(wǎng)關(guān)能否無縫鏈接，不需要重新進行配置，本設(shè)計采用STM32F429芯片內(nèi)置全球唯一ID碼可以做標識識別主鍵，當設(shè)備更換時，云端服務(wù)器可以導(dǎo)入歷史配置，靈活可擴展。工業(yè)互聯(lián)網(wǎng)為了有效地管理和監(jiān)控各個節(jié)點的數(shù)據(jù)，通過將部分計算能力遷移到網(wǎng)關(guān)，網(wǎng)關(guān)分擔(dān)了繁重的計算任務(wù)，達到了提高工業(yè)互聯(lián)網(wǎng)對設(shè)備的管理能力，使系統(tǒng)具有有很高開放性，提高了效率。
2.2MQTT通信
針對煤礦監(jiān)控系統(tǒng)使用環(huán)境，為了達到對監(jiān)控系統(tǒng)井下現(xiàn)場設(shè)備數(shù)據(jù)采集與控制，采用了MQTT協(xié)議構(gòu)建了完整的消息轉(zhuǎn)發(fā)系統(tǒng)。MQTT協(xié)議是最初是由IBM于20世紀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ā)布圖題消息的實時性，MQTT使用TCP的長連接。MQTT屬于1對多消息，有3種身份：發(fā)布者、訂閱者以及消息代理。每一條MQTT命令消息都包含1個只有2個字節(jié)的固定報頭，有些消息會攜帶1個可變報頭或有效載荷，為了實現(xiàn)在相同數(shù)據(jù)量條件下流量消耗最小，MQTT基于二進制形式實現(xiàn)的。MQTT協(xié)議報頭見表1。Byte1用于表示MQTT消息的報文類型以及某些類型的控制標記，高4位（bit7~bit4）表示協(xié)議類型，總共可以表示16種協(xié)議類型，其中0000和1111是保留字段。首字節(jié)的低4位（bit3~bit0）用來表示某些報文類型的控制字段，實際上只有少數(shù)報文類型有控制位。剩余長度從Byte2開始，最長可達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è)計的網(wǎng)關(guān)為了保證效率以及準確性，選擇QoS1服務(wù)質(zhì)量等級。QoS1存在可能出現(xiàn)重復(fù)的問題，所以需要在應(yīng)用里手動對消息進行去重設(shè)置，芯片的唯一ID是網(wǎng)關(guān)與工業(yè)互聯(lián)網(wǎng)之間的通信主鍵，當收到新消息的時候，通過消息的ID來判斷是否是重復(fù)的消息，如果重復(fù)丟棄，否則更新消息ID并存儲數(shù)據(jù)包。這樣做就可以保證消息的可靠性和準確性的同時不會出現(xiàn)重復(fù)的問題，該算法適用于在使用MQTT時需要保證數(shù)據(jù)的準確性的同時又要兼顧傳輸速度的情況，在應(yīng)用程序客戶端進行去重處理，就減少了對數(shù)據(jù)傳輸速度的影響。為了實現(xiàn)準確高效的訂閱，每個客戶端可設(shè)定不同主題進行消息過濾，當網(wǎng)關(guān)接收到帶有確定的發(fā)布消息服務(wù)質(zhì)量等級的發(fā)布消息后，主動將消息發(fā)送到消息代理服務(wù)器，消息代理服務(wù)器收到消息后按照內(nèi)部的消息隊列排列次序發(fā)送主題消息。
3仿真試驗
試驗平臺采用中煤科工集團沈陽研究院KJ1177X監(jiān)控系統(tǒng)與工業(yè)互聯(lián)網(wǎng)二級子節(jié)點接入云平臺（目前處于調(diào)試階段沒有正式運行），準備2臺KJ1177X-F1監(jiān)控分站，1臺通過以太網(wǎng)與網(wǎng)關(guān)連接，1臺通過CAN總線與網(wǎng)關(guān)連接，在云端服務(wù)器打開WireShark軟件進行抓包測試延時與觀察數(shù)據(jù)，發(fā)布端每100ms發(fā)送1次數(shù)據(jù)，共進行100次試驗，延時結(jié)果取平均值范圍在12～16ms之間波動，符合AQ6201—2019標準巡檢周期以及異控斷電時間要求。另外，分別進行10、15、20、30kB數(shù)據(jù)負載測試，試驗結(jié)果可表明所在負載增加延時可控制在500ms以內(nèi)，由于監(jiān)控系統(tǒng)單次上傳數(shù)據(jù)不可能達到10KB量級，所以實時性達到AQ6201—2019標準要求。
4結(jié)語
以工業(yè)互聯(lián)網(wǎng)二級子節(jié)點系統(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è)計并開發(fā)了一種分布式計算網(wǎng)關(guān)，此網(wǎng)關(guān)應(yīng)用在監(jiān)控系統(tǒng)交換機與工業(yè)互聯(lián)網(wǎng)連接端，對交換機下屬的監(jiān)控分站發(fā)來的數(shù)據(jù)進行解析處理后封裝JSON格式，通過MQTT協(xié)議傳入工業(yè)互聯(lián)網(wǎng)云端軟件。該方案有效的解決了煤礦監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)平臺的問題，通過采用QoS1服務(wù)質(zhì)量解決了數(shù)據(jù)傳輸過程中存在的丟包問題，通過設(shè)計去重算法解決了QoS1重復(fù)包的問題，仿真測試結(jié)果表明此方法在數(shù)據(jù)傳輸壓力測試過程中沒有出現(xiàn)丟幀情況，并且延時造成的影響在AQ6201—2019標準要求的巡檢周期以及異控時間范圍內(nèi)，滿足傳輸效率要求達到設(shè)計的預(yù)期效果。
作者:丁遠 單位:中煤科工集團沈陽研究院有限公司 煤礦安全技術(shù)國家重點實驗室
