组件级 Pareto — 滚动 12 个月
不再看全量历史数据，只看最近 12 个月的工单分布。5 年前的头号问题可能已在批次改进中解决——全量 Pareto 会让你追着过时的问题跑。
X 射线管组件占 23%，加上冷却系统和探测器模块，前 3 项覆盖 62% 工单。这是资源分配的第一优先级。
失效率 × 装机后月份 — 分层浴缸曲线
每条线是一个装机年份的 cohort。5 年持续发货 = 混龄装机基座，混在一起画会得到平坦的均值线，掩盖真实问题。分层展开后，各年龄段的健康状态一目了然。
2021 cohort在第 48 个月后失效率从 0.025 飙升至 0.058——典型耗损期特征。2024-2025 cohort的早期失效率显著低于老批次，说明 HV 模块改版和固件升级有效。
Cohort 累计失效率对比 — 改进趋势验证
同样按装机后月份对齐，但看的是累计失效率。线条从上往下叠——越新的 cohort 应该越低。如果新 cohort 比旧的还高，立即拉警报。
2024-Q3 cohort 在第 12 个月的累计失效率为 8.2%，比 2023-Q1 cohort 同期的 14.1% 下降了 42%。每次设计变更的效果可量化追踪——这张图是下次预算答辩的弹药库。
失效现象 × 解决方案矩阵 — 驱动 R&D 改进
Pareto 只告诉你「X 射线管最多」，但研发需要知道：具体是什么现象？工程师每次怎么修的？这张矩阵把 Top 1 组件拆开——行是失效现象，列是解决方案。解决方案是根因的反向投影：如果同一个现象 80% 都是"更换"，大概率是来料或设计问题，直接拿这个比例对话研发。
球管打火 / 内部放电共 38 次，其中 更换球管 30 次（79%）、升级固件 5 次、调整校准 3 次。79% 的更换率 = 零件级问题，不是软件能修的。研发的着手点：球管供应商来料质量审查 + 真空密封工艺。对比图像伪影：14 次中 11 次升级固件（79%）= 软件问题，走算法迭代路线。
FCO 渐进式推广 — 渗透率 × MTBF 曲线
FCO 不是一瞬间生效的——从发布到全量部署可能持续半年。推广期内，设备分成「已更新」和「未更新」两组。这两组在同一日历时间对比，就是一次天然的 A/B 测试——唯一变量就是 FCO 本身。阴影带 = 推广窗口，虚线 = 已更新设备，点线 = 未更新设备，实线 = 混合 Fleet MTBF。
FCO-2024-019（HV 模块改版）从 2024-09 发布，到 2025-03 完成推广（95% 渗透）。在这 6 个月窗口内，已更新设备的 MTBF 从 30 跃升到 34，而未更新设备仍维持在 30。两组差异 4 个月 = FCO 的真实贡献。推广完成后，未更新设备归零，Fleet MTBF 完成爬升。推广期的「已更新 vs 未更新」对比是量化 FCO 效果的金标准——它排除了时间趋势、季节性、设备年龄等混淆变量。
物料共现热力图 — 同一工单里什么一起坏
一次现场服务可能换多个零件。产品涉及上百种物料，但相关性分析只聚焦失效率 Top 10。格子里的数字不是原始共现次数，而是Lift 系数 = 实际共现 ÷ 独立期望。Lift = 1× = 跟随机一样（无关），>2× = 强关联。Lift 消除了高频物料的"曝光偏差"——两个低频料如果几乎总是一起坏，Lift 会远高于两个高频料。
Lift 排名和原始共现次数排名完全不同。滑环 × 碳刷 Lift = 9.0×（原始仅 11 次，但两个都是低频料，独立期望只有 1.2 次）——几乎每对滑环故障都连带碳刷，摩擦副的物理因果。探测器 × 准直器 Lift = 6.5×——光路对准链路。冷却泵 × 散热器 Lift = 5.3×——热管理回路。而原始次数最高的球管 × HV模块 Lift 仅 2.1×——因为两者都是高频料，独立期望就有 10.4 次，22 次共现只比随机高 2 倍，关联强度远不如摩擦副。
物料关系网络图 — 链路簇 × 枢纽节点
把共现热力图展开成网络——节点 = 物料，边 = 共现关系，粗细 = 频次。力导向布局自动把经常一起出现的物料拉近，形成物理链路簇。大节点 = 高连接度（枢纽），坏了会连累最多其他件。这张图是给研发展示链路全貌的最佳形式。
网络自动聚成 3 个链路簇：① 高压链路（球管-HV模块-电缆）② 热管理链路（冷却泵-散热器-风扇）③ 机械链路（滑环-碳刷-轴承）。球管是全图最大枢纽节点——它的故障会向 4 个物料辐射，是整个产品可靠性的单点风险。如果球管 FCO 能落地，连带降低 HV 模块和电缆的失效率，ROI 远超球管本身的备件成本。
方法论 — MTBF 与失效率怎么算
上面的图表靠的是正确的计算口径。这里拆解每个数字背后的公式和数据逻辑——拿到真实数据后按这套规则跑。
核心指标定义
MTBF = 总在役设备运行时间 ÷ 期间现场服务访问次数
公司的指标是 MTBF (site visit)——"失败"不是零件坏了，而是需要工程师去现场。一次访问可能修了 3 个问题，但只算 1 次。MTBF 反映的是服务成本而非零件可靠性。
Fleet-level 计算
λ = 该月现场访问次数 ÷ 该月设备-月（unit-months）
分母不能用固定装机数——每年新增 ~300 台，同时有退役。设备-月按每台设备实际在役天数折算：
| 设备 | 在该月的天数 | 贡献的设备-月 |
|---|---|---|
| SN-001（全年在线） | 30 天 | 1.00 |
| SN-002（15 日装机） | 16 天 | 0.53 |
| SN-003（20 日退役） | 20 天 | 0.67 |
浴缸曲线的数据点
λ(装机后第 m 月) = Σ(该 cohort 中第 m 月的访问数) ÷ Σ(该 cohort 中第 m 月的设备-月)
每个 cohort 独立计算，然后在同一张图上叠加——这就是为什么 5 年持续发货的产品必须分层看，不能混在一起。
合同状态 — 最隐蔽的坑
| 有合同设备 | 无合同设备 | |
|---|---|---|
| 故障报告 | 全量上报（你方负责修） | 可能不上报（客户自修/第三方） |
| 数据可见性 | 完整 | 不完整（censored data） |
| PM 执行 | 按计划执行 | 可能不做 |
正确做法：① 分层计算——有合同和无合同分开算；② 如果大部分有合同（>70%），以有合同设备为标准口径，注明统计范围。
合同类型本身也是分层维度：Full Service 什么都报 / PM Only 只做预防 / T&M 小问题自己扛。
失效率 ↔ MTBF
MTBF(月) = 1 / λ | MTBF(月) = 12 × 在役设备数 / 年度访问数
例如：λ = 0.029 次/台/月 → MTBF = 1/0.029 ≈ 34.5 个月，即平均每 2.9 年需要一次现场访问。
数据清单 — 你需要提供什么
图表 01-03 需要两张基础表；图表 04-05 需要额外补充失效模式和工程变更数据。以下是完整字段需求。
表 1：装机基座清单（Install Base Registry）
| 字段 | 说明 | 示例 |
|---|---|---|
| Serial Number | 设备唯一标识（关联键） | SN-2021-0156 |
| 产品型号 | 产品系列 | CT-5000 |
| 装机日期 | 开始在役的时间 | 2021-03-15 |
| 退役日期 | 如已退役（可空） | 2026-01-10 |
| 合同状态 | 合同类型 | Full Service / PM Only / T&M / None |
| 合同起止 | 当前合同覆盖区间 | 2021-03 ~ 2026-03 |
| 装机批次 | 用于 cohort 分组 | 2021-Q1 |
| 硬件版本 | 设计变更追踪 | Rev-B |
| 固件版本 | 当前/最后已知版本 | FW 4.2.1 |
| 安装区域 | 地理分层 | Shanghai |
表 2：现场服务记录（Service Event Log）
| 字段 | 说明 | 示例 |
|---|---|---|
| Event ID | 访问唯一标识 | EVT-2026-04432 |
| Serial Number | 关联到装机基座 | SN-2021-0156 |
| 访问日期 | 工程师到现场日期 | 2026-05-12 |
| 访问类型 | Corrective / PM / Installation | Corrective |
| 涉及组件 | 子系统/模块 | X射线管组件 |
| 故障代码 | 如有 | E-307 |
| 解决方案 | 维修/更换/调整 | 更换球管 |
| 关闭日期 | 工单关闭 | 2026-05-13 |
表 3：失效模式记录（Failure Mode Log）— 驱动 Chart 04
工单长文本里提取不出根因——但每条工单都有失效现象和解决方案。解决方案是根因的反向投影：更换率高 → 来料/设计问题，固件升级率高 → 软件问题。
| 字段 | 说明 | 示例 |
|---|---|---|
| Event ID | 关联现场服务记录 | EVT-2026-04432 |
| 失效现象 | 客户/工程师观察到的现象（已有） | 球管打火 / 漏油 / 图像伪影 |
| 解决方案 | 本次服务实际做了什么（已有） | 更换零部件 / 升级固件 / 调整校准 / 清洁保养 |
| 故障代码 | 系统记录的错误代码（已有） | E-307 |
| 影响等级 | 停机时长 / 安全等级 | Critical / Major / Minor |
| 关联 FCO | 工程变更编号（如有） | FCO-2024-019 |
| 根因怎么办？不对每条工单标根因。只对 Top 5 现象做 5 次 RCA/8D，结论回填到这张表 → 矩阵的根因维度从无到有。 | ||
表 4：工程变更日志 + 逐台部署记录 — 驱动 Chart 05
FCO 从发布到全量部署可能持续半年。需要逐台追踪部署日期，才能画出渗透曲线和 A/B 对比。
| 字段 | 说明 | 示例 |
|---|---|---|
| FCO 编号 | 工程变更唯一标识 | FCO-2024-019 |
| 发布日期 | FCO 正式发布时间 | 2024-09-01 |
| 变更类型 | 设计/供应商/固件/工艺 | 设计变更 |
| 影响范围 | 受影响的组件/模块 | HV 模块 |
| 预期效果 | 为什么做这个变更 | 降低球管打火概率 |
| Serial Number | 逐台部署记录 | SN-2024-0801 |
| 部署日期 | 该设备实际收到 FCO 的日期 | 2024-11-15 |
| 部署工程师 | 谁做的部署 | FSE-07 |
某月渗透率 = 该月已部署设备数 ÷ 适用范围内总设备数。推广期内，将设备分成「已部署」和「未部署」两组，分别计算 MTBF → A/B 对比。
四张表 → 五张图 → 研发闭环
装机后月份
Cohort 分组
组件拆分
访问类型
根因归类
影响等级
生效日期
预期效果
五张图的决策闭环
备件 · R&D · 供应商
早期 · 随机 · 耗损
预算弹药 · FCO 决策
更换率 = 根因方向
推广窗口 = 测量窗口
关联强度 · 备件包设计
枢纽节点 · 单点风险
数据闭环 · 持续迭代