功能安全（Functional Safety）

读完本页后，你应该能够：

• 用一句话说出功能安全与传统可靠性的根本区别，并给出一个反直觉的例子。
• 区分随机硬件失效和系统性失效，说明为什么后者无法用冗余消除。
• 从整车级危害出发，完整走一遍 HARA 流程：项目定义 → 危害识别 → S×E×C 评估 → 安全目标 → 功能安全概念。
• 计算 ASIL 等级（给定 S、E、C 三个维度的值）。
• 解释 SPFM、LFM、PMHF 三个硬件度量指标的含义，以及 ASIL D 的数值要求。
• 正确使用 ASIL 分解规则：D = B+B 可以，D = A+C 不可以，而且两侧必须无共因失效。
• 画出双核锁步 MCU 如何把 SPF 变成可检测事件，把 SPFM 拉到 99%。
• 用 AIAG-VDA 2019 的 AP（Action Priority）方法做一次 FMEA，并解释为什么它比旧版 RPN 更好。

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

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

一个反直觉的例子：

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

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

这个区别决定了功能安全的所有工程实践：

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

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

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

所有失效都可以归入两类，管理方法完全不同：

随机硬件失效（Random Hardware Failures）

由物理退化机制产生，工程上可概率化、可冗余消除。

5 种核心机制对比：

共性特征：

• 可用概率描述（λ = 失效率，单位 FIT = $10^{-}9$/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）。

系统性失效（Systematic Failures）

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

由开发过程的错误引入：

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

特点：

• 不能用概率描述（它要么存在要么不存在）
• 冗余无效 —— 两个拷贝同样的软件 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 之前全部完成。

工程后果：

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

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

汽车界 ISO 26262、航空 DO-178C、铁路 EN 50128 看似各有各的标准,实则全部脱胎自同一本母标准 IEC 61508——通用功能安全标准。母标准定义了 SIL 评级、V 模型、Safety Lifecycle 这些通用概念,各行业标准在此基础上做行业剪裁(如汽车把 SIL 改名 ASIL、增加 Controllability 维度)。理解 IEC 61508 = 同时理解所有功能安全标准的骨架。

IEC 61508 是 1998 年制定的通用基础标准。航空、汽车、铁路、机械、过程工业的所有功能安全标准都以它为基础：

理解 IEC 61508 的核心概念，就理解了所有衍生标准。

衍生标准的精确对应关系（源：IEC 61508 & Functional Safety-2022 §Standalone & sector/product standards）：IEC 62061 机械安全，IEC 61511 过程工业（石化/化工），IEC 61513 核能，IEC 61800-5-2 可调速电气驱动系统，EN 50128/50129 铁路信号，IEC 60601 医疗设备；汽车的 ISO 26262 以及航空的 DO-178C 也是 IEC 61508 思想的分支。"市场逻辑"上这意味着一件事：一个 IEC 61508 认证的元件（如安全 MCU、安全 SBC、安全光耦）可以被声明适用于所有 sector 标准，这就是 NXP / Infineon / TI 喜欢做"Safety Element out of Context"（SEooC）认证的原因——一次认证，多个行业复用。

IEC 61508 的 7 个部分

7 个 Part 不是平等并列,前 3 个是核心强制(总框架 + 硬件 + 软件),Part 4 是术语词典,Part 5-7 是辅助导引。新人入门只需要先读 Part 1+2+3,后续按需查 Part 4 词典。

实际工程中，Part 2 和 Part 3 是核心（硬件和软件要求），Part 5 是入门必读（SIL 怎么定）。

SIL（Safety Integrity Level）等级

SIL 是 IEC 61508 把"安全完整度"量化的尺度,SIL 4 最严,SIL 1 最松。每升一级,允许失效率降一个数量级——这是工程上极强的约束(SIL 4 要求 $10^{-9}$ /h 失效率,需要双冗余 + 物理隔离 + 多重独立监控)。汽车界对应的 ASIL 等级与 SIL 量级相同但维度多一个 Controllability(详见 §4)。

SIL 是 IEC 61508 的核心概念——量化的"安全完整性等级"，具体的失效率要求见上表。

两种操作模式的含义：

• Low Demand（低需求模式）：安全功能只在异常时才被调用（例如：燃气泄漏时才启动切断阀）。用 PFD（Probability of Failure on Demand）量化。
• Continuous / High Demand（连续模式）：安全功能一直在运行（例如：刹车系统一直随时可能被用）。用 PFH（Probability of Failure per Hour）量化。

汽车几乎都是连续模式——刹车、转向、动力总成随时可能失效，必须用 PFH。

SIL 确定的三种方法

1 定量风险矩阵

二维表格：严重度 × 暴露频率 → SIL。简单直接，用于明确的场景。

2 风险图（Risk Graph）

四维：后果 × 频率 × 可避免性 × 需求频率 → SIL。更精细，用于过程工业。

3 保护层分析（LOPA, Layer of Protection Analysis）

量化每一层的失效概率，累计达到目标 PFD：

$需求事件频率\times 保护层1失效概率\times 保护层2失效概率\times ...\le 可接受风险$ LOPA 是过程工业（石化）的主流方法，可以清楚地看到每层保护各贡献多少风险降低。

RRF（Risk Reduction Factor）的直观算法（源：IEC 61508 & Functional Safety-2022 §SILs & Risk Reduction）：IEC 61508 把每个 SIL 带映射到一个 RRF 区间——SIL 1 = 10～100，SIL 2 = 100～1000，SIL 3 = 1000～10000，SIL 4 = 10000～100000。一个具体示例：某工艺致命事故无保护时发生频率约 "1 次 / 10 年"，引入一个 SIL 1 的安全功能（取 RRF = 80），新的危险事件频率就降到 "1 次 / 800 年"——注意后果的严重度没有变，只是频率被 80 倍稀释。这是为什么过程工业同时用两个数字（PFD + RRF）：PFD 给出硬件能力的上限，RRF 给出业务可接受风险的实际降幅。

本质一句话：SIL 是把"系统要多安全"翻译成"它每小时允许多少次危险失效"的量化工具——从主观变客观，从定性变定量。

ISO 26262 是 IEC 61508 在汽车领域的专业化应用。2011 年第一版，2018 年第二版（本文参考 2018 版）。

核心差异：

• 用 ASIL（Automotive Safety Integrity Level）替代 SIL
• 针对量产汽车特点（寿命 15 年、极端温度、软件 OTA、功能组合爆炸）定制
• 从整车级危害出发，HARA 是核心
• 明确了半导体层面的要求（Part 11，2018 年新增）

ISO 26262 与 IEC 61508 的 5 个结构差异（源：Functional Safety for Road Vehicles §2.1；Introduction to Functional Safety for high-voltage systems §ISO 26262）：

• ISO 26262 不使用 EUC（Equipment Under Control）这个 IEC 61508 核心概念——汽车整车已经是一体化的 item，安全功能与被控对象不能干净切分。
• ISO 26262 明确将电击、火、烟、热、辐射、化学反应、能量释放 排除在范围之外（除非 root cause 是电气元件失效）——所以电池包的热失控、电解液腐蚀不属于 ISO 26262，而属于 GB 18384 / ECE R100 等法规。
• 风险评估用 f = E × C 的简化（频率 = 暴露 × 可控性）而不是 IEC 61508 的完整危险事件概率。
• ISO 26262 明确排除"functional inadequacy"（功能充分性不足） ——即算法本身不够好导致的危害属于 SOTIF / ISO 21448 而非 ISO 26262。
• 典型 System 架构：工业用 1oo2（两通道投票，HFT=1），汽车用 1oo1D（单通道 + 诊断，HFT=0）——因为汽车里一个独立第二通道在整车集成、散热、成本上都不可行；IEC 61508 SIL3 ≡ ISO 13849 PL e 要求 min Cat 3（HFT=1），而 ISO 26262 ASIL D 允许 HFT=0 只要诊断覆盖率达到 SPFM ≥ 99%。

ISO 26262(2018) 结构

ISO 26262 共 12 个 Part,但日常工作里真正反复打开的是 Part 3/5/6/9——Part 3 做 HARA 与安全目标,Part 5 算硬件指标 SPFM/LFM/PMHF,Part 6 是软件 V 模型,Part 9 处理 ASIL 分解。其它 Part 是组织管理或确认审计,新人按需查。

实际工作中最常用的是 Part 3（概念）、Part 5（硬件）、Part 6（软件）。

ASIL 等级的典型应用

ASIL 不是工程师拍脑袋定的——是 HARA 评估出来的,S × E × C 三维查表得 ASIL 等级。所以下面这张表说的是"行业经验下这类功能通常落到哪个 ASIL",作为快速参照,真实项目还是要走 HARA 流程。

