OPC UA是工业通讯的未来——这句话我信。但OPC UA的“信息模型”这个事，我踩了两年坑才搞明白。

先说一个让我头疼的项目。

一个水处理厂的项目，要上一套OPC UA服务器，把全厂的设备数据统一暴露给上层系统（MES、SCADA、云端）。

设备有：6台PLC（西门子、三菱、汇川都有）、12台仪表（流量计、pH计、浊度仪）、4台变频器、2台软启动器。

我搭了一个OPC UA服务器，把所有的数据点都配了上去。每个设备几十个测点，总共800多个节点。

配完之后，上层系统的开发人员来找我：“你这个节点结构太乱了，我找个数据要翻半天。”

问题出在哪？

我把所有的节点都平铺在了一个层级下：

Objects/ Device1 Temperature Device1Pressure Device1 Flow Device2Temperature Device2_Pressure ... 800多个节点全部平铺，没有任何分组。上层系统想找“1号PLC的温度”，要在800多个节点里翻。

OPC UA信息模型的核心：用“类型”来组织数据

OPC UA跟Modbus最大的区别是：Modbus只有“地址”，OPC UA有“信息模型”。

信息模型的意思是：节点不是孤立的，节点之间有层级关系、有类型定义、有语义。

一个设计良好的OPC UA信息模型应该是这样的：

Objects/ 水处理厂/ 车间1/ PLC1/ 温度 压力 流量 仪表1/ pH值 浊度 车间2/ ... 上层系统找数据的时候，顺着层级往下找就行——水处理厂→车间1→PLC1→温度。

但这只是第一步。 真正的信息模型设计，还要定义“类型”。

类型定义：让数据有“语义”

OPC UA允许你定义自定义类型。比如定义一个“温度传感器类型”： TemperatureSensorType:

• 当前值 (Float)
• 上限 (Float)
• 下限 (Float)
• 单位 (String)
• 状态 (Int)

然后，所有的温度传感器都实例化这个类型。上层系统看到这个节点，就知道它有“当前值”“上限”“下限”“单位”“状态”这五个属性。

不需要看文档，不需要问开发人员。 节点的类型本身就说明了它有什么数据。

这就是“语义化”——数据不仅要有值，还要有含义。

我踩过的三个坑

坑一：把所有数据都放在一个层级。

刚开始的时候，我图省事，把所有节点平铺在Objects下面。结果上层系统找数据要找半天。

改进： 按“工厂→车间→设备→测点”的层级组织节点。层级不要超过5层，太深了也不好找。

坑二：用了自定义类型，但没有文档。

我给温度传感器定义了自定义类型，但忘了写文档。半年后我自己都忘了这个类型里有哪些属性。

改进： 自定义类型必须有文档。每个类型有哪些属性、每个属性的数据类型、每个属性的含义——全部写清楚。

坑三：节点ID用了随机字符串。

OPC UA的节点ID可以是数字、字符串、GUID。我一开始用了GUID——全球唯一，但完全不可读。

上层系统想通过节点ID找数据，看到一堆“ns=2;s=8f3a2b1c-4d5e-6f7a-8b9c-0d1e2f3a4b5c”完全不知道是什么。

改进： 节点ID用“有意义的字符串”。比如“ns=2;s=车间1.PLC1.温度”。可读性好，调试方便。

OPC UA信息模型设计的五条原则

第一，按层级组织。 不要平铺。按工厂→车间→设备→测点的层级组织节点。

第二，用类型定义。 同类型的设备用同一个类型定义。温度传感器用TemperatureSensorType，压力传感器用PressureSensorType。

第三，节点ID用有意义的字符串。 不要用随机GUID。用“设备名.测点名”的格式。

第四，属性的数据类型要明确。 温度是Float还是Double？状态是Int还是Enum？定义清楚，上层系统才知道怎么解析。

第五，写文档。 信息模型设计好之后，写一份文档——每个节点的ID、数据类型、含义、单位。这份文档是OPC UA服务器和上层系统之间的“合同”。

怎么验证信息模型设计是否合理？

用OPC UA客户端工具（比如UaExpert）连上服务器，浏览节点树。看看：

能不能在3层之内找到想要的数据？

节点的名字能不能看懂？

节点的类型定义是不是清晰？

属性的数据类型是不是明确？

如果这些都能做到，信息模型就是合格的。

如果没有真实设备，可以用ProtoForge模拟不同协议的设备，然后用OPC UA网关把这些设备的数据映射成OPC UA节点。在办公室把信息模型设计好、验证好，再到现场部署。

ProtoForge（工业协议仿真平台，17种协议，90+设备模板）： GitHub：suoten/ProtoForge Gitee：suoten/ProtoForge