3.3 通信模式与服务

3.3 通信模式与服务

本节摘要：OPC UA 客户端取数有两条路——主动读写与订阅推送。本节把会话、读写、订阅三件套推演完整，重点讲清订阅的四个参数如何决定"数据到达的及时性"与"网络开销"之间的平衡，以及事件订阅与数据订阅的分工。

两种取数方式的分野

把第 2 章的轮询与这里的订阅放在一起看，会发现在"数据怎么到达消费方"这个问题上，两套协议给出了截然不同的答案。Modbus 只有轮询一条路：主站定时问，从站定时答，问多勤数据就多新。OPC UA 则提供两种模式：读写服务让客户端主动取，与轮询同构；订阅服务让服务器在数据变化时主动推——**客户端注册一次兴趣，之后的数据流自动上门。**这不是简单的新增功能，它改变了系统的力学结构：轮询的负担随点位数线性增长，订阅的负担主要随"变化频率"增长。安静产线上千个点位用订阅可能比轮询一百个点还轻松。

本节先讲读写与会话的关系，再拆订阅的完整机制，最后给事件订阅留出篇幅——它是告警与审计场景的正确工具，却常被误用数据订阅来凑合。

学习目标

阅读完本节，你应当能够：

1. 判断一个采集需求该用读写还是订阅；
2. 说出订阅四个核心参数的含义与调优方向；
3. 解释心跳与队列在订阅机制里防什么问题；
4. 区分数据订阅与事件订阅的适用场景。

一、会话语境下的读写服务

读写服务本身很简单：客户端递上一串 NodeId，服务器回一串数据值（写则反向）。有意思的是它的两个工程细节。

细节一，批量是免费的午餐。一次读写请求可以携带成百上千个节点，服务器内部并行取数后一次返回。对比 Modbus"一次事务一段连续寄存器"的限制，UA 的批量可以跨越地址空间的任意角落——一帧里同时读一号泵的转速与二号池的液位毫无障碍。采集程序的常规写法就是每周期一批读写，点位再多也就几帧。

细节二，写有权限与类型双重闸。服务器先查客户端在这个节点上的写权限（安全层的角色授权），再查写入值是否符合类型与量程（建模层的约束），两关都过才落值。第 2 章里"写错区域被异常码拒绝"的拙朴防御，在这里升级成了细粒度的体系。也正因为有权限体系，写操作失败的报错要分层看：权限拒绝、类型不符、量程越界、节点不存在，各有各的错误码，排错时先看错误类别再动手。

二、订阅机制完整推演

订阅的建立过程：客户端创建一个订阅对象，约定发布间隔（服务器多久汇总推送一次）；然后在订阅里创建若干监视项，每个监视项绑定一个变量节点，并约定采样间隔（服务器多久读一次该变量的真实值）与队列长度（变化了但还没推送的值最多缓存几个）。此后服务器自动干活：采样发现值变了，放进队列；发布间隔到点，把队列里的变化打包推送。

四个参数各自决定一件事，合在一起决定了系统的性格：

死区值得单独说：给监视项设一个死区阈值，变化小于阈值视为没变，不进队列。液位测量总有毫米级的抖动，没有死区的订阅会被噪声淹没——十个百分点的"变化"里九个是白噪声。经验值：把死区设为工艺上有意义的动作粒度（比如百分之一量程），数据既干净又不失真。

心跳防的是另一类问题：变量长期无变化时，客户端怎么区分"数据没变"与"链路死了"。订阅心跳定期推送"我还活着"的空包，客户端超过若干个心跳没收到任何包就判定链路异常。监控系统的告警逻辑里必须有这条——否则链路断了两小时，屏幕上的老数据一动不动，操作员还以为生产太平无事。

图12 订阅推送全链路：从采样到多客户端交付

三、事件订阅：告警的正确打开方式

数据订阅回答"值变成了多少"，事件订阅回答"发生了什么"。设备故障、模式切换、操作审计，这些事件的本质不是某个变量的值，而是带时间戳、来源、严重级别、消息文本的结构化通知。服务器在地址空间里维护事件通告器，客户端订阅的是"某对象及其子孙的事件"，条件触发时收到完整的事件对象。

用数据订阅轮询一个"故障标志位"来凑合实现告警，是这个场景最常见的反模式：标志位只在两次采样之间闪一下的话，你就永远错过了它；事件机制没有这个问题——事件在发生的那一刻入队，哪怕你一分钟后再收。另外事件天然带上下文（来源、级别、时间、附加字段），写告警记录时不用再回查设备。原则一句话：状态用数据订阅，过程用事件订阅。

⚠️ 常见坑：把所有点位的发布间隔都设成最小值，以为"越快越好"。订阅的负担在服务器侧是每个监视项的采样与排队，几百个点位全部高频率，低配网关先倒下。按工艺重要性分级配置：控制相关秒级，一般监测十秒级，统计类分钟级。

四、订阅调优的一个完整算例

把四个参数放进具体场景算一遍，体会它们怎么协同。场景：一台网关要向 MES 推送三十台电机的转速，MES 的画面每两秒刷新一次，工艺上转速的"有意义变化"是每分钟转五十转。

参数推演：画面两秒一刷，发布间隔取两秒——推得再快画面也用不上；采样间隔取一秒——比发布快一倍，既能发现变化又不过度采样；死区取五十转——五十转以内的波动对工艺无意义，属于噪声；队列长度取三——最坏情况下两个发布周期内的变化都能兜住。算下来，服务器每两秒为三十个监视项做一次推送决策，负载轻到可以忽略。对照反面案例：曾见项目把发布间隔与采样间隔都压到一百毫秒、死区留零，同一台网关 CPU 占用翻了一倍多，数据质量反而更差——噪声全量推送把 MES 的存储与人工告警都淹了。订阅调优的全部诀窍，就是让每个参数对齐一个真实的消费需求。

还有一个工程细节：订阅总数与发布间隔的乘积要写进设计文档并留三成余量——现场扩容时最先超的往往不是带宽，而是服务器的事件队列；余量就是为"临时加几百个点"这类需求预备的。评审时把这行乘积当红线查，比事后调优便宜得多。另外，事件订阅与数据订阅别混在同一个订阅组里：告警要低延迟、数据可批量，分开管理才能各自调优，出了问题也互不牵连。

本节要点回顾

• 两条取数路径：读写批量主动取适合周期采集，订阅推送适合变化驱动，按数据性格选择；
• 四参数定性格：发布间隔管节奏、采样间隔管分辨率、队列管抗突发、死区管噪声，分级配置是正解；
• 心跳是活性的凭证：无心跳的静默分不清"没变化"与"链路断"，告警逻辑必须依赖心跳判定；
• 状态与过程分家：数据订阅盯值，事件订阅盯事，用标志位轮询凑合告警是反模式。

机理都齐了，下一节动手干活：为你的设备从零建一个像样的信息模型。