📚 课程目录第4章设备数据映射与地址空间设计

4. 设备数据映射与地址空间设计

OPC UA 集成的核心工作，不是把设备连上网络就结束，而是把设备里真实存在的物理量、可调参数和运行状态，翻译成客户端能够按名字稳定访问的节点。这个过程叫数据映射，它的产物是一棵地址空间树。映射做得好，上位机、SCADA、MES 拿到的数据语义清晰、路径稳定；映射做得随意，后面每加一台设备都要改客户端代码。

先分清三类数据对象

实验设备上的数据可以粗分为三类，它们的映射策略并不相同。

物理量（测量值）：温度、压力、流量、转速、电压、电流等由传感器采集的连续量。它们通常只读，带工程单位，需要关注量程、精度和采样周期。
参数（设定值）：目标温度、PID 的 Kp/Ki/Kd、报警上限、泵的额定转速等。它们可读可写，写入后会影响设备行为，必须考虑权限和写入范围校验。
状态（离散量）：运行/停止、自动/手动、阀门开/关、故障字、就绪位等。它们多为布尔量或枚举量，变化频繁，适合用状态变量或事件表达。

区分这三类的意义在于：物理量决定数据类型和单位，参数决定访问权限和写入约束，状态决定是否需要订阅与事件通知。如果混在一起，客户端就无法判断一个节点到底能不能写。

地址空间的组织原则

OPC UA 的地址空间是一棵以 NodeId 为标识的树，节点之间通过引用（Reference）连接。设计时通常遵循几条原则：

按设备层次组织：从 Objects 文件夹出发，先分车间/工位，再分设备，最后到具体变量。层次反映物理归属，而不是通信链路。
用 BrowseName 表达语义：节点名应能自解释，例如 Reactor1/Temperature/PV，而不是 Tag001。
用 NodeId 保证稳定：NodeId 是客户端真正引用的标识，一旦发布就不应随设备重启或重排而改变。常用字符串型 NodeId，如 ns=2;s=Reactor1.Temperature.PV。
用类型定义复用结构：同类设备应使用相同的 ObjectType，变量挂在类型下，实例只覆盖差异部分。

下面这张图展示了一台实验反应釜从物理对象到 OPC UA 地址空间的映射关系。左侧是设备上的真实测点与执行机构，中间是映射规则，右侧是最终形成的节点树。

从物理量到节点的具体映射

以温度为例，物理侧是 TT101 的 4–20mA 信号，量程 0–200℃。在 OPC UA 侧，它应映射为一个 Float 类型的只读变量，NodeId 为 ns=2;s=Lab1.Reactor1.Temperature.PV，BrowseName 为 2:Temperature.PV。同时应附加两个属性：EngineeringUnits 设为摄氏度，EURange 设为 0–200。这样客户端不需要额外查表就能知道数值含义和有效范围。

压力 PT101 同理，量程 0–1.6MPa，映射为 Pressure.PV，单位 MPa。搅拌电机 M101 的转速反馈是物理量，映射为 Motor1.Speed，单位 rpm；而它的启停命令是参数，映射为 Motor1.RunCmd，AccessLevel 为 ReadWrite。加热器 H101 的功率设定 Heater1.PowerSP 也是读写参数，写入范围 0–100，超出范围应返回 Bad_OutOfRange。

状态类数据要特别注意。控制器状态字通常是一个 16 位字，每一位代表一种状态。直接映射为 UInt16 虽然可行，但客户端需要自己解析位定义。更好的做法是拆成多个 Boolean 变量，如 Status.Running、Status.Fault、Status.Ready，或者使用枚举类型并配合 EnumStrings 属性，让客户端直接显示“运行中”“故障”“就绪”。

地址空间结构设计示例

下面给出一个可直接参考的地址空间结构，适用于单台实验反应釜。它体现了“工位—设备—部件—变量”的四层组织。

Objects
└─ Lab1
   └─ Reactor1  (TypeDefinition: ReactorType)
      ├─ Temperature
      │  ├─ PV   : Float, RO, ℃, 0–200
      │  ├─ SP   : Float, RW, ℃, 0–200
      │  └─ AlarmHi : Float, RW, ℃, 默认 150
      ├─ Pressure
      │  ├─ PV   : Float, RO, MPa, 0–1.6
      │  └─ AlarmHi : Float, RW, MPa, 默认 1.2
      ├─ Motor1
      │  ├─ RunCmd : Boolean, RW
      │  ├─ Running : Boolean, RO
      │  └─ Speed : Float, RO, rpm
      ├─ Heater1
      │  ├─ PowerSP : Float, RW, %, 0–100
      │  └─ PowerPV : Float, RO, %
      ├─ Valve1
      │  ├─ OpenCmd : Boolean, RW
      │  └─ Opened : Boolean, RO
      └─ Status
         ├─ Running : Boolean, RO
         ├─ Fault : Boolean, RO
         └─ Ready : Boolean, RO

这个结构的关键点在于：Reactor1 使用 ReactorType 作为类型定义，所有同类反应釜实例共享同一套变量结构，只是 NodeId 前缀不同。这样新增第二台反应釜时，只需实例化类型并覆盖 NodeId，不需要重新设计节点。

映射过程中容易出错的几个点

NodeId 不要用自动生成的数字。 很多工具默认生成 ns=2;i=1001 这类数字 NodeId，一旦设备重新导入或节点顺序变化，编号就会漂移，客户端全部失效。工程上应坚持使用字符串型 NodeId，把设备名、部件名、变量名编码进去。

读写权限要与物理能力一致。 把只读的测量值误设为 ReadWrite，客户端可能写入无效值；把可写参数误设为只读，则无法下发设定。映射完成后应逐节点核对 AccessLevel。

单位不要只写在文档里。 工程单位应作为 EngineeringUnits 属性挂在变量节点上，量程作为 EURange。这样即使客户端换了人维护，也能从地址空间本身读到正确语义。

映射完成后的检查方法

映射是否成功，不能只看节点能不能被浏览到。建议用以下方式验证：用 UaExpert 或类似客户端连接服务器，展开 Objects/Lab1/Reactor1，确认每个变量的 DataType、AccessLevel、EngineeringUnits 和 EURange 是否正确；对读写变量执行一次写入，观察返回值是否为 Good；对状态变量建立订阅，改变设备状态，确认客户端能在预期时间内收到通知。如果写入返回 Bad_NotWritable，说明 AccessLevel 设置错误；如果订阅收不到变化，说明采样周期或 MonitoredItem 配置有问题。

地址空间设计不是一次性的工作。随着实验设备增加，应把公共结构沉淀为 ObjectType，把命名规则固化为模板，这样每接入一台新设备，映射工作就变成“实例化 + 填参数”，而不是重新设计一棵树。