4. 设备领域知识建模
设备故障诊断要真正落地，不能只靠维修师傅的经验口口相传，也不能只靠一堆传感器数据“硬算”。它需要一个可共享、可推理、可扩展的知识底座——这就是设备领域知识建模。本节围绕设备本体设计，把设备拆解为部件、测点、故障模式、症状、原因五类核心概念，并建立它们之间的语义关系，为后续知识图谱构建和故障推理提供结构基础。
一、核心原理：从“设备台账”到“语义网络”
传统设备管理系统中，设备信息往往以表格形式存在：设备编号、型号、位置、责任人。这种结构能回答“这台泵在哪里”，却很难回答“振动值升高可能由哪些原因引起”“更换轴承需要关注哪些测点”。知识建模的目标，是把这些分散信息组织成一张有向语义网络：节点表示概念或实例，边表示关系。
设备本体（Ontology）是这张网络的“骨架”，它定义领域内有哪些类、哪些属性、哪些关系。一个典型的设备本体包含以下核心类：
- 设备（Equipment）：如离心泵、电机、压缩机，是诊断对象顶层单元。
- 部件（Component）：设备的功能组成单元，如轴承、叶轮、密封、联轴器。
- 测点（MeasurementPoint）：安装传感器或人工采集数据的位置，如驱动端轴承振动测点、出口压力测点。
- 故障模式（FailureMode）：设备或部件失效的表现形式，如轴承磨损、叶轮不平衡、密封泄漏。
- 症状（Symptom）：可观测到的异常现象，如振动烈度超标、温度升高、噪声异常。
- 原因（Cause）：导致故障模式发生的根本因素，如润滑不足、装配偏心、介质腐蚀。
这些类之间不是孤立的，而是通过关系连接：设备包含部件，部件关联测点，故障模式发生于部件，故障模式产生症状，原因导致故障模式。正是这些关系，让知识图谱具备了推理能力。
二、方法流程：五步完成设备本体设计
设备本体设计不是一次性拍脑袋，而是一个迭代过程。推荐按以下五步推进：
- 确定范围与目标：明确建模对象是单台关键设备还是整条产线，诊断目标是早期预警还是故障定位。
- 抽取核心概念：从设备台账、检修记录、FMEA报告、传感器清单中抽取部件、测点、故障模式、症状、原因。
- 定义类与属性：为每个概念定义唯一标识、名称、别名、单位、量程、安装位置等属性。
- 建立关系：确定类之间的语义关系及基数，如一台设备包含多个部件，一个测点可监测多个部件。
- 实例化与校验：用真实设备数据填充实例，检查关系是否完整、是否存在矛盾，并请领域专家评审。
三、关系图解：设备本体核心结构
下图展示了设备本体中六类核心概念及其主要关系。图中以离心泵为例，把设备、部件、测点、故障模式、症状、原因组织成一张可推理的语义网络。
四、案例场景：离心泵轴承磨损的诊断链路
以某化工厂离心泵 P-101 为例。该泵驱动端轴承安装有振动测点 1H，出口安装压力测点 PI-102。某日振动烈度从 2.1 mm/s 上升至 7.8 mm/s，系统触发预警。
在知识图谱中，推理链路如下：测点 1H 采集到振动烈度超标 → 该测点关联驱动端轴承 → 驱动端轴承可能发生轴承磨损 → 轴承磨损的典型症状为振动烈度超标、温度升高 → 导致轴承磨损的原因包括润滑不足、装配偏心、疲劳载荷。系统进一步调取润滑记录，发现该轴承已超过润滑周期 320 小时，从而将“润滑不足”列为高置信度原因。
如果没有本体关系，系统只能报警“振动超标”，维修人员仍需人工判断。有了本体，系统可以直接给出“疑似轴承磨损，建议检查润滑状态”的结论，大幅缩短诊断路径。
五、常见误区与复盘
| 误区 | 表现 | 改进建议 |
|---|---|---|
| 只建部件树，不建故障关系 | 图谱只能回答“设备由什么组成”，不能回答“为什么故障” | 同步建立故障模式、症状、原因三类节点及关系 |
| 测点与部件关系模糊 | 一个测点关联多个部件，推理时无法定位 | 明确测点安装位置和监测对象，必要时增加方向属性 |
| 原因与故障模式混为一谈 | 把“轴承磨损”同时当作原因和故障模式 | 区分“现象层”和“根因层”，原因应指向可干预因素 |
| 本体过于庞大，难以维护 | 类目数百个，实例关系混乱 | 先做最小可用本体，按设备类型分批扩展 |
设备领域知识建模的本质，是把维修经验从“人脑”搬到“图谱”。设备、部件、测点、故障模式、症状、原因六类节点及其关系，构成了故障诊断知识图谱的骨架。只有骨架清晰、关系准确，后续的推理、检索和智能诊断才有可靠基础。