如有其他需要，请查看看更多。

FMEA的七步法

2.1 设计FMEA步骤一：策划和准备

2.1.1 目的

设计FMEA“策划和准备”步骤的目的是确定项目将要执行的FMEA类型，并根据正在进行的分析类型（即系统、子系统或组件）定义每个FMEA类型中包含和不包含的内容。

设计FMEA（DFMEA）“策划和准备”步骤的主要目标是：

·项目识别

·项目计划：目的、时间安排、团队、任务和工具（5T）

·分析边界：确定分析中包括什么、不包括什么

·利用以往的经验识别基准FMEA

·结构分析步骤的基础

2.1.2 DFMEA项目识别和边界

DFMEA项目识别包括明确了解需要评估的内容。这涉及到一个决策过程来定义顾客项目所需的DFMEA。在分析中需要不包括和包括的内容同样重要。

以下基本问题可帮助识别DFMEA项目：

·顾客要向我们购买什么？

·是否有新要求？

·顾客或公司是否需要DFMEA？

·我们是否制造产品、并拥有设计控制权？

·我们是否购买产品、并拥有设计控制权？

·我们是否购买产品、但不拥有设计控制权？

·谁负责接口设计？

·我们是否需要系统、子系统、组件或其它层面的分析？

对这些问题和公司定义的其他问题的回答有助于创建所需的设计FMEA项目清单，从而确保了方向、承诺和工作重点的一致性。以下可有助于团队定义边界，适用于：

·法律要求 / 技术要求

·顾客需求/需要/期望（内部和外部顾客）

·要求规范

·类似项目图表（方块图/边界图）

·示意图、图纸和/或3D模型

·物料清单、风险评估

·类似产品曾用的FMEA

·防错要求、可制造性和可装配性设计（DFM/A）

·质量功能展开（QFD）

在界定FMEA范围时，如适用，以下方面可能被考虑：

·技术新颖性/创新程度

·质量/可靠性历史（内部、零公里、现场失效、类似产品的保修和保险索赔）

·设计复杂性

·人员和系统的安全

·网络物理系统（包括网络安全）

·法律合规性

·目录和标准零件

2.1.3 DFMEA项目计划

确定设计FMEA项目后，应立即制定DFMEA的执行计划。

建议使用本手册1.5节所述的5T方法（目的、时间安排、团队、任务、工具）。DFMEA的计划有助于公司提前启动DFMEA。DFMEA活动（七步法过程）应纳入总体项目计划。

2.1.4 识别基准DFMEA

DFMEA的部分准备工作包括了解哪些可用信息可以帮助跨职能团队，如基础DFMEA（第1.3节中所述）、类似产品的DFMEA或同一产品系列的DFMEA。家族DFMEA是一个基础设计FMEA的具体化，用于那些包含共同或一致产品边界和相关功能的产品。对于同一个产品系列中的新产品，为完成该新产品DFMEA所需的新项目特定组件和功能将添加到家族FMEA中。新产品的添加内容可能来源于家族DFMEA，也可能来源于参考初始家族DFMEA或基础DFMEA的新文件。如果没有可用的基准，那么团队将开发一个新的DFMEA。

2.1.5 DFMEA表头

在策划和准备阶段，DFMEA文件的表头应当填写。表头可根据组织的需要修改。表头包含了一些基本的DFMEA范围的信息，如下：

2.1.6 结构分析的基础

在步骤一“策划和准备”中收集的信息将为步骤二“结构分析”做准备。

2.2 设计FMEA步骤二：结构分析

2.2.1 目的

设计结构分析的目的是将设计识别和分解为系统、子系统、组件和零件，以便进行技术风险分析。

设计结构分析的主要目标是：

·分析范围的可视化

·结构树或其它：方块图、边界图、数字模型、实体零件

·设计接口、交互作用和间隙的识别

·顾客和供应商工程团队之间的协作（接口责任）

·功能分析步骤的基础

2.2.2 系统结构

系统结构由系统要素组成，根据分析的范围，设计结构的系统要素可以由系统、子系统、装配件和组件组成。复杂的结构可以分为若干个子结构（工作包）或不同层次的方块图，并根据组织起因分别进行分析，或确保足够清楚。系统有一个边界，将自身与其他系统和环境分开。其与环境的关系是由输入和输出决定。系统要素是功能项目的独立部分，而不是功能、要求或特性。

2.2.3 定义顾客

在FMEA分析中有两种主要顾客需要考虑：

·最终用户：在产品充分开发和销售后使用该产品的个人。

·装配和制造作业：制造作业（如动力总成、冲压和制造）以及整车/产品总装和生产材料加工的地点。处理好产品与其装配过程之间的接口对于有效的FMEA分析至关重要。这可能是任何后续或下游作业，或是下一级的制造过程。

了解这些顾客有助于更好的定义功能、要求和规范，并有助于确定相关失效模式的影响。

注：在不知道最终用户的情况下，参考第2.4.4节中的说明。

2.2.4 系统结构可视化

系统机构的可视化有助于DFMEA团队进行结构分析。团队可以使用各种工具来实现这一点。以下章节种中介绍了常用的两种方法：

·方块图/边界图

·结构树

2.2.4.1 方块图/边界图

