前言:想要寫出一篇引人入勝的文章?我們特意為您整理了煤礦監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)設(shè)備研究范文,希望能給你帶來(lái)靈感和參考,敬請(qǐng)閱讀。
摘要:以工業(yè)互聯(lián)網(wǎng)二級(jí)子節(jié)點(diǎn)系統(tǒng)為平臺(tái),煤礦監(jiān)控系統(tǒng)為接入對(duì)象,分析了工業(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)連接端,對(duì)交換機(jī)下屬的監(jiān)控分站發(fā)來(lái)的數(shù)據(jù)進(jìn)行解析處理后封裝JSON格式,通過(guò)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]對(duì)數(shù)據(jù)扁平化要求較高,提倡信息端與生產(chǎn)現(xiàn)場(chǎng)協(xié)同制造。在煤礦安全監(jiān)控系統(tǒng)[2]中,1個(gè)煤礦按照40臺(tái)分站布局來(lái)計(jì)算,可安裝1000~1200臺(tái)傳感器,每個(gè)傳感器節(jié)點(diǎn)在不停的更新數(shù)據(jù)。由于傳感器完全分散,如果完全采用云計(jì)算[3]方式不對(duì)數(shù)據(jù)進(jìn)行分布式采集處理,隨著傳感器不斷增加時(shí),當(dāng)前網(wǎng)絡(luò)逐漸臃腫,傳輸效率與信息安全均得不到有效保障,大量的數(shù)據(jù)給數(shù)據(jù)庫(kù)存取技術(shù)以及數(shù)據(jù)查詢帶來(lái)挑戰(zhàn);另外由于工業(yè)互聯(lián)網(wǎng)二級(jí)節(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)換;另一方面,對(duì)于一些實(shí)時(shí)性要求高的工業(yè)現(xiàn)場(chǎng),云計(jì)算過(guò)度依賴服務(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)換,對(duì)遠(yuǎn)端云平臺(tái)指令分析下發(fā)以及對(duì)下行監(jiān)控分站數(shù)據(jù)計(jì)算與處理后上傳;二是接入工業(yè)互聯(lián)網(wǎng)二級(jí)子節(jié)點(diǎn)系統(tǒng)。從硬件通信接口來(lái)看,監(jiān)控分站對(duì)上層設(shè)計(jì)一般采用以太網(wǎng)、LONWORKS、CAN、485等總線;從軟件協(xié)議看,各個(gè)協(xié)同廠家的通信協(xié)議均為自定義非標(biāo)協(xié)議,協(xié)議不統(tǒng)一的;從AQ6201—2019行業(yè)標(biāo)準(zhǔn)[6]來(lái)看,對(duì)數(shù)據(jù)處理時(shí)間,上層指令響應(yīng)速度均有嚴(yán)格要求。因此網(wǎng)關(guān)硬件架構(gòu)要圍繞多接口來(lái)設(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總線控制器。主控芯片通過(guò)UART外掛4片MAX3845芯片實(shí)現(xiàn)4路RS485總線通信,2路CAN總線通過(guò)內(nèi)置CAN1、CAN2控制器外加2片CTM1051收發(fā)器實(shí)現(xiàn),以太網(wǎng)接口通過(guò)內(nèi)置以太網(wǎng)控制器加外置DP83848C網(wǎng)卡實(shí)現(xiàn),WIFI、4G、5G等模塊通過(guò)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)二級(jí)子節(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ù)存儲(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)部控制器還有移植第三方開源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ā)出的請(qǐng)求指令與對(duì)下行設(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í)訪問(wèn)時(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é)議可以分為適用于串行鏈路的Mod-busRTU、ModbusASCII,以及通過(guò)TCP/IP傳輸?shù)腗odbus/TCP等多種模式。為了方便在不同模式下的數(shù)據(jù)傳輸,Modbus通信協(xié)議定義了1個(gè)與基礎(chǔ)通信層無(wú)關(guān)的數(shù)據(jù)應(yīng)用單元在不同的傳輸模式下,只需要在其首位加上相應(yīng)的附加域,便可以正常的傳輸數(shù)據(jù)信息。ModbusTCP通信協(xié)議[8]是建立在物理層為以太網(wǎng),并且取消校驗(yàn)和與地址等信息的Modbus協(xié)議簇中的一種,采用主機(jī)主動(dòng)發(fā)送請(qǐng)求指令查詢從設(shè)備,從設(shè)備被動(dòng)應(yīng)答的一主多從的通訊模式。ModbusTCP協(xié)議為了實(shí)現(xiàn)相同IP段的多個(gè)獨(dú)立終端同時(shí)工作時(shí)的不沖突,協(xié)議頭由4個(gè)域(7個(gè)字節(jié))組成(簡(jiǎn)稱為MBAP)。另外當(dāng)網(wǎng)關(guān)故障時(shí),新接入的網(wǎng)關(guān)能否無(wú)縫鏈接,不需要重新進(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ù),通過(guò)將部分計(jì)算能力遷移到網(wǎng)關(guān),網(wǎng)關(guān)分擔(dān)了繁重的計(jì)算任務(wù),達(dá)到了提高工業(yè)互聯(lián)網(wǎng)對(duì)設(shè)備的管理能力,使系統(tǒng)具有有很高開放性,提高了效率。
2.2MQTT通信
針對(duì)煤礦監(jiān)控系統(tǒng)使用環(huán)境,為了達(dá)到對(duì)監(jiān)控系統(tǒng)井下現(xiàn)場(chǎng)設(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é)議,采用輕量級(jí)的發(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的長(zhǎng)連接。MQTT屬于1對(duì)多消息,有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。Byte1用于表示MQTT消息的報(bào)文類型以及某些類型的控制標(biāo)記,高4位(bit7~bit4)表示協(xié)議類型,總共可以表示16種協(xié)議類型,其中0000和1111是保留字段。首字節(jié)的低4位(bit3~bit0)用來(lái)表示某些報(bào)文類型的控制字段,實(shí)際上只有少數(shù)報(bào)文類型有控制位。剩余長(zhǎng)度從Byte2開始,最長(zhǎng)可達(dá)4字節(jié)。所以剩余長(zhǎng)度范圍是Byte2-Byte5。協(xié)議頭中的服務(wù)質(zhì)量字段決定了網(wǎng)關(guān)與工業(yè)互聯(lián)網(wǎng)之間的通信質(zhì)量。QoS[10]是發(fā)送者和接收者之間對(duì)于消息傳遞的可靠程度的協(xié)商,旨在協(xié)議層解決傳輸質(zhì)量問(wèn)題。QoS可根據(jù)分發(fā)次數(shù)分3個(gè)等級(jí):QoS0至多發(fā)送1次,QoS1至少分發(fā)1次,QoS2僅分發(fā)1次。設(shè)計(jì)的網(wǎng)關(guān)為了保證效率以及準(zhǔn)確性,選擇QoS1服務(wù)質(zhì)量等級(jí)。QoS1存在可能出現(xiàn)重復(fù)的問(wèn)題,所以需要在應(yīng)用里手動(dòng)對(duì)消息進(jìn)行去重設(shè)置,芯片的唯一ID是網(wǎng)關(guān)與工業(yè)互聯(lián)網(wǎng)之間的通信主鍵,當(dāng)收到新消息的時(shí)候,通過(guò)消息的ID來(lái)判斷是否是重復(fù)的消息,如果重復(fù)丟棄,否則更新消息ID并存儲(chǔ)數(shù)據(jù)包。這樣做就可以保證消息的可靠性和準(zhǔn)確性的同時(shí)不會(huì)出現(xiàn)重復(fù)的問(wèn)題,該算法適用于在使用MQTT時(shí)需要保證數(shù)據(jù)的準(zhǔn)確性的同時(shí)又要兼顧傳輸速度的情況,在應(yīng)用程序客戶端進(jìn)行去重處理,就減少了對(duì)數(shù)據(jù)傳輸速度的影響。為了實(shí)現(xiàn)準(zhǔn)確高效的訂閱,每個(gè)客戶端可設(shè)定不同主題進(jìn)行消息過(guò)濾,當(dāng)網(wǎng)關(guān)接收到帶有確定的發(fā)布消息服務(wù)質(zhì)量等級(jí)的發(fā)布消息后,主動(dòng)將消息發(fā)送到消息代理服務(wù)器,消息代理服務(wù)器收到消息后按照內(nèi)部的消息隊(duì)列排列次序發(fā)送主題消息。
3仿真試驗(yàn)
試驗(yàn)平臺(tái)采用中煤科工集團(tuán)沈陽(yáng)研究院KJ1177X監(jiān)控系統(tǒng)與工業(yè)互聯(lián)網(wǎng)二級(jí)子節(jié)點(diǎn)接入云平臺(tái)(目前處于調(diào)試階段沒有正式運(yùn)行),準(zhǔn)備2臺(tái)KJ1177X-F1監(jiān)控分站,1臺(tái)通過(guò)以太網(wǎng)與網(wǎng)關(guān)連接,1臺(tái)通過(guò)CAN總線與網(wǎng)關(guān)連接,在云端服務(wù)器打開WireShark軟件進(jìn)行抓包測(cè)試延時(shí)與觀察數(shù)據(jù),發(fā)布端每100ms發(fā)送1次數(shù)據(jù),共進(jìn)行100次試驗(yàn),延時(shí)結(jié)果取平均值范圍在12~16ms之間波動(dòng),符合AQ6201—2019標(biāo)準(zhǔn)巡檢周期以及異控?cái)嚯姇r(shí)間要求。另外,分別進(jìn)行10、15、20、30kB數(shù)據(jù)負(fù)載測(cè)試,試驗(yàn)結(jié)果可表明所在負(fù)載增加延時(shí)可控制在500ms以內(nèi),由于監(jiān)控系統(tǒng)單次上傳數(shù)據(jù)不可能達(dá)到10KB量級(jí),所以實(shí)時(shí)性達(dá)到AQ6201—2019標(biāo)準(zhǔn)要求。
4結(jié)語(yǔ)
以工業(yè)互聯(lián)網(wǎng)二級(jí)子節(jié)點(diǎn)系統(tǒng)為平臺(tái),煤礦監(jiān)控系統(tǒng)為接入對(duì)象,分析了工業(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)連接端,對(duì)交換機(jī)下屬的監(jiān)控分站發(fā)來(lái)的數(shù)據(jù)進(jìn)行解析處理后封裝JSON格式,通過(guò)MQTT協(xié)議傳入工業(yè)互聯(lián)網(wǎng)云端軟件。該方案有效的解決了煤礦監(jiān)控系統(tǒng)接入工業(yè)互聯(lián)網(wǎng)平臺(tái)的問(wèn)題,通過(guò)采用QoS1服務(wù)質(zhì)量解決了數(shù)據(jù)傳輸過(guò)程中存在的丟包問(wèn)題,通過(guò)設(shè)計(jì)去重算法解決了QoS1重復(fù)包的問(wèn)題,仿真測(cè)試結(jié)果表明此方法在數(shù)據(jù)傳輸壓力測(cè)試過(guò)程中沒有出現(xiàn)丟幀情況,并且延時(shí)造成的影響在AQ6201—2019標(biāo)準(zhǔn)要求的巡檢周期以及異控時(shí)間范圍內(nèi),滿足傳輸效率要求達(dá)到設(shè)計(jì)的預(yù)期效果。
作者:丁遠(yuǎn) 單位:中煤科工集團(tuán)沈陽(yáng)研究院有限公司 煤礦安全技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室
級(jí)別:部級(jí)期刊
榮譽(yù):中國(guó)優(yōu)秀期刊遴選數(shù)據(jù)庫(kù)
級(jí)別:部級(jí)期刊
榮譽(yù):中國(guó)期刊全文數(shù)據(jù)庫(kù)(CJFD)
級(jí)別:省級(jí)期刊
榮譽(yù):中國(guó)優(yōu)秀期刊遴選數(shù)據(jù)庫(kù)
級(jí)別:北大期刊
榮譽(yù):Caj-cd規(guī)范獲獎(jiǎng)期刊
級(jí)別:統(tǒng)計(jì)源期刊
榮譽(yù):Caj-cd規(guī)范獲獎(jiǎng)期刊