OPC UA 通讯专题
工业4.0和IIoT的通用互操作语言。本专题把零散的教程和软件按 「认知 → 地址空间 → 安全 → 通讯模式 → 开发 → 工程化」 串成一条可照着走的路径，不堆标准文档，只讲现场真正用得上的部分。
一条路径走完 OPC UA（六个阶段）
- 01
先建立整体认知：OPC UA 是什么、为什么它是工业4.0的通用语言
OPC UA 不是又一个"Modbus 替代品"，它是一套面向服务的工业互操作架构。先搞清楚它和 OPC DA 的本质区别、在工业4.0/IIoT 中的定位，后面的概念才学得进去。
- OPC DA 是 Windows 专属、基于 COM/DCOM 的老标准，跨平台和安全是硬伤；OPC UA 是跨平台、面向服务的新架构
- OPC UA 不只是"读数据"，它定义了完整的信息模型：数据、报警、方法、历史、程序，都可以标准化表达
- OPC UA 是工业4.0参考架构（RAMI 4.0）和 IIoT 的核心互操作标准，主流 PLC/SCADA/MES 都已原生支持
- 02
核心概念：地址空间、节点、引用与信息模型
OPC UA 最反直觉的地方是：它不是"寄存器地址+值"的扁平模型，而是一个由节点和引用组成的层次化地址空间。理解了节点和引用，就理解了 OPC UA 的一切。
- 地址空间 = 节点(Node) + 引用(Reference) 的有向图，节点有8种类型：对象、变量、方法、对象类型、变量类型、引用类型、数据类型、视图
- 每个节点有唯一的 NodeId（命名空间+标识符），BrowseName 是浏览名，DisplayName 是显示名，三者不要混淆
- 信息模型(Information Model) 是 OPC UA 的灵魂：Companion Specification（如 PLCopen、ADI、MDIS）为特定行业定义了标准节点层次
- 浏览(Browse) 是 OPC UA 的核心操作：从根节点开始，沿引用关系遍历整个地址空间，发现有哪些节点可读
相关软件： UaExpert - 03
安全机制：认证、加密、证书与安全策略（最容易卡住的部分）
OPC UA 的安全设计是它相比 Modbus 的最大优势，但也是新手最容易卡住的地方。"连不上"90% 是证书和安全策略配置问题。搞清楚信任链、安全策略和用户认证，调试效率提升十倍。
- 三层安全：传输层加密(Sign&Encrypt) + 应用层认证(证书/用户名) + 用户授权(角色权限)
- 安全策略三档：None(无加密)、Sign(仅签名)、Sign&Encrypt(签名+加密)，生产环境必须用 Sign&Encrypt
- 证书信任链：客户端和服务器各有自己的证书(自签名或CA签发)，首次连接时证书进入对方的"Rejected"目录，手动移到"Trusted"才建立信任
- 用户认证：匿名、用户名密码、X.509证书、Kerberos/Active Directory 四种方式，企业环境常用 Windows 集成认证
- 04
通讯模式：订阅、方法调用、历史数据与报警事件
OPC UA 不只是"读一个变量的值"。订阅(Subscription) 是它的核心通讯模式——服务器主动推送变化，而不是客户端轮询。还有方法调用、历史数据、报警事件等高级服务，这些才是 OPC UA 的价值所在。
- 订阅(Subscription) + 监控项(MonitoredItem)：客户端订阅一组节点，服务器按采样间隔检测变化，按发布间隔批量推送，比轮询高效得多
- 方法调用(Method Call)：服务器可以暴露可调用的方法（如"启动电机""校准传感器"），客户端传参数调用并获取返回值，这是 RPC 在工业场景的标准化
- 历史数据(Historical Access)：OPC UA 定义了标准的历史数据读取接口，客户端可以按时间范围查询历史趋势，不需要每个厂商自己搞一套
- 报警与条件(Alarms & Conditions)：标准的报警模型，包括报警状态机、确认/消除、订阅报警事件，SCADA/MES 可以统一处理不同厂商的报警
- 05
实战开发：用开源 SDK 搭建 OPC UA 客户端和服务器
理解了概念之后，动手写代码是最快的学习方式。开源 SDK 已经非常成熟：C 语言用 open62541，Java 用 Eclipse Milo，Python 用 asyncua。从连接服务器、浏览地址空间、订阅变量开始，逐步到方法调用和自建服务器。
- C/C++ 首选 open62541：纯 C 实现，开源免费，可运行在嵌入式/Linux/Windows，API 简洁，文档和示例丰富
- Java 首选 Eclipse Milo：Eclipse 基金会项目，Java 生态首选，客户端/服务器都支持，和 Spring Boot 集成方便
- Python 首选 asyncua（原 python-opcua）：异步架构，适合快速原型和脚本，AI/数据分析场景用 Python 对接 OPC UA 很方便
- 开发顺序建议：先用 UaExpert 连接目标服务器验证地址空间 → 写客户端读变量 → 加订阅 → 调方法 → 最后自建服务器
- 06
工程化落地：架构选型、网关部署与性能优化
从"能连上"到"生产环境稳定跑"，要回答几个工程问题：哪些设备直连 OPC UA、哪些用网关转换、服务器部署在哪、性能能不能扛住、安全怎么加固。这是一线工程师最有价值的经验部分。
- 架构选择：新设备原生支持 OPC UA 就直连；老旧设备只有 Modbus/串口时，用 OPC UA 网关（如 KEPServerEX、Neuron、ThingsGateway）做协议转换，上层统一按 OPC UA 采集
- 部署位置：OPC UA 服务器可以跑在 PLC 里、独立工控机上、或边缘网关上；采集点位多、协议杂时建议用独立网关服务器，减轻 PLC 负载
- 性能优化：用订阅代替轮询、按变化快慢分订阅组、合理设置采样间隔和发布间隔、大数量节点分批订阅、监控服务器 CPU/内存和网络带宽
- 安全加固：关闭匿名访问、强制 Sign&Encrypt、用 CA 签发证书代替自签名、按角色配置最小权限、把 OPC UA 网络放在隔离区、通过 VPN/专线远程访问
边学边用：数据解析在线工具
OPC UA 相关软件选型（按用途分组）
OPC UA 常见问题
OPC UA 和 OPC DA 有什么区别？老项目需要迁移吗？
OPC DA 是 1996 年推出的老标准，基于 Windows COM/DCOM，只能在 Windows 上运行，没有内置安全机制，跨网段和跨平台配置 DCOM 非常痛苦。OPC UA 是 2008 年推出的新一代标准，跨平台（Windows/Linux/嵌入式）、面向服务架构、内置安全（加密+认证）、支持信息模型。老项目如果运行稳定可以不迁移，但新项目强烈建议直接用 OPC UA；需要跨平台、远程访问、安全加固的场景，迁移收益很大。可以用 OPC UA 网关做 DA→UA 转换，上层统一按 UA 采集，逐步迁移。
OPC UA 的地址空间到底是什么？和 Modbus 的寄存器地址有什么不同？
Modbus 是扁平模型：每个数据点就是一个寄存器地址（如 40001），客户端需要事先知道地址映射表。OPC UA 是层次化的图模型：地址空间由节点(Node)和引用(Reference)组成，节点有类型（对象、变量、方法等）、属性（名称、数据类型、访问权限等），引用定义了节点之间的关系（包含、继承、关联等）。客户端可以通过 Browse 操作动态发现服务器有哪些节点，不需要事先知道地址表。这就像 Modbus 是"按编号取快递"，OPC UA 是"走进一个有目录和索引的图书馆，可以逐层浏览找到想要的书"。
OPC UA 连不上，90% 是证书问题，怎么快速排查？
OPC UA 连接失败最常见的原因就是证书信任问题，按这个顺序排查：① 先确认服务器和客户端的 IP/端口能通（telnet 或 curl 测试）；② 检查安全策略是否匹配（客户端选的 Sign&Encrypt，服务器也要支持）；③ 查看服务器的 Rejected 证书目录，客户端首次连接时证书会被放到这里，需要手动移到 Trusted 目录；④ 检查证书的有效期和 Subject Alternative Name（SAN），证书里的域名/IP 必须和实际访问地址一致；⑤ 用 UaExpert 先测试连接，UaExpert 会给出详细的错误信息，比自己代码调试快得多。生产环境建议用内部 CA 统一签发证书，不要用自签名证书。
OPC UA 的订阅(Subscription)和轮询(Polling)有什么区别？什么时候用哪个？
轮询是客户端定时向服务器发"读这个变量"的请求，不管值有没有变化都要读一次，网络开销大，实时性取决于轮询周期。订阅是客户端告诉服务器"我关心这几个变量，变化了通知我"，服务器在内部按采样间隔检测变化，按发布间隔把变化批量推送给客户端。订阅的优势是：网络流量小（只传变化的数据）、实时性好（变化后最快一个采样间隔就推送）、服务器负载低。几乎所有 OPC UA 场景都应该用订阅而不是轮询。只有在极少数不支持订阅的老旧服务器、或需要精确控制读取时刻的场景下才用轮询。
应该自己用 SDK 开发 OPC UA，还是用商业软件/网关？
取决于场景：① 如果需要把 OPC UA 深度嵌进自有上位机/产品，或者需要定制化的信息模型和方法，用开源 SDK（open62541/Eclipse Milo/asyncua）自己开发，灵活度最高，授权费为零；② 如果只是采集多品牌设备数据、做协议转换、快速落地项目，用商业服务器（KEPServerEX/Matrikon）或开源网关（Neuron/ThingsGateway/Node-RED），配置化对接，开发量小，稳定性有保障；③ 调试阶段无论哪种方案，都建议先用 UaExpert 验证服务器侧的地址空间和安全配置。自己开发的学习成本主要在信息模型和安全配置，SDK 本身的 API 并不复杂。
OPC UA、Modbus、MQTT 到底怎么选？三者能配合用吗？
三者定位不同，不是互斥关系，经常配合使用：① Modbus 是现场设备层最通用的协议，成本低、设备支持广，但功能简单、无安全，适合现场设备通讯；② OPC UA 是车间/工厂层的互操作标准，功能丰富（数据/报警/方法/历史）、安全可靠、信息模型标准化，适合 SCADA/MES/上位机与设备/系统之间的标准化对接；③ MQTT 是云/IIoT 层的轻量消息协议，发布订阅模式、带宽小、适合弱网，适合设备数据上云、跨地域传输。典型架构：现场设备用 Modbus → 边缘网关做 Modbus→OPC UA 转换 → 车间系统用 OPC UA 采集 → 需要上云的数据再用 MQTT 推送。本站有专门的教程对比三者的选型。
OPC UA 性能怎么样？一个服务器能支持多少标签和客户端？
OPC UA 的性能取决于服务器实现、硬件配置和使用方式，差异很大。商业服务器（如 KEPServerEX）经过深度优化，单服务器可支持 10 万+ 标签和数十个并发客户端。开源 SDK（open62541）自建服务器在普通工控机上支持 1 万+ 标签和 10 个左右客户端没有问题。性能优化要点：① 用订阅代替轮询，减少请求次数；② 按变化快慢分订阅组，快变量采样间隔短、慢变量采样间隔长；③ 合理设置发布间隔，不要每个变化都立即推送，批量推送更高效；④ 大数量节点分批订阅，避免单个订阅过大；⑤ 监控服务器的 CPU、内存、网络带宽，标签数特别多时考虑分布式部署或用专门的 OPC UA 服务器产品。
继续往深走
OPC UA 解决「标准化对接」，放到完整系统里，还要回答协议怎么选、数据怎么存、系统怎么分层：