谈谈ISO26262中的FMEA分析

FMEA是汽车功能安全(ISO26262)中常用的一种安全分析方法，本文谈谈如何进行功能安全的FMEA分析。

说明：

• ISO26262标准中要求进行安全分析的方法之一是Inductive Analysis，FMEA是Inductive Analysis中常用的方法。因此本文描述中，以FMEA替代Inductive Analysis。
• 本文所阐述的FMEA思路和做法，仅针对ISO26262汽车功能安全。不能取代传统的IATF16949中的FMEA做法。
• 本文未包括P-FMEA。

1. 为什么要做安全分析

引用ISO26262:2018 Part 4中的系统阶段安全分析的目的：

• 证明设计能够适应与ASIL等级相匹配的安全需求和特性；
• 识别失效原因和故障影响；
• 识别或确认安全相关的系统要素（Element）和接口（Interface）；
• 验证安全机制的有效性。

2. 哪些阶段要做FMEA分析

ISO26262标准在每个阶段，都提到安全分析，总结如下：

备注：

• ISO26262-6没有明确的软件详细设计(模块设计)这一层级，但是要求软件架构设计要down to the level where the software units are identified。实际项目中，通常有软件模块设计这一层级。对于软件模块设计，要不要做FMEA分析呢？取决于软件架构设计的颗粒度，如果软件架构设计太粗，建议在软件模块设计级别，进行FMEA分析。
• 关于软件架构设计的颗粒度，可参考文章：​​软件架构设计的颗粒度​​

3. 什么时候做FMEA

FMEA贯穿于整个产品开发阶段，但是ISO26262只在设计阶段，提到要通过FMEA分析对设计进行验证。

实施建议：

• 1st FMEA on Pre-design，项目初期，针对产品初始设计进行FMEA分析，此阶段做FMEA的目的是帮助导出安全需求。通过FMEA，能够系统性地识别和分析产品中的failure对安全的影响，针对影响安全的失效，采取安全机制，写入安全需求规范。如果产品比较成熟，团队有丰富的功能安全项目经验，可不做。针对新产品、新功能、新技术或高度复杂系统，建议借助FMEA分析，导出安全需求。
• 2nd FMEA on safe design，完成产品安全设计后，针对整个产品设计进行FMEA分析。此阶段做FMEA的目的是验证产品的设计。

4. 谁来做FMEA分析

FMEA分析需要team work，不是功能安全工程师一个人的工作。产品设计开发团队一定要参与分析。

5. FMEA分析的范围

针对本文第3章描述的2nd FMEA on safe design这种场合，分析的对象是整个产品设计。

例如：项目的范围是整个ECU，包括有安全相关的架构要素和接口、非安全相关的架构要素和接口。是不是要针对所有的架构要素和接口都要进行分析呢？

以上图中的ECU系统架构设计的FMEA为例，建议如下：

• QM的要素和接口：可以不在功能安全的FMEA中进行分析，但是要做要素共存分析，分析QM的失效是否影响ASIL的要素
• QM(X)的要素和接口：需要纳入FMEA分析中
• 不确定是否安全相关的架构要素和接口：建议纳入FEMA分析。因为FMEA可以识别或确认安全相关的系统要素（Element）和接口（Interface）
• 来自ECU外部的输入接口：建议纳入FEMA分析，除非上一层FEMA已包括此接口分析
• ECU对外输出的接口：可不纳入FMEA分析，由接收信号的模块分析，建议告知客户
• ECU内部要素间接口：软硬件接口，建议纳入FEMA分析。软件要素和软件要素的接口，以及硬件要素和硬件要素的接口，可不纳入系统FMEA分析，可放入下一层级软硬件FMEA中分析。

6. 如何进行FMEA分析

推荐参考VDA/AIAG FMEA handbook，此手册中的内容，本文不再赘述，本文从功能安全的角度阐述如何进行FMEA分析。

需要澄清的是：VDA/AIAG FMEA handbook中的内容，功能安全的FMEA也需要满足，不能只考虑本文此章节的内容。

6.1 在FMEA手册的D-FMEA中融入功能安全的考虑

VDA/AIAG FMEA handbook中第2章是DFMEA。

建议：

• DFMEA Step 2结构分析中，考虑本文第5章的分析范围
• DFMEA Step 4失效分析中，失效模式可参考ISO26262 Part 5附录D、Part 6附录E和Part 11中的失效模式。软件的失效模式，可进一步参考NASA Software Safety Guidebook
• DFMEA Step 5风险分析中，分析失效对功能安全的影响，是否会造成违背安全目标或安全需求

6.2 FMEA手册中的FMEA-MSR vs. 功能安全FMEA

VDA/AIAG FMEA handbook中第4章是FMEA-MSR的执行。

此方法是新引入的FMEA方法，是对监控功能的有效性进行分析。提供了诊断/感知和系统响应的打分，规则如下（此内容来自VDA/AIAG FMEA handbook，仅摘录一部分）。

这个打分规则，和功能安全中的安全机制有效性的思路类似，分为故障探测+故障处理的打分。FMEA-MSR关注的是监控功能的有效性，而功能安全关注的是安全机制的有效性（功能安全FMEA分析一个重要的目的是验证安全机制的有效性）。

1）实施方案1：

把安全机制的诊断覆盖度Low-medium-High的结果映射到FMEA-MSR的诊断监视/感知打分；能否在FTTI内处理故障（比如进入安全状态）的结果映射到FMEA-MSR的系统响应/人体反应打分中。根据措施优先级AP的得分，采取对应措施。此方法实际操作起来，比较困难，因为很少有项目做FMEA-MSR。

2）实施方案2：

在现有的FMEA表单中，加入对于安全措施是否足够的考量，如下示例。

• 增加1列“是否影响安全”，结合失效影响的结果，判断是否违背安全目标或者需求。如下图所示，列出SG或安全需求ID，以及对应的ASIL等级
• 增加1列“SM+DC”，填写针对此失效已有的安全措施及其诊断覆盖度。
  如何判断安全机制的诊断覆盖度，可参考文章：​​​谈谈安全机制的诊断覆盖度​​如果采取的安全措施不是安全机制类的措施，这类措施在ISO26262标准中没有诊断覆盖度的概念，项目中如何处理呢？
• 增加1列“是否需要进一步措施”，结合安全机制的诊断覆盖度和会违背的ASIL等级，判定是否需要进一步措施（如何判定呢？）。如果不需要，填写No；如果需要，描述需要采取什么措施，分配责任人和完成日期。

7. 评审FMEA报告

ISO26262要求对FMEA报告进行confirmation review和verification review。

两者的区别，以及如何制订review checklist。参考文章：​​聊聊ISO26262和ASPICE中的文档评审​​

文章转载自公众号：仨人谈起