2. OPC UA核心概念：地址空间、节点、对象、变量、方法
好，咱们进入正题。上一章聊了OPC UA的诞生背景和整体架构，这一章咱们得把袖子撸起来，看看OPC UA肚子里到底装了什么货。
地址空间、节点、对象、变量、方法——这几个词你肯定听过。但说实话，我见过不少工程师，干了三五年OPC UA项目，对这些概念的理解还是模模糊糊的。嗯，这其实挺危险的。因为如果你不理解地址空间，你连服务器里有什么数据都找不到。
2.1 地址空间：OPC UA的“数据宇宙”
地址空间是什么？说白了，它就是OPC UA服务器里所有数据的“大本营”。
你可以把它想象成一个巨大的文件系统。Windows有C盘、D盘，文件夹套文件夹。OPC UA的地址空间也是类似的层级结构，只不过它不存文件，它存的是“节点”。
为什么叫“地址空间”而不是“数据表”？
我刚开始接触OPC UA时也有这个疑问。后来做项目多了才明白：因为数据不是平铺的，是有结构的。一个电机，它有转速、温度、电流，这些数据之间是有关系的。地址空间就是用来表达这种关系的。
地址空间有几个关键特征：
- 分层结构：根节点在最上面，下面挂着一层一层的子节点。就像你电脑里的文件夹。
- 全局唯一：每个节点都有一个唯一的NodeId，就像身份证号。你拿着这个ID，就能精准定位到任何一个数据点。
- 类型与实例分离：这是OPC UA的精髓。你可以先定义一个“电机类型”，然后创建无数个具体的电机实例。每个实例都继承类型的结构，但数据各自独立。
核心要点：地址空间不是一张表，而是一棵树。树上的每个“果子”都是一个节点。
2.2 节点：地址空间的基本单元
节点是地址空间里最小的组成单位。你可以把它理解成数据库里的一条记录，或者面向对象里的一个对象。
每个节点都包含一组属性：
| 属性 | 说明 | 我的经验 |
|---|---|---|
| NodeId | 节点的唯一标识 | 建议用数字型NodeId，字符串型在大量节点时性能会下降 |
| BrowseName | 浏览时显示的名称 | 命名要规范，我见过用中文命名的，客户端兼容性很差 |
| DisplayName | 展示给用户看的名称 | 可以跟BrowseName不同，用于本地化 |
| NodeClass | 节点类型（对象、变量、方法等） | 这个最重要，决定了节点能干什么 |
节点之间通过“引用”连接。引用就像文件夹之间的快捷方式，让节点可以形成复杂的网络结构。
避坑指南：我曾经在一个项目中，把所有数据都塞在一个层级下，没有做任何分类。结果客户端浏览时，几千个节点挤在一起，找数据跟大海捞针一样。后来我花了三天重新组织地址空间结构，才把问题解决。记住：好的地址空间设计，是OPC UA项目成功的一半。
2.3 对象：现实世界的数字化映射
对象节点，说白了就是“东西”。一台电机是一个对象，一个传感器是一个对象，一条生产线也是一个对象。
对象节点本身不存数据，它是个“容器”。它里面装着变量（数据）、方法（操作）、还有子对象。
举个例子：
// 一个电机对象的地址空间结构（伪代码）
对象: Motor_001
├── 变量: Speed (当前转速)
├── 变量: Temperature (当前温度)
├── 变量: Status (运行状态)
├── 方法: Start() (启动电机)
├── 方法: Stop() (停止电机)
└── 对象: Encoder (编码器子对象)
└── 变量: Position (位置值)你看，一个电机对象，把它的所有数据、操作、子部件都组织在了一起。这就是面向对象思想在工业自动化里的体现。
对象类型 vs 对象实例
我记得第一次做OPC UA建模时，我直接创建了100个电机对象，每个都手动添加变量和方法。累得半死。后来才发现，应该先定义一个“MotorType”对象类型，然后从这个类型创建实例。类型定义一次，实例可以创建无数个，每个实例的数据是独立的。
核心要点：对象是容器，变量是数据，方法是操作。三者配合，才能完整描述一个工业设备。
2.4 变量：真正承载数据的地方
变量节点是地址空间里最常用的节点。它承载着实际的数据值。
变量有几个关键属性：
- Value：当前值。可以是整数、浮点数、字符串、布尔值，甚至结构体。
- DataType：数据类型。OPC UA有内置类型，也支持自定义类型。
- AccessLevel：访问权限。可读、可写、可订阅等。
- MinimumSamplingInterval：最小采样间隔。这个很重要，决定了服务器多久更新一次数据。
变量的两种类型
你想想看，有些变量是“属性”，比如电机的额定功率，它基本不变。有些变量是“数据”，比如电机的当前转速，它每时每刻都在变。
OPC UA把变量分成了两种：
- Property（属性变量）：描述对象的特征，一般不变化或变化很慢。
- DataVariable（数据变量）：承载实时数据，变化频繁。
注意：我曾经遇到一个坑——把频繁变化的数据定义成了Property。结果客户端订阅时，发现数据更新延迟严重。因为Property的采样间隔默认是0，服务器会尽量缓存。而DataVariable的采样间隔可以精确控制。所以，实时数据一定要用DataVariable。
2.5 方法：让客户端能“操作”设备
方法节点，就是OPC UA里的“函数”。客户端可以调用它，让服务器执行某个操作。
比如：启动电机、复位报警、切换配方。这些操作都可以封装成方法。
方法的特点：
- 有输入参数：调用时传入，比如启动电机的转速目标值。
- 有输出参数：调用后返回，比如操作是否成功、错误码。
- 可执行：客户端通过Call服务调用方法。
- 有副作用：方法执行会改变服务器状态，不像读变量那样只是获取数据。
方法 vs 写变量
有人会问：我直接写变量不也能控制设备吗？比如把“StartCommand”变量写成1，电机就启动了。
嗯，这里要注意。写变量是“数据驱动”，方法调用是“操作驱动”。
用方法的好处是：
- 可以校验参数合法性。比如启动电机时，转速不能超过额定值。
- 可以返回执行结果。写变量你没法知道操作是否成功。
- 可以执行复杂逻辑。比如启动电机前先检查安全门是否关闭。
我的建议：凡是涉及设备控制的操作，尽量用方法。写变量只适合设置参数，不适合执行动作。我在一个项目中，客户坚持用写变量来控制设备，结果出了好几次误操作。后来改成方法调用，问题就解决了。
2.6 实战：用Python浏览地址空间
光说不练假把式。咱们用Python的opcua库，看看怎么浏览地址空间里的节点。
from opcua import Client
# 连接到OPC UA服务器
client = Client("opc.tcp://localhost:4840")
client.connect()
try:
# 获取根节点
root = client.get_root_node()
print(f"根节点: {root}")
# 浏览子节点
children = root.get_children()
for child in children:
print(f"子节点: {child}")
print(f" BrowseName: {child.get_browse_name()}")
print(f" NodeClass: {child.get_node_class()}")
# 如果是变量节点，读取值
if child.get_node_class() == NodeClass.Variable:
value = child.get_value()
print(f" 当前值: {value}")
# 如果是对象节点，继续浏览
if child.get_node_class() == NodeClass.Object:
sub_children = child.get_children()
for sub in sub_children:
print(f" 子节点: {sub}")
finally:
client.disconnect()这段代码很简单，但能让你直观地看到地址空间的层级结构。你运行一下，就能看到根节点下面挂着一堆对象、变量、方法。
为什么先学这个？
因为后面讲订阅机制时，你需要知道订阅什么。订阅的不是“数据”，而是“节点”。你订阅一个变量节点，当它的值变化时，服务器会通知你。你订阅一个对象节点，当它的子节点发生变化时，你也能收到通知。
所以，理解地址空间的结构，是理解订阅机制的前提。你想想看，如果你连数据在哪都不知道，怎么订阅？
本章总结：地址空间是OPC UA的数据骨架，节点是骨架上的关节，对象是容器，变量是数据，方法是操作。这五个概念，是OPC UA的基石。下一章，咱们就基于这些概念，深入订阅机制的核心。