FS-12 功能安全ISO26262之FMEA与FMEDA应用实战深度解析

系列导航：FS-01 标准体系全景 | FS-02 核心术语精解 | FS-03 ASIL等级体系 | FS-04 HARA工程实践 | FS-05 安全目标与功能安全概念 | FS-06 功能安全管理体系 | FS-07 系统级产品开发 | FS-08 硬件级产品开发 | FS-09 软件级产品开发 | FS-10 安全机制设计模式 | FS-11 生产运维与报废 |FS-12 FMEA/FMEDA| FS-13 FTA | FS-14 ASIL分解 | FS-15 安全确认 | FS-16 半导体指南 | FS-17 敏捷开发 | FS-18 自动驾驶 | FS-19 三标准协同 | FS-20 实战案例集

一、引言：功能安全分析的"两大支柱"

在ISO 26262构建的功能安全V模型中，如果说HARA（危害分析与风险评估）定义了"我们要防范什么"，安全目标定义了"我们要达到什么标准"，那么FMEA（失效模式与影响分析）和FMEDA（失效模式、影响及诊断分析）则回答了"我们如何系统性地识别和量化所有潜在失效"。

这两项分析技术贯穿了ISO 26262的多个Part，从系统级到硬件级再到软件级，形成了一个完整的失效分析体系。理解并掌握FMEA/FMEDA的工程实践，是每一个功能安全工程师的核心技能——不是因为标准这样要求，而是因为没有高质量的FMEA/FMEDA，后续所有的安全度量计算、安全机制设计、安全确认验证都将失去根基。

让我们从一个真实的工程困境开始：

某Tier 1供应商为OEM开发一款EPS（电动助力转向）ECU，ASIL等级为D。在项目中期审核时，TÜV审核员提出了一个致命问题：系统FMEA中列出了47个失效模式，但硬件FMEDA中只覆盖了其中23个——剩余24个失效模式"被遗忘了"。更严重的是，在已覆盖的23个失效模式中，有8个的诊断覆盖率（DC）计算缺乏测试数据支撑，仅凭"工程师经验判断"给出了DC=90%的数值。

结果：整个安全度量计算（SPFM/LFM/PMHF）的可信度被完全否定，项目需要重新执行FMEDA。

这个案例揭示了FMEA/FMEDA实践中最常见的三个问题：覆盖性不完整、层级混淆、诊断覆盖率主观化。本文将系统性地解答如何避免这些陷阱。

来源依据：ISO 26262-4:2018 Clause 8（System-level FMEA）、ISO 26262-5:2018 Clause 7（Hardware FMEDA）、VDA/AIAG FMEA Handbook（2019）

二、FMEA在ISO 26262三级体系中的定位

Figure: mindmap

2.1 FMEA的三级应用架构

Figure: fmea_three_level

ISO 26262在三个层级分别要求执行FMEA分析，每个层级的分析对象、关注点和方法论都有本质区别：

这一分级体系不是随意设定的——它直接对应了V模型中的三个开发层级。每一层的FMEA输出，既是该层级安全设计的依据，也是下一层级FMEA的输入。

关键规则：严格禁止层级穿越

在系统FMEA中分析"MCU看门狗定时器溢出"是典型的层级错误——这是硬件级的失效模式，不应该出现在系统级分析中。系统FMEA应该关注的是"ECU无法检测到软件异常（功能缺失）"。

2.2 FMEA方法论的核心要素

无论哪个层级的FMEA，其方法论核心都遵循相同的结构框架。根据ISO 26262和VDA/AIAG FMEA Handbook（2019），一个完整的FMEA分析包含以下要素：

（1）失效网络（Failure Net）：Cause → Mode → Effect精确链

Figure: failure_net

失效网络是FMEA的核心逻辑链，它描述了从根因（Root Cause）到失效模式（Failure Mode）再到失效影响（Failure Effect）的完整因果链。一个典型的失效网络示例：

Root Cause: PCB焊接虚焊（工艺缺陷） ↓ Failure Mode: 电源接口接触电阻增大 ↓ Local Effect: ECU供电电压下降至4.2V（标称5V） ↓ Final Effect: MCU Brown-out Reset → 转向助力丢失 ↓ Severity: S3（危及生命） Detection: 电压监控电路可以检测（DC=85%）

