国产欧美日韩精品a在线观看-国产欧美日韩精品一区二区三区-国产欧美日韩精品综合-国产欧美中文字幕-一区二区三区精品国产-一区二区三区精品国产欧美

摘要：隨著云技術(shù)在邊緣側(cè)的逐步落地，邊云協(xié)同的應(yīng)用場景與需求逐步增多，云和邊之間的協(xié)同包括資源協(xié)同、數(shù)據(jù)協(xié)同、應(yīng)用管理協(xié)同、 業(yè)務(wù)管理協(xié)同、服務(wù)協(xié)同等。本文提出的基于MQTT技術(shù)的云邊協(xié)同協(xié) 議，主要為數(shù)據(jù)協(xié)同提供解決方案，可實現(xiàn)數(shù)據(jù)的雙向全雙工通信，同時保證傳輸?shù)陌踩浴?/span>

關(guān)鍵詞：MQTT；OPC UA；云邊協(xié)同

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　引言

當(dāng)今工業(yè)領(lǐng)域，以云計算為主的ICT技術(shù)正在向邊緣側(cè)不斷滲透，云與邊雖然擔(dān)任的職責(zé)和適用的業(yè)務(wù)場 景有很大差別，但是它們之間已逐漸變得相互融合、不可分割，在不同層級有著不同層次的交互，云和邊之間的協(xié)同包括資源協(xié)同、數(shù)據(jù)協(xié)同、應(yīng)用管理協(xié)同、業(yè)務(wù)管理協(xié)同、服務(wù)協(xié)同等[1]，如圖1所示。另外，隨著自動化軟件層級結(jié)構(gòu)由垂直模式逐漸向水平模式演變，各設(shè)備和系統(tǒng)計算能力差異很大，尤其物聯(lián)網(wǎng)技術(shù)的融 入，更要求各系統(tǒng)間的通信能夠提供一種通用、輕量、 高效、安全的通信協(xié)議，為解決邊緣設(shè)備與云中心互聯(lián)問題，本文提出了以MQTT技術(shù)為基礎(chǔ)的實現(xiàn)方案，重點闡述協(xié)議層的設(shè)計原理。

 圖1 云邊協(xié)同的應(yīng)用場景

 2　應(yīng)用場景

隨著萬物互聯(lián)時代的到來，邊緣側(cè)設(shè)備呈爆炸性增長，以云技術(shù)構(gòu)建起來的大數(shù)據(jù)中心為裝備的智能化提供支撐，如深度學(xué)習(xí)、大數(shù)據(jù)分析等，但是這些的本源是數(shù)據(jù)，如果邊緣側(cè)的過程數(shù)據(jù)如傳感器數(shù)據(jù)、配置數(shù)據(jù)、多媒體數(shù)據(jù)等無法接入云中心，那么智能化就無從談起，所以為打通設(shè)備與云的數(shù)據(jù)通道，必須提供一種廣泛適用的應(yīng)用層協(xié)議。

在工業(yè)現(xiàn)場，目前涉及比較多的場景是傳遞四遙數(shù)據(jù)，此場景要求通信數(shù)據(jù)量大、數(shù)據(jù)連續(xù)、有一定的 實時性、保證數(shù)據(jù)安全。一方面，云中心可接收和存儲設(shè)備上傳的遙測、遙信數(shù)據(jù)，實現(xiàn)過程監(jiān)管和算法調(diào)優(yōu)，另一方面又可從云中心下發(fā)一些控制指令和控制策 略，要求數(shù)據(jù)傳輸必須及時、安全、可靠。

2.1　選型

目前工業(yè)界的通信協(xié)議種類繁多，由于商業(yè)利益或技術(shù)壁壘，不能作為通用的互聯(lián)協(xié)議連接各個系統(tǒng)， 而且傳統(tǒng)的工控協(xié)議大都運行在局域網(wǎng)內(nèi)，對于新型的互聯(lián)網(wǎng)場景不適用，為打破這種困局，勢必需要一種既能滿足傳統(tǒng)工業(yè)需求又能融入現(xiàn)代廣域網(wǎng)技術(shù)的通信協(xié)議，這也是當(dāng)今MQTT協(xié)議[2]占據(jù)物聯(lián)網(wǎng)協(xié)議半壁江山的原因，本文涉及的協(xié)議正是基于此技術(shù)實現(xiàn)的應(yīng)用層實現(xiàn)方案，選用MQTT作為底層通信協(xié)議主要有以下原 因：

