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

ISO 26262 把 DFA 分散在 part 9 + part 11 两层:part 9 §7 给出通用方法学(§7.4.4 列了从 random hardware failures 到 ageing 共 9 类评估 topic),part 9 Annex C("Framework for Identifying Dependent Failures",资料性)给出 7 类 coupling factor 清单和跨 system / software / hardware / semiconductor 四层的示例表(Table C.1);part 11 §4.7 是 2018 版新加的半导体 DFA 专章(约 14 页):§4.7.5 给出另一套按失效来源分类的 DFI 清单 + 逐类缓解措施(Tables 21–26),§4.7.6 给出 12 步 DFA workflow(B1–B12)。IEC 61508 则用 part 6 Annex D 的评分表(约 37 项措施,2010 版口径)反查 β factor。

一个术语精度问题(评审现场真会被问):Part 9 Annex C 的原文措辞是 "coupling factor classes",不叫 DFI。DFI (Dependent Failure Initiator) 的定义在 ISO 26262-1:2018 §3.30 — "single root cause that leads multiple elements to fail through coupling factors";Part 11 §4.7.5 另有一套按失效来源分的 7 类 DFI(shared resources / single physical root cause / environmental / development / manufacturing / installation / service faults)。业界(含本 wiki 各页)习惯把 Annex C 的 7 类 coupling factor 俗称"7 类 DFI",本页沿用这个俗称,但引用条款时要分清是哪一套。

ISO 26262 倾向"监测共享资源"(定性 — 看是否有共因路径 + 有没有相应安全机制),IEC 61508 倾向"β 评分量化"(定量 — 给 β 一个数值,直接进 PFD 公式)。ISO 不强推 β factor 的原因是评分主观性强 — IEC 61508-6 Annex D 自己在正文承认"没有可用于校准该方法的现场共因数据,表格数值基于工程判断"。但 FMEDA 实战还是绕不开 β(否则没法算 PFD/PMHF),通常折中:用 ISO Annex C 列 coupling factor,用 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 的电压监测"(datasheet 明确 voltage monitoring 用独立 reference),把 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 兜底。Part 11 的 DFI 清单(Table 21)把"common clock elements(含 PLL / clock tree / clock enable)"列为 shared-resource DFI 的第一个例子。

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

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

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

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

β 不是凭感觉拍,可查的锚点有三层:

• IEC 61508-6 Annex D Table D.4 反查区间:logic 子系统 0.5% – 5%,传感器 / 执行器 1% – 10%(标准注明低于 0.5% / 1% "难以论证");详见 §6
• exida 经验域:可编程电子 0.005 – 0.05,现场设备(传感器 / 执行器)0.01 – 0.1 — 与 Table D.4 两列一致;exSILentia 工具默认值 0.1(非常保守)
• 实测上限:同板同源、差工程实践下 β 实测可达 0.25(SIS-Tech/Summers:"nearly zero to up to 25%")

与 Fail-operational 架构 §6.3 的口径一致:那页对含传感 / 执行的整通道取 β = 1%,正是 Annex D 传感 / 执行列的最低档(≥120 分才拿得到),且注明"须按项目 checklist 重评"。

来源:exida — CCF 重要性

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

来源: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(在 Part 11 §4.7.5 的 DFI 分类里对应 single physical root cause + manufacturing faults 两类):

• 同 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

下表给出对本架构的示意打分(数值是示意 — 真实项目必须逐题打分并留审计记录;且严格按 Annex D 应对 logic 与传感/执行分开两套列,此处为可读性给合并值):

合计 X = 42,Y = 43 → S = X + Y = 85,落在 Table D.4 的 70–120 档。

Annex D 要求分段反查:logic 列 → β = 1%,传感器/执行器列 → β = 2%。把 λch = 100 FIT 按 §9 架构拆段:

合计 λCCF ≈ 1.7 FIT。双点独立项比 CCF 项低约 5 个数量级(完整代入见 fail-op 页 §6.3),所以 PMHF ≈ λCCF ≈ 1.7 FIT,对照 ISO 26262-5:2018 §9.4.2.2 Table 6 的 ASIL D 目标 < 10 FIT:CCF 一项就吃掉 17% 预算。fail-op 页用整通道 β = 1% 得 1.0 FIT — 同一架构、更粗口径,结论同级(个位数 FIT、CCF 绝对主导)。

把三条措施拿掉 — MCU 换成同 vendor 同型号、两通道线束合并走线、共 12V 输入无独立滤波 — 分隔/隔离和多样性/冗余两大类的分数崩掉:按 §10.1 的表实算,即使这两类整体清零(合计 34 分),S = 85 − 34 = 51,掉进 Table D.4 的 45–70 档 → β = 2% / 5%:λCCF = 30 × 2% + 70 × 5% = 4.1 FIT,41% 预算没了 — 只丢三条措施,CCF 的预算占用就从 17% 翻到 41%,任何器件级优化都救不回来。这就是 fail-op 页那句话的数字版:fail-op 系统的可靠性设计 = β 的设计,钱要花在独立性证明(DFA)上,不是花在更贵的器件上。(顺带说明最烂档的量级:S 真要掉到 45 以下 — 那还得把环境控制/环境测试类措施也一起砍掉 — β = 5% / 10%,λCCF = 8.5 FIT,85% 预算蒸发。)

最后一个专家级口径提醒:若把 lockstep + Q&A WD + 独立电压监测的诊断计入(Table D.2/D.3 的 Z),检出部分要用 ${\beta }_D$(SD = X·(Z+1)+Y ≥ 120 → ${\beta }_D$ = 0.5%),总 CCF 概率 = ${\lambda }_{DU}\cdot \beta +{\lambda }_{DD}\cdot {\beta }_D$。汽车连续运行口径里检出失效在 FTTI 内进 safe state、主要影响 LFM 而非直接吃 PMHF — 别把 IEC 低需求口径和 ISO 连续口径混在一张表里。

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

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

实战通常两套并用:架构期 top-down 锁定关键 CCF 路径,设计稳定后 bottom-up 查漏。半导体层有正式版本:ISO 26262-11 §4.7.6 的 12 步 workflow(B1–B12) — B1 识别需要独立性/FFI 的元素对(输入 = 技术安全需求 + 架构描述 + 安全机制清单)→ B2 用 §4.7.5 DFI 清单查完备性 → B3–B5 证据充分性核查 + DFI 清单巩固 → B6–B9 定义缓解措施 + 措施证据核查 → B10–B12 有效性评估、风险降低充分性判定、不够就改措施再循环。

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

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

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