面向化工車間環(huán)境的實(shí)時監(jiān)控系統(tǒng)設(shè)計(jì)

孫成富，李曉晨

（淮陰工學(xué)院，江蘇 淮安 223001）

0 引 言

化工車間作業(yè)屬于有限空間作業(yè)，由于環(huán)境特殊，容易出現(xiàn)各種危險?；ぼ囬g的事故與車間中溫濕度、可燃?xì)怏w濃度[1]以及電力數(shù)據(jù)[2]等指標(biāo)有著密切關(guān)系。為了避免化工生產(chǎn)過程中出現(xiàn)事故對人和財務(wù)造成損失，必須實(shí)時地對車間進(jìn)行監(jiān)控。對化工車間環(huán)境和電力系統(tǒng)數(shù)據(jù)進(jìn)行監(jiān)測的傳統(tǒng)方法主要是通過管理人員巡視進(jìn)行現(xiàn)場查看，但是人力檢測既不能實(shí)時地獲取化工車間的各項(xiàng)指標(biāo)，而且每次巡邏周期較長、效率低下，并不能及時發(fā)現(xiàn)化工車間存在的問題。本文針對復(fù)雜的化工車間環(huán)境，通過數(shù)據(jù)融合的監(jiān)控系統(tǒng)，實(shí)時采集環(huán)境數(shù)據(jù)和電力系統(tǒng)數(shù)據(jù)，并通過協(xié)議網(wǎng)關(guān)將基于不同協(xié)議的數(shù)據(jù)實(shí)時傳輸?shù)綍r序數(shù)據(jù)庫[3]。最后，采用Echarts實(shí)現(xiàn)了可視化的數(shù)據(jù)顯示系統(tǒng)，使管理者能夠?qū)崟r查看化工車間運(yùn)行狀態(tài)。

1 系統(tǒng)整體架構(gòu)設(shè)計(jì)

面向化工車間環(huán)境的實(shí)時監(jiān)控系統(tǒng)可以劃分為三層：（1）感知層，實(shí)時采集化工車間現(xiàn)場數(shù)據(jù)，并通過ZigBee和ModBus協(xié)議將數(shù)據(jù)發(fā)送到協(xié)議網(wǎng)關(guān)；（2）協(xié)議轉(zhuǎn)換層，獲取感知層采集的數(shù)據(jù)，并將感知層協(xié)議數(shù)據(jù)進(jìn)行重新組合，同時將數(shù)據(jù)通過MQTT協(xié)議傳輸?shù)椒?wù)器；（3）應(yīng)用層，通過MQTT代理服務(wù)器接收網(wǎng)關(guān)發(fā)來的數(shù)據(jù)，并保存到時序數(shù)據(jù)庫，以便進(jìn)行數(shù)據(jù)處理。系統(tǒng)結(jié)構(gòu)示意圖如圖1所示。

圖1 系統(tǒng)結(jié)構(gòu)

2 感知層設(shè)計(jì)

面對化工車間環(huán)境中獲取溫濕度以及煙感的位置較多，想要實(shí)現(xiàn)多點(diǎn)獲取數(shù)據(jù)時，有線系統(tǒng)的布線復(fù)雜、傳輸速率慢、實(shí)時性差。針對這些問題，本系統(tǒng)將多個ZigBee節(jié)點(diǎn)連入無線傳感器網(wǎng)絡(luò)，使得數(shù)據(jù)采集過程中擁有延時短、成本低、結(jié)構(gòu)靈活等特點(diǎn)。由于化工廠房對電氣設(shè)備和用電的要求高，需要對電壓和電流進(jìn)行監(jiān)測，所以采用ModBus協(xié)議的交流多功能通信模塊獲取電力數(shù)據(jù)。感知層節(jié)點(diǎn)主要有兩種類型：基于ZigBee協(xié)議的無線感知節(jié)點(diǎn)、基于ModBus協(xié)議的有線感知節(jié)點(diǎn)。

