EPB功能安全笔记(8)：FMEA方法论介绍

本文要点

在上文(​​EPB功能安全笔记(7)：EPB safety concept分析示例)​​ 以一条Safety Goal为例，结合系统架构和功能定义与边界分析出功能安全需求，最终得到技术安全需求。技术安全需求将分配给软件工程师和硬件工程师实现。

功能安全开发团队合作示意图

至此，对功能安全需求分析的介绍将告一段落，从本文开始将展开对另一个主要功能安全开发工作的讨论——安全分析（Safety Analysis）。

在ISO 26262中关注两点失效：

随机硬件失效(random hardware failure)：在硬件要素的生命周期中，非预期发生并服从概率分布的失效。

系统性失效（systematic failure）：以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。

站在以结果为导向的角度，安全分析的目的就是借助分析方法去实现以下三点目标从而证明产品符合ISO 26262的要求。

• 产品的失效被完整地识别
• 系统性失效被有效地规避
• 随机失效被控制在了可接受的范围内

作为安全分析的开头，本文将介绍常用的分析系统性失效的方法——FMEA(Failure Mode and Effects Analysis)。

1.什么是FMEA?

1.1.FMEA的目的

对于企业来说，影响产品释放和质量的因素包括技术风险，财务风险，时间风险和策略风险。FMEA (Failure Mode and Effects Analysis)则是针对技术风险，是对产品开发和生产流程中进行预防性质量管理的一种分析方法。FMEA 有助于及时识别和评估系统或产品使用过程中所有可能的风险，并制定和实施适当的措施以优化产品开发和生产环节的质量控制以降低故障成本（如召回率）。

1.2.FMEA在汽车行业的标准

FMEA历史悠久，最早于1949年在美国军事装备开发中提出，后来形成了国际标注1977年引入汽车行业，并随着时间发展产生了两个标准：

• 德国汽车工业协会VDA：VDA Volume 4，“Product and Process FMEA”
• 美国汽车工业行动小组AIAG：“FMEA Reference Manual”

这两个标准的核心是一样的，但是仍然在一些概念的定义等方面存在差异，随着汽车行业全球化合作越来越深入，这些差异不可避免引起合作上的不便，对标准统一的呼声也越来越高，于是VDA和AIAG 在2019年联合发布了统一的标准“Failure Mode and Effects Analysis – FMEA Handbook”。

Failure Mode and Effects Analysis – FMEA Handbook，封面截图

按照AIAG&VDA标准的分类，如果将FMEA用于从进货到递交给客户的生产环节中，那么称为PFMEA（Process FMEA），由工厂管理相关工程师负责；如果将FMEA分析方法用作产品开发环节中，那么称为DFMEA（Design FMEA）。本文及后续文章只涉及DFMEA的讨论，对PFMEA感兴趣的读者可以参考标准里的详细介绍。

1.3.FMEA的优势和不足

正确且有效地进行FMEA活动，可以：

• 提高产品的质量、可靠性、安全性，从而提高用户满意度；
• 打通整车层（vehicle level）、系统层（system level）和组件层(component level)之间的接口，在与客户和供应商沟通中更有针对性从而提高效率；
• 降低失效引起的成本；
• 避免干扰项目SOP时间；
• 有助于在公司内部建立know-how。

但是，FMEA也不是万能的。首先，FMEA只是用来做定性分析而不是定量分析。具体来说，对识别出的故障所能造成的风险大小的评估，以及对避免故障所制定的措施的有效性的评估，会因为不同公司之间的能力水平差异和理解上的差异而存在出入。这就导致了不同公司之间的FMEA分析结果没有比较的意义。

其次，FMEA只用来进行单点故障分析，而不能进行多点故障分析。即在分析某个失效模式时，假设的前提是系统中所有其他功能都是正常工作的。