QM 的含义：不是"不重要"，而是"失效不会造成安全事故"，所以不需要功能安全流程——普通的质量管理（QM = Quality Management）足够。

ASIL 由 S × E × C 矩阵决定

不是数学相乘，而是查表：

S（严重度 Severity） —— 失效对乘员/行人的伤害程度：

• S0：无伤害
• S1：轻伤，可以完全恢复
• S2：严重伤害，可能需要长期治疗
• S3：生命威胁 / 致命

E（暴露概率 Exposure） —— 特定场景发生的频率：

• E0：极少发生（< 0.001%）
• E1：低（> 1% 次数的驾驶里会遇到）
• E2：中等（> 1% 时间的驾驶在该场景下）
• E3：中高（> 10% 时间的驾驶在该场景下）
• E4：高（> 50% 时间的驾驶在该场景下，例如"开车时"本身）

C（可控性 Controllability） —— 驾驶员能否避免伤害：

• C0：完全可控（99%+ 驾驶员能避免）
• C1：通常可控（90%+）
• C2：通常可控但困难（10～90%）
• C3：难以控制（< 10% 能避免）

查表（简化版，单元格按 E1 / E2 / E3 / E4 顺序给出 ASIL 等级）：

一个完整的 ASIL 计算示例：EPS 失效

场景：高速公路行驶中 EPS（电动转向）突然失效。

分析：

• S：方向盘助力失效 → 驾驶员力量不足以控制 → 车辆偏离车道 → 可能致命 → S3
• E：高速公路是日常驾驶常用场景 → E4
• C：100 km/h 时瞬间失去转向助力，即使驾驶员经验丰富，避免事故也非常困难 → C3

查表：S3 × E4 × C3 = ASIL D

后果：EPS 控制器需要：

• 双核锁步 MCU（实现 SPFM ≥ 99%）
• 独立监控 MCU（Checker core，独立评估软件执行）
• 冗余电源、冗余通信
• ISO 26262 Part 3 的完整 HARA + FSC
• ISO 26262 Part 4/5/6 的完整 V&V
• 第三方独立评估
• 安全案例（Safety Case）归档

这就是为什么一个 ASIL D EPS 控制器的开发成本是普通控制器的 5～10 倍。

HARA（Hazard Analysis and Risk Assessment）是 ISO 26262 Part 3 的核心。它把抽象的"安全"要求具体化为可操作的安全目标。

HARA 五步流程

HARA 是从"业务功能"推导到"ASIL 等级"的标准流程,五步串行执行,任意跳步必出错:先识别危害(脱离人闷头工作),再算 S×E×C,再凝练成安全目标,再分配到部件。这五步背后的逻辑链是"从用户视角的危害一路推到工程师能改的部件",每一步是上一步的精化。

一个完整 HARA 示例：EV 电机控制器

下表用 EV 电机控制器一个项目走通 HARA 全流程的实例——同一个系统在不同工况下产生完全不同的 ASIL(高速意外加速 D 级、中速意外反转 B 级、低速过流 A 级)。这就是 HARA 的关键发现:ASIL 是工况相关而不是部件固有——所以 HARA 必须穷举工况,不能只考虑"标称工况"。

安全目标：SG1 = 防止意外加速(≤100 ms STO)；SG2 = 防止反转；SG3 = 通知驾驶员；SG4 = 波动<5%；SG5 = 停车禁止输出。

运行场景（部分）：

• S1：停车
• S2：低速爬行 (< 30 km/h)
• S3：中速（30～80 km/h）
• S4：高速（> 80 km/h）

功能失效模式（部分）：

• M1：电机输出意外最大正转矩
• M2：电机意外反转
• M3：电机失去转矩
• M4：电机转矩波动

交叉组合给出危险事件（部分），对每个评估 ASIL（结果见上表）：

SG1 是整个系统的最高要求。它的 FSC 展开可能是：

• FSR1.1：MCU 通过双核锁步检测自身失效 → 100 ms 内触发 STO
• FSR1.2：栅极驱动 IC 独立监测 $V_{CC}$ 和短路 → 硬件 STO
• FSR1.3：IGBT/SiC 模块自带过流保护 → 硬件切断
• FSR1.4：MCU 独立的"看门狗"定期刷新 → 看门狗超时 → 硬件 STO

三层保护：MCU 软件 + 驱动 IC 硬件 + 模块硬件——任何一层触发都能实现 STO。这是 ASIL D 典型的冗余架构。

FTTI（Fault Tolerant Time Interval）是 FSC 中最容易被忽视的数字（源：nxp-whitepaper-High-VoltageInverterSafetySystemConceptforISO26262 §Functional Safety Concept）：它是从"故障发生"到"必须进入安全状态"的最长允许时间窗，决定了整条诊断链（检测 + 去抖 + 反应）的实时预算。NXP HV 逆变器参考设计把所有五个 FSR（命令完整性、传感器合理性、转矩监控、故障上报、Safety Manager 状态机）统一设为 FTTI = 200 ms。这意味着如果某个 safety mechanism 需要 50 ms 检测 + 30 ms 去抖 + 80 ms 软件响应 = 160 ms，就只剩 40 ms 给硬件切断和机械响应——FTTI 不留余量就会违反安全目标。FTTI 必须在 Part 3 就定下来，往后的 Part 4 / Part 5 / Part 6 设计都在这个预算里分配。

HARA 的常见陷阱

HARA 翻车多数不是工具用错,是思路偏差——下面四个陷阱按"场景 / 失效模式 / 评分 / 目标表述"四维分,每维都对应到 HARA 五步中的某一步打折扣。

• 场景遗漏：只想到了常见场景，忽略了紧急制动、雨天湿滑、坡道起步等边缘场景
• 功能失效遗漏：只想到了"不工作"，没想到"工作过度"、"工作反向"、"工作延迟"
• ASIL 低估：过于乐观的 C 评估（"驾驶员肯定能应付"），实际上多数人应付不了
• 安全目标太宽泛："系统应当安全"——这不是目标，是废话；应该是"在 X 条件下 Y 时间内达到 Z 状态"
• 遗漏依赖失效：多个功能共享一个电源/时钟/软件库时的共因失效

工程做法：

• HARA 必须跨团队评审（系统工程师、安全工程师、应用专家、独立第三方）
• 所有 HARA 输出必须可追溯到后续开发文档
• 每次需求变更都要重新评审相关 HARA 条目

本质一句话：HARA 的价值不在于产生文档，而在于强迫开发团队系统性地枚举所有可能的危险场景——遗漏一个场景，整个安全方案就多一个盲点。

ISO 26262 Part 5 用三个定量指标衡量硬件安全性。这三个数字决定了一个硬件架构能否达到目标 ASIL。

三个核心指标

ISO 26262 Part 5 用三个独立指标量化硬件安全度量,三者从不同维度评价同一件事：SPFM 看"诊断能不能在单点故障发生时及时发现"、LFM 看"诊断能不能在潜伏故障变成第二点故障前发现它"、PMHF 看"整体危险失效率是否够低"。三者必须同时达标才算硬件 ASIL D 合格——任一指标卡线就要返工诊断。

三者的关系：SPFM 和 LFM 衡量架构质量（诊断覆盖得多彻底），PMHF 衡量最终风险（每小时出事概率）。SPFM/LFM 过关但 PMHF 超标，说明元件本身 FIT 太高；PMHF 过关但 SPFM 低，说明有单点没覆盖。三项缺一不可。

失效模式五分类（Part 5 §8）

每种失效模式先按是否影响安全目标筛出 Safety-Related (SR)，再对 SR 的部分按是否被 Safety Mechanism 覆盖和是否立即致命细分：

计算路径（后续小节用到这些量）：

${\lambda }_{SPF},residual=\Sigma {\lambda }_{SR}\cdot (1-K_{DC},SPF),{\lambda }_{MPF},latent=\Sigma {\lambda }_{SR}\cdot (1-K_{DC},MPF)\cdot (1-K_{DC},LF)$ $K_{DC},SPF$ 和 $K_{DC},LF$ 分别是针对该失效模式的两级覆盖率：前者看"主 SM 有没有抓住 SPF"，后者看"自检 SM 有没有抓住主 SM 自己的失效"。

Safety Mechanism（SM）详解

定义（ISO 26262-1）：用来检测、指示、处置或控制失效，从而保持或达成安全态的技术方案。SM 不是抽象概念——每一条都必须能在 Safety Manual 或设计文档里写出检测原理 + 检测时间 + 覆盖率三件事。

三层分类（ISO 26262-5 Annex D）：

车规 MCU 常见 SM 菜单（同时也是 Safety Manual 的标配清单）：

