【汽车芯片功能安全分析与故障注入实践 08】Diagnostic Coverage 是怎么算出来的？
作者：Darren H. Chen
方向：汽车芯片功能安全分析与故障注入实践
Demo：D08_dc_engine
标签：汽车芯片功能安全Diagnostic CoverageDCSafety MechanismFMEDA
Demo 说明
D08_dc_engine的目标是实现一个简化但可解释的 Diagnostic Coverage 计算引擎。
对应的通用工具名称为：
safeic-dc它的作用是把下面几类输入连接起来：
SP/EP/Cone 结构 Safety Mechanism Library EP-to-SM Mapping FIT / structure weights最终输出：
dc_report.csv metric_summary.csv dc_explain.md这一篇的重点不是背公式，而是理解：
Diagnostic Coverage 不是一个孤立百分比，而是安全机制对结构故障空间的覆盖能力。
1. DC 的直观含义
Diagnostic Coverage，通常简称 DC，可以理解为：
安全机制能够检测或覆盖的故障比例如果某个模块可能发生 100 个安全相关故障，其中 90 个能够被 safety mechanism 检测到，则可以说这个场景下的 DC 约为 90%。
但在芯片工程中，事情没有这么简单。
原因是：
不同故障的权重不同 不同 endpoint 的安全影响不同 不同 safety mechanism 覆盖范围不同 permanent fault 和 transient fault 可能需要分别处理 memory 和 standard cell 权重也不同因此，DC 不是简单的：
detected_faults / total_faults在结构分析阶段，它更像是一个加权覆盖率。
2. 两类 DC 思路：结构估算与故障注入验证
工程上可以把 DC 分成两类：
| 类型 | 输入 | 特点 | 使用阶段 |
|---|---|---|---|
| 结构估算 DC | SP/EP/Cone、SM map、覆盖定义 | 快，适合早期探索 | 架构/RTL 阶段 |
| 故障注入验证 DC | fault campaign 结果 | 更接近实际仿真证据 | 后期验证/签核前 |
结构估算 DC 回答：
根据结构和安全机制定义，预计能覆盖多少风险？故障注入验证 DC 回答：
在具体运行上下文和 fault campaign 下，实际检测了多少故障？本篇 Demo 先做结构估算 DC，为后续 fault campaign 的 quantitative DC 打基础。
3. DC 为什么要基于 EP/SP/Cone
第 6 篇已经说明，功能安全结构可以抽象为：
SP -> Cone -> EP不同 safety mechanism 覆盖的位置不同。
例如：
endpoint parity 可能主要覆盖 EP duplication checker 可能覆盖 EP + Cone lockstep 可能覆盖 SP + Cone + EP所以 DC 不能只说“这个模块 90% 覆盖”。更合理的表达是：
对 EP 覆盖多少？ 对 SP 覆盖多少？ 对 Cone 覆盖多少？ 对 transient fault 覆盖多少？ 对 permanent fault 覆盖多少？这种结构化描述可以让 DC 计算更透明。
4. 一个简化 DC 公式
在 Demo 中，可以采用简化公式：
DC_EP_TOTAL = Covered_Weight / Total_Weight其中：
Total_Weight = W_EP + W_SP + W_Cone Covered_Weight = W_EP * DC_EP + W_SP * DC_SP + W_Cone * DC_Cone举例：
EP weight = 32 SP weight = 64 Cone weight = 16某个安全机制的覆盖能力为：
DC_EP = 90% DC_SP = 0% DC_Cone = 90%则：
Total_Weight = 32 + 64 + 16 = 112 Covered_Weight = 32*0.9 + 64*0 + 16*0.9 = 43.2 DC = 43.2 / 112 = 38.57%这个例子说明：
即使 EP 和 Cone 覆盖率都很高，如果 SP 完全没有覆盖，总体 DC 也可能不高。5. Safety Mechanism Library 的设计
为了让 DC 可计算，需要先把 safety mechanism 抽象成库。
示例sm_library.yaml：
safety_mechanisms:EP_PARITY:description:Endpoint parity checkpermanent:ep:0.90sp:0.00cone:0.00transient:ep:0.80sp:0.00cone:0.00DUP_COMPARE:description:Duplicated logic comparepermanent:ep:0.90sp:0.00cone:0.90transient:ep:0.85sp:0.00cone:0.85LOCKSTEP:description:Lockstep comparisonpermanent:ep:0.95sp:0.90cone:0.95transient:ep:0.90sp:0.85cone:0.90这个库不只是工具输入，也是方法论载体。
它让安全机制从一句话变成结构化数据：
保护对象 覆盖范围 permanent coverage transient coverage 适用模块 限制条件6. EP-to-SM Map 的作用
Safety Mechanism Library 说明“某类机制能覆盖什么”。
EP-to-SM Map 说明“这个设计里哪个 endpoint 被哪个机制覆盖”。
示例ep_to_sm_map.csv：
ep_id,node,sm_id,mode,enabled EP_0001,top.u_ctrl.state.D,EP_PARITY,local,true EP_0002,top.u_bus.grant.D,DUP_COMPARE,module,true EP_0003,top.u_cpu.pc.D,LOCKSTEP,system,true这使 DC 计算可以从设计结构落到具体对象。
没有 EP-to-SM Map，安全机制只是设计意图；有了映射，它才成为可计算证据。
7. DC Engine 工具架构
safeic-dc可以设计成以下流程：
内部模块建议：
| 模块 | 作用 |
|---|---|
| structure_loader | 读取 SP/EP/Cone |
| sm_loader | 读取 safety mechanism library |
| map_loader | 读取 EP-to-SM map |
| weight_engine | 计算 EP/SP/Cone 权重 |
| dc_engine | 计算 permanent/transient DC |
| report_writer | 输出 CSV/Markdown/JSON |
8. 输出报告设计
dc_report.csv示例：
ep_id,node,sm_id,total_weight,covered_perm,dc_perm,covered_tran,dc_tran EP_0001,top.u_ctrl.state.D,EP_PARITY,112,28.8,0.2571,25.6,0.2285 EP_0002,top.u_bus.grant.D,DUP_COMPARE,240,144.0,0.6000,136.0,0.5667 EP_0003,top.u_cpu.pc.D,LOCKSTEP,300,282.0,0.9400,270.0,0.9000metric_summary.csv示例：
scope,total_weight,covered_perm,dc_perm,covered_tran,dc_tran top,652,454.8,0.6975,431.6,0.6619dc_explain.md示例：
# DC Explanation Endpoint: top.u_bus.grant.D Safety Mechanism: DUP_COMPARE The endpoint has a high cone weight and is covered by duplicated logic comparison. The mechanism covers EP and Cone, but does not cover upstream SP. Therefore the final DC is lower than a full lockstep-style protection.这样的报告适合 CSDN、GitHub、软著说明书和后续工具展示。
9. 结构 DC 与 fault campaign DC 的关系
结构 DC 是估算，fault campaign DC 是验证。
两者不是互相替代，而是前后衔接：
结构 DC：帮助选择安全机制和生成 fault list 故障注入 DC：验证实际运行上下文下是否真的检测到故障可以理解为：
如果结构 DC 预估很高，但 fault campaign 检测率很低，说明可能存在问题：
alarm list 不完整 observe point 配置错误 VCD 上下文不足 安全机制没有在该场景触发 fault injection time 不合理 某些故障传播到了 blackbox 或 missing sim data因此，DC Engine 不是最终答案，而是功能安全闭环中的一个中间环节。
10. D08 Demo 的目录建议
D08_dc_engine/ README.md run_demo.csh run_demo.sh inputs/ sp.csv ep.csv cone.csv sm_library.yaml ep_to_sm_map.csv dc_config.yaml outputs/ dc_report.csv metric_summary.csv dc_explain.md dc_result.json scripts/ safeic_dc.py运行命令示例：
python3 scripts/safeic_dc.py\--spinputs/sp.csv\--epinputs/ep.csv\--coneinputs/cone.csv\--sm-lib inputs/sm_library.yaml\--sm-map inputs/ep_to_sm_map.csv\--outoutputs11. 方法论总结
Diagnostic Coverage 的本质不是一个孤立数字，而是：
安全机制对故障传播结构的覆盖能力要把 DC 讲清楚，至少需要四类数据：
结构对象：SP、EP、Cone 安全机制定义：覆盖 EP/SP/Cone 的能力 映射关系：哪个 endpoint 被哪个机制保护 权重模型：不同结构对象的风险贡献D08_dc_engine的目标就是把这四类数据连接起来。
当 DC 计算变成可解释、可复现、可追溯的工程流程后，后续 safety mechanism selection、fault list generation 和 fault campaign 才能形成闭环。