跳到主要内容

Ontology — 工厂知识图谱

概述​

PlantPulse Ontology 是以图的形式表达工厂实体及其相互关系的工厂知识图谱（Knowledge Graph）。

它帮助 AI 准确处理诸如"连接到该设备的传感器有哪些？"、"这台泵停机后影响会波及到哪里？"这类必须沿着关系才能回答的问题。仅需要层级结构时，资产树就够用；但涉及影响传播或多条件交叉时，就需要图谱。

已内置于平台中

Ontology 并非独立服务，而是运行在 PlantPulse 平台的 server-web 内部。 该图谱是基于 Apache Jena 的内存 RDF 模型，以平台 DB 为源定期重建。 无需另行安装或运维图数据库。

原独立服务 plantpulse-ontology(:8888) 已归档。当时的工具名称 （ontology_get_stats、ontology_get_graph 等）已不复存在。

节点类型（11 种）​

以下是出现在 RDF 图中的类。

类说明
Site工厂/站点
Area区域（生产厂房、公用工程等）
Line生产线
Equipment设备（注液机、包装机等）
Asset上述层级节点的公共父类 —— 用于不区分层级、查询全部资产时
Tag传感器标签
AlarmConfig报警设置
CommandDef设备命令定义
Statement设备规格书
Document设备附件文档
RegistryEntryUNS 注册项

层级关系： Site → Area → Line → Equipment → Tag

关系类型（3 种）​

除层级之外，资产之间还存在有方向的关系。影响传播类问题正是沿着这些关系展开的。

关系含义
FEEDSA 向 B 供给（上游 → 下游）
DEPENDS_ONA 依赖于 B
PRODUCESA 生产 B

图谱工具（集成 MCP）​

AI 通过以下三个工具访问图谱。它们名称相似，但返回的维度不同 —— 区分这三者正是本文的重点。

工具返回内容何时使用
get_ontology单个站点的 ISA-95 结构摘要 + 树（区域/产线/设备，以及各设备的标签数量）"这个站点是怎么构成的"、"有多少台设备"
query_ontology有向关系图（root + nodes[] + edges[]）"X 停机会影响到哪里"、"什么在给 X 供给"
query_sparqlSPARQL SELECT/ASK 结果行需要交叉多个条件的查询

如果只需要纯粹的层级结构，比起 Ontology，get_asset_tree 更为合适。

get_ontology 主要参数​

参数说明
site_id必填。 只知道名称时，先用 search_domains 解析出 ID
asset_id子树的根节点。只查看特定产线/设备时指定
depth根节点以下的展开深度。以站点根为基准，1=区域，2=产线，3=设备
include_tags为 true 时，在设备节点上附带标签名称列表。默认仅返回数量（tag_count）
标签总数只能以 total_tag_count 为准

把各节点的 tag_count 相加会得出错误结果，因为未展开分支上的标签会被遗漏。 若响应中出现 total_tag_count_unknown=true，表示无法计数，请不要臆测， 而应缩小范围后重新查询。

query_ontology 主要参数​

参数默认值说明
entity_id（必填）遍历起始实体
directionDOWNDOWN=下游影响，UP=上游原因，BOTH
relation_type（全部）FEEDS / DEPENDS_ON / PRODUCES
depth2遍历深度 1~5

影响传播遍历示例​

"注液机 DJ_M_01_1 停机后影响会波及到哪里" —— 使用 direction=DOWN 沿下游追踪。

     [Equipment: DJ_M_01_1] ← 시작 노드
              │ FEEDS
       ┌──────┴──────┐
       ▼             ▼
 [Equipment:    [Equipment:
  건조기]         컨베이어]
       │ FEEDS
       ▼
 [Equipment: 포장기]

响应中同时包含访问过的节点（nodes[]）和相连的关系（edges[]）。若因深度限制而无法继续遍历，会显示 truncated；当该值为 true 时，请调高 depth 后重新查询。

更新方式​

图谱以平台 DB 为源定期重建。新增设备或修改标签后，需等到下一个更新周期才会生效，因此刚刚注册的设备可能尚未出现在图谱中。更新周期由平台配置 semantic.graph.refresh.minutes 设定。

应用场景​

场景如何实现
掌握工厂构成用 get_ontology 一次性获取区域/产线/设备结构及标签数量
追溯异常原因query_ontology direction=UP —— 在异常设备的上游查找原因候选
评估停机影响范围query_ontology direction=DOWN —— 停机后向下游蔓延的范围
多条件交叉query_sparql —— 处理"3 号产线中带有已设置报警标签的设备"这类复合条件