3. OPC UA核心概念与信息模型基础
要把一台食品设备的数据可靠地接入OPC UA系统，仅会“连上服务器、读几个标签”是不够的。OPC UA与早期现场总线最大的区别，在于它不只传输数值，还携带一整套描述数据含义的语义结构——这就是信息模型。理解地址空间、节点、引用、变量、方法、对象和类型这几个核心概念，才能把“杀菌釜1号的上腔温度”这类设备语义准确地表达出来，让上位系统、MES或云端不必依赖人工对照表就能读懂数据。
地址空间与节点：一切皆节点的统一视图
OPC UA服务器对外暴露的全部信息组织在一个称为地址空间（AddressSpace）的树状（严格说是图状）结构中。地址空间由节点（Node）构成，每个节点有唯一的NodeId，形式如 ns=2;s=Kettle01.Temperature，其中 ns 是命名空间索引，s= 表示字符串型标识符。命名空间是避免冲突的关键：标准节点放在 ns=0，厂商自定义的设备模型通常放在自定义命名空间（如 ns=2），这样不同厂商的“Temperature”不会互相覆盖。
节点本身只是“身份”，其内容由属性（Attribute）描述。每个节点都至少有 NodeId、BrowseName、DisplayName、NodeClass 等基础属性；变量节点还额外拥有 Value、DataType、AccessLevel 等。工程上排查“为什么读不到值”，往往先看 AccessLevel 是否允许读、DataType 是否与客户端预期一致，而不是盲目怀疑网络。
引用：把节点连成有意义的图
节点之间通过引用（Reference）连接，引用本身也是一种节点类型，带有方向性。最常用的是层次引用：Organizes 表示文件夹式组织，HasComponent 表示整体与部件，HasProperty 表示对象与其属性。此外还有非层次引用，如 HasTypeDefinition 指向类型定义，HasSubtype 表示类型继承。
正是引用让地址空间从“一堆孤立变量”变成“可导航的设备结构”。客户端浏览（Browse）时，本质上是沿着引用逐层展开。例如从 Objects 文件夹出发，经 Organizes 到达 Kettle01 对象，再经 HasComponent 到达 Temperature 变量。理解这一点，就能明白为什么良好的建模要让引用关系清晰、层级合理，而不是把所有变量平铺在一个文件夹里。
变量、对象、方法与类型
变量（Variable）承载具体数据，是接入中最常见的节点。它除了当前值，还可通过 HasProperty 挂载 EngineeringUnits（工程单位）、EURange（量程）等属性，使“85”这个数值自带“℃、0~150”的语义。对象（Object）是变量的容器，代表设备、部件或功能组，如 Kettle01、Valve03。方法（Method）表示可被客户端调用的操作，如“启动清洗程序”，调用时可有输入参数和输出结果，适合表达需要服务端执行逻辑的动作，而非简单读写。
类型（ObjectType / VariableType）是信息模型可复用的核心。定义一个 KettleType 对象类型，内含温度、压力、液位等标准部件；现场每台杀菌釜只需实例化该类型，就自动获得一致的结构。类型支持继承，KettleType 可继承自更通用的 FoodEquipmentType，在保持共性的同时扩展特性。这正是食品设备批量建模、保证多台设备语义一致的关键手段。
在食品设备建模中的落地方式
把上述概念落到一台杀菌釜上，推荐的做法是“先类型、后实例”。第一步，在自定义命名空间下定义 KettleType，用 HasComponent 挂上温度、压力、液位三个变量，用 HasProperty 为温度挂载 EngineeringUnits=℃ 与 EURange=0~150，用 HasComponent 挂上 StartCIP 方法。第二步，为现场每台设备创建对象实例，通过 HasTypeDefinition 指向 KettleType，实例自动继承全部结构，只需绑定各自的实时数据源。
这样做的直接收益是：上位系统只需按类型编写一次解析逻辑，就能适配全部同型号设备；新增设备时建模工作量从“逐个变量配置”降为“实例化并绑定”。对于多品种、多产线的食品工厂，这种一致性远比单点接入更有价值。
EngineeringUnits 与 EURange，并让 DisplayName 使用现场人员熟悉的叫法（如“上腔温度”）。语义完整的信息模型，能显著减少后期数据对接时的口径争议。一个可参考的建模检查清单
完成建模后，可用下面这份清单自查，避免“能连上但不好用”的常见问题：
| 检查项 | 合格标准 | 常见问题 |
|---|---|---|
| 命名空间 | 自定义节点统一放在 ns=2 等专用命名空间 | 混用 ns=0 导致与标准节点冲突 |
| 类型复用 | 同类设备均通过 HasTypeDefinition 指向同一类型 | 逐台手工建变量，结构不一致 |
| 变量语义 | 具备单位、量程、数据类型 | 只有裸值，客户端无法判断含义 |
| 引用层级 | 对象—部件—变量层次清晰 | 变量全部平铺，浏览困难 |
| 方法边界 | 需服务端执行逻辑的动作才建模为方法 | 把简单读写也做成方法，增加复杂度 |
需要强调的是，信息模型不是一次性画完的静态图纸，而是随设备改造持续演进的结构。当产线新增一台带搅拌功能的杀菌釜时，正确做法是扩展类型（如新增 AgitatorSpeed 部件或派生新子类型），而不是在实例上临时加变量，否则类型一致性会被逐步侵蚀。掌握地址空间、节点、引用、变量、方法、对象与类型这套概念体系，本质上是在掌握一种“让数据自带说明书”的建模能力，这也是OPC UA接入食品设备时最值得投入的基础工作。