DR Fault Atlas · 本体驱动故障树图谱

6+7

实体类型 + 关系

MCP 推理工具

200

POC 合成工单

消费端: BI + Agent

01背景与问题

现状	痛点
6-7k 条工单已由 AI pipeline 结构化	字段提取已解决，但知识仍是散的——没有「产品结构」骨架把它们组织起来
LLM 直接回答故障问题	靠训练记忆猜测，不可靠、不可审计、不随新数据更新
Power BI 看板	人被动看图；智能体无法沿维度推理

核心思路

固化「产品族 → 系统 → 部件 → 故障模式 → 现象 → 工单」的本体（Ontology），让结构化工单挂到这棵树上。 BI 看树，智能体沿树推理——同一份底座，两种消费方式。

02全景链路

① Ontology Playground

拖拽画本体
导出 RDF 设计图

→

② Git

单一真相源
版本管理

→

③ Databricks

rdflib 解析
atlas 三张元数据表

→

④ v_fault_tree

JOIN 真实工单
故障树宽表视图

→

⑤ 消费

Power BI（人看）
MCP Agent（推理）

边界设计

①② 在个人环境（画板+git），③④⑤ 在公司 Databricks 内——工单数据不出公司，RDF 只是图纸不含数据。

📐 交互式架构图：DR Fault Atlas Pipeline（Archify 渲染，4 视图切换）　·　🛠 本体画板：Ontology Playground 自托管版

03本体设计（RDF）

实体	关键属性	关系链
🏥 ProductFamily	config（天吊/地装/移动）	`ProductFamily` ─includes→ `System` ─contains→ `Component` `Component` ─failsAs→ `FaultMode` ─manifestsAs→ `Symptom` `FaultMode` ─recordedIn→ `WorkOrder` ─reports→ `Symptom` `WorkOrder` ─installedAt→ `ProductFamily`
⚙️ System	smu（责任服务组织）
🔩 Component	partNumber（SAP物料号）、fruLevel、isSafetyCritical
⚡ FaultMode	category 枚举（No Output / Image Quality / Mechanical / …）
🔍 Symptom	channel（Customer Call / Remote Monitoring）
📋 WorkOrder	downtimeHours、repairAction 枚举

DataBinding 节点记录本体属性 ↔ 工单表字段的映射（orderId=order_id 等），落在 RDF 里统一维护，Power BI 与 MCP 共用。

04落库与视图

表/视图	内容	行数	来源
`atlas.nodes`	实体类型定义（名称/图标/属性）	6	RDF 解析
`atlas.edges`	关系定义（谁连谁、基数）	7	RDF 解析
`atlas.data_bindings`	字段映射说明	1	RDF 解析
`service.work_orders`	真实工单事实表	6-7k（持续新增）	业务系统（非 RDF）
`atlas.v_fault_tree`	故障树宽表（每行一条工单，维度拍平）	—	JOIN 产物

v_fault_tree（Power BI 与 MCP 共用的唯一出口）

-- 每行: 一条工单 + 全链路维度
SELECT w.order_id, f.family_name AS product_family, s.system_name,
       c.component_name AS component, ft.fault_name AS fault_mode,
       ft.category, sy.symptom_name AS symptom,
       w.report_date, w.downtime_h, w.action_type
FROM work_orders w
LEFT JOIN ref_family f ON ... LEFT JOIN ref_system s ON ...
LEFT JOIN ref_component c ON ... LEFT JOIN ref_fault ft ON ...
LEFT JOIN ref_symptom sy ON ...;

本体改版成本 ≈ 0

Playground 里加实体 → 重跑解析 → 元数据表刷新，工单数据不动，Power BI 维度自动跟着本体走。

05MCP 智能体推理（核心价值）

把故障树推理包成 4 个 MCP 工具，Copilot CLI / Claude Code / 任意 agent 接入即可调用——答案从图谱查出，可追溯、随数据自动更新：

