OPC UA 的核心突破在于用统一的 AddressSpace 替代了传统 OPC 的接口割裂。信息建模是整个架构的基石——没有正确的节点与引用关系，上层的订阅、读写、方法调用都无从谈起。
AddressSpace 的组织逻辑
AddressSpace 本质上是一个有向无环图（DAG），节点是图的顶点，引用是图的边。OPC UA 规范在 Part 3 中定义了八种核心节点类，其中实际工程建模最常用的是 Object、Variable、Method、DataType 和 ReferenceType。
节点之间通过 Reference 关联，每条引用由 SourceNodeId、TargetNodeId、ReferenceTypeId 三元组定义。HasComponent、HasProperty、Organizes 这三种引用类型构成了绝大多数层级关系。HasComponent 表达包含关系（电机包含轴承子对象），HasProperty 绑定属性（电机对象具备额定功率属性），Organizes 则用于文件夹式的逻辑分组。
+---------------------+
| 1:RootFolder |
| (FolderType) |
+----------+----------+
| Organizes
v
+---------------------+
| 2:ObjectsFolder |
| (FolderType) |
+----------+----------+
| Organizes
v
+---------------------+ HasComponent +---------------------+
| 3:Motor_001 | ----------------------->| 4:Bearing_A |
| (MotorType) | | (BearingType) |
+----------+----------+ +----------+----------+
| HasProperty | HasProperty
v v
+---------------------+ +---------------------+
| 5:RatedPower | | 6:Temperature |
| (Double, kW) | | (Double, °C) |
+---------------------+ +---------------------+图中展示了一个典型的电机对象树。Motor_001 作为 Object 节点，类型为自定义的 MotorType，通过 HasProperty 关联 RatedPower 这个 Variable 节点，通过 HasComponent 嵌入 Bearing_A 子对象。数据类型由 DataType 属性指向的 NodeId 决定——这里是内置的 BaseDataTypes 命名空间下的 Double。
AddressSpace 支持多命名空间隔离。工业服务器通常将标准定义放在 namespace 0，厂商扩展类型放在 namespace 2，运行时实例放在 namespace 3。这种划分避免了不同设备厂商的类型定义冲突，也为 Companion Spec 的扩展机制预留了空间。
Companion Spec 与标准映射
Companion Specification 是 OPC UA 生态最重要的扩展机制。它不修改核心规范，而是针对特定工业领域定义一组相互配合的类型定义和语义约定。截至 2025 年 8 月，OPC Foundation 已发布 40+ 份 Companion Spec，覆盖 ISA-95（企业控制系统集成）、IEC 61131-3（PLC 编程语言）、MTConnect（数控机床互联）、Euromap（塑料机械）等领域。
以 ISA-95 Companion 为例，它定义了 EquipmentClass、PhysicalAssetClass、MaterialClass 等对象类型，分别对应 ISA-95 的设备层级、物理资产层级和物料层级。每个实例化的设备对象必须提供 Identification（标识）、Location（位置）、OperationalState（运行状态）等标准属性，客户端可以统一解析而无需关心设备底层是 PLC 还是 CNC。
Companion Spec | 适用领域 | 核心对象类型 | 数据映射规范 |
ISA-95 | MES-设备集成 | Equipment, Material, ProcessSegment | 层级式对象树，状态枚举对齐 |
IEC 61131-3 | PLC 变量暴露 | POUVariable, FunctionBlock | 直接映射变量名和注释 |
MTConnect | 数控机床 | Device, Component, DataItem | 流式数据项 + 条件事件 |
OPC UA for Robotics | 工业机器人 | Robot, Joint, Tool | 运动学模型 + 关节状态 |
Euromap 77 | 注塑机 | InjectionMouldingMachine | 工艺段状态 + 参数快照 |
Companion Spec 的落地并不强制——很多厂商只实现了核心对象的部分属性。客户端在连接时需要通过 Browse 服务遍历 AddressSpace，检查目标对象是否存在 Companion Spec 要求的标准属性，再决定如何消费数据。这种"尽力而为"的设计在工程上是务实的，但也给语义互操作带来了不确定性。
语义层：从 AddressSpace 到机器可读
AddressSpace 解决了数据结构统一的问题，但语义统一是另一回事。两个不同的电机对象，额定功率属性的名称可能是 "RatedPower"、"NominalPower" 或 "RatedCapacity"，即使底层数据类型都是 Double，客户端也需要人工适配。
语义层的目标是让机器自动理解 AddressSpace 中节点的业务含义。有两条主流路径：
第一条是 UA 自身的 Annotation 机制。OPC UA Part 3 允许为节点添加 AdditionalAttributes 属性，其中可以嵌入 JSON Schema 片段。客户端在读取 Variable 节点时同时拉取对应的 JSON Schema，就能知道该值的物理量纲、取值范围和业务约束。
第二条是映射到 W3C 标准的语义网体系。即将 AddressSpace 中的 Object 和 Variable 映射为 OWL 本体中的类和属性，引用关系映射为对象属性。这样 AddressSpace 就成为了一个轻量级的工业领域本体库，可以被 SPARQL 查询引擎消费。已有开源项目 opcua-ontology 提供了从 UAModeler 导出模型自动转换为 OWL 的工具链。
两条路径各有取舍。Annotation 机制的优势是低侵入——不需要修改 AddressSpace 结构，只扩展属性内容；缺点是表达能力有限，无法描述复杂的推理规则。OWL 路径表达力强，但对客户端的语义网技术栈有依赖，当前工业现场的接受度不高。
建模团队在实践中通常采用 Annotation 为主、OWL 为辅的策略：在 Companion Spec 要求的属性层面用 JSON Schema 标注物理量纲和取值约束，在跨系统语义对齐场景下（比如 MES 与 WMS 的物料批次关联）再引入轻量 OWL 映射。
自定义类型扩展
没有哪个 Companion Spec 能覆盖所有场景，工业现场大量存在领域特有的数据结构。OPC UA 的 BaseDataType 层级体系允许从任意已存在的 DataType 派生出新类型。
派生有两种方式：Subtype 和 Structure。Subtype 针对简单类型，比如从 Double 派生出 PercentType，约束取值范围 [0, 100]。Structure 针对复合结构，类似于编程中的 Struct——例如振动采样数据需要同时传递时间戳、三个方向的加速度值和采样频率，用 Structure 定义如下：
<StructuredType DataType="ns=2;s=VibrationSample" BaseType="ns=0;i=22">
<Field Name="Timestamp" DataType="ns=0;i=29" ValueRank="-1"/>
<Field Name="AccX" DataType="ns=0;i=11" ValueRank="-1"/>
<Field Name="AccY" DataType="ns=0;i=11" ValueRank="-1"/>
<Field Name="AccZ" DataType="ns=0;i=11" ValueRank="-1"/>
<Field Name="SampleRate" DataType="ns=0;i=11" ValueRank="-1"/>
</StructuredType>ValueRank=-1 表示该字段是标量，如果是数组则设为 1 并增加 ArrayDimensions 属性。定义好的 Structure 需要注册到服务器的 DataType 字典中，客户端在首次连接时通过 DataTypeDictionary 服务拉取完整定义，之后就能直接反序列化收到的 Variant 值。
结构定义的版本管理容易被忽视。当 DataType 结构发生变更（增加或删除字段）时，服务器应递增 DataType 的 Version 属性，并在 ChangeReferenceType 中保留旧版本到新版本的迁移路径。否则依赖旧版结构的客户端在收到新数据时会出现反序列化错误。
建模工具链
UAModeler 是当前最主流的建模工具，由 Unified Automation 开发，提供可视化界面编辑节点树、定义 DataType 和 ObjectType。模型文件以 XML 格式存储（.xml 或 .csv 导出），支持导入导出 Companion Spec 标准模型。
但 UAModeler 有明显的局限：它是单点编辑工具，不支持多人协作，模型与服务器实现之间需要手动同步。对于大型项目——例如一个包含 2000+ 标签的水电站机组模型——建模团队通常采用 Git 管理 XML 源文件，用 CI 脚本自动校验模型完整性（所有 Variable 的 DataType 必须在字典中注册、Object 节点必须有 InstanceOf 引用指向 ObjectType）。
近年来一些团队开始用 Python 脚本化建模：通过 opcua SDK 在测试服务器上动态构建 AddressSpace，然后用 UAModeler 导出最终模型文件。这种方式适合有大量重复结构的场景——例如 20 台相同型号的电机，可以写循环批量生成实例节点。
结语
工业现场的设备种类和数据结构差异巨大，OPC UA 信息建模提供了一套统一的抽象框架。工业互联网的建设需要将跨厂商的语义对齐作为长期推进方向——Companion Spec 的普及率仍然偏低，自定义类型的版本兼容常常靠人工约定。AI 原生工业数据平台可以在 AddressSpace 之上自动识别语义、关联跨设备的上下文关系，为建模团队提供模型完整性校验和类型推断能力，降低大规模模型的维护成本。