• CPU：lockstep 锁步 + checker、BIST（Boot-time / Run-time）、stack monitor
• 总线：CRC、奇偶、Parity；End-to-End 通信保护（E2E 协议）
• 内存：SRAM ECC、Flash ECC、MBIST、Address line test
• 时钟：独立参考时钟 + frequency monitor、PLL lock detect
• 电源：VR monitor、UV/OV detect、LDO current limit
• 中断：ISR 运行时间监控、miss interrupt detect
• I/O：output readback、independent monitor channel
• 系统：external SBC watchdog（window challenger）、ASIL-B FSM 独立域

SM 设计铁律：

1. 独立性优先：SM 与被监控对象不能共用关键资源（时钟、电源、总线），否则同一根因把两边都打倒 → 属于 DFA 要查的 Common Cause
2. 检测时间 τ_det 必须 ≤ FTTI（故障容错时间区间 — 危害发生前允许的窗口）；例如刹车 FTTI 100 ms，看门狗窗口就必须 ≤ 80 ms 预留执行缓冲
3. SM 自己也会失效——它的失效落入潜伏类别，必须有二级自检（POST + PDT）覆盖

Diagnostic Coverage（DC）——如何估值

定义：在某类失效模式中，被 SM 检出的比例。Part 5 §8 给出估算范围（低 60 % / 中 90 % / 高 99 %），不是随便写的。

三档对应的技术证据：

DC 估算的合法手段（按证据力度从强到弱）：

1. 故障注入实验（Fault Injection） — 在 RTL 仿真或实际硅上 stuck-at / 翻转；ISO 26262-11 对 SoC 强推荐；可直接产出 DC 数字
2. formal verification — 用 SymbiYosys / Cadence JasperGold 穷举覆盖证明某些失效模式必被检测
3. Failure Mode Distribution（IEC 61508 Annex D） — 对齐厂商标准，如 DRAM 的 stuck-at : bridging : open = 85 % : 8 % : 7 %
4. Expert Judgment — 只能用于 DC ≤ 60 %，必须配多名评审签字

DC 虚高的三个常见坑（Safety Assessor 最爱挑的）：

• 把"可检出频率"当成"失效覆盖" — 比如 CRC 10 ms 检一次，但失效在 CRC 之间已经造成危害 → 实际 DC 可能 0 %
• 重复计算 — 同一 SM 同时声称覆盖两个不相关的失效模式，双算 → 总覆盖率超 100 %
• 忽视 DC 对 FTTI 的依赖 — SM 检测慢于 FTTI 等于没检测（对 Safety 而言）

DC 与 τ_test 的耦合（LFM 专属）：

DC_{effective} = DC_{instantaneous} \cdot (1 - (\tau _{test})/(\tau _{lifetime}))^-^1 直观说：测试周期越长，两次自检之间可能"潜伏"的时间越长，有效 DC 越低。这就是为什么 PDT 周期设置（100 ms ～ 1 s）比表面看起来更关键。

SPFM 计算——单点故障覆盖率

公式：

$SPFM=1-(\Sigma {\lambda }_{SPF}+\Sigma {\lambda }_{Residual})/(\Sigma {\lambda }_{SR})$ 分子是没被 SM 抓住的部分（SPF 全部 + Residual = SM 的漏网之鱼）；分母是所有 Safety-Related 的失效率。

推导：把 λ_SR 按"是否被 SM 覆盖"切成两段：

${\lambda }_{SR}=\underset{被}{\underbrace{{\lambda }_{SR}\cdot K_{DC},SPF}}覆盖+\underset{Residual}{\underbrace{{\lambda }_{SR}\cdot (1-K_{DC},SPF)}}+\underset{无}{\underbrace{{\lambda }_{SPF}}}SM$ 代入得 $SPFM=({\lambda }_{SR}\cdot K_{DC},SPF)/({\lambda }_{SR}+{\lambda }_{SPF})$（无 SM 的元件没有 $K_{DC}$，直接计入分子罚款项）。

ASIL 目标（ISO 26262-5 Table 4）：ASIL B ≥ 90 %、C ≥ 97 %、D ≥ 99 %。ASIL A 不强制。

达不到 D ≥ 99 % 的常见原因：

• 大量 Safe 分类被错标为 Safety-Related（分母虚高）
• 对模拟元件（ADC / DAC / 运放）DC 估得过低，SPFM 被拉下去
• 没用锁步或 TMR 时，CPU 内部故障只能靠运行时自检（DC 难到 90 %）

LFM 计算——潜伏故障覆盖率

公式：

$LFM=1-(\Sigma {\lambda }_{MPF},latent)/(\Sigma {\lambda }_{SR}-\Sigma {\lambda }_{SPF}-\Sigma {\lambda }_{Residual})$ 分母是已被主 SM 覆盖的失效率（= λ_SR 减去单点和残余）；分子是其中主 SM 自己失效且没被二级自检抓住的部分。

直观意义：LFM 衡量"诊断系统本身健不健全"。LFM 低意味着主 SM 的失效会被留在系统里当定时炸弹。

ASIL 目标：ASIL B ≥ 60 %、C ≥ 80 %、D ≥ 90 %。

提升 LFM 的手段：

1. POST + PDT — 启动自检 + 运行时周期自检（τ_test 通常 100 ms）
2. 双 SM 独立冗余 — 锁步比较器本身被独立 BIST 验证
3. SM 的 SM — 看门狗由二级独立 SBC 监控；ECC 的错误计数器被读取上报
4. 周期性切换主备 — 热备 SM 隔一段时间主备对调，防止备份 SM "长时间没用坏了不知道"

常见陷阱：LFM 分母吃亏——如果 SPFM 非常高（比如 99.9 %），Residual 几乎为 0，被覆盖的部分接近 λ_SR，分母最大 → 分子中 λ_MPF,latent 要更严格压下去才能达标。SPFM 拉满反而让 LFM 压力变大。

PMHF 计算——每小时危险失效概率

定义（ISO 26262-5 §9.4.2）：一次安全目标违反的等效平均每小时概率，单位 FIT = $10^{-}9$/h。

一阶近似（大多数工程默认用这个，适用于 λ·T ≪ 1 的情形）：

$PMHF\approx \underset{SPF}{\underbrace{\Sigma {\lambda }_{SR}\cdot (1-K_{DC},SPF)}}+Residual贡献+\underset{潜}{\underbrace{\Sigma {\lambda }_{SR},i\cdot {\lambda }_{SR},j\cdot {\tau }_{test}}}伏失效+后续失效的组合项$ 含义：

• 第一项是 SPF/Residual 的直接贡献（线性于 λ）
• 第二项是两步失效：第一个失效潜伏 τ_test 时间，期间第二个失效到来 → 发生概率 ∝ λ² · τ_test（τ_test 是 PDT 周期）

精确公式（Part 5 Annex F / Markov 模型）：

$PMHF={\lambda }_{SPF}+{\lambda }_{Residual}+{\lambda }_M,A{\lambda }_M,B\cdot [({\tau }_{test})/(2)+(T_{lifetime}-{\tau }_{test})]$ 其中 $T_{lifetime}$ 是车辆寿命（通常 10,000 ~ 15,000 h）。τ_test 在第二项里线性影响 PMHF——PDT 周期每缩短 10 倍，潜伏组合的贡献也缩 10 倍。

ASIL 门槛：

工程中 PMHF 算不过的 3 条出路：

• 降 λ：选更高等级元件（AEC-Q100 Grade 0 比 Grade 1 FIT 通常低 30 %）；降结温 10 ℃ 约减半
• 升 $K_{DC}$：加更好的 SM（锁步 + ECC + BIST 三件套）
• 缩 τ_test：PDT 从 1 s 缩到 100 ms，潜伏项立降一个数量级

PMHF vs SPFM/LFM 的常见错觉：三者不是线性相关。有团队把 SPFM 刷到 99.99 % 但没管 τ_test，结果 PMHF 潜伏项爆掉。三个数字必须同时满足 Table 4/5/6，缺一不可。

单点故障 vs 潜伏故障——关键区别

正常状态：MCU 与诊断监控器互相监测

两步失效演化：

单点故障（SPF）：一个元件失效就导致安全功能丧失（系统中没有冗余覆盖它）。

潜伏故障（LF）：一个元件失效不会立即致命，但它会悄悄"禁用"诊断机制——当另一个元件后来失效时，由于诊断已被禁用，系统无法检测这个失效。"两步失效"（见上图示例）。

潜伏故障的危险在于它是"时间炸弹"——只要它不被检测到，就一直埋在那里，等另一个故障到来时引爆。

解决潜伏故障的方法：周期性测试诊断机制本身（Safety Mechanism Self-Test）。典型做法：

• 每次启动时自检（Power-On Self-Test，POST）
• 运行中周期性测试（Periodic Diagnostic Test，PDT）
• 典型周期：每 100 ms～1 s 一次

