基于增強設(shè)備協(xié)議的智能遠程監(jiān)測系統(tǒng)設(shè)計

陳麗，夏興隆，王莉莉，卜樹坡

(1.蘇州工業(yè)職業(yè)技術(shù)學院 電子與通信工程系，江蘇 蘇州 215000；2.蘇州易泰勒電子科技有限公司，江蘇 蘇州 215123； 3.東南大學 電子科學與工程學院，南京 210096)

0 引 言

新基建背景下，工業(yè)互聯(lián)網(wǎng)、大數(shù)據(jù)中心等基礎(chǔ)設(shè)施的大力建設(shè)，進一步加速了各行各業(yè)的數(shù)字化進程。借助云平臺在數(shù)據(jù)存儲、數(shù)據(jù)推送、命令下發(fā)等方面的優(yōu)勢，使信息遠程監(jiān)測、設(shè)備遠程控制等在工業(yè)、農(nóng)業(yè)等諸多領(lǐng)域得以實現(xiàn)[1-5]。

終端設(shè)備按照一定的應用層協(xié)議與云平臺實現(xiàn)信息交互，比較常用的協(xié)議包括HTTP、CoAP、MQTT等，每種協(xié)議具有不同的特點，應用領(lǐng)域不同[6-8]。HTTP協(xié)議是目前互聯(lián)網(wǎng)應用最多的應用層協(xié)議，采用TCP作為傳輸層協(xié)議，協(xié)議簡單、靈活；但是，這類協(xié)議較占資源，僅報文頭就至少需要占用幾十字節(jié)的資源。在M2M應用場景中，節(jié)點數(shù)量多、設(shè)備資源有限等特點決定了HTTP協(xié)議并不能很好地滿足應用需求[9]。CoAP和MQTT是針對終端設(shè)備資源受限這一特點專門設(shè)計的應用層協(xié)議，兩者協(xié)議包均較小，很大程度地節(jié)約了資源，在M2M場景中應用均較為廣泛[9-12]。CoAP協(xié)議基于RESTFul架構(gòu)[10-11]，其傳輸層采用較TCP更輕便、占用資源更少的UDP協(xié)議，消息格式為更緊湊的二進制格式，因此，CoAP協(xié)議的協(xié)議包遠小于HTTP；但是這類協(xié)議容易受到DDos攻擊，安全性和可靠性存在問題[13]。MQTT協(xié)議基于TCP傳輸層協(xié)議，采用發(fā)布/訂閱的模式進行信息傳輸，該協(xié)議提供三類QoS來保證消息傳輸質(zhì)量和傳輸效率[14]，但是，較低的QoS存在丟包率高的問題，較高的QoS需要消耗更多資源；這類協(xié)議通過訂閱的方式實現(xiàn)消息傳輸，不支持點對點通信；同時，不支持負載均衡，存在由于惡意攻擊、高并發(fā)引起的安全隱患。

為了滿足點對點設(shè)備間的通信，同時兼顧丟包率和安全因素，基于TCP傳輸層協(xié)議設(shè)計了增強設(shè)備協(xié)議，采用發(fā)送RAS加密消息的方式，增強安全性。與HTTP協(xié)議相比，增強設(shè)備協(xié)議減少了大量HTTP協(xié)議的復雜報文，更適合資源受限的M2M使用場景。

本文以水環(huán)境監(jiān)測為具體應用場景，采集溫度、溶氧量兩類信息，并基于增強設(shè)備協(xié)議實現(xiàn)終端設(shè)備采集信息上傳至云平臺、云平臺命令下發(fā)至終端設(shè)備、不同終端設(shè)備間數(shù)據(jù)推送三大類功能，采用BP神經(jīng)網(wǎng)絡對溶氧量及控制信號進行預測，最終實現(xiàn)復雜場景下的智能遠程監(jiān)測和控制。

1 設(shè)計方案

本系統(tǒng)主要由以下幾部分構(gòu)成：傳感器和信號傳輸電路組成的信號采集部分、GSM模塊組成的無線傳輸部分、STM32L系列的低功耗MCU控制部分、供電模塊。系統(tǒng)框圖如圖1所示。

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

