2. OPC UA基础回顾：协议栈架构、地址空间与节点模型、服务集与通信模式

好，咱们正式开始第二讲。在聊OPC UA和MQTT融合之前，我觉得有必要先把OPC UA的老底翻一翻。你想想看，如果连基础都不扎实，后面谈融合方案就容易飘。我个人习惯是，每接触一个新协议，先把它拆成三块看：骨架（架构）、血肉（模型）、动作（服务）。OPC UA也不例外。

2.1 OPC UA协议栈架构——从底层到应用

OPC UA的协议栈，说白了就是一套分层设计的通信骨架。它不像传统OPC那样依赖COM/DCOM，而是从零开始构建的。我当年第一次接触OPC UA时，最直观的感受就是：这玩意儿终于不依赖Windows注册表了，跨平台部署舒服多了。

整个协议栈从下往上，大致可以分为这几层：

• 传输层：支持TCP、HTTPS、UDP等多种通道。默认走UA TCP二进制协议，效率最高。
• 安全层：包括会话加密、消息签名、证书管理。嗯，这里要注意，OPC UA的安全模型是强制性的，不像某些协议可以裸奔。
• 协议层：定义了消息的序列化格式（二进制或XML）以及如何交换消息。
• 服务层：这是核心，定义了客户端和服务器之间能做什么操作——读、写、订阅、调用方法等等。
• 应用层：最上层，面向具体的业务逻辑，比如你写一个上位机程序去读PLC的数据。

2.2 地址空间与节点模型——数据怎么组织

地址空间，是OPC UA最让我佩服的设计之一。它把所有的数据、对象、方法、类型都抽象成了节点（Node），然后用引用（Reference）把这些节点串起来，形成一个巨大的信息网络。

你可以把地址空间想象成一个文件系统：

• 根节点是“Objects”文件夹
• 下面有设备、变量、方法等子文件夹
• 每个文件夹（节点）都有自己的属性（比如名称、描述、数据类型）

节点模型有8种基本类型，我挑几个重点说：

节点类型	说明	我见过的坑
Object	代表物理或逻辑对象，比如一台电机、一个PID控制器	对象嵌套太深，导致浏览效率低
Variable	代表数值，比如温度、压力、转速	变量属性（比如工程单位）没配全，上位机解析出错
Method	代表可调用的函数，比如“复位报警”	方法输入参数定义不清晰，调用时总报错
View	地址空间的子集视图，用于简化浏览	视图定义太随意，反而增加了维护成本

2.3 服务集与通信模式——Client/Server vs PubSub

OPC UA的服务集，就是它提供的一系列“动作”。你可以通过调用这些服务，去操作地址空间里的节点。常用的服务集包括：

• 发现服务集：客户端怎么找到服务器？说白了就是“你在哪？”
• 会话服务集：建立和关闭通信会话。相当于“握手”和“再见”。
• 节点管理服务集：增删改查地址空间里的节点。这个在动态建模时很有用。
• 查询服务集：按条件搜索节点。比如“找出所有温度大于100度的变量”。
• 订阅/监控服务集：这是最常用的。客户端订阅某个变量，值一变就收到通知。

通信模式这块，咱们重点说两种：

2.3.1 Client/Server模式

这是最经典的模式。客户端主动发起请求，服务器响应。就像你去食堂打饭——你点菜（请求），师傅给你打（响应）。

优点：实时性好，双向通信，安全机制完善。

缺点：客户端和服务器必须同时在线，点对点通信，不适合大规模数据分发。

我在一个工厂MES项目中，用了Client/Server模式连接了30多台设备。一开始还行，后来设备增加到100台，服务器压力就上来了。嗯，这时候就该考虑PubSub了。

2.3.2 PubSub模式

PubSub是OPC UA后来加入的“大招”。它把数据发布者和订阅者解耦，通过一个中间件（比如MQTT Broker）来传递消息。

说白了就是：发布者只管发，订阅者只管收，两边不用认识。

优点：一对多、多对多，扩展性好，适合边缘到云端的数据传输。

缺点：实时性不如Client/Server，需要额外的Broker组件。

2.4 小结

回顾一下，OPC UA的协议栈是分层设计的，地址空间用节点和引用组织数据，服务集提供了丰富的操作接口，而通信模式则根据场景灵活选择。我个人觉得，理解这些基础，是后面玩转融合通信的前提。你想想看，如果连节点模型都搞不清楚，怎么把OPC UA的数据映射到MQTT的Topic上？

下一章，咱们就正式进入MQTT的世界，看看这个轻量级协议到底有什么魔力，能和OPC UA擦出火花。

---

公众号:蓝海资料掘金营，微信deep3321