4. 工业设备语义工程概述

在工业现场，设备数据往往分散在PLC、SCADA、MES、ERP以及各类传感器网关中。同一个“温度”可能被命名为Temp1、AI_101、炉膛温度或FurnaceTemp，语义工程的目标就是把这些“各自为政”的数据，转化为机器可理解、可推理、可复用的统一语义资产。本节从语义工程的目标出发，梳理本体与知识图谱的基础概念，并分析工业设备语义描述面临的核心需求与挑战。

一、语义工程的目标：从“数据可读”到“语义可推理”

语义工程不是简单的数据字典或字段映射，它要解决三个层次的问题：

• 统一概念：把不同厂商、不同协议、不同命名习惯中的同一物理量，映射到共享的概念体系，例如把AI_101、炉膛温度统一为Boiler.FurnaceTemperature。
• 表达关系：不仅描述“是什么”，还要描述“属于谁、连接谁、由谁控制、与谁联动”，例如“温度传感器安装在锅炉本体上”“给水泵向汽包供水”。
• 支持推理：让系统能够基于已有语义自动推导新结论，例如“若某设备属于压力容器，则必须关联安全阀”“若泵处于运行状态且出口压力低于阈值，则可能发生汽蚀”。

二、本体与知识图谱基础

本体（Ontology）是对某一领域概念及其关系的显式、形式化描述。它通常由类、属性、关系、约束和实例组成。在工业设备领域，本体可以定义“设备—部件—传感器—参数—工况—故障”等核心概念及其层级关系。

知识图谱（Knowledge Graph）则是本体之上的实例化数据网络，用节点表示实体、用边表示关系。本体提供“骨架”，知识图谱填充“血肉”。二者关系可概括为：

在AAS子模型体系中，本体常以标准化词表或信息模型的形式出现，知识图谱则作为运行时的语义数据层，支撑设备检索、影响分析和跨系统协同。

三、设备语义描述的需求与挑战

工业设备语义描述并非“给字段起个统一名字”那么简单，它需要同时满足多类需求，并克服现实中的多重挑战。

• 多源异构：设备来自不同厂商，通信协议包括Modbus、OPC UA、Profinet、MQTT等，数据模型差异巨大。
• 粒度不一：有的系统只提供设备级状态，有的细化到部件级、测点级，语义描述必须支持多粒度映射。
• 动态变化：设备会改造、扩容、更换传感器，语义模型需要可扩展、可版本化。
• 实时性要求：语义查询与推理不能拖慢控制回路，需要轻量化、边缘化部署。
• 标准落地难：ISA-95、IEC 61360、OPC UA信息模型等标准提供了参考，但到具体设备仍需大量工程化裁剪。

四、案例场景：从PLC变量到语义资产

某热电厂有3台锅炉，每台锅炉的PLC变量命名规则不同。语义工程的第一步是抽取变量清单，第二步是建立本体映射，第三步是生成知识图谱实例。

原始变量：
  B1_AI_101  → 1号锅炉炉膛温度
  B2_TEMP_F  → 2号锅炉炉膛温度
  B3_TC1     → 3号锅炉炉膛温度

本体映射：
  Boiler.FurnaceTemperature
    - unit: ℃
    - range: 0~1600
    - belongsTo: Boiler

知识图谱实例：
  Boiler1 --hasMeasurement--> FurnaceTemp1 (value=1120℃)
  Boiler2 --hasMeasurement--> FurnaceTemp2 (value=1085℃)
  Boiler3 --hasMeasurement--> FurnaceTemp3 (value=1150℃)

完成映射后，上层应用不再关心原始变量名，而是直接查询“所有锅炉的炉膛温度”，并可进一步推理“炉膛温度超过1200℃时触发高温报警”。

五、常见误区与复盘

• 误区一：把语义工程等同于数据清洗。清洗只解决格式和缺失值，语义工程还要解决概念统一和关系表达。
• 误区二：本体一次建完就冻结。工业设备持续变化，本体必须支持迭代和版本管理。
• 误区三：忽视AAS子模型的承载作用。AAS提供了标准化的子模型容器，语义描述应优先复用其已有结构，而非另起炉灶。
• 误区四：只做静态描述，不做运行时关联。知识图谱需要与实时数据流结合，才能支撑动态推理和告警。

综上，工业设备语义工程是一项跨越自动化、信息化与知识工程的系统性工作。它以本体为骨架、以知识图谱为血肉、以AAS子模型为承载，最终目标是让设备数据在异构系统之间“说同一种语言”，并具备可推理、可演进的语义能力。