第四章 OPC UA 信息模型：从基础到实战
好，咱们今天聊聊信息模型。说实话，这是OPC UA里最核心、也最容易被忽视的部分。很多人一上来就急着写代码、连设备，结果地址空间搞得一团糟，后面维护起来想死的心都有。我刚开始接触OPC UA时也犯过这毛病，后来被一个德国老工程师狠狠教育了一顿，才明白信息模型才是真正的灵魂。
4.1 基础信息模型（Base Information Model）
基础信息模型，说白了就是OPC UA官方给你搭好的骨架。它定义了最基础的数据结构，比如节点（Node）、引用（Reference）、属性（Attribute）这些概念。你想想看，如果没有这个基础，各家厂商各玩各的，那还怎么互联互通？
我个人习惯把基础信息模型理解成「乐高积木的基础块」。它提供了：
- 节点类型：对象节点、变量节点、方法节点、视图节点等
- 引用类型：比如HasComponent、HasProperty、Organizes这些
- 基础属性：NodeId、BrowseName、DisplayName、Description
嗯，这里要注意一点。很多初学者以为NodeId随便起个名字就行。我在项目中遇到过有人用中文拼音当NodeId，结果德国那边的OPC UA客户端直接解析失败。NodeId的命名空间（Namespace）一定要规划好，这是血的教训。
核心原则：基础信息模型是标准化的，不要随意修改。你可以在它上面扩展，但不能破坏它的结构。
4.2 配套规范（Companion Specifications）
配套规范是什么？就是各个行业组织基于基础信息模型，制定的行业标准模型。比如：
| 行业 | 配套规范 | 说明 |
|---|---|---|
| 机器人 | OPC UA for Robotics | 定义了机器人关节、运动控制等模型 |
| 数控机床 | OPC UA for MachineTools | 主轴、刀具、加工状态等 |
| 过程控制 | OPC UA for Process Automation | PID参数、模拟量、数字量等 |
| 能源管理 | OPC UA for Energy | 电能、功率、碳排放等 |
我建议你，如果项目涉及的设备有现成的配套规范，直接拿来用。别自己造轮子。我曾经有个客户非要自己定义机器人模型，结果跟ABB的机器人对接时，光映射就花了三周。后来换成配套规范，一天搞定。
我的经验：去OPC基金会官网下载配套规范PDF，先看它的类型定义和引用关系。看不懂没关系，先照猫画虎。用着用着就明白了。
4.3 自定义信息模型的设计原则
如果配套规范没有覆盖你的场景，那就得自己设计信息模型了。这里我总结了几条铁律：
- 继承优先于组合：能用继承扩展的，别搞复杂的组合关系。比如你有个特殊泵，直接从PumpType继承，别把泵拆成电机+叶轮+壳体再拼起来。
- 命名空间隔离：自定义的类型和实例，一定要用你自己的命名空间。别往OPC UA标准命名空间（0）里塞东西，那是找骂。
- 语义明确：变量名、类型名要让人一看就懂。我见过有人用Var001、Var002这种名字，三个月后他自己都忘了是啥。
- 最小化原则：只暴露必要的数据。别把PLC里所有内部变量都映射上来，地址空间不是垃圾桶。
为什么会这样？因为信息模型一旦发布，客户端就会依赖它。你改一个节点名，可能全厂的系统都要跟着改。所以设计时一定要想清楚。
避坑指南：我曾经设计过一个自定义模型，把设备的所有参数都放在一个对象节点下，结果地址空间里一个节点下面挂了200多个变量。客户端浏览时卡得要死。后来改成按功能分组，用Organizes引用组织成树形结构，问题就解决了。
4.4 如何在地址空间中组织数据
地址空间，就是OPC UA服务器的「文件系统」。怎么组织才合理？我一般按这个思路来：
- 根节点：Objects（对象根）和Types（类型根）是固定的，别动它。
- 设备层：每个物理设备对应一个对象节点，比如"Robot1"、"CNC_Machine_03"。
- 功能层：设备下面按功能分组，比如"MotionControl"、"Diagnostics"、"Safety"。
- 数据层：具体的变量和方法，比如"CurrentPosition"、"EmergencyStop"。
举个例子，一个简单的机器人地址空间结构：
Objects
└── Robot1 (Object)
├── MotionControl (Object)
│ ├── CurrentPosition (Variable)
│ ├── TargetPosition (Variable)
│ └── MoveTo (Method)
├── Diagnostics (Object)
│ ├── Temperature (Variable)
│ └── ErrorCode (Variable)
└── Safety (Object)
├── EmergencyStop (Variable)
└── SafetyStatus (Variable)
你看，这样组织是不是很清晰？客户端浏览时，一眼就能找到想要的数据。我习惯在设备节点上再加一个Manufacturer属性和SerialNumber属性，方便资产管理。
关键点：地址空间的深度不要超过5层。太深了客户端浏览效率低，太浅了又显得杂乱。3-4层是最舒服的。
最后说一句，信息模型设计没有绝对的对错，但一定要有逻辑。你想想看，如果别人接手你的系统，打开地址空间一看，乱七八糟的，那得多崩溃？所以，设计时多花点心思，后面能省十倍的时间。
嗯，这一章就到这里。下一章咱们聊聊如何用代码实现信息模型，包括UA-Modeler工具的使用和代码生成。到时候我会分享一些我踩过的坑，保证实用。