基于本体的SFMEA方法研究

阳曦鹏，胡璇，巩宇，李德华，李世勇

（1.中国南方电网有限责任公司调峰调频发电公司，广东 广州 510635；2.工业和信息化部电子第五研究所，广东 广州 511370）

0 引言

故障模式及影响分析（FMEA）是一种发现潜在故障的方法[1]，其主要目的是为了发现可能对系统功能或性能造成不良影响的潜在故障模式，并通过计算风险优先数（RPN）对其进行排序。当前FMEA的研究热点之一是基于知识的重用[2]。首先，FMEA的效果极大地依赖于分析人员的经验及其对待分析系统所属领域的熟悉程度；其次，故障模式极大地依赖于组件，因此在多次FMEA活动中可以被重用[3]。本体（Ontology）是共享概念模型的明确、形式化的规范说明[4-5]。近年来，采用本体方法对关键系统进行可靠性分析一直是一个热点。Ebrahimipour V采用本体方法以支持FMEA研究[6]。其研究的主要思想是应用本体对FMEA结果表格中的词汇形式化。Martin Molhanec提出了一种基于本体的无铅锡焊FMEA方法[7]。此外，本体方法的使用也能够在一定程度上克服传统FMEA方法基于文本描述的局限性并能提供查询及定位功能。

软件故障模式及影响分析（SFMEA）由硬件FMEA发展而来，用于分析软件系统中的软件失效对系统造成的可能影响，它的基本思想是：识别软件存在的潜在的失效模式、评估失效模式对系统的影响，并提出有效的措施或修改意见。它是一种自下而上的分析方法，通常是在软件初始设计完成后，即软件开发阶段的早期展开，分析各种失效模式对整个系统的影响，从而在软件完成之前为提高设计质量提供依据。由此可见，SFMEA真正的目的是在软件的设计阶段就对各种可能的失效进行预计及量化的评估，若有必要还应采取相应的措施，以防止及避免发生故障，即防患于未然。

本文提出一种基于本体的SFMEA方法，解决了传统SFMEA中存在的问题，提升了传统SFMEA方法的效率和质量。

1 实施SFMEA的必要性

传统的产品质量问题的解决思想为先找到产品和服务所出现的所有问题，然后再逐一地解决，通过这种方法不断地对产品和服务进行技术和质量的改进。随着市场竞争的不断加剧，这种被动地为了满足客户和市场的需要，而不是去主动预防产品出现问题和改进产品质量的做法将会使公司失去竞争力。实施FEMA就是为了做到防患于未然，使公司在运行过程中的风险降到最小。以下是实施FMEA的一些好处[8]。

a）可以确定所有问题的优先级

在一个产品的设计和生产的过程中必定会存在很多的问题和困难。但是，重大的事情总是比较少，而琐碎的事情总是比较多，总是要先解决当前最迫切和最需要解决的问题。FMEA能够帮助我们确定这种优先关系。

b）提高效率，减少产品的开发时间和成本

通过对产品故障的发生度和严重度的评估，确定对故障是采取必要的措施还是制定计划，或者是忽略该故障，以便减少问题的复杂性。FMEA让我们把精力和时间都集中在重要的问题上，减少冗余设计，进一步地降低成本和简化设计。

c）为系统、设计、过程或服务的开发过程进行指导

在传统思想上，系统、设计、过程或服务的开发过程所针对的用户都是最终客户，显然这种方法与实际不符，面对具体的问题时，有时用户可能是生产线的下一个操作者或者服务的实施者。FMEA可以指导我们明确问题的用户和确定解决方案。

d）预防潜在故障模式产生的影响，降低和消除产品风险，提高企业的竞争力和形象

FMEA是一种用来评估系统、设计、过程或服务等所有可能会发生的故障的特殊方法，协助对故障进行确定和预防，确保考虑了所有可能的故障及其对产品功能的影响。不仅可以维护客户的利益，而且能够保证产品的可持续性改进。

2 SFMEA的基本概念

下面给出SFMEA的几个基本概念。

a）软件失效（Software Failure）

泛指软件在运行中丧失了全部或部分功能、出现偏离预期的正常状态的事件。软件失效是由软件的错误或故障引起的。

b）软件失效模式（Software Failure Mode）

软件失效模式是指软件失效的不同类型，通常用于描述软件失效发生的方式和对设备运行可能产生的影响。

c）软件失效原因（Software Failure Cause）

指包括物理设备损坏、接口信息错误、设计缺陷和调用错误等方面的基本失效原因，以及初始化信息错误等失效原因，这类原因可能会逐步地恶化并导致最终的软件失效。

d）软件失效影响（Software Failure Effect）

软件失效的影响是指软件失效模式对软件系统的运行、功能或状态等造成的后果。

e）危害性分析（Criticality Analysis）