看到这里可能有读者想，既然只能做定性分析，而且还不能分析多点故障，局限性这么多，做FMEA还有什么意义？在这里需要给FMEA正名一下。分析方法的优劣取决于这个方法的侧重点是什么。对于FMEA来说，关注的是组成系统的每一个要素，其目的就是尽可能完整地识别所有要素可能产生的所有失效，并对影响大的失效制定应对措施。对于某个失效所造成的影响，虽然A公司评分为9，而B公司评分为8，但是这两个评分都不影响A公司和B公司都意识到这个失效的后果严重从而都根据自己的know-how制定相应的措施。从这个角度，FMEA分析的目的已经达到了。

我们可以说，单靠FMEA的分析结果不能完整地证明系统的可靠性，但是正确使用FMEA一定提高了系统的可靠性。

在这里说句题外话，从上一节的介绍中不难看出，理论上来说FMEA可以用来分析任何类型的产品（E/E，机械，液压等），从组成产品的底层要素入手进行风险分析。因此对于分析E/E产品的ISO 26262来说，自然而然地将FMEA作为一种自下而上的分析方法（归纳分析方法）作为推荐引入其中，用以辅助功能安全开发。但是不要错误得认为FMEA就是为ISO 26262服务的。通过上面的对比我们知道，实际上FMEA的使用范围比ISO 26262更广。

2.FMEA的方法论

在2019版的《Failure Mode and Effects Analysis – FMEA Handbook》中将FMEA活动归纳为七步，如下图所示。

FMEA“七步法”

其中第1步和第7步是新版本加上去的，分别对计划和最后的文档工作进行了指导，而中间五步则是FMEA的核心。接下来将重点对这五步的关键点进行阐述。

2.1.Structural Analysis（结构分析）

这里的结构指的是系统的结构。什么是系统？系统由若干个要素（element）组成，这些要素都具备相应的特征同时通过一定的关系与其他要素相互联系。同时系统具有将系统与外界环境分开的明确的边界，并且其与环境的关系由输入和输出定义。

结构分析的目的就是清晰、完整地描述产品的组成部分，包括系统的边界。在DFMEA中用树状图的形式描述了整个系统中的要素。

车窗升降系统树状图示例

在这里需要强调一点，整车系统由好几家公司的产品共同组成，相应地，这个系统完整的FMEA也是这些公司各自的FMEA通过系统接口定义拼接而成，而这些接口定义来自于需求定义。

多厂家合作时完整FMEA示意图

2.2.Function Analysis（功能分析）

对于要分析的产品，有基于产品设计需求定义出来的产品功能；而对每一个系统要素，也都各自对应一个或多个功能。功能分析的目的是保证产品功能被适当地分配给了相应的要素，从而将产品功能和要素功能关联起来形成功能网络。而这个工作将在已经确定的系统结构树的基础上完成。

车窗升降系统功能网示例

2.3.Failure Analysis（失效分析）

失效分析的目的是正确地识别出失效原因（failure cause）、失效模式（failure mode）和失效影响（failure effect）, 从而基于功能网确定失效网。

对失效的定义来源于功能定义，当功能不能被实现时即为失效。功能的失效模式可以从以下几个方面定义：

• Loss of function (e.g. inoperable, fails suddenly)
• Degradation of function (e.g. performance loss over time)
• Intermittent function (e.g. operation randomly starts/stops/starts)
• Partial function (e.g. performance loss)
• Unintended function (e.g. operation at the wrong time,
• unintended direction, unequal performance)
• Exceeding function (e.g. operation above acceptable threshold)
• Delayed function (e.g. operation after unintended time interval)

失效模式图示

前面提到，一条完整的失效网包含以下三个因素，三者的关系如下。

• 失效原因（failure cause）
• 失效模式（failure mode）
• 失效影响（failure effect）

失效网模型

failure mode是使要素无法满足预期功能的方式；而failure cause则为使failure mode发生的原因；failure effect被定义为failure mode所引起的后果。

值得注意的是，当分别站在系统层、子系统层和部件层来看某一个失效时，这个失效可能在不同的层级下分别被定义为failure cause、failure mode和failure effect。举例来说，OEM站在主机厂定义“电机扭矩非预期将为0Nm”为车窗无法升起的failure cause，但是对电机供应商来说却是failure effect。

