📚 课程目录第3章 OPC UA信息模型

3. OPC UA信息模型

OPC UA 与传统 OPC 最大的区别，在于它不再只是“搬运数值”的通道，而是把设备、参数、状态、事件、方法都组织成一套可被机器理解的信息模型。客户端读到的不是一个孤立的 Item，而是一个带有语义、类型、层级和引用关系的节点网络。理解信息模型，是开发 OPC UA 客户端与服务端的地基。

一、信息模型的作用：让数据具备语义

在经典 OPC DA 中，客户端只能看到形如 Device1.Tag1 的字符串地址，它不知道这个 Tag 是温度还是设定值，也不知道它属于哪台设备、能否写入、单位是什么。OPC UA 通过信息模型解决了这个问题：每个数据点都是一个节点（Node），节点有类型、有属性、有引用，节点之间通过引用连接成层次结构。

信息模型的核心价值体现在三方面：

语义化：变量节点带有 DataType、ValueRank、EngineeringUnits 等属性，客户端无需硬编码即可理解数据含义。
可发现：客户端可以从 Objects 文件夹开始，逐层浏览到任意设备、任意变量，实现自动组态。
可扩展：通过类型定义和实例化，新增设备类型只需定义一次，即可批量生成实例。

信息模型 = 节点 + 属性 + 引用 + 类型系统。客户端浏览的是结构，读写的是属性，调用的是方法，订阅的是变量与事件。

二、建模规则：节点、属性与引用

OPC UA 信息模型由节点构成，每个节点由 NodeId 唯一标识，并拥有若干属性。最常用的节点类别包括：

节点类别	作用	典型属性
Object	表示设备、系统、文件夹等对象	NodeId、BrowseName、DisplayName、EventNotifier
Variable	表示可读写的数据值	Value、DataType、ValueRank、AccessLevel
Method	表示可被客户端调用的操作	Executable、InputArguments、OutputArguments
ObjectType	定义对象的类型模板	IsAbstract、SubtypeOf
VariableType	定义变量的类型模板	DataType、ValueRank
DataType	定义值的数据类型	IsAbstract、SubtypeOf
ReferenceType	定义节点之间的引用语义	IsAbstract、Symmetric

节点之间通过引用连接。最基础的引用是 Organizes、HasComponent、HasProperty、HasSubtype。例如，一个温度变量作为某设备的组件，使用 HasComponent 引用；而它的工程单位作为属性，使用 HasProperty 引用。建模规则要求：类型定义中声明的成员，在实例化时必须按相同 BrowseName 和引用类型出现。

三、类型定义与实例化：从模板到对象

类型定义是信息模型的“类”，实例化是“对象”。以一台电机为例，先定义 MotorType，它继承自 BaseObjectType，包含 Speed、Current、Start 方法等成员。然后在 Objects 下创建 Motor1，其 TypeDefinition 指向 MotorType，并自动获得 Speed、Current 等子节点。

MotorType (ObjectType)
 ├─ HasComponent → Speed (Variable, Double)
 ├─ HasComponent → Current (Variable, Double)
 ├─ HasProperty  → RatedPower (Variable, Double)
 └─ HasComponent → Start (Method)

Motor1 (Object, TypeDefinition = MotorType)
 ├─ Speed   = 1480.0
 ├─ Current = 12.3
 ├─ RatedPower = 7.5
 └─ Start() 可调用

实例化的关键点在于：实例节点可以覆盖类型中定义的默认值，但不能随意删除类型中声明的必选成员。可选成员通过 ModelingRule 标记为 Optional，实例可选择是否创建。这种“类型—实例”分离机制，使得服务端可以用一套代码批量生成成百上千个设备节点。

四、命名空间与节点ID：全局唯一标识

NodeId 是节点的身份证，格式为 ns=命名空间索引;i=标识符。命名空间用于隔离不同厂商、不同标准、不同项目的节点集合。索引 0 保留给 OPC UA 基础规范，索引 1 通常给服务端自定义模型，索引 2 以上可分配给其他配套规范。

ns=0;i=85      → Objects 文件夹（标准节点）
ns=0;i=2253    → Server 对象
ns=1;i=1001    → 自定义 Motor1
ns=2;s=LineA.Motor1.Speed → 字符串标识符

NodeId 的标识符可以是数值、字符串、GUID 或字节串。数值型紧凑高效，字符串型可读性好但占用空间大。服务端设计时应遵循：标准节点用 ns=0，厂商自定义模型用独立命名空间，避免与标准节点冲突。客户端在浏览时，必须同时记录 NodeId 和 BrowseName，因为 BrowseName 只在同一命名空间内唯一，而 NodeId 全局唯一。

命名空间索引是服务端本地分配的，不同服务端的 ns=1 可能指向完全不同的模型。客户端跨服务端通信时，应使用 NamespaceUri 而非索引进行匹配。

五、常见误区与复盘

误区一：把 BrowseName 当唯一标识。BrowseName 只在同一命名空间内唯一，跨命名空间可能重名。客户端缓存节点时应以 NodeId 为主键。

误区二：忽略命名空间索引的动态性。服务端重启或重新配置后，ns=1 可能指向不同模型。跨会话持久化时应保存 NamespaceUri。

误区三：类型定义与实例不一致。实例化时若遗漏必选成员，客户端浏览会报 BadNodeIdUnknown 或结构不完整。建模时应使用建模工具校验。

误区四：滥用字符串 NodeId。字符串标识符可读性好，但大量节点时内存和索引效率下降。高密度数据点建议使用数值型 NodeId。

复盘一个典型场景：某服务端将 5000 个温度点全部放在 ns=1 下，使用字符串 NodeId，客户端浏览耗时超过 8 秒。优化方案是将设备类型抽象为 TemperatureSensorType，实例化时使用数值 NodeId，并按产线划分命名空间，浏览耗时降至 1.2 秒。这说明信息模型的设计质量直接影响客户端性能与可维护性。

掌握信息模型后，客户端开发就不再是“猜地址”，而是“按类型浏览、按引用导航、按属性读写”。服务端开发也不再是“堆变量”，而是“定义类型、批量实例化、分配命名空间”。这是 OPC UA 区别于传统 OPC 的核心能力，也是后续实现地址空间服务、订阅与事件通知的基础。