1.1 信號傳輸電路

信號傳輸電路主要將傳感器信號準確地傳送至MCU，考慮到水環(huán)境監(jiān)測通常在水下進行，電磁波在水中快速衰減且干擾較大，通常采用有線的方式將傳感器采集到的數(shù)據(jù)傳送至MCU。常見的有線傳輸方式中，RS-485總線應用較多，與傳統(tǒng)RS-232相比，該方式允許在兩根傳輸線上連接多個設(shè)備，在需要采集多個信息、抗干擾能力要求高的應用場景中，具有較大的優(yōu)勢。針對RS-485接口的傳感器，需要采用相應的信號轉(zhuǎn)換芯片，文中的信號傳輸電路由RS-485芯片SIT3088E、光隔離模塊組成，如圖2所示。其中，RS-485芯片用于信號轉(zhuǎn)換，經(jīng)過光隔離模塊將信號送至MCU。當不需要進行信號采集時，MCU控制電源開關(guān)電路(圖3)關(guān)斷電路來降低功耗。

圖2 信號傳輸電路

圖3 電源開關(guān)電路

1.2 無線信號傳輸電路

終端采集的信號傳輸至云平臺，通常采用無線信號傳輸電路來實現(xiàn)?？紤]到戶外環(huán)境下運營商網(wǎng)絡覆蓋率高、物聯(lián)網(wǎng)單個節(jié)點數(shù)據(jù)量小等特點，本文選取了支持GSM/GPRS網(wǎng)絡的M6312芯片，該芯片工作溫度范圍可達-40 ℃～85 ℃，滿足苛刻應用環(huán)境要求。無線傳輸電路設(shè)計如圖4所示。

圖4 無線信號傳輸電路

2 增強設(shè)備協(xié)議

增強設(shè)備協(xié)議是基于OneNET平臺定義的一類針對物聯(lián)網(wǎng)應用特點的應用層協(xié)議，該協(xié)議規(guī)定了終端設(shè)備與云平臺建立連接、上傳數(shù)據(jù)、透傳數(shù)據(jù)等消息的組包規(guī)則，以最簡單的形式定義了數(shù)據(jù)交互的實現(xiàn)方式。

所有消息包含以下三部分：消息頭、可選項、消息體。消息頭由消息類型、保留位和剩余消息長度組成，其中消息類型占第一個字節(jié)的高四位；保留位占第一個字節(jié)的低四位，一般保留位全為零；剩余消息長度可以占用1-4字節(jié)，具體數(shù)值為可選項占用字節(jié)數(shù)與消息體占用字節(jié)數(shù)之和，根據(jù)計算結(jié)果決定剩余消息長度，具體對應關(guān)系如表1所示。

2.1 設(shè)備連接

終端設(shè)備與云平臺建立連接，必須發(fā)送滿足協(xié)議要求的連接請求。

連接請求的消息類型為1，考慮到消息類型在消息頭第1字節(jié)的高位，消息頭第1字節(jié)為0x10。

連接請求的可選項包括協(xié)議名稱、協(xié)議版本、連接標志、保持連接時間。協(xié)議名稱由5個字節(jié)組成，低三位為協(xié)議名稱“EDP”，高兩位表示協(xié)議名稱的長度3。協(xié)議版本占用1個字節(jié)，值為1。連接標志占用1個字節(jié)，通過最高位區(qū)分設(shè)備登錄的認證方式，當最高位為1時，采用產(chǎn)品ID和auth_info進行認證；當最高位為0時，采用設(shè)備ID和APIkey進行認證；保持連接時間占2個字節(jié)，以秒為單位。

消息體內(nèi)容與連接標志對應。當連接標志最高位為0時，消息體包含設(shè)備ID和APIkey兩項參數(shù)，每項參數(shù)由長度和參數(shù)值組成，組包時長度在前，具體參數(shù)值在后；當連接標志最高位為1時，消息體包含設(shè)備ID、產(chǎn)品ID和auth_info，其中設(shè)備ID直接設(shè)為兩字節(jié)0，后兩項參數(shù)同樣包含參數(shù)長度和參數(shù)值。

