使用FMEA软件的可靠性分析

第3期 常州轻工职业技术学院学报

2009年9月 Changzhou Institute of Light Industry Technoloy

使用FMEA的软件可靠性分析

章琦 章磊

（中山大学软件学院 广东广州 510080；江苏常州轻工职业技术学院 江苏常州 213164）

〔摘 要〕为了提高软件产品的可靠性，采用FMEA(故障影响模式分析) 的方法，探索一套行之有效的，可实际应用的软件可靠性分析方法。应用结果表明，使用SFMEA 分析方法的软件产品，在运行故障率, 故障损失，故障修复率等方面都要优于以往软件产品, 因此，SFMEA 在提高软件项目可靠性, 进而减少软件产品应用中的失效性方面, 具有显著效果。

〔关键词〕可靠性 故障影响模式 故障修复率 0 引 言

设备的可靠性包括硬件可靠性和软件可靠性。随着可靠性设计活动在产品中的深入开展，系统级FMEA 分析，板间信号级FMEA 分析，器件级FMEA 分析和RCA 分析已经广泛应用于系统设计和单板硬件设计中，硬件可靠性分析设计方法已经非常成熟。而对于系统设计中的软件设计则还没有提高可靠性的设计方法，因此，迫切需要一套提高软件可靠性的分析和设计方法，从而保证系统可靠性。

FMEA （Failure Mode Effect Analysis）故障模式影响分析是指在产品设计过程中，通过对产品各组成单元潜在的故障模式及其对产品功能的影响进行分析，并把每一个潜在的故障模式按其严重程度予以分类，提出可以采取的故障检测、补偿、预防、改进等措施，以提高产品可靠性的一种设计分析方法[1]。

FMEA 分析方法包括硬件法和功能法两种。硬件法是指从硬件的角度，对每个器件管脚输出

章磊（1980—），男，上海海事大学毕业，硕士，讲师。

分别去考虑故障模式，故障影响，检测补偿措施。功能法是指每个产品可以完成若干个功能，而功能可以按输出分类，这种方法将输出一一列出并对它们的故障模式进行分析。

软件功能流FMEA 分析是采用FMEA 分析功能法的思想，以软件功能流作为分析的基础，对功能执行过程中每个步骤的可能失效进行分析。功能流是指系统某一具体功能的实现过程，可能只设计单个模块，也可能涉及到多个模块。

在分析中不仅考虑软件功能实现的问题导致处理过程失效，还考虑其他环境因素导致的处理过程及输出结果失效。比如数据或消息交互过程中的通信故障，软件处理过程中的异常掉包，数据存储过程中存储介质失效，Asic 器件的软失效导致数据改写，人为误操作等等。

软件功能流FMEA 分析方法跟其他FMEA 一样，具有最基本的两个特性[2]：便利性和系统性。便利性就是保证软件处理过程中的各个步骤都经过统一考虑，通过分析每个处理步骤中的异

- 17 -

使用FMEA 的软件可靠性分析

常和其对系统影响，找到处理流程设计中考虑不够严密的设计问题；系统性是指FMEA 分析方法是通过对系统组件的失效分析，确定其对系统，网络和最终业务（最终用户）的影响。

1 软件功能流FMEA的目的

软件功能流FMEA 分析的最主要目的是发现软件设计和实现中的薄弱环节，针对性的进行改进，提升软件可靠性。

软件功能流FMEA 分析的目的包括： 帮助软件设计者对影响软件功能流的各种故障都进行周密考虑。

有助于找出对系统有重大影响的故障模式并分析其影响程度采取改进措施。

有助于设计者全面系统的了解各个软件模块之间的相互关联关系。

软件功能流FMEA 分析的问题主要具有以下特点：

发现潜在软件内部流程设计缺陷。 发现模块间配合和交互过程中的问题。 能够遍历各种缺陷对系统的所有影响。 发现一些需求规格没有明确，但又必须的可靠性问题。

2 软件故障模式

基于功能的软件故障模式库需要有非常丰富的积累，较短时期内很难完整的支撑软件功能流FMEA ，因此，如果分析当中单纯从故障模式库获取故障模式，无法保证FMEA 分析的便利性，很多潜在的问题就无法在FMEA 中暴露出来。

没有理论指导的情况下由评审专家发散性的补充故障模式，尽管也可以取得很好的效果，但这种方式投入太大，严重限制了SFMEA 分析的应用和推广。

针对以上问题，我们可以使用“头脑风暴”形成故障模式的方法对软件功能流FMEA 中的故

- 18 -

障模式进行补充，此方法可帮助分析人员开拓思路，更全面细致的考虑某个功能故障模式。提高SFMEA 分析的效率和效果，发现软件设计中潜在的问题。