2.1 無線感知節(jié)點(diǎn)

ZigBee協(xié)議是物聯(lián)網(wǎng)感知層的協(xié)議之一，它具有近距離、低功耗、低復(fù)雜度、成本低以及自組織等特點(diǎn)[4]，其低功耗的特點(diǎn)可以使其在有限能源供應(yīng)的場合下工作更長的時間。技術(shù)人員通過ZigBee協(xié)議可以在廠房環(huán)境中設(shè)置多個節(jié)點(diǎn)，并將節(jié)點(diǎn)采集的數(shù)據(jù)實(shí)時傳輸?shù)骄W(wǎng)關(guān)設(shè)備。本設(shè)計(jì)中的ZigBee協(xié)調(diào)器節(jié)點(diǎn)與終端節(jié)點(diǎn)的硬件電路基本一致，ZigBee硬件電路的主控芯片選用了CC2530，是目前ZigBee應(yīng)用的主流微控制芯片。

圖2為協(xié)調(diào)器節(jié)點(diǎn)與終端節(jié)點(diǎn)。終端節(jié)點(diǎn)與溫濕度傳感器以及可燃?xì)怏w傳感器相連，協(xié)調(diào)器通過串口與網(wǎng)關(guān)控制器相連。

圖2 ZigBee協(xié)調(diào)器節(jié)點(diǎn)與終端節(jié)點(diǎn)

ZigBee網(wǎng)絡(luò)有三種拓?fù)湫问剑盒切巍⒋貥湫魏途W(wǎng)絡(luò)。網(wǎng)絡(luò)節(jié)點(diǎn)根據(jù)其功能分為終端節(jié)點(diǎn)、路由器節(jié)點(diǎn)和協(xié)調(diào)器節(jié)點(diǎn)。根據(jù)實(shí)際情況，本設(shè)計(jì)使用的是星形拓?fù)浣Y(jié)構(gòu)。在星形結(jié)構(gòu)中，多個終端只能連接到一個協(xié)調(diào)器，如果終端想要相互通信，必須要通過協(xié)調(diào)器節(jié)點(diǎn)，而協(xié)調(diào)器節(jié)點(diǎn)直接負(fù)責(zé)終端節(jié)點(diǎn)的數(shù)據(jù)轉(zhuǎn)發(fā)[5]。

2.2 有線感知節(jié)點(diǎn)

ModBus協(xié)議是MODICON公司開發(fā)的一種工業(yè)現(xiàn)場總線協(xié)議標(biāo)準(zhǔn)，是一種較為常見的有線通信協(xié)議，使用串口作為硬件接口。它采用命令答應(yīng)的通信方式，主機(jī)發(fā)出請求后，從機(jī)將給出應(yīng)答并返回相應(yīng)的數(shù)據(jù)或寄存器狀態(tài)信息。從機(jī)不能主動向主機(jī)發(fā)送數(shù)據(jù)。

ModBus RTU報文幀每8個字節(jié)含有兩個4 bit十六進(jìn)制的字符，因此具有較高的數(shù)據(jù)流密度。ModBus RTU沒有規(guī)定起始和結(jié)束標(biāo)志，需要至少3.5個字符的通信暫停和啟動間隔讀取下一幀。幀模式如圖3所示。

圖3 ModBus報文幀模式

下面是對各數(shù)據(jù)域的詳細(xì)解釋。地址碼：該字節(jié)表示用戶設(shè)置地址碼對應(yīng)的從設(shè)備將會接收主機(jī)發(fā)送的信息，主機(jī)發(fā)送的地址碼表示發(fā)送的從機(jī)地址，從機(jī)發(fā)送的地址碼表示返回的從機(jī)地址。功能碼：作為傳送的第二個字節(jié)，當(dāng)主機(jī)采集數(shù)據(jù)請求發(fā)送時，功能碼告訴從機(jī)要執(zhí)行的具體操作。數(shù)據(jù)區(qū)：根據(jù)不同的功能碼而不同。CRC碼是二字節(jié)的錯誤檢測碼。

