我在OPC Day Finland 2021 论坛上谈论了OPC UA PubSub。该演讲和幻灯片可在 YouTube 上看到，但我决定也写一篇博文来探讨这一新功能。这个话题很重要，需要更多的关注，这样我们才能正确地理解它。

我对这篇文章的定义如下：

1. OPC UA 客户端/服务器模式 – 简略介绍来提醒读者传统的 OPC UA 通信模式
2. OPC UA 发布端/订阅端模式 – 这种新模式是什么，优势是什么
3. PubSub 场景 – 优势在哪里
4. PubSub 演示 – 我们自己是如何尝试的
5. 结论

我已经添加了演示文稿的截图，如果您想听到我解释的话，您可以点击图片进入视频中的那个部分。视频中有动画，希望有助于将复杂的主题分解为几个更容易理解的部分。

1. OPC UA 客户端/服务器模式

客户端/服务器模式是 OPC UA 中传统的通信模式。它基于这样一种想法，即有一个被动的服务器组件，为充当客户端的其他应用程序提供数据。客户端应用程序可以通过一些标准化服务从服务器访问数据和信息。

客户端必须做的第一件事就是打开与服务器的连接。它需要一个连接地址，然后（跳过一些细节）创建到服务器的会话。会话包含一个安全上下文，其中包括可选的加密和身份验证参数，用于标识服务器中的客户端应用程序和用户。客户端还可以识别服务器，并决定是否允许与之通信。

会话建立后，客户端应用程序可以从服务器请求一些标准服务。这些服务包括：

1. 连接并创建会话
2. 浏览地址空间 - 了解服务器上的可用内容
3. 读取-变量值或元数据
4. 写入-变量值-有时甚至元数据
5. 通话方法
6. 读取历史记录-变量和事件
7. 关闭会话并断开连接

最后，当客户端完成工作时，将关闭会话并断开连接。

客户端/服务器订阅

客户端/服务器模型还包含订阅模型。在这个模型中，每个客户端都可以创建任意数量的服务器订阅。每个订阅都可以包括变量和 EventNotifier（设置了 EventNotifier 属性的对象节点）的 MonitoredItems。

创建订阅后，客户端将开始向服务器调用Publish方法，服务器将以 NotificationMessages 响应。NotificationMessage 可能包含数据更改和事件，这与 MonitoredItems 的类型有关。

客户端/服务器模式的优缺点

客户端/服务器模式已经被成功地应用于典型的 SCADA 场景，当不同应用程序之间的连接数量不是很高时，这个模式能够完美地执行任务。如果您有数十台或数百台设备（即服务器）需要持续连接，或者有类似数量的客户端需要连接到任何服务器，那么您可能最终会遇到资源问题，因为每个连接和订阅都需要内部管理，它们会在网络中造成单独的流量。

传统上，OPC UA 的设计不支持任何确定性通信或不可靠网络上的通信。但它支持同步服务调用，这些调用可以立即收到结果或对操作的确认，这对应用程序来说非常重要。

安全性也很灵活，您可以为每个应用程序和用户定义规则，如果需要，甚至可以为每个变量定义规则。

2. 发布端/订阅端模式

PubSub 模式与客户端/服务器模式截然不同，但在 OPC UA 环境中，两者有相似之处。

在 PubSub 模式中，我们有一个发布端组件，它可以定义包含变量或 EventNotifiers 的数据集。然后，发布端会发布分别包含数据更改或事件的 DataSetMessages。因此，传输的数据类似于客户端/服务器订阅。只是它的排列方式有所不同。

这些信息被发布到一个网络中，用户可以在那里收听并过滤他们需要的信息。

因此，与客户端/服务器模式中的订阅相反，发送方在数据集中定义要发送的内容，而不是接收方。除此以外，DatasetMessages 中的数据与 NotificationMessages 中的数据基本相同（尽管格式不同）。

该模型可以扩展，因为理论上可以有任意数量的发布端和订阅端。它们都连接到同一个网络，但彼此不连接，这是对客户端/服务器模型的主要改进。

PubSub 网络

OPC UA 为 PubSub 定义了两种不同的网络类型。

1. 本地网络 - 可以使用 UDP 广播（或在某些情况下单播）或以太网 APL。消息是优化的二进制 UADP，这在 OPC UA 规范中定义。因此，只有 OPC UA 用户可以解释这些消息。