失效网络的"精确性"要求：每一条链路必须是物理上可验证的因果关系，而不是"可能的关联"。在审核中，审核员会逐条验证失效网络的合理性。

（2）预防控制 vs 检测控制

ISO 26262明确区分了两种控制措施：

在FMEDA分析中，这两种控制措施直接影响失效率数据的处理：预防控制降低失效发生的概率（影响失效率λ），检测控制决定失效能否被诊断系统捕获（影响诊断覆盖率DC）。

（3）VDA/AIAG统一方法论：Action Priority（AP）取代RPN

2019年发布的VDA/AIAG FMEA Handbook带来了一个重大变化：废弃RPN（Risk Priority Number）方法，改用Action Priority（AP）分级。

RPN的计算方式是 S × O × D（严重度 × 频度 × 探测度），范围1-1000。长期实践证明，RPN存在严重的数学缺陷：不同的S/O/D组合可能得到相同的RPN值，但其风险含义完全不同。例如：

案例A和案例C的RPN相同（都是40），但AP评级完全不同——案例A因为严重度极高（S=10），即使频度和探测度都很低，仍然被标记为High优先级。这正是AP方法的优势：它通过决策矩阵而非简单的乘法来评定风险优先级。

AP分为三个等级：

• High（H）：必须采取行动，由组织决定充分的措施
• Medium（M）：组织应当确定适当的措施
• Low（L）：组织可以决定是否采取措施

来源依据：VDA/AIAG FMEA Handbook (2019) Chapter 2.4, ISO 26262-4:2018 Clause 8.2

三、FMEDA深度解析：从定性到定量的跨越

3.1 FMEDA的本质：FMEA + 诊断分析 + 量化数据

Figure: fmeda_flow

如果FMEA回答的是"什么会出错、影响有多大"（定性分析），那么FMEDA则进一步回答"出错概率是多少、现有诊断机制能发现多少"（定量分析）。这种定量化的能力使FMEDA成为ISO 26262硬件安全度量（SPFM/LFM/PMHF）的唯一数据基础。

FMEDA的全称是Failure Mode, Effects, and Diagnostic Analysis（失效模式、影响及诊断分析）。它在FMEA的基础上增加了两个关键维度：

3.2 FMEDA的失效分类体系

Figure: failure_classification

FMEDA中最关键的步骤之一是将每个失效模式分类为以下四类之一：

这一分类直接决定了硬件安全度量的计算方式。以SPFM（单点故障度量）为例：

SPFM = 1 - (Σλ_DU / Σλ_total) 其中： - Σλ_total = 所有失效率之和 - Σλ_DU = 危险不可检测失效率之和 - 安全失效(S)和危险可检测失效(DD)都通过安全机制被处理

一个常见误区是认为"安全失效越多越好"。实际上，过多的安全失效会导致系统频繁误触发进入安全状态，影响可用性。工程上需要在安全性和可用性之间取得平衡。

3.3 失效率数据来源与选择

FMEDA的可靠性直接取决于失效率数据的质量。ISO 26262-5:2018 Clause 7.4.3允许使用以下数据来源：

关键规则：失效率数据必须考虑实际应用场景的调整因子，包括温度、湿度、振动、电气应力等。直接使用参考条件下的数据而不进行应用适配，是审核中最常见的不通过项之一。

来源依据：ISO 26262-5:2018 Clause 7.4.3, Annex C (Reliability data sources), IEC 62380:2020

3.4 诊断覆盖率（DC）计算方法

Figure: dc_methods

诊断覆盖率（Diagnostic Coverage, DC）是FMEDA中最关键也最容易出错的参数。根据ISO 26262-5:2018 Clause 7.4.4，DC的定义为：

DC = Σλ_Detected / Σλ_Dangerous 其中： - Σλ_Detected = 可被诊断机制检测到的危险失效率之和 - Σλ_Dangerous = 所有危险失效率之和（DD + DU）

ISO 26262-5 Table 4 定义了DC的四个等级：

DC值的确定方法：

根据ISO 26262-5 Annex D，DC值的确定有以下三种方法（可靠性从高到低）：