最后，根據(jù)可選項和消息體計算剩余消息長度，并合成消息頭。發(fā)送連接請求后，會收到平臺4個字節(jié)的連接響應，消息類型為2；第4個字節(jié)表示連接返回碼，0表示連接成功。

2.2 信息上傳

設(shè)備增強協(xié)議中，上傳數(shù)據(jù)消息類型為8。可選項包括標志、目標地址和消息編號。標志占用1個字節(jié)，最高位表示是否有目標地址，不存在目標地址時，值為0；次高位表示消息編號，用于區(qū)分不同消息。目標地址根據(jù)標志最高位值進行設(shè)置，該項不必需。消息編號占用2個字節(jié)。

消息體為具體上傳的數(shù)據(jù)。第一個字節(jié)表示數(shù)據(jù)類型，后兩個字節(jié)表示消息長度，后續(xù)為具體消息內(nèi)容。最后，根據(jù)可選項和消息體計算剩余消息長度。

2.3 命令下發(fā)

從云平臺向終端設(shè)備發(fā)送命令以實現(xiàn)遠程控制是云平臺重要應用之一。在這類應用中，設(shè)備增強協(xié)議規(guī)定了云平臺發(fā)送至設(shè)備端的消息模式，設(shè)備端接收到消息并按協(xié)議規(guī)則進行解析。下發(fā)命令的消息類型為10，剩余消息長度由后續(xù)內(nèi)容確定，占用1～4個字節(jié)。剩余消息由命令I(lǐng)D和命令消息體組成。對于每一條下發(fā)命令，系統(tǒng)均會分配一個命令I(lǐng)D，當需要響應時，需要在響應信息中，添加該ID進行針對性回復；命令I(lǐng)D又包含2個字節(jié)的命令I(lǐng)D長度和具體ID值，命令消息體則包含4個字節(jié)的命令消息體長度和不超過64K的命令消息體組成。

2.4 點對點數(shù)據(jù)透傳

點對點數(shù)據(jù)透傳將數(shù)據(jù)的解析下放至設(shè)備端，由終端設(shè)備自行定義數(shù)據(jù)的解析規(guī)則，可以通過點對點的定向數(shù)據(jù)交互實現(xiàn)更個性化、安全的應用設(shè)計。與上述功能不同，點對點數(shù)據(jù)透傳包含發(fā)送端和接收端兩部分。點對點數(shù)據(jù)透傳的消息類型為3。剩余消息長度由可選項和消息體的長度決定。可選項由目標地址長度和目標地址組成，其中地址長度占用2個字節(jié)，目標地址為設(shè)備ID。消息體為用戶自定義的不超過276字節(jié)的數(shù)據(jù)。

3 增強設(shè)備協(xié)議實現(xiàn)

增強設(shè)備協(xié)議每項具體功能的實現(xiàn)均包括按照協(xié)議規(guī)則進行數(shù)據(jù)組包或解包、設(shè)備端與云平臺實現(xiàn)無線數(shù)據(jù)傳輸兩部分。以下通過數(shù)據(jù)協(xié)議組包、解包和無線數(shù)據(jù)收發(fā)，介紹增強設(shè)備協(xié)議的實現(xiàn)方式。

3.1 無線數(shù)據(jù)傳輸

無線數(shù)據(jù)傳輸是雙向的，一般包括數(shù)據(jù)發(fā)送和數(shù)據(jù)接收。本文中，M6312是無線數(shù)據(jù)傳輸?shù)木唧w實現(xiàn)模塊，通過串口與MCU實現(xiàn)數(shù)據(jù)通信，接收到MCU的數(shù)據(jù)后，通過AT指令發(fā)送上傳數(shù)據(jù)：

//發(fā)送上傳數(shù)據(jù)AT指令

sprintf(cmdBuf, "AT+IPSEND=%d ", len);

當成功收到云平臺反饋后，通過如下代碼將信息上傳至云平臺：

//收到‘>’時可以上傳數(shù)據(jù)

if(!M6312_SendCmd(cmdBuf, ">"))