ASIL 对三个指标的数值要求

ASIL 等级越高,三个指标全线收紧——D 比 C 严一档,C 比 B 严一档。SPFM/LFM 是百分比、PMHF 是绝对值——前两者随 ASIL 阶梯式提高(每升一级 +约 10 个百分点),后者按 10× 量级降。所以从 ASIL B 升到 ASIL D 的代价是巨大的(诊断覆盖率每提 10% 都需要新增一组监控机制)。

ASIL A 对三个指标均无硬性要求。

"FIT"（Failure In Time）= 失效率单位 = 每 $10^9$ 小时 1 次失效 = $10^{-}9$ / h

ASIL D 要求 < 10 FIT 意味着：硬件每 $10^8$ 小时（约 11,000 年）才被允许出现一次危险失效。这个数字看起来不可能达到，但通过冗余和诊断将"危险失效"变成"可检测失效"，就可以在保持底层 FIT 率不变的前提下把危险失效率压到目标以下。

一个具体的计算示例

假设一个 MCU 有 10 种可能的内部故障模式：

• 2 种会立刻导致安全功能失效（SPF） → 称为 SPF 故障
• 3 种会悄悄禁用诊断（LF）
• 5 种被诊断机制直接检测和处理

如果没有任何诊断：

• SPFM = 0%（所有 2 种 SPF 都未被覆盖）
• LFM = 0%（所有 3 种 LF 都未被覆盖）
• → 达不到任何 ASIL

加入双核锁步监控：

• 2 种 SPF 中有 1.98 种被两核结果比较检测（覆盖率 99%）
• 3 种 LF 中有 2.7 种被周期性自检检测（覆盖率 90%）
• → SPFM = 99%，LFM = 90% → 满足 ASIL D

SN 29500 与失效率 λ 的源头

SN 29500（Siemens Norm 29500，1986 起，对应 IEC 61709）是工业界事实上的失效率数据库标准——几乎所有 FMEDA 的 λ 都可以回溯到这本 Siemens 内部标准。它与 IEC 62380 / MIL-HDBK-217F / FIDES / British Telecom HRD5 并列四大可靠性预测源，但 SN 29500 在欧洲车规 / 工业 / 医疗领域用得最广。

内部结构（11 个 Part）：

核心公式（每种元件都是这个范式）：

$\lambda ={\lambda }_{ref}\cdot {\pi }_U\cdot {\pi }_T\cdot {\pi }_I\cdot {\pi }_{\tau }\cdot {\pi }_{env}$

工程举例：1 kΩ MELF 精密电阻

• ${\lambda }_{ref}$ = 0.05 FIT（Part 3）
• ${\pi }_T$ = 1.4（90 ℃ 结温）
• ${\pi }_U$ = 0.8（用在 0.5 × 额定电压）
• ${\pi }_{env}$ = 3.5（车载非防护舱）
• λ = 0.05 × 1.4 × 0.8 × 3.5 ≈ 0.196 FIT

SN 29500 vs IEC 62380 vs MIL-HDBK-217F：

ISO 26262-5 Annex F 明确：允许使用 SN 29500 / IEC 62380 / FIDES 数据，但必须声明来源 + 置信水平 + 温度参考点 + 使命剖面假设——否则 Assessment 会挑战你的 λ 数字。

常见错误 3 条：

1. 把 ${\lambda }_{ref}$ 40 ℃ 直接用到 105 ℃ 结温 → 漏算 ${\pi }_T$，实际 λ 被低估 5~10×
2. 用民品 / 消费级 ${\lambda }_{ref}$ 套车规 → ${\pi }_{env}$ 不对；车规建议 3.0~5.0
3. 混用 60 % 和 90 % 置信 → Safety Case 要求置信统一，通常 ISO 26262 ASIL D 要用 90 %

防单点失效（防 SPF）手段深入

目标：把"一个元件失效就违反 Safety Goal"压缩到接近零，让 SPFM ≥ 99 %（ASIL D）。本质是让失效传播被中断或重做一遍。

五大类技术：

元件级 SM（防 SPF 在硬件层的落地）：

• RAM/Flash：SECDED ECC（Single-Error Correct, Double-Error Detect）
• 总线 / 通信：数据 CRC + 地址校验 + 时间戳
• 寄存器：关键寄存器写后回读比对；镜像寄存器（mirror + XOR check）
• 时钟：两路独立时钟源交叉频率监测（Clock Monitor Unit）
• 电源：两路独立 LDO / BG，互相监测 $V_{ref}$
• 输出驱动：DESAT 短路检测、过流保护、过温保护

工程指标：

• 单点故障检测时延 ${\tau }_{det}$ 必须 ≤ FTTI / 2（留缓冲给反应时间）。刹车 FTTI 100 ms → ${\tau }_{det}$ ≤ 50 ms
• 检测后进入 Safety State 的反应时间 ${\tau }_{react}$ 也要纳入计算：${\tau }_{det}+{\tau }_{react}\le FTTI$

常见反模式：

• 锁步两核共用同一时钟/电源 → 时钟故障让两核同时错 → 比较器察觉不到 → 属于 CCF 漏洞
• 软件"锁步" — 在同一核跑两份代码比较；软件 bug 或 ISR 卡死时两份都错；不算合法 SPF 防护
• 只靠 E2E 不管发送端完整性 → 发送端硬件错误照样绕过 E2E

防潜伏失效（防 LF）手段深入

目标：LFM ≥ 90 %（ASIL D）。核心逻辑是让诊断机制自己也会被检测——SM 失效不能悄悄潜伏，必须被察觉。

四大技术方向：

典型实现：

• MBIST（Memory BIST）— 对 RAM / Flash 做内置自检；启动阶段全量扫，运行时 Concurrent MBIST 分块扫
• LBIST（Logic BIST）— 数字逻辑用 Scan + LFSR 生成激励比对响应
• ECC 错误计数 — 统计周期内可纠 1-bit 错误数量；超阈值报警（说明 ECC 即将失效）
• 看门狗自测试 — 主 MCU 故意让看门狗触发一次，确认 reset 链路是否还活着（上电时做）
• Challenger watchdog — SBC 主动发挑战 → MCU 答；MCU 挂死则 SBC 拉 FS0b（示例：NXP MC33907/08 FSM）
• Dual path sensor readback — 主通道 + 独立监控通道都采同一物理量，两者数据不一致则主通道 SM 失效

LFM 计算中的 τ_test 影响（回顾 §6.PMHF）：

$PMH{F}_{latent}\approx {\lambda }_A\cdot {\lambda }_B\cdot {\tau }_{test}$ τ_test 每缩短 10 倍，潜伏项贡献降 10 倍。这是LFM 工程的最大杠杆——不是加更多 SM，而是缩短已有 SM 的自检周期。

MPF Detected vs MPF Latent 的转换：核心技巧是把 Latent 变成 Detected：

• 未被察觉的 SM 失效 = Latent，计入 λ_MPF,latent
• 被次级 SM 或 BIST 抓住的 SM 失效 = Detected，不再计入 LF 分子

从计算角度：每条"次级监控"增加 $D{C}_{MPF}$，分子直接缩小。

两个工程陷阱：

• POST 测不到运行时浮动的失效（比如温度升高才出现的 stuck-at）→ 必须有 PDT 补漏
• PDT 跑得太慢：把 τ_test 设到 10 秒看起来 CPU 占用低；但 λ² · τ_test 一项直接乘 10 → PMHF 爆掉。τ_test 是 LF / PMHF 的核心参数

实现这些指标的硬件手段

诊断机制：

• 内存 ECC（Error-Correcting Code）：RAM/Flash 的每一位都有校验，单位错自动纠正
• 总线 CRC：外设通信都带 CRC 校验
• 寄存器周期测试：每 100 ms 测试所有关键寄存器是否能正确读写
• 时钟监测（Clock Monitor）：独立振荡器监测主时钟是否正常
• 看门狗（Watchdog）：一种更通用的"程序还在跑"检查
• 电源监测：监测 $V_{CC}$ 是否在范围内（典型 ±5%）

现代汽车 MCU（Infineon TC3xx、NXP MPC57xx、Renesas RH850）把这些机制全部集成到芯片里，数据手册直接给出"Safety Manual"列出所有 Safety Mechanism 以及它们对应的覆盖率数字。

