两类失效 — 随机 vs 系统性

功能安全L1别名 随机失效 · 系统性失效 · random hardware failure · systematic failure · 可靠性 vs 安全性 · reliability vs safety相关functional-safetyharasafety-mechanism-catalogthermal-management

本质与导读

本质: 功能安全把所有失效切成"随机硬件失效"（可概率化，靠冗余 + 诊断管理）和"系统性失效"（不可概率化，靠 V 模型 + 评审 + 形式化预防），两类管理路径完全不能互换；HSE 数据显示 44 % 的危险失效源自需求阶段，所以系统性失效在工程上远比随机失效致命。

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

1. 核心矛盾：可靠 ≠ 安全

工程师常把"可靠"和"安全"当同义词，但功能安全标准里两者解决不同问题——可靠性问"多久会失效"、用 MTBF 衡量；安全性问"失效会不会伤人"、用 ASIL/SIL 衡量。一个 MTBF 极高的零件如果失效后导致人员伤亡，在功能安全语境下仍属"危险件"；一个 MTBF 一般的零件如果失效后能进 safe state，在功能安全语境下可以接受。下图把这两条独立维度并排画出来。

可靠性 vs 功能安全 两条独立维度

功能安全最容易被工程师误解的一点是：它不是可靠性的升级版。两者回答的是完全不同的问题。

一个反直觉的例子：

  • 系统 A：MTBF = 100 万小时（极其可靠），但某种失效模式下会输出错误的刹车指令（制动失效变成制动反向）
  • 系统 B：MTBF = 1 万小时（100× 更差），但任何失效都会让输出安全停止（失效 → 断电 → 机械制动接管）

从可靠性看，A 完胜。从功能安全看，B 完胜——因为 A 的失效会造成事故，B 的失效不会。

这个区别决定了功能安全的所有工程实践：不能只看 MTBF 而要分析失效模式和失效后果；要主动证明系统对每种危险失效都有缓解手段（诊断 + 安全反应）；冗余是为了检测失效，不是"反正另一个还能工作"；软件的系统性 bug 比硬件的随机失效更难管理（冗余对软件 bug 无效）。

三个关键问题贯穿整个安全生命周期：

  • 有哪些危险？（HARA）
  • 硬件失效时如何检测和反应？（诊断覆盖率 + 安全反应时间）
  • 系统性失效如何避免？（V 模型开发流程 + 评审 + 形式化方法）

2. 随机硬件失效（Random Hardware Failures）

随机硬件失效由物理退化机制产生，工程上可概率化、可冗余消除。这两个特性决定了它的管理范式：先用 FMEDA 量化每条失效率，再设计 Safety Mechanism 把覆盖率推到 ASIL 目标。

2.1 5 种核心机制对比

下表把车规里实际触发 FIT 的物理失效机制收成五条主线——每条机制对应不同的物理根因、识别手段和缓解策略，FMEDA 时按这五类逐元件估 。

机制物理根因典型症状识别手段预防/缓解
电迁移 EM大电流密度使金属原子沿电子风迁移；空洞/短桥互连开路、阻值漂移、断续开关加速寿命试验（高 J + 高 T）；Black 方程外推；在线阻值监测降低电流密度（加粗金属/并联）；控温；Cu + 封顶工艺
热疲劳开关循环 ΔT_j × 键合/焊层 CTE 失配，裂纹累积键合线脱落；焊层 delamination； 上升Coffin–Manson 模型； 监测；功率循环测试降低 ΔT_j（限功率加速）；Ag/Cu sinter 或压接封装；DBC
腐蚀湿气 + 离子污染侵蚀键合/焊盘；阳极溶解或阴极析出键合根部断裂；漏电；参数漂移85/85 湿热；pHAST；外观 SEM气密/防潮封装（保形涂层/灌封）；金属化升级 Au/Pd
SEE 单粒子宇宙射线/α 粒子穿过器件产生电荷脉冲SEU 位翻转；SET 脉冲；SEL 闭锁烧毁JESD89 中子/α 加速；ECC 纠错日志统计ECC（位/字/帧）；TMR 三模冗余；EPI 衬底抗闭锁；关键寄存器周期刷新
介电击穿 TDDB氧化层在高电场 + 高温下累积缺陷 → 漏电激增 → 穿孔 漂移；栅漏电突变；栅短高压栅偏压 + 高温加速（JESD92）；Weibull 外推至工作条件保留栅压/温度裕度；避免栅极过冲尖峰；RC snubber；选低 器件

2.2 共性特征与系统级预防

