Fault Injection 实战案例 — 8 类典型 SM 的 Campaign 设计

功能安全L2别名 fault injection 实例 · SM 验证 campaign · ECC fault injection · lockstep fault injection · watchdog FI · ADC plausibility FI · CRC fault injection · 实战 FI 案例

本质与导读

本质 Fault injection 方法论只讲"怎么做",实战卡在每类 SM 的 campaign 各不相同——注入点、fault model、触发时序、判定条件、期望 DC 都得逐类定制,套通用流程必失真。本页给 8 类高频 SM 可直接填进 ASIL D Confirmation Review 的 FI campaign 模板。

主线坐标:横轨 · 功能安全(跨站) · ↑ 全景主线

1. ECC(Memory)— 内存纠错 FI

典型应用:RAM / Flash / Cache 的 SECDED ECC

维度	内容
注入点	RAM bit cell(每个 word 64 bit + 8 校验)
Fault model	1-bit flip(SECDED 应纠) / 2-bit flip(应检不纠) / 3+ bit flip(可能漏)
触发时序	注入后下一次 read 触发 ECC 检查
Campaign size	64M RAM bit × 4 fault models = 250M(穷举不现实)→ 统计采样 100k(95% 置信度)
期望 DC	1-bit:100%(纠 + 报告) / 2-bit:99%(检测,不纠)/ 3-bit:< 50%(SECDED 不强制覆盖)
判定	(a) ECC 报错给 CPU(b) 状态记入诊断码(c) 反应时间 < DTI

实战陷阱:1-bit 自动纠正后 CPU 是否得到正确数据 + 是否记录 fault——很多团队只测"纠了"忘记测"记录",审计员一抓一个准。

2. CPU Lockstep — 双核冗余 FI

典型应用:MPC5744P / Cortex-R5 lockstep

维度	内容
注入点	主核的 ALU 输出 / register file / cache line
Fault model	Stuck-at-1 in ALU output bit X for N cycles
触发时序	关键:注入要避开 idle cycles,在 lockstep 比对窗(典型 1-2 cycle 延迟)内
Campaign size	关键路径(ALU / FPU / DMA controller)穷举,~10k scenarios
期望 DC	99%+(主核 vs 检查核不一致 → RCCU 报错)
判定	RCCU 在故障注入后 ≤ 2 cycles 触发 fail 信号

实战陷阱:注入到 idle / 死代码 cycle 不会被检出——结果统计算 "未检出"会拉低 DC。要排除 idle 注入或加权重。

3. Watchdog — 4 种喂狗故障 FI

典型应用:windowed watchdog(SBC 或独立)

下图把 watchdog 放进 5 类高频 SM 的统一对照里——每个 SM 的 campaign 细节虽然不同(见各小节表),但验证骨架是同一条:注入一个具体故障 → SM 在检测时间内检出 → 在 FTTI 内驱动系统进安全状态。读表时盯三件事:注什么故障、期望反应是不是"检出 + 进安全状态"两步都做、反应时间是否落在 FTTI 预算内。

故障注入实例 — watchdog/lockstep/ECC/plausibility/CRC 各安全机制 x 注入故障 x 期望反应 x FTTI 内,注入-检测-反应时序

维度	内容
注入点	MCU 喂狗信号(SPI 写 / GPIO 翻转 / 计算结果)
Fault model 4 种	(a) 无喂:模拟 MCU 死机 / (b) 早喂:窗口前喂 / (c) 晚喂:窗口后喂 / (d) 错喂:Q/A 协议答案错
触发时序	在 MCU 任务周期内随机注入
Campaign size	每种 fault 各 100 trials × 不同时序 = 400
期望 DC	所有 4 类 100% 触发 watchdog reset
判定	(a) RSTB 拉低复位 MCU(b) FS0B 拉低进系统 safe state(c) 在 FTTI 内

实战陷阱:只测"无喂"是 watchdog 入门级——ASIL D 必须测全 4 种,否则 audit 时被"你的 SM 只覆盖死机不覆盖跑飞"打脸。

4. ADC Plausibility Check — 跨工况 FI

典型应用:电流 / 电压 / 温度采样的合理性检查

维度	内容
注入点	ADC 输入信号(模拟开关 / DAC)
Fault model	(a) 超范围(< 0.1V 或 > 4.9V) / (b) stuck:卡值不变 / (c) 漂移:慢速偏移 / (d) 跳变率异常:di/dt 物理不可能
工况组合	冷启动(-40°C)/ 室温 / 高温(+105°C) × 各种 nominal 信号
Campaign size	4 fault × 3 温度 × 5 nominal = 60+ scenarios
期望 DC	(a) 超范围 100% / (b) stuck 90%(冷启动时不易检)/ (c) 漂移 80%(慢漂浮难分正常)/ (d) 跳变率异常 95%
判定	对应 fault flag 在 N 个 sample 内置位

实战陷阱:"漂移"是 ADC plausibility 最难检的故障——和"系统真有变化"分不开。要靠多通道交叉(电流 + 电压 + 位置 + 时间一致性)综合判断。

5. Communication CRC + E2E — CAN 报文 FI

典型应用:E2E protection profile / SecOC

维度	内容
注入点	CAN bus 上的报文(用 CANoe + FI 模块)
Fault model	(a) CRC 错 / (b) counter 跳变(重放 / 跳号)/ (c) timeout(报文丢失)/ (d) 消息内容篡改(数据值不在物理范围)
触发时序	注入 1 帧 / 多帧连续 / 多帧间隔
Campaign size	4 fault × 多帧组合 = 200+ scenarios
期望 DC	CRC 错 100% / counter 不连续 99% / timeout 100% / 内容超范围 ≥ 95%
判定	接收方:(a) 标记报文 invalid (b) 进入 timeout safe state (c) 不响应错误命令

