摘要：随着云技术在边缘侧的逐步落地，边云协同的应用场景与需求逐步增多，云和边之间的协同包括资源协同、数据协同、应用管理协同、 业务管理协同、服务协同等。本文提出的基于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月刊