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

所有 FI campaign 回答同一组问题,但答案逐 SM 不同。ISO 26262-5:2018 §10(硬件集成与验证)Table 11 把 fault injection test 列为验证安全机制完整性与正确性的集成测试方法,ISO 26262-11:2018 §4.8 对半导体进一步把 FI 定位为"解析方法不足以覆盖的设计点"的检查手段——但两处都不给 campaign 怎么设计,细节要工程师自己定。骨架是六要素:注入点(物理/寄存器/总线/仿真节点)、fault model(注什么样的故障)、激活条件(故障要被 workload 用到才会传播)、注入相位(相对 SM 时间窗的时刻)、判定 oracle(什么算检出 + 反应正确)、样本量(统计上证到什么置信度)。下图把 5 类高频 SM 放进统一对照:每个 SM 的 campaign 细节不同(见各节表),但验证骨架是同一条——注入一个具体故障 → SM 在检测时间内检出 → 在 FTTI 内驱动系统进安全状态。

SECDED 的检测能力来自码距,这决定了 campaign 的全部结构。典型组织是 Hamming(72,64)——64 数据 bit + 8 校验 bit,最小码距 4:1-bit 错的 syndrome 唯一指向出错位置,纠正;2-bit 错的 syndrome 非零但不落在任何合法单 bit 位置上,检出不纠;3-bit 及以上错的 syndrome 可能落回"合法单 bit 错"空间,译码器按错误的位置"纠正",产出错数据还标着 corrected(miscorrection)——这就是"3-bit DC 不承诺"的机制根源,不是工程偷懒。

注入机制上,真芯片不需要辐射源:NXP S32K3 的 EIM(Error Injection Module)可在读路径上翻转指定的数据/校验 bit,ERM(Error Reporting Module)记录事件与地址;Infineon AURIX 经 MTU 的 ECC 控制寄存器提供等价机制。关键是等价类思想:EIM 注入验证的对象是 ECC 编解码逻辑 + 上报链——同一 word 的 72 个 bit 位置 × 故障阶数就是完整等价类,cell 阵列本身的 stuck-at 归 MBIST 管(TC39x 的 MBIST 对 SRAM 阵列 100% 覆盖,Safety Manual v1.1)。把"64 Mbit × 4 fault model = 2.5 亿次穷举"当成 ECC campaign,是把两个 SM 的验证对象混在了一起。

实战陷阱:只测"纠了"忘测"报了"。1-bit 纠正若没进 ERM/SMU 计数,退化中的 cell 就静默累积——等第二个 bit 坏,直接落进"2-bit 检不纠"甚至 miscorrection。这是 LFM 的缺口(潜伏故障未被周期上报),审计员一抓一个准。

Lockstep 的检测物理是时间冗余 + 输出比对。以 TC397 为例,双核以 2 个时钟周期的延迟错开执行(AURIX TC39x Safety Manual v1.1)——目的是让同一个电源 glitch / EMI 事件打到两核时,两核处在不同的执行状态,产生可比对的差异而非相同的错误。比对点在核的输出接口(总线访问/写回),不是内部每个节点:没传播到比对点的故障 lockstep 看不见,但它们也没传播进系统,按 §1.1 属 no-effect、出分母。检测覆盖率的真值由 vendor 的 RTL FI 给出(TC39x:LBIST 覆盖 97.1% 触发器与组合路径,MBIST 100% SRAM,Safety Manual v1.1)——Tier-1 不重跑 RTL,Tier-1 campaign 的对象是反应链:比对报警 → SMU/FCCU → 安全态,用 alarm/fault 注入寄存器触发"假报警"走通全链。术语按 vendor 对号:NXP 叫 RCCU,TI 叫 CCM(Cortex-R5F lockstep,TMS570),Infineon 叫 lockstep comparator + SMU。

实战陷阱:注入到 idle / 死代码 cycle 的故障既不传播也不会被检出——按"未检出"计会人为压低 DC。正确做法是 golden run 三分类后把 no-effect 剔出分母,或注入前用 workload 画像排除不激活窗口;把 vendor Safety Manual 的 structural DC 直接抄成自己应用的 specific DC 则是反方向的错(应用软件与 PCB 互联不在 vendor 报告里)。

