DTC 根因分析

多码并发时找出首发根源码，把伴生码从处置清单里剥离。 核心方法：时序 + 拓扑 + 电源域三重证据交叉，单一证据不下结论。 脚本负责关联与聚类等确定性工作；模式辨析（尤其是反例陷阱）是你的工作。

执行流程

第 0 步 · 路径分流

• 单码口头询问且无数据文件 → 轻量路径：读 references/dtc_structure.md

确认编码含义，结合 references/root_cause_sop.md 对应模式给排查方向， 不跑脚本。但必须声明：单码无冻结帧、无伴生码上下文， 结论为方向性而非确定性。

• 有 DTC 导出文件 / 多码 / 车队级问题 → 完整路径，进第 1 步。

第 1 步 · 归一化

bash
python scripts/parse_dtc.py <导出文件> -o dtc_norm.json

支持 CSV 与 JSON 两种导出格式。看 stderr：

• 丢弃率 > 10%：向用户确认导出模板版本；脚本已列出前 5 条丢弃原因

（缺字段／status_byte 无法解析），据此判断是模板不符还是个别脏数据。

• WARN: first_seen 全部相同：TSP 平台按读取时刻覆盖了首发时间，

首发排序将降级为 occurrence 计数器排序——报告中必须声明置信度降低。

• WARN: first_seen 与 occurrence 均不可用：只能做拓扑分析，

报告须明确声明该局限，不要假装能排首发。

第 2 步 · 关联分析

bash
python scripts/correlate_dtc.py dtc_norm.json -o correlated.json

脚本做三件确定性工作：

1. 首发排序：按 confirmed 时间戳（或降级用 occurrence）排出每车的候选根源码
2. 传播标注：依 ecu_topology 邻接关系，把「根源候选下游的通信类 U 码」

标为 suspected_secondary

1. 车队聚类：码 × 软件版本 三维聚集度，给出 pattern_hint

若 stderr 出现 WARN: 拓扑表未覆盖的 ECU，该 ECU 的传播判断不可用—— 在报告中标注，并提示维护者更新 references/ecu_topology.md。

第 3 步 · 领域裁决（你的核心工作）

读 references/root_cause_sop.md，按脚本给出的 sop_section 只定位到对应节：

| 脚本标注的 pattern | SOP 节 | 含义 | |---|---|---| | POWER_DOMAIN_CASCADE | §1 | 电源类码首发 + 多域 U 码伴生 | | BUS_SEGMENT_LOSS | §2 | 同段 ECU 集体 U 码，无功能码 | | SINGLE_ECU_INTERNAL | §3 | 单 ECU 功能码，无伴生 | | MIXED_REVIEW_REQUIRED | §1–§3 | 混合形态，需人工辨析（脚本不裁决） | | NO_CONFIRMED | §5 | 仅 pending，confirmed 不落 | | 车队 SW_VERSION_CLUSTER | §4 | 同码同版本聚集（车队级，与单车模式叠加） |

对照 SOP 的判据逐条核对，特别注意每节的「反例」——表象相同但根因不同的 陷阱场景。脚本给出的 pattern 是基于规则的初判，反例辨析是它做不到的：

• 最典型的陷阱：BUS_SEGMENT_LOSS 与 POWER_DOMAIN_CASCADE 表象都是"多域 U 码"，

区别在冻结帧电压是否越限（脚本已给 voltage_abnormal 字段，但你要核对 伴生码的冻结帧电压是否也越限——只有根源码越限而伴生码正常时， 电源假设不成立）。

• 第二个陷阱：搭电救援后的历史遗留码，时序集中且此后无 pending 复发，

不是活动故障。

第 4 步 · 交付

报告必须包含：

1. 根源码判定：含置信度与依据（三重证据分别说明是否支持）
2. 伴生码清单：明确写出"这些码不需要单独处置"——这是本技能的核心价值，

避免维修端对着一屏故障码逐个排查

1. 处置顺序：按 SOP 的处置节给出动作序列
2. 若为批次问题：圈定影响面的查询条件（版本号／批次号／ECU 供应商代码），

而不是只说"建议排查批次"

错误处理与 fallback

• 冻结帧缺失：降级为时序 + 拓扑双证据，报告中显式降置信度，

并说明"补充冻结帧后可提升至确定性结论"。

• 时间戳全同：见第 1 步；改用 occurrence 排序，二者皆无 → 只做拓扑分析

并声明局限。

• 拓扑表未覆盖的新 ECU：脚本列为 unknown_nodes，该 ECU 相关传播判断

标注为不可用；不要凭 ECU 名称猜测它挂在哪条总线上。

• MIXED_REVIEW_REQUIRED：脚本明确表示无法裁决。此时逐条核对 §1–§3 判据，

若仍不能定论，交付"两个假设 + 各自的验证方法"，不要强行二选一。

边界

• 上下文中出现"升级／刷写／OTA"字样 → 立即声明移交 ota-log-diagnosis，

不做部分分析。 移交话术示例："这些故障码出现在 OTA 升级过程中， 属于刷写失败的伴生现象，我按 OTA 诊断流程来分析会更准确。"

• 清码操作指导、维修工艺 → 超出本技能，指向售后工艺文档体系。
• 纯科普问题（"P0 和 U0 开头有什么区别"）→ 直接回答即可，不必走本流程。