共因失效 (CCF) — DFA 量化 + lockstep 三重缓解 + 反模式

ISO 26262 把 DFA 分散在 part 9 + part 11 两层:part 9 §7 + Annex C 给出通用方法学和 7 类 DFI 清单,part 11 §8 是 2018 版新加的 16 页半导体专章,把方法学落到 die 级。IEC 61508 则用 part 6 Annex D 的 37 题评分表给出 β factor 的反查方法。

ISO 26262 倾向"监测共享资源"(定性 — 看是否有共因路径 + 有没有相应安全机制),IEC 61508 倾向"β 评分量化"(定量 — 给 β 一个数值,直接进 PFD 公式)。ISO 不强推 β factor 的原因是评分主观性强 — 37 题答案靠工程师判断,不同人打分差异大。但 FMEDA 实战还是绕不开 β(否则没法算 PFD),通常折中:用 ISO Annex C 列 DFI,用 IEC Annex D 量化 β,两套都进 DFA Report。

来源:ADI EngineerZone — ISO 26262 part 11 / Lorit Consultancy — 量化 DFA

工程师最常踩的坑是"我用了双 LDO 就独立了" — 真相是即使两路 5V 是独立 rail,同一颗 SBC die 内的 bandgap reference / charge pump / OV 比较器 是单点。一次 bandgap drift 同时让两路输出失准。Infineon TLF35584 的解法是提供"独立 reference 的 UV/OV 监测",把 reference 路径物理隔开 — 但这只是部分缓解,die-level 共因仍在。真双独立必须两颗不同 vendor 的 PMIC。

来源:Infineon TLF35584

主时钟单点是最经典的 CCF — 一颗 XTAL 失效全 MCU 死。但更阴险的是同 PLL 锁相:即使 dual core,共用一个 PLL 的话 frequency drift / jitter / glitch 同步发生,lockstep 比较器看不出问题。AURIX TC3xx 的对策是要求独立 backup clock(LP OSC vs main XTAL),关键路径用 LP OSC 兜底。

Reset domain 重叠是另一类隐蔽 CCF — 主 MCU 的 PORST 拉低把 checker MCU 也拉死。工程对策是 checker core 的 reset 必须由独立 watchdog 驱动,主 MCU PORST 不能进入 checker reset domain。

双核访问同 RAM = 一次 ECC double-bit error 同时阻塞双 core。AURIX 的解法是 lockstep CPU 不复制 RAM 本体,但把 PMI/DMI 接口 + ECC encode/decode 全放在 area of duplication 内 — 接口级冗余,RAM cell 共享但 ECC 路径双份。

来源:Infineon AURIX TC3xx FuSa AN0001

这是 7 类 DFI 中最被低估的一类。同一 PWM scheduler / 同一 motor control lib / 同一 CRC 实现 = 一个 bug 同时坏两通道。ISO 26262-9 明确把软件共因列为 DFI 第 ⑥ 类(Systematic Coupling),OEM 评审会直接问:"diverse software 证据在哪?"工程对策是软件多样性 — 不同团队 / 不同语言 / 不同算法实现同一功能,典型如一条通道 FOC + 另一条通道直接转矩。

β factor 把单通道总失效率 λ 拆成两部分 — 共因部分 + 独立部分:

PFD 双通道(1oo2)公式必须先减后乘:

独立项平方衰减(两通道概率相乘),CCF 项线性衰减(冗余无效)。这就是为什么 CCF 即使 β 很小,也常常是 PFD 的主导贡献。

β 不是凭感觉拍,标准给出明确范围:

• 可编程电子(IEC 61508-6 Annex D):0.005 – 0.05
• 现场设备(传感器 / 执行器):0.01 – 0.1
• 良好工程实践:0.001 – 0.05
• 差工程实践:可达 0.25
• exSILentia 工具默认值:0.1(非常保守)

来源:exida — CCF 重要性

