失效模式和效果分析(FMEA)是一种系统的识别和预防产品和过程问题的技术。在FMEA中，我们分析出潜在的失效模式，按照不同失效模式下的影响来划分风险等级，按照不同的风险等级来对问题进行优先级排序。风险管理是一种识别与产品相关的风险、评估和评估相关风险、控制这些风险以及监控控制有效性的过程。该过程包括风险分析、风险评估和风险控制。在风险管理的过程中，我们使用FMEA作为风险监控和风险评估的技术方式。

注意，许多人使用FMECA这个词而不是FMEA。在首字母缩写FMECA中，C代表危害。这个过程是一样的，只是你探测到了一个更坏的的结果——失效的危害性。请参考军用标准MIL-HDBK-1629(详情请参见国防部网站http://dodssp.daps.dla.mil) 。

通常，人们会混淆术语“失效模式”和“失效机理”。“我们在这本书中两个术语使用了很多次，所以我将在这里提供说明。”失效模式是失效的实际症状，例如“失效部件”或“性能下降”。故障机理是“腐蚀”或“振动”等故障模式的原因。

FMEAs在设计过程的早期就需要被引入，然后还需要产品的整个生命周期中不断地更新，以捕捉设计上的变化，以及更新FMEA对纠正措施的有效性。在设计的早期，我们会通过FMEAs识别潜在的故障模式，并为该故障模式制定纠正措施，但我们并不知道在实际去执行这项纠正措施并测试其有效性之前，纠正措施的效果如何。这些通常在整个项目的后期才会进行更新。

 

16.1不同类型的FMEA

 

为了使FMEA更易于管理，我们应该首先决定想要的是哪种类型的FMEA。比较常见的FMEA类型有：设计，制程，用户，软件和其它几个常见类型。

 

在设计层面上对整个产品系统进行设计FMEAs。其目的是分析故障模式如何影响系统，并将故障对系统的影响最小化。

 

制程FMEAs是在制造过程中执行。在生产过程中，PFMEA将作为前期质量规划的重要支撑文件之一。其目的是分析和纠正制造过程中可能出现的故障模式，包括设备、工装、仪表、操作员培训或潜在误差来源的局限。

 

用户FMEAs特别关注最终用户，以及他们将如何使用、滥用，甚至可能会如何滥用产品。用户FMEA的其中一个输入是用户手册。用户FMEA将查看安装、使用和全生命周期的情况。当涉及到用户时，我们应该特别注意用户使用产品的各种可能性和场景，哪些会造成产品不完整，或者更糟糕的是，引发安全事件。

 

软件FMEAs主要用于潜在的软件bug，以及界面错误和边界条件的错误。如果我们已经有了一组Bug,并且需要去找寻导致这些Bug的原因，那么，这会是个不错的办法。

 

我们还需要确定的是在哪一个层面上执行我们的FMEA,比如是零部件级？还是功能层级？如果是零部件级的设计FMEA 就先从每个单独的零部件开始，如果是PFEMA就先从流程步骤开始，如果是用户FMEA就先从用户开始，如果是软件FMEA就先从软件的子程序集开始。然后分每个零部件，流程步骤和子程序集的去识别所有的故障模式。

 

如果是在功能层级的，先确定产品的主要功能，再去为每一个功能识别故障模式。对于复杂的系统，我们通常从功能层级开始，然后只在我们确定一个具有高风险的故障模式的时候会在相对应的功能的层级上向下到分解，这样可以节省很多时间和费用。

 

16.2 不同的FMEA标准

 

对于FMEAs来说，至少有20种不同的标准和准则。大多数方法上非常相似，并且只在如何为一个特定的失效模式评分方面存在差异。除此之外，这些都只是大概的描述了如何去罗列这些失效模式以及打多少分，但是跳过了一些更重要的步骤，比如怎样开发自己的评分系统，以及如何有效地识别失效模式。这里有一些常用的标准和准则:
• International Electrotechnical Commission (IEC) standard 812
• Sematech standard E14
• Military standard MIL-STD-1629

 

16.3  FMEA的基本步骤
1.    确定FMEA的边界条件
2.    收集文件和审核设计/流程
3.    建立FMEA小组
4.    确定客户使用剖面/基本使用场景
5.    开发一个评分系统
6.    头脑风暴潜在失效模式
7.    将头脑风暴结果转换到电子表格上
8.    列出每种故障模式的潜在影响
9.    为每个故障模式打分
10.    计算风险优先级(RPN)
11.    为行动的失败模式划分优先级
12.    RPN数值分类
13.    采取行动消除/减少高风险的故障模式
14.    计算评分结果的RPN
15.    在产品生命周期中更新FMEA

16.3.1确定FMEA的边界条件

 

首先，确定您将要执行的FMEA类型(参见第16.1节不同的FMEA类型)和FMEA的边界条件。如果你特别想关注制造过程，一定要明确你的FMEA的边界。我经常看到工程师们会犯的一个错误是，总是试图用一个相对简单的FMEA的结论去定论太多的事情在许多更高层级的失败模式里。由于缺乏专注，他们也错过了很多失效的模式。

 

16.3.2收集文档和审查设计/流程

 

接下来，回顾一下将要对其展开FMEA的所有设计内容或过程，并收集在FMEA过程中有用的文档，包括框图、界面矩阵、用户手册、原理图、PFD，以及你认为会对这个过程有帮助的任何其他文档。

 

16.3.3 建立FMEA 团队

 

FMEAs最好是团队作业。首先，我们需要确定团队成员和各自职能。确保你选择了一个跨职能的团队，这样我们就能进行产品全方位的交流。这团队成员可能是来自设计、软件、制造、测试、客户服务、市场营销、质量和可靠性(以及可能需要的其他功能)的代表。六到十个人会是一个比较好的选择。人太少，不同的意见和见解就会越少，人太多，就会很难保证所有人的意见都能被满足。接下来，您需要选择一个主持人。主持人会引导你通过这个过程，确保每个人都能清楚的了解FMEA的每个细节和过程，不允许任何个人主导    FMEA的活动。我们在第17章中详细讨论了主持人的作用。

 

16.3.4确定任务剖面

 

作为一个产品开发团队，在客户使用剖面的认知上需要达成一致，这是产品开发的基准之一。有些时候，可能需要在销售说明中注明相关事宜。但无论如何，在FEMA开始之前，必须明确所有团队成员都要清晰的认知产品的使用剖面。我们遇到过这个问题，讨论往往会进行的非常激烈。但是，这件事情如果没有得到正确的理解，我们就很难正确认知产品自身的失效模式。

 

16.3.5 开发评分系统

 

开发评分系统是FMEA活动中极为重要的一环，因为你需要根据你所分析的特定产品或使用场景对这个评分系统进行调整，以获得正确的结果。这些分数包括:

 

• 严重度

• 发生频率

• 探测度

• 风险优先级数

 

我建议使用1 - 10评分系统，如果你也觉得它好用，当然你也可以选择其他的度量标准。我们不是非得一定要为每一个值定义一个分数。如果我们在创建评分系统时有些情况无法详细定义评分，当我们去执行FMEA时，可以执行就近原则。我们将看到在表16.1到16.3中没有给定分数的例子。

 

值得提醒大家的是，任何标准的评分系统都是不能直接使用到产品的FMEA中，产品的FMEA评分系统应该也必须是量身定制的。也只有这样，FMEA的过程和结论才可能是有效的。举个例子来说：一般致死都是10分，但是如果你的产品并不涉及安全，而且最多就造成中度伤害。如果，此时仍然沿用10分为会导致死亡的相关失效模式，那么FMEA的整体评分就会被拉低。而本来可能是比较严重的失效模式和高优先级的事件就有可能被误判，原因是因为评分太低。

 

16.3.5.1故障严重程度

 

故障严重度是指如果失效模式发生，后果会有多严重。一些公司开发了三种不同的评分表——第一个是处理设备的严重程度，第二个是处理系统的严重程度，第三个是针对用户的严重程度。表16.1显示了一个严重度评分系统的例子，我们使用的机器人将半导体晶片移动到半导体加工机器之间。

 
16.3.5.2发生频率

 

发生频率，一般是指我们在创建这个表格或者评分系统的时候需要了解当下的元器件或者子系统的失效率水平。对于这个项目来说，我们一般会有两种选择，一种是制作一个当下的失效率水平的表格，然后使用可靠性预计的方法来预计未来各零部件有多少失效，以及如何分配。可是这种方法有一个弊端，那就是并不是所有的失效模式都可以被定位到子系统或者部件级。而且，这种失效模式并不少见。在这种情况下，可靠性预计的作用，相当有限，甚至根本是南辕北辙。比如，一个电源产品，你可以收集数据并且得出由于开关导致的产品失效次数。然后在进行分配，这是可行的。但是，如果因为客户将110V的电源误接入220V系统而导致失效发生的时效。你将如何预计此类的发生概率？

 
16.3.5.3 探测度

 

探测度是指在发生故障时发现它的能力。对于探测，一般也有两种方法。首先，我们可以在检测失效模式之前开发一个评分系统。其次，我们可以开发一个评分系统，在它发生后检测故障模式，这样我们就可以在情况变得更糟之前减轻故障。例如，如果汽车燃料很低，低燃料灯就会亮起来，警告你很快就会用光燃料。

 

这是汽车制造商提出的一种检测方法，这样我们就可以在故障模式变得更糟之前解决这个问题(因为燃料用光了)。表16.3显示了我们用于汽车装配公司的探测计分系统的一个例子。在本例中，我将两种不同的方法组合在一起。
 
这里要注意的是，探测度的评分系统和其他两个是相反的，因为，探测度越高，对系统就越有利。另外，请注意，在本书的撰写过程中，一些FMEA指导方针会让我们并不依赖这个探测评分系统。因为，在开发发生率评分系统的时候，会有一部分交叉的内容。

 

对于不同类型的FMEAs，我们需要为正在执行的FMEA提供独特的评分系统。例如，如果我们正在执行一个流程FMEA，我们将需要提出一个评分系统，这些系统是与生产过程相关的失效所特有的。

 

16.3.5.4 风险优先级

 

RPN是通过将严重度、频度和探测度的分数相乘得到的。开发一个评分系统，分门别类地将风险划分为不同的类别和等级。最后的分数是的RPN。为此，将控制线以上的失效模式转化到控制线以下。然而，一般在这个时候，我不建议大家先把失效模式和风险分类再去打分，因为，很多人可能倾向于给低分，用来避免自己过多的在一到两个特定的失效模式上做太多的工作。我建议大家先打完分以后，在把失效模式和风险等级分门别类的归纳起来。

 
16.3.6用头脑风暴去发现潜在失效模式

 

FEMA的主持人必须通过头脑风暴来引领团队，以确定所有潜在的失败模式。有许多好的头脑风暴技术可以帮助思想自由流动，也可以指导我们去思考。但是，头脑风暴并不是毫无目的的瞎想，“风暴”指的是思维是具有发散性的，不被束缚。如果只是漫无目的的乱想，那会一事无成。 团队也会很快失去耐心，因为大家都不知道到底要干嘛。

 

在头脑风暴会议期间，我最喜欢的两种确定故障模式的技术是边界图和参数图。

 

16.3.6.1 边界图

 

界面编辑图的作用很重要，特别是当你的产品是一个复杂系统或者产品本身与其他系统有很多接口的时候。图16.1显示了界面边际图的示例。我们在这里用不同的线连接不同系统之间的接口。接口可以是物理、能源、材料或数据。如果我们在头脑风暴的时候画一边界界面图，并识别不同的接口，那么FMEA团队就可以集中关注每个接口相关联的失效模式上。不至于漫无目的“风暴”。

 
16.3.6.2参数图

 

参数图，或p 图，通常称为p图，是将头脑风暴会议集中到四个不同领域的一种方法：个体差异、环境、客户使用/工作周期和退化。每个区域都被称为噪声因子，或者一个你无法控制的影响因素。从其中一个领域开始，确定与该领域有关的所有失效模式，然后继续下一个领域。每个故障模式都有输入、输出、控制因素和故障状态。各要素的定义。

 

•噪声因子——所有无法控制因素的影响因子
•控制因素——所有你有可以有效控制的影响因子
•输入——从另一个设备或用户(例如用户与系统交互的用户)输入系统的输入
•输出——系统应该具备的功能
•故障状态——这些是产生的效果(此信息可以输入步骤8 /第16.3.8小节)。

 

P图的基本结构和DOE类似，对于DOE，我们也有噪声因素，控制因素，和错误。

 
当你完成头脑风暴以后，接下来的步骤并不需要每个人都参与，找相关的职能工程师就可以。很多公司在这方面都犯过错误，为了让人才积累经验，为了让员工尽心尽力。让每个工程师参与项目的每一步。其实，这样往往适得其反。长此以往，项目会对所有人来说都会变成一个既漫长又冗余的活动。

 

16.3.7 不能风暴完了就结束了，你需要把结果整理成表格

 

风暴完了需要有结果，不然这项活动的价值何在？这里需要提醒一点，不要在风暴的时候使用表格整理大家的想法和结论。我进场会看见有团队犯这种错误，这样会使大家的思维受到限制。是本来是一个集思广益的活动，变成评分和归类讨论会。

 
表16.5显示了我们可以使用的表格示例。注意，在表格中，有一个“u”和“m”在列P、D和PRN的旁边。“u”是在采取行动前的得分(在采取任何行动之前的得分)，而“m”是行动后的分数(在采取行动后的分数)。还要注意的是，还有一个“参考验证”专栏。“我们建议使用这列，展示你是如何验证行动的效果，或者如果你还没有采取行动。”这是指当你将在以后阶段中采取的行动。举个例子：产品的失效模式之中可能有一个是由于客户的不正确清洗造成的，所以，我们就会希望在用户手册中启用正确的清晰方式。然而，此时很可能用户手册并没有写好。那么，在这个时候，你就可以在这一列加一个提醒，提醒你这一动作必须被加入用户手册。你可以设置一个责任人，并且将这一项分配给编写手册的人。

 

对于步骤8和步骤9(第16.3.8和16.3.9小节)，我们将告诉大家FMEA的垂直方法。使用垂直方法，移动到下一列之前完成一列，而不是完成一行，然后移动到下一行(水平方法)。例如，在列出了所有的故障模式之后，我们在分析系统影响之前，就能清晰的知道每个失效模式的具体影响。这比水平方法要有效得多，我们可以按需要有选择性的有优先级的系统性的评估失效模式的影响和对其进行评分。

 

16.3.8 列出每个失效模式的潜在影响

 

选择最了解产品的团队成员，以及故障如何影响终端系统。他们应该确定每个故障模式的系统层面的影响。我们甚至可以在开始这个练习之前提出一个所有可能会存在的的系统影响的表格，这样这个过程就会更快捷，你的标签也会更加一致。如果你的系统很复杂，可能需要添加一个“局部影响”列，如表16.5所示。

 

16.3.9给每个失效模式评分

 

为严重程度(S)、频度(P)和探测度(D)打分。使用16.3.5节中开发出来的表格。一旦确定了故障影响，我们应该就能够相对较快地对每个故障模式进行评分。通常，由一个人来进行所有的评分活动。

 

16.3.10计算风险优先级(RPN)

 

在填写了S、P和D值之后，应该在电子表格中设置公式，以自动计算得到的RPN。

 

16.3.11采取行动之前先对失效模式进行优先级排序

 

下一步，我们就要对所有的失效模式根据RPN数值进行优先级排序。但是对于所有严重程度得分为10的失效模式，不论RPN值得分有多低，都必须自动保持高优先级。

 

16.3.12 RPN表分类

 

在开始为故障模式采取措施或行动之前，先对RPN表进行分类，以确定哪些风险是无法忍受的、不受欢迎的、可容忍的、可忽略的。参见表16.6，获得与每种风险类型相关联的风险评分，并以此为依据来修订的RPN评分系统的示例。记住这是一个例子;分离RPN表的方式可能有很多种。

 
16.3.13采取行动消除/减少高风险失效模式

 

现在，我们应该将每个故障模式对应一个高风险的数数值，并提出一个降低或降低总风险的方法。如果没有，流程就只完成了一半。你可以通过执行以下一项或多项措施来达到这一目标:

 

1、减少发生故障的概率。
2、降低当失效发生时影响的严重程度。
3、增加在产品发布前或在该领域出现故障时检测故障的可能性。

 

注意，这里的纠正措施可能需要综合使用本书中描述的许多其他技术。

 

16.3.14计算你所得到的RPN

 

接下来，基于我们所采取的操作(或者你在尚未执行既定的计划)计算新的RPN。与我们之前的RPN表比较，确保产生的新的RPN现在处于可容忍的水平或可忽略的水平（控线以下）。

 

16.3.15在产品生命周期内保持FMEA的不断更新

 

并不是到了这一步FMEA的工作就可以告一段落，而是在产品生命周期的每个阶段。例如：对设计进行更改时，或者在执行测试时，周期性地回顾FMEA，确定是否出现了新的故障模式。如果我们有必要重新设计了产品的主要部分，那我们就应该回到第6步(第16.3.6节)，并让FMEA团队一起进行头脑风暴，然后重复步骤6 - 14。

 

同时，每次当我们开发既定的纠正措施或风险降低计划，实施之后，都需要再一次回顾FMEA，并确认这个动作和第一次开发降低风险分数时的效果一样有效。

可靠性整合：将FMEA和HALT结合在一起——让FMEA帮助你编写HALT实验计划

 

FMEA对编写HALT计划非常有用，因为FMEA可以识别出产品的不同部分是如何失败的，这样就可以有针对性的开发测试方案来验证高RPN的对应失效模式是否得到有效缓解。可以参见第19章的吸入器例子。此外，FMEA还可以指出非相关的故障模式，这样当我们在开发测试计划时，您可以选择合适的应力和等级，以避免测试中出现这些故障。

案例学习：FMEA需要一个主导人

 

过去，一家半导体制造设备公司一直在使用FMEA技术，但由于每次尝试FMEA时，效率很低，没什么成效。团队在许多不同的细节上争论不休，却没有什么有用的结果。此外，不同的团队成员说FMEA这个过程耗时太长，他们害怕成为FMEA过程的一部分。他们请我们为他们下次的FMEA会议做准备。首先，我们将FMEA练习结合在一起，这样我们就可以专注于一个特定的领域。然后，我们通过边界接口图和p -图的头脑风暴技术来帮助团队在设计的特定领域，而不是他们以前使用的随机方法。一旦我们有了失败模式的列表，我们就解散了大部分团队，并与其中一个职能团队合作完成了FMEA。这就有了一个更有效的FMEA，覆盖了超过50%的相关失效模式，我们在客户之前的FMEA练习中减少了相当平时一半的时间。