SBC / 伴随 IC 的 Fail Safe Machine 设计哲学（源：Integrating the MPC5643L and MC33907:08 for Safety Applications §3.4）：一个安全 MCU 光靠自己不够——它的电源本身可能失效。NXP MC33907/08 SBC 里有专门的 FSM（Fail Safe Machine），由 4 个子块组成：Voltage Supervisor（VS）、Fail Safe State Machine（FSSM）、Fail Safe Output driver（FSO）、Built-In Self Test（BIST）。关键是 FSM 自带独立的 bandgap、振荡器、模拟 + 数字电压源，并在版图上物理隔离，所以即使主电压路径失效，FSM 仍能工作——这是 ASIL 分解"两侧不得共享电源/时钟"的硬件落地。另一个关键机制是 Windowed Challenger 看门狗：SBC 定期向 MCU 发一个"挑战"，MCU 必须在打开的时间窗内算出正确答案回发，错过窗口（早或晚）或答案错误都会触发 FS0b（fail-safe output）。这比传统"定时刷新"看门狗能检测更多的 MCU 卡死/错误跳转/时钟漂移模式。

双核锁步的物理示意

双核锁步(Lockstep)是 ASIL D MCU 的标配硬件冗余——两个 core 跑同一段代码,每个时钟周期比较输出,任何一个 core 故障会立刻被另一个 core 通过比较器发现。这不是"双计算 + 多数表决",而是"同步执行 + 单一比较"——所以两个 core 每条指令都必须完全一致。下图给出 Lockstep 的最小拓扑。

为什么能达到 SPFM 99%：

• 任何一个核里发生故障 → 两核输出不一致 → 比较器触发
• 例外情况：比较器本身失效 → 靠定期自检捕获（属于 LF 覆盖）
• 例外情况：两核同时发生相同故障（SEE 穿过两个核）→ 概率极低，计入未覆盖 1%

Infineon AURIX 2G 家族的两个代表：

• TC397（高端）：三核锁步 + 一个 Checker，甚至用于 ASIL D 中要求最高的应用（ADAS L3+）
• TC38x（主流）：4 核 TriCore TC1.6.2P @ 300 MHz，其中 2 核有锁步影子核。片上 SMU（Safety Management Unit）汇集所有安全告警、IOM（I/O Monitor）交叉校验数字 I/O、MTU（Memory Test Unit）做 ECC + MBIST。全部 NVM / SRAM 有 ECC 保护。ISO 26262 Safety Element out of Context 认证，ASIL D capable。典型用于发动机控制、变速箱控制、底盘控制等需要丰富外设但不需要三核锁步的场景

Sphere of Replication（SoR）——比"双核锁步"更精确的术语（源：Integrating the MPC5643L and MC33907:08 for Safety Applications §2.1）：很多工程师以为"双核锁步"只是 CPU 核复制。实际上，NXP MPC5643L 的 SoR 同时复制 9 个模块：CPU 核、DMA 控制器、中断控制器、交叉条总线系统、内存保护单元（MPU）、Flash 和 RAM 控制器、外设总线桥、系统定时器、看门狗定时器。每个 SoR 输出都挂了一个 RCCU（Redundancy Control and Checker Unit） 做比较；全片还有 FCCU（Fault Collection and Control Unit） 把所有 RCCU 告警、ECC 错误、片外 PIN 错误汇集到一个硬件通道，不需要 CPU 介入就能把输出 PIN 拉到安全态——CPU 本身可能已经冻死在 bug 里，所以安全响应必须绕过它。这是 ASIL D MCU 架构的真正完整定义。

ASIL 分解（ASIL Decomposition） 允许把一个高 ASIL 的安全目标分解给两个（或更多）独立的子系统，每个子系统负担更低的 ASIL。

合法的分解组合

ISO 26262 允许以下分解（每次只能降一级）：

ASIL D = ASIL D(A) + ASIL QM(B)
ASIL D = ASIL C(A) + ASIL A(B)
ASIL D = ASIL B(A) + ASIL B(B)    ← 最常见

ASIL C = ASIL C(A) + ASIL QM(B)
ASIL C = ASIL B(A) + ASIL A(B)
ASIL C = ASIL A(A) + ASIL A(B)

ASIL B = ASIL B(A) + ASIL QM(B)
ASIL B = ASIL A(A) + ASIL A(B)

ASIL A = ASIL A(A) + ASIL QM(B)

非法的分解

不允许 ASIL D = ASIL A + ASIL C！为什么：两边等级不平衡（一边 A 一边 C），风险集中在 C 那一侧，而 A 那侧几乎做不了任何贡献。ISO 26262 要求分解后两个子系统的等级相同或接近。

独立性是关键

分解的先决条件：两个子系统必须独立，无共因失效（CCF, Common Cause Failure）。

独立性要求：

• 不共享电源（至少不共享同一 LDO 的输出）
• 不共享时钟（不来自同一晶振）
• 不共享软件库（至少不共享关键函数的实现）
• 不共享通信总线（或者总线本身做了独立冗余）
• 不共享算法（用不同的算法实现同一功能）

DFA（依赖失效分析，Dependent Failure Analysis） 是 ISO 26262 Part 9 的强制要求——必须证明两侧之间的所有可能共因都被分析过，并且都没有可感知的依赖。

ASIL 分解的典型应用

ASIL 分解不是简单"加冗余"——核心要求是 DFA(Dependent Failure Analysis)证明两路真独立。下图把分解后系统的物理独立性约束画出来:独立电源、独立时钟、独立 SPI 路径——任意共享因素(共电源/共时钟/共编译器)都会让分解失效。这就是为什么 ASIL 分解工程上比看起来难。

EPS 控制器的分解架构：

这比用一个 ASIL D 单片 MCU 便宜得多——两个 ASIL B 器件加起来的开发成本远低于一个 ASIL D。

常见陷阱

ASIL 分解被滥用最常见的三种误解都源于**"独立性"概念的不严谨**——只看到表面的"两套",没有真正分析共因失效。这三条陷阱实务里几乎每个新做 ASIL D 的项目都要踩一次。

• "冗余就是分解"：错。冗余只是分解的充分条件之一，还要求两侧独立和 DFA 通过
• "软件拷贝两份就是分解"：错。软件 bug 在两份拷贝里同时出现，这是共因失效
• 分解后 ASIL 就不管了：错。每个子系统仍然要按其分到的 ASIL 做 V&V

本质一句话：ASIL 分解是功能安全的"降级法宝"，可以让开发成本大幅下降——但它要求严格的独立性和DFA 分析，做不好就是自欺欺人。

HV 逆变器的"三种安全态"——安全状态不是唯一的

一个高频被误解的问题（源：nxp-whitepaper-High-VoltageInverterSafetySystemConceptforISO26262 §Safe State Definition）：EV 主驱逆变器检测到故障后，"安全态"到底是什么？直觉答案是"把 6 个 IGBT 全关掉"（3-Phase Open, $S{S}_{3PO}$），但这在高速行驶时反而危险——电机仍以转子惯量转动，打开所有开关会让反电动势通过反并联二极管对直流母线充电，同时在机械轴上产生制动转矩，相当于瞬间抱死驱动轮。因此 ISO 26262 HV 逆变器参考设计定义了三种互补的安全态：$S{S}_{HSS}$（短接三个上管 HS → 电机三相短路，电流在定子内部环流），$S{S}_{LSS}$（短接三个下管 LS → 同效果），$S{S}_{3PO}$（打开全部六个开关）。选择规则与车速绑定：高速用 HSS/LSS（短路态，电机自然滑行直到低速），低速用 3PO（无制动，直接脱开）；速度阈值由电机反电动势与直流母线电压的关系决定，通常在 20～40 km/h。这意味着 safety manager 里必须有速度判据 + 条件分支，不能写"发现故障 → 切断 PWM"这样的幼稚伪代码。

IEC 61800-5-2 的标准化驱动安全函数词汇表（源：Introduction to Functional Safety for high-voltage systems §Industrial drives/machinery standards）：工业变频器 / 伺服驱动领域有一套与 ASIL 平行的预定义安全函数，由 IEC 61800-5-2 规范：

• STO（Safe Torque Off）：切断电机转矩产生能源——最基础
• SS1（Safe Stop 1）：受控制动然后进入 STO
• SS2（Safe Stop 2）：停止并保持位置锁定（不进入 STO）
• SOS（Safe Operating Stop）：停止但伺服仍激活
• SBC（Safe Brake Control）：控制外部机械抱闸
• SLS / SLT / SSM / SMT / SCA：Safely-Limited Speed / Torque / Speed Monitor / Motor Temperature / Safe Cam

实现 STO 至少有 5 种物理途径（源：同上 §Realizing safe torque off）：1 断开 AC 母线侧接触器，2 断开电机侧接触器，3 Safe Pulse Block（切断栅极驱动 IC 的供电），4 禁用 PWM 信号链（通过双路安全信号 + 逻辑门），5 把转矩参考值软件置零（最弱——因为靠处理器）。TÜV SÜD 评估的工业参考设计（TI TIDA-01599）用的是第 3 种——两路 STO 信号分别控制上下桥的隔离栅极驱动电源，单路失效不会让任意管子导通。这对 EV 主驱的启示：汽车 ASIL D 的"等效 STO"必须做到栅极驱动级的冗余，不能只靠 MCU PWM 停发。