β factor 是 2 通道模型,3 通道以上必须用 α factor(2oo3 表决 / TMR 三模冗余)。${\alpha }_k(n)$ 表示 n 个元件中刚好 k 个失效的占总失效率比例,可以表达"3 个全挂"vs"3 个挂 2 个"的不同概率,比 β 更细。其他常用模型族:Multiple Greek Letter (MGL)、Binomial Failure Rate、Alpha Factor。

来源:Reliability Space — CCF modelling

虽然 SFF 不直接含 β,但 FMEDA 输出表里必含:

CCF 部分通常进 ${\lambda }_{DU}$(危险未检出),除非有专门的 CCF 检测机制 — 这是为什么"双 watchdog 真独立 vs 假独立"会影响 SFF。

来源:Quiddity — FMEDA IEC 61508

三重缓解分别打时间相关性 / 空间相关性 / 信号方向相关性三种共因机制 — 三个维度上让 master 和 checker 在同一时刻看到的世界不一样,任何"同步影响两核"的干扰都会被比较器捕获:

• ① Temporal diversity:checker 输入信号延迟 2 clock cycle。一次瞬态干扰打中 master 的瞬间,checker 还在处理 2 cycle 前的输入,两核不会同步出错,比较器能抓到差异
• ② Spatial separation:checker 物理位置与 master 在 die 上错开布局,避免同一颗 alpha particle 同时穿过两核同一寄存器
• ③ Signal invert:master core 的 monitor point 反相后再送比较器,降低共模干扰对两个信号同方向影响的概率

来源:LinkedIn — TriCore AURIX diverse lockstep

三重缓解之外仍有不可消除的 die-level CCF:

• 同 die wafer defect — 一颗硅片局部缺陷,两核同位置都中招
• 同 fab lot 系统性失效 — 同批次工艺漂移
• 同时钟 PLL drift — 即使 backup clock,PLL 锁相期内仍同步
• 同 power rail UV/OV — 整片掉电没法靠 lockstep 检测

这些必须靠架构层冗余 — 双 MCU + 双 PMIC + 不同 fab。所以**"lockstep = ASIL D"是反模式**:lockstep 只解 random HW fault,不解 systematic,也不解 die-level CCF。要做 fail-operational EPS / 主驱,必须双独立 MCU。

Infineon 在 TC3xx Safety Manual 里把每条 dependent failure cause 配一个 adequate safety measure,典型 assumption 条目:

• "Avoid adjacent pins for digital acquisition" — 防 pin / package 物理共因
• "Use independent Backup Clock" — 防时钟共因
• "Use independent reference for UV/OV monitoring" — 防 reference 共因

集成商必须把这些 assumption 落到 system level Assumption of Use (AoU) 文档,DFA Report 交叉引用。

来源:Infineon AURIX TC3xx AN1001

DFA 不是单向流程,而是 deductive(顶向下)+ inductive(底向上)双向扫描,各自负责不同生命周期阶段 — 架构期没有完整的 DFI 实体只能从 SG 倒推,设计稳定后底层 DFI 清单完整就可以正向扫:

• Top-down (deductive) — 从顶层 safety goal violation 倒推可能的 CCF / CF 路径,架构期用
• Bottom-up (inductive) — 从 7 类 DFI 清单出发,正向推可能 fail,设计稳定后用

实战通常两套并用:架构期 top-down 锁定关键 CCF 路径,设计稳定后 bottom-up 查漏。

来源:3SK — DFA guide / VerveTronics — DFA

DFA Report 是 safety case 的硬证据之一,缺一项评审都会打回 — 评审看的是结构完整性 + 量化数据 + 验证闭环三件套同时齐全:

• CCF 分析:7 类 DFI 逐项 + 缓解措施 + 残余风险
• CF 分析:cascading 路径 + FFI 措施 + 验证证据
• 量化:β factor(IEC 61508-6 Annex D 累计分 + 反查表)+ FMEDA 集成
• Verification cross-ref:每条 DFA 论证指向 verification plan 的具体 test case
• Assumption of Use:供应商 SEooC 的 CCF assumption 接住清单