2、OPC UA核心概念：地址空间、节点、对象、变量、方法、事件
好，咱们进入正题。这一节要聊的是OPC UA的「骨架」——核心概念。
说实话，很多初学者一上来就被这些术语搞懵了。地址空间？节点？对象？感觉像在学面向对象编程，但又不太一样。我当年第一次接触时也绕了好一阵子。
其实你想想看，OPC UA要解决什么问题？就是让不同厂家的设备能互相理解。那怎么理解？得有一套统一的「语言」和「语法」。这些核心概念，就是这套语言的基本单元。
2.1 地址空间：一切信息的「大本营」
地址空间，说白了就是OPC UA服务器里所有数据的「总目录」。你可以把它想象成一个巨大的文件柜，里面分门别类地放着各种信息。
我个人习惯把地址空间比作「信息宇宙」。服务器里能访问到的所有东西——温度值、电机转速、报警记录、设备参数——都住在这个空间里。没有地址空间，客户端连该问谁都不知道。
关键点：地址空间是分层的树状结构。根节点在最上面，下面挂着一堆子节点。这种结构的好处是——扩展性强，你随时可以在任意位置挂新的节点。
我在一个汽车焊装车间项目里遇到过这种情况：客户想把机器人控制器的内部状态全部暴露出来。传统方式得改协议、改驱动，折腾死人。但用OPC UA，直接在地址空间里新建一个分支，把状态变量挂上去就完事了。前后不到半天。
2.2 节点：地址空间的「砖块」
地址空间由什么组成？节点。每个节点就是一块「砖」，所有信息都封装在节点里。
节点长什么样？它有几个基本属性：
- NodeId：节点的身份证，全局唯一。客户端找节点就靠它。
- BrowseName：浏览时显示的名字，方便人看。
- DisplayName：展示用的名称，可以本地化。
- Description：描述信息，告诉你这个节点是干嘛的。
嗯，这里要注意：NodeId是机器读的，BrowseName是人看的。千万别搞混。我见过有人把BrowseName当NodeId用，结果客户端连不上，排查了半天。
2.3 对象：现实设备的「数字分身」
对象节点，是OPC UA里最常用的节点类型之一。它用来表示现实世界中的「东西」——一台电机、一个传感器、一条生产线。
对象可以嵌套。比如一个「机器人」对象，下面可以挂「关节1」、「关节2」等子对象。每个子对象又有自己的属性和方法。这种建模方式，跟面向对象编程里的「类」和「实例」很像。
我的经验：建模时别贪多。我刚开始做项目时，恨不得把每个螺丝钉都建模成对象。结果地址空间膨胀得厉害，客户端浏览都卡。后来学乖了——只建模对业务有用的东西。
2.4 变量：数据的「载体」
变量节点，用来存放实际的数据值。温度、压力、速度、状态码……这些都是变量。
变量有几个关键属性：
| 属性 | 说明 | 示例 |
|---|---|---|
| Value | 实际的数据值 | 25.3（温度值） |
| DataType | 数据类型 | Float、Int32、String |
| AccessLevel | 读写权限 | 只读、读写 |
| MinimumSamplingInterval | 最小采样间隔 | 100ms |
变量还分两种：属性变量和数据变量。属性变量是节点自带的元数据，比如Description；数据变量才是你真正关心的业务数据。
我曾经踩过一个坑：在给变量赋值时，忘了设置DataType。结果客户端读到的数据全是乱码。后来我养成了习惯——每个变量创建时，第一件事就是指定DataType。
2.5 方法：可执行的「动作」
方法节点，代表一个可调用的操作。比如「启动电机」、「复位报警」、「切换模式」。
方法有输入参数和输出参数。调用方法时，客户端传输入参数，服务器执行操作，返回输出参数。
注意：方法是同步执行的。如果操作耗时较长（比如启动一个大型电机），客户端会一直等待。我建议把耗时操作设计成异步模式——方法只负责下发指令，真正的执行结果通过事件或变量变化来反馈。
举个实际例子：在半导体车间的项目中，我们需要远程校准一个温度传感器。校准过程要30秒。如果直接用同步方法，客户端界面会卡死。后来我们改成：方法只触发校准指令，校准进度通过一个变量来更新，客户端订阅这个变量就行。
2.6 事件：主动的「通知」
事件节点，是OPC UA里最「主动」的概念。变量和方法都是客户端主动去读、去调。但事件是服务器主动推给客户端的。
什么时候用事件？报警、故障、状态变化、操作记录……这些需要及时通知的场景。
事件包含一组字段：
- EventType：事件类型，比如AlarmEvent、SystemEvent
- SourceNode：事件来源节点
- Time：事件发生时间
- Message：事件描述信息
- Severity：严重等级（1-1000）
我建议把事件设计得「少而精」。别什么鸡毛蒜皮的事都发事件。我在一个水处理项目里，客户要求每5秒发一次状态事件。结果服务器CPU飙到90%，网络也堵了。后来我们把周期事件改成变量订阅，只有状态变化时才发事件，问题就解决了。
2.7 它们怎么配合？
这些概念不是孤立的。它们一起构成了OPC UA的信息模型：
- 对象作为容器，组织现实世界的实体
- 变量挂在对象下面，存放数据
- 方法挂在对象下面，提供操作
- 事件由对象或变量触发，通知客户端
- 所有这一切都放在地址空间里，通过节点来访问
说白了，这就是一套「万物皆节点」的哲学。你只要理解了节点，就理解了OPC UA的一半。
总结一下：地址空间是地图，节点是地标，对象是建筑，变量是建筑里的仪表盘，方法是建筑里的开关，事件是建筑里的警报器。把这套逻辑理清了，后面学信息模型、配套规范就轻松多了。
下一节，咱们聊聊OPC UA的通信模型——客户端怎么找到服务器，怎么建立连接，怎么交换数据。这些是实战中绕不开的硬骨头。