Fault Injection Testing — 安全机制有效性的唯一硬证据

ISO 26262 Part 5 Annex D 给的 generic DC(60% / 90% / 99%)是典型上界,实际项目要算 specific DC:

generic DC 99% 的 SM 在你的具体实现里可能只有 95%——SM 实现细节、timing、interaction 都会影响。只有 fault injection 能给硬数字。下面这张方法分类全景把后续各节的 HWFI 3 层、SWFI 3 法、4 类 fault model 与 campaign 5 步收拢到一张图,便于先建立整体心智模型再逐节深入:

这一节先给出“ISO 26262 强制要求”需要同时考虑的几个判断点，后面的条目按工程优先级展开。

• Part 5 Annex D:推荐用 fault injection 评估 DC
• Part 11 Annex C:数字 IC 的 DC 评估强制用 fault injection
• ASIL D Confirmation Review:审计员会问 fault injection 报告

Fault Injection 与其它 verification 互补,不能省:

• Code review → 发现规范 / 风格问题,但不知 SM 在故障下是否真有效
• Unit test → 验证 SM 自身代码逻辑,但不验它对 fault 的反应
• Static analysis → 找 NULL 解引用 / 死代码,与 fault 反应无关
• Fault Injection → 唯一直接证明 "SM 检出 fault 在 FTTI 内"

这一节先把“4 类经典 fault model”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。

这一节先给出“对应物理失效”需要同时考虑的几个判断点，后面的条目按工程优先级展开。

• Stuck-at:开路 / Latchup / 老化
• Transition:边沿速度退化 / clock skew
• Bridging:Layout 短路 / 焊点桥接
• SEU:辐射(车规器件标 0.5-2 FIT/Mb DRAM)

车规 ASIL D 通常 覆盖至少 stuck-at + SEU 两类;高级项目加 transition + bridging。

最早期 + 最便宜的 FI:

• 工具:Synopsys VC FI / Cadence Xcelium FI / Mentor Questa FI
• 方法:在 Verilog/VHDL 仿真里强制 wire/reg 值
• 覆盖:几百万到几亿 fault scenarios
• 优势:芯片做完前发现设计缺陷,不用回片
• 限制:仿真速度慢(实时 1ms 仿真要几小时),只看数字,不能验模拟

ASIL D 数字 IC 量产前必跑——典型 1-3 个月跑完。

工具:

• Internal BIST(Built-In Self-Test):MBIST / LBIST 是芯片内置的 fault injection,工厂烧片时跑
• 外部测试设备:Teradyne / Advantest 测试仪 + 故障注入卡
• 聚焦离子束(FIB):物理切断 wire 模拟开路

适合:production test + post-silicon validation。

这一节先给出“System Level — HIL / 实车”需要同时考虑的几个判断点，后面的条目按工程优先级展开。

• HIL fault injector:dSPACE / Vector / NI 的 FI 模块,在 ECU 输入端注故障(短路 / 开路 / 信号偏移)
• CAN bus injector:用 Vector CANoe + FI script 注入伪造 / 漏发 / 延迟报文
• 环境注入:辐射 / 温度 / EMC 故意打到 ECU 看反应

适合:Part 4 系统集成测试 + Part 7 量产前 vehicle validation。

在代码里插入 fault injector 模块,运行时按 trigger 注入:

// 正常代码
result = compute_torque(input);

// 加 saboteur
result = compute_torque(input);
if (FI_active && FI_target == TORQUE) {
    result = FI_inject(result, FI_pattern);  // 按 pattern 改 result
}

适合:验证 SM 对特定数据 corruption 的反应。

把代码"改坏"成多个 mutants(变体),跑测试套件看是否检出:

• 改 < 为 <=(off-by-one)
• 删除 if 条件
• 把 + 改 -

每个 mutant 跑测试,Mutation Score = 检出的 mutants / 总 mutants。ISO 26262 ASIL D 推荐 mutation score ≥ 95%(Table 12)。

编译时注入 hooks,运行时按规则触发故障:

• LLVM pass / GCC plugin
• 工具:Mathworks Polyspace / Cantata / VectorCAST FI 模块

适合:自动化大规模测试(几千个 fault scenario 跑一晚上)。

这一节先给出“Campaign 5 步”需要同时考虑的几个判断点，后面的条目按工程优先级展开。

1. 定义目标 SM(哪个 SM 要验)
2. 定义 fault model 集(stuck-at / SEU / 等)
3. 定义注入点(每个 wire / register / variable)
4. 跑 campaign(穷举或采样)
5. 算 DC + 报告

这一节先把“穷举 vs 随机”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。

ASIL D MCU 的 cache 有几千万个 bit, 不可能穷举 → 用统计学采样(95% 置信度 + 5% 误差需要 ~1000 scenarios)+ 重点导向 critical path。

不只是"检出",还要看反应:

• 检测时间 ≤ DTI(Diagnostic Time Interval)
• 反应类型正确(报警 / 进入 safe state / 重启)
• 不误报(Negative test:无故障时 SM 不触发)

FI 工具本身可能 buggy:

• 注入点选错(没注入到真信号上)
• Trigger 提前 / 延后
• FI 工具引入额外 fault(自我污染)

工程实务:FI 工具按 ISO 26262 Part 8 Tool Qualification 评估——大概率 TCL2 或 TCL3,需要 qualification 报告。

Pre-silicon FI 在 RTL 上跑可能与 silicon 实测差异 1-3% DC——需要 silicon-level FI 复测关键 SM。

很多团队混淆:

• Code coverage(MC/DC):测试用例覆盖了多少代码 — 这是 Part 6 要求
• Fault injection coverage(DC):SM 检出多少注入故障 — 这是 Part 5/11 要求

两者不能互替,ASIL D 项目都要做。