2. OPC UA核心概念精讲
OPC UA 与早期 OPC Classic 最大的差别，不在于“换了一个协议”，而在于它把设备信息组织成了一套可浏览、可寻址、可扩展的信息模型。要真正读懂一台 OPC UA 服务器暴露了什么，必须先理解地址空间、节点、引用、属性、变量、方法、事件和类型系统这八个概念之间的关系。它们不是并列的八个名词，而是一套从“容器”到“内容”再到“语义”的层次结构。
地址空间：服务器的信息地图
地址空间（Address Space）是 OPC UA 服务器对外暴露的全部信息集合，可以把它理解成一张有向图：图中的顶点是节点，边是引用。客户端通过 Browse 服务从某个起点节点出发，沿着引用逐层展开，就能“走遍”整台设备的信息。地址空间不是文件目录树，因为一个节点可以被多个父节点引用，形成网状而非严格的树状结构。
地址空间的根是 Root 文件夹，其下通常挂三个关键入口：Objects（对象实例，如设备、通道、变量）、Types（类型定义，如对象类型、变量类型）、Views（视图，用于按需裁剪子集）。工程上最常浏览的是 Objects，因为真实设备的温度、转速、状态都作为对象和变量实例挂在这里。
节点与节点类别
节点（Node）是地址空间的基本单元，每个节点由 NodeId 唯一标识。NodeId 由命名空间索引（NamespaceIndex）和标识符（Identifier）组成，标识符可以是数值、字符串、GUID 或字节串。例如 ns=2;s=Machine1.Temperature 表示命名空间 2 下、字符串标识为 Machine1.Temperature 的节点。命名空间索引用于隔离不同厂商或不同信息模型的标识符，避免冲突。
节点按语义分为八类：对象（Object）、变量（Variable）、方法（Method）、对象类型（ObjectType）、变量类型（VariableType）、引用类型（ReferenceType）、数据类型（DataType）、视图（View）。其中对象、变量、方法属于“实例侧”，类型节点属于“类型侧”，引用类型和数据类型是支撑语义的元模型。
引用：节点之间的语义连接
引用（Reference）定义了节点之间的有向关系，并带有引用类型。最常用的引用类型是 Organizes（组织关系，类似文件夹包含）、HasComponent（组合关系，表示整体与部件）、HasProperty（属性关系）、HasTypeDefinition（实例指向其类型定义）。引用是双向的：A 通过 HasComponent 指向 B，则 B 必然有一条反向引用指回 A。客户端浏览时正是靠这些引用判断“这个变量属于哪台设备”。
属性：节点的元数据
每个节点都有一组标准属性，用来描述节点自身，而不是节点所代表的工艺量。核心属性包括：NodeId、BrowseName（浏览名，用于人机识别）、DisplayName（显示名）、Description、NodeClass、WriteMask、UserWriteMask。变量节点还额外拥有 Value、DataType、ValueRank、AccessLevel、Historizing 等属性。属性通过 HasProperty 引用挂接，读取属性用 Read 服务，读取 Value 同样用 Read，但语义不同：前者读元数据，后者读实时数据。
变量、方法与事件
变量（Variable）是承载数据的节点，其 Value 属性就是客户端真正关心的过程值。变量可以是标量，也可以是数组（由 ValueRank 描述维度）。方法（Method）是可被客户端调用的节点，通过 Call 服务执行，可带输入参数和输出参数，常用于“下发配方”“触发标定”等动作。事件（Event）不是节点，而是服务器在特定条件下向客户端推送的通知，客户端通过订阅（Subscription）和监控项（MonitoredItem）接收，事件类型由事件类型节点定义，如 BaseEventType 及其子类型。
类型系统：让语义可复用
类型系统是 OPC UA 信息模型可扩展的关键。对象类型（ObjectType）定义一类对象应有哪些组件、属性和方法；变量类型（VariableType）定义变量的数据类型和语义。实例通过 HasTypeDefinition 引用指向其类型。例如定义一个 MotorType，包含 Speed 变量、Start 方法、Running 属性；现场三台电机都作为该类型的实例，只需各自维护 NodeId 和实时值，结构语义由类型统一保证。这正是“建模一次、实例多处”的工程价值。
从概念到工程：一次典型浏览与读取
假设现场有一台电机，服务器地址空间中的路径为 Objects → Machine1 → Temperature。客户端先用 Browse 从 Objects 出发，沿 Organizes 找到 Machine1，再沿 HasComponent 找到 Temperature 变量节点，同时读取其 BrowseName、DataType、AccessLevel 等属性，确认它是 Double 类型、可读。随后客户端用 Read 服务读取该节点的 Value 属性，得到实时温度。若该变量配置了 Historizing，还可通过 HistoryRead 读取历史值。整个过程不依赖任何私有约定，完全由标准节点、引用和属性驱动，这正是 OPC UA 互操作性的根基。
| 概念 | 本质 | 工程关注点 |
|---|---|---|
| 地址空间 | 节点与引用的有向图 | 浏览起点、命名空间划分 |
| 节点 | 由 NodeId 唯一标识的实体 | NodeId 稳定性、命名空间索引 |
| 引用 | 带类型的有向语义连接 | HasComponent / HasTypeDefinition 方向 |
| 属性 | 描述节点自身的元数据 | DataType、AccessLevel、Historizing |
| 变量 | 承载 Value 的数据节点 | ValueRank、采样周期、死区 |
| 方法 | 可被 Call 调用的节点 | 输入输出参数、权限 |
| 事件 | 服务器推送的通知 | 事件类型、订阅与监控项 |
| 类型系统 | 实例的模板与语义约束 | 自定义类型、类型继承 |
把这八个概念放在一起看，OPC UA 的信息模型就清晰了：地址空间提供容器，节点提供寻址，引用提供语义连接，属性提供自描述，变量、方法和事件提供数据、动作与通知，类型系统提供复用与约束。后续无论是做设备建模、客户端采集还是服务器开发，都是在这套骨架之上展开。