软件功能流FMEA 分析的过程中，一个大的功能流往往被分成若干个子功能流进行分析，针对软件功能流中的某一特定功能，需考虑以下几个方面的故障：

1) 提前失效

即输入条件的异常。输入异常如：输入参数错误；传入的消息丢失；消息错误等。

2) 结果失效

即输出结果的异常。输出异常如：无返回值；返回值错误；传出消息丢失；处理动作不成功等。

3) 环境失效

即支撑这个功能的底层软硬件环境的实效。环境异常如：底层软件出错；硬件失效（存储器故障, 单板复位, 供电异常, 温度异常等）。

4) 异常操作

对来自用户的操作缺乏判断和规避可能导致出现严重后果。如用户发出删除数据库命令，而指定的数据库不存在，此类错误可看作输入失效的一种。

5) 功能失效

即功能点的核心处理过程失效。这种失效可能由于设计或实现上的错误产生，也可能由于其中更细节的字处理过程失效导致。

3 软件功能流FMEA详细操作过程

软件功能流FMEA 跟器件级FMEA 分析基本类似, 但跟一般的FMEA 相比，软件功能流FMEA 分析的某些步骤需要重点投入才能保障整个FMEA 分析的成果，软件功能流FMEA 分析流程图如下[3]：

使用FMEA 的软件可靠性分析

下面我们具体来看看每个步骤地主要含意. 3.1 确定进行FMEA 分析的功能流 软件功能流FMEA 分析对象可以是一项处理流程，也可以是一系列的处理流程，可以是纯软件过程，也可以是软硬件结合的处理流程。选择分析对象的重点应放在：业务处理相关（保护处理，业务配置等）；状态机复杂；处理过程复杂；多个进程，多个模块间交互；软硬件交互等，由客户与可靠性工程师共同讨论确定。

要进行软件功能流FMEA 分析，首先要做到对分析对象非常了解，因此在进行分析之前，最好先熟悉模块的架构、功能及处理流程，可以参考培训文档，需求规格说明书，规格设计文档等。

对要进行FMEA 分析的功能流进行分解，划出模块的功能流图，在此过程中再次分析FMEA 流程，子流程的正确性与完整性。

3.2 确定分析对象详细流程

上一步确定的是一个全局流程，对于进行软件功能流FMEA 分析还是比较粗的，所以这个步骤需要根据前面确定的分析对象，对流程进行两个层次的细化。首先要根据分析对象的特点确定出主要的子流程，然后再对每个子流程进行逐步的细化。此项工作要由熟悉方案的软件开发人

员负责完成。

流程细化的过程中比较难把握的一点是：异

常细化到什么角度？软件功能流FMEA 分析活动是在HLD 阶段进行的，要求至少细化到这个阶段已经确定的运行步骤的程度，主要是便于分析，便于找到处理过程中的隐患为目的。一般来说没有必要细到具体的函数实现以下的层次。

详细功能流一般是由软件开发人员给出。详细功能流给出后由PL 进行审核，或者在FMEA 分析表格评审过程中对流程进行再一步的确认。

3.3 明确功能的有效输入

软件功能流中的每一个步骤，列出其所有输出条件，即能够执行这个功能或到达这个状态的所有先决条件，包括但不限于：应用场景，用户操作，输入参数，传入的消息等。

明确有效输入的意义在于，在考虑着一个步骤可能存在故障模式，可以参考这列每一个输入条件进行分析其失效的可能及失效的影响。

3.4 建立故障模式/异常条件

充分考虑每一个步骤的故障模式，并判断其发生的可能性。

故障模式由软件工程师负责完成，可靠性工程师负责协助，实际过程中由于不同分析人员的经验与水平不同，结果可能不一样。

故障模式/异常条件考虑的是否充分直接决定了软件功能流FMEA 分析的深入程度和输出质量，因此在确定故障模式和故障原因时，最好

- 19 -

使用FMEA 的软件可靠性分析

召集市场，维护，测试，软件设计，系统设计，可靠性等方面的专家一起讨论确定。只有全面地分析所有可能的故障模式，尤其是故障出现概率高，影响大的故障模式，才可能充分分析这些功能流中存在的故障隐患。

3.5 评审故障模式/异常条件

由软件开发工程师，测试工程师，可靠性工程师以及对应模块的软件开发PL 和SE 等共同参与，对分析人员列出故障模式进行评审和补充，保证故障模式的全面性与正确性。

3.6 填写影响功能流FMEA 分析表格 将SFMEA 的成果以表格的形式记录下来，主要包括几个方面，已有容错措施，故障影响，故障严酷度，改进建议等[4]。

1) 已有容错措施

已有的容错措施主要是指故障模式发生后，软件将会采取的检测，规避，恢复措施，也就是系统对此故障可能导致系统功能受损所采取的各种措施。