· 各種設(shè)備的計算能力差別很大，尤其一些過程層 的執(zhí)行設(shè)備本身不能支持資源消耗高的通信協(xié)議棧。 MQTT協(xié)議具備輕量的特點，設(shè)備很容易支持；

· 與應(yīng)用層數(shù)據(jù)無關(guān)，僅作為載荷的通道，具有很 好的適應(yīng)性和擴展性；

· 輕量、簡潔，占用帶寬小，同時又具有Qos特性，滿足各種傳輸需求；

· 基于發(fā)布/訂閱模式，可使發(fā)送和接收端解耦，這是一條非常重要的特性，因為在復(fù)雜的互聯(lián)網(wǎng)環(huán)境里， 不能保證兩者都同時在線；

· 基于中間代理人的機制，發(fā)送端和接收端位置透明，這對虛擬化的跨網(wǎng)絡(luò)環(huán)境極其重要；

· 通過消息遺囑機制，可使通信雙方感知對方的狀態(tài)；

· 目前MQTT已經(jīng)發(fā)布5.0，其提供的安全傳輸機制能滿足信息安全的需求。

2.2　方案

MQTT本身與業(yè)務(wù)無關(guān)，它只提供基礎(chǔ)的位于應(yīng) 用層的傳輸通道，如果要實現(xiàn)邊緣設(shè)備與云中心的雙向傳輸，還需要在此之上設(shè)計業(yè)務(wù)層的交互協(xié)議。本節(jié)將以目前各個工業(yè)互聯(lián)網(wǎng)解決方案中都涉及的邊緣網(wǎng)關(guān)與云中心的互聯(lián)為場景，描述總體的解決思路，后續(xù)章節(jié)會具體針對此方案的協(xié)議實現(xiàn)。

邊緣網(wǎng)關(guān)設(shè)備的結(jié)構(gòu)如圖2所示。

圖2 邊緣網(wǎng)關(guān)的結(jié)構(gòu)圖

Root：代表本網(wǎng)關(guān)所在設(shè)備/站點的位置；

Channel：代表網(wǎng)關(guān)與設(shè)備所在網(wǎng)絡(luò)的連接配 置，如鏈路類型（485/以太網(wǎng)等）、連接信息（端口/ IP等）等；

Device：代表實際相連的物理設(shè)備，以及設(shè)備相 關(guān)的參數(shù)，如設(shè)備地址、通信參數(shù)、通信協(xié)議等；

DataGroup：按業(yè)務(wù)對數(shù)據(jù)進行組織的文件夾；

Tag：代表實際的測點，包括點名、偏移地址、數(shù) 據(jù)格式等。

如果要建立云和邊緣網(wǎng)關(guān)的連接，僅僅上傳測點 信息是不夠的，因為云需要對接成千上萬的設(shè)備，首先需要識別這些設(shè)備，然后才能組織這些設(shè)備，對號入 座，但是云所面對的接入設(shè)備的規(guī)模成千上萬，靠預(yù)先手動分配和設(shè)置是無法完成的，所以這就要求邊緣網(wǎng)關(guān)能夠自描述。關(guān)于自描述的問題，可由OPC UA技術(shù)[3] 來解決（本文不對OPC UA的建模技術(shù)做描述，可參考相關(guān)的OPC UA規(guī)范）。

掌握了網(wǎng)關(guān)的自描述信息，云側(cè)就可以識別后續(xù)上傳的數(shù)據(jù)，這些數(shù)據(jù)包括過程數(shù)據(jù)以及過程事件， 過程數(shù)據(jù)是Tag對應(yīng)設(shè)備產(chǎn)生的實時值，過程事件是 Device對應(yīng)的設(shè)備產(chǎn)生的過程報警，或網(wǎng)關(guān)自身產(chǎn)生的診斷事件，二者在數(shù)據(jù)格式、數(shù)據(jù)規(guī)模上是不同的， 所面對的接收者也是不同的。

最后，要求數(shù)據(jù)傳輸是雙向的，因此必須能夠傳輸遙控、遙調(diào)數(shù)據(jù)，由于涉及安全、權(quán)限、可靠性等問題，所以必須在協(xié)議層面保證一種機制滿足這些需求。

3　實現(xiàn)

3.1　總體架構(gòu)

