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

作者： Darren H. Chen
方向： 汽车芯片功能安全分析与故障注入实践
Demo： D08_dc_engine
标签： 汽车芯片 功能安全 Diagnostic Coverage DC Safety Mechanism FMEDA

Demo 说明

D08_dc_engine 的目标是实现一个简化但可解释的 Diagnostic Coverage 计算引擎。

对应的通用工具名称为：

text 复制代码

safeic-dc

它的作用是把下面几类输入连接起来：

text 复制代码

SP/EP/Cone 结构
Safety Mechanism Library
EP-to-SM Mapping
FIT / structure weights

最终输出：

text 复制代码

dc_report.csv
metric_summary.csv
dc_explain.md

这一篇的重点不是背公式，而是理解：

Diagnostic Coverage 不是一个孤立百分比，而是安全机制对结构故障空间的覆盖能力。

1. DC 的直观含义

Diagnostic Coverage，通常简称 DC，可以理解为：

text 复制代码

安全机制能够检测或覆盖的故障比例

如果某个模块可能发生 100 个安全相关故障，其中 90 个能够被 safety mechanism 检测到，则可以说这个场景下的 DC 约为 90%。

但在芯片工程中，事情没有这么简单。

原因是：

text 复制代码

不同故障的权重不同
不同 endpoint 的安全影响不同
不同 safety mechanism 覆盖范围不同
permanent fault 和 transient fault 可能需要分别处理
memory 和 standard cell 权重也不同

因此，DC 不是简单的：

text 复制代码

detected_faults / total_faults

在结构分析阶段，它更像是一个加权覆盖率。

2. 两类 DC 思路：结构估算与故障注入验证

工程上可以把 DC 分成两类：

类型	输入	特点	使用阶段
结构估算 DC	SP/EP/Cone、SM map、覆盖定义	快，适合早期探索	架构/RTL 阶段
故障注入验证 DC	fault campaign 结果	更接近实际仿真证据	后期验证/签核前

结构估算 DC 回答：

text 复制代码

根据结构和安全机制定义，预计能覆盖多少风险？

故障注入验证 DC 回答：

text 复制代码

在具体运行上下文和 fault campaign 下，实际检测了多少故障？

本篇 Demo 先做结构估算 DC，为后续 fault campaign 的 quantitative DC 打基础。

3. DC 为什么要基于 EP/SP/Cone

第 6 篇已经说明，功能安全结构可以抽象为：

text 复制代码

SP -> Cone -> EP

不同 safety mechanism 覆盖的位置不同。

例如：

text 复制代码

endpoint parity 可能主要覆盖 EP
duplication checker 可能覆盖 EP + Cone
lockstep 可能覆盖 SP + Cone + EP

所以 DC 不能只说"这个模块 90% 覆盖"。更合理的表达是：

text 复制代码

对 EP 覆盖多少？
对 SP 覆盖多少？
对 Cone 覆盖多少？
对 transient fault 覆盖多少？
对 permanent fault 覆盖多少？

这种结构化描述可以让 DC 计算更透明。

4. 一个简化 DC 公式

在 Demo 中，可以采用简化公式：

text 复制代码

DC_EP_TOTAL = Covered_Weight / Total_Weight

其中：

text 复制代码

Total_Weight = W_EP + W_SP + W_Cone
Covered_Weight = W_EP * DC_EP + W_SP * DC_SP + W_Cone * DC_Cone

举例：

text 复制代码

EP weight   = 32
SP weight   = 64
Cone weight = 16

某个安全机制的覆盖能力为：

text 复制代码

DC_EP   = 90%
DC_SP   = 0%
DC_Cone = 90%

则：

text 复制代码

Total_Weight = 32 + 64 + 16 = 112
Covered_Weight = 32*0.9 + 64*0 + 16*0.9 = 43.2
DC = 43.2 / 112 = 38.57%

这个例子说明：

text 复制代码

即使 EP 和 Cone 覆盖率都很高，如果 SP 完全没有覆盖，总体 DC 也可能不高。

5. Safety Mechanism Library 的设计

为了让 DC 可计算，需要先把 safety mechanism 抽象成库。

示例 sm_library.yaml：

yaml 复制代码

safety_mechanisms:
  EP_PARITY:
    description: Endpoint parity check
    permanent:
      ep: 0.90
      sp: 0.00
      cone: 0.00
    transient:
      ep: 0.80
      sp: 0.00
      cone: 0.00

  DUP_COMPARE:
    description: Duplicated logic compare
    permanent:
      ep: 0.90
      sp: 0.00
      cone: 0.90
    transient:
      ep: 0.85
      sp: 0.00
      cone: 0.85

  LOCKSTEP:
    description: Lockstep comparison
    permanent:
      ep: 0.95
      sp: 0.90
      cone: 0.95
    transient:
      ep: 0.90
      sp: 0.85
      cone: 0.90

这个库不只是工具输入，也是方法论载体。

它让安全机制从一句话变成结构化数据：

text 复制代码

保护对象
覆盖范围
permanent coverage
transient coverage
适用模块
限制条件

6. EP-to-SM Map 的作用

Safety Mechanism Library 说明"某类机制能覆盖什么"。

EP-to-SM Map 说明"这个设计里哪个 endpoint 被哪个机制覆盖"。

示例 ep_to_sm_map.csv：

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 可以设计成以下流程：
Read EP/SP/Cone Data
Read SM Library
Read EP-to-SM Map
Build Endpoint Weight
Apply SM Coverage
Compute Permanent DC
Compute Transient DC
Generate Reports

内部模块建议：

模块	作用
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 示例：

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.9000

metric_summary.csv 示例：

csv 复制代码

scope,total_weight,covered_perm,dc_perm,covered_tran,dc_tran
top,652,454.8,0.6975,431.6,0.6619

dc_explain.md 示例：

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 是验证。

两者不是互相替代，而是前后衔接：

text 复制代码

结构 DC：帮助选择安全机制和生成 fault list
故障注入 DC：验证实际运行上下文下是否真的检测到故障

可以理解为：
SP/EP/Cone
Structural DC
Safety Mechanism Selection
Fault List
Fault Campaign
Quantitative DC
Final Metric

如果结构 DC 预估很高，但 fault campaign 检测率很低，说明可能存在问题：

text 复制代码

alarm list 不完整
observe point 配置错误
VCD 上下文不足
安全机制没有在该场景触发
fault injection time 不合理
某些故障传播到了 blackbox 或 missing sim data

因此，DC Engine 不是最终答案，而是功能安全闭环中的一个中间环节。

10. D08 Demo 的目录建议

text 复制代码

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

运行命令示例：

bash 复制代码

python3 scripts/safeic_dc.py \
  --sp inputs/sp.csv \
  --ep inputs/ep.csv \
  --cone inputs/cone.csv \
  --sm-lib inputs/sm_library.yaml \
  --sm-map inputs/ep_to_sm_map.csv \
  --out outputs

11. 方法论总结

Diagnostic Coverage 的本质不是一个孤立数字，而是：

text 复制代码

安全机制对故障传播结构的覆盖能力

要把 DC 讲清楚，至少需要四类数据：

text 复制代码

结构对象：SP、EP、Cone
安全机制定义：覆盖 EP/SP/Cone 的能力
映射关系：哪个 endpoint 被哪个机制保护
权重模型：不同结构对象的风险贡献

D08_dc_engine 的目标就是把这四类数据连接起来。

当 DC 计算变成可解释、可复现、可追溯的工程流程后，后续 safety mechanism selection、fault list generation 和 fault campaign 才能形成闭环。