方块图/边界图是一种有用的工具，用于描述考虑中的系统及其与相邻系统、环境和顾客的接口。它是一种图表展示法，为结构化的头脑风暴提供指导，并有助于分析系统接口，从而为设计FMEA打下基础。下图显示了产品组件之间的物理和逻辑关系，表示了设计范围内组件和子系统的交互作用、以及与产品顾客、制造、服务、运输等的接口。该图还标识了设计在其使用寿命期间与之交互的人员和事物。边界图可以用来识别结构分析和功能分析中需要评估的关注要素。

图表可能以直线连接的方框形式出现，每个方框对应产品的一个主要组件。直线对应产品组件之间的关系或相互接口，直线的箭头表示流动方向。边界图中要素之间的接口可以作为关注要素被纳入结构和功能分析结构树中。

构建方块图/边界图的方法和格式有很多，可由组织自己决定。在本手册中，术语“方块图”和“边界图”交替使用。然而，由于边界图包含了外部影响和系统交互作用，因此更为全面。

图2.2-1方块图/边界图示例

在DFMEA语境下，方块图/边界图定义了分析范围和责任，并为结构化的头脑风暴提供了指导。分析范围由系统的边界来确定；但是，需要解决与外部因素/系统的接口问题。

·定义分析范围（有助于确定潜在的团队成员）

·识别内部和外部接口

·使系统、子系统和组件层次得以应用

正确构建的方块图/边界图可为参数图（P图）和FMEA提供详细信息。尽管方块图/边界图的详细程度可以不同，但要识别出主要要素，并了解它们如何交互作用，以及它们如何与外部系统交互作用，这一点很重要。

方块图/边界图随着设计的成熟而不断完善。

方块图/边界图的制作可包括以下步骤：

其它示例：AIAG FMEA 第四版框（界线）图范例

2.2.4.2 接口分析

接口分析描述系统要素之间的交互作用

接口有五种主要类型：

·物理连接（例如：支架、螺栓紧固、夹紧和其各种连接）

·材料交换（例如：气压、液压油或任何其它液体或物料的交换）

·能量传递（例如：热量传递、摩擦或运动传递，如链条或齿轮）

·数据交换（例如：计算机输入或输出、线束、电信号或任何其它类型的信息交换、网络安全项目）

·人 - 机（例如：控制、开关、镜子、显示器、警告、座位、出入口）

另一种类型的接口可以描述为没有物理连接的零件之间的物理间隙，间隙可以是静态和/或动态的。

除了子系统和组件本身的内容外，还应考虑子系统和组件之间的接口。

接口分析将方块图/边界图中显示的所有内、外部接口发生的关系性质（强/弱/无、有益/有害）和类型（物理、能量、信息或材料交换）形成文件。

接口分析中的信息可为设计FMEA提供有价值的输入，例如主要功能或接口功能，这些功能将与相邻系统和环境影响导致的潜在失效起因/机理一起进行分析。接口分析还为参数图（P图）提供理想功能和噪音因素的输入。

2.2.4.3 结构树

结构树按层次排列系统要素，并通过结构化连接展示依赖关系。

为了防止冗余，每个系统要素只存在一次，这就保证了整个系统结构清晰明了。

在每个系统要素下排列的结构都是独立的子结构（图2.2-2）。

系统要素之间的交互作用稍后可以描述为功能并由功能网描述（见步骤三：功能分析）。

结构树中总是会存在一个系统要素，即使它只是从功能派生出来，而且还不能清楚地定义它到底是什么。

图2.2-2 结构分析结构树示例

图2.2-3 结构分析表格示例

1. 上一较高级别：分析范围内最高集成层级。

2. 关注要素：受关注的要素，也是考虑失效链的主题项目。

3.下一较低级别或特性类型：结构中处于关注要素下一低级别的要素

2.2.5 顾客和供应商之间的协作

结构分析的输出（设计及其接口的可视化）为顾客和供应商在设计和/或DFMEA项目技术评审期间的协作提供了工具。

2.2.6 功能分析的基础

步骤二“结构分析”中定义的信息将被用于步骤三“功能分析”。结构分析中缺少的设计要素（项目），在功能分析中也会缺少。

2.3 设计FMEA步骤三：功能分析

2.3.1 目的

设计功能分析的目的是确保要求/规范中规定的功能被适当地分配给系统要素。无论设计FMEA使用什么工具创建，其分析都要用功能术语编写，这一点至关重要。设计功能分析的主要目标是：

·产品或过程功能可视化

·制作功能树/网或者功能分析表格和参数图（P图）

·具备相关要求的顾客（内部和外部）功能的展开

·将要求或特性与功能关联

·工程团队（系统、安全和组件）之间的协作

·失效分析步骤的基础

该结构提供了基础，以便能够就每个系统要素的功能和要求对其进行单独分析。为此，有必要全面了解系统及其运行条件和环境，如热、冷、灰尘、溅水、盐、冰、振动、电气故障等。

2.3.2 功能

功能描述了项目/系统要素的预期用途。

一个功能被分配给一个系统要素，一个结构要素也可以包含多个功能。

功能的描述需清晰准确。

推荐的短语格式为：一个“行为动词”后加一个“名词”，表示可测量的功能。

功能应当是“现在时态”，并使用动词的基本形式（交付、包含、控制、组装、传输）

例子：传输动力、包含液体、控制速度、传递热量、标记黑色。

