今日頭條
官方微信
官方抖音
資訊頻道摘要：隨著云技術在邊緣側的逐步落地，邊云協同的應用場景與需求逐步增多，云和邊之間的協同包括資源協同、數據協同、應用管理協同、 業務管理協同、服務協同等。本文提出的基于MQTT技術的云邊協同協 議，主要為數據協同提供解決方案，可實現數據的雙向全雙工通信，同時保證傳輸的安全性。
關鍵詞：MQTT；OPC UA；云邊協同
Abstract: With the gradual implementation of cloud technology on the edge side, the application scenarios and demands of edge cloud collaboration are gradually increasing. The collaboration between edge and cloud includes resource collaboration, data collaboration, application management collaboration, business management collaboration, service collaboration, etc. The protocol of cloud and edge collaboration based on MQTT technology is proposed in this paper. It mainly provides a solution for data collaboration, which can realize two way full-duplex communication of data meanwhile ensure the security of transmission.
Key words: MQTT；OPC UA；Edge cloud synergy Design of Protocol for Cloud and Edge Collaboration Based on MQTT Technology
1 引言
當今工業領域，以云計算為主的ICT技術正在向邊緣側不斷滲透，云與邊雖然擔任的職責和適用的業務場 景有很大差別，但是它們之間已逐漸變得相互融合、不可分割，在不同層級有著不同層次的交互，云和邊之間的協同包括資源協同、數據協同、應用管理協同、業務管理協同、服務協同等[1]，如圖1所示。另外，隨著自動化軟件層級結構由垂直模式逐漸向水平模式演變，各設備和系統計算能力差異很大，尤其物聯網技術的融 入，更要求各系統間的通信能夠提供一種通用、輕量、 高效、安全的通信協議，為解決邊緣設備與云中心互聯問題，本文提出了以MQTT技術為基礎的實現方案，重點闡述協議層的設計原理。
圖1 云邊協同的應用場景
2 應用場景
隨著萬物互聯時代的到來，邊緣側設備呈爆炸性增長，以云技術構建起來的大數據中心為裝備的智能化提供支撐，如深度學習、大數據分析等，但是這些的本源是數據，如果邊緣側的過程數據如傳感器數據、配置數據、多媒體數據等無法接入云中心，那么智能化就無從談起，所以為打通設備與云的數據通道，必須提供一種廣泛適用的應用層協議。
在工業現場，目前涉及比較多的場景是傳遞四遙數據，此場景要求通信數據量大、數據連續、有一定的 實時性、保證數據安全。一方面，云中心可接收和存儲設備上傳的遙測、遙信數據，實現過程監管和算法調優，另一方面又可從云中心下發一些控制指令和控制策 略，要求數據傳輸必須及時、安全、可靠。
2.1 選型
目前工業界的通信協議種類繁多，由于商業利益或技術壁壘，不能作為通用的互聯協議連接各個系統， 而且傳統的工控協議大都運行在局域網內，對于新型的互聯網場景不適用，為打破這種困局，勢必需要一種既能滿足傳統工業需求又能融入現代廣域網技術的通信協議，這也是當今MQTT協議[2]占據物聯網協議半壁江山的原因，本文涉及的協議正是基于此技術實現的應用層實現方案，選用MQTT作為底層通信協議主要有以下原 因：
· 各種設備的計算能力差別很大，尤其一些過程層 的執行設備本身不能支持資源消耗高的通信協議棧。 MQTT協議具備輕量的特點，設備很容易支持；
· 與應用層數據無關，僅作為載荷的通道，具有很 好的適應性和擴展性；
· 輕量、簡潔，占用帶寬小，同時又具有Qos特性，滿足各種傳輸需求；
· 基于發布/訂閱模式，可使發送和接收端解耦，這是一條非常重要的特性，因為在復雜的互聯網環境里， 不能保證兩者都同時在線；
· 基于中間代理人的機制，發送端和接收端位置透明，這對虛擬化的跨網絡環境極其重要；
· 通過消息遺囑機制，可使通信雙方感知對方的狀態；
· 目前MQTT已經發布5.0，其提供的安全傳輸機制能滿足信息安全的需求。
2.2 方案
MQTT本身與業務無關，它只提供基礎的位于應 用層的傳輸通道，如果要實現邊緣設備與云中心的雙向傳輸，還需要在此之上設計業務層的交互協議。本節將以目前各個工業互聯網解決方案中都涉及的邊緣網關與云中心的互聯為場景，描述總體的解決思路，后續章節會具體針對此方案的協議實現。
邊緣網關設備的結構如圖2所示。
圖2 邊緣網關的結構圖
Root：代表本網關所在設備/站點的位置；
Channel：代表網關與設備所在網絡的連接配 置，如鏈路類型（485/以太網等）、連接信息（端口/ IP等）等；
Device：代表實際相連的物理設備，以及設備相 關的參數，如設備地址、通信參數、通信協議等；
DataGroup：按業務對數據進行組織的文件夾；
Tag：代表實際的測點，包括點名、偏移地址、數 據格式等。
如果要建立云和邊緣網關的連接，僅僅上傳測點 信息是不夠的，因為云需要對接成千上萬的設備，首先需要識別這些設備，然后才能組織這些設備，對號入 座，但是云所面對的接入設備的規模成千上萬，靠預先手動分配和設置是無法完成的，所以這就要求邊緣網關能夠自描述。關于自描述的問題，可由OPC UA技術[3] 來解決（本文不對OPC UA的建模技術做描述，可參考相關的OPC UA規范）。
掌握了網關的自描述信息，云側就可以識別后續上傳的數據，這些數據包括過程數據以及過程事件， 過程數據是Tag對應設備產生的實時值，過程事件是 Device對應的設備產生的過程報警，或網關自身產生的診斷事件，二者在數據格式、數據規模上是不同的， 所面對的接收者也是不同的。
最后，要求數據傳輸是雙向的，因此必須能夠傳輸遙控、遙調數據，由于涉及安全、權限、可靠性等問題，所以必須在協議層面保證一種機制滿足這些需求。
3 實現
3.1 總體架構
由于本協議自身基于MQTT實現，所以站在 MQTT協議的角度來看，前者屬于載荷部分，如圖3所 示。
圖3 云邊協同協議與MQTT的關系
協議包括兩部分內容；
（1）Property用于描述message的性質；
（2）Message為交互的實際內容，該部分內容包括時序信息、模型信息、事件信息，以及其他待擴展信息。
協議使用JSON格式，格式如下：
｛
Property : <Property List>,
Message: <Json Object>
｝
property格式
{
Messagetype: <string>,
Target: <string>,
Session: <string>,
sequenceId: <UInt>
}
（1）Messagetype：消息內容類型，通常用于表明message的數據格式；
（2）Target：發布到事件總線的名稱；
（3）Session：發送體的標識信息；
（4）sequenceId（optional）：消息編號， 該編號從1開始，每新產生一條消息，編號+1； CloudGateway可根據編號來判斷是否出現網絡異常。
3.2 模型數據
由于可以把邊緣網關的各個元素以對象的視角來對待，我們把它的自描述信息歸為模型數據，對于模型數據的定義如下：
message格式
{
namespace: Holi_GatewayId,
nodes: [ <Model> ],
version: <UInt or String>
}
（1）namespace：網關所屬的命名空間；
（2）node：網關的點表數據（模型信息）；
（3）version(optional)：工程點表版本。
以站點模型為例，其報文格式定義示例如下：
{
"Uri": "<ns>/Root",
"Name": "Root",
"Type": "Root",
"Description": "根節點",
"$name": "網關A",
"$class": "Folder",
"$root": ""
}
（1）Uri：節點的唯一全局標識；
（2）Name：用于表示通道或設備的英文名；
（3）Type：用于表明節點是否是根節點類型；
（4）Description：用于表示通道或設備的描 述；
（5）$name：用于表示中文名；
（6）$class：用于表示類別信息；
（7）root：節點中會包括$root關鍵字段，用于表 示作為導航起始節點。
3.3 時序數據
時序數據是指現場的過程數據，主要指測點的實時值，它通常包含vst三元組：
（1）v（value）：數值，可以是bool、int、 float、double、string類型，或者為null；
（2）s（StatusCode）：狀態碼，0x00000000表 示Good，0x80000000表示Bad，該字段為optional字 段，默認值為0x00000000；
（3）t（timestamp）：數據源產生變化的時間。
對于時序數據類型，其Message格式如下：
message格式
{
namespace: Holi_GatewayId,
values: [ <NodeValue> ]
}
（1）namespace：網關所屬的命名空間；
（2）values：為需要提交的測點數據，數據類型 為DataValue（包含VST三元組）型數組。
NodeValue格式
{
id: <string>,
value: <DataValue>
}
（1）id：用于表示測點ID；
（2）value：用于表示測點的值。
3.4 事件數據
事件數據用于上報日志或報警事件，其主要包含 了事件的各個字段信息，其Message格式如下：
Message格式
{
namespace: <string>,
events: [ <event> ]
}
（1）namespace：網關所屬的命名空間；
（2）events：網關產生的日志或報警。 事件格式
{
EventId: <string>,
Time: <timestamp>,
EventType: <string>,
SourceId: <string>,
Severity: <UInt>,
Message: <string>,
SourceName: <string>，
ReceiveTime: <timestamp>
}
所有事件（包括報警）的基礎結構：
（1）EventId：每條事件的唯一標識；
（2）Time：事件時間戳，用于表示事件產生的 時間；
（3）EventType：事件類型；
（4）SourceId：產生事件的事件源ID；
（5）Severity：事件嚴重級別，范圍從0到 1000，按照數值由低到高分為6個級別：0（None）， 1~200（Low），201~400（Medium Low）， 401~600（Medium），601~800(Medium High)， 801~1000(High)；
（6）Message：事件信息描述；
（7）SourceName：產生事件的事件源名稱；
（8）ReceiveTime：用于表示網關接收到事件的 時間；通常情況下與Time相等，但如果該事件是網關從底層系統直接采集（SOE）上來的，ReceiveTime則 不等于Time的值。
3.5 控制數據
控制指令的下發依賴于MQTT的發布機制來實 現，云中心將指令下發至MQTT Broker的topic上，再由Broker下發至網關，且可根據具體的場景要求結合 MQTT的Qos來實現，下發指令的具體格式如下：
Message格式
{
userId: <string>,
values: [ <NodeValue> ]
}
（1）userId：用戶名稱；
（2）values：需要下置的測點信息（測點名+測 點值）。
NodeValue格式
{
id： <string>,
value： <DataValue>
}
（1）id：需要下至的測點標識；
（2）value：測點值。
4 應用
在為某家電集團實現智能云平臺的項目中，通過將現場的數據采集網關（即邊緣網關）接入私有的云中 心，通過基于MQTT協議的基礎設施實現數據的雙向傳 輸，如圖4所示，集成方案如下：
圖4 云邊協同協議的應用案例
（1）每一條產線部署一臺邊緣網關，采集現場的 PLC或機器人設備，完成數據采集，并通過MQTT協議將設備的模型、時序數據、事件數據發送至MQTT Broker對應的時序數據主題名、事件數據主題名；
（2）私有云中心向MQTT訂閱時序數據主題名、 事件數據主題名，當有新數據時收到通知，根據具體的 數據類型，分別放入時序庫和事件庫；
（3）云中心的數據服務器負責為上層應用提供數 據查詢等業務；
（4）當需要下發指令時，云中心向下置命令主題名發送置值指令，而作為訂閱者的網關設備將會收到下置指令，完成指令下置。
5 結論
本文提出的基于MQTT技術的云邊協同協議， 可實現云、邊在數據協同領域的需求，其充分利用了 MQTT協議自身的優勢，以及OPC UA的建模技術，具 有一定的技術先進性，且可作為工業互聯網場景下實現數據通道的解決方案。
作者簡介：
謝 峰（1982-），男，河南人，中級工程師，碩士， 現任北京和利時智能技術有限公司、寧波和利時智能科技有限公司系統設計師，主要研究方向為工業自動化軟件。
王松林（1983-），男，山東人，中級工程師，碩士， 現任北京和利時智能技術有限公司、寧波和利時智能科技有限公司資深軟件工程師，主要研究方向為工業 自動化軟件。
參考文獻：
[1] 邊緣計算產業聯盟, 工業互聯網產業聯盟. 邊緣計算參考架構3.0[R/OL]. http://www.ecconsortium.net/Lists/show/id/334.html. 2018.
[2] MQTT Version 5.0 Committee Specification Draft 02 Public Review Draft 02[S].
[3] OPC Unified Architecture SpecificationPart 5: Information Model Release 1.04[S].
摘自《自動化博覽》2021年5月刊
北京市公安局海淀分局備案號：11010802023656號