3. OPC UA 通信模式：请求/响应、订阅与发布/订阅
OPC UA 规范定义了三种核心通信模式，分别适用于不同的工业数据交换场景。理解这三种模式的差异与适用边界，是部署工业网关和设计数据采集架构的基础。本章从协议栈实现角度，逐一解析请求/响应模式、订阅与监控项机制，以及发布/订阅（PubSub）模式。
3.1 请求/响应模式（Client-Server）
请求/响应是 OPC UA 最基础的通信模式，遵循典型的客户端-服务器架构。客户端主动发起请求，服务器处理请求并返回响应。这种模式适用于一次性读取、写入或方法调用等操作。
| 特性 | 说明 |
|---|---|
| 通信方向 | 客户端发起 → 服务器响应 |
| 典型服务 | Read、Write、Call（方法调用）、Browse（浏览地址空间） |
| 适用场景 | 配置读取、参数写入、设备诊断、单次查询 |
| 实时性 | 低至中等，受网络往返延迟影响 |
| 资源消耗 | 每次请求建立逻辑通道，高频率下开销较大 |
网关部署提示： 在工业网关中，请求/响应模式常用于初始化阶段的地址空间浏览和配置下发。对于高频数据采集（如 100ms 间隔的传感器值），应避免使用轮询式 Read 请求，改用订阅模式以降低网络负载。
3.2 订阅（Subscription）与监控项（MonitoredItem）机制
订阅机制是 OPC UA 实现高效、实时数据采集的核心。它允许客户端在服务器上注册感兴趣的数据节点，服务器在数据变化或达到特定触发条件时主动推送通知，无需客户端反复轮询。
3.2.1 核心概念
- Subscription（订阅）： 一个通信契约，定义了通知的发布周期（Publishing Interval）、存活时间（Lifetime Count）和最大保持通知数（Max Keep Alive Count）。一个订阅可以包含多个监控项。
- MonitoredItem（监控项）： 绑定到地址空间中的特定节点（如变量节点），定义了监控的采样间隔（Sampling Interval）、触发方式（DataChange 或 Event）以及过滤条件（如死区设置）。
- Notification（通知）： 当监控项检测到数据变化或事件发生时，服务器生成的通知数据包，通过订阅通道推送给客户端。
3.2.2 工作机制流程
- 创建订阅： 客户端调用
CreateSubscription服务，指定发布周期等参数。 - 添加监控项： 客户端调用
CreateMonitoredItems服务，将需要监控的节点 ID 和采样参数绑定到订阅上。 - 服务器采样： 服务器按采样间隔读取节点值，并与上次值比较（或检查事件条件）。
- 发布通知： 服务器按发布周期将变化的数据或事件打包成通知，通过
Publish响应发送给客户端。 - 客户端确认： 客户端通过
Publish请求确认已收到通知，维持订阅存活。
关键参数对比：
| 参数 | 作用 | 典型值 |
|---|---|---|
| Sampling Interval | 服务器读取底层数据源的频率 | 100ms - 1000ms |
| Publishing Interval | 服务器向客户端发送通知包的频率 | 200ms - 2000ms |
| Deadband（死区） | 数据变化超过此阈值才触发通知，减少无效传输 | 0.5%（百分比死区）或 0.1（绝对值死区） |
3.3 发布/订阅（PubSub）模式简介
发布/订阅（PubSub）模式是 OPC UA 规范中为应对工业物联网（IIoT）和跨网络数据共享而引入的通信模式。它解耦了数据生产者和消费者，支持一对多、多对多的数据分发，尤其适合云平台对接、边缘计算和异构网络场景。
3.3.1 核心角色
- Publisher（发布者）： 数据源，负责将数据（如变量值、事件）发布到消息中间件或网络，不关心谁在消费。
- Subscriber（订阅者）： 数据消费者，订阅感兴趣的数据集，从消息中间件接收数据，不关心数据来源。
- Message Oriented Middleware（消息中间件）： 可选组件，负责消息的路由、缓存和分发。PubSub 支持无中间件的直接 UDP 多播，也支持有中间件的 MQTT/AMQP 桥接。
3.3.2 两种主要传输方式
| 传输方式 | 协议 | 特点 | 适用场景 |
|---|---|---|---|
| UDP 多播 | UDP（User Datagram Protocol） | 低延迟、无连接、局域网内高效；不保证可靠传输 | 车间级实时数据分发、控制器间同步 |
| Broker 桥接 | MQTT / AMQP | 可靠传输、支持广域网、QoS 等级控制、安全认证 | 云平台数据上送、跨工厂数据集成、移动端监控 |
3.3.3 与订阅模式的关键区别
- 耦合度： 订阅模式是客户端-服务器直接耦合；PubSub 模式通过消息中间件或网络层解耦，发布者和订阅者无需直接建立会话。
- 扩展性： PubSub 天然支持一对多分发，增加订阅者不影响发布者性能；订阅模式中，服务器需为每个客户端维护独立的订阅通道。
- 网络穿越： PubSub 基于 MQTT 等协议可轻松穿越 NAT 和防火墙；订阅模式通常需要 VPN 或反向代理。
- 数据模型： PubSub 使用数据集（DataSet）作为发布单元，一个数据集可包含多个变量，结构由发布者定义。
3.4 三种模式对比总结
| 对比维度 | 请求/响应 | 订阅 + 监控项 | 发布/订阅（PubSub） |
|---|---|---|---|
| 通信方向 | 客户端→服务器 | 服务器→客户端（推送） | 发布者→中间件→订阅者 |
| 实时性 | 低（轮询延迟） | 高（事件驱动） | 中高（取决于传输协议） |
| 网络负载 | 高（频繁请求） | 低（仅变化时传输） | 低（批量发布） |
| 耦合度 | 强耦合 | 强耦合 | 完全解耦 |
| 跨网络能力 | 弱（需 VPN） | 弱（需 VPN） | 强（MQTT 桥接） |
| 典型应用 | 配置、诊断、浏览 | 实时数据采集、报警 | 云平台对接、跨系统集成 |
工程选型建议： 在工业网关部署中，建议采用混合策略——使用请求/响应模式完成初始配置和地址空间浏览，使用订阅模式采集高频实时数据，使用 PubSub 模式将数据上送至云端或跨车间共享。三种模式并非互斥，而是互补的通信工具箱。