功能描述了一个项目/系统要素的输入和输出之间的关系，目的是完成一个任务。

注：一个组件（即零件清单中的零件或项目）在没有输入/输出的情况下，也可能有一个目的/功能。例如密封件、润滑脂、夹具、支架、外壳、连接件、焊剂等都有功能和要求，此功能和要求包括材料、形状和厚度等。

图2.3-1 输入/接口/输出流程

2.3.3 要求

ISO 9000将要求定义为一个特定设计、产品或过程需要满足的需求或期望。

要求可分为两类：功能性要求和非功能要求。

功能性要求是判断或测量功能预期性能的标准（如材料硬度）。

非功能性要求是对设计决策自由度的限制（如温度范围，材料刚度 (功能)）

要求可以来自外部和内部的各种来源，它们可能是：

法律要求：

·环境友好型产品设计、适合回收利用、操作员不当使用时仍能保持安全、不易燃等。

行业规范和标准：

·ISO9001、VDA6.3过程审核、SAE J等(如ISO 26262功能安全、SAE J3061网络安全）

顾客要求：

·明确要求（如顾客规范）和隐含要求（如无违禁材料）- 在所有规定的条件下

内部要求：

·特定产品的要求（如：要求规范、可制造性、测试应用性、与其他现有产品的兼容性、可重复使用性、清洁性、颗粒物的进入和扩散性）

产品特性

·产品特性指产品的显著特征 (或可量化的属性)，如轴的直径、表面光洁度

2.3.4 参数图（P-图）

参数是功能行为的属性。参数图（P-图）是一个项目所在环境的图表展示。参数图（P图）包括影响输入和输出之间转化功能的因素，专注于优化输出所需的设计决策。

参数图（P图）用于描述单个功能语境下系统或组件的行为特点。并非所有功能都需要参数图（P图）。团队应当关注于受新条件影响的几个关键功能、以及那些在以前的应用中具有稳健性历史问题的功能。可能需要一个以上的参数图（P图），以便说明FMEA团队关注的系统或组件的功能。

完整的功能描述能够为后续失效分析和风险缓解提供基础。

参数图（P图）专注于功能的实现。它可以清楚的识别该功能的所有影响因素，包括可以控制的因素（控制因素）和不能适当控制的因素（噪音因素）。

针对特定理想功能完成的参数图（P图）有助于确认以下各项：

·系统优化所需的因素、级别、响应和信号

·作为设计FMEA输入的功能

·可能影响功能性能的控制和噪音因素

·非预期系统输出

通过创建参数图（P图）获得的信息为测试计划提供了输入。

参考下文中的图2.3-2，项目/系统要素的输出（灰域）经常偏离/异于期望的行为的变差（直线）。控制因素作用于设计，以尽可能接近期望行为。

图2.3-3 电机参数图示例

输入（为取得期望结果您想要输入什么）是对实现系统功能所需的信息源的描述。

功能（您想要发生什么）在参数图中描述，使用现在时态，主动动词后加上一个可测量的名词，并与需求相关。

功能要求（实现功能所需的要求）与功能的性能相关。

控制因素（为实现功能要求，您可以做什么）被识别出来。控制因素可以调整，以使设计对噪音更不敏感（更稳健）。信号因素是控制因素的一种，它是由系统用户直接或间接设置的调整因素，可适当的改变系统响应（即，制动踏板的移动改变刹车距离）。仅动态系统才使用信号因素。没有信号因素的系统称为静态系统。

非功能性要求（除功能性要求以外您需要什么）可以限制设计选择。

预期输出（您希望从系统获得什么）是理想的、预期的功能输出，其量级可能会（动态系统）或可能不会（静态系统）与信号因素成线性比例（如，前照灯的近光启动、制动踏板移动导致的刹车距离）。

非预期输出（您不希望从系统中获得什么）指故障行为或意外的系统输出，它们使得系统性能从理想的预期功能偏高。例如，与制动系统相关的能量理想的转化为摩擦。热量、噪音和振动是制动能量的非预期输出。转向输出可能会对热辐射、振动、电阻、流量限制造成损失。

噪音因素（干扰实现期望输出的因素是什么）是指代表系统响应潜在的显著变化源的参数，从工程师的角度来看，这些参数无法控制或要控制它们不切实际。噪音以物理单位描述。

噪音因素分为以下几类：

·组件间的变化（在一个组件中，以及组件之间的相互干扰）

·随着时间变化（随着使用寿命增加不断老化，如里程、老化和磨损）

·顾客使用（超出预期规范的使用）

·外部环境（顾客使用时的环境，例如道路状况、天气等）

·系统交互作用（与其它系统之间的相互干扰）

2.3.5 功能分析

利用功能树/网或DFMEA表格展示若干系统要素功能之间的交互作用。分析的重点从OEM到一级供应商再到N级供应商。

创建功能树/网或功能矩阵的目的是将功能之间的技术依赖关系进行整合。因此，它在后期将支持失效依赖关系的可视化。当按层次连接的功能之间存在功能关系时，相关失效之间就会存在潜在关系。否则，如果按层次连接的功能之间不存在功能关系，那么相关失效之间也将不存在潜在关系。

为了创建功能树/网，必须检查所涉及的功能。子功能使整体功能得以执行。所有子功能在功能结构（布林逻辑AND关系）中按照逻辑相互连接。

功能结构自上至下逐级详细，较低级别功能描述了较高级别功能是如何被满足的。以下几个问题有助于功能结构符合逻辑的连接：

·“较低级别功能如何使得较高级别功能生效？”（自上而下）以及

·“为什么需要较低级别功能？”（自下而上）

图2.3-4 功能分析结构树示例

表头栏的编号（1，2，3）和颜色有助于显示结构分析和功能分析相关内容的一致性（见图2.3-5）。在这一节中，从左到右回答这个问题：“较低级别的功能如何使得较高级别的功能失效？”

1、上一较高级别功能及要求：在分析范围内的功能

2、关注要素功能及要求：在结构分析中识别的相关系统要素的功能（关注项目）

3、下一较低级别功能及要求或特性：在结构分析中识别的相关组件的功能

2.3.6 工程团队之间的协作(系统、安全和组件)

公司内部的工程团队需要彼此协作，以确保项目或顾客项目的信息一致，特别是当多个DFMEA团队同时进行技术风险分析时。例如，系统团队可能正在创建一个设计架构(结构)，这些信息将有助于DFMEA避免重复工作。安全团队可能正与顾客协作了解安全目标和危险。此信息将有助于DFMEA确保失效影响的严重度评级一致。

2.3.7 失效分析的基础

功能的完整定义（用肯定的词语）将使步骤四失效分析更全面，因为潜在失效的方式和功能失效的方式相同（用负面的词语）。

2.4 设计FMEA步骤四：失效分析

2.4.1 目的

设计失效分析的目的是识别失效起因、模式和影响，并显示它们之间的关系，以便进行风险评估。

设计失效分析的主要目标是：

·确认每个产品功能的潜在失效影响、失效模式和失效起因（失效链）

·顾客和供应商之间的协作（失效影响）

·FMEA表格中失效文件化和风险分析步骤的基础

2.4.2 失效

功能的失效由功能推导而来。潜在失效模式包括但不限于以下几种：

·功能丧失（即无法操作，突然失效）

·功能退化（即性能随时间损失）

·功能间歇（即操作随机开始/停止/开始）

·部分功能丧失（即性能损失）

·非预期功能（即在错误的时间，意外的方向，不相等的性能）

·功能超范围（即超出可接受极限的操作）

·功能延迟（即非预期时间间隔后的操作）

图2.4-1 失效模式的类型

系统和子系统的失效模式描述的是功能损失或退化，例如，当向左打方向盘时，车辆向右转，这就是一个非预期功能。必要时，应当包括整车的操作条件，例如：在车辆启动或熄火时失去转向助力。

组件/零件的失效模式由名词和失效描述组成，例如：密封件扭曲。

对失效的描述一定要清楚，以便阅读人员能看懂，这一点很重要。例如“未满足”、“不好”、“有缺陷”和“坏了”这样的陈述都是不充分的。

一个功能可能会有多个失效，因此团队不能识别出一个失效后就停止。他们应当问：“还有没有其他的失效？”

图2.4-2 失效定义

2.4.3 失效链

FMEA中对失效的分析包括三个不同方面：

l失效影响（FE）l失效模式（FM）l失效起因（FC）

2.4.4 失效影响

失效影响定义为失效模式产生的后果。

失效影响描述的是对下一级产品集成（内部或外部）的影响，对操作整车的最终用户的影响（外部），以及对适用的政府法规的影响（监管）。

顾客影响应当说明用户可能注意到或体验到的情况，包括那些可能影响安全性的影响。目的是预测与团队知识水平一致的失效影响。一个失效模式可能导致多个与内外部顾客相关的影响。

作为设计协作的一部分，OEM可以和供应商和次级供应商分享这些影响。

失效影响的严重度按照表格D1中的10分制进行评级

对最终用户的失效影响示例：

·无可察觉的影响

·外观不良，如近观难看，褪色，表面腐朽

·噪音，例如：未对准/摩擦、流体噪音、吱吱声、啁啾声、嘎嘎声

·异味、手感粗糙、操作更费劲

·操作受损、间歇，无法操作，电磁不兼容（EMC）

·外部泄漏造成性能损失，运行不稳定

·无法驾驶车辆（步行回家）

·不遵守政府规定

·转向或刹车功能损失

在某种情况下，进行分析的团队可能不知道最终用户影响，例如：目录部件、现货成品、第3级组件。当不了解这些信息时，应当按照零件功能和规格(specification)来定义影响。在这种情况下，系统集成人员负责确保选择正确的应用零件。如汽车、卡车、船舶、农用车。

另一列显示在“公司或产品线示例”的评级表上。

2.4.5 失效模式

失效模式定义为一个项目可能无法满足或交付预期功能的方式。

失效模式来源于功能。失效模式应当用技术术语来描述，而不一定是顾客注意到的症状。

在编制DFMEA时，假设设计将按照设计目的进行制造和组装。如果历史数据显示制造过程中存在缺陷，团队可以自行决定是否进行例外处理。

组件级失效模式的示例可以包括，但不限于以下：

系统级失效模式的示例包括但不限于以下：

·机液完全滤失

·脱离的太快

·不脱离

·不传递转矩

·不保持充分扭矩

·结构支撑不足

·支撑结构损失

·无信号/间歇信号

·提供太多的压力/信号/电压

·提供的压力/ /电压/信号不足

·不能承受负载/温度/震动

2.4.6 失效起因

失效起因是指失效模式发生的原因。起因造成的后果是失效模式。尽可能识别每种失效模式的所有潜在起因。无法稳健应对噪音因素（参数图中）也可能是引起失效的起因。起因应尽可能简明、完整的列出，以便针对具体起因采取适当的补救措施（控制和措施）。

失效起因可能源自于下一较低级别的功能失效模式、要求和潜在噪音因素（例如：参数图）。

潜在失效起因的类型可能包括，但不限于：

·功能性能设计不充分（指定的材料不正确、几何形状不正确、选择的零件不正确、规定的表面处理不正确、行程规范不充分、定义的摩擦材料不当、润滑能力不足，设计寿命假设不当、计算程序不正确、维护指南不当等）

·系统交互作用（机械接口、流体流动、热源，控制器反馈等）

·随时间变化 (良率、疲劳、材料不稳定、蠕变、磨损、腐蚀、化学氧化、电迁移、过度压力等)

·对于应对外部环境设计不足（热、冷、潮湿、振动、路面杂物、路面盐等）

·最终用户的错误操作或行为（错误使用挡位、错误使用踏板、超速、拖拽、错误燃料型号、服务损坏等）

·制造设计不可靠（零件几何形状使得零件安装向后或倒过来，零件缺乏明显的设计特征，运输容器设计使得零件摩擦或黏在一起，零件处理造成损坏等）

·软件问题（未定义的状态、损坏的代码/数据）

2.4.7 失效分析

根据分析是在系统、子系统还是组件级别进行的，失效可以视为失效影响、失效模式或失效起因。失效模式、失效起因和失效影响应当与FMEA表格中的相应列相对应。

图2.4-4显示了从整车层面到特性层面的设计相关失效模式、起因和影响之间的级联。关注要素（失效模式）、起因和影响因设计集成的级别而异。因此，OEM级别的失效起因在下一个（一级供应商）级别上可能成为失效模式。

无论如何，当已知情况下，而没有做过假设，在整车层面上的失效影响（如最终用户所感知的）应当进行文件化。因此，应考虑图1.5-1所示的沟通。失效网可由拥有多个设计级别的组织创建。当多个组织负责不同级别的设计时，他们应负责酌情将失效影响传达给上一较高或下一较低级别。

图2.4-5 使用结构树进行失效分析的示例

再次遵循表头编号（1、2、3）和颜色标注，通过检查功能分析中的各个项目，开始构建失效链。

1. 失效影响（FE）：

功能分析中与“上一较高级别要素和/或最终用户”相关的失效影响。

2.失效模式（FM）：

功能分析中与“关注要素”相关的失效模式（或类型）

3.失效起因（FC）：

结构树中与“下一较低级别要素或特性”相关的失效起因

结构分析、功能分析和失效分析可按照下表记录。

图2.4-9 较低级别项目 – 功能 - 失效表格视图

2.4.9 顾客和供应商之间的协作（失效影响）

根据与顾客的协议和与供应商共享的需要，失效分析的输出可在风险分析步骤之前或之后由顾客和供应商进行评审。

2.4.10 风险分析的基础

对潜在失效的完整定义将为步骤五“风险分析”的完整实施提供基础，因为严重度、频度和探测度的评级都基于失效描述。如果潜在失效过于模糊或缺失，可能导致风险分析不完整。

2.5 设计FMEA第五步：风险分析

2.5.1 目的

设计风险分析的目的是通过评估严重度、频度和探测度来估计风险, 并对需要采取的措施进行优先排序。

设计风险分析的主要目标是：

·对现有和/或计划的控制进行分配、并对失效进行评级

·针对失效起因，分配预防控制

·针对失效起因和/或失效模式，分配探测控制

·针对每个失效链进行严重度、频度和探测度评级

·顾客和供应商之间的协作（严重度）

·产品或过程优化步骤的基础

2.5.2 设计控制

现有的设计控制是针对以前类似的设计建立的，其效果已得到证实。设计控制文件为设计的稳健性提供基础。

预防型控制和探测型控制是现有的验证和确认方法库的一部分。

预防控制提供信息或指导，作为设计的输入使用。

探测控制则描述了已建立的验证和确认程序，这些程序已被证明在出现失效时，能探测到失效。

对用于防止已发布测试程序中的失效或条目的设计特征的特定引用将在失效和设计控制之间建立可靠的联系。对于那些必要的但不属于当前已确定的程序库中的预防和/或探测方法，应作为措施写入设计FMEA。

2.5.3 当前预防控制（PC）

当前预防控制描述了如何使用现有的和计划中的活动来减少导致失效模式的潜在起因。为确定频度评级提供基础。预防控制与性能要求有关。

对于不是在该背景下设计的项目或从供应商购买的作为库存或目录项的项目，预防控制应当具体说明该项目如何满足要求。可以引用目录中的规范表。

当前预防控制必须清楚全面地说明, 并引证。如有必要, 可以通过参考附加的文件来完成。诸如“经过证明的材料”或“汲取的经验”之类的陈述，不能算是对控制的清楚说明。

DFMEA团队还应当在设计中把安全边际作为预防控制来考虑。

当前预防控制的示例:

·EMC指令遵守、指令89/336/EEC

·根据模拟、公差计算和程序的系统设计 - 分析概念，以建立设计要求

·公布的线程类设计标准

·图纸热处理规范

·传感器的性能规格

·机械冗余(安全失效)

·可测试性设计

·设计和材料标准（内部和外部）

·文件 – 类似设计的最佳实践、经验等记录

·防错法（如：零件的几何结构防止错误方向）

·与以前应用中经过验证的并具有性能历史记录的设计完全相同。（然而，如果工作周期或操作条件发生变化，则借用的项目需要重新验证，以便探测控制与此相关。）

·屏蔽或保护，可减轻潜在的机械磨损、热暴露或EMC电磁兼容。

·与最佳实践相一致

预防措施完成后，频度通过探测控制来确认。

2.5.4 当前探测控制（DC）

当前探测控制在项目交付生产前探测失效起因或失效模式是否存在。FMEA中列出的当前探测控制表示计划的活动（或已完成的活动），而不是可能永远不会实施的潜在活动。

当前探测控制必须清楚全面地说明。诸如“测试”或“实验室测试”之类的陈述，不能算是对探测控制的明确说明。如适用，应当引用具体测试、测试计划或程序，以表明FMEA团队已确定该测试将在失效模式或起因发生时切实探测出它们（例如：测试号1234爆破压力测试，第6.1段）。

当前探测控制的例子：

·功能检查

·爆裂测试

·环境测试

·驾驶测试

·耐久性测试

·运动范围研究

·硬件、软件仿真

·试验设计

·电压输出的实验室测量

所有对于失效起因或失效模式的探测控制都应输入到“当前探测控制”栏中。

图2.5-1 设计FMEA中的预防和探测

2.5.5 当前预防和探测控制的确认

应当确认当前预防和探测控制的有效性。这可以在确认分解评审过程中完成。该确认可以根据团队的正常产品开发程序，适当的在DFMEA或其他项目文件中记录。如果这些控制被证明是无效的，则需要额外的措施。

若使用之前产品的FMEA条目，应当对频度和探测度评估进行评审，因为新产品可能有不同的条件。

图2.5-2 设计理解路线图

2.5.6 评估

应评估每一个失效模式、起因和影响，以便对风险进行估计。评估风险的级别标准如下：

严重度（S）：代表失效影响的严重程度

频度（O）：代表失效起因的发生频率

探测度（D）：代表已发生的失效起因和/或/失效模式的可探测程度

S、O和D的评估分别采用 1-10 分制，10代表最高风险。

注：即使产品/过程看起来相同，将一个团队的FMEA和另一个团队的FMEA评级进行比较是不合适的，因为每个团队的环境都不同，因此他们各自的评级都是独一无二的（也就是说，评级是主观的）。

2.5.7 严重度（S）

严重度评级是一种度量，它关系到被评估功能的既定失效模式的最严重失效影响程度。严重度评级用于识别某个FMEA范围的优先级，并在不考虑频度和探测度的情况下确定。

严重度应当使用严重度表 D1 中的标准进行估计。该表可以扩充，以包括特定产品的示例。FMEA项目团队应当就评估标准和评级体系达成一致，即使根据单个设计分析做了修改，该标准和体系也是一致的。

如果需要，失效影响的严重度评估应当由顾客转移给供应商。

2.5.8 频度（O）

频度评级是根据评级标准对预防控制有效性的衡量。

频度评级应当使用频度表 D2 中的标准进行估计。该表可以扩充，以包括特定产品的示例。FMEA项目团队应当就评估标准和评级体系达成一致，即使根据单个设计分析（例如：客车，卡车、摩托车等）做了修改，该标准和体系也是一致的。

频度评级值是FMEA范围内的一个相对级别，可能不能反映实际发生的情况。

根据评级表，并考虑已经完成的探测控制的结果，频度评级描述了顾客操作中可能发生的潜在失效起因。

在分析评价值时，可以查阅类似产品领域的专家意见、数据手册、保修数据库或其他经验。

当针对频度评定失效起因时，考虑了对当前预防控制有效性的估计。评级的准确性取决于对预防控制的描述。

以下问题可帮助团队确定适当的频度等级:

·类似组件、子系统或系统的过往使用情况和使用现场经验是怎样的？

·该项目是否是一个借用件或类似于先前水平的项目？

·与先前水平的项目相比，变化有多大？

·该项目是完全新的吗？

·应用是什么或有哪些环境改变？

·是否使用了工程分析 (例如：可靠性) 来对应用的预期可比较频度等级进行估计？

·预防控制是否到位？

·在产品开发过程中，其稳健性是否得到验证？

2.5.9 探测度（D）

探测度评级(D)是对探测控制有效性的估计，用于在项目交付生产前，可靠的证明失效起因或失效模式。探测评级与最有效的探测控制相关。

探测度是一个相对的等级，且在单个FMEA范围内进行评级，它的确定不考虑严重度或频度。应当使用表D3中的标准对探测度进行评估。这个表格可以用公司常用的探测方法进行补充。FMEA项目团队应当就评估标准和评级体系达成一致，即使针对个别产品分析做了修改，该标准和体系也是一致的。

探测度评级最初是对任何尚未被证实的控制的有效性进行的预测。在探测控制完成后，可以对其有效性进行验证和重新评估，然而，探测控制(例如：测试)的完成或取消也会影响对频度的估计。

在确定该估计时，应考虑如下问题：

·探测失效起因或失效模式的最有效测试是什么?

·探测失效所需要的使用记录/工作周期是什么?

·探测失效需要多少样品?

·探测该起因/失效模式的测试程序是否已得到证明?

2.5.10 措施优先级（AP）

团队完成失效模式、失效影响、失效起因和控制的初始识别（包括严重度、频度和探测度的评级）后，他们必须决定是否需要进一步努力来降低风险。由于资源、时间、技术和其它因素的固有限制，他们必须选择如何最好的将这些措施进行优先排序。

本手册介绍了措施优先级（AP）方法，提供了所有1000种S、O、D的可能组合。该方法首先着重于严重度，其次为频度，然后为探测度。其逻辑遵循了FMEA的失效预防目的。AP表建议将措施分为高-中-低优先级别。公司可使用一个体系来评估措施优先级，而不是使用多个顾客要求的多个体系。

风险顺序数是S×O×D的乘积，范围为1-1000。RPN分布可以提供有关评级范围的一些信息，但仅RPN并不能确定是否需要采取更多措施，因为RPN对S、O和D的权重相等。因此，RPN可能会对S、O和D的不同组合产生类似的风险数，使团队无法确定如何进行优先级排序。使用RPN时，建议使用其它方法对类似RPN结果进行优先级排序，例如S×O。不推荐使用风险顺序数（RPN）阀值来确定所需要的措施。本出版物不包括PRN和S×O方法。

风险矩阵可以表示S和O、S和D、O和D的组合。这些矩阵形象的展示了分析结果，并可作为输入来对措施进行优先级排序。这样做时要根据公司设立的标准进行，而本出版物中不包括此标准。

由于AP表的设计是为了和本手册中提供的严重度、频度和探测度表一起使用，如果组织针对特定产品、过程或项目选择修改S、O、D表，则AP表也应当仔细检查。

注：设计FMEA和过程FMEA的措施优先级评级表是相同的，但是监视及系统响应FMEA则不同。

优先级高（H）： 评审和措施的最高优先级。

团队需要识别适当的措施来改进预防和/或探测控制，或证明并记录为何当前的控制足够有效。

优先级中（M）： 评审和措施的中等优先级。

团队应当识别适当的措施来改进预防和/或探测控制。或由公司自行决定，证明并记录当前的控制足够有效。

优先级低（L）： 评审和措施的低优先级。

团队可以识别措施来改进预防或探测控制。

对于潜在的严重度为9-10且措施优先级为高和中的失效影响，建议至少由管理层评审，包括所采取的任何建议措施。

这不是对高、中、低风险的优先排序，而是对降低风险的措施的优先排序。

注：酌情在备注部分写上诸如“无需进一步措施”之类的陈述，这可能会有帮助。

AP表 – DFMEA和PFMEA的措施优先级

2.5.11 顾客和供应商之间的协作（严重度）

风险分析的结果是顾客和供应商对技术风险达成的一致理解。协作的方法包括从口头到正式报告。共享的信息量取决于项目的需要、公司政策、合同协议等。共享的信息内容取决于公司在供应链中的位置。下面列出了一些示例:

1.OEM 可将整车级DFMEA的设计功能、失效影响和严重度与一级供应商的DFMEA进行比较。

2.一级供应商可将子系统设计FMEA的设计功能、失效影响和严重度与负有设计责任的二级供应商进行比较。

3.一级供应商以产品图纸和/或规范或其他方式传达有关产品特性的必要信息，包括对标准或特殊特性和严重性的指定。此信息用作二级供应商PFMEA以及一级供应商内部PFMEA的输入。当设计团队传达“产品特性超出规范”的相关风险时，过程团队可以在制造过程中建立适当水平的预防和探测控制。参考PFMEA第3.4节了解更多信息。

2.5.12 优化的基础

FMEA“七步法”中前五个步骤的输出结果用于确定是否需要额外的设计或测试措施。设计评审、顾客评审、管理层评审和跨功能团队会议为步骤六“优化”提供基础。

2.6 设计FMEA步骤六：优化

2.6.1 目的

设计优化的目的是确定减轻风险的措施以及评估这些措施的有效性。

设计优化的主要目标是：

·识别降低风险的必要措施

·为措施实施分配职责和任务期限

·实施措施并将其文件化，包括对所实施措施的有效性的确认以及采取措施后的风险评估

·FMEA团队、管理层、顾客和供应商在潜在失效方面的协作

·为改进产品要求和预防、探测控制提供基础

优化设计的主要目的是通过改进设计来制定降低风险和增加顾客满意度的措施。在这一步骤中，团队要评审风险分析的结果、并分配措施，以降低失效起因发生的可能性，或者增强探测控制的有效性，以便探测出失效起因或失效模式。

对于那些能改进设计但不一定降低风险评估等级的措施，也可以分配。这些措施指的是具体、可衡量、可实现的措施，而不是制定可能永远不实施的潜在措施。这些措施不用于已经计划的活动，因为它们已经在预防或探测控制中记录下来并且已经在初始风险分析中考虑过了。

如果团队决定不需要进一步采取措施，则在备注部分写上“无需进一步的措施”，以表示风险分析已经完成。

应当使用DFMEA来评估与持续改进设计有关的技术风险。优化最有效的顺序如下：

·修改设计以消除或减少失效影响 (FE)

·修改设计以降低失效起因（FC）的频度（O）

·提高探测（D）失效起因（FC）或失效模式（FM）的能力

·在发生设计修改的情况下，所有受将影响的设计要素都要重新评估

在概念变更的情况下，FMEA的所有步骤都要针对受影响的部分进行评审，这是必要的，因为初始分析是基于不同的设计概念，已不再有效。

2.6.2 责任分配：

每个措施都应当有负责人和与之相关联的目标完成日期。

负责人确保措施的状态保持更新。如果措施被确认，那么该负责人也要对措施的实施情况负责。

记录预防和探测措施的实际完成日期，包括措施实施的日期。

目标完成日期应当切合实际（例如，按照产品开发计划、在过程验证之前、在生产开始之前)。

