【汽车芯片功能安全分析与故障注入实践 08】Diagnostic Coverage 是怎么算出来的？

作者Darren H. Chen方向汽车芯片功能安全分析与故障注入实践DemoD08_dc_engine标签汽车芯片功能安全Diagnostic CoverageDCSafety MechanismFMEDADemo 说明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 分成两类类型输入特点使用阶段结构估算 DCSP/EP/Cone、SM map、覆盖定义快适合早期探索架构/RTL 阶段故障注入验证 DCfault 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.yamlsafety_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.csvep_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可以设计成以下流程Read EP/SP/Cone DataRead SM LibraryRead EP-to-SM MapBuild Endpoint WeightApply SM CoverageCompute Permanent DCCompute Transient DCGenerate Reports内部模块建议模块作用structure_loader读取 SP/EP/Conesm_loader读取 safety mechanism librarymap_loader读取 EP-to-SM mapweight_engine计算 EP/SP/Cone 权重dc_engine计算 permanent/transient DCreport_writer输出 CSV/Markdown/JSON8. 输出报告设计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验证实际运行上下文下是否真的检测到故障可以理解为SP/EP/ConeStructural DCSafety Mechanism SelectionFault ListFault CampaignQuantitative DCFinal Metric如果结构 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 才能形成闭环。