由于本協(xié)議自身基于MQTT實現(xiàn)，所以站在 MQTT協(xié)議的角度來看，前者屬于載荷部分，如圖3所 示。

圖3 云邊協(xié)同協(xié)議與MQTT的關(guān)系

協(xié)議包括兩部分內(nèi)容；

（1）Property用于描述message的性質(zhì)；

（2）Message為交互的實際內(nèi)容，該部分內(nèi)容包括時序信息、模型信息、事件信息，以及其他待擴展信息。

協(xié)議使用JSON格式，格式如下：

｛

Property : <Property List>,

Message: <Json Object>

｝

property格式

{ 

Messagetype: <string>,

Target: <string>,

Session: <string>,

sequenceId: <UInt>

}

（1）Messagetype：消息內(nèi)容類型，通常用于表明message的數(shù)據(jù)格式；

（2）Target：發(fā)布到事件總線的名稱；

（3）Session：發(fā)送體的標(biāo)識信息；

（4）sequenceId（optional）：消息編號， 該編號從1開始，每新產(chǎn)生一條消息，編號+1； CloudGateway可根據(jù)編號來判斷是否出現(xiàn)網(wǎng)絡(luò)異常。

3.2　模型數(shù)據(jù)

由于可以把邊緣網(wǎng)關(guān)的各個元素以對象的視角來對待，我們把它的自描述信息歸為模型數(shù)據(jù)，對于模型數(shù)據(jù)的定義如下：

message格式

{

namespace: Holi_GatewayId,

nodes: [ <Model> ],

version: <UInt or String>

}

（1）namespace：網(wǎng)關(guān)所屬的命名空間；

（2）node：網(wǎng)關(guān)的點表數(shù)據(jù)（模型信息）；

（3）version(optional)：工程點表版本。

以站點模型為例，其報文格式定義示例如下：

{

"Uri":  "<ns>/Root",

"Name":  "Root",

"Type":  "Root",

"Description": "根節(jié)點",

"$name":  "網(wǎng)關(guān)A",

"$class":  "Folder",

"$root":  ""

}

（1）Uri：節(jié)點的唯一全局標(biāo)識；

（2）Name：用于表示通道或設(shè)備的英文名；

（3）Type：用于表明節(jié)點是否是根節(jié)點類型；

（4）Description：用于表示通道或設(shè)備的描 述；

（5）$name：用于表示中文名；

（6）$class：用于表示類別信息；

（7）root：節(jié)點中會包括$root關(guān)鍵字段，用于表 示作為導(dǎo)航起始節(jié)點。

3.3　時序數(shù)據(jù)

時序數(shù)據(jù)是指現(xiàn)場的過程數(shù)據(jù)，主要指測點的實時值，它通常包含vst三元組：

（1）v（value）：數(shù)值，可以是bool、int、 float、double、string類型，或者為null；

（2）s（StatusCode）：狀態(tài)碼，0x00000000表 示Good，0x80000000表示Bad，該字段為optional字 段，默認值為0x00000000；

（3）t（timestamp）：數(shù)據(jù)源產(chǎn)生變化的時間。

對于時序數(shù)據(jù)類型，其Message格式如下：

message格式

{

namespace: Holi_GatewayId,

values: [ <NodeValue> ]

}

（1）namespace：網(wǎng)關(guān)所屬的命名空間；

（2）values：為需要提交的測點數(shù)據(jù)，數(shù)據(jù)類型 為DataValue（包含VST三元組）型數(shù)組。

NodeValue格式

{

 id: <string>,

value: <DataValue>

  }

（1）id：用于表示測點ID；

（2）value：用于表示測點的值。

3.4　事件數(shù)據(jù)

事件數(shù)據(jù)用于上報日志或報警事件，其主要包含 了事件的各個字段信息，其Message格式如下：

Message格式

{

namespace: <string>,

events: [ <event> ]

}

（1）namespace：網(wǎng)關(guān)所屬的命名空間；

（2）events：網(wǎng)關(guān)產(chǎn)生的日志或報警。 事件格式

{

EventId: <string>,

Time: <timestamp>,

EventType: <string>,

SourceId: <string>,

Severity: <UInt>,

Message: <string>,

SourceName: <string>，

ReceiveTime: <timestamp>

}

所有事件（包括報警）的基礎(chǔ)結(jié)構(gòu)：

（1）EventId：每條事件的唯一標(biāo)識；

（2）Time：事件時間戳，用于表示事件產(chǎn)生的 時間；