2) 故障影响（对功能模块）

说明假设的故障模式对被分析的功能实现造成的影响需要给出具体的描述。对于有些故障模式，如果不能确定实际的影响是什么，需要给出不同情况（不同场景，不同条件下）可能的影响是什么，并分别进行描述。

3) 故障影响（对用户，对系统）

说明假设的故障模式对用户以及系统可能造成的最终影响，描述用户能够感受到的故障现象，需要给出具体的描述。如果不能确定实际的影响是什么，则分别进行描述。若不同情况下可能对系统产生多种不同程度的影响需要重复说明最坏情况下的影响。

4) 确定故障严重程度

根据故障模式对系统的最终影响给出该故障模式所属的严重度类别。

严重度的分类可以根据要求制定, 例如: 我们可将严重度分为1，2，3四个等级，分别理解为故障发生后对系统的影响程度的四个等级，致- 20 -

命，严重，一般，提示。具体各种问题应该定义为哪个组别可根据组织规定来执行。

5) 改进建议

改进建议提出用于提高可靠性，减少故障模式影响的改进方法，包括容错，规避，恢复措施等。提出改进建议时，重点关注影响较大，故障发生概率较高的故障。确定方案时以对用户，对系统影响最小为原则，在此基础上进行权衡，优先考虑实现难度较小的改进方案。

3.7 注意事项

为保证软件功能流FMEA 分析的质量，需最大限度的通过FMEA 分析提升软件的可靠性。必须做到以下几点：

1) 软件开发人员必须作为软件功能流FMEA 分析的责任主体。

2) 充分考虑和讨论所有可能存在的故障模式，故障模式的全面性直接决定了SFMEA 分析的便利性。很多分析人员分析过程中容易拘泥于以前的开发思路，单靠个人力量难以保证分析质量，因此应最大限度的发挥团体和评审专家的作用，让参与评审的人充分发表意见和建议。

3)FMEA 作为有效提高软件可靠性的手段, 其作用可能并不能十分直观的显现, 但只要树立起该种观念, 并切实实施, 相信很快就可由前后数据的对比看出其对于软件产品质量的极大提升!

2 结语

本文介绍了ＳＦＭＥＡ（软件可靠性分析）的概念，以及软件可靠性分析的作用与目的。对可能引起软件可靠性变化的各个因素作了分析，同时，详细介绍了软件功能流可靠性分析的方法及具体操作过程。详细阐述了ＳＦＭＥＡ分析的工具－ＦＭＥＡ分析表，并指出了软件可靠性分析的注意事项，对软件可靠性分析工作的开展具有较强的指导意义！

参考文献：

[1]黄锡滋编著，软件可靠性，安全性，与质量手册[M] 北京：电子工业工业出版社，2002.

使用FMEA 的软件可靠性分析

[2]Ozarin N, A Process for Failure Modes and Effects Analy-sjs of computer Software[G].Reliability and Maintain-ability Symposium Proceedings Annual 2003.

[3]GJB/Z 102软件可靠性和安全性设计准则[S].国防科学技术工业委员会，1997－11.

[4]赵晓华, 计算机软件可靠性与质量管理, 中国经济出版社 1992.

[5]柯尧, 赵保华, 屈玉贵. 基于组件系统的可靠性分析[J].北京邮电大学学报.2005,28(6):115－119. [6]H AMLET D, M ASON D, W OIT D. Theory of software reliability based on components[C]//Proc of the 3rd Intl Workshop on Component Based

The Application of FMEA in Software Reliability Effect Analysis

Zhang Qi Zhang Lei

( Software Academe of Zhongshan University Guangzhou Guangdong 510080; Changzhou Institute of Light Industry technology ChangzhouJiangsu 213164)

〔Abstract 〕For improving reliability of software product,a series of effective and applied methods which are used to analyze the reliability of software are explored with FMEA(Failure Mode Effect Analysis ）.The applied result shows that software product which making use of SFMEA method is certainly better not only in failure rate of run but also in loss rate and repair rate of failure than it without using SFMEA process. Therefor SFMEA is obviously effective in improving reliability of software project and even more reducing invalidation of software application.

〔Keywords 〕reliability failure affect mode repair rate of failure

Software Engineering. Toronto: IEEE Computer Society, 2001:361－370.

[7]K ATERING G P， T RIVEDI K，M ATHUR A P. How different architecture based software reliability models are related [C]//Proc of the Fast |Abstracts 11th IEEE Intl Symposium on Software Reliability Engineering (ISSRE 2000), California, 2000.

[8]KATERING G P，TRIVEDIK. Architecture based approach to reliability assessment of software systems[J]. Performance Evaluation, 2001, 45(2 3):179－204.

- 21 -