OPC与MQTT Sparkplug的比较(非常详细）-MQTT中文站

工厂的数字化转型已经进行了很长时间。随着工业4.0及其相关系统的网络化，确保跨系统数据交换和高效的机器对机器通信的标准变得越来越重要。

OPC UA是生产环境中最常见的通信协议之一。然而，完整实现广泛的OPC UA规范极为复杂。OPC UA基于客户端/服务器架构。当需要网络化来自不同制造商的众多异构应用程序和设备时，实施OPC UA架构具有挑战性。

基于工业物联网（IIoT）中互操作性的日益重要性，特别是与Sparkplug扩展结合使用时，MQTT提供了一个有趣的替代方案，与OPC UA相比。

MQTT是OASIS标准的物联网消息传递协议，以其极其轻量级的特性和易于实现而闻名。使用MQTT协议带来了架构的根本变化。MQTT的发布-订阅模式减少了组件的配置开销，并且通信所需的带宽更少。

Sparkplug是一个开放标准，采用了MQTT的简单性、效率和易理解性等特点。Sparkplug使用MQTT指定了基础设施内的所有系统组件如何通过MQTT代理进行双向通信。

MQTT与Sparkplug的结合降低了复杂性，特别是在运行异构生产结构时，提高了效率。维护、修理和添加新组件也大大便利。

对于现有基础设施，可以通过结合Sparkplug和MQTT来实现集成。遗留设备可以通过MQTT传感器连接到Sparkplug基础设施，并为所有组件集中提供数据。

OPC UA简介

OPC统一架构（OPC UA）是制造环境中的一种连接框架标准，于2008年作为OPC（过程控制的对象链接与嵌入）标准的继承者发布。OPC UA引入的统一架构旨在实现平台独立性。

OPC UA的目标之一是实现与设备制造商的专有API无关的设备互操作性。

OPC UA协议是制造行业中最重要的通信协议之一。典型的用例包括工业自动化和过程控制应用，以及组件之间的客户端-服务器互动，例如设备或应用程序。为了便于配置、浏览、监控和数据访问，服务器和设备的地址空间被暴露出来，以允许对位于该空间的所有对象进行查询。OPC UA还支持数据的语义描述。OPC UA客户端的请求发送到OPC服务器。OPC服务器处理请求并将响应发送回相应的OPC UA客户端。此请求-响应通信模式使用结构化数据。

OPC UA基于客户端/服务器架构，并使用TCP/IP和HTTP/SOAP作为底层技术。

OPC UA服务器转换硬件通信协议，使得通过标准化的设备模型传输设备数据。

安全性通过各种方法实现，如PKI证书、WebSocket令牌、TLS和用户名/密码认证等。

支持错误管理和异常处理，并通过不同的事件和警报进行通信。OPC UA服务包括对消息传递保证（QoS）的有限支持；然而，QoS功能并非作为一个基本概念存在。

OPC UA定义了完整的数据类型系统。

OPC UA中的资源被称为节点。构成系统的不同节点是单独可寻址的，并且可以被结构化为来自不同复杂性的结构化数据类型的数据对象。

此外，OPC UA发现服务可用于动态检测基础设施设置中的新组件。

通用设备模型在OPC UA架构中扮演着核心角色。设备制造商负责提供将通用设备模型映射到特定设备的服务器。OPC UA标准由众多单个规范组成。每个规范描述了一个子功能，并指定了服务器和客户端为支持特定功能必须实现的接口。由于不需要实现所有的单个规范，因此运行OPC UA的客户端-服务器系统必须识别客户端和服务器需要哪些规范。

不同行业的配套规范对于涉及的设备和系统有助于识别哪些规范是必要的。配套规范提供了为各个行业特定应用和相关对象创建的预定义结构。

可以通过用于网络中间件（DDS）和直接机器对机器通信（M2M）应用的网关实现或通过HTTP网关与其他服务建立通信。

服务器提供了一个面向对象的远程可调用API，实现了设备模型。可以通过标准设备模型访问设备。有几十种设备类型的设备模型，从传感器到反馈控制器。

例如，特定传感器的对象模型可以提供用于设置参数、读取数据和操作设备的方法。这些方法允许应用程序直接控制传感器，而无需了解相应制造商的确切实现。系统中的一个或多个服务器等待任意数量的客户端发送请求。当服务器收到请求时，它响应然后返回到等待状态。

如果需要，客户端可以指示服务器在服务器上发送更新。

在OPC UA中，客户端决定服务器何时以及从底层系统中检索哪些数据。例如，即使服务器订阅了定期状态更新，客户端也可以决定服务器多久轮询一次设备和系统。

OPC UA的功能，如浏览或读取元信息以及在监视列表中灵活组织变量，使得从外部查看和监控机器变得更加容易。

然而，当连接来自不同制造商的众多异构应用程序和设备时，实施OPC UA架构的挑战增加。OPC UA规范长达1200多页，预示着完整实现可能会有多么广泛。完整的实现不仅在开发和支持成本方面代价高昂，而且由于OPC UA对设备的CPU要求显著提高，也代价高昂。

实施多个消费者所需的一对多构型和高度灵活的发布-订阅架构是问题所在。由于底层架构，无法实现真正的数据解耦。连接到基于云的应用程序也可能被证明是复杂的或需要高实施努力。

以下是OPC UA的基本特征总结：

  • 客户端-服务器架构
  • 通过使用TCP / HTTP作为传输协议实现平台独立性和互操作性
  • 使用TLS和证书的安全性
  • 完全定义的数据类型设置
  • 固定结构数据对象和端点
  • 预定义的行业特定规范库
  • 发现服务可用
  • 网关兼容性

传统OT / IT基础设施与OPC UA

生产环境中的典型架构包括大量的设备、传感器和网关，这些设备可能通过不同的协议进行通信。每个实体都通过直接的双向连接提供其数据或受到控制。在OPC UA中，没有“单一真理源”。来自操作生产区域的任何数量的OPC UA服务器都可以直接与所有其他操作技术（OT）参与者进行通信。每个OT参与者反过来可以作为客户端或服务器与信息技术（IT）领域的一个或多个OPC UA客户端进行工作。

MQTT简介

如果你想绕过复杂性，转向一个保证在工业自动化中安全可靠数据交换的精简解决方案，你将不可避免地遇到MQTT协议。作为OASIS标准，MQTT 5协议提供了一个被普遍认为是物联网的事实标准的规范。

MQTT协议特别轻量级的核心原则是发布-订阅模式。这种模式允许任意数量的数据消费者订阅个别主题或主题领域，并接收关于它们的发布消息。

MQTT的精简性特别适合于非常低资源的设备和低带宽、不可靠或高延迟网络中的通信。

MQTT架构通过发布-订阅协议实现与无限数量的客户端通信。

鉴于MQTT规范的许多详细描述，例如MQTT 5基础系列，本文仅关注与OPC UA相比较感兴趣的MQTT方面。

MQTT的重要特点包括：

  • 轻量级，基于TCP
  • 发布/订阅架构
  • 安全
  • 有状态的会话使用
  • 数据不可知
  • 高度动态主题
  • 消息交付保证
  • 遗嘱和保留消息概念
  • MQTT 5功能
  • 引入语义元数据，如用户属性、有效载荷指示器或内容类型描述符
  • 请求-响应模式
  • 共享订阅
  • 否定确认
  • 消息和会话过期时间按客户端设置
  • 等等

生产环境中的MQTT基础设施

使用发布-订阅协议，如MQTT和消息代理作为中心组件，代表了架构的根本变化。

所有消息都通过中心MQTT代理发送，所有MQTT客户端都连接到代理，并可以订阅特定主题。

MQTT代理承担了服务器的任务，处理与无限数量的MQTT客户端的每一次通信。

MQTT客户端直接在网关、设备或应用程序中实现，所有客户端都是松散耦合的。客户端之间没有直接关系。除了功能要求外，MQTT代理还处理诸如冗余、故障转移、高可用性和可伸缩性等需求。

MQTT与OPC UA的比较

MQTT的发布-订阅架构与OPC UA的客户端-服务器基础架构显著不同。

MQTT的中心组件始终是一个MQTT代理。代理负责完全实现MQTT规范。特别是在MQTT 5功能方面，代理的符合水平各不相同。由于MQTT 5规范中的许多功能是可选的，一些代理没有实现MQTT 5提供的所有功能。在云领域，支持水平的不同尤为相关。

会话的使用允许MQTT客户端的数据超出客户端连接的持续时间而持久化。例如，订阅、离线消息或在代理处为离线客户端存储的额外信息在客户端重新连接时立即可用。

在此处呈现的上下文中的另一个本质上的不同是在数据不可知方面。MQTT协议在规范层面上不对数据类型施加限制。因此，MQTT协议可以用于传输广泛多样的数据类型。

这种完全自由也适用于主题。除了语法要求外，MQTT主题不受任何规范的约束。主题是动态的，不必事先指定或创建。只有在MQTT客户端订阅主题以消费传入消息的上下文中，主题才存在。如果在没有MQTT客户端订阅的主题上发布消息，代理最终将丢弃该消息。

为了保证在稳定连接下完整传输消息，MQTT使用TCP作为传输协议。由于MQTT主要为不稳定的网络而设计，因此指定了三个服务质量水平（QoS），即QoS 0、1和2。MQTT消息的交付保证概念是MQTT与OPC UA的另一个显著不同之处。

MQTT中的保留消息原则对于生产环境也非常有用。此功能允许在每个主题上存储特定消息。保留消息确保每个订阅该主题的客户端都可以立即接收保存的消息。

MQTT遗嘱概念的同样重要性适用于指定客户端连接期间的消息，以便在发生离线事件时发送。遗嘱消息的一个典型用例是从客户端传输状态信息。

MQTT 5还引入了用户属性，使得在MQTT数据包中自由传输元信息成为可能，而不使用有效载荷。用户属性提供了一种简单有效的变量，用于交换元信息。

与OPC UA相比，简洁的80页MQTT规范易于实现，不定义固定结构或数据类型。

IIoT转型挑战

工业领域的数字化转型是当前影响代表全球三分之二GDP的公司的全球性趋势。随着IIoT的出现，传统流程经过200年的建立正处于深刻变革之中。因为数字化已成为保持竞争力的决定性因素，改变是必然的。

物联网或M2M通信必须具备传统人类基于HTTP的互联网的速度和简单性。当前的挑战是快速高效地实施灵活且可扩展的IIoT系统，这些系统易于设计和维护。

IIoT的挑战包括：

  • 将新设备添加、适应和集成到现有系统中
  • 根据报告的值更新设备配置
  • 更改测量、处理或数据交付工作流

在组件较少的系统中，尤其是当使用SCADA主机作为面向消息的中间件时，运营工厂所需的维护工作仍然可控。

然而，需要多个主机应用程序和连接到其他企业IT组件的系统变得非常复杂。这种复杂性导致了巨大的手动配置和维护负担。由于底层架构模式，每个组件都必须使用请求/响应方式与SCADA主机通信。

当存在多个SCADA主机时，复杂的基础设施创造了以下条件：

  • 分离的
  • 集成点
  • 每个点都必须通过请求/响应模式进行轮询
  • 将新设备集成到现有系统中的复杂性增加
  • 使用物联网提高生产线效率的原始目标在这类复杂系统中难以实现，因为每次设备更新的维护工作与基础设施设置成线性关系。

MQTT和OPC UA的结论

MQTT规范的概念非常适合用于生产的数字化。

MQTT提供的“单一真理来源”和通过中心消息组件解耦数据的优势显著。

安全性可以像在OPC UA中一样快速且多种方式实现。

客户端状态是参与组件的一个重要且固有的特性，可以通过MQTT功能完美实现。

网关可以作为集成器，连接需要其他协议的设备。

剩下的问题是如何最好地应用轻量级MQTT协议，以满足工业自动化的互操作性要求。

Sparkplug简介

为了满足工业自动化的互操作性要求，必须定义基于MQTT的实施标准。提供这种定义是Sparkplug的目标。

Sparkplug是Eclipse Foundation的Sparkplug工作组的一个项目。Sparkplug提供了一个开放且免费可用的规范，描述了边缘网关、原生MQTT支持的端点和基础设施中的MQTT应用程序如何通过中心组件（MQTT代理）双向通信。

Sparkplug是一个规范，定义了MQTT如何用于关键任务、实时OT环境中。它建立了一个标准，针对使用SCADA、标签和度量表示的工业应用案例进行了优化。该规范描述了如何在实时SCADA实现中最佳使用这些原则。

Sparkplug规范旨在实现三个目标：

定义主题命名空间
MQTT自由且动态使用主题名称是一个关键优势。然而，当在生产环境中使用MQTT时，必须指定本体。本体共享使用术语，并映射主题空间中所有设备和应用程序之间的关系。

规定有效载荷数据结构
类似于主题命名空间的规范，当在生产环境中使用MQTT时，必须定义消息内容（有效载荷）的模式。这个模式定义可以通过原生的MQTT 5概念完美实现。

定义状态管理
由于MQTT最初是为了监控实时系统而开发的，因此从一开始，协议的一个主要关注点就是处理网络故障、低带宽和高延迟。例如，通过充分使用会话功能。

Sparkplug规范的目的是将MQTT的强点（如简单性、易于实施和操作）与OT要求相结合。Sparkplug为所有参与方定义了一个本体，以保证客户端会话管理，并将消息大小保持在最小。

Sparkplug规范为开发人员和架构师提供了明确的指导，用于设计主题命名空间和结构化有效载荷数据，以及维护和传达客户端状态的方法。

Sparkplug在IIoT环境中的MQTT基础设施

在Sparkplug架构中，设备、EoN节点和SCADA/IIoT主机连接到中心MQTT代理以发布和订阅数据。

作为中心组件，MQTT代理必须100%支持MQTT标准。这是一个重要的考虑，限制了像亚马逊网络服务（AWS）或Azure IoT Hub等云提供商的适用性，因为这些供应商不完全支持MQTT协议，而是使用协议的专有版本。

除了完全支持MQTT协议外，具有故障安全、高可扩展性和集群能力的代理需要提供度量、监控和报警接口，以便可以最佳地监控所涉及的所有系统组件。

除了MQTT代理之外，使用Sparkplug的基础设施还包括以下组件：

SCADA/IoT主机是系统操作员用来管理和监控整个系统状态的中心应用程序。这个应用程序直接与MQTT代理作为特定的MQTT客户端进行交互。与传统的SCADA系统架构相比，使用Sparkplug时，SCADA/IoT主机不负责直接建立或维护与设备的连接。

网络边缘（EoN）节点在每个Sparkplug基础设施中扮演关键角色。通常，EoN节点用于将遗留基础设施连接到Sparkplug。遗留基础设施元素可以通过其他协议（如OPC UA、Modbus或专有的PLC制造商协议）与EoN节点通信。EoN节点负责管理自己的状态和设备的状态，以及从设备接收和发送数据到Sparkplug基础设施。

设备和传感器是工业自动化的支柱。在Sparkplug的背景下，设备通过EoN节点连接到Sparkplug基础设施。尽管大多数设备和传感器使用诸如Modbus、OPC UA和各种其他标准化或专有协议，但许多供应商现在提供原生支持MQTT的设备和传感器。如果MQTT支持的设备已经配备了Sparkplug，它可以直接参与基础设施。在这种情况下，设备作为Sparkplug基础设施的一个EoN节点进行标识。如果设备支持标准的MQTT而不带Sparkplug检测，则仍必须建立与EoN节点的连接。

MQTT应用程序，或次要应用程序，是参与Sparkplug通信的组件，可以生成和处理MQTT消息，但不是SCADA / IIoT主机。

结论

所有MQTT客户端，特别是SCADA主机和IT应用程序，都订阅了希望接收信息的主题。由于明确定义了主题结构和数据对象，每个MQTT客户端都知道可以从哪里以及以何种形式检索信息。由于MQTT客户端是有状态的，信息不会在任何时候丢失。特定信息的消息类型是规定的。

Sparkplug主题结构

遵循Sparkplug B规范的每个MQTT客户端都使用预定义的结构来定义主题命名空间，可以定义如下：

namespace/group_id/message_type/edge_node_id/[device_id]

NAMEDESCRIPTIONEXAMPLE
namespaceRoot element that sets the Sparkplug versionspBv1.0
group_idLogical grouping for MQTT edge nodesmachine-group
message_typeThe message typemqtt-edge-1
edge_node_idOne edge nodeNBIRTH

Sparkplug规范定义了几种消息类型。

不同的消息类型可以传输元数据以及关于设备状态的信息。

Sparkplug消息类型

节点和设备的出生和死亡证明

出生消息宣布一个MQTT客户端在线。设备或节点本身在出生主题上向整个系统提供这一信息。此类消息在建立连接后立即发送。EoN节点发送NBIRTH消息，设备发送DBIRTH消息。

为了确保即使在发送消息时不在线的设备或应用程序也可以接收到这些消息，这些消息作为保留消息发送。这种方法允许稍后登录到特定主题的组件接收消息。

DEATH消息用于传达设备或EoN的离线状态。MQTT客户端连接包中的遗嘱（LWT）和保留消息功能用于实现这一概念。LWT消息由代理管理。如果客户端失去连接，代理会将LWT消息发送到相应的DEATH主题。这种方法也允许传输客户端的离线状态。当客户端以有序方式使用DISCONNECT包注销时，在连接结束之前，离线状态将作为保留消息发布到DEATH主题。EoN节点发送NDEATH消息，设备发送DDEATH消息。

使用出生和死亡消息类型，具有特定有效载荷并用于主题结构中，可以统一实现EoN节点和设备的状态管理。

客户端状态的元数据也随之传输。通过出生消息传输元数据，可以精确定义客户端在其生命周期中发送的信息的模式或模板。这让消费MQTT客户端（在本例中为SCADA主机）知道可以期望来自相应设备或EoN的什么信息。

节点和设备的数据消息

此消息类型用于传输测量数据和某些设备属性。仅传输自上一个设备或EoN的数据消息或出生消息以来的信息状态更改。因为只发送更新，所以通信负载保持非常低。发布-订阅架构消除了轮询更改的需求，因为更改主动发送给订阅该主题的所有订阅者。

节点和设备的命令消息

此消息类型用于向EoNs或设备传输更新。MQTT消息的相关有效载荷中包含时间戳和必须写入设备的度量值等内容。

主应用程序的状态状态消息

当使用集群能力强、动态可扩展的MQTT代理时，状态消息类型是可选的。此消息类型旨在用于在实施多个并行、非集群能力代理的基础设施中使用Sparkplug。STATE消息用于通过相应的namespace/group_id/STATE/scada_host_id主题传输SCADA IIoT主机的出生消息。
EoNs在启动时订阅此主题，以消费来自主机的信息。

Sparkplug消息内容

通过定义命名空间，主题结构在语义上与要传输的信息相关联。

Sparkplug B规范支持实时数据的高效传输。有效载荷可以用不同的数据类型定义：

  • 复杂数据类型
  • 数据集
  • 丰富的度量值
  • 包括元数据的数据
  • 度量别名
  • 历史数据
  • 文件数据

有效载荷数据在Sparkplug B中以Protobuf格式进行分层结构编码。

有效载荷由一个结构化记录组成，至少必须包含发送时间戳（UTC）、一个度量值和一个序列ID。

名称和时间戳是必须的。标志是可选的，可用于指示特定数据。例如，“is_null”表示没有发送数据。自定义数据可以存储在属性中，作为键值对列表，或在body对象中。

报告异常（RBE）概念是MQTT和Sparkplug RBE的另一个重要方面，确保只发送与前一情况相关的更改。这种方法大大减少了数据量。对于特定消息类型，可以在会话开始时发送描述消息内容完整模式和初始值的有效载荷模板。基于模式，只有更改被发布并由消费MQTT客户端解读。

Sparkplug状态管理

除了定义主题结构和内容外，还必须定义状态管理的概

念。MQTT的使用有效地解决了这一要求。参与系统的MQTT客户端在建立连接时使用会话。通过结合Sparkplug出生和死亡消息以及MQTT遗嘱和保留消息，系统中的每个客户端都可以映射其状态。

状态的提供由各个组件负责，并通过MQTT代理获得。

SCADA主机状态管理

在示例中，系统的所有组件都可以通过订阅spv1.0/g1/STATE/scada1主题来获取SCADA主机的当前状态。只发布状态的更改。由于在主题上使用保留消息，最后的信息被保留，以便新添加的客户端获得信息。在消息丢失的情况下，代理会将LWT消息作为保留消息发布到主题。SCADA主机还订阅了上下文中涉及的所有设备，以便接收来自EoNs及其设备和其他MQTT应用程序的所有消息。这可以进一步限制为一个组。

EoN节点的状态管理

EoN节点的在线状态也使用LWT和保留消息实现。使用消息类型NDEATH和NBIRTH。通过订阅SCADA主机的STATE主题，EoN节点随时了解一个或多个主机的状态。通过订阅NCMD主题，EoN节点接收所有相关的控制信息。订阅DCMD主题用于接收与EoN链接的设备的控制信息，并将信息传输给设备。EoN节点的数据通过NDATA消息类型发送。

通过EoN节点的设备状态管理

与EoN连接的设备和传感器的通信由EoN节点处理。设备的在线和离线信息通过设备特定主题的保留消息传输。设备的数据被打包到数据消息中，并在相应主题上发布。所有注册在该主题上的MQTT客户端都接收到测量数据。

消息代理选择

在MQTT中，消息代理是所有消息通过其发送并且所有MQTT客户端订阅特定主题的中心组件。

Sparkplug规范基于MQTT的属性和特性。正如本文“Sparkplug在IIoT环境中的MQTT基础设施”部分所讨论的，使用完全支持MQTT协议的代理是至关重要的。

使用多个单独的代理来保证故障安全性，如Sparkplug规范中所描述的，是不必要的，当使用像HiveMQ这样具有集群能力、高可用性和故障安全的MQTT代理时。使用集群能力代理还使状态管理比规范中描述的要简单得多。从外部看，具有集群能力的代理被视为一个逻辑单元，消除了指定或识别组件连接到哪个代理的需要。

Sparkplug和OPC UA的结论

MQTT规范的概念非常适合用于生产的数字化。

MQTT所提供的“单一真理来源”和通过中心消息组件解耦数据的优势是显著的。MQTT协议支持多样化的安全选项，可以快速实现，且具备用于状态管理的现成工具。客户端状态是参与组件的一个重要且固有的特征，可以通过MQTT功能无缝实现。此外，MQTT的固有速度和低开销对于实时IIoT运营非常理想。

Sparkplug规范基于MQTT，创建了一个专为IIoT系统要求量身定做的框架。例如，为使用OT定义标签值所需的上下文数据提供支持。通过只发送数据变化并使用发布-订阅模式，显著减少了网络流量。使用编码和压缩数据格式的消息有效载荷进一步节省了网络资源。

这项比较研究突出显示了MQTT和Sparkplug相比于OPC UA或HTTP所提供的极大带宽节省。

为数据和主题定义的本体确保发送的信息可以被IT结构的组件解读，而无需进一步的元信息。这种对数据和主题设计的统一方法使制造商能够交付符合规范的设备。更一致的一致性使得在IIoT中配置和使用设备变得更加容易、快速且最终更具成本效益。

在使用面向消息的中间件（如MQTT代理）的架构中集成设备，比在复杂的客户端-服务器结构中要容易得多。系统中的每个组件只与代理通信。不需要额外的配置。

即使OPC UA和MQTT在数据处理方式上有显著差异，它们仍然可以一起工作。一些旧设备需要OPC服务器，并应保持连接到Sparkplug基础设施。通过使用连接到旧设备的MQTT兼容传感器，可以使用MQTT和Sparkplug使这些数据在IT的所有组件中中央可用。

总结而言，MQTT和Sparkplug提供了一种高效且灵活的方法，用于在工业环境中处理数据和通信，特别是在考虑到实时数据和设备管理的IIoT应用中。与传统的OPC UA相比，它们提供了更高的效率和更低的复杂性，同时也提供了丰富的功能，适合于现代工业自动化和数字化需求。

打赏微海报分享