工具	输入 → 输出	推理路径
`diagnose`	报修现象 → 部件归因排序 + 预估停机	Symptom ← FaultMode ← Component（反向两跳）
`spares_advice`	部件 → 历史维修措施分布	Component → WorkOrder 聚合
`mtbf`	产品族 → 各部件故障统计	沿族→系统→部件聚合
`alert_check`	近 30 天激增部件检测	时间窗环比 >2 倍判定

影像科报修「灰图/空白图像」，先查什么？带什么备件？

现象 'Gray/Blank Image' 历史共 29 单, 归因排序: 1. Flat Panel Detector (Image Artifacts) — 16单 (55%), 平均停机 4.7h 2. X-ray Tube Unit (Image Artifacts) — 11单 (37%), 平均停机 5.6h 3. Detector Power Board (Image Artifacts) — 2单 (6%), 平均停机 1.7h 建议排查顺序按上述频率从高到低。

最近有激增故障吗？

⚠️ 激增部件: Flat Panel Detector: 近30天 10 单 (基线 4.5/月) HV Generator: 近30天 9 单 (基线 3.0/月) Encoder: 近30天 8 单 (基线 2.7/月) …

与裸 LLM 的区别

没有 ontology 时 LLM 靠记忆猜「灰图可能是探测器」；有 ontology 时它调用图谱查询——每条结论能指出走了哪条边，且随工单数据自动更新。这正是 Microsoft Fabric IQ 与 Snowflake Cortex Agents 的同一设计动机。

06部署形态

本地 POC（Mac，已验证 ✅）

PostgreSQL（atlas_poc 库）+ 200 条合成工单 + MCP server（local 后端）。 Power BI Desktop 直连 localhost:5432 的 v_fault_tree 即可出看板。

公司 Databricks（迁移路径 🔁）

同一 RDF + notebook（解析→Delta 表→视图）；MCP server 切 ATLAS_BACKEND=databricks，经 SQL Warehouse HTTP endpoint 远程查询。推理在本地 CLI，计算在公司 Warehouse，数据不落地。

MCP 接入配置（Copilot CLI / Claude Code 通用）

{
  "mcpServers": {
    "dr-fault-atlas": {
      "command": "python",
      "args": ["/path/to/mcp_server.py"],
      "env": { "ATLAS_BACKEND": "databricks", "DATABRICKS_HOST": "…",
               "DATABRICKS_HTTP_PATH": "…", "DATABRICKS_TOKEN": "…" }
    }
  }
}

07验证记录（全部真实执行）

环节	验证内容	结果
RDF 校验	官方 validator（`npm run validate`）	PASS 全部通过
Playground 导入	线上导入渲染图谱	PASS Entities(6) / Relationships(7)
解析落库	rdflib → PostgreSQL	PASS 6/7/1 全部读出
视图查询	Pareto / 产品族切片	PASS 排序合理
MCP 协议	initialize → tools/list → tools/call	PASS 4 工具握手成功
Databricks 驱动	databricks-sql-connector 安装	PASS 双后端切换就绪
公司真实数据	同管道 + 真工单	TODO 到司执行

08概念速查（ELI5）

📖 Ontology 本体

字典的目录结构——不是内容，是「词分几类、类之间怎么连」的规则。

📄 RDF

目录设计图，一个平台无关的标准文件。本体存这里，git 管版本。

🗄 数据库

字典正文——6-7k 条工单一直躺在这里，RDF 不含任何数据。

🔌 MCP

Model Context Protocol——让 Copilot/Claude 等 AI 客户端调用外部工具的标准协议。这里把故障树推理包成 4 个工具。

🌲 故障树视图

v_fault_tree——把「部件→故障→工单」拍平成一张宽表，BI 和 agent 共用。

🧠 GraphRAG

结构化图谱约束 + 检索增强生成的混合推理——本方案的进阶形态。

09演进路线

阶段	形态	状态
M1 本地 POC	RDF → 库 → 视图 → MCP 推理	完成
M2 公司真实数据	同管道跑在 Databricks + Power BI 看板	待执行
M3 自然语言查询	Databricks Genie / agent 挂视图，同事直接问	规划
M4 主动预警	新工单自动归因 + 激增检测推送飞书	规划