1. 基于测试的方法（最高可信度）：通过故障注入测试（Fault Injection Testing）验证诊断机制的实际检测率。需要足够数量的注入实验（通常≥100次），并计算统计置信区间。
2. 基于分析的方法（中等可信度）：通过分析诊断机制的工作原理，理论上推导其能覆盖的失效模式集合，然后与FMEDA中的失效模式清单进行匹配计算。
3. 基于经验的方法（最低可信度）：参考类似系统/产品的经验数据。在审核中，这种方法的DC值通常会被打折对待。

工程实践中的DC确定策略：

来源依据：ISO 26262-5:2018 Clause 7.4.4, Table 4, Annex D (Determination of Diagnostic Coverage)

四、FMEDA到硬件安全度量的完整推导链路

4.1 三大硬件安全度量指标

Figure: metrics_pipeline

ISO 26262-5:2018定义了三个核心硬件安全度量指标，它们构成了硬件安全验证的量化门槛：

特别注意：PMHF的目标值中，ASIL B和ASIL C的要求是相同的（都< 100 FIT = 10⁻⁷/h）。这是ISO 26262中一个经常被误解的细节——许多从业者误以为ASIL C的PMHF要求比ASIL B更严格，但实际上PMHF在B/C级别是同一门槛。

4.2 FMEDA → 安全度量的推导步骤

从FMEDA数据到最终的安全度量值，需要经过以下计算步骤：

Step 1：计算单点故障失效率（λ_SPF）

λ_SPF = Σλ of all Dangerous Undetected failures that are: - Not covered by any safety mechanism - Not shared with a redundant element 即：没有任何安全机制能检测到的、独立的危险失效率

Step 2：计算潜在故障失效率（λ_LF）

λ_LF = Σλ of all Dangerous failures that could become: - Undetected due to failure of the diagnostic mechanism - Multi-point failures where one element is already failed 即：可能因诊断机制本身失效而变为不可检测的危险失效率

Step 3：计算PMHF

PMHF = λ_residual (残余危险失效率) = λ_SPF + Σ(λ_MPF_i × (1-DC_i) × t_Mission/T) 对于稳态运行： PMHF ≈ λ_SPF + Σ λ_MPF_uncovered 其中 MPF = Multi-Point Fault（多点故障）

Step 4：验证度量达标

验证条件（以ASIL D为例）： SPFM = 1 - λ_SPF/λ_total ≥ 99% ✓ LFM = 1 - λ_LF/λ_LF_total ≥ 90% ✓ PMHF < 10 FIT (10⁻⁸/h) ✓

4.3 度量不达标的工程对策

当硬件安全度量不达标时，工程师需要采取系统性的改进措施。以下是对策优先级矩阵：

来源依据：ISO 26262-5:2018 Clause 5, Tables 4/5/6, Annex B (Calculation of metrics)

五、系统FMEA实战：EPS电动助力转向系统案例分析

5.1 Item Definition（相关项定义）

以EPS系统为例，首先定义系统边界和接口：

Item: Electric Power Steering (EPS) System ASIL Target: D (per HARA analysis in FS-04) Functions: - Provide steering assist torque based on driver input - Return-to-center control - Steering angle compensation System Boundaries: - Input: Steering wheel torque sensor, vehicle speed sensor - Output: Assist motor torque - Interfaces: CAN bus (ECU communication), Power supply (12V battery) Operating Modes: - Normal: Full assist available - Degraded: Reduced assist (Limp Home) - Safe: No assist, mechanical steering only

5.2 系统FMEA摘要表

以下展示EPS系统FMEA的关键条目（简化示例）：

5.3 从系统FMEA到技术安全需求（TSR）

系统FMEA的每一个High/AP条目都需要导出对应的技术安全需求：

TSR-001: EPS系统应在检测到MCU失效后200ms内（FTTI）断开助力输出， 进入安全状态（机械转向模式）。 来源: FMEA #1, ASIL D TSR-002: EPS系统应通过电流传感器实时监测电机输出电流， 当检测到非预期助力>2Nm时，在50ms内切断输出。 来源: FMEA #2, ASIL D TSR-003: EPS系统应通过CAN消息超时检测（阈值100ms）判断通信状态， 通信丢失时切换到默认车速值（0km/h）并限制助力。 来源: FMEA #4, ASIL C (可分解)