Watchdog 检测的物理量是"时间行为偏离",三代机制各扩一层覆盖:simple timeout 只抓"不喂"(死机);窗口看门狗加"早喂也 trip",抓定时器跑飞变快;Q&A challenger 再加"喂的内容要算对",抓"程序还在跑但算错了"(跑飞后碰巧仍在喂狗的场景)。所以 4 种喂狗故障各对应一类真实 MCU 失效模式,少测一种 = 少覆盖一类失效。以 NXP FS26/FS85 族为参数锚(FS84/FS85C DS Rev.6 §32.4):窗口周期 1–1024 ms 离散可配(默认 3 ms),CLOSED 段占比 31.25%–68.75%;Q&A 用 16-bit LFSR(默认种子 0x5AB2)出题,bad refresh 使 WD 错误计数器 +2、good refresh −1,达 WD_ERR_LIMIT(可配 8/6/4/2)拉 RSTB;故障升级到 FS0B 由 FLT_ERR_CNT 管(§32.8.1)。

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

Plausibility 的检测能力来自"信号与物理先验的距离",四类故障的先验强度不同,期望 DC 必然分层。超范围可检是设计出来的:ratiometric 传感器把有效输出压进诊断带内(典型有效区 0.5–4.5 V),带外(如 < 0.1 V / > 4.9 V)只可能是断线 / 短路 / 供电故障——先验距离最大,DC 最高。stuck 靠"真实物理量必然带噪声与纹波"这条先验——冷启动时信号本来就平,先验变弱,这是 stuck 检出率随工况波动的机制。漂移最难:慢漂在单通道信号空间里与真实工况变化不可分,原理上单通道检不出,必须跨通道物理一致性闭合(电流 + 电压 + 温度 + 位置互相印证)。跳变率异常靠系统物理惯量(di/dt 上限)判,是强先验。这解释了为什么 campaign 必须跨温度工况:先验强度本身是工况的函数。

实战陷阱:漂移是 plausibility 最难检的故障——和"系统真有变化"分不开。单通道阈值收紧只会换来量产误报,正解是多通道交叉(电流 + 电压 + 位置 + 时间一致性)综合判断;campaign 里对漂移的期望 DC 要按跨通道架构如实定,别写 99% 然后 FI 打脸。

E2E 保护是三个正交机制的叠加,各抓一类故障,必须分开注入分别判。CRC 抓 bit corruption,数学保证是:Hamming distance 以内的错误 100% 检出,超出后随机错误的逃逸概率约 $2^{-c}$(c 为 CRC 位数)——8-bit CRC 逃逸 0.39%,16-bit 0.0015%。这就是"E2E 对 corruption 的 DC 上限"的机制来源:P01(CRC-8,SAE J1850 多项式 0x1D + 4-bit counter,经典 CAN ASIL B 档)约 99.6%,P05(CRC-16,多项式 0x1021 + 8-bit counter,CAN-FD ASIL D 主流)约 99.998%(AUTOSAR E2E Protocol Specification R23-11)。counter 抓丢帧 / 重放 / 乱序——注意 P01 的 4-bit counter 按模 15 计数(到 14 即回 0,0xF 保留跳过),恰好丢 15 的整数倍帧时 counter 看起来连续,这段盲区由 timeout 兜底(抓持续丢失)。三者的期望反应也不同:CRC/counter 错标记单帧 invalid,timeout 才进通信丢失安全态。

实战陷阱:SecOC 加 MAC 后,CRC 错和 MAC 错是两条独立检测路径、两种反应(E2E 状态机 vs 认证失败计数)——要分别注入分别判,合并测会掩盖其中一条路径的失效。

UV/OV 监控 = 比较器 + deglitch 滤波器,而 deglitch 是故意的:比 deglitch 窗短的瞬态被滤掉是设计行为(防瞬态误动作导致整车误停),不是漏检。FS26/FS85 族 VMON 的 UV/OV deglitch 可配约 5–40 µs(FS84/FS85C DS Rev.6)——campaign 的期望值必须按 datasheet 写:spike 长于 deglitch 窗 → 期望 100% 检出;短于窗 → 期望"不动作",把它记成 miss 是把设计行为当缺陷(这类"期望值写反"会引发错误的"修复",把滤波改掉反而抬高误触发率)。真正值得花 trial 的是边界:deglitch 窗 ±20% 附近的 spike 行为是否与 DS 一致。

