3、OPC UA通信模型：客户端/服务器架构、发布/订阅模式、通信协议栈
好，咱们今天聊聊OPC UA的通信模型。说实话，很多刚接触OPC UA的朋友，一上来就被各种术语搞晕了——客户端、服务器、发布者、订阅者、协议栈……感觉像是一锅粥。别急，我当年也经历过这个阶段。咱们今天就把这锅粥拆开，看看里面到底放了什么料。
3.1 客户端/服务器架构：最经典的“一问一答”
先说说最基础的客户端/服务器架构。这个模式，说白了就是“你问我答”。
客户端是主动方，它发起请求。比如一个MES系统要读取一台机床的温度，它就向OPC UA服务器发一个“Read”请求。
服务器是被动方，它等着客户端来问。服务器里存着设备的数据模型，比如温度、压力、转速这些变量。客户端问什么，它就答什么。
我在一个汽车焊装车间项目里，就遇到过典型的C/S架构。当时我们要把几十台机器人的状态数据采集上来。每台机器人上都跑着一个OPC UA服务器，上位机系统作为客户端，轮询读取每个机器人的数据。
核心特点：
- 同步通信：客户端发一个请求，必须等服务器回复，才能干下一件事。就像你打电话问朋友“吃饭了吗？”，必须等他回答“吃了”或“没吃”，你才能继续聊。
- 一对多关系：一个服务器可以同时服务多个客户端。但反过来，一个客户端也可以连接多个服务器。
- 安全性高：每次通信都有会话管理和加密机制。我记得有一次客户问“数据会不会被截获？”，我直接告诉他OPC UA的通信是加密签名的，比HTTP强多了。
但C/S架构有个明显的短板——实时性不够。你想想看，如果现场有1000个数据点，客户端每秒轮询一次，那服务器就得每秒处理1000个请求。数据变化越快，轮询频率就得越高，网络和CPU的压力就越大。
我的经验：在数据点少于500个、变化频率不高（比如几秒变一次）的场景下，C/S架构完全够用。但如果你要采集高速振动信号或者伺服电机的实时位置，那就得考虑另一种模式了。
3.2 发布/订阅模式：数据主动“推”给你
发布/订阅模式，简称Pub/Sub。这个模式解决了C/S架构的轮询痛点。
它的核心思想是：数据生产者（发布者）只管发数据，数据消费者（订阅者）只管收数据，中间有个消息代理（Broker）负责转发。
打个比方：你订阅了一个天气预报公众号。气象局（发布者）每天更新天气数据，公众号平台（Broker）把数据推给你（订阅者）。你不需要每天去问“今天天气怎么样？”，数据会自动送上门。
在OPC UA Pub/Sub里，发布者通常是PLC、传感器这些设备。订阅者是MES、SCADA、数据库这些系统。Broker可以是MQTT Broker，也可以是OPC UA自己的中间件。
核心特点：
- 异步通信：发布者只管发，不管谁在收。订阅者只管收，不管谁在发。两者完全解耦。
- 一对多高效分发：一个发布者的数据，可以同时被成千上万个订阅者接收。这在C/S架构下是不可想象的。
- 实时性极强：数据变化了才发，不变化不发。网络带宽利用率极高。
我曾经在一个锂电池涂布项目中，用Pub/Sub模式采集涂布机的张力数据。涂布机的张力传感器每秒变化几百次，如果用C/S轮询，网络早就爆了。换成Pub/Sub后，数据只在张力波动超过阈值时才发送，网络负载直接降了90%。
注意：Pub/Sub虽然好，但有个前提——你的网络基础设施要支持。如果车间里还是老式的工业以太网，延迟和丢包率都高，那Pub/Sub的优势就发挥不出来。我建议至少用千兆工业交换机，最好支持TSN（时间敏感网络）。
3.3 通信协议栈：数据是怎么“跑”起来的？
聊完了两种架构，咱们看看数据到底是怎么从设备传到系统的。这就涉及到OPC UA的通信协议栈。
OPC UA的协议栈分两层：
- 传输层：负责数据怎么打包、怎么传输。
- 应用层：负责数据怎么理解、怎么操作。
咱们先看传输层。OPC UA支持两种传输协议：
| 协议 | 特点 | 适用场景 |
|---|---|---|
| UA TCP | OPC UA自有的二进制协议，效率高，延迟低 | 车间内部局域网，实时性要求高的场景 |
| HTTPS | 基于HTTP/HTTPS，兼容性好，能穿透防火墙 | 跨车间、跨工厂、云端通信 |
我个人习惯，在车间内部用UA TCP，因为它的数据包更小，解析更快。如果数据要传到集团总部或者云平台，那就用HTTPS，毕竟防火墙不会轻易拦截80和443端口。
再看应用层。应用层定义了数据怎么组织、怎么访问。核心是地址空间和服务集。
- 地址空间：就是设备的数据模型。比如一个电机，它的温度、转速、电流都组织成节点，节点之间有层次关系。这就像Windows的文件系统，文件夹套文件夹。
- 服务集：就是客户端能对地址空间做什么操作。比如Read（读）、Write（写）、Browse（浏览）、Subscribe（订阅）等。
举个例子，你要读一个电机的温度：
// 伪代码示例
// 1. 建立会话
Session session = client.createSession();
// 2. 浏览地址空间，找到温度节点
NodeId tempNode = session.browse("Motor1.Temperature");
// 3. 读取温度值
DataValue value = session.read(tempNode);
// 4. 输出结果
Console.WriteLine("当前温度: " + value.Value);
这段代码看着简单，但背后协议栈做了很多事：建立安全通道、加密握手、序列化数据、校验完整性……嗯，这些细节咱们不用深究，你只要知道OPC UA把底层都封装好了，我们直接调API就行。
避坑指南：我曾经遇到一个项目，现场工程师直接用OPC UA的HTTPS协议在车间内网通信，结果发现延迟比UA TCP高了3倍。后来一查，是因为HTTPS每次通信都要做SSL握手，浪费了大量时间。所以，内网用UA TCP，外网用HTTPS，这个原则别搞反了。
3.4 三种模式怎么选？
最后，我给大家一个简单的选择建议：
- 数据点少（<500）、变化慢：用C/S架构，简单直接，开发成本低。
- 数据点多（>1000）、变化快：用Pub/Sub架构，节省带宽，实时性好。
- 跨网络、跨工厂：用HTTPS协议，兼容性好，能过防火墙。
- 车间内部、实时控制：用UA TCP协议，延迟最低，效率最高。
当然，实际项目中往往是混合使用。比如一个智能工厂，底层设备用Pub/Sub采集数据，上层MES用C/S架构做配置管理，云端用HTTPS做数据上传。这都很正常。
好了，这一章的内容就到这里。下一章咱们聊聊OPC UA的信息模型，看看地址空间里到底藏了什么秘密。