2.6.3 措施的状态

措施的状态，建议分为以下几类：

开放的 没有措施被定义

尚未决定(可选) 措施已经定义，但还没有决定。正在创建决定文件。

尚未执行(可选) 已对措施做出决定，但尚未执行。

已完成 已完成状态是指措施已经被执行，其有效性已经被证明和记录，并已经进行了最终评估。

不执行 当决定不执行某项措施时，就会分配“不执行”状态。如果实践和技术限制超出当前能力，就会发生这种情况。

只有当FMEA团队评估了每个项目的措施优先级，并接受风险水平或记录措施结束时，FMEA工作才算完成。

如果“不采取措施”，那么“措施优先级”就不会降低，失效的风险就会继续进入产品设计。对于具有开环的措施，需以书面形式将其关闭。

2.6.4 措施有效性评估

当措施完成时，频度和探测度值将重新评估，一个新的措施优先级可能要被确定。

新的措施将获得初步措施优先级评估，作为对有效性的预测。

然而，该措施将一直保持“尚未执行”的状态，直到其有效性得到测试为止。测试完成后，初步评估必须得到确认或在必要时调整。然后，措施的状态从“尚未执行”改为“已完成”。

重新评估应当基于采取的预防和探测措施的有效性，并且新的值应基于设计FMEA频度和探测度度评级表中的定义。

