把 OPC UA 接入 Azure IoT Edge / OPC Publisher

开始之前

• 一个运行在网关上、既能访问 OPC UA 服务器又能访问云端的 IoT Edge 运行时。
• 一个 published-nodes 配置文件，列出要订阅的端点和节点 id。
• 一份计划：发布方的证书将如何在它所对接的每一台服务器上获得信任。拖慢部署的是这一部分，而不是容器。
• 网关的出站网络。从 publisher 的角度看，OPC UA 一侧只有入站，这正是它适合分层网络的原因。

配置方法

1. 编写 published-nodes 文件每个端点一条记录，各自带有节点 id 列表、发布间隔和采样间隔以及可选的死区。在语法允许的地方把命名空间 URI 写进节点 id 中，而不要用原始索引，这样 PLC 下载就不会悄悄中断采集。
2. 部署模块作为 IoT Edge 模块部署，附带配置文件，并为其 PKI 目录挂载持久卷。该卷不是可选项：参见常见坑。
3. 在每台服务器上信任 publisher首次连接时，publisher 的证书会落入每台服务器的拒绝库。需要管理员在每台服务器上把它移到信任库。在整个设备群上请为此预留实际工时，或者先部署一套证书管理方案。
4. 有意识地选择编码publisher 可以输出可逆或不可逆 JSON。不可逆 JSON 更小、更易读，但丢弃类型信息且无法往返还原。要在下游消费方按它开发之前做出决定。
5. 验证到达的内容在 IoT Hub 中检查消息，确认状态码和 SourceTimestamp 得以保留。在 JSON 编码中 Good 状态是 0 且会被完全省略，因此缺少状态字段意味着 Good 而不是数据缺失：下游代码必须在知道这一点的前提下编写。
6. 先调优再扩展把发布间隔设成云端消费者所需要的值，而不是 PLC 能给出的最快值，对模拟量应用死区，并保持不同间隔的数量尽量少。每一个不同的间隔都会在服务器上变成又一个订阅。

地址空间是什么样子

publisher 不做任何建模：它只转发你列出的节点。语义仍留在你放置它的地方，实际上这意味着要么节点 id 按约定携带含义，要么由下游某处重新附加含义。如果机器实现了伴随规范，除非你把该结构编码进主题或标签命名，否则这一结构会丢失。

陷阱

• 非持久的 PKI 卷会在每次容器重启时重新生成应用证书，于是每次部署后每台服务器的信任列表都会失效。这是 OPC Publisher 部署中最常见的单一故障。
• 文档明确指出，让设备接受发布方的证书是大多数 OT 管理员面临的最大障碍。把它当作一项有责任人的项目任务，而不是一个配置细节。
• 非可逆 JSON 会静默丢失类型信息。下游消费者无法区分 Int32 和 Double，而一旦有人做算术运算，这就要紧了。
• reverse connect 仅支持 opc.tcp，publisher 会在一个可配置的端口上监听。在只允许出站的 Purdue 分层网络中很有用。
• published-nodes 文件中硬编码的命名空间索引会在 PLC 程序下载后失效。在节点 id 语法支持的情况下请使用命名空间 URI。

从中获取 OEE 数据

只要设备暴露了可用率、计数和原因，它们都能上云，但 publisher 只转发数值，不做解释。状态机迁移以数值变化的形式到达，因此时长计算发生在下游，并取决于你的发布间隔：10 秒的间隔无法分辨 3 秒的微停机。停机原因应订阅 Part 9 的 condition 事件，而不是轮询原因寄存器。计划生产时间和订单上下文不在设备里，这里也不会出现。

最后核对日期 2026 年 9 月 7 日，对照 OPC UA 1.05.07。OPC UA Connect 是教育资源，与 OPC Foundation 无隶属关系。