实战陷阱:可编程电源的 slew 率做不出 < 100 µs 的 spike——你以为在测 spike,实际注进去的是斜坡。注入波形必须示波器回读确认(§11.6)。

CMU 的原理是参考窗计数:用独立的内部 RC 振荡器开一个测量窗,数被监时钟在窗内的边沿数,超出上下限报警(NXP S32K3 的 CMU_FC;TI TMS570 用 DCC 双时钟交叉计数,原理相同)。两个物理推论直接决定 campaign 期望值:① 检测延迟 ≈ 测量窗长——窗越长频率分辨率越高但报警越慢;② 检测下限 = 参考源自身精度——内部 RC 全温典型 ±1–3%(查器件 DS),报警阈值必须开得比参考误差宽,所以参考精度以内的慢漂移原理上不可检(见 §12.2)。完全停振最容易检(窗内计数为 0,且 watchdog 兜底);占空比/抖动异常要靠别的机制(PLL 失锁指示、glitch filter),CMU 计数对它们天然不敏感。

实战陷阱:慢漂移测试要长时间(分钟到小时级),量产线 ATE 节拍塞不下,经常被压缩省略——这类覆盖要在 DV 台架补足并在报告里写明分工,否则 field 偶发问题没人认领。

这一类不是 ISO 26262 的 fault(元件没坏),是 ISO 21448:2022(SOTIF)的 triggering condition:功能局限在特定场景组合下被触发。方法学与 FI 同构(注入 → 观察 → 判定),但三点本质不同,照搬 26262 的 campaign 口径会全错:① 注入空间是场景空间而非故障空间——无穷维,覆盖论证只能对 ODD 分区 + 已知 triggering condition 目录做,不存在穷举;② oracle 不是二值(见 §12.3);③ "DC" 变成 scenario coverage,数字只相对已知目录有意义。

实战陷阱:SOTIF 的判据不是"通过/失败"二值,是 safe response 程度——识别错但及时降级算 safe,识别"差不多对"却继续全速执行可能更危险。判定谓词要写成系统级安全响应(TTC 阈值 / 接管请求时限),不是识别正确率。

把 §4 的 watchdog campaign 在一个真实器件链上完整走一遍,产出可直接交 Confirmation Review 的报告条目。

SM ID: SM-WD-001 (FS26 challenger window watchdog)
ASIL: D    SG: SG-EPS-01    FTTI: 10 ms
Config: WDW_PERIOD = 4 ms (50/50), WD_ERR_LIMIT = 2, fault escalation -> FS0B

Fault model coverage (zero-failure demonstration, C = 95%, target DC >= 99%):
  - no-feed:      300/300 detected, max t = 4.21 ms
  - early-feed:   300/300 detected, max t = 4.05 ms
  - late-feed:    300/300 detected, max t = 4.18 ms
  - wrong-answer: 300/300 detected, max t = 0.42 ms
  - SPI stuck:    300/300 detected, max t = 4.24 ms
  Combined: 1500/1500 -> DC >= 99% demonstrated at 95% confidence

Reaction validation:
  - RSTB + FS0B asserted, gate-driver enable removed: all 1500 trials
  - max(t4 - t0) = 4.24 ms <= FTTI 10 ms (margin 58%)
  - False trip: 0 / 10000 fault-free trials
Tooling: dSPACE HIL + solid-state FI box; 4-ch scope sync
Tool qualification: per ISO 26262-8 clause 11 (TCL report attached)

方法论层面的坑(套 generic DC 不做 FI、只测 t1 不测 t4、空载 FI、CCF 遗漏、工具无 TCL)见方法论页 §7;下面 7 个是 campaign 执行层特有的。

本页仅列页面用到的工业标准缩写。通用英语、单位、月份及 层/Lx tag 不列。