FMEA（Failure Mode and Effects Analysis）：失效模式与影响分析。功能安全开发中最常用的系统性分析工具。

DFMEA vs PFMEA

DFMEA 与 PFMEA 切分的是问题源头——前者管"设计本身有没有缺陷"、后者管"生产工艺会不会引入缺陷"。两者解决独立问题不能替代——一个 DFMEA 通过的产品如果 PFMEA 漏项,生产会引入缺陷;一个 PFMEA 严密的产品如果 DFMEA 没做,设计本身就缺陷。下面给出两者基本对照,详细方法论见 FMEA 方法论。

• DFMEA（Design FMEA）：在设计阶段，分析产品设计本身的失效模式
• PFMEA（Process FMEA）：在制造阶段，分析生产过程的失效模式（如装配错误、焊接缺陷）

本节重点讨论 DFMEA，因为它是功能安全设计的主要工具。

AIAG-VDA 2019 的改进：从 RPN 到 AP

旧方法 RPN（Risk Priority Number）：

$RPN=S\times O\times D（严重度\times 发生概率\times 探测度，每项110分）$ 问题：不同组合可能得到相同 RPN。例如：

• S=10, O=1, D=1 → RPN = 10
• S=1, O=10, D=1 → RPN = 10
• S=1, O=1, D=10 → RPN = 10

但这三个情况完全不一样：第一个是"可能致命但概率极低"；第二个是"常见轻微问题"；第三个是"微不足道的难以检测问题"。第一个绝对是最需要关注的，但 RPN 看不出来。

新方法 AP（Action Priority）：

不再简单相乘，而是查表。S、O、D 的组合映射到三个优先级：

H (High)    必须采取行动
M (Medium)  推荐采取行动
L (Low)     可选

关键变化：

• 高 S 永远优先 —— 即使 O 和 D 很低，高 S 项仍可能是 H 或 M
• 严重度 10 的项永远不会被"掩盖" —— 即使 O=1, D=1，也不会被判为"不重要"

这符合功能安全的哲学："严重度决定一切，不能用低概率或好检测来掩盖严重度"。

FMEA 实施步骤

FMEA 不是想到什么写什么——按 9 步固定顺序做。前 5 步定义"问题"(范围 / 功能 / 失效模式 / 影响 / 起因)、6-7 步给"现状"(现有控制 + 评分)、8-9 步给"未来"(改进措施 + 闭环)。这条流程是 AIAG-VDA 7 Step 的早期版本,新法详见 FMEA 方法论 §2。

Step 1  定义范围（系统/子系统/组件）
Step 2  功能分析（这个组件做什么？）
Step 3  失效模式识别（这个组件怎么坏？）
Step 4  失效影响分析（坏了会怎样？）
Step 5  失效原因分析（为什么会坏？）
Step 6  现有控制措施（预防 / 探测）
Step 7  评分 S、O、D
Step 8  查 AP
Step 9  AP = H 的必须采取行动，定义改进措施、责任人、完成日期
Step 10 跟踪行动完成情况，重新评分

举例：MOSFET 栅极驱动电路的 FMEA 片段

把抽象 FMEA 流程套到 MOSFET 栅极驱动这个具体电路上,看一组失效模式怎么评分得到 AP 优先级。关注表里 S 列——DESAT 检测阈值漂移偏高时 S=9(高 ASIL 安全相关),即使 O=2/D=7 也被评为 H 优先级——这就是新法 AP 替代 RPN 的核心逻辑(高 S 必为 H 不论 O/D)。

改进措施：驱动 IC → 增加输出电压监测；DESAT → 必须 DESAT 自检+精度比较器；Bootstrap → 必须 $V_{BS}$ 监测+诊断回读；$V_{CC}$ → UVLO 保护；$R_G$ → 双并联冗余。

关键洞察：DESAT 阈值漂移的 AP = H，必须采取行动。不能因为"我们相信元器件质量"就跳过——高 S 的项必须被主动处理。

FMEA-MSR：2019 年 AIAG-VDA 新增的第三种 FMEA

Supplemental FMEA for Monitoring and System Response（FMEA-MSR） 是 2019 版手册相对旧版 AIAG 4th / VDA 4 最大的新增（源：AIAG VDA FMEA Handbook §4.1～§4.5）。它解决的是 DFMEA 回答不了的问题：产品已交付到客户手中，运行期内硬件/软件故障能否被诊断监控检测到并触发正确的系统响应，从而维持安全或合规状态？

DFMEA 用 S/O/D 打分，FMEA-MSR 用 S/F/M 打分：

• S（Severity，严重度）—— 与 DFMEA 的 D1 表完全一致
• F（Frequency，频率）—— 不是"每百万辆缺陷数"，而是"整车寿命内原因发生概率"；用 MSR2 表（10=极高，1=不可能）
• M（Monitoring，监控）—— 诊断 + 系统响应的综合能力，用 MSR3 表

M 评分与 ISO 26262 诊断覆盖率直接对齐（关键数字）：

• M = 1：诊断覆盖率 明显 >99.9%（系统总能在 FTTI 内自动反应）
• M = 2：>99.9%
• M = 3：>99%
• M = 4：>97%
• M = 5：90%～97%
• M = 6：>90%（仅上电自检）
• M = 7：>60%
• M = 8：<60%
• M = 10：不能检测 / 不在 FTTI 内反应

三种失效场景：1 无监控 → S=10 直接命中原始 FE；2 可靠监控 → S 被降到 mitigated FE（如 S=10 → S=6）；3 不可靠监控 → 按加权概率两者都要算。工程意义：FMEA-MSR 是第一个把 FMEA 和 FMEDA/ISO 26262 覆盖率数字直接挂钩的方法——以前 DFMEA 的 D 列充满主观，现在 M 列直接对应 DC 百分比，可以从 FMEDA 结果反向填写，不用打分扯皮。

把整个功能安全章节里散见的失效模式收成一张图谱,作为 FMEA 起点参考。这张表按"V 模型阶段"分组——需求阶段失效(场景遗漏)、设计阶段失效(系统性 bug)、运行阶段失效(随机硬件失效),分组对应不同缓解工具。

ISO 26262 项目从启动到 SOP 通常 24~36 个月,关键不是阶段本身,是阶段间的 dependency——HARA 没做完不能定 ASIL,ASIL 没定不能开始硬件设计,硬件设计没冻结不能算 FMEDA。下图给出标准时间线,实际项目的延期 90% 卡在 HARA 评审或 FMEDA 反算。

一个 ASIL D 的汽车控制器项目，时间线大致：

总时长：1.5～2 年是典型的 ASIL D 汽车电子项目开发周期。概念阶段和验证阶段合起来占 40～50% 工作量——不是在写代码，是在做安全论证。

ISO 26262-6 按 V 模型划分六个子阶段（§5～§11），每阶段给一张 ASIL 推荐方法表。表里 ++ = 强烈推荐，+ = 推荐，o = 无建议。下表推荐强度列统一按 A/B/C/D 格式。

软件 V 模型

ISO 26262 Part 6 的软件 V 模型与 ASPICE SWE 完全同构,这不是巧合——两者来源都是 IEC 61508-3。差别在 ISO 26262 多了一层"安全需求"色彩:每条 SSR(软件安全需求)必须追溯到系统级安全目标(详见 ASPICE)。

软件安全需求 (SSR)                软件集成测试
   ↓                                 ↑
软件架构设计 ↘              ↗ 软件架构级集成
              软件单元设计 → 软件单元实现 → 软件单元验证

建模与编码规范（§5, Table 1）

开发启动前必须确定"建模与编码指南"，对 ASIL D 以下主题都是 ++：低复杂度、语言子集、强类型、防御式编程、命名规范。对 C 语言，MISRA C 就是 Table 1 的落地；基于模型开发用 MISRA AC 系列。

架构设计原则（§7, Table 3）

ISO 26262-6 §7 给的架构设计原则按 ASIL A/B/C/D 给出推荐强度——++ 强烈推荐,+ 推荐,o 无意见。表里 4 列对应 4 个 ASIL 等级,从左到右严格度递增。

工程提示：AUTOSAR 分层（BSW/RTE/SWC）天然满足"分层受限"；但"组件大小受限"靠自律——单 SWC 超过 5000 行基本已违反 ASIL C/D 精神。

单元设计 10 条 ASIL D 强制项（§8, Table 6）

这 10 条全是约束代码可分析性的规则——目的让静态分析、形式化验证、单元测试能跑得通。共同点是排除"运行时不可预测"的语言特性(动态分配、递归、无条件跳转、指针),让代码行为在编译期就可推。MISRA C/C++ 大部分规则就是从这里推导出来的。

