fmea案例（软件FMEA如何做？）

fmea案例（软件FMEA如何做？）

FMEA这个工具在软件行业应用其实非常小众，在汽车行业或者说硬件这块应用相对比较多。有些质量人员把硬件质量管理工具想延伸到软件上，才提出在软件设计时应用FMEA这个质量工具，但真正的软件从业者或者软件QA人员，可能有听过但真正在企业使用的可能是极少数。

当下传统企业数字化转型以及新能源汽车电子化，使得软件的重要作用得以凸显，也导致软件研发质量的越来越得到重视。但现实情况是，很多质量管理人员都是硬件出身，对软件并不太懂，因此很多人都希望宋老师讲讲软件FMEA，所以今天我们就聊聊软件的FMEA如何做。

01

FMEA概述

FMEA：潜在失效模式及后果分析

FMEA是一种系统化的过程活动针对产品（系统、子系统、零件）或制造过程；分析潜在失效原因、失效模式及失效后果；识别现行的控制措施；风险评价；按行动优先级，制定改进措施并完成验证。

我们简单一点描述就是分析风险的工具，在风险发生前予以识别出来，并在事前采取合适的措施来消除缺陷，这正是预防思想的具体体现。

FMEA作为技术风险分析工具，可以帮助组织实现如下预期；

FMEA最早参数于美国军方的MIL-P-1629，后来在航天航空业得到应用并获得成功，再逐步推广到其他行业，2019年推出最新版。下图可以看到FMEA的一个发展历程，可以发现在软件行业涉猎还比较少。

最新版的FMEA最显著的改进是，一个是建立了FMEA制定的过程步骤；另一个是，在分析时，更强调系统环境对分析对象的影响。

《GJB/Z1391-2006故障模式、影响及危害性分析指南》对软件FMEA做了一个定义：

软件FMECA主要是在软件开发阶段的早期，通过识别软件故障模式，研究分析各种故障模式产生的原因及其造成的后果，寻找消除和减少其有害后果的方法，以尽早发现潜在的问题，并采取相应的措施，从而提高软件的可靠性和安全性。

02

软件FMEA与硬件FMEA的主要差异

不同于硬件的FMEA有比较多的案例来进行参考，软件FMEA尚缺乏统一可供参考的案例也比较少。两者之间也存在重要差异：

1)分析对象的差异

硬件的分析对象可以明确地选择到底层物理器件，而软件不容易清楚地划分模块和层次，软件分解的深度常常受到工程应用的限制。软件如果也分解至基本的语句级，要穷尽所有的逻辑路径风险，则将面临失效模式无法穷尽，分析工作难以为继的局面。软件运行时的输入数据和外界环境对运行结果也有影响，因此即使单独语句没有错误，运行时仍可能失效；

2)失效模式不同

硬件的失效主要是由于物理器件的老化或磨损带来的参数漂移，因此，硬件的失效模式比较明确而且有限。而软件不存在磨损情况，其失效是由于设计造成的，也与用户的使用软件的方式有关，所以软件的失效模式较为复杂，目前尚无全面系统的定义，因此需要针对具体的应用进行分析。

03

软件FMEA的实施

软件FMEA它是一种引导式的分析方法，通常是在软件的概要设计完成后展开，并在其后的各开发阶段反复进行。下图以最为普及的软件生命周期模型：瀑布模型，为例，说明实施软件FMEA与软件开发过程之间的关系。

当软件的原型结构设计出来并且确定了每个模块的功能要求之后，就可以进行系统级软件 FMEA。其目的是鉴定软件架构的质量属性，侧重于从系统的角度去分析各个子模块的输出和各模块之间的协调匹配，主要包括软件功能FMEA、软件接口FMEA。

详细级软件FMEA可以确定模块设计是否达到了软件质量要求，识别具体的失效情况，确定失效的根本原因。

因此，通常软件FMEA的实施过程其实主要分为如下步骤：

04

软件FMEA的案例

从系统级FMEA与系统的业务逻辑相关性比较高，相对来说详细级的FMEA与业务逻辑关联性不大，因此，我们以详细级软件FMEA为例来谈一个案例。

常用的过程式设计

fun main（）

{

task1（）

{

fun1（）

fun2（）

。。。

funx（）

}

task2（）

。。。。

taskn（）

}

这种结构，通常表达的设计意图说明：

main 是主入口函数，对下面所有任务级模块进行调度

task 是任务模块，具体处理一个业务功能点或者某个外部负载的控制，可以理解为一个模块；

fun 是最后代码实现函数

我们与软件架构分层对应可以看每个功能由一个main对应，模块由task对应，具体函数由fun来对应。我们对模块1中来进行FMEA

一个软件函数，从通用性抽象而言也是输入与输出，还有函数内部的处理逻辑，所以分析时从下面几个通用的方面展开：

1、运行时不符合要求

2、输入不符合要求

3、输出不符合要求

在相关IEEE标准和GBJ标准中，对软件常见失效模式与原因有些说明，摘取其中部分：

这里以一个系统时钟系统为例，

把前段部分截取下来如下表，因为这里仅仅是个案例，选取各函数的，输入、函数内处理、输出 的异常，分别举了一个案例。

大家可以结合软件常见失效模式，针对输入、输出、程序处理 每种可能的失效模式进行分析与识别，尽可能全的识别出对应的风险。

风险识别后，对应的风险评估还有，应对措施的制定，相对比较简单了，所以，这里就不再累述。

05

注意事项

1、软件设计，其实很难确切的说，哪一个是概要设计，哪一个是详细设计。因为，下一层的设计对上一层级就是详细设计。只能说取决于，系统层级的设计分配或者约定。因此，做软件FMEA，务必要进行软件系统架构的设计与分层，否则直接到代码层级，是很难获得结构信息的。

2、一个软件FMEA的制作，大家可以发现，即使一个很小的函数其可能的失效原因也众多，一个大型软件如果完整的实施FMEA几乎肯定会遇到“逻辑爆炸”的困扰，在实际商业项目的成本和进度约束下很难完成。因此我们需要做取舍，可以考虑，仅对新设计、有变更的，并且扇入、扇出大于5的这类发生风险的可能性大的模块进行分析。

3、在软件设计中其实比较好的方式是把失效模式的设计为编码规范，然后通过在编码过程中的自动化工具的检查、人工同行评审的方式落实。

软件 失效 设计 分析 模式