实施FMEA所需的必要信息

一、系统结构要求具有下列信息：

🔺明确系统各组成部分的特征、性能、角色和功能；

🔺各组成部分、任务、组件之间的联系；

🔺冗余级别和冗余系统性质；

🔺所有设备的系统位置（如果可能）；

🔺由低向高中所有研究的层次都必须具有其功能、特征和性能的相关数据。

二、系统初始化、操作、控制、维护

需要确定系统不同使用条件的详细情况，以及系统及其组件在不同使用阶段下的配置和位置的变化。在考虑指定层次的性能和该层次所出现的危害与损害时，应该定义系统最小性能要求和可用性或安全性的需求。

有必要了解以下几个问题：

🔺每个任务的持续时间；

🔺定期测试的时间间隔；

🔺在系统的严重结果出现之前，采取纠正措施可利用的时间；

🔺整个设备、环境或个人维修条件，包括纠正措施和时间、设备、或完或人员。

所需的进一步信息：

🔺系统启动期间的操作程序；

🔺操作阶段的控制：

🔺预防性和修复性维修；

🔺例行测试的程序（如果使用）。

三、系统环境

应该确定系统所处的环境条件，包括周围环境条件以及在应用过程中其他系统的影响。同时，系统应该连同与之相连的辅助设施以及人机界面共同描述。

通常，在设计阶段并不知道以上这些所有信息，因此需要近似和假设。随着项目不断开展，数据量越来越大，FMEA也将随着新的信息或新修改的假设或近似而不断改进。

FMEA或任何其他分析方法都要求对系统建立确定的模型（也就是系统相关信息的简化）。同时，一般会对故障模式的本质和它们结果的严重性做某些假设。

例如，在充分考虑安全的因素下对故障模式的影响做保守的假设。

硬件FMEA的实施最后带来对故障影响、危害度和条件概率上的权衡决策，包括确认软件特性、序列和时间选择。在这种情况下，需要很清楚地确定影响FMEA分析结果的因素，因为任何后续的变动或软件的改善和变更可能会改变FMEA和由FMEA所派生出的评估结果。而软件的开发和修改一旦确认后，可能会对FMEA和相关评估工作产生有条件性的修改需求。

四、系统结构的表现

可以使用符号特别是图表来表示系统的结构和运行。通常可以采用框图突出系统所必须具有的功能。

在图表中，通过线条把方框连在一起，代表每个功能的输入、输出。通常，必须准确描述每个功能和输入的特性。也可以使用多个图表表示系统运行的不同阶段。

通常，图形化的表示方式，包括与分析方法密切相关的图表（例如故障树或因果图表）将有助于加深对系统结构和运行的理解。然而它们的使用却带来了产生于FMEA和那些方法之间的问题。

五、故障模式

故障模式是通过观察在系统组件中的故障影响来确定的。列出系统所有可能或潜在的故障模式是FMEA的重要基础。

组件或设备制造商应该参与产品的故障模式鉴定，原因如下：

🔺对新研制的组件来说，具有相似功能和结构的其他部件以及它们所做的试验都可以作为一种参考；

🔺对于已经普遍使用的组件，实验室试验方案可以参考实际使用中提供的性能参数和故障数据；

🔺如果复杂的组件能被分解为更小的质量分析部件，则把每一个部件当作系统进行分析；

🔺潜在的故障模式能够从组件操作的典型功能和物理参数中推导出来。

在进行FMEA分析时应该完成故障模式的分类。故障模式的分类有以下2种方式。

1.确定一般的故障模式，例如：

🔺提前运行；

🔺在规定的时间内无法完成相应的功能；

🔺不能在规定时间消除操作的故障；

🔺在运行期间的故障。

2.通过列表，尽可能列出所有派生的故障模式，一些故障模式如下：

结构故障（裂开）；错误的激励；物理联结或者人为干扰；不能停止；振动；不能启动；不能保持正常位置；不能切换；不能打开；不成熟的操作；不能关闭；运行滞后；错误输入--过大；内部渗漏；错误输入--过小；输入的遗失；错误输出--过大；输出的遗失；错误输出--过小；短路（电的）；超出公差（过高）；打开（电）；超出公差（过低）；工作不稳定；间歇性工作；泄漏（电的）；疏忽的操作；错误的指示；流动不畅；通信；无动力；编码错误；受限流；安全问题。

六、共因故障

在可靠性分析中，仅仅考虑任意和相互独立的故障是不够的。由于一些单独的原因，比如设计失误、人为错误等，那么几个系统组件会同时由于这些缺陷的发生从而导致性能下降或者故障，这就是共因故障的发生。FMEA恰能解决这个问题。