不同层级定义的FE/FM/FC

基于上述关系，在连接失效网时，连接failure mode和failure cause前，可以问这样一个问题：为什么这个failure mode会发生？而在连接failure effect和failure mode时，则考虑：这个failure mode发生了会产生什么后果？

车窗升降系统失效网示例

2.4.Risk Analysis （风险分析）

风险分析的目的是通过评估风险的严重度（Severity）、频度（Occurrence）和探测度（Detection）来确定需要采取优化措施的优先级。

Severity值指的是最顶层（整车层）的failure effect所造成的严重程度。对S值的评级见下表。简单来说，10表示最严重，0表示最不严重。

Severity评分表，截图来自Failure Mode and Effects Analysis – FMEA Handbook

Occurrence值反映的是在为避免failure cause发生所采取的预防措施的作用下failure cause发生的可能性。对O值的评级见下表。简单来说，10表示发生的可能性最大，0表示可能性最小。

Occurrence评分表，截图来自Failure Mode and Effects Analysis – FMEA Handbook

Detection值则反映了在产品量产释放之前采取的探测failure cause的措施的有效性。

这里必须要强调一点：探测措施是指产品量产之前即交到客户手中之前所采取的措施。通常探测措施指的是量产之前产品验证阶段定义的一系列测试。

对D值的评级见下表。简单来说，10表示探测的有效性最差，0表示有效性最好。

Detection评分表，截图来自Failure Mode and Effects Analysis – FMEA Handbook

实际上在这三个维度的概念中，Severity是最好理解的，但是Occurrence和Detection的理解上容易出现偏差。在这里想做一些补充以便让读者能够更准确地掌握这两个概念。

首先可以问一个问题：预防措施设计非常完美，O值很低，是否有信心认为失效一定得到了有效的控制？

答案是否定的。我们可以从两个方面提出质疑：

1.有没有充分的证据说明预防措施100%取得了效果？

2.如何证明预防措施的设计实施环节没有出错？

简而言之，O值只是代表了预防措施的设计质量，而不代表预防措施的执行质量。设计质量取决于对failure cause的了解程度，理论上来说对failure cause越了解我们越能准确地“对症下药”。但是“药效”如何？在配药的过程中是否出现从差错？还需要进行进一步的验证以来证明预防措施真的取得了预期的效果。探测措施就是用以验证预防措施的有效性。

设计理解线路图

对探测措施的定义或设计是否完整，将直接决定验证的可信度。因此引入D值，对探测措施的验证质量进行评分。

下表准确地描述了对O值和D值的理解。

回到本节主题，在确定失效网的S\O\D值后，将进行风险分析，确定需要采取优化措施的优先级。对于风险评估的标准每个公司都可能有自己的标准，有些公司用RPN值，RPN=O*D*S，根据RPN的结果大小来确定优先级。有些公司采用S*O值的结果来进行确定。不管采取哪一种评价标准，核心的目的是识别出系统中最需要优化的点。

2.5.Optimization（优化）

优化的目的是对需要采取进一步措施的failure cause定义新的预防措施和探测措施，以降低O/D值从而将风险降低到可接受的范围。

是否需要采取优化措施，采取什么样的优化措施，这是FMEA团队的共同决定。当优化措施被定义以后，应相应地定义负责人和完成时间，以便对优化措施的状态进行跟踪。另外需要指出，优化是一个迭代的过程，对于同一个failure cause，可能要定义不止一轮优化措施。

下篇预告

本文系统地介绍了FMEA的方法论以及开展FMEA的关键步骤。不过，当我们将这一套方法论运用在分析E/E系统上时，其实会遇到一系列的问题，常见的有：

• 怎么用FMEA来分析软件？
• 对一些失效模式，软件中定义了监控模块，在车辆运行过程中及时探测失效，这类监控在FMEA是否应该考虑？如何考虑？

下期将围绕这些问题对FMEA进行进一步的阐述。

本文转载自：焉知智能汽车