用于表示软件失效对系统影响的严重程度。通常采用RPN来衡量软件失效的危害性。RPN由软件失效模式的严酷度等级、软件失效模式的发生概率等级和软件失效模式的被检测难度等级的乘积计算得出。

f）软件失效模式及影响分析（SFMEA）

指对软件系统中存在的潜在的失效模式进行分析的过程。通过分析来决定每种失效对系统产生的影响，并根据失效的严重级别对各种潜在的失效模式进行分类。

3 SFMEA分类

3.1 系统级SFMEA

系统级SFMEA主要对系统的功能方面进行失效分析，即从软件系统的顶层分析软件失效的模式，常应用于软件开发阶段的早期，如概要设计阶段。系统级SFMEA对软件体系结构进行安全性评估，确保软件结构能够抵御软件失效所带来的影响，进而修改软件设计，降低软件开发风险。其分析的对象是设计阶段早期的高层次的子系统、功能模块或部件[8]。由于系统级SFMEA侧重于从系统的角度去分析子模块和各个模块之间的协调匹配，因此可以将各个软件模块看做功能已知的黑盒进行分析。

进行系统级SFMEA不像硬件FMEA那样简单，因为软件是一种逻辑结构，而不是一种物理实体，必须将潜在的失效识别出来并翻译成软件术语。在设计过程中应该尽可能早地进行系统级SFMEA，以减少设计缺陷并降低软件开发成本。系统级SFMEA需要在开发阶段的各种过程中不断地重复进行，后期还应与详细级SFMEA同步进行。值得注意的是在这个过程中要充分地考虑到分析和软件开发的成本。

3.2 详细级SFMEA

详细级SFMEA的任务是深入软件模块内部，通过分析每个软件模块的变量和算法的失效模式，确定失效影响和产生失效的原因，保证软件模块和系统的安全性。由于详细级SFMEA对象是已经编码实现的模块或由伪代码描述的模块，因此如何准确地描述模块中语句间的各种依赖关系是这一部分的关键内容[8]。

4 SFMEA的实施步骤

SFMEA的实施步骤如图1所示[9]。

图1 SFMEA的实施步骤

4.1 系统定义

首先，绘制软件功能流程图，明确软件系统各软件部件或软件单元之间的功能逻辑关系，即系统自上而下的层次关系。其次，定义软件约定层次结构。软件系统由程序、分程序、模块和程序单元组成。在定义软件约定层次时应根据实际需要，重点考虑关键的、重要功能的软件部件或模块。

4.2 软件故障模式分析

软件故障模式是软件故障的表现形式。软件故障模式分析的目的是针对每个被分析的软件单元，找出其所有可能的故障模式，如表1所示[9]。

表1 软件故障模式分类及其典型示例

4.3 软件故障原因分析

针对每个软件故障模式应分析其所有可能的原因。软件故障原因往往是软件开发过程中形成的各类缺陷所引起的。软件故障原因按其缺陷分类及典型示例如表2所示。

表2 软件故障原因按其缺陷分类及典型示例

4.4 软件故障影响及严酷度分析

软件故障影响及严酷度分析主要包括软件故障影响和软件故障影响的严酷度两个方面。

a）软件故障影响

软件的故障影响必须分析每个软件故障模式对软/硬件综合系统的功能影响，考虑软件系统自身的复杂性，其故障也可以按照功能及硬件FMEA方法分为局部影响、高一层次影响和最终影响，如表3所示。但是，基于软件的特殊性，在分析软件的故障影响时，可直接分析其最终影响，也可直接分析软/硬件综合系统的影响。

表3 SFMEA表

4.5 改进措施分析

根据每个软件故障模式的原因、影响及严酷度等级，综合地提出有针对性的改进措施。初始约定层次 任务 审核 第页·共页约定层次 分析人员 批准 填表日期

5 基于本体的SFMEA方法

本文研究基本本体的软件系统级FMEA。下面给出基于知识本体的软件系统级FMEA过程模型如图2所示，包括：分析了解目标软件、构建SFMEA知识本体、确定系统功能并划分模块、软件故障模式分析、软件故障原因分析、软件故障影响分析、软件危害性分析、提出改进措施和形成SFMEA报告，以及更新软件故障模式库。这一模型在传统模型的基础上增加了构建SFMEA知识本体这一过程，使得FMEA知识的重用成为可能，并有助于提高FMEA的质量和效率。下面详细地介绍SFMEA知识本体构建的相关内容。

图2 基于本体的FMEA过程模型

5.1 SFMEA知识多本体框架