随机硬件失效的三条共性是它可用概率描述（ = 失效率，单位 FIT = /h），它独立于设计过程——即使完美设计也会随时间累积，以及它可用冗余 + 诊断消除。基于这三条特性，系统级预防策略成五条主线：

  • FMEA / FMEDA 逐元件打分，映射到 SPFM / LFM / PMHF
  • 在线诊断：ECC、DESAT、UVLO、电流自检、温度监测、看门狗
  • 冗余：双 MCU lockstep；双采样通道；双栅极驱动 Enable（STO 两条独立路径）
  • 降额：电流密度 ≤ Black 模型允许值；ΔT_j 减半 → Coffin–Manson 寿命 ×32（见 热管理）
  • 筛选：HTOL + Burn-in 清除婴儿期失效

目标：通过冗余和在线诊断把危险失效的概率降到目标以下（如 ASIL D 要求 PMHF < 10 FIT）。

3. 系统性失效（Systematic Failures）

系统性失效不是硬件抖动而是人为留下的逻辑错误——设计、需求、代码、调试中的错误，一旦写进就永远存在，不能用 MTBF 描述。统计上 44 % 的系统性失效根源在需求阶段——这就是为什么 ISO 26262 把大量精力压在 V 模型左侧的需求/架构/分配，而不是右侧的测试。

3.1 失效来源分布（HSE 数据）

英国 HSE 对 34 个化工/石化/机械控制系统事故的分类数据是功能安全领域最常被引用的根因占比——它的关键发现是需求阶段错误占 44 %，远超后期所有阶段之和，这直接决定了 ISO 26262 把概念阶段做成 Part 3 整个独立 Part 的合理性。

失效来源占比
规范（需求）阶段错误44 %
设计阶段错误15 %
实施阶段错误15 %
安装调试错误6 %
运行维护错误20 %

由开发过程的错误引入的常见类别：需求错误（"我以为系统要干 X，实际上要干 Y"）、架构缺陷（共享资源、时序冲突）、软件 bug（算法错误、指针错误、竞态条件）、人为错误（施工错误、调试残留）、接口误解（硬件和软件对同一信号的理解不同）。

3.2 关键特点

系统性失效的三条特性正好与随机失效相反——不能概率化、冗余无效、只能流程预防，三者一起决定了"V 模型 + 评审 + 形式化"是唯一可行的管理路径。

  • 不能用概率描述（它要么存在要么不存在）
  • 冗余无效 —— 两个拷贝同样的软件 bug 还是 bug
  • 只能用流程控制预防：V 模型、评审、形式化方法、测试

HSE（英国健康与安全执行局）的研究——功能安全领域最著名数据：44 % 的危险失效源自需求阶段，而不是实现阶段。这意味着写代码时发现的 bug 远不如需求没想清楚严重；功能安全必须从概念阶段就介入而不是事后"打补丁"；整个 ISO 26262 Part 3（Concept Phase）存在的理由就是这个数字。

HSE 原始数据的工程细节（源：IEC 61508 & Functional Safety-2022 §Primary cause of control system failure）：这份研究名为 Out of Control: Why control systems go wrong and how to prevent failure（HSG238, ISBN 0-7176-2192-8），覆盖 34 个化工/石化/机械行业控制系统事故。60 % 以上的危险失效是在投入运行之前就"内置"进系统的（Specification 44 % + Design & Implementation 15 % ≈ 59 %），这是"发布后才开始真正测试"反模式的量化代价——这也是为什么 ISO 26262 要求 Confirmation Measures 三档（Review / Audit / Assessment）必须在 SOP 之前全部完成。

3.3 工程后果

现代安全关键系统开发中，规范 + 架构 占总工作量的 40～60 %（而不是代码）；每个需求都要有"ID + 来源 + 验证准则 + 追溯链路"；概念阶段的 HARA 输出是后续一切工作的起点，做错了再也回不来。

随机失效靠冗余 + 诊断管理，系统性失效靠流程控制预防——两者不能互相替代，而系统性失效更致命因为 44 % 的危险失效都在需求阶段就埋下了。

核心要点
  • 可靠性 ≠ 安全性：MTBF 高不等于安全，关键看失效模式和失效后果。
  • 随机硬件失效用 FIT 概率化、冗余 + 诊断管理；典型机制 EM / 热疲劳 / 腐蚀 / SEE / TDDB 各有专门加速试验。
  • 系统性失效不能概率化、冗余无效，只能用 V 模型 + 评审 + 形式化方法预防。
  • 44 % 危险失效源自需求阶段（HSE 数据）——这是 ISO 26262 把工作量压在概念阶段的根本原因。

Cross-references