{

//發(fā)送設(shè)備連接請求數(shù)據(jù)

Usart_SendString(USART2, data, len);

}

其中，data和len是按照協(xié)議封裝后的協(xié)議包。

接收平臺發(fā)送的信息，則直接讀取M6312緩存內(nèi)的內(nèi)容，并進行分析。

3.2 信息發(fā)送及協(xié)議組包

增強設(shè)備協(xié)議可實現(xiàn)的功能中，發(fā)送連接請求、信息上傳、點對點數(shù)據(jù)透傳發(fā)送端的實現(xiàn)流程類似，如圖5所示。

圖5 信息發(fā)送流程圖

系統(tǒng)為數(shù)據(jù)分配內(nèi)存，按照增強設(shè)備協(xié)議的連接請求、信息上傳規(guī)則或點對點數(shù)據(jù)透傳規(guī)則進行協(xié)議組包，再通過M6312芯片將協(xié)議包上傳至云平臺，然后等待平臺響應。為了進一步簡化協(xié)議，平臺響應采用代碼來表示不同連接結(jié)果和信息上傳結(jié)果，點對點數(shù)據(jù)透傳則不設(shè)響應碼。終端設(shè)備接收到平臺響應代碼后，根據(jù)協(xié)議規(guī)定進行解析，并對應地打印連接結(jié)果。

3.3 信息接收及協(xié)議解包

設(shè)備增強協(xié)議中，接收信息類型包含云平臺下發(fā)的命令、終端設(shè)備透傳的信息等，解析流程類似，如圖6所示。

圖6 信息接收流程圖

M6312接收到信息后，通過判斷是否有關(guān)鍵字來明確是否收到平臺信息。各類信息的區(qū)分主要在于消息頭中的消息類型。接收到消息后，通過判斷消息類型進一步明確按照何種協(xié)議規(guī)則對接收到的信息進行解包。對于下發(fā)命令來說，解包過程主要提取命令I(lǐng)D和命令消息體；透傳信息則主要提取消息體。

4 協(xié)議性能測試

本文旨在設(shè)計基于增強設(shè)備協(xié)議的遠程智能監(jiān)測系統(tǒng)，協(xié)議包的大小是重要評估指標[9-12]。當發(fā)送相同信息的情況下，不同協(xié)議生成的協(xié)議包大小不同；協(xié)議復雜程度決定了通信芯片、MCU的選型；協(xié)議包越大，所需設(shè)備資源、網(wǎng)絡資源越多，同時，也會產(chǎn)生較多的資費。

以下，針對HTTP、EDP、MQTT三種協(xié)議，通過抓包工具分析上傳信息、命令下發(fā)對應的協(xié)議包大小。為了避免設(shè)備名稱、鑒權(quán)信息長度等對協(xié)議包大小的影響，本實驗涉及的設(shè)備名稱保持一致。

4.1 傳信息

圖7給出了上傳不同長度的信息時，不同協(xié)議所生成的協(xié)議包大小。

圖7 不同協(xié)議發(fā)送信息的協(xié)議包大小Fig.7 Packet size of messages sent by different protocols

從圖7中可以看出，HTTP協(xié)議的協(xié)議包遠大于EDP協(xié)議和MQTT協(xié)議，后兩種協(xié)議更適合物聯(lián)網(wǎng)場景的應用。

4.2 命令下發(fā)

三種協(xié)議中，HTTP協(xié)議采用請求/響應工作模式，服務器無法主動向客戶端發(fā)送消息，無法實現(xiàn)云平臺命令主動下發(fā)。以下比較增強設(shè)備協(xié)議和MQTT協(xié)議，對云平臺命令下發(fā)的數(shù)據(jù)包大小進行分析，結(jié)果如圖8所示。

圖8 不同協(xié)議接收云平臺命令的協(xié)議包大小

從圖8中可以看出，EDP協(xié)議的協(xié)議包小于MQTT的協(xié)議包大小。從資源占用角度來看，EDP和MQTT均較適合M2M的應用場景。但是，該平臺下發(fā)指令時，EDP可以在設(shè)定的時間范圍內(nèi)，接收離線消息，而MQTT協(xié)議無法接收離線消息。由于網(wǎng)絡信號等原因，丟包率高于EDP協(xié)議。

