FMEA应用在硬件方面，各行各业也都积累了比较多的实战经验与经典案例。目前，整机产品上越来越多的功能是由软件来实现的，那么，软件FMEA该如何做呢？

本文将从软件开发的视角，以软件FMEA这一特殊方法为切入点，尝试探讨提高软件质量和可靠性的手段。

什么是FMEA？

FMEA(Potential Failure Mode and Effects Analysis)即潜在的失效模式及后果分析，是在产品/过程/服务等的策划设计阶段，对构成产品的各子系统、零部件，对构成过程，服务的各个程序逐一进行分析，找出潜在的失效模式，分析其可能的后果，评估其风险，从而预先采取措施，减少失效模式的严重程序，降低其可能发生的概率，以有效地提高质量与可靠性，确保顾客满意的系统化活动。 

FMEA种类： 

按其应用领域常见FMEA有设计FMEA（DFMEA）和过程FMEA（PFMEA），其它还有设备FMEA、应用FMEA、采购FMEA、服务FMEA。

2019年6月发布的AIAG&VDA FMEA手册明确的将其定义为技术风险分析工具，基于风险管理的过程（ISO31000风险管理将其定义为风险识别、风险分析、风险评价和风险控制），用事前预防（设计开始前）的思维，系统分析产品以及工艺过程控制所存在的风险，并加以系统评价和控制。

所以，从上述来看，FMEA的应用其实非常的明确，就是将FMEA开发的结果应用于设计以及设计控制活动中，以增强设计结果可靠性的保证。

要想让FMEA的价值真正发挥出来，那必须将FMEA理解为一个完整的过程，而这个过程的步骤就是启动（I）、开发（D）、应用（A）及动态管理（A）。

注：IDAA模型是QualityIn质量学院基于多年FMEA实践总结出来的实践方法论，并于2015年正式提出，请勿抄袭或进行商业目的的应用。有关IDAA的具体内容请关注我们的线上或线下FMEA相关课程（www.quality-in.com）。

• 启动

  就是在正式开发FMEA前的准备，这次AIAG&VDA FMEA手册提出的5T（目的、时间、团队、任务、工具）就是在做FMEA的准备工作，而七步法的第一步“策划准备”就是启动。

  当然，我认为七步法中的策划准备并不完整，比如，历史数据、经验教训、以往FMEA的结果的收集等重要工作就没有被显著提及；
  

  
  

• 开发

  这是FMEA的关键阶段，也是大家最关注的阶段，按照七步法的第二到第六步，我们将输出一份FMEA文件；

  
  

• 应用

  在IDAA模型中，每个阶段都非常重要，但最重要的其实不是FMEA的开发，而是FMEA的应用。就是将FMEA开发的结果应用于设计及设计控制过程，不管是针对产品设计还是过程设计，均是如此。

  
  

• 动态管理

  就是将量产后所发生的问题分析结果反向更新到FMEA中去，包括失效模式、原因以及控制措施等等。这个也可以理解为我们常说的逆向FMEA，严格意义上说也应该是FMEA的一种应用形式，是组织知识和经验的不断积累的重要手段。

软件开发质量控制工具箱！

提到软件开发质量控制，非常容易让人联想到敏捷开发、 ASPICE等概念。如果放开思路，不局限于CMMI等既有体系，那么软件开发的质量控制和提升还有多种工具，例如：

• 专家经验类：依靠核心专家的经验，全面把控设计方案和测试过程的合理性，从而对整个设计进行控制。

• 体系推进类：体系推进类是经常被讨论的，涵盖了各种标准化的方法论，如各级review、测试体系、失效库的建立和分析等。FMEA也是其中之一。

• 管理监督类：从结果导向的角度，对软件产品的进度和质量进行考核，从而推动软件开发质量提升。

不同的产品与市场，不同的团队特点下，适合灵活采取各种方案。当然，方案间不是互斥的，相信每个软件团队都有符合自身特点的工具组合。

嵌入式软件如何做FMEA？

1. 必要性

软件FMEA是一个相对特殊的主题。谈到FMEA，被检查对象更多涉及系统、硬件或生产过程，软件似乎并不太常见。而谈到软件质量控制，虽然有各种体系和审核，FMEA却常常不是强制要求。

然而正是这个相对冷门的方法，在汽车行业的软件开发中却孕育着独特价值。根据个人经验，以下是一些特殊要素，可说明其在汽车行业中的重要性：

● 系统整合性：汽车行业的软件需在一个完整系统中工作，因此不能孤立地检查软件。例如，在设计驱动程序时，必须考虑到车辆可能出现的电压波动、温度变化等因素。只有从系统角度来检查软件设计，才能提供更为全面的视角。

● 软硬件协同：软件行为需要与硬件紧密结合，并可能受到批量一致性的影响。例如软件需要与一个外围器件进行SPI通信，单个样品测试多次都是好的，但批量后的少数个体偶发失效也客观存在，不能因此影响客户体验。

● 可靠性和可维护性：整体对可靠性和可维护性要求很高，功能丧失或系统重启等问题可能对客户影响极大。有些与可靠性关联的故障工况，可能在研发阶段难以预见或模拟。而可维护性虽与FMEA关系并不显著，却容易在常规软件review中被忽略。

通过对比经典的软件质量控制工具箱，我们可以发现，虽然其中的专家经验或管理监督方法能全方位覆盖各种问题，但ASPICE等经典体系对于上述特殊要素的聚焦却相对不足。

软件FMEA以其天然的系统观点、关注环节间关联性的特点，以及对衡量标准（如可维护性、关注程度等）的人为调整能力，在汽车行业软件设计中成为一种实用且有效的工具。这一方法的价值不应被忽视，反而应当作为软件质量控制的重要组成部分加以重视和推广。

2. 边界与方法

当然，虽然软件FMEA是一项有力的工具，但在实际应用中必须明智地选取适用范围和关注点。不是每个子系统设计都需要进行一轮FMEA分析，也不是软件设计中的每个部分都需要全部检查。

以下是结合个人经验，对有关软件FMEA适用范围和关键焦点的一些理解。

适用范围：软硬结合的复杂子系统

● 在FMEA的体系下去检查coding级别的错误，投入大且基本难有什么产出，那是ASPICE等工具的长项；

● FMEA体系还是更适合概念性/体系性/失效模式为导向的检查。检查目标为软件产品所实现的功能，而不是软件本身。

失效模式非常体现软件FMEA特色

● 需要考虑失效对软件的影响：例如系统FMEA关注晶振的偏差影响，软件FMEA中就需要关注偏差范围内频率变化是否能被各模块容错处理。

● 需要考虑软件特有的失效类型：例如时序问题、资源抢占、数据一致性等，这些软件特殊的失效类型在软件FMEA中可能会受到重点关注，而在系统FMEA中可能会被忽略。

● 特别考虑失效定位的便捷性：软件失效处理和更新所占的时间不容忽视，因此“失效是否方便被快速定位”是高价值功能，前期提前考虑能节省后期大量人力物力。

经典软件流程与FMEA的不同关注项：

软件开发的质量和可靠性设计是一个综合话题，对此的追求应从设计阶段就需要保证，而不是单纯依靠测试。多种工具和方法都可以为研发过程提供支撑，软件FMEA方法虽被较少提及，但却具有特殊意义。