2.6.5 持续改进

DFMEA是设计的历史记录。因此，初始严重度、频度和探测度（S、O、D）编号需显示可见，或至少可作为历史记录一部分使用和访问。分析完成后将形成一个存储库，能够记录过程决策和设计改进的进展。然而，对于基础、家族或一般DFMEA，初始的严重度、频度和探测度（S、O、D）评级可能被修改，因为这些信息在特定应用中被用作特定应用分析的起点。

2.6.6 FMEA团队、管理层、顾客和供应商之间针对潜在失效的协作

在技术风险分析进行期间和/或当DFMEA初步完成时，FMEA团队、管理层、顾客和供应商之间的沟通会将相关人员聚在一起，以提高他们对产品功能和失效的理解。通过这种方式可以使得如何降低风险的知识得以传播。

2.7 设计FMEA步骤七：结果文件化

2.7.1 目的

“结果文件化”步骤的目的是，针对FMEA活动的结果进行总结和交流。

“将结果文件化”的主要目标是:

·对结果和分析结论进行沟通

·建立文件内容

·采取的措施文件化，包括对实施措施的效果进行确认、采取措施后进行风险评估

·在组织内部，以及与客户和/或供应商之间（如需）针对降低风险的措施进行沟通

·记录风险分析和风险降低到的可接受水平