2. 消息队列代理 - 实际上可以是 MQTT 或 AMQP 代理。在这种情况下，消息通常使用 JSON 消息格式，尽管 UADP 可以用于提高性能。OPC 基金会为消息定义了一个标准的内容结构，但基本上任何 JSON 订阅服务器都可以解释它们。

PubSub 安全性

PubSub 的安全性比客户端/服务器中的安全性要复杂一些，而且规范没有那么细致。

在本地网络中，您将需要一个额外的组件，即安全密钥服务器，所有发布端和订阅端都要与其连接，安全密钥服务器为它们提供共享密钥，以便它们可以对消息进行加密和解密。该模式没有身份验证，除非密钥服务器对应用程序进行身份验证。

在代理网络中，安全性基于 SSL/TLS，代理除了可以为传输启用 SSL/TLS，还可以定义应用程序级身份验证。

在这两种安全模式中，没有为某个数据项定制的规则，可被用于某些订阅端从某些发布端接收数据。原则上，对于每个可以加入网络的订阅端和发布端，这些安全模式要么全有，要么全无。

PubSub 优缺点

PubSub 模型解决了可扩展性问题。 MQTT 在许多（非 OPC UA）应用程序中已经非常流行和成功，在这些应用程序中，您需要通过不可靠的连接将数千个数据提供商（如小型传感器或远程仪表）连接到中央监控。很多行业已经提出了新的想法，如何在更大的背景下实际使用。现在，OPC UA 为消息内容添加了一些标准格式，并提供了将 OPC UA 数据映射到其中的标准方法，这应该是有益的。新的标准化仍在进行中，例如，丰富的 OPC UA 信息模型如何以最佳方式映射到 MQTT，目前尚不明确。

另一方面，OPC UA 使用 PubSub 模式在本地网络中实现非常快速的通信，一旦网络通过以太网 TSN 和 APL 技术变得确定和快速，我们就可以预见通过 OPC UA PubSub 进行实时通信的可能性。这就是 OPC UA 现场级通信（FLC）计划的全部内容，也是新的现场交换（FX）规范可以提供的内容。

3. PubSub 场景

世界正在慢慢地从以著名的自动化金字塔为基础的工业 3.0 发展到工业 4.0。在工业 4.0 中，工厂中的所有组件都连接到生产网络。此外，产品本身也可以携带有关自身的信息，可以从世界任何地方访问生产信息。客户端/服务器模式非常适合旧世界，那里的智能组件（即计算机）数量和连接很少。在新的世界中，当产生和消费共享网络信息的组件数量急剧增加时，连接问题可能会爆发。PubSub 模式应该更适合新世界，但至少在现时，我们仍将使用这两种模式来互补。

实际上，在大多数情况下，PubSub 模式可以并且将与客户端/服务器模式相结合。这允许将发布服务端添加到服务器，将订阅端添加到客户端，或添加任何其他组合。

最初设想的两个主要 PubSub 运用场景是同步服务器和边缘到云场景。

在同步服务器场景中，我们有两个或多个 OPC UA 服务器，它们在地址空间中相互镜像数据。UDP 广播在本地网络中尤其适用，通过实时网络，该场景可被用于分布式控制，尽管它仍然缺乏适当的方法调用接口。

4. PubSub 演示

我们已经创建了三个关于 PubSub 的公开演示：

1. 使用 MQTT 将 OPC UA 发布端连接到 Azure
2. 使用 MQTT 将 OPC UA Publisher 连接到亚马逊 AWS 物联网
3. 制造网关演示

您可以从链接的博客帖子中查看详细信息。该视频还为您提供了对这些使用场景的概述。

5. 结论

因此，我们仍然需要 OPC UA 客户端/服务器模式，以便能够在典型的 SCADA 场景中“同步”通信。

PubSub 模型实现了更好的可扩展性，并提高了通信性能，这使其成为实时通信的良好候选择，并能够在 OPC UA 现场级通信（FLC）计划和新的现场交换（FX）标准中发挥重要作用。

Georg Biehler 在 OPC Day Finland 2021 发表了一篇关于 OPC UA 现场交流（FX）的精彩演讲，您感兴趣的话可以查阅！