2. OPC UA基础回顾

在进入 OPC UA PubSub 之前，必须先把经典 OPC UA 的骨架重新梳理一遍。很多初学者把 PubSub 理解为“OPC UA 加了一个发布订阅功能”，这种理解会掩盖两者在通信模型、数据组织方式和运行机制上的根本差异。本节从客户端服务器模型、信息模型、地址空间、服务集四个维度回顾经典 OPC UA，再对照 PubSub 的差异，为后续实时数据通信打下概念基础。

一、经典客户端服务器模型：请求—响应是默认节奏

经典 OPC UA 采用客户端/服务器（Client/Server）架构。服务器维护地址空间、暴露服务接口，客户端主动发起连接、建立会话、发送服务请求，服务器处理后返回响应。整个交互遵循“请求—响应”节奏：客户端不请求，服务器通常不会主动推送数据；即使使用订阅（Subscription）和监控项（MonitoredItem），底层仍然是客户端先创建订阅，服务器再按发布间隔把通知放入响应或通知消息中。

这种模型的关键特征包括：

• 连接导向：客户端与服务器之间需要建立安全通道和会话，通信关系是点对点的。
• 角色明确：客户端是主动方，服务器是被动响应方，服务器一般不主动向未知客户端发送数据。
• 状态维护：会话、订阅、监控项都有生命周期，服务器需要为每个客户端维护状态。
• 可靠但开销较高：请求响应可确认、可重传，但每个客户端都要单独建链、单独订阅，规模扩展时服务器压力明显。

二、信息模型与地址空间：把设备语义装进节点网络

OPC UA 的核心价值不只是“传值”，而是“传有语义的值”。信息模型（Information Model）用对象、变量、方法、类型等元素描述现实设备；地址空间（Address Space）则是这些元素在服务器中的组织容器。地址空间由节点（Node）和引用（Reference）构成，节点通过引用相互连接，形成一张有向图。客户端通过浏览（Browse）地址空间，可以发现设备有哪些对象、变量、方法以及它们之间的关系。

例如，一个温度传感器在地址空间中可能表现为：

Objects
 └─ Machine_1
     ├─ Temperature (Variable, Double)
     │   ├─ EngineeringUnits = °C
     │   └─ EURange = 0..150
     └─ StartHeating (Method)

节点由 NodeId 唯一标识，属性包括 DisplayName、DataType、ValueRank、AccessLevel 等。变量节点还带有当前值、时间戳和状态码。信息模型让数据自带类型、单位和语义，而不是一串裸字节。这也是 OPC UA 与 Modbus 等传统协议的重要区别。

三、服务集：客户端能做什么，由服务定义

经典 OPC UA 把服务器能力抽象为一组服务集（Service Set），客户端通过服务调用与服务器交互。常见服务集包括：

• SecureChannel 服务集：建立安全通道、协商密钥、维护通道状态。
• Session 服务集：创建会话、激活会话、关闭会话。
• View 服务集：浏览地址空间、注册节点、翻译浏览路径。
• Attribute 服务集：读取、写入节点属性，如读变量值、写变量值。
• Subscription 服务集：创建订阅、修改发布间隔、删除订阅。
• MonitoredItem 服务集：为订阅添加监控项，设置采样间隔、死区、队列大小。

这些服务大多以请求/响应方式调用，返回结果包含状态码。服务集体现了经典 OPC UA 的“接口化”设计：客户端不需要了解服务器内部实现，只要按服务契约调用即可。

四、PubSub 与经典模型的差异：从点对点到多对多

PubSub（发布/订阅）改变了数据分发方式。发布者（Publisher）把数据集（DataSet）编码成网络消息，通过 UDP、MQTT、AMQP 等传输协议发送到网络；订阅者（Subscriber）按配置接收消息并解析。发布者不需要知道有多少订阅者，订阅者也不需要与发布者建立会话。通信关系从“点对点请求响应”变成“多对多单向分发”。

下表对比经典客户端服务器与 PubSub 的关键差异：

对比维度	经典客户端/服务器	PubSub
通信模式	请求—响应，点对点	发布—订阅，多对多
连接方式	需建立安全通道与会话	通常无会话，基于消息中间件或组播
数据组织	地址空间节点 + 服务调用	DataSet、DataSetWriter、WriterGroup
传输协议	UA TCP、HTTPS 等	UDP、MQTT、AMQP、Ethernet 等
实时性	受请求周期和会话开销影响	可周期发布，延迟更低、更稳定
扩展性	客户端越多，服务器压力越大	订阅者增加通常不增加发布者负担
可靠性	确认与重传机制完善	依赖传输层，UDP 下可能丢包

五、核心原理：两种模型如何衔接

PubSub 并不是要取代经典 OPC UA，而是与其互补。发布者通常仍然运行在 OPC UA 服务器内部，它从地址空间读取变量值，按配置组装成 DataSet，再通过 WriterGroup 发布出去。订阅者收到消息后，可以把数据映射回自己的地址空间，供本地客户端访问。也就是说，地址空间和信息模型仍然是语义基础，PubSub 只是换了一种更高效的数据分发通道。

六、案例场景：产线温度监控

假设一条产线有 20 个温度传感器，需要把温度实时送到监控大屏、边缘计算网关和 MES 系统。若采用经典客户端/服务器模型，大屏、网关、MES 都要分别与 OPC UA 服务器建立会话、创建订阅，服务器需要维护三套订阅状态，客户端数量继续增加时压力线性上升。

若采用 PubSub：OPC UA 服务器作为发布者，把 20 个温度变量组织成一个 DataSet，通过 MQTT 主题 line1/temperature 周期发布。大屏、网关、MES 都作为订阅者订阅该主题，发布者只发一份消息，订阅者数量增加不影响发布者。对于需要历史追溯或按需读取的场景，仍可保留经典客户端/服务器接口。

七、常见误区与复盘

• 误区一：PubSub 不需要信息模型。实际上 DataSet 字段仍然需要名称、类型和语义，信息模型仍是基础。
• 误区二：PubSub 一定比客户端/服务器快。实时性取决于发布周期、传输协议和网络质量，配置不当同样会延迟或丢包。
• 误区三：PubSub 可以完全替代客户端/服务器。配置、诊断、历史访问、方法调用等场景仍依赖经典服务集。
• 误区四：UDP 发布不需要可靠性设计。UDP 不保证送达，关键数据应结合序列号、心跳、冗余发布或改用 MQTT 等可靠传输。

总结来看，经典 OPC UA 以客户端服务器、地址空间、信息模型和服务集为核心，强调安全、语义和按需访问；PubSub 在此基础上引入发布订阅、DataSet、WriterGroup/ReaderGroup 和多种传输映射，强调高效、多对多和低延迟分发。理解两者的差异与衔接，是掌握 OPC UA PubSub 实时数据通信的第一步。