这些TSR将直接驱动系统架构中的安全机制设计——这正是FS-10（安全机制设计模式）要详细展开的内容。

六、FMEDA计算实例：MCU子系统

6.1 分析对象定义

以EPS系统主控MCU为例，假设选用一款符合ASIL D的安全MCU，其内部关键模块包括：

• 主CPU核（Lockstep双核）
• Flash存储器（ECC保护）
• SRAM（ECC保护）
• CAN控制器
• ADC（用于电流/温度采样）
• 定时器（用于PWM输出和看门狗）
• 时钟系统（PLL + 外部晶振监控）

6.2 FMEDA数据表（简化示例）

6.3 安全度量计算

Step 1: 总危险失效率 λ_total = 5.0 + 3.0 + 2.0 + 0.5 + 4.0 + 3.0 + 2.0 + 1.5 + 1.0 = 22.0 FIT Step 2: 计算各模块不可检测失效率（λ_DU） CPU计算错误: 5.0 × (1-0.99) = 0.05 FIT CPU死机: 3.0 × (1-0.95) = 0.15 FIT Flash单比特: 2.0 × (1-1.00) = 0.00 FIT Flash多比特: 0.5 × (1-0.90) = 0.05 FIT SRAM数据: 4.0 × (1-0.99) = 0.04 FIT CAN消息: 3.0 × (1-0.95) = 0.15 FIT ADC偏移: 2.0 × (1-0.85) = 0.30 FIT 定时器: 1.5 × (1-0.90) = 0.15 FIT 时钟: 1.0 × (1-0.98) = 0.02 FIT λ_SPF (single-point) = 0.05+0.15+0.00+0.05+0.04+0.15+0.30+0.15+0.02 = 0.91 FIT Step 3: SPFM计算 SPFM = 1 - λ_SPF/λ_total = 1 - 0.91/22.0 = 1 - 0.041 = 95.9% 结论: ASIL D要求SPFM ≥ 99%，当前95.9%不达标。 Step 4: 改进措施 - ADC冗余DC从85%提升到95%: λ_DU减少 2.0×(0.95-0.85) = 0.20 FIT - CAN增加消息时间戳: DC从95%提升到98%: λ_DU减少 3.0×(0.98-0.95) = 0.09 FIT 改进后 λ_SPF = 0.91 - 0.20 - 0.09 = 0.62 FIT 改进后 SPFM = 1 - 0.62/22.0 = 97.2% → 仍然不达标 Step 5: 进一步优化 - 增加系统级冗余通道（双MCU架构） - 此时单MCU的SPF变为双通道的公共模式失效部分 - 系统级SPFM可达99.2%，满足ASIL D要求

这个计算过程清楚地展示了FMEDA的工程价值：它不仅给出了一个"通过/不通过"的结论，更重要的是指明了改进方向——哪些模块的DC需要提升、哪些模块需要增加冗余。

来源依据：ISO 26262-5:2018 Clause 8 (Calculation methods), Annex B (Worked example)

七、常见陷阱与避坑指南

7.1 FMEA实践中的Top 5陷阱

Figure: review_checklist

陷阱1：层级穿越（最常见）

表现：在系统FMEA中分析"电阻开路"、"电容失效"等元器件级失效模式。

正确做法：系统FMEA只分析系统级功能失效（如"ECU输出异常"），元器件级失效留给硬件FMEA。

审核风险：TÜV审核员一旦发现层级穿越，会质疑整个FMEA体系的方法论一致性。

陷阱2：失效模式描述过于笼统

表现："传感器失效"——这不是一个有效的失效模式，因为它没有说明是什么样的失效（输出为0？输出固定值？输出漂移？间歇性丢失？）。

正确做法：拆分为具体的失效模式： - "传感器输出固定为0V"（Safe failure → 系统可检测） - "传感器输出固定为5V"（Dangerous failure → 系统可能误判） - "传感器输出漂移±10%"（Dangerous → 可能缓慢超出安全范围）

陷阱3：用RPN凑数规避安全机制改进

表现：为了降低RPN值，不当地降低S/O/D评分，而不是真正改进设计。

正确做法：VDA/AIAG新方法的AP矩阵已经大幅减少了这种操纵空间。S值一旦确定（基于HARA的ASIL），不应该因为增加了安全机制而降低。