共因故障就是（因为从属）在2个或更多组件中发生同样故障的事件（通过原始故障的影响引起的二次失效除外）。

故障原因能够通过使用FMEA定性技术进行分析。FMEA连续检查每个故障模式及其相关原因，并能确定所有的定期测试、预防性维护方式等。它可对所有的故障原因，包括潜在的共因故障，进行分析。

这些原因能被分为5个主要的类别：

1.环境影响（正常的、异常的和意外的）；

2.设计缺陷；

3.制造缺陷；

4.装配错误；

5.人为错误（在操作和维护期间）。

可以根据这些类别制定检查清单，并可用于包含共因故障所有可能原因的详细分析和确定。

构造冗余系统来避免故障是一种趋势。必须小心的是冗余系统本身也不能解决或消除所有的共生故障问题。在处理这些故障中，结合几个方法共同处理故障是很有必要的（功能差异、不同类型的冗余、物理分离、测试等）。

七、人为因素

系统的设计必须考虑防止人为错误造成的影响（例如铁路信号系统中的联动装置，在电脑使用或数据恢复中要求密码确认）。由于在系统中存在这样的防错设计，预防故障的影响将取决于错误类型。在进行故障树分析时也需要考虑人为错误以检查防错设计的效果。尽管不完全，但就这部分故障模式的分析也是有益的。

八、软件错误

由于软件错误或设计不充分产生对系统造成影响的故障。危害度将取决于硬件和软件的设计。这种错误或影响分析不充分的假定只在一定有限范围存在，并且超出了FMEA的分析范围。然而，可以对软件错误所引起的相关硬件影响进行评估。

九、危害度概念

对于任何故障的分析肯定和故障的发生度和影响的严重程度都有关系。危害度的概念是定量的分析以及对FMEA的补充。对于系统的危害性没有通用的标准，因为这个概念和严重度的后果以及发生度都有关系。严重度的概念本身有很多种定义方法，这取决于目标是否和寿命安全、间接损坏或损失，或者服务的可用性有关。

通过如下考虑，危害度的概念大大地增加了FMEA的分析能力：

🔺通过对分析对象进行透彻的研究，可以消除某种特殊的危险，增加故障安全输出的概率，减小故障率，降低损害的程度，以此减小故障风险；

🔺在产品的制造过程中，增加对质量保证的控制力度；

🔺增加了制定关于设计、性能、可靠性、安全性或质量保证特别的需求；

🔺制定对供应商的产品接受标准，包括严格的参数测试；

🔺特殊程序、安全措施、保护设备、监控装置或警告系统：

🔺针对事故预防措施最大性价比的应用。

为了定义危害度，针对考察标准，必须有一个衡量尺度对后果的严重度进行考察。以下是根据后果，将危害度分为4个等级的例子（MIL-STD-1629A 1980）。

十、危害度级别和危害度条件

1.有可能引起系统运行功能退化的任何事件，但对系统或者环境的危害可以忽略，并对寿命或主要部分也没有危害。

2.任何降低系统运行功能的事件，但对系统、寿命、主要部分的危害不可忽略。

3.引起系统主要功能丧失的任何潜在事件，并且对上述系统或其环境造成重大危害，但对寿命或主要部分的危害可忽略。

4.引起系统主要功能丧失的任何潜在事件，并且对上述系统或它的环境有重大危害，同时对寿命或主要部分有灾难性影响。

选择危害度的等级数量是任意的。在这个例子中，等级的划分是基于综合各种被考虑的相关标准和关注的因素做出的，分别为：

🔺对人员（伤、死）的危害；

🔺系统功能的丧失；

🔺环境的影响和物资的损失。

灾难的、临界的、主要的和次要的，这些词被广泛使用在危害度的划分定义上，但在IEC的271中，它们的定义可能不一定适合特定的FMEA用法。在每一项特定FMEA分析过程中，应该给出诸如以上这些词汇的明确定义。

十一、程序

为了适应复杂系统的设计和应用的更改，一般需要保持每个独立的FMEA过程与可用信息之间高度的一致性。下面是在电子行业中，进行FMEA分析的基本步骤。

1.系统的定义和完成系统功能的最小运作需求。

a.系统的完整定义，包括系统的主要和次要功能。系统的使用、预期性能、系统约束以及明确的故障判定准则。

b.另外，有必要定义整个系统和组成部分的可接受性能特征，以及不能接受的性能特征。部分定义还需要考虑将来能进行修改，特别是生产调整、使用以及副产品方面。