5 遠程監(jiān)控結(jié)果

整個系統(tǒng)設(shè)計完成后，可以通過網(wǎng)頁進行遠程監(jiān)控，實現(xiàn)信息上傳和云平臺命令下發(fā)；點對點數(shù)據(jù)透傳過程中，云平臺僅作為中轉(zhuǎn)站，信息監(jiān)控直接在設(shè)備端進行。

當系統(tǒng)工作時，可以遠程登錄云平臺實現(xiàn)信息查看和命令下發(fā)，圖9給出溶氧傳感器每隔兩小時上傳一個數(shù)據(jù)點的監(jiān)測結(jié)果。

圖9 溶氧量遠程監(jiān)測結(jié)果(mg/L)

溶氧量受光照強度、喂食等因素影響顯著，要滿足最優(yōu)的水環(huán)境指標，需要對溶氧量進行準確地調(diào)節(jié)[15]?？紤]到溶氧量的時變性、非線性、大時滯等特點[16]，基于Tensorflow搭建BP神經(jīng)網(wǎng)絡對溶氧量進行預測，BP神經(jīng)網(wǎng)絡結(jié)構(gòu)如圖10所示，主要包括三層：輸入層、中間層和輸出層，每一層都包含若干個神經(jīng)元，圖中圓形表示一個神經(jīng)元；每個神經(jīng)元包含若干個輸入信號和一個輸出信號，每個輸入對應一個權(quán)重，輸入和權(quán)重相乘，然后相加，結(jié)果經(jīng)過sigmoid函數(shù)后輸出。本文將監(jiān)測到的上一時刻的溶氧量和溫度作為輸入，當前時刻的溶氧量和溶解氧控制信號作為輸出，進行訓練。

圖10 BP神經(jīng)網(wǎng)絡結(jié)構(gòu)圖

考慮到MCU的運算能力較弱，訓練過程在計算機上進行，再通過Cube.AI將訓練好的模型轉(zhuǎn)換成庫文件，直接在STM32 MCU上運行，根據(jù)監(jiān)測到的參數(shù)信息，預測溶氧量和溶解氧的控制信號。

圖11給出云平臺下發(fā)命令至智能終端的頁面，下發(fā)格式包含字符串和16進制。QoS級別有需要響應和不需要響應兩類。在設(shè)定的失效時間范圍內(nèi)，設(shè)備上線即可收到云平臺下發(fā)的命令。

圖11 云平臺命令下發(fā)

遠程監(jiān)控可以訪問固定網(wǎng)址實現(xiàn)，監(jiān)控界面如圖12所示。該界面可以查看溫度和溶氧兩個傳感器采集的信息。溫度為一段時間范圍內(nèi)的值，溶氧量為實時監(jiān)測結(jié)果；還可以通過按鍵直接控制系統(tǒng)執(zhí)行器的外部供電，實現(xiàn)遠程控制。

圖12 遠程監(jiān)控界面

6 結(jié)束語

文章采用低功耗MCU、RS-485接口傳感器、信號傳輸電路、GSM無線傳輸電路設(shè)計了智能終端硬件系統(tǒng)。該系統(tǒng)通過增強設(shè)備協(xié)議與云平臺實現(xiàn)信息交互，并通過網(wǎng)頁實現(xiàn)遠程監(jiān)測和控制。設(shè)備端采用BP神經(jīng)網(wǎng)絡對溶氧量及控制信號進行預測，實現(xiàn)智能控制。

通過對不同協(xié)議的協(xié)議包大小進行對比，結(jié)果表明增強設(shè)備協(xié)議的協(xié)議包較小，對資源要求低；且支持離線消息；在支持信息上傳、云平臺命令下發(fā)的同時，還支持點對點信息透傳，適合資源受限的M2M應用場景。后期將對終端硬件平臺與云平臺信息交互過程中，涉及的信息安全進行深入研究，使系統(tǒng)更完善，更好地滿足實際應用需求。