失效模式和影响分析（FMEA）是硬件设计普遍采用的一种分析方法，用来避免设计遗漏(field failure)。使用FMEA为软件系统建模来提高可靠性的工程人员逐年增加。
在诸多的方法、工具和实践中，FMEA毫无争议是开销最小，容易上手并最为有效的。（我们需要学习的原因） 。
FMEA的核心元素有两块：FBD（Function Block Diagram，功能块图 ） 以及 FMEA工作表
FMEA工作表是整个分析流程的最后交付件，所有分析按照推荐动作优先级在此汇总。
FMEA分析的目的是为了找到潜在的失效点。当FMEA识别到单点失效模式，我们必须有一个可靠的解决方案来应对潜在失效点。
关键的关键，我们需要给各种失效模式提供 失效权重 以及 相应影响 。
即使FMEA不是为软件设计而生，我们仍然可以将这些原则应用到软件上，汲取FMEA方法带来的好处
- 提前识别失效点和系统接口可能出现的问题。
- 做更多的分析工作，让设计有更好的规划和安排。
- 促使早期的测试计划完善。
- 减少培训的投入。
- 提高产品的的可靠性。
通过对系统风险优先级的评估，列出失效模式。风险列表中应该识别到最有价值的可靠性设计点。
典型的FMEA是一个团队活动，通过一次或多次会议完成。系统、子系统的领域Owner，项目leader，QA和至少一名领域专家参加
任何对本系统比较熟悉的开发人员也可参与，以提升分析讨论的质量。
在会议上，可以开展以下几个必要的步骤：
- 定义失效模式 --可能出现什么样的错误。
- 定义影响 --谁（哪个模块，功能，函数）会遭受牵连。
- 描述目标 --出现失效模式会发生什么样的事。
- 找寻根因 ---为什么会发生这样的事。
- 定义策略动作 --如何避免
- 定义当前预防&检测措施 --我们已经（尚未）做的措施。
在会议中重复开展以上步骤，并输出到FMEA的表格中。
表格包含：风险优先级列表和相关系统失效点。
有三种主要的FMEA：
流程：用来分析制造装配流程。这无疑是最直接也是最简单理解的类型。
硬件：在概念设计之前和详细设计之后，用来分析硬件系统。
功能： 基于系统功能的拆分。用来分析系统的上层功能模块，分析评估软件。即：软件FMEA。
因为流程的FMEA最为直接，我们先举一个流程FMEA例子来说明一些基础概念。
下面这个例子里，我们用导热胶带将PCB板附着到金属散热片中的简单例子。 冷却的PCB可以延长零件的有效期。
| 步骤编号 | 步骤名称 | 失效模式 | 影响 | 目标 | 根因 | S | O | D | 应对动作 | 当前方案 |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 用酒精清理金属片 | |||||||||
| 2 | 把导热胶铺在边缘 | |||||||||
| 3 | 清理底座 | |||||||||
| 4 | 用力按压散热片，使之贴到导热胶带上 | |||||||||
| 5 | 用酒精清洗导热槽 | |||||||||
| 6 | 把LED灯带放置在散热片上，施重压在灯带外的区域 |
假设在制造过程外的每个步骤都是完全正确的，而且不是所有的制造步骤都是可区分失效模式的。 如果没有发现可能的失效模式，我们就跳到表格的下一行继续执行分析动作。
步骤：用酒精清理金属片
可能的失效：金属片可能没有清理干净。 可能的失效：金属片可能在清洗过程中折弯。
这两种可能性就是本步骤的失效模式。
对于已经列出的每个失效模式，下一步要问的是“会发生什么？”。一个时间只关注一个失效模式。 并聚焦失效造成任何直接结果。
失效模式：金属拨片可能没有被完全清理干净。 直接结果：铺上的导热胶没有完全黏着，导致热胶路径开裂，从而导致PCB过热或直接整块脱落。
失效模式: 金属薄片可能在清除过程中弯曲。
直接结果：散热片和金属薄片之间形成一个空气隔层。导致导热胶覆盖路径脱落而使PCB过热。 直接结果： 后续步骤中存在弯曲变形过于严重导致无法安装。导致返工
第三步就是如何影响的对象，通过问自己“谁会因为这个失效出现问题”
影响： 导热胶没有黏着，导热路径脱离，PCB过热
谁会受到影响：过热通常需要期间承受一定的压力才会出现，生产测试中可能发现不了。很有可能将该缺陷带给客户。
影响： 导热胶中的空气鼓，导热路径脱离，PCB过热。
谁会受到影响：过热通常需要期间承受一定的压力才会出现，生产测试中可能发现不了。很有可能将该缺陷带给客户。
失效模式： 金属片没有完全清理干净。 根因： 存在酒精无法溶解的污染物。 根因： 操作错误
失效模式： 金属片在清理过程中被折弯。 根因： 操作错误。
根因填在FMEA表格中的“ROOT Causes”一列。
第五部就是把失效模式和风险的优先级联系起来。每个失效被赋值为1-10之间的三个指标。
+ 严重程度（S）： 1 （无关紧要） 到 10（灾难性）
+ 出现的可能性（O）: 1 ( 不可能 ) 到 10（不可避免）
+ 可检测性（D）： 1 （肯定能被检测） 到 10 （不可检测）
这三个数乘起来就是 风险优先级参数（RPN）。 因此，S x O x D = RPN.
影响： 导热胶带没有完全黏住，导热路径脱离，PCB过热。
严重程度： 6 缩短PCB组件寿命
可能性： 2 经过恰当的训练，这不太可能发生。
可检测性： 3 在生产过程中很容易被检测。
RPN： 6 x 2 x 3 = 36
影响：导热胶带的空气鼓， 导热路径脱离，PCB过热。
严重程度： 6 缩短PCB组件寿命
可能性： 2 经过恰当的训练，这不太可能发生。
可检测性： 1 在生产过程中很容易被检测。
RPN： 6 x 2 x 1 = 12
影响： 严重折弯使得部件不可用导致
严重程度： 3 浪费时间和资源，不会直接影响客户。
可能性： 2 经过恰当的训练，这不太可能发生。
可检测性： 1 在生产过程中很容易被检测。
RPN： 3 x 2 x 1 = 6
-
失效模式： 金属薄片没有清除干净。
解决动作：操作员及时赋能培训清理技巧。
解决动作： 在工作指南中增加污染物检查的步骤。 -
失效模式： 金属薄片可能在清理过程中折弯。
解决动作： 操作员及时赋能培训清理技巧。
解决动作： 在清理中可能需要一个固定平板来支撑金属薄片。
失效模式： 金属薄片没有清除干净。
当前方法：在产线上岗之前对操作员进行培训。在生产中呈现工作指南。
失效模式： 金属薄片可能在清理过程中折弯。
当前方法：在产线上岗之前对操作员进行培训。在生产中呈现工作指南。
把以上所有的步骤重复执行，然后最终得到一个RPN列。我们筛选出最有价值的措施来做系统设计。
FMEA的功能模块（FBD）在软件FMEA分析中是一个必要工具。区别于流程FMEA，软件FMEA是没有预先定义的。
线性工作流的工作指南。
上文的例子中，work guide是FMEA步骤的起点。 软件系统是在run-time决定合适的路径，这样的话FMEA的分析变的复杂。 另一个基本的差别是，软件不需要100%的覆盖设计。 此外，聚焦最有可能出现的失效点，出现的结果哪里最严重。 动作应该聚焦在特定的子系统或系统的新特性。
为了定义这些步骤，需要把系统拆分为功能块，拆解为功能块图。
功能块是一个上层软件系统描述。功能块细节的程度有多决策并受到诸多影响：
- 新技术和硬件的出现。团队需要在新技术和硬件上花费更多的时间。在这些新硬件上输出更多细节的功能块描述。
- 总体的子系统的置信度。系统曾有些可重用的代码吗？这些部分可以用更大的，更少描述性的功能块吗，这样就可以把精力更多放到容易出问题的地方。
- 关注Safety， 谈及Safety，功能块应该更加详细以避免出现假设或忽视。
一个比较顺其自然的途径是使用设计规格中的FBD，但这通常导致宽泛而复杂的设计，所以需要一个更上层的FBD。 可以通过FBD的各个独立的模块组合起来形成这个上层泛化版本。
一旦分析出来的泛化FBD完成，很有可能图标不是线性的，也无法在很好适配到FMEA表格。
系统分解为更小，更具有可管理性的FBD后，每个可以回填到FMEA表格。每个FBD都有会在FMEA表格中占一小部分，会后可以很方便的被引用。
blocks输入到表格后，遍历相同FMEA步骤
1，定义失效模式 --可能出现什么样的错误。
2，定义影响 --谁（哪个模块，功能，函数）会遭受牵连。
3，描述目标 --出现失效模式会发生什么样的事。
4，找寻根因 ---为什么会发生这样的事。
5，定义策略动作 --如何避免
6，定义当前预防&检测措施 --我们已经（尚未）做的措施。
软件FMEA和流程FMEA的差别在于 软件FMEA的 根因 通常与 失效模式 等价。所以相同时，FMEA表格可以省略根因一栏。
需要值得一提的是：分析软件系统不应该把“软件bug“当做失效模式。因为任何一段code都可能包含bug。 bug作为失效模式毫无意义，在FMEA分析中不应该被纳入分析。
这就是说：FMEA分析会议 是检查哪个模块更有可能出现bug的好时机，以此展开深度的代码review。
FMEA在设计的早期阶段运用能体现出最大价值，如果在任何代码完成之前而且在一些重要的需求被定义之后就是最完美的时机。
如果提前执行，FMEA可以暴露系统的薄弱环节。 提出硬件，软件或者组合解决方案来以免在后续项目中付出过大的代价。
在最cost-effective和最可靠的途径间更快的把握住足够大的灵活度
测试开发和计划要提前介入
支撑方案动作的验证 当前预防和检测方法如果是空的话，这里可以添加测试用例。 更多的测试efforts需要来指导RPN值的输出。
一个例子：
在防抱死系统中，有相当巨大的硬件和软件协同工作来保证车辆安全。
如果FMEA方法在任何时间被应用上，传感器的单点故障一旦被检测到ABS需要立即响应。
如果我们提前知道单点故障，我们还有时间增加一个冗余Sensor并设计一个fail-safe刹车机制。
否则，由于我们在设计阶段并未安排有这个分析导致直接因为sensor失效而直接刹车。
列出FBD， 给功能块分组。或者视细节程度拆分一个block为多个。 使用Visio，或者白板上的任务纸条来作为FBD的表现形式。
在工程师在不停的问“如果这样...那么。。。”这种问题事，话题往往会很快的深入。 即使这些讨论很有益，但是应该立即一笔带过。并只在更高层面上讨论问题。 因为我们不是在做代码或设计review.
软件FMEA中常犯的错误：
1，假设所有的错误模式是硬件引起的。
2，覆盖设计的100%而不是聚焦分析最可能出现严重失效的设计。
3，在分析过程中忽略了解决方案的动作
4，会议上讨论到了代码级别
5，没有领域专家参会。
FMEA是最有效的设计方法，提前将fail-safe和冗余或者其他元素加入以提高总体系统的可靠性。