2.7.2 FMEA报告

该报告可用作公司内部或公司之间的沟通使用。当管理层、顾客或供应商要求时，该报告不是为了取代对DFMEA细节的评审。它是DFMEA团队和其他人员的总结，以确认每个任务都已完成、并评审分析结果。

文件化的内容满足组织、预期读者和利益相关方的要求，这一点很重要。具体细节可由各方商定。这样，还可以确保分析的所有细节和知识产权都由编制FMEA的公司保留。

文件的格式可根据具体公司而定。但是，报告应当指出失效的技术风险，并将其视为为开发计划和项目里程碑的一部分。报告可包括以下内容:

A.相较于第1.5 节“项目计划”中的初始目标，说明一下最终状态。

a.FMEA目的 - FMEA的目的是什么?

b.FMEA时间安排 - FMEA的截止日期?

c.FMEA团队 - 参与人员清单?

d.FMEA任务 - FMEA的范围?

e.FMEA工具 - 如何使用所采取的分析方法?

B.总结分析范围并识别新的内容。

C.对功能是如何开发的进行总结。

D.至少对团队确定的高风险失效进行总结，并提供一份具体的S/O/D评级表和措施优先级的方法(如措施优先级表)。

E.对采取的和/或计划中的措施进行总结（包括这些措施的状态），以解决高风险的失效。

F.为进行中的FMEA改进措施制定计划和时间安排，并承诺完成。

a.对尚未确定的措施进行关闭做出承诺和时间安排

b.承诺在批量生产期间对DFMEA进行评审和修订，以确保相对于生产设计来说，分析是准确和完整的(例如，根据公司程序，由设计变更、纠正措施等引起的修订)。(参考第1.4节案例3 FMEA修订)

c.承诺在“基础DFMEA'中找到“出差错的地方'，以便在将来适用时可以再次用于分析。参见第1.3.6节基础和家族FMEA。

新版FMEA第五版2019版FMEA：设计DFMEA全解