（3）EventType：事件類型；

（4）SourceId：產(chǎn)生事件的事件源ID；

（5）Severity：事件嚴(yán)重級別，范圍從0到 1000，按照數(shù)值由低到高分為6個級別：0（None）， 1~200（Low），201~400（Medium Low）， 401~600（Medium），601~800(Medium High)， 801~1000(High)；

（6）Message：事件信息描述；

（7）SourceName：產(chǎn)生事件的事件源名稱；

（8）ReceiveTime：用于表示網(wǎng)關(guān)接收到事件的 時間；通常情況下與Time相等，但如果該事件是網(wǎng)關(guān)從底層系統(tǒng)直接采集（SOE）上來的，ReceiveTime則 不等于Time的值。

3.5　控制數(shù)據(jù)

控制指令的下發(fā)依賴于MQTT的發(fā)布機制來實 現(xiàn)，云中心將指令下發(fā)至MQTT Broker的topic上，再由Broker下發(fā)至網(wǎng)關(guān)，且可根據(jù)具體的場景要求結(jié)合 MQTT的Qos來實現(xiàn)，下發(fā)指令的具體格式如下：

Message格式

{

userId: <string>,

values: [ <NodeValue> ]

}

（1）userId：用戶名稱；

（2）values：需要下置的測點信息（測點名+測 點值）。

NodeValue格式

{

 id： <string>,

  value： <DataValue>

} 

（1）id：需要下至的測點標(biāo)識；

（2）value：測點值。

4　應(yīng)用

在為某家電集團實現(xiàn)智能云平臺的項目中，通過將現(xiàn)場的數(shù)據(jù)采集網(wǎng)關(guān)（即邊緣網(wǎng)關(guān)）接入私有的云中 心，通過基于MQTT協(xié)議的基礎(chǔ)設(shè)施實現(xiàn)數(shù)據(jù)的雙向傳 輸，如圖4所示，集成方案如下：

圖4 云邊協(xié)同協(xié)議的應(yīng)用案例

（1）每一條產(chǎn)線部署一臺邊緣網(wǎng)關(guān)，采集現(xiàn)場的 PLC或機器人設(shè)備，完成數(shù)據(jù)采集，并通過MQTT協(xié)議將設(shè)備的模型、時序數(shù)據(jù)、事件數(shù)據(jù)發(fā)送至MQTT  Broker對應(yīng)的時序數(shù)據(jù)主題名、事件數(shù)據(jù)主題名；

（2）私有云中心向MQTT訂閱時序數(shù)據(jù)主題名、 事件數(shù)據(jù)主題名，當(dāng)有新數(shù)據(jù)時收到通知，根據(jù)具體的 數(shù)據(jù)類型，分別放入時序庫和事件庫；

（3）云中心的數(shù)據(jù)服務(wù)器負責(zé)為上層應(yīng)用提供數(shù) 據(jù)查詢等業(yè)務(wù)；

（4）當(dāng)需要下發(fā)指令時，云中心向下置命令主題名發(fā)送置值指令，而作為訂閱者的網(wǎng)關(guān)設(shè)備將會收到下置指令，完成指令下置。

5　結(jié)論

本文提出的基于MQTT技術(shù)的云邊協(xié)同協(xié)議， 可實現(xiàn)云、邊在數(shù)據(jù)協(xié)同領(lǐng)域的需求，其充分利用了 MQTT協(xié)議自身的優(yōu)勢，以及OPC UA的建模技術(shù)，具 有一定的技術(shù)先進性，且可作為工業(yè)互聯(lián)網(wǎng)場景下實現(xiàn)數(shù)據(jù)通道的解決方案。

作者簡介：

謝　峰（1982-），男，河南人，中級工程師，碩士， 現(xiàn)任北京和利時智能技術(shù)有限公司、寧波和利時智能科技有限公司系統(tǒng)設(shè)計師，主要研究方向為工業(yè)自動化軟件。

王松林（1983-），男，山東人，中級工程師，碩士， 現(xiàn)任北京和利時智能技術(shù)有限公司、寧波和利時智能科技有限公司資深軟件工程師，主要研究方向為工業(yè) 自動化軟件。

 參考文獻：

[1] 邊緣計算產(chǎn)業(yè)聯(lián)盟, 工業(yè)互聯(lián)網(wǎng)產(chǎn)業(yè)聯(lián)盟. 邊緣計算參考架構(gòu)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月刊