c.应该对所有工作和非工作条件下，所有相关寿命期内，所有环境条件下，系统所有的预期和特殊参数进行可接受指标的定义。

d.环境条件例如温度、湿度、辐射、振动和压力应该明确定义，特别是系统的使用环境（暴露的或存储环境）。对于控制系统影响人为操作以及系统设计或操作的问题，则需要考虑更多的因素，例如心理的、生理的和环境的。

2.改进功能框图、可靠性框图、其他图表或数学模型以及相关描述。

使用图表显示系统的功能原理对于系统功能的技术理解和后续的分析都是有必要的。图表可以展示出系统内部组成部分之间的串联或冗余关系以及功能之间的依存关系。这使得系统内部的功能故障具有可跟踪性。可以使用多个图表显示系统操作的替换模式。但每个操作模式一般都需要不同的独立逻辑图表。方框图至少应该包含：

🔺把系统分解为主要的子系统，包括功能关系；

🔺把所有的输入、输出和ID号进行正确的标识，这样每个子系统都能根据其特定的标识进行引用；

🔺所有冗余、备用的信号通道和其他工程参数都应提供度量故障不影响安全性的方法；

🔺应该在基本准则和相关文档都存在的基础上进行分析。

选择系统分析级别的原则取决于期望的结果和设计信息的可用程度。以下内容对系统分析级别的选择会有些帮助。

🔺最高系统级别是从设计概念和指定输出需求中来选择。

🔺分析有效的最低系统级别，就是对功能进行定义和描述时，有相关信息存在的最低级别。已有的经验可以影响最低系统级别的选取。对于任何有相对成熟设计、高可靠性、维修性和安全性记录的系统，可以进行相对粗略的分析。相反地，对于任何新研制的或没有相关可靠性记录的系统，应该进行较详细的分析并选取相应较低的层次开始进行FMEA分析。

在选取FMEA分析最低层次时，可以参考特定的维修级别来划分。比如系统可进行维修的最低层次可以作为FMEA分析的首选层次，然后逐层递升的对每一可进行维修的系统层次进行分析。对于系统的关键模块，应将分析进行到最小可替换单元。

就文档来说，推荐将FMEA做在一张表格中以满足系统的需求，并与设置的目标保持一致。表格没有标准的格式。每个公司必须根据自身的需求设计自己的表格。

十二、故障模式、故障原因和影响、相关重要程度和顺序的确定

FMEA是否成功取决于系统某个关键的模块。而对系统性能进行评估的关键是确定系统的关键模块。可以从以下几个方面考虑先准备一份故障模式的清单，以提高确认故障模式、原因和影响的过程效率：

🔺系统使用；

🔺相关的系统特定模块；

🔺操作模式；

🔺有关操作规范；

🔺时间约定：环境。

在FMEA中特别需要注意，故障模式、原因和影响的定义依赖于当前分析的层次，但这些定义可以相互转换。例如，根据分析级别的对应关系，故障模式可以是故障影响，故障原因也可以是故障模式，而且随着分析的进行，低层次的故障影响可能是上一层次的故障模式。同样，低一层次的故障影响也可能是高一层次的故障原因等。

十三、故障检测确认和隔离方法

故障检测确认就是对故障模式的检测方法进行描述。故障模式不是分析和列出那些可能会引起故障的事件。在操作过程中，需要考虑冗余设计给故障检测带来的影响。

十四、针对防止突发事件制定设计和操作预防措施

FMEA表中应该记录故障的相关重要性，这将清楚地表明当发生内在故障时，设备的确切表现如何。其他的预防措施包括：

🔺冗余设备，如果一个或更多的故障发生时，系统将继续工作；

🔺备用操作方法；

🔺监控和报警装置；

🔺允许有效操作或限制损害的任何其他方法。

在设计中当功能单元（不是硬件就是软件）被重组或重新配置时，其性能将改变。随后，在重复FMEA之前应该对有关故障模式进行再测试。

以下内容可作为FMEA表格的补充。

🔺任何异常状况。

🔺冗余单元发生故障的影响。

🔺对于重要特性的重视。

🔺对于增加后续分析条目的解释。

🔺为了后续的故障分析，参考其他的FMEA或相关条目：

--事件危害度（仅FMECA）的确定；

--故障概率（仅FMECA）的评估；

--考虑多种故障模式的共同影响（可选择的）；

--建议。

注：在没有完成FMEA的情况下，就可能已经得到了最大的收益。

来源：天行健管理咨询，侵删。