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

丁 遠(yuǎn)

（1.中煤科工集團(tuán)沈陽研究院有限公司，遼寧撫順 113122；2.煤礦安全技術(shù)國家重點(diǎn)實(shí)驗(yàn)室，遼寧撫順 113122）

工業(yè)互聯(lián)網(wǎng)[1]對數(shù)據(jù)扁平化要求較高，提倡信息端與生產(chǎn)現(xiàn)場協(xié)同制造。在煤礦安全監(jiān)控系統(tǒng)[2]中，1 個(gè)煤礦按照40 臺(tái)分站布局來計(jì)算，可安裝1 000～1 200 臺(tái)傳感器，每個(gè)傳感器節(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)端云平臺(tái)指令分析下發(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é)議看，各個(gè)協(xié)同廠家的通信協(xié)議均為自定義非標(biāo)協(xié)議，協(xié)議不統(tǒng)一的；從AQ 6201—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á)到180 MHz, 具有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)。

圖1 網(wǎng)關(guān)硬件圖Fig.1 Gateway hardware diagram

需要強(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。

圖2 軟件結(jié)構(gòu)圖Fig.2 Software diagram

協(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ù)存儲(chǔ)區(qū)，主控上傳模塊負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)緩存區(qū)的數(shù)據(jù)、狀態(tài)是否改變，如改變立即上傳，否則周期性上傳，上傳時(shí)先封裝JSON 格式后再上報(bào)MQTT 客戶端。驅(qū)動(dòng)讀寫模塊實(shí)現(xiàn)各個(gè)硬件操作，如RS485、4G 等。網(wǎng)口模塊比較繁瑣，不僅要操作內(nèi)部控制器還有移植第三方開源TCPIP 協(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ù)組成，每個(gè)任務(wù)之間有操作系統(tǒng)內(nèi)核完成調(diào)度，不用開發(fā)者再使用定時(shí)器模擬調(diào)度，減少了開發(fā)周期并且避免了不必要的錯(cuò)誤產(chǎn)生。

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

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

網(wǎng)關(guān)需要處理的數(shù)據(jù)很多，為了保證處理的實(shí)時(shí)性與正確性，需要考慮各個(gè)線程之間保證互不干擾和同一個(gè)內(nèi)存空間當(dāng)多個(gè)線程同時(shí)訪問時(shí)數(shù)據(jù)完整性與正確性。另外，為了實(shí)現(xiàn)網(wǎng)關(guān)的內(nèi)部系統(tǒng)資源與用戶數(shù)據(jù)的隔離，數(shù)據(jù)處理中的各個(gè)線程間通信的同步與互斥采用信號(hào)量和事件組實(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é)議可以分為適用于串行鏈路的Modbus RTU、Modbus ASCII，以及通過TCP/IP 傳輸?shù)腗odbus/TCP 等多種模式。為了方便在不同模式下的數(shù)據(jù)傳輸，Modbus 通信協(xié)議定義了1 個(gè)與基礎(chǔ)通信層無關(guān)的數(shù)據(jù)應(yīng)用單元在不同的傳輸模式下，只需要在其首位加上相應(yīng)的附加域，便可以正常的傳輸數(shù)據(jù)信息。Modbus TCP 通信協(xié)議[8]是建立在物理層為以太網(wǎng)，并且取消校驗(yàn)和與地址等信息的Modbus協(xié)議簇中的一種，采用主機(jī)主動(dòng)發(fā)送請求指令查詢從設(shè)備，從設(shè)備被動(dòng)應(yīng)答的一主多從的通訊模式。Modbus TCP 協(xié)議為了實(shí)現(xiàn)相同IP 段的多個(gè)獨(dú)立終端同時(shí)工作時(shí)的不沖突，協(xié)議頭由4 個(gè)域（7 個(gè)字節(jié)）組成（簡稱為MBAP）。

另外當(dāng)網(wǎng)關(guān)故障時(shí)，新接入的網(wǎng)關(guān)能否無縫鏈接，不需要重新進(jìn)行配置，本設(shè)計(jì)采用STM32F429芯片內(nèi)置全球唯一ID 碼可以做標(biāo)識(shí)識(shí)別主鍵，當(dāng)設(shè)備更換時(shí)，云端服務(wù)器可以導(dǎo)入歷史配置，靈活可擴(kuò)展。工業(yè)互聯(lián)網(wǎng)為了有效地管理和監(jiān)控各個(gè)節(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.2 MQTT 通信

針對煤礦監(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é)議。它是一個(gè)開源、可靠的網(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 個(gè)只有2 個(gè)字節(jié)的固定報(bào)頭，有些消息會(huì)攜帶1 個(gè)可變報(bào)頭或有效載荷，為了實(shí)現(xiàn)在相同數(shù)據(jù)量條件下流量消耗最小，MQTT 基于二進(jìn)制形式實(shí)現(xiàn)的。MQTT 協(xié)議報(bào)頭見表1。

表1 MQTT 協(xié)議頭Table 1 MQTT protocol header

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 個(gè)等級：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)用里手動(dòng)對消息進(jìn)行去重設(shè)置，芯片的唯一ID 是網(wǎng)關(guān)與工業(yè)互聯(lián)網(wǎng)之間的通信主鍵，當(dāng)收到新消息的時(shí)候，通過消息的ID 來判斷是否是重復(fù)的消息，如果重復(fù)丟棄，否則更新消息ID 并存儲(chǔ)數(shù)據(jù)包。這樣做就可以保證消息的可靠性和準(zhǔn)確性的同時(shí)不會(huì)出現(xiàn)重復(fù)的問題，該算法適用于在使用MQTT 時(shí)需要保證數(shù)據(jù)的準(zhǔn)確性的同時(shí)又要兼顧傳輸速度的情況，在應(yīng)用程序客戶端進(jìn)行去重處理，就減少了對數(shù)據(jù)傳輸速度的影響。為了實(shí)現(xiàn)準(zhǔn)確高效的訂閱，每個(gè)客戶端可設(shè)定不同主題進(jìn)行消息過濾，當(dāng)網(wǎng)關(guān)接收到帶有確定的發(fā)布消息服務(wù)質(zhì)量等級的發(fā)布消息后，主動(dòng)將消息發(fā)送到消息代理服務(wù)器，消息代理服務(wù)器收到消息后按照內(nèi)部的消息隊(duì)列排列次序發(fā)送主題消息。

3 仿真試驗(yàn)

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

4 結(jié) 語

以工業(yè)互聯(lián)網(wǎng)二級子節(jié)點(diǎn)系統(tǒng)為平臺(tái)，煤礦監(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)平臺(tái)的問題，通過采用QoS1 服務(wù)質(zhì)量解決了數(shù)據(jù)傳輸過程中存在的丟包問題，通過設(shè)計(jì)去重算法解決了QoS1 重復(fù)包的問題，仿真測試結(jié)果表明此方法在數(shù)據(jù)傳輸壓力測試過程中沒有出現(xiàn)丟幀情況，并且延時(shí)造成的影響在AQ 6201—2019 標(biāo)準(zhǔn)要求的巡檢周期以及異控時(shí)間范圍內(nèi)，滿足傳輸效率要求達(dá)到設(shè)計(jì)的預(yù)期效果。