实战陷阱:SecOC 加 MAC 后 CRC 错和 MAC 错可能同时发生——要分别测,不能合并。

6. Voltage Monitor — 电源监控 FI

典型应用:OV / UV / spike detection

维度	内容
注入点	ECU 主电源(可调电源 + FI 模块)
Fault model	(a) UV(< 0.85 × Vnom)/ (b) OV(> 1.15 × Vnom)/ (c) spike(瞬态 ±50% 持续 < 100us)/ (d) sag(瞬态降到 0 几 ms)
触发时序	静态(稳态后注)/ 动态(MCU 任务执行中注)
Campaign size	4 fault × 动 / 静 × 几个幅度 = 30+
期望 DC	UV/OV 检测 ≥ 99% / spike 80%(瞬态短)/ sag 取决于响应时间
判定	SBC 输出 fail-safe 信号 + MCU 可重启进 safe state

实战陷阱:spike 太短 SBC 可能漏检(典型 SBC 检测窗 1-10us),要看 datasheet 的 detection window 与你的 spike 长度匹配。

7. Clock Monitor — 时钟监控 FI

典型应用:晶振失效 / PLL 失锁 / 时钟漂移检测

维度	内容
注入点	主时钟输入(注入器替代晶振输出)
Fault model	(a) 完全停止 / (b) 频率漂 ±10% / (c) 抖动过大 / (d) 占空比异常
触发时序	启动后注 / 运行中注(更难检)
Campaign size	4 fault × 时序 = 20+
期望 DC	停止 100%(看门狗会兜)/ 频率漂 ≥ 95%(MCU 内置 clock monitor)/ 抖动 80%
判定	(a) MCU 切到内部 RC 备用时钟(b) 标记诊断 code

实战陷阱:时钟漂移测试要长时间(几分钟到几小时)——ECU 量产线 ATE 时间紧张,经常被压缩省略,造成 field 偶发问题。

8. SOTIF Triggering — 算法极限 FI

典型应用:ADAS 摄像头识别 / 雷达 fusion 算法(注:这是 SOTIF 而非 26262 fault,但方法类似)

维度	内容
注入点	仿真环境的 sensor 输入(Carmaker / VTD / CARLA)
Fault model	(a) 罕见物体注入(动物 / 异常姿态行人)/ (b) 环境干扰(雨 / 雪 / 逆光)/ (c) 多目标快切换
触发时序	不同 ADAS 工况 / 速度 / 距离
Campaign size	1000s 仿真场景(SOTIF 标配)
期望"DC"	实际是 trigger condition coverage——已知场景 area 覆盖率 ≥ 95%
判定	(a) 算法识别正确 OR (b) 算法不确定 → 降级到司机接管 OR (c) 系统报告 ODD 退出

实战陷阱:SOTIF FI 评判不是"通过 / 失败"二值,是"safe response"程度——算法识别错但及时降级也算 safe;算法识别"差不多"但继续执行可能更危险。

9. Campaign Size 与置信度推算

ASIL D 关键 SM 想证 DC ≥ 99%,统计学需求:

置信度	误差(p)	最少 campaign N
90%	±5%	~268
95%	±5%	~385
95%	±2%	~2401
99%	±1%	~16641

公式 $N = (z α /2/ p)^{2} \cdot D C \cdot (1 - D C)$ 。

工程实务:ASIL D 关键 SM 至少 1000 trials,常规 SM 100-500。10000+ campaigns 主要做 random sampling 提覆盖度。

10. FI Report 模板(给 Confirmation Review)

每个 SM 的 FI 报告标准格式:

SM ID: SM-CPU-LOCKSTEP-001
ASIL: D
DC target: 99%

Fault model coverage:
  - Stuck-at-0/1 in ALU output: 5000 trials, 4995 detected, DC = 99.9%
  - Transition fault in register: 2000 trials, 1980 detected, DC = 99.0%
  - Combined: 7000 trials, 6975 detected, DC = 99.6%

Reaction validation:
  - All detected faults triggered RCCU within 2 cycles: ✓
  - All detected faults caused FS0B assertion within FTTI: ✓
  - No false positive in 10000 fault-free trials: ✓

Conclusion: SM-CPU-LOCKSTEP-001 meets ASIL D DC ≥ 99%
Tool used: Synopsys VC FI v2024.06 (TCL2 qualified)

每个 SM 一份,数十个 SM 拼成 ASIL D 项目的 FI 总报告。

核心要点

每类 SM 的 FI campaign 设计完全不同 — ECC 重 1-bit/2-bit 比例,lockstep 重时序对齐,watchdog 重 4 种喂狗故障
ADC plausibility 必须跨工况测,漂移是最难检的 fault
Communication FI 要分别测 CRC / counter / timeout / 内容篡改,SecOC 加 MAC 单独测
Spike 与 sag 测试要看 SBC datasheet 的 detection window 是否匹配
ASIL D 关键 SM 至少 1000 trials,99% 置信度需 16641 trials
FI 报告每个 SM 一份,Confirmation Review 必看

Cross-references

← 索引
Fault Injection 测试方法:方法论 + 工具
安全机制目录:每个 SM 都要 FI 验证
ISO 26262-5 硬件层细化:DC 公式
ISO 26262-11 半导体细化:IC 厂 FI 实践
电流采样诊断 SM:ADC plausibility 实战
电压采样诊断 SM:voltage monitor FI 实战
位置采样诊断 SM:resolver plausibility FI
栅极驱动诊断 SM:driver fault FI
CAN E2E + SecOC:通信 FI 详细
MCU + SBC ASIL D 集成:lockstep + watchdog 实战
ASIL D 案例研究:整车级 FI campaign 案例