• 子程序单入口单出口
• 变量初始化
• 禁止变量名多用
• 禁止无条件跳转
• 禁止递归（ASIL C/D ++；A/B +）
• 动态分配禁止或上线检测
• 指针使用受限
• 禁止隐式类型转换

这 10 条在 C 代码中几乎 100% 被 MISRA C 规则覆盖，Polyspace / Coverity / Helix QAC 静态扫一遍即可。

单元验证（§9, Table 7/8）

ASIL D 全列 ++ 的验证方法：Inspection（同行评审）、半形式化验证、控制流分析、数据流分析、静态代码分析、基于需求的测试、接口测试、故障注入、资源使用评估、模型-代码 Back-to-Back。测试用例生成（Table 8）对 ASIL D ++：需求分析、等价类、边界值。

结构覆盖率要求（§9, Table 9）

代码覆盖率的层次从弱到强:Statement < Branch < MC/DC——三者强度依次提高,ASIL 越高要求越严的覆盖类型。理解这条递进关系才能解释为什么 ASIL D 强制 MC/DC——前两者覆盖率即使 100% 也漏掉布尔表达式中某些组合的真值,只有 MC/DC 才真正穷尽决策路径。

MC/DC = Modified Condition/Decision Coverage，每个布尔子表达式都要独立证明能改变判决结果。if (a && b && c) 要 ≥ 4 条用例（分支覆盖只需 2 条）。ASIL D 必须 MC/DC——这是行业里"ASIL D 贵"的主因之一，与航电 DO-178C Level A 同款要求。

软件集成测试（§10, Table 10～13）

接口测试、故障注入、资源使用、背靠背（模型 vs 代码）、基于需求的测试。ASIL D 对全部方法都是 ++。

Safety Case 是"结构化论证 + 证据"的集合，回答"为什么我相信这个 Item 对应 ASIL X 是足够安全的"。所有 Work Product 最终都为 Safety Case 服务。

ISO 26262 规定 Confirmation Measures 三档：

Assessment 必须由组织上独立的团队或外部机构完成；ASIL 分解对 Confirmation Measures 无效——按原 Safety Goal 的 ASIL 做。

13.1 四把尺的分工与互补

功能安全分析有 6 个常用工具(FMEA/FMEDA/FTA/DFA/FSA/HAZOP),每个工具有明确的分工边界——FMEA/FMEDA 自下而上从部件失效推到系统效应,FTA 自上而下从顶事件分解到基事件,DFA 横向分析共因和级联失效。这条分工正是为什么"只做 FMEA 就够了"的项目最后会被 OEM 退回——FMEA 看不到 FTA 能发现的多重失效组合。

四件套协同工作：FTA 从 Safety Goal 顶向下拆到硬件/软件基事件 → FMEDA 在基事件层给出定量数字（失效率 × DC） → DFA 横向检查 FTA 的"与门"两侧真的独立 → FSA 最后验收这整条链子。单独做任何一个都不够。

13.2 FMEDA 深入（Failure Mode, Effects, and Diagnostic Analysis）

定义：在 FMEA 基础上加一列 Diagnostic Coverage（DC, %），把定性的"失效模式"变成可以算 SPFM / LFM / PMHF 的定量账。ISO 26262 Part 5 §8 把 FMEDA 钦定为硬件度量计算的唯一合法载体。

输入：

• 设计 netlist / BOM → 每个元件的失效率 λ（FIT，通常查 IEC 62380 / SN 29500 / Siemens 616）
• FMEA 表：每种失效模式及其分布系数（开路/短路/漂移的相对概率）
• 安全机制清单（内部诊断、外部看门狗、CRC、ECC 等）及各自的 DC 估值

关键步骤（ISO 26262-5 Annex E 的 FMEDA 表列）：

1. 对每个元件列出所有失效模式，按 IEC 61508 Annex C 分配 mode 分布
2. 判断每个失效模式是否与 Safety Goal 相关（Safety-Related, SR）
3. 判断是否残留（Single-Point / Residual / Latent / Safe）
4. 指定覆盖该失效模式的 Safety Mechanism 及其 DC
5. 汇总：
   • ${\lambda }_{SPF}=\Sigma \lambda \cdot (1-D{C}_{SPF})$
   • ${\lambda }_{LF}=\Sigma \lambda \cdot (1-D{C}_{LF})$
   • SPFM = 1 − λ_SPF / λ_SR ；LFM = 1 − λ_LF / (λ_SR − λ_SPF)

两条常见陷阱：

• λ 基数错：厂商 Datasheet 的 FIT 数字通常是 60 % 置信 / 40 ℃；做 ASIL 分析必须折算到 实际结温 并统一置信水平，否则 PMHF 少算一个量级
• DC 估值虚高：每项 Safety Mechanism 的 DC 必须能在 Safety Manual 中找到"怎么测到、时间常数多少"的论证；拍脑袋写 90 % 是最大坑

Accellera Functional Safety Data Model（2023.12）——FMEDA 交换格式标准化（源：Functional_Safety_White_Paper_20231213 §I～§IV）：每家 OEM/Tier1 的 FMEDA 模板都不一样，IP 供应商做一次 FMEDA 要对齐 20+ 套格式——Accellera Functional Safety Working Group 正在定义一套数据模型 + 原型语言统一这层接口；这套标准一旦落地，SEooC 认证的可复用性会大幅上升。

原型语言核心命令：create_fmeda / create_element / create_fm / create_sm / assign_sm_fm 等，把 FMEDA 表的每一行变成可机读、可重算的指令序列，而不是 Excel 单元格。

四大概念库——把 FMEDA 拆成正交的四个轴，各自独立扩展：

跨供应链 4 层共享——上游每升一层，FMEDA 粒度变粗、AoU 数量增多：

两大交换用例——决定下游能不能改算：

AoU（Assumptions of Use）是关键交换字段——当 safety mechanism 在供应商 element 之外时（如外部 watchdog、外部 ECC、监控周期），Safety Manual 必须通过 AoU 把这些假设传达给集成方；任一假设失配，集成方复用上游 FMEDA 数字时 DC 就会算错，等于全链路返工。

13.3 DFA 深入（Dependent Failure Analysis）

定义：ISO 26262 Part 9 §7 的强制分析，用于证明声明"独立"的两侧（冗余通道、ASIL 分解后的两条路径、监控与被监控元素）确实没有共因 (Common Cause) 或级联 (Cascading) 耦合。没有 DFA，冗余可能是伪冗余，ASIL 分解不成立。

两类 Dependent Failure：

DFI（Dependent Failure Initiator）清单（源 Part 9 Annex B）：硬件 DFI 包括电源、时钟、复位、温度、电磁、机械、通信；软件 DFI 包括共享变量、共享栈、共享中断、共享 ISR、共享时序资源。每条 DFI 都要逐条评估"它对两侧的影响是否独立"。

步骤：

1. 识别所有独立性声明（Independence Claims）——哪两侧必须独立？
2. 针对每对独立两侧，穷举 DFI 清单
3. 对每个 DFI 判断：是否有物理/逻辑耦合？耦合是否被安全机制缓解？
4. 未缓解的耦合 → 加缓解措施或重新 ASIL 分配
5. 输出 DFA Report，进 Safety Case

工程落地手段：

• 空间隔离 — PCB 走线物理分开、封装内两核放对角、模块放不同 ECU
• 电源 / 时钟独立 — 双 LDO + 双晶振；SBC 的 FSM 自带 bandgap + 振荡器（NXP MC33907）
• 通信隔离 — 数字隔离器跨双 ASIL 域
• 时序隔离 — 监控核和被监控核的中断、看门狗在不同时钟域

两条常见翻车：

• 共享地没被识别为 DFI：两条信号看似独立但都走同一返回地 → 地弹时双侧都中枪
• "分解了但没做 DFA"：项目经理让架构师写 "ASIL D = B + B"，却没做 DFA → Safety Assessment 一次拍回

13.4 FTA 深入（Fault Tree Analysis）

定义：Top-down 推演。从 Top Event（= Safety Goal violation 或危害） 出发，用布尔逻辑（AND / OR / XOR / NOT 门）拆到基事件（Basic Event，通常是元件层失效或人因错）。给每个基事件配失效率 → 顶事件概率可算出来。

用途差异：

符号速查（IEC 61025）：

• OR 门：任一输入发生即输出发生（寻找单点失效的利器）
• AND 门：所有输入同时发生才输出（冗余应该形成 AND）
• Transfer：子树在别处定义，保持主图干净
• Undeveloped：已知基事件但不再展开（工程判断）

与 FMEDA 的协同：