本設(shè)計(jì)中網(wǎng)關(guān)平臺作為主機(jī)，發(fā)送格式為：

01 04 00 00 00 09 30 0C

從機(jī)為多功能通信模塊，收到主機(jī)發(fā)送的命令之后返回的數(shù)據(jù)為：

01 04 12 08 98 03 E8 00 00 00 1D 00 00 00 01 00 00 01 F4 00 32 78 F555

其中電壓為十六進(jìn)制的0x0898，換算為十進(jìn)制的2 200，表示220.0 V；電流為十六進(jìn)制數(shù)據(jù)0x000003E8，換算為十進(jìn)制1 000，表示為1.000 A。

3 協(xié)議轉(zhuǎn)換層設(shè)計(jì)

協(xié)議轉(zhuǎn)換層的主要作用是實(shí)現(xiàn)對底層設(shè)備的數(shù)據(jù)上傳、數(shù)據(jù)更新等應(yīng)用[6]。網(wǎng)關(guān)系統(tǒng)可以完成傳感設(shè)備數(shù)據(jù)快速存取，加快事件處理速度，減輕平臺壓力，實(shí)現(xiàn)網(wǎng)關(guān)對設(shè)備的管理。

3.1 協(xié)議轉(zhuǎn)換層硬件設(shè)計(jì)

網(wǎng)關(guān)硬件平臺由WiFi網(wǎng)卡與主處理器兩部分組成，WiFi網(wǎng)卡負(fù)責(zé)與服務(wù)器進(jìn)行無線通信，主處理器負(fù)責(zé)協(xié)議格式的處理和轉(zhuǎn)換。網(wǎng)關(guān)主控制器使用STM32MP157，該控制器集成Arm Cortex-A7和Cortex-M4兩種內(nèi)核的異構(gòu)架構(gòu)，既通過多核架構(gòu)提供高性能，還能兼顧低功耗的實(shí)時控制。為縮短研發(fā)周期，本系統(tǒng)采用華清遠(yuǎn)見公司的FS-MP1A，其主要硬件模塊包括4 GB eMMC、512 MB DDR3、4路USB HOST接口以及板載WiFi模組，完全滿足了網(wǎng)關(guān)對運(yùn)算、存儲等性能的需求。

3.2 協(xié)議轉(zhuǎn)換層軟件設(shè)計(jì)

協(xié)議轉(zhuǎn)換層軟件設(shè)計(jì)分為三個模塊，分別為串口通信模塊、事件處理模塊以及MQTT通信模塊，如圖4所示。

圖4 協(xié)議轉(zhuǎn)換層組成結(jié)構(gòu)

協(xié)議轉(zhuǎn)換層采用嵌入式Linux系統(tǒng)，該系統(tǒng)具有Linux操作系統(tǒng)強(qiáng)大的網(wǎng)絡(luò)功能，并且開發(fā)環(huán)境友好，能夠快速完成系統(tǒng)的部署[7]。首先，通過串口讀取傳感器設(shè)備所采集的各種類型的數(shù)據(jù)。串口設(shè)備也是一種文件，利用文件接口函數(shù)，實(shí)現(xiàn)數(shù)據(jù)從感知層到協(xié)議轉(zhuǎn)換層的傳輸。使用open（）函數(shù)獲得該串口設(shè)備的句柄，然后進(jìn)行配置。對于不同協(xié)議設(shè)備，串口設(shè)置的波特率也有所不同，在本實(shí)驗(yàn)中兩個串口的波特率均為9 600。完成串口運(yùn)行參數(shù)配置后，通過串口讀寫感知層發(fā)來的數(shù)據(jù)，使用協(xié)議解析模塊對化工車間現(xiàn)場數(shù)據(jù)進(jìn)行解析。