本研究借助知识分析和设计系统（KADS：Knowl edge Analysis and Design System）[6，10]对FMEA知识系统进行建模。在此基础上通过使用本体，保留了该模型中知识层次划分清晰、各层知识具有良好的可维护性和可重用性的优点，同时消除了各层知识间缺乏强有力的纽带及领域层包含的知识不完备的缺点。依据本体建模论域的抽象层次可把本体分为多种类型，包括：泛化本体（GO）、领域本体、任务本体和应用本体[11]。其中，泛化本体描述了独立于特定问题或领域的泛化概念，位于本体结构的顶层。领域本体和任务本体是对通用领域的描述，也是对泛化本体的特化。应用本体依赖于特定领域和任务，是对领域本体和任务本体的特化。本文对软件系统级FMEA（领域层）进行研究，因此研究范围为本体的泛化层和领域层。得到软件系统级FMEA知识多本体框架如图3所示。

图3 软件系统级FMEA知识多本体框架

由图3可见，本体间存在类层次关系。GO可经实例化得到软件系统级FMEA领域本体。GO可划分为结构本体（静态视角）和行为本体（动态视角）。领域本体能在相同的领域中重用。该框架中，软件系统级FMEA数据、领域知识和行业标准均为领域本体的源泉，各个利益相关者均能参与到多本体框架构建过程中来，故该框架是基于多视点的。

5.2 SFMEA知识本体的定义

5.2.1 本体的形式化表示

不论本体位于哪个层次，都由构成本体的类、关系、约束和公理定义共享知识的常用词汇。因此可将本体形式化定义为如下6元组。

定义1O=（C，H，I，R，P，A）

C=CC∪CI表示本体概念集，CC表示类的集合，CI表示实例集。c2∈CC}表示概念层次集，即c1是c2的子类。I=CI}表示本体类和实例间关系集。R={relK（c1，c2，表示既不是kind_of也不是is_a的本体关系集。P={propK（ci，datatype）|ci∈CC}表示本体类和其基本数据类型的属性集。A=CC}，其中表示公理和规则集。

5.2.2 SFMEA知识本体层次结构

5.2.2.1 GO概念类及类层次构建

根据图3，得到图4所示的GO概念类层次结构，带*号的概念类为非终结概念类，其余为终结概念类。若继承关系定义为：

定义2 GO概念类层次中子类自动共享父类属性和结构的机制。

那么，非终结概念类下的子类与父类构成继承关系。该定义表明：可在一个现存概念类的基础上实现一个新类，将现存类定义的内容作为自身内容，并加入若干新内容。可以证明概念关联中的继承关系是偏序关系，表示为：a≤b。图4也表明GO由静态元素和动态元素共同构成。

图4 GO概念类层次

5.2.2.2 SFMEA领域本体概念空间的构建

领域本体概念空间应当包含领域概念、属性和关联，并提供领域中发生活动及主要理论等。软件系统级FMEA领域本体的核心实质上是描述软件系统级故障模式及其原因和影响，因此可以从静态和动态两个方面对其进行刻画。

定义3软件系统级FMEA领域本体概念集C中的每个概念用来表示相同种类的一组对象，并能用相同的属性集进行描述。

本文基于GJB/Z 1391-2006《故障模式、影响及危害性分析指南》[9]和IEEE STD 1044-1993[12]构建软件系统级FMEA知识本体，其核心概念包括：故障模式、故障原因、故障影响、故障风险数（SRPN）、出现频度（SOPR）、严重程度（SESR）和检测指数（SDDR）等。这也是从静态视角对领域的刻画。

此外，从动态视角也可对该领域进行刻画。从本体观点来看，导致故障发生的原因及其影响可被建模为因果关系[7]。因此SFMEA领域本体的核心即是由一系列这样的因果关系构成的链状结构及围绕这一结构的领域概念、关联。这种链状结构的形成是由故障影响的传递性导致的。由表3可见，故障影响可分为局部影响、高一层次影响和最终影响。对某一个给定的层次，其故障影响是其紧邻的上一层的故障表现，即故障模式。这种不同层级间的传递性也使软件系统级FMEA的因果关系链得以形成，如图5所示。

图5 SFMEA的因果关系链

在前述分析的基础上，得到软件系统级FMEA领域本体概念类层次如图6所示，概念关联如表4所示。

图6 软件系统级FMEA领域本体概念类层次

表4 软件系统级FMEA领域本体概念关联

6 结束语

本文给出了一种基于本体的软件系统级FMEA方法，该方法通过本体的使用提供了对领域内概念一致、无二义的理解，并实现了软件系统级FMEA领域知识的共享和重用。

本文仅考虑了以单条链状结构呈现的独立的软件系统级FMEA结果。随着复杂软件系统的发展，同一层次故障模式间及故障链之间也可能相互作用。下一步的软件系统级FMEA研究将考虑上述内容。此外，随着软件密集型系统的发展，一类由软硬件综合作用所引发的故障模式尤其要引起重视，如电磁干扰引起的故障、温度应力引起的故障、振动应力引起的故障等。这些故障有时还以多种应力综合或应力与操作综合的形式出现。对这类故障应当采用FMEA方法进行深入的分析。这些内容都将在对软件系统级FMEA知识本体构建的完善中得以完成。