第三章：信息模型——类型系统、对象类型、变量类型、引用类型
好，咱们进入信息模型这一章。说实话，这是OPC UA里最核心、也最容易被忽视的部分。很多人觉得OPC UA就是个通信协议，能传数据就行。但真正用过的人都知道，信息模型才是OPC UA的灵魂。
我刚开始接触OPC UA时，也犯过这个错误。当时做一个设备监控项目，我直接把所有数据点平铺开，用最简单的变量节点去传。结果项目做到一半，客户要求增加设备层级关系，还要区分不同类型的传感器。我那个数据结构，改起来简直要命。后来我才明白，信息模型设计得好不好，直接决定了系统的扩展性和维护成本。
3.1 类型系统：一切节点的“模板”
OPC UA的类型系统，说白了就是一套“模板”。你想想看，现实世界里的设备，比如一个电机，它有转速、温度、电流这些属性。如果每个电机都单独定义一遍，那太累了。类型系统就是让你先定义好“电机”这个模板，然后所有电机都按这个模板来实例化。
类型系统里主要有三种类型：
- 对象类型（ObjectType）：描述“东西”的模板，比如设备、控制器、传感器。
- 变量类型（VariableType）：描述“数据”的模板，比如温度、压力、转速。
- 引用类型（ReferenceType）：描述“关系”的模板，比如“包含”、“连接”、“输入”。
这三种类型构成了OPC UA信息模型的骨架。你设计的每一个节点，本质上都是某个类型的实例。
核心要点：类型系统是分层的，支持继承。你可以定义一个“通用设备”类型，再派生出“电机”、“泵”、“阀门”等子类型。子类型会继承父类型的所有属性和方法。
3.2 对象类型：描述“东西”的模板
对象类型是最常用的。我习惯把对象类型理解成面向对象编程里的“类”。你定义一个“温度传感器”对象类型，它包含：
- 变量：当前温度、量程上限、量程下限
- 方法：校准、复位
- 子对象：安装位置、维护记录
然后你现场有100个温度传感器，每个都是这个类型的实例。它们共享相同的结构，但各自的数据不同。
举个例子，定义一个简单的“电机”对象类型：
// 伪代码，描述对象类型的结构
ObjectType: MotorType
- Variable: Speed (Double)
- Variable: Temperature (Double)
- Variable: Current (Double)
- Method: Start()
- Method: Stop()
- Object: MaintenanceRecord (MaintenanceRecordType)我在项目中遇到过一个问题：客户要求所有设备都必须有“设备ID”和“设备名称”这两个属性。如果每个对象类型都单独加，太容易遗漏了。我的做法是定义一个“基设备类型”，把公共属性放进去，然后所有设备类型都继承它。这样改一处，所有设备都生效。
我的建议：设计对象类型时，先想清楚哪些是公共属性，哪些是特有属性。公共属性放到基类型里，特有属性放到子类型里。这样后期维护会轻松很多。
3.3 变量类型：描述“数据”的模板
变量类型比对象类型简单一些，但它同样重要。变量类型定义了数据的“元信息”，比如：
- 数据类型（Int32、Double、String等）
- 数据范围（最小值、最大值）
- 工程单位（摄氏度、帕斯卡、转/分钟）
- 访问级别（读、写、可订阅）
为什么要用变量类型？直接定义变量不行吗？
嗯，这里要注意。如果你只是传一个“温度”值，确实可以直接定义变量。但如果你有100个温度点，每个温度点都需要相同的工程单位和范围，那用变量类型就方便多了。你定义一个“TemperatureVariableType”，设置好工程单位为“摄氏度”，量程为“-40到150”，然后所有温度变量都引用这个类型。以后要改量程，改一处就行。
我记得有一次做制药厂的项目，客户要求所有温度数据都必须带“校准日期”和“校准有效期”这两个属性。如果每个温度变量单独加，那工作量太大了。我直接在“TemperatureVariableType”里加了这两个属性，所有温度变量自动就有了。这就是变量类型的威力。
| 变量类型属性 | 说明 | 示例 |
|---|---|---|
| DataType | 数据类型 | Double, Int32, String |
| ValueRank | 值的维度（标量、数组） | -1（标量）, 1（一维数组） |
| ArrayDimensions | 数组各维度大小 | [10], [3, 4] |
| AccessLevel | 访问权限 | CurrentRead, CurrentWrite |
| MinimumSamplingInterval | 最小采样间隔 | 100（毫秒） |
3.4 引用类型：描述“关系”的模板
引用类型可能是最容易被忽略的，但它恰恰是信息模型的“粘合剂”。没有引用类型，你的节点就是一堆孤立的点，无法形成有意义的网络结构。
引用类型定义了节点之间的关系。常见的引用类型有：
- Organizes：组织关系，比如“车间”包含“设备”
- HasComponent：组成关系，比如“电机”包含“转速传感器”
- HasProperty：属性关系，比如“温度传感器”有“量程”属性
- HasTypeDefinition：类型定义关系，指向节点的类型
你想想看，如果没有引用类型，你怎么表达“这个温度传感器属于那个电机”？你只能靠命名规则，比如“Motor1_Temperature”。但这样太脆弱了，一旦改名就全乱了。有了引用类型，你可以直接建立“HasComponent”关系，从电机指向温度传感器。这样不管名字怎么变，关系始终存在。
我曾经在一个项目中，客户要求展示设备的“电气连接关系”。比如“变频器A”连接到“电机B”。我自定义了一个“HasElectricalConnection”引用类型，然后在两个节点之间建立引用。这样客户端就可以通过遍历引用来生成电气拓扑图。如果只用变量名，根本做不到这一点。
避坑指南：我曾经犯过一个错误，就是滥用引用类型。把所有关系都用“Organizes”来表达，结果导致信息模型混乱不堪。后来我学乖了，每种关系都用专门的引用类型。比如“包含”用HasComponent，“连接”用HasConnection，“输入”用HasInput。这样模型清晰多了。
3.5 类型系统的继承与复用
OPC UA的类型系统支持单继承。这意味着你可以构建一个类型层次结构，从最抽象的基类型到最具体的子类型。
举个例子：
BaseObjectType
└── DeviceType
├── MotorType
│ ├── ACMotorType
│ └── DCMotorType
├── PumpType
└── ValveType在这个层次结构中，ACMotorType继承了MotorType的所有属性和方法，MotorType又继承了DeviceType的所有属性和方法。如果你在DeviceType里加一个“设备ID”属性，所有设备类型都会自动拥有这个属性。
这种继承机制，说白了就是让你“少写代码”。我在设计大型系统时，通常会先花一天时间设计类型层次结构。虽然前期投入大，但后期维护成本会大幅降低。
我的经验：类型层次不要超过4层。太深了反而不好维护。一般2到3层就够用了。基类型放公共属性，中间层放分类属性，叶子层放特有属性。
3.6 实战：设计一个简单的信息模型
咱们来实战一下。假设你要为一个工厂设计信息模型，工厂里有车间，车间里有设备，设备有传感器。
第一步，定义对象类型：
- FactoryType：工厂，包含车间列表
- WorkshopType：车间，包含设备列表
- EquipmentType：设备，包含传感器列表
- SensorType：传感器，包含测量值
第二步，定义变量类型：
- TemperatureVariableType：温度变量，工程单位“摄氏度”
- PressureVariableType：压力变量，工程单位“帕斯卡”
- SpeedVariableType：转速变量，工程单位“转/分钟”
第三步，定义引用类型：
- HasWorkshop：工厂包含车间
- HasEquipment：车间包含设备
- HasSensor：设备包含传感器
然后实例化：
- 创建“Factory1”节点，类型为FactoryType
- 创建“Workshop1”节点，类型为WorkshopType，通过HasWorkshop引用连接到Factory1
- 创建“Motor1”节点，类型为MotorType，通过HasEquipment引用连接到Workshop1
- 创建“TempSensor1”节点，类型为SensorType，通过HasSensor引用连接到Motor1
- 创建“Temperature1”变量，类型为TemperatureVariableType，作为TempSensor1的子节点
这样，一个完整的信息模型就建好了。客户端可以通过遍历引用来导航整个工厂结构，从工厂到车间，从车间到设备，从设备到传感器，再到具体的测量值。
嗯，这就是信息模型的魅力。它不只是传数据，它是在描述你的整个系统。设计得好，系统就清晰、可扩展、易维护。设计得不好，后面全是坑。
我个人习惯是，在写任何代码之前，先用纸笔画一下信息模型的结构。把对象类型、变量类型、引用类型都列出来，确认关系正确了再动手。这个习惯帮我避免了很多返工。