3.4 信息建模实战

3.4 信息建模实战

本节摘要：以一台进水泵为对象，从需求梳理到实例发布完成一次完整建模：定义泵类型、约束变量语义、挂上方法与事件、发布实例并用客户端验收。全流程走完，3.2 的节点体系就从概念变成手艺。

任务书

任务背景是这样的：你的边缘网关下面挂着一台进水泵（经 Modbus 采集转速、温度、状态三个量，可下发启停与复位命令），上游的 MES 要求以 OPC UA 形式接入，并且明确提出三条要求——变量必须带工程单位与量程、必须有统一的设备状态枚举、故障要能以事件形式推送。这个任务书本质上是在要求你把一台"寄存器设备"升格为一个"语义设备"，是第 4 章网关集成的最小预演。

建模工具不限：商用建模器、开源的节点集编辑器，甚至手写节点集文档都可以，概念流程完全一致。本节按"设计、定义、实例化、验收"四步走，重点讲每一步的决策依据，操作细节以你手头工具的文档为准。

学习目标

阅读完本节，你应当能够：

1. 把设备接入需求翻译成类型定义清单；
2. 决定变量的类型、单位、量程、访问级别四要素；
3. 区分"该建模的"与"不该建模的"，避免过度设计；
4. 用客户端完成模型验收，逐项核对需求书。

一、第一步：设计类型定义

先画类型，再谈实例——顺序不能反。直接给设备手工挂变量（不定义类型）当然也能跑，但第二台泵上线时你要把全部工作重做一遍，而且两台泵的结构可能微妙地不一致。类型定义的产出物是一张清单：

进水泵类型 PumpType 设计清单（派生自标准设备类型 BaseDeviceType）

组件一 变量组
  ActualSpeed   实际转速   浮点   单位转每分   量程 0 到 3000   只读
  WindingTemp   绕组温度   浮点   单位摄氏度   量程 -20 到 150  只读
  RunStatus     运行状态   枚举   停止 运行 故障 保养          只读
  StartStopCmd  启停命令   枚举   停止 启动                        读写
  SpeedSetpoint 转速设定   浮点   单位转每分   量程 0 到 3000   读写

组件二 方法
  RemoteReset 远程复位   输入无   返回 布尔

组件三 事件
  PumpAlarmEvent 故障事件   来源类型 PumpType
  字段：严重级别 故障码 消息文本 时间戳
​

这份清单里有三处决策值得展开。**其一，状态用枚举而不是裸整数。**Modbus 那边寄存器里的 1、2、3 到了 UA 侧应该升格为带名字的枚举——停止、运行、故障——上游系统不再需要一份"1 是什么意思"的对照表。**其二，命令与反馈分开建点。**启停命令是读写变量，实际状态是只读枚举，两者语义不同、权限不同，合并成一个"状态"节点是常见的新手错误，后果是 MES 对着状态节点下发命令被权限拒绝。**其三，量程就是防线。**转速设定 0 到 3000 的量程写在类型里，上游传 30000 时服务器在入口直接拒绝，而不是写进设备后再看现场出什么乱子。

同时克制一下：**不是知道的都要建模。**设备的固件版本、累计运行小时这类信息，若上游明确不用，就不建。每个节点都有维护成本——权限要配、订阅要管、变更要审。模型的第一版宁可小而准，跑通后再按需扩。

二、第二步与第三步：定义与实例化

定义阶段在你的建模工具里把清单落成节点集。无论用哪种工具，产出的节点集文档里都包含这几样东西：类型声明（PumpType 及其组件）、变量类型与数据类型的引用、单位的编码、方法的参数定义。下面截取节点集文档的骨架示意（有删节，字段以规范为准）：

<!-- 节点集文档骨架示意（非完整可运行文档） -->
<NamespaceUris>
  <Uri>urn:demo:waterworks:pumps</Uri>
</NamespaceUris>
<UAObject NodeId="ns=2;s=PumpType" BrowseName="2:PumpType">
  <!-- HasSubtype 引用挂到标准设备类型之下 -->
</UAObject>
<UAVariable NodeId="ns=2;s=PumpType.ActualSpeed" DataType="Double"
            ParentNodeId="ns=2;s=PumpType">
  <!-- 工程单位 转每分 -->
  <!-- 工程量程 下限0 上限3000 -->
  <!-- AccessLevel 只读 -->
</UAVariable>
<UAObject NodeId="ns=2;s=Pump01" BrowseName="2:进水泵01"
          TypeDefinition="ns=2;s=PumpType">
  <!-- 实例：类型派生 自动继承全部组件结构 -->
</UAObject>
​

实例化阶段把类型变成活对象：为 1 号泵创建实例节点，绑定类型，把每个变量接到数据来源——转速与温度接到网关内部的 Modbus 采集缓存（地址在点表里），状态枚举由网关把寄存器原始值映射成枚举成员，命令变量的写动作注册回调，收到写入后翻译成对应的 Modbus 写寄存器操作。这一步正是"语义注入"的实现现场：字节变语义的翻译逻辑全部集中在实例绑定层，第 4 章的网关无非是把这一层做成可配置的批量产品。

图13 从类型定义到实例发布的建模流水线

三、验收：让机器替你检查

验收的核心思想是用客户端的行为验证模型的语义，而不是用眼睛看树长得对不对。三组动作照着做：浏览检查结构与命名空间归属；行为检查往转速设定里写越界值，应收到量程拒绝的报错，写合理值则设备侧真实动作；事件检查人为制造一次故障（把温度量程上限临时调低即可触发），订阅端应在一秒内收到带故障码与时间戳的事件。三组全过，模型才算成立。

新手最常见的验收失败是第二组：写命令总能成功，越界也照单全收——说明建模时量程没写或访问级别配成了可写。这类问题在验收阶段暴露是幸运的，它的可怕之处在于静默进入生产：MES 误写一个值，现场设备真动作，安全性问题直接上桌。量程与权限是模型的刹车系统，验收就是试刹车。

⚠️ 常见坑：把网关自动生成的"树形点表"当成信息建模完成。变量挂了树、名字改成了中文，但没类型、没单位、没量程——上游系统依旧需要一份人工对照表才能干活，语义注入并没有发生。判断标准很简单：把点表文档藏起来，看上游系统还能不能正确消费数据。

四、建模答疑

**问：设备类型应该从哪个标准类型派生？**有行业配套模型的优先从行业模型派生（下游客户端可能按行业模板渲染）；没有的，从基础设备类型派生，至少保证"设备对象"的身份被客户端认出。自己凭空造根类型是下策——你的类型对任何客户端都是陌生词。

**问：一个模型建多少节点算合适？**没有绝对数，但有判断式：模型里的每个节点都应能回答"谁消费它、什么频率、要不要权限控制"三个问题之一，回答不了的节点先删。典型的一台单机设备（如本节的泵）模型节点数在十五到三十个之间，超过就要警惕垃圾桶对象或过度嵌套（3.2 的两个反模式）卷土重来。

本节要点回顾

• 先类型后实例：类型定义让第二台设备零成本接入，手工挂点是建模的头号反模式；
• 四要素配齐：每个变量都要有类型、单位、量程、访问级别，缺一项就缺一道防线；
• 命令与反馈分立：语义不同的变量不合并，权限体系才能各就各位；
• 验收试刹车：越界写入必须被拒、事件必须可达，用客户端行为而非肉眼核对模型。

到这里，单台设备的语义化完成了。下一章把镜头拉远：成片设备、真实产线，网关与映射才是主战场。