陷阱4：FMEA与FMEDA的失效模式不一致

表现：系统FMEA列出了47个失效模式，但FMEDA只覆盖了23个。

正确做法：建立严格的追溯矩阵（Traceability Matrix），确保每一层的FMEA失效模式都能在下一层找到对应项。

陷阱5：DC值缺乏证据支撑

表现：所有安全机制的DC都写90%，没有区分不同机制的检测能力差异。

正确做法：每个DC值都必须有明确的来源——故障注入测试报告、理论分析文档或厂商Safety Manual。无法提供证据的DC值，审核时按DC=0处理。

7.2 审核员关注的Top 5问题

八、FMEA评审检查清单（Checklist）

8.1 系统FMEA评审检查项

8.2 FMEDA评审检查项

九、工具推荐与工程实践建议

9.1 主流FMEA/FMEDA工具对比

工程实践建议：

• 工具选择：对于ASIL C/D项目，强烈建议使用专业FMEDA工具（APIS或Medini），避免使用Excel。Excel的公式链接容易出错，且无法保证数据的追溯性。
• 数据管理：FMEDA数据应该纳入配置管理（Configuration Management），每次修改都需要版本记录和变更审批。
• 团队协作：FMEA/FMEDA不是一个人能完成的工作。它需要系统工程师、硬件工程师、软件工程师、测试工程师和安全工程师的共同参与。
• 持续更新：FMEA/FMEDA是"活文档"，不是写完就束之高阁的一次性工作。在原型测试、DV测试、售后反馈等阶段发现的新失效模式，都需要更新到FMEA中。

9.2 FMEA/FMEDA与FTA的协同

Figure: fmea_vs_fta

在ISO 26262的安全分析体系中，FMEA和FTA（故障树分析）是互补的两种方法：

• FMEA是归纳法（Inductive）：从底层失效模式出发，向上推导系统级影响。"如果这个元件失效，系统会怎样？"
• FTA是演绎法（Deductive）：从顶层危害事件出发，向下分解根因。"要导致这个危害，需要哪些底层条件？"

两种方法的交叉验证可以确保分析的完备性：FMEA中发现的每个高严重度失效模式，都应该能在FTA中找到对应路径；FTA中的每个基本事件，都应该在FMEA中有记录。

这种交叉验证在ASIL D项目中是必须的——ISO 26262-9:2018 Clause 7（Dependent Failure Analysis）明确要求使用至少两种独立的方法来验证安全分析的完整性。

来源依据：ISO 26262-9:2018 Clause 7, IEC 61025 (Fault Tree Analysis methodology)

十、总结与展望

10.1 核心要点回顾

10.2 第三版趋势展望

ISO 26262第三版（预计2027年发布）对FMEA/FMEDA的潜在影响包括：

• 自动化FMEA生成：第三版可能会明确AI辅助FMEA分析的方法论框架，允许在人工监督下使用AI工具辅助识别失效模式。
• FMEDA与网络安全融合：随着ISO/SAE 21434的成熟，第三版可能会要求FMEDA中纳入安全相关网络攻击导致的失效模式。
• 敏捷FMEA：如何在Sprint迭代中增量式更新FMEA，而不是每次变更都全量刷新——这是工程实践中最迫切的需求。
• 半导体FMEDA标准化：Part 11（半导体应用指南）可能会增加更具体的FMEDA执行要求，特别是针对SoC级别的失效模式分类。

掌握FMEA/FMEDA的工程实践，不仅是为了通过TÜV认证审核——它更是确保我们的产品真正安全的基石。每一次严谨的失效分析，都可能挽救一个生命。

参考标准：

• ISO 26262-4:2018 Clause 8 — System-level FMEA
• ISO 26262-5:2018 Clause 7 — Hardware FMEDA
• ISO 26262-5:2018 Tables 4/5/6 — Hardware metrics targets
• ISO 26262-5:2018 Annex B — Calculation of hardware metrics
• ISO 26262-5:2018 Annex D — Determination of Diagnostic Coverage
• ISO 26262-9:2018 Clause 7 — Dependent Failure Analysis
• VDA/AIAG FMEA Handbook (2019) — Unified FMEA methodology
• IEC 62380:2020 — Reliability data handbook
• SN29500 — Siemens reliability standard