3. OPC UA基础回顾：协议栈、地址空间与节点模型、客户端/服务器架构、发布/订阅模式
各位工程师朋友，咱们今天来聊聊OPC UA的基础。说实话，很多搞工业自动化的兄弟，一听到OPC UA就觉得头大，觉得这是IT那边的事。但我个人觉得，想要把PROFINET和OPC UA玩转，这块基础必须得打牢。你想想看，如果连地址空间和节点模型都搞不清楚，后面做互联互通的时候，你连数据从哪来到哪去都摸不着头脑。
3.1 OPC UA协议栈：不只是个通信管道
OPC UA的协议栈，说白了就是一套通信的规矩。但它跟传统的工业协议不太一样。我记得刚开始接触OPC UA时，总觉得它太复杂，为什么不能像Modbus那样简单粗暴？后来在项目中吃了亏才明白——OPC UA的协议栈是分层设计的，每一层都有它的道理。
协议栈主要分这么几层：
- 传输层：支持TCP、HTTPS、UDP等多种方式。嗯，这里要注意，OPC UA不挑食，什么网络环境都能适应。
- 安全层：包括加密、签名、认证。我在一个汽车厂的项目中，客户死活要求必须用X.509证书认证，当时觉得麻烦，后来想想，没有这层安全，谁敢把生产数据往上层传？
- 会话层：管理客户端和服务器的连接状态。说白了就是握手和挥手的那套流程。
- 应用层：这才是我们真正关心的——数据怎么组织、怎么读写、怎么订阅。
避坑指南：我曾经在一个项目中，直接用OPC UA的裸TCP连接，结果防火墙把端口给封了。后来改用HTTPS（443端口），问题迎刃而解。所以，部署前一定要搞清楚现场的网络策略。
3.2 地址空间与节点模型：OPC UA的灵魂
地址空间，这是OPC UA最牛的地方。你想想看，传统的工业协议，比如PROFINET，数据就是一串字节，你得知道第几个字节代表什么。但OPC UA不一样，它把所有的数据都组织成一个节点，每个节点都有唯一的ID，节点之间还有关系。
节点模型的核心概念：
- 节点(Node)：最小的信息单元。每个节点都有一个NodeId，就像人的身份证号。
- 引用(Reference)：节点之间的关系。比如一个"电机"节点，可以引用"转速"节点和"温度"节点。
- 对象(Object)：代表现实世界中的实体。比如一个变频器、一个传感器。
- 变量(Variable)：代表数值。比如当前转速、温度值。
- 方法(Method)：代表可执行的操作。比如启动电机、复位报警。
我个人的习惯是，把地址空间想象成一棵大树。根节点是"Objects"，下面挂各种设备。每个设备下面挂变量和方法。这样找数据就像在文件系统里找文件一样直观。
小技巧：在UA Expert（OPC UA的调试工具）里，你可以直接浏览地址空间。我建议新手先拿这个工具练手，把节点树的结构摸清楚，比看十遍文档都管用。
3.3 客户端/服务器架构：一问一答的模式
这是OPC UA最经典的通信模式。客户端发起请求，服务器响应。就像你去问路，你问一句，对方答一句。
典型的交互流程：
- 发现：客户端找到服务器。通过Discovery Endpoint，客户端可以知道服务器上有哪些可用的服务。
- 建立连接：客户端和服务器握手，协商安全策略。这里要特别注意，证书必须配好，否则连不上。
- 浏览地址空间：客户端问服务器"你有什么数据？"，服务器把节点树返回给客户端。
- 读写数据：客户端说"我要读变量X的值"，服务器返回数值。
- 订阅数据：客户端说"变量X变了就通知我"，服务器定期推送变化。
我在一个水处理项目中，用了客户端/服务器模式来采集PLC数据。当时遇到一个问题：客户端每隔100ms轮询一次，结果服务器CPU飙到90%。后来改成订阅模式，服务器只在数据变化时才推送，CPU直接降到20%。所以，能用订阅就别用轮询，这是血的教训。
注意：客户端/服务器模式有一个天然缺陷——单点故障。如果服务器挂了，所有客户端都连不上。所以关键场合，一定要考虑冗余方案。
3.4 发布/订阅模式：从拉数据到推数据
发布/订阅模式，简称PubSub。这是OPC UA UA后来加上的功能，说白了就是从"你问我答"变成了"我主动告诉你"。
为什么需要PubSub？你想想看，在PROFINET这种实时网络中，数据是周期性交换的。如果用客户端/服务器模式，每个设备都要去轮询，网络负载会很大。PubSub模式下，发布者只管发，订阅者只管收，中间通过一个消息中间件（比如MQTT、AMQP）来解耦。
PubSub的核心角色：
- 发布者(Publisher)：产生数据的一方。比如一个PLC，它周期性地发布当前的生产数据。
- 订阅者(Subscriber)：消费数据的一方。比如一个MES系统，它接收PLC发布的数据。
- 消息中间件(Message Broker)：负责转发消息。它不关心数据内容，只负责把数据从发布者送到订阅者手里。
我记得在一个大型物流项目中，现场有50多台PLC，每台PLC都要把数据发给3个不同的上位机系统。如果用客户端/服务器模式，每台PLC要维护150个连接（50台PLC × 3个系统），网络开销巨大。后来改成PubSub模式，PLC只管往MQTT Broker上发数据，上位机系统自己去订阅，网络负载直接降了80%。
关键区别：客户端/服务器是点对点的，PubSub是一对多的。在需要大规模数据分发时，PubSub是更好的选择。
3.5 两种模式的对比与选择
| 特性 | 客户端/服务器 | 发布/订阅 |
|---|---|---|
| 通信方式 | 请求-响应 | 推送-接收 |
| 实时性 | 取决于轮询频率 | 取决于发布频率 |
| 网络负载 | 高（频繁轮询） | 低（数据变化才发） |
| 可靠性 | 高（直接连接） | 中（依赖Broker） |
| 适用场景 | 少量客户端、实时交互 | 大量订阅者、数据分发 |
怎么选？我个人建议：
- 如果你只有1-2个上位机系统，数据量不大，用客户端/服务器模式，简单直接。
- 如果你有多个系统需要同一份数据，或者数据量很大，用PubSub模式，省带宽、省CPU。
- 如果你需要实时控制（比如PROFINET的等时同步），那还是老老实实用PROFINET，OPC UA的实时性目前还比不上。
实战建议：在实际项目中，我经常把两种模式混着用。比如，用客户端/服务器模式做配置和诊断，用PubSub模式做数据采集。这样既保证了交互的实时性，又降低了数据采集的网络负载。
好了，OPC UA的基础就回顾到这里。下一章，咱们要开始动真格的了——把OPC UA和PROFINET连起来。到时候你会发现，今天讲的这些基础，每一个都会用到。