• FTA 是结构化"为什么会发生"；FMEDA 是"发生的概率多大、被检测的比例是多少"
• FTA 的 MCS 长度为 1 的节点 = FMEDA 里的 SPF → 必须加覆盖
• FTA 的概率汇总（AND 门串积 + OR 门串和）比 FMEDA 的平均 PMHF 更能暴露局部高风险路径

工具：商业 Isograph FaultTree+、Ansys Medini Analyze；开源 SCRAM；手工 VSCode + PlantUML。

常见坑：

• 门类型填错：AND 和 OR 混用 → 整棵树概率差几个数量级
• 基事件不独立：两个基事件其实共用 DFI → 概率乘积被低估，真实概率比算的高
• 顶事件定义含糊：Safety Goal 一句话塞不下所有场景时要拆多棵 FT

13.5 FSA 深入（Functional Safety Audit vs Assessment）

FSA 有两副面孔，ISO 26262 Part 2 §6 定义不同：

通俗类比：Audit 是"财务检账单对不对"，Assessment 是"审计师重新核对盈亏"。

Assessment 的 5 个审查维度（Part 2 Annex D）：

1. Safety Plan 完整性 — 生命周期所有 work product 都列出来了？
2. Safety Case 充分性 — 论证链条每一环都可追溯、关键假设明确？
3. 组织 — RASIC / 责任链清晰？Confirmation Measures 人选独立？
4. 方法裁剪 — 选了哪些 Table 项、裁掉哪些，理由够不够？
5. Residual Risk 声明 — 知道自己还留了什么风险，是否可接受？

强度要求（按 ASIL）：

• ASIL A：Assessment 推荐（+）
• ASIL B：Assessment 推荐（+）
• ASIL C：Assessment 强推荐（++）
• ASIL D：Assessment 强推荐（++），且 Assessor 必须组织独立（内部 QA 不够，必须跨 BU 或外部）

ASIL 分解对 FSA 无效：分解后两侧各为 ASIL B，但 Assessment 仍按原 Safety Goal（ASIL D）执行——这是 ISO 26262-2 的明文规定，防止通过分解"降级规避评审"。

FSA 与其他三件套的衔接：Assessor 会逐条查 FMEDA（数字可否重算）、DFA（每条 DFI 的缓解是否足够）、FTA（基事件独立性是否成立）。写这三份时就要想着"Assessor 下个月会问什么"，留证据留得干净是最省时间的做法。

• 功能安全 ≠ 可靠性：可靠性看"多久会失效"，功能安全看"失效时会不会伤人"。一个 MTBF 极高但失效时输出错误指令的系统可能比低 MTBF 但"失效 = 停机"的系统更不安全。
• 两类失效：随机硬件失效（可概率化、可冗余消除）和系统性失效（需求/软件 bug，冗余无效，只能流程预防）。44% 的危险失效源自需求阶段——所以概念阶段和 HARA 是一切的起点。
• IEC 61508 是通用母标准，ISO 26262 是其汽车版本；用 ASIL 替代 SIL，并通过 S × E × C 矩阵 查表确定等级。
• HARA 是概念阶段的核心：项目定义 → 危害识别 → 风险评估 → 安全目标 → 功能安全概念。做好 HARA 意味着系统性枚举所有危险场景，遗漏一个就留一个盲点。
• 硬件度量：ASIL D 要求 SPFM ≥ 99%、LFM ≥ 90%、PMHF < 10 FIT。SPF 是"直接致命"，LF 是"悄悄禁用诊断导致两步失效"——都需要专门的诊断机制覆盖。
• 双核锁步 MCU 是实现 ASIL D 的主流架构：两核输出比较 → 几乎所有单点故障都变成可检测事件 → SPFM 拉到 99%。
• ASIL 分解：ASIL D 可以分解为两个 ASIL B，但两侧必须独立（DFA 通过）。合法组合有限，非法组合（如 D = A + C）不允许。
• FMEA 用 AP 替代 RPN（AIAG-VDA 2019）：查表而不是相乘，严重度永远优先，不允许用低概率或好检测"掩盖"高严重度项。
• 典型 ASIL D 项目时间线 1.5～2 年，概念 + 验证占 40～50% 工作量——不是在写代码，是在做安全论证。
• 软件安全硬核三件套（ISO 26262-6）：MISRA C 编码规范落地 Table 1 + ASIL D 必须 MC/DC 结构覆盖 + Inspection / 故障注入 / 需求追溯齐全。
• Safety Case 是最终交付物，Confirmation Measures 三档中 Assessment 必须组织独立；ASIL 分解对 Confirmation 无效。
• 分析工具分工：FMEA/FMEDA Bottom-up、FTA Top-down、DFA 查共因、HAZOP 早期危害挖掘；FMEDA 是唯一能做 SPFM/LFM 计算的载体。

基础标准

• IEC 61508:2010 — 通用功能安全母标准（7 parts）
• ISO 26262:2018 — 汽车功能安全（12 parts）
• IEC 61511 — 过程工业（石化）
• DO-178C — 航空软件
• DO-254 — 航空电子硬件

入门教材

• The Safety Critical Systems Handbook（Smith & Simpson）
• Functional Safety for Road Vehicles（Lindskov Hansen 等）
• Optima ISO 26262 Primer White Paper

FMEA

• AIAG & VDA FMEA Handbook（2019，AP 方法源头）

半导体 / 硬件

• ISO 26262 Part 5 + Part 11（2018 年新增 Part 11 针对半导体）
• Infineon / NXP / ST 的 Safety Manual（每颗汽车 MCU 必有）

概念白皮书

• NXP — High-Voltage Inverter Safety System Concept for ISO 26262
• Functional Safety White Paper (2023.12)
• Introduction to Functional Safety for High-Voltage Systems

由 feed.py 每日自动追加；来源见各条链接。

• 2026-04-17 Technical ArticleMagnetic Sensor ICs Offer Integrated Diagnostics for ASIL ComplianceThe ever-evolving requirements of t — 磁传感器IC通过嵌入式固态线圈实现端到端自测，提供集成诊断功能以满足ISO 26262 ASIL D的功能安全要求。这些IC取代传统电机械开关，能够在恶劣汽车环境中进行故障检测和自纠正，从而降低剩余风险并支持FMEDA分析。
• 2026-04-16 TIDA-01599: IEC 61800-5-2 Certification for STO Function - Can it be implemented without additional microcontroller? — 该设计方案TIDA-01599旨在实现符合IEC 61800-5-2标准的STO（Safe Torque Off）功能，核心问题在于探讨是否可以在不增加额外微控制器的情况下完成认证。可能涉及使用特定隔离器件和控制电路来满足安全要求，简化系统设计。

• ← 索引
• 汽车电子 — E/E 架构、CAN、AEC-Q、ISO 26262 在整车里的落地
• SiC 器件（Silicon Carbide Devices） — EPS、主驱逆变器的核心器件，功能安全设计的硬件承载
• IGBT 技术 — 工业变频器、传统动力总成的功能安全对象
• 栅极驱动（Gate Driver） — DESAT、UVLO、OTP 等硬件保护是功能安全的第一道防线
• 热管理（Thermal Management） — 过温保护 OTP 是功能安全链路的一环
• 保护器件（TVS / ESD / 过压保护） — 瞬态保护是抗共因失效的一部分
• 汽车微控制器（Automotive MCU）
• CAN / CAN FD / LIN 总线（Automotive Bus Protocols）
• 电流传感器（Current Sensing）
• 失效模式综合速查表（FMEA Quick Reference）
• DFA / FMEDA / FTA 三种核心分析方法 — DFA 看独立性 / FMEDA 量随机硬件失效覆盖 / FTA 拆顶事件路径,功能安全分析三件套
• ISO 26262 硬件要素三类分类 — I/II/III 类决定芯片选型与评估深度,ASIL C/D 系统的硬约束
• 安全机制目录 — MCU/电源/驱动/传感/通信 5 维 SM 大全 + ASIL 等级 SM 组合选型
• HARA 危害分析与风险评估 — 概念阶段起点,S/E/C 评分得 ASIL,推导 Safety Goal + FTTI
• ASIL 分解(Decomposition) — 把 ASIL D 拆成两路 B(D)+B(D) 降成本,前提是 4 项独立性都过
• SEooC(Safety Element out of Context) — 通用芯片合规开发 + Safety Manual 4 类 assumption + Tier1 验收
• Safety Case 安全案例 — argument + evidence 结构化集合,living document 边开发边累积
• 逆变器栅极驱动 IC（Inverter Gate Driver）
• 电机控制（Motor Control）
• 位置传感器（Position Sensing）
• 功率电子学（Power Electronics）
• PPAP 与汽车零部件开发阶段
• SBC / 伴随 IC（System Basis Chip）
• 特殊特性（Special Characteristics）