MQTT協(xié)議由IBM公司在1999年提出，又稱消息隊(duì)列遙測傳輸協(xié)議，它可以運(yùn)行在TCP協(xié)議之上，是基于發(fā)布/訂閱模式的即時通信協(xié)議。MQTT協(xié)議擁有輕量級的特點(diǎn)，用于帶寬較小、設(shè)備受限或者網(wǎng)絡(luò)不穩(wěn)定的物聯(lián)網(wǎng)網(wǎng)絡(luò)中[8]。

采取MQTT異步訪問模式，首先通過MQTTAsync_create 函數(shù)創(chuàng)建句柄，用MQTTAsync_setCallbacks 函數(shù)設(shè)置MQTT通信過程中對相應(yīng)事件進(jìn)行響應(yīng)的回調(diào)函數(shù)。如若連接失敗，執(zhí)行回調(diào)函數(shù)connlost（）；若成功，則執(zhí)行回調(diào)函數(shù)messageArrived（）。MQTTAsync_connect（）函數(shù)與MQTT服務(wù)器連接，連接完成后進(jìn)行數(shù)據(jù)處理。用MQTT_sendMessage（）將MQTT消息發(fā)送到服務(wù)器，讓訂閱者獲取相關(guān)消息。最后執(zhí)行MQTTAsync_destroy函數(shù)銷毀句柄，斷開與服務(wù)器的連接。由于MQTT協(xié)議只實(shí)現(xiàn)了傳送消息的格式，并沒有限制用戶數(shù)據(jù)的格式。在本系統(tǒng)實(shí)現(xiàn)中，在MQTT協(xié)議之上通過JSON對協(xié)議數(shù)據(jù)進(jìn)行管理。

4 服務(wù)器搭建與客戶端功能實(shí)現(xiàn)

4.1 服務(wù)器搭建

服務(wù)器平臺選用Linux操作系統(tǒng)，服務(wù)器平臺包括MQTT代理服務(wù)器和時序數(shù)據(jù)庫。其中MQTT代理服務(wù)器作為消息中間件轉(zhuǎn)發(fā)消息。MQTT消息服務(wù)器選擇EMQX代理服務(wù)器，EMQX服務(wù)器是一款高可用的分布式MQTT消息服務(wù)器軟件，其支持最新的MQTT5協(xié)議規(guī)范，并向下兼容。EMQX服務(wù)器支持集群和高并發(fā)技術(shù)，具有優(yōu)秀的并發(fā)處理能力以及通信支持能力[9]，能夠使設(shè)備之間的通信簡單化，所以非常適合物聯(lián)網(wǎng)的信息傳遞。時序數(shù)據(jù)庫TDengine部署于服務(wù)器的存儲空間中，用于保存監(jiān)控系統(tǒng)采集的歷史數(shù)據(jù)。EMQX服務(wù)器提供了規(guī)則引擎[5]功能，該功能可以結(jié)合開源時序數(shù)據(jù)庫TDengine的RESTful API完成數(shù)據(jù)的入庫。

4.2 后臺可視化實(shí)現(xiàn)

后臺可視化界面基于springboot框架進(jìn)行編寫，利用JAVA數(shù)據(jù)庫連接接口（JDBC），連接時序數(shù)據(jù)庫TDengine管理數(shù)據(jù)，最后使用Echarts框架實(shí)現(xiàn)數(shù)據(jù)的可視化。

當(dāng)后臺監(jiān)控系統(tǒng)啟動后，會讀取數(shù)據(jù)庫中的數(shù)據(jù)，然后每隔1 s刷新可視化界面。但頻繁加載整個頁面會增加用戶等待時間，影響用戶體驗(yàn)。由于Ajax技術(shù)可以使網(wǎng)頁在不重新加載整個頁面的前提下，有選擇性地更新部分內(nèi)容[10]。因此采用Ajax通過異步回調(diào)函數(shù)獲取數(shù)據(jù)，從而實(shí)現(xiàn)網(wǎng)頁的局部刷新，Web客戶端首先會向服務(wù)器發(fā)送異步請求，將獲取到的數(shù)據(jù)以JSON格式進(jìn)行傳輸，最后使用處理后的數(shù)據(jù)對Echarts圖表進(jìn)行初始化，異步刷新流程如圖5所示。如果無法請求到數(shù)據(jù)庫中的數(shù)據(jù)，就會執(zhí)行請求失敗函數(shù)，網(wǎng)頁會跳出提示框。

圖5 Ajax異步刷新流程

5 結(jié)果分析

首先組建好相應(yīng)的硬件模塊，如ZigBee終端和傳感器的連接、ZigBee協(xié)調(diào)器與網(wǎng)關(guān)的串口連接，以及將交流電通信模塊與網(wǎng)關(guān)串口相連等。在服務(wù)器端啟動EMQX服務(wù)器以及TDengine數(shù)據(jù)庫后，通過EMQX代理服務(wù)器所對應(yīng)的1883端口可查看MQTT消息是否發(fā)送成功。在客戶端的Web端輸入服務(wù)器的IP地址后可以實(shí)時查看相關(guān)信息。進(jìn)入系統(tǒng)后，可視化界面一共分為5個模塊，分別是電壓監(jiān)控模塊、電流監(jiān)控模塊、溫度監(jiān)控模塊、濕度監(jiān)控模塊和煙霧監(jiān)控模塊。

電壓監(jiān)控模塊如圖6所示，電壓表設(shè)計(jì)的縱坐標(biāo)為電壓測量范圍-300～300 V。如果在-250～250 V的區(qū)間范圍內(nèi)，則電壓正常，電壓數(shù)據(jù)顯示綠色的折線；如果在小于-250 V或者大于250 V的區(qū)間內(nèi)，則異常。電流監(jiān)控模塊圖表設(shè)計(jì)與電壓設(shè)計(jì)基本類似，電流測量范圍為-100～100 A，設(shè)定-63～63 A之間為正常電流范圍。

圖6 電壓監(jiān)控模塊

溫度監(jiān)控模塊圖表使用的是散點(diǎn)圖。溫度測量范圍為0～50 ℃，如果是在15～30 ℃的區(qū)間范圍內(nèi)，則溫度正常。當(dāng)溫度異常時，散點(diǎn)為紅色，顯示情況如圖7所示。濕度監(jiān)測數(shù)據(jù)圖表設(shè)計(jì)與溫度基本類似，濕度測量范圍為0%～80%，設(shè)定30%～60%之間為正常濕度范圍。

圖7 溫度監(jiān)控模塊

煙感監(jiān)控模塊圖表使用的是柱狀圖。如圖8所示，其中煙感測量范圍為0～70 obs/m，如果在20～45 obs/m的區(qū)間范圍內(nèi)，則煙感正常。如果超出范圍，為異常。

圖8 煙感監(jiān)控模塊

6 結(jié) 語

本文為了能夠?qū)崟r監(jiān)控化工車間各環(huán)境指標(biāo)，從而保證化工安全生產(chǎn)，設(shè)計(jì)了一個基于多協(xié)議網(wǎng)卡的化工車間實(shí)時監(jiān)控系統(tǒng)，將ZigBee協(xié)議和ModBus協(xié)議轉(zhuǎn)換為MQTT協(xié)議發(fā)送至服務(wù)器，同時對數(shù)據(jù)進(jìn)行持久化操作，并存入時序數(shù)據(jù)庫。同時設(shè)計(jì)了可視化界面實(shí)時異步調(diào)用數(shù)據(jù)，并動態(tài)顯示出來。本系統(tǒng)解決了物聯(lián)網(wǎng)在不同通信方式、不同的通信協(xié)議環(huán)境下的模塊對接問題，提高了化工車間環(huán)境數(shù)據(jù)監(jiān)測的效率。經(jīng)過測試，系統(tǒng)與服務(wù)器連接正常，系統(tǒng)運(yùn)行正常、穩(wěn)定。