CN103473400B - 基于层次依赖建模的软件fmea方法 - Google Patents

Abstract

本发明公开了一种基于层次依赖建模的软件FMEA方法，包括第一步，从需求出发，对所分析的对象全面深入了解，确定分析目标；第二步，以概要设计为参考，构建系统级层次依赖模型；第三步，选取待分析模块及确定其失效模式，由系统级层次依赖模型可达性节点分析，分析失效影响传播路径和失效原因追踪的路径，确定失效原因和失效影响，提出改进措施；第四步，根据系统级FMEA结果，选取详细级FMEA分析对象；第五步，以选取的分析对象的详细设计或伪代码为依据，构建详细级层次依赖模型；第六步，根据详细级层次依赖模型，选取要分析的关键变量；第七步，确定待分析变量的具体失效模式，由详细级别依赖模型可达性节点分析，分析变量的产生原因及失效影响，提出改进措施。

Description

基于层次依赖建模的软件FMEA方法

技术领域

本发明涉及软件可靠性工程中的软件失效模式及影响分析(FMEA)领域，具体地说，是指一种基于层次依赖模型的建模，能够有效、方便、自动化进行软件FMEA的方法。

背景技术

软件FMEA是实现软件可靠性增长和对软件可靠性进行评估的有效途径之一。软件FMEA分为系统级软件FMEA和详细级软件FMEA，系统级主要采用层次图的方法，详细级采用变量线索的方法。

传统基于层次图的方法根据软件系统的功能、结构层次确定系统的分析级别以及分析对象，如功能模块、软件部件或单元等。传统的系统级软件FMEA，往往纯粹依赖于软件分析人员的经验，分析过程精确性低、客观性差，且没有效率。传统的详细级SFMEA分析步骤为：建立变量映射表，建立软件线索，确定失效模式。变量线索是以表格的形式来描述的，常用的表格有：模块定义表、函数定义表、变量定义表，变量使用表、函数调用表。这种用表格形式表达的变量线索不清晰，不易观察，而且变量众多、表格众多，造成分析的不便。

另外，GJB/Z1391-2006中的提到的软件FMEA只是针对软件系统级FMEA，而没有给予详细级软件FMEA的规范。

依赖图是软件工程领域的一个十分重要的研究课题，是程序分析、程序理解、软件测试、软件维护的重要基石，通常与程序切片技术结合在一起，在编码结束后，对代码静态分析。然而依赖图在可靠性工程领域，还没有相关的尝试。本文结合FMEA技术特点以及依赖图的特性，将依赖图扩展成层次依赖模型并提出相应的依赖建模方法，根据依赖性分析失效模式的传播影响和追踪失效的原因。

发明内容

本发明为了解决嵌入式软件FMEA中所面临的层次不清晰、路径不易表达、分析方法客观性差、计算机辅助薄弱困境，针对结构化开发的安全关键软件，结合FMEA自身特点，构建一种层次依赖模型，使FMEA失效影响分析和原因分析转化为层次依赖模型的节点可达性问题，为软件FMEA客观分析和自动化分析提供了理论方法。

本发明所提供的软件FMEA方法主要包括以下步骤：

第一步，从需求出发，对所分析的对象全面深入了解，确定分析目标；

第二步，以概要设计为参考，构建系统级层次依赖模型；

第三步，选取待分析模块及确定其失效模式，由系统级层次依赖模型可达性节点分析，分析失效影响传播路径和失效原因追踪的路径，确定失效原因和失效影响，提出改进措施；

第四步，根据系统级FMEA结果，选取详细级FMEA分析对象；

第五步，以选取的分析对象的详细设计或伪代码为依据，构建详细级层次依赖模型；

第六步，根据详细级层次依赖模型，选取要分析的关键变量；

第七步，确定待分析变量的具体失效模式，由详细级别依赖模型可达性节点分析，分析变量的失效影响及产生原因，提出改进措施。

构建层次依赖模型以及利用层次依赖模型进行软件FMEA是本发明的重点。

软件依赖图(Software Dependability Graph，简称SDG)是软件程序间控制依赖关系和数据依赖关系的图形表示。它着眼于整个软件系统的内部依赖关系的表示，综合组成软件系统的多个程序的依赖信息而构建，以图的数据结构描述了程序的内在特征。

本方法将软件依赖图扩展为适于软件FMEA的层次依赖模型。根据软件FMEA分为系统级软件FMEA和详细级软件FMEA的特征，本方法中层次依赖模型也分为系统级层次依赖模型和详细级层次依赖模型。系统级与详细级层次依赖模型都从体系结构角度构建，但系统级在结构中以属性形式表达功能，因为系统级FMEA本身是要从功能出发的。本方法采用一个比较完整的图形化建模方法准确地描述程序结构以及失效影响的传播路径和原因追踪路径，本发明与现有技术相比，具有以下明显的优势和有益效果：

1、本发明给出了一种新的软件FMEA实施方法，可以满足对安全关键软件的系统级FMEA和详细级FMEA，为软件FMEA辅助分析工具设计提供了新的思路。

2、基于层次依赖建模的软件FMEA符合嵌入式软件实际开发过程，能够与分析、设计、开发同步进行，符合了FMEA中“边设计，边分析”的原则。

3、对依赖图扩展，形成基于数据流和控制流的软件系统级层次依赖模型的建模机制，能够直观、准确、充分的反映出软件系统级FMEA所关注的软件中模块构成、层次结构以及各模块之间的控制和数据依赖关系；基于结构化开发程序的控制流程图以及变量使用关系提出详细级层次依赖模型的建模机制，将传统软件详细级FMEA分析中的软件线索可视化。

4、以层次依赖模型为分析依据，把软件失效影响分析和失效原因分析转化为图的节点可达性问题。通过在体系结构中的客观表达，提高分析的准确性，减轻依靠分析人员经验的随意性，通过节点的属性为高效地分析软件的失效原因、失效影响提供有力依据。

5、给出了基于并行程序层次依赖模型进行FMEA的方法，解决了传统软件FMEA方法中没有并行程序客观分析方法的缺陷。

附图说明

图1为本发明中FMEA层次关系图；

图2为本发明中并发程序依赖模型建立过程图；

具体实施方式

为了便于本领域普通技术人员理解和实施本发明，下面通过具体实施方式对本发明作进一步的详细和深入描述。

本发明的基于层次依赖建模的软件FMEA方法，具体实现步骤如下：

第一步，从需求出发，对所分析的对象全面深入了解，确定分析目标，

系统级软件FMEA主要是在软件开发的需求分析和概要设计阶段进行。与传统系统级软件FMEA一样，第一步是要确认所要分析的目标，并进行功能描述。软件在需求分析阶段形成软件需求说明文档，在文档中给出软件功能流程图。功能流程图中给出软/硬件综合系统中每个软件部件或软件单元之间的功能逻辑关系，它表示了软/硬件综合系统自上而下的层次关系。

通过软件需求规格说明文档首先明确：1)软件使用环境和使用条件；2)软件功能、性能要求；3)软件安全性、适用性要求；4)测试性、维护性要求。然后利用现有阶段的需求关键性分析方法，识别目标软件的安全关键需求，根据安全关键需求得到安全关键功能。

第二步，从需求出发，以概要设计为参考，构建系统级层次依赖关系模型

在软件概要设计过程中，软件建模是由多种视图组合描述的，包括系统结构图、功能流程图、控制流图、数据流图等。多种视图的表达不利于对失效模式传播影响的分析，不利于计算机辅助的实现。本文提出一种基于构建层次依赖模型的软件FMEA方法，将多种视图的信息融合在层次依赖模型中，促进FMEA分析团队的交流和协作。

软件系统级层次依赖模型的构建由以下几个步骤组成：

1)对目标软件进行分解和数据精化。

根据软件工程理论，结构化开发的软件系统可以看成由不同层次的子系统组成。在问题分解、逐步求精的分析过程中，把目标软件功能分解为许多子系统或子功能来实现，通过自上而下的分解过程，可以得到系统的层次结构。现有分解方法有两种：(1)按功能分解，将一项功能分解成若干子功能；(2)按结构分解，结构分解出模块，一个模块具有一个或多个子功能。软件结构化分解特征是：在高层，功能与结构是相对应的，但随着分解层次的深入，功能与结构的对应关系出现不一致情况，一个模块可能实现多个功能，一个功能也可能需要多个模块协同作用。

在系统级FMEA构建层次依赖模型时，使用的是系统分解的结构图。通过现有的软件模块关键性分析方法，辨别模块与功能对应关系以及模块的安全关键性，将功能作为模块的属性。在系统级层次依赖模型中，每个节点代表软件模块。系统级软件FMEA仍旧以功能角度表述，通过模块的功能属性来辨别功能的失效模式。此构建法有两个优点：(1)对于故障的定位，要定位在实际结构上而不是定位在功能上。(2)在实际设计中，使用的是层次结构图，可以保持与概要设计的方法和流程一致，充分利用概要设计的结果，减少工作量。

对数据的精化是伴随着对软件的分解同步进行的，通过问题分解、逐步求精，把一个复杂的问题分割为若干个可管理、易实现的小问题，从软件的概念表示中分解出数据结构的细节，包括交换数据类型、数据取值范围、实时性约束，辨别出数据在模块之间的传递关系。

2)基于分解结果，为节点添加属性，将系统层次结构图转化为只包含控制依赖关系的层次依赖模型。

系统级软件FMEA分析是和目标软件的概要设计同步进行的，通过第一步分析出的系统层次结构和数据的传递关系构建系统级层次依赖模型。依赖建模既要符合现有依赖图对依赖定义规范，又要能够具有FMEA层次特点。传统的依赖图，每个节点只代表软件的某部分结构，不具有特殊含义。而对于FMEA来讲，由于故障模式是从功能或输出、结果角度描述的，故每个节点属性也要从功能或输出、结果角度表达。

系统级别层次依赖模型节点的定义

在系统级层次依赖模型中，每个节点代表软件结构分解后的模块，每个节点从功能出发定义相关属性。在层次依赖模型中每个节点采用一个八元组Na＝(M，I，O，P，L，G，Q，C)来储存信息，其中：

(1)M是节点的名称(或编号)，能唯一标识这个节点，且不为空值；

(2)I是节点代表的模块的输入变量集合，非空，集合中的每个变量又分别是一个变量模型，变量模型包括变量编号、变量名称、变量类型、变量作用域属性；

(3)O是节点代表的模块的输出变量集合，其属性与输入变量I相同，即，集合中的每个变量也是一个变量模型，变量模型包括变量编号、变量名称、变量类型、变量作用域属性；

(4)P是处理过程描述，描述节点所代表的模块的功能流程，可以是文字性描述，也可以是流程图形式，主要用于分析人员对功能有更深刻理解，P可以为空；

(5)L是层次依赖模型中上层相关联节点的集合，即控制依赖本节点的上层节点集合，L包括上个横向层次中相依赖节点集合L1和上个纵向层次相依赖节点集合L2；

(6)G是层次依赖模型中节点的功能属性，包括详细描述和功能关键词两个属性，其中功能关键词属性主要由分析人员的通用软件失效模式集确定，功能关键词用于FMEA自动化查找失效模式，详细描述是对功能关键词进行细致的描述，便于分析人员理解；

(7)Q是层次依赖模型中下一个层次相关联节点的集合，Q包括下个横向层次相依赖节点集合Q1和下个纵向层次相依赖节点集合Q2。

(8)C表示本节点所处的层次，包括横向层次及纵向层次，采用层次对<横向层次，纵向层次>表示。

横向层次与分层数据流图的中“层”的定义一样，指的是定义在不同一个图层内，是上层图中某节点的内部结构的具体展开。纵向层次定义为在同一个图层中，节点由上而下构成的层次，与传统FMEA中层次定义一样。纵向层次用于传统的分析中对上层下层的影响，横向层次主要用于定位。采用这种方式主要是便于依赖模型的直观显示和降低可视化建模的难度并且不丢失某些依赖关系。因为依赖关系复杂，在一个图层上无法清晰展示。

系统级别的层次依赖模型中依赖关系定义:

定义1：模块间的控制依赖关系是指模块间的调用关系(或包含关系)，用模块间的控制依赖边表示，从代表调用模块(或总模块)的节点指向代表被调用模块(或子模块)的节点，用实箭头表示。逆着箭头方向是寻找失效的影响，顺着箭头是寻找失效的可能原因。

控制依赖从FMEA的角度出发定义的，其有两层含义：一，对下层产生控制作用，控制作用包括，调用、控制流向变换、包含。即上层汇总节点调用、使用或包含了下层节点内容；二，上层结果依赖于下层结果，约定上层功能结果是下层功能结果的综合，所以下层失效会影响到上层。

定义2：模块间的数据依赖关系是指模块间的数据传递，在本模型中采用数据传递边表示，数据传递边从代表数据定义模块的节点指向代表数据应用模块的节点，用虚箭头表示。采用数据传递边表示是为了符合人们对数据流的作图习惯。顺着箭头是寻找失效的影响，逆着箭头方向是寻找失效的原因。

每个节点间的依赖关系采用一个七元组E＝(I，Q，Z，L，P，C，Y)来储存信息，其中：

(1)I表示的是依赖关系的编号，每个依赖关系都有唯一的编号。

(2)Q表示的是表示依赖关系箭头的起点的名称(或编号)，由于不同依赖关系表示方式不同，起点是指箭头连线的起始点，而非依赖关系的起点。

(3)Z表示的是表示依赖关系箭头的终点的名称(或编号)，也是指箭头连线的终点，而非依赖关系的终点。

(4)L表示的是依赖的类型，不同的依赖关系所使用的箭头不同，箭头的起点与终点的含义不同，如控制依赖的起点依赖终点，数据传递是数据由起点传递到终点，终点依赖于起点，类型包括数据传递、控制依赖、同步依赖、通信依赖、控制流向，在系统级层次依赖模型中使用的是控制依赖与数据传递。

(5)P表示的是依赖的优先级，同一个节点有多条依赖关系时，通过优先级表示此节点被依赖的顺序，默认情况下为0，数值越大，优先级越低。如果在循环依赖的情况下有不同的优先级，影响分析时，优先级越高的首选被遍历，只有在没有更低的依赖关系时循环依赖遍历完成。主要是用于更清楚的表现传播影响路径。在分析失效原因时，优先级低的首选被遍历。

(6)C表示依赖关系代表的操作的描述，包括：调用、包含、控制流向、数据读、数据写。

(7)Y表示依赖关系的约束，控制依赖的约束有递归、条件调用，数据依赖的约束有数值限幅、实时性要求，对约束还可以进行详细描述。

3)基于数据精化的结果，在只包含控制依赖关系的层次依赖模型中，节点间增加相应的数据传递边。

层次依赖模型的核心组成部分是程序间的控制依赖关系和数据依赖关系。在第2)步中得出控制依赖关系基础上，增加对节点间的数据传递关系。通过对目标软件进行分析，在叶子模块间的数据依赖关系表现为以下五种形式：

(1)全局变量和数组的数据传递；

(2)函数调用形参传递；

(3)函数内部静态局部变量的数值传递；

(4)函数返回参数的传递。

(5)其它公共数据交换模式，如文件、数据库

为降低数据传递的冗余性，在系统级层次依赖模型中，数据传递边只在模型的叶子节点之间构建。

层次依赖模型说明

定义六元组<N，E，Ec，Ed，V，f>为层次依赖模型。其中，N是节点集合；E是节点间的依赖边；Ec为节点间控制依赖边，用实的有向边表示，从调用模块指向被调用模块；Ed为模块间数据传递边，用虚的有向边表示，有向边的方向与模块间数据流动的方向一致；E＝Ec∪Ed，V是目标软件系统的数据集合；f为从Ed到V上函数f：Ed→V，表示数据依赖边上流动的数据流信息。

约定：上层模块功能属性是下层功能属性的综合，下层节点的功能属性是上层的功能分解。综合的含义是指下层的所有模块的功能经过叠加或经过逻辑运算形成上级的功能，上层功能不仅包含了下层的功能，还隐含着他们的逻辑。例如，在结构上，调用模块对下层的输入模块和输出模块调用，但是下层的输入模块运行结果可能没有返回给上层的调用模块，而是直接传递给了输出模块。那么此时，输入模块的失效，结构上只影响到输出模块。但是调用模块由于调用了输入和输出，将输入与输出模块都视为上层模块的一部分，那么调用模块在层次依赖模型中的功能里就不仅是调用，而是包括输入和输出功能，使输入模块的失效就影响到调用模块的输出功能。这样，下层出现失效就必然引起上层的某功能失效，能使基于结构的层次依赖模型实现软件FMEA中底层逐渐产生对高层影响，实现了基于结构与基于功能分解进行FMEA的一致性，使软件FMEA与硬件FMEA以及功能FMEA的分析一致。

第三步，选取约定层次，确定约定层次中每个模块的失效模式，由系统级层次依赖模型节点可达性分析，分析失效影响传播路径和失效原因追踪路径,确定失效影响和失效原因，提出改进措施。

由于软件FMEA技术本身特点决定，分析对象的选取、失效模式的确定以及影响的分析离不开分析人员的经验。在本方法中通过规则与准则的制定规范分析行为，降低对分析对象选取的随意性，通过在层次依赖模型中节点间结构上确定传播路径，使影响分析更加客观。

与现有技术一样，首先选定要分析的层次，确定出合理的初始约定层次和最低约定层次。约定层次能够为分析提供明确的范围和目标，并为分析结果的综合及应用提供可靠线索和有力依据，能大大提高FMEA的有效性和效果。初始约定层次与约定层次确定方法与现有方法一样，不同点是本方法结合软件特征制定了确定最低约定层次的原则。

1)确定初始约定层次

初始约定层次指的是软件功能层次的最顶层层次，它是系统级软件FMEA最终影响的对象。软件的初始约定层次常常并不是软件本身，而是与软件结合在一起，完成第一步识别出的某安全关键功能对应的整个系统的模块。对初始约定层次的划分影响分析结果严酷度类别的确定。

2)确定约定层次

约定层次是按软件系统的功能关系或组成特点进行系统级软件FMEA的模块所在的功能层次或结构层次，它规定了系统级软件FMEA所要分析的软件的范围，超出这个范围的其他所涉及到的因素都应该划归为软件的运行环境范畴，确定了约定层次就划定了系统级FMEA分析的边界。

3)确定最低约定层次

最低约定层次是指约定层次中最底层的模块所在的层次。它决定了系统级软件FMEA工作深入、细致的程度以及确定了系统级FMEA与详细级FMEA的界限。最底层约定层次的划分应该至少达到对系统的严重故障有直接影响的层次。对于最低约定层次按以下原则规定：

●所有可获得分析数据的软件单元中最低的层次，它能够有完整的输入，或能够对应到软件中的一个或几个有一定功能的函数；

●当软件中某模块的失效将直接导致灾难的(I类)或致命的(II类)的后果时，则最低约定层次至少划分到这一模块所在层次；

●确定或预期需要单元测试的最低产品层次，这些软件单元可能导致临界的(III类)或轻度的(IV类)故障

软件约定层次定义的深度，影响着软件FMEA的工作量和难度。在定义软件约定层次时应根据实际需要，重点考虑关键的、重要功能的软件部件或模块。在哪一层次上选择模块进行FMEA分析取决于项目的时间、进度、人员、预算等许多因素。在系统级一定要以功能角度去分析，系统级的分析对象必须有一定的功能。在系统级别上，代表模块的节点有输入变量与输出变量属性，具体到变量怎样影响其他模块，在详细级FMEA中分析。

获取通用软件失效模式集与确定待分析节点具体失效模式的步骤如下：

1)定义故障判据，判断功能故障需要定义故障判据，故障判据是判别软件故障的界限。它是根据产品的功能、性能指标、使用环境等允许极限进行确定的。本方法故障判据如下：

(1)软件在规定的条件下和规定时间内，不能完成规定的功能；

(2)软件在规定的条件下和规定时间内，某些性能指标不能保持在规定的范围内；

(3)软件在规定的条件下和规定时间内，通过硬件引起对能源和物资等的消耗或人员、环境等的影响超出了允许范围；

(4)技术协议或其他文件规定的故障判据。

2)对通过故障判据判定的故障进行分析和抽象，总结人们在长期的软件开发实践中常见的、经典的软件失效案例，分析其发生的原因和失效形式，形成通用的失效模式集S。本方法通过层次分类法总结了系统级《通用软件失效模式分类表》，根据软件的“输入-处理-输出”的工作特性，采取了“输入-输出-处理-性能”分类方式对软件中常见失效模式进行总结归类，是对GJB1391的进一步细化。例如输入失效，分为文件输入类、外部通信类等类别，每一类别又分为输入失效和输入时失效，对每一类别的输入失效与输入时失效再划分为具体失效模式。采用这种“输入-输出-处理-性能”的层次分类方式既能融合各种常见失效模式又能便于查找，其中在《通用软件失效模式分类表》中的示例如下：

表1.通用软件失效模式分类表示例

3)基于通用的失效模式集S和已经建立的软件系统依赖关系模型中节点的功能属性，分析当前关注的节点所代表的的模块所有可能发生的具体失效模式集T。失效模式集T主要由三部分组成：直接来自于S的失效模式；S中的某些失效模式的进一步细化或变种；从当前目标软件系统中提取出来的特有失效模式。

具体失效模式确定方法有：

(1)启发式，直接来自于通用失效模式集的失效模式或某些失效模式的进一步细化或变种；对采用现有的软件，可从该软件在过去的使用中所发生的故障模式为基础，再根据该软件使用环境条件的异同进行分析修正，进而得到该软件的故障模式。

(2)借鉴式，从相似功能和相似结构软件中发生的失效模式作基础，分析判断其失效模式。

(3)脑力式，通过调查分析软件失效发生机理，通过团队“脑力激荡法”根据常见软件缺陷来预测可能的失效。

(4)变异式，从软件使用环境，功能、体系结构和维护要求以及可靠性、安全性要求等方面入手理解目标软件系统提取特有失效模式。

(5)索取式，对引进国外货架软件或构件，应向外商索取其故障模式

4)将特有失效模式总结抽象，归结到通用失效模式集S中，为以后分析提供借鉴。

基于系统层次依赖关系模型进行失效原因分析：

获取失效模式后首先进行失效原因分析，对于找不出失效原因的失效模式，证明失效不会发生，需要将其删除，避免失效影响做出无用功。软件失效原因的分析从两方面分析：一是软件自身缺陷原因，包括模块本身设计不合理和下层模块的失效模式两方面；二是使用不当或硬件问题造成的接口因素，失效原因分析中的接口影响因素考虑软件分析对象与内部其它系统和外部周边系统间的相互作用。

对于软件自身失效原因，在层次依赖模型中，按照其控制依赖箭头的正方向，数据传递箭头的反方向，采用深度优先遍历算法，来查找目标软件中导致某一模块失效的所有可能模块。FMEA是一个由下而上的分析迭代过程，由于FMEA结果本身也有一定的层次性。约定层次间存在着一定的关系，即低层次产品的故障模式是紧邻上一层次的故障原因这样对的高层影响的自动生成高层节点的故障模式，同时高层的相应的故障原因也通过低层节点的故障模式自动生成。对于分析到最低层失效原因时或分析模块自身设计不当时，需要结合《软件失效原因分类表》(可参见GJB1391)与软件FMEA分析人员对目标软件的深刻理解，将失效原因归结到软件设计缺陷，或者通过详细级确定失效更本质的原因。

利用系统级层次依赖模型进行软件失效影响分析：

影响分析是根据软件失效发生的所在层次，评估软件失效对同一层次其他模块的影响和对上一层次的影响以及对整个软件系统的影响。软件失效影响分析从以下几个方面考虑：对于软件自身的影响：对同级模块、高层次模块、整个软件运行的影响的描述；对于任务的影响：对任务的成败、任务的完成程度的影响描述；对环境的影响：对硬件执行的影响；对人员安全性的影响描述或者其它影响的描述。后两方面的影响主要从对软件的影响再分析得出。

一个软件模块失效，其影响只可能波及到与该模块有控制依赖和数据依赖关系的模块，因此软件失效影响分析问题可以被转化为在系统级层次依赖模型中寻找某个图形节点的遍历问题，例如，在系统层次依赖模型G中，假定模块A发生失效，A对应的节点为NA，那么对模块A的失效影响分析问题就可以转化为G中寻找由NA的所有影响可达节点组成的子图GA的问题。采用深度优先遍历方法按照其控制依赖箭头的反方向，数据传递箭头的正方向，来查找目标软件中该模块的失效所影响到的所有可能模块。这样，将影响分析首先定位到影响到的节点。因为FMEA结果本身也有一定的层次性，如附图1所示，低层次的失效模式是中间层次的失效原因，而中间层次的失效模式又是更高层次的失效原因；低层次的上级影响就是中间层次的故障模式，中间层次的上级影响又是更高层次的故障模式；最高层次的最终影响，对应到中间层次和低层次的最终影响；低层次的改进措施就是对应中间层次和高层次模块的改进措施。根据影响到的节点的属性，辨别影响到的节点的某一具体失效模式就是影响结果。

每个节点，都有属性加以信息约束，进行寻找可达节点遍历时由功能关键字搜索通用软件失效模式集，将与之相关的所有失效模式查找出来。基于功能关键字对失效模式进行匹配，是基于语法匹配的，所以功能关键字完全来自于通用软件失效模式集S。当同一部件具有许多功能时，必须考虑每种功能的可能失效模式。如果本层有相同功能模块，证明此功能有冗余。这个功能点的故障模式则不会传递到上层。在遍历过程中需对相关联的节点之间进行功能关键字匹配，判断是否有冗余。基于系统级层次依赖模型进行失效影响分析是方便和并且是客观的，能够遍历出一条条传播路径，客观的可视化显示以及节点属性的描述为FMEA分析提供方便的辅助作用。

在系统级FMEA中对影响严酷度的判别方法如下：

首先由研制方从功能角度制定高层功能失效的严酷度，其中，研制方将功能失效严酷度层次定义级别越低，使分析人员对下层的FMEA严酷度确定越准确，但是研制方本身制定严酷度的随意性却增大。本方法中权衡两者的准则是：研制方制定功能失效严酷度层次应在分解系统时，功能与结构开始出现不完全对应的一层；研制方可以在更底层制定，但是不得高于这一层，因为在这层中，功能相对独立，而更上层功能范围太大，使分析人员不易把握影响，更下层出现功能耦合，研制方严酷度不易确定。

分析人员利用层次依赖模型，将影响定位到结构中的模块，高层的模块与功能对应，辨别影响到的高层功能，通过对高层功能的影响程度以及高层功能失效的严酷度确定底层失效的具体严酷度。如果底层失效引起高层功能完全失效，那么严酷度等级应与高层一致，如果部分影响高层功能，即高层功能并未完全失效，那么严酷度等级应该比高层功能失效低。

改进措施的提出方法

对于软件来讲，改进措施的提出方法主要结合现有的软件可靠性设计方法，在系统级有以下方法：

1)重新设计方法,利用软件工程化思想，采用合适的软件开发过程、开发方法及工具，贯彻软件避错设计原理，重点考虑抽象与逐步求精、模块独立与信息隐藏、健壮性设计、形式化方法等。这种重新设计的措施常常耗费人力物力，所以经常采用冗余设计。

2)冗余设计，针对系统级的故障模式，常见的改进措施有结构容错和时间容错。结构容错包括N-版本程序设计NVP(N-Version Programming)和恢复块RB(Recovery Block)两种基本技术以及一致性恢复块、接受表决、N自检程序设计等先进技术。时间容错针对系统级故障模式主要是建立软件系统运行日志和数据副本，设计较完备的数据备份和系统重构机制，以便在出现修改或删除等严重误操作、硬盘损坏、人为或病毒破坏及遭遇灾害时能恢复或重构系统。

3)通过详细级改进，对出现的失效模式进行详细级软件FMEA，由于详细级中通过变量线索一步步向上影响到系统级的功能，在详细级针对变量的故障模式提出的改进措施也是对系统级功能设计的改进。由于在系统级的N版本、恢复快方法等耗费大量资源，所以在详细级中提出的改进措施会更加有效，这也是软件详细级FMEA的一个作用。

第四步，根据系统级软件FMEA结果，选取详细级FMEA分析对象

详细级FMEA目的主要是分析模块的外部功能失效，是由内部如何引发的，更详细说明系统级失效模式的深层次原因；查找软件中的部分野错误。另外，还验证系统级软件FMEA对各类软件元素潜在失效提出的改进措施在详细设计中是否有效的规避；验证详细设计是否满足安全性的要求；为软件测试中测试用例的选择提供依据。

软件系统很难分解到标准的单元，进行详细级软件FMEA来确定失效的根源和具体位置之前，往往通过系统级FMEA把失效的位置确定在了某一个模块内或者只分析人员对某个模块内的失效感兴趣，这时如果再对整个软件进行详细级FMEA则非常不必要，因此详细级软件FMEA首选要选取安全关键模块作为要进行详细级FMEA分析的对象。为了降低分析人员选取分析模块的随意性，本方法针制定如下选取规则：

1)功能重要性选取法，系统的核心模块，实现其主要功能。

2)体系重要性选取法，与其它模块有较多的交互，通过耦合度计算度量。

3)逻辑复杂性选取法，通过算法空间复杂度和时间复杂度度量。

4)专家打分法，FMEA本身离不开分析人员的经验，有经验分析人员直觉出问题的模块也是分析的重点；

5)系统级软件FMEA选取法，系统级软件FMEA中查找到的会引起关键用例或功能发生失效的模块，其严酷度或危害度在Ⅱ类(致命的，参见GJB1391)以上。

第五步，以选取的分析对象的详细设计或伪代码为依据，构建详细级层次依赖模型。

根据FMEA“及早性”原则，需要在编写代码前期进行FMEA，根据概要设计与详细设计文档构建适合详细级软件FMEA的层次依赖模型。详细级别依赖模型把控制依赖和数据依赖以及函数调用关系包含在单个的结构中，控制依赖揭示了语句间存在的控制流的内在联系，而数据依赖则揭示了语句间存在的数据流方面的内在联系，而FMEA中失效模式的影响传播的实质是由这种依赖关系引起的。

详细级层次依赖模型中依赖关系包括：控制依赖、数据依赖、同步依赖和通信依赖。同步依赖和通信依赖是对并发程序，多线程而言的。因为要进行FMEA的软件通常都是安全关键软件，多线程、实时性是重要特性。传统FMEA方法并没有对多线程造成的影响进行分析。通过本依赖建模方法，还能够对并发程序进行有效的FMEA分析。

层次依赖模型建模步骤如下：

1)辨别分析对象的控制流

控制流图是程序依赖图中数据依赖和控制依赖信息的载体，控制流节点中包含对应的存储数据依赖和控制依赖信息的域。一般以控制流图作为输入。在程序控制流图的基础上，组合数据依赖和控制依赖，把单个函数表示为函数内部层次依赖模型，然后通过添加调用依赖边和与之相随的参数依赖边，组成整个软件的层次依赖模型。

2)识别节点，控制依赖关系与数据依赖关系

详细级层次依赖模型中节点定义

在详细级依赖模型中包含几种类型的结点：单节点，表示软件中的单语句或某变量；域结点，概括了域中语句间的控制依赖。依赖模型的域结点可以利用相同的控制依赖来集合语句。

域节点可分为以下五大类型：1)模块节点，表示系统级结构分解的模块；2)函数节点，用于表述函数整体功能以及相关参数之间传递；3)复合语句节点，表述了一个复合语句整体的实现，实现一定算法功能的语句块也可视为复合语句节点；4)谓词控制节点，表示程序中的策略或分支条件，包括条件语句(包括switch语句)和循环语句的判断部分等，用该语句谓词的标记表示；5)结构化跳转语句节点，包括break、continue、return等语句。

在详细级层次依赖模型中每个域结点同系统级节点一样，不仅仅是一组依赖关系的起始节点，更从FMEA故障模式角度出发，表示的是其下子节点运行的结果综合。每个域节点从功能出发，也约定上层节点功能属性是下层功能属性的综合，如同系统级FMEA中模块节点的定义，采用八元组Na＝(M，I，O，P，L，G，Q，C)储存信息。其中:

(1)M是节点的名称,能唯一标识这个节点,且不为空值；

(2)I是节点代表的模块的输入变量集合，集合中的每个变量又分别是一个变量模型，变量模型包括变量ID、变量名称、变量类型、变量作用域。

(3)O是节点代表的模块的的输出变量集合，其属性与输入变量I相同，即，集合中的每个变量也是一个变量模型，变量模型包括变量ID、变量名称、变量类型、变量作用域；

(4)P是处理过程描述，描述节点所代表的模块的功能流程，可以是文字性描述，也可以是流程图形式，主要用于分析人员对功能有更深刻理解，P可以为空；

(5)L是层次依赖模型中上层相关联节点的集合，即控制依赖本节点的上层节点集合，L包括上个横向层次中相依赖节点集合L1和上个纵向层次相依赖节点集合L2；

(6)G是层次依赖模型中节点的功能属性，包括详细描述和功能关键词两个属性，其中功能关键词属性主要由分析人员的通用软件失效模式集确定，功能关键词用于FMEA自动化查找失效模式，详细描述是对功能关键词进行细致的描述，便于分析人员理解；

(7)Q是层次依赖模型中下一个层次相关联节点的集合，Q包括下个横向层次相依赖节点集合Q1和下个纵向层次相依赖节点集合Q2。

(8)C表示本节点所处的层次，包括横向层次及纵向层次。，采用层次对<横向层次，纵向层次>表示

在详细级层次依赖模型中，break、continue、return等构化跳转语句节点在模型中采用域节点表示形式，不同之处在于属性I、O、P始终为空。其功能属性G表示的是自身功能以及跳转到的语句块的结果综合。

变量节点，包括变量ID、变量名称、数据类型、存储类型、作用域、所处的域，别名属性，采用一个七元组表示Nb＝(ID，Name，L，CL，Y，SY，BN)。其中，

(1)ID作为一个变量节点的唯一标识。

(2)Name表示变量的名称，同一个名称的变量可能因为作用域表示不同内容。

(3)L表示数据类型，数据类型有整型、实型、字符型、数组类型、指针类型、结构体类型、及公用体类型。数据类型决定了变量值的数据类型、表现形式和分配空间的大小以及对变量能执行的操作。

嵌入式软件，输入输出行为不仅与取值有关而且与时间相关，每个变量数据类型还应标识是否与时间相关以及时间约束特性。

(4)CL表示变量的存储类型，在C/C++语言中，变量的存储类型有4种：自动类(auto)、静态类(static)、寄存器类(register)来和外部类(extern)。见表2.

表2变量存储类型表

存储类型	关键字	生命周期	定义位置	作用域
					动态变量	无	临时	函数内	局部
静态变量	static	永久	函数内	局部
					寄存器变量	register	临时	函数内	局部
外部变量	extern	永久	函数外	全局(所有文件)
					静态外部变量	static	永久	函数外	全局(一个文件)

(5)Y表示变量的作用域，包括局部变量和全局变量，参数变量视为局部变量。

(6)SY表示变量属于某个域节点内，表示变量与某个域节点的从属关系。

(7)BN表示数组变量、指针变量或全局变量、静态变量的别名属性，主要是因为出现在不同的语句中，改变一处其他都会改变。别名属性表示方法为<p,<t,i>,d,r>,并定义如下约束规则:

(a)p、t是互为别名的变量编号。它们没有先后顺序之分，但如果其中一个是数组元

素，则要把它放在t的位置。

(b)i是数组元素t的下标，如果t是普通的指针变量，则i＝-1；如果t为多维数组元

素，则可以用将i扩展为多元组的方法，精确表示其下标信息。

(c)d是p的解引用级别，p＝-1表示取地址；p＝1表示指向。

(d)r表示别名关系，r＝D表示必然别名，r＝P表示可能别名。

(e)<*p,<*t,i>,d,r>与<p,<t,i>,d,r>等价，因此在集合中均表示为<p,<t,i>,d,r>。

(f)p≠t，即不表示自反性导出的别名对。

别名可以准确地表示数组和指针的别名信息。当程序里面存在指针数据类型或者存在通过传送地址方式进行的过程调用时，两个或两个以上的表达式就可能代表同一内存地址，对一个变量的修改必然影响到另一个变量。别名问题主要指示了同名变量之间、参数传递之间或指针引用之间的依赖关系，是对依赖关系的一种约束属性，提高FMEA分析的精确度。

详细级层次依赖模型中依赖定义：

定义1(控制依赖)

令G是一个控制流图，u和w是G中的节点。结点u是控制依赖w的，当且仅当：

①在一条从u到w的有向路径P，v(不包括结点U和w)是p中任意一个结点，w是v的后必经结点；

②w不是u的后必经结点。

③控制依赖箭头指向由u指向w。

其简单理解为：如果结点u是控制依赖w，那么u必须有两个出口。沿着其中的一个出口，总是导致执行w，而另外一个出口则导致w不被执行。

定义2(数据依赖)

设u与v为给定程序中两条不同的语句，如果有一条从u到v的执行路径,同时存在一个在u处定义、v处引用的变量，且该变量在从u到v的执行路径上的其他位置没有被重新定义，则称v数据依赖于u。数据依赖在层次依赖模型中用数据传递表示，由u指向v。

定义3同步依赖:设u与v为给定程序不同线程中的两条语句,如果u执行的开始或终止通过线程间同步直接决定v执行的开始或终止,则称v同步依赖于u。

定义4通信依赖:设u与v为给定程序不同线程中的两条语句,如果u计算的变量的值通过线程间通信直接影响在v计算的变量的值,则称v通信依赖于u。

为了更加直观，采用图形化方法来表示各种依赖关系，将依赖关系赋予属性扩展，在详细级层次依赖模型中依赖属性与系统级依赖关系属性定义完全一样，采用一个六元组E＝(I，Q，Z，L，P，C，Y)表示。

3)节点与依赖关系的精简

函数调用中存在参数传递、多次调用、局部变量和全局变量，所产生的控制依赖和数据依赖非常复杂。复杂的图形化显示不利于观察，不利于FMEA分析的进行。因此，在建模阶段,需要对模型中节点进行精简，以利于辨别失效模式的影响路径和原因的追踪。节点的精简与建模过程是同步进行的。

建模的化简原理：

性质1：在顺序程序中，函数间的数据和控制依赖关系具有传递性，设P＝path(s1,s2,,,sk)是层次依赖模型中的一条路径，如果P中每一个节点s_i+1控制依赖或数据依赖于s_i(1≤i≤k-1)，则称节点s_k传递依赖于节点s₁，记做TD(s_k,s₁)。

性质2：如果有向图中节点x与y是可达的，则以有向图中某节点(不包括节点x)为基础对图进行传递转换后，节点x与y还是可达的。对图进行传递转换不会影响图中其他非被依赖节点对被依赖节点的依赖性。有向图的传递转换是指以有向图中任何一个节点x为基础，对有向图进行转换，使其边集为E＝(E-{(x,n)|n∈succ(x)})∪{(m,n)|m∈succ^-1(x),n∈succ(x)}。其中，succ(x)表示x的直接后继节点集合，succ^-1(x)表示G的反图中的直接后继节点集合，即G中x的直接前驱节点。m∈succ(x)说明m依赖于x,n∈succ^-1(x)说明x依赖于n。

利用这两条性质对层次依赖模型进行简化：

(1)如果x是条件谓词节点，它只引用了变量，引发的信息流是语句间的信息流，它的执行不会修改任何变量，在信息的传递过程中只充当中介，以它为基础对依赖图进行传递转换，同时删除这个节点以及它依赖于其他节点的依赖边。

(2)详细级FMEA中关注的是待分析变量之间的依赖关系，所以依赖模型中的中间媒介变量就可以省略。

(3)进行分析时，最终是分析输入、输出与全局变量，对全局变量和局部变量的不需要区别处理，只要把没有对外可见性的局部变量节点从依赖模型图中删除即可。

(4)扩大每个方法入口结点的含义(隐含参数结点及参数之间的数据传递)，两个方法的参数结点之间的数据依赖关系用方法之间的数据依赖来表示；每个过程依赖图只需用过程入口结点表示即可，而不必再展开表示；

依赖图模型建模原则及特性：

(1)体现出层次性，因为层次性是FMEA的基础；

(2)能够将各种控制结构融入的图中，以表达出各种失效模式及影响路径；

(3)忽略过程处理性，删除不关注的局部中间处理变量，强调结构依赖性。

4)关于变量的依赖关系构建

函数内的依赖构建时主要关注的是局部作用域和语句作用域的变量。对于C++程序来说，定义性变量则包括赋值语句的左值及for语句的循环控制变量，引用性变量包括赋值语句的右值、if(switch、while、for)等条件判断语句中条件表达式中变量。

对于赋值语句节点或函数调用节点则记录改节点所使用的局部变量集合，如果从变量定义节点到使用变量的节点之间没有该变量的重新定义并且使用变量的节点包含变量定义节点定义的变量，则称该变量使用节点数据依赖于该变量定义结点。添加数据流边由变量定义节点指向使用变量的节点。

变量节点中存在别名属性。在C/C++程序中主要是引用和指针导致别名。对于有些静态变量、全局变量、静态参数变量，由于出现位置不同，其值也不同，也通过别名表示，将其依赖影响的顺序表示出来。同变量名的节点，可以不用画出，按别名属性以暗线形式搜索出路径。对于变量传递到另一个域节点中，利用变量节点的属于(SY)属性将变量与相关域节点进行相关联，利用域节点之间的依赖关系，辨别同名变量的依赖关系。

5)关于谓词控制节点的控制依赖构建

软件中有三种主要的控制结构，分别为顺序结构，判断结构与循环结构。对各种控制节点的构建方法如下：

(1)顺序结构

控制依赖主要是由于控制结构改变程序流向所引起的，顺序结构如变量声明语句、赋值语句，无谓词出现，执行结果不会影响程序的执行流程，不存在控制依赖。在分析控制依赖的过程中，可以将顺序结构的语句简单看成一个程序节点而不予考虑。

(2)控制语句

if语句中的复合语句依赖于if语句判断部分(称为if域节点)；if-else语句中，if下的复合语句依赖于if域节点，else下的复合语句依赖于else，else语句控制依赖于if语句。For语句或while语句下的复合语句依赖于for或while语句判断部分(称为for域节点或while域节点)。switch-case语句每个case复合语句控制依赖于switch判断部分(称为switch域节点)。

(3)跳转语句

break语句是结构化转移语句。break语句将控制流转到直接嵌套break语句的循环语句后的第一条语句，使程序跳出循环，即循环语句后第一条语句控制依赖于break语句。

continue语句是结构化转移语句。continue语句将控制流转到直接嵌套continue语句的循环语句的入口处，直接进行下一次循环，即循环条件语句控制依赖于continue语句。

goto语句是非结构化的转移语句，goto语句将控制流引向相应的标号语句，即相应的标号语句控制依赖于goto语句。如下面的程序段：if cond then goto L；L:语句块。语句块并没有包含在if语句中，但从语义看，标号语句块控制依赖于goto语句。goto语句控制依赖于if中的条件。

(4)函数调用语句

函数调用语句将控制流转向调用子函数的入口语句，即子函数的入口语句控制依赖于函数调用语句，函数调用语句的下一条语句控制依赖于子函数出口语句，但是从函数又入口到出口的依赖传递性，为了表示方便，对函数调用语句的下条语句块传递转换，使其直接依赖于函数调用语句。

6)关于函数的依赖关系构建

有函数调用时，首先分析的是调用函数的层次依赖关系，得到调用函数的层次依赖，然后再把得到的依赖图以横向层次的方式并入主调函数的依赖图。

(1)辨别函数调用关系

在每个调用位置节点和相应的过程入口节点之间加入调用边。调用依赖边从调用点指向被调用函数。如果这个函数被上层调用，但是上层他可能处于某种结构，如循环、选择，这就涉及到变量，故要结合上层的控制流程。

对于同一行中含有多个函数调用，可以在此基础上利用函数调用出现的顺序，来确定实际的调用。当发生多层函数嵌套调用时，依赖模型的生成方法先分析最外一层的调用函数的依赖模型，被调用函数作为域节点出现在调用函数的依赖模型中,然后再一层一层得到里层调用函数的依赖图,最后得出整个程序的依赖模型。

根据函数调用被触发的条件可将函数之间依赖关系分为条件依赖和必然依赖。在函数A的CFG的所有路径中，如果存在至少一条路径不包含B的调用点，即如果函数A以某路径执行不会调用函数B，称A对B的依赖是条件依赖，该调用被称为条件调用。无论函数A以哪条路径执行都将调用函数B，称A对B的依赖是必然依赖，该调用被称为必然调用。由于这两种关系在FMEA中都有可能引起上层失效。并且上层的失效原因也都可能是由于这两种情况引起。条件依赖问题不会影响FMEA的分析结果，但是在依赖约束属性Y中要加以限定，用于间接递归程序的分析。

(2)调用关系中构建参数依赖或输入、输出依赖。

以子函数为单位，它们对外提供的接口是参数间的依赖关系，而内部数据、语句之间的依赖关系对外不可见，对调用程序不会产生影响，利用带参数的方法入口结点来表示是通过哪个参数发生的依赖关系。

变量对函数的依赖有四种形式，一种是传值，另一种是传址或传引用，作为处理某些变量的过程。两者主要不同的是对依赖的变量数目不同。第三种是通过全局变量或静态变量来联系的。第四种，被调函数返回值赋值给变量。

(3)将形参视为内部局部变量，构建被调用函数内部依赖关系。参数和函数调用点之间规定为形参控制依赖于函数定义入口。

(4)对于控制节点和复合语句等，可以视为多入口和多出口的函数，可以将其判断条件当做一个节点，在对其内部打开。出口是通过同名变量。

7)内联与递归函数构建方法

数在程序中存在形式有：多态、内联、递归。函数多态性表示函数不止有一种类型，是一种动态运行的结果，在我们FMEA依赖建模中属于一种静态形式，分析到多态函数时可当做一般函数处理，只是将调用的函数名称展开成几个横向层次，每个横向层次描述每一个多态函数的内部层次模型。分析失效影响和原因时等同的每个多态函数遍历。

用函数内联的方法处理将调节点用被调用的函数体替换，在层次依赖模型中，可以视为传引用方式的函数。

函数递归调用在高级程序设计语言里广泛存在，它可以分为两种：

(1)直接递归调用：如果程序P中存在某函数A，且A中存在对自己的调用。

(2)间接递归调用：如果程序P中存在函数A、B，且函数A调用了函数B，B调用了C，C调用了其它函数，如此调用下去，在后续调用的函数里，如果再次出现A，则称程序P中存在A的间接递归调用。

处理递归函数时即是采用这种思想：利用递归函数的执行记录，根据这些记录将递归函数的多次调用抽象为一个与递归函数效果相同的函数。

一个可终止的程序在进入递归调用后，必定会在某条件满足后退出递归，否则程序会永不停息的递归下去。因此可以判定构成递归的所有函数调用中，至少有一个位于条件分支中，如位于if-then-else的某个分支中。设call A是对子程A的过程调用语句则在A中一定存在节点S1与S2使得call A直接控制依赖于语句S1，S2是S1最近的向后必经节点.

确定函数之间调用关系以及标记是否条件调用之后，模拟递归子程序的执行过程，分两步分析A的依赖关系:

第一步去掉S1到S2且通过call A的路径上的所有语句，然后搭建A的依赖模型图，并求出参数之间的依赖关系。这相当于模拟了递归过程中最后一次对A的调用由于语句S1中的条件不能满足而跳过了call A的执行。

第二步恢复第一步去掉的语句，建立callA输入与输出的数据传递，增加call A指向A的控制依赖，并标记依赖约束为递归。根据递归中的返回过程，增加call A前面节点到S2后节点的数据传递。

间接递归

在间接递归中,在所有的调用语句中至少有一条必须是条件调用。鉴于此，在调用图中对这两种边必须加以区分。在控制依赖中增加条件调用属性，正确的递归子程序最终一定会终止的，也就是在它们的调用回路中一定会有一条或几条边因不符合调用条件而断开，从而解除递归。间接递归的建模过程和处理算法为：

第一步，求出这些子函数分析的顺序。

(1)在调用回路中，逐条断开条件调用边(注：可能存在互斥的情况，即几条条件调用边不能同时被断开)，直到某一节点的出度为0。如果去掉所有能去掉的条件调用边，没有找到出度为0的节点，则此递归调用一定不能终止，出现死循环；

(2)如果节点A的出度为0，则去除节点A和所有指向A的边，包括条件调用边，然后找下一个出度0的节点，直到列出所有节点为止，如果在此过程中，又出现了回路，转(1)。设A0,A1,…,AZ是求得的分析序列。

第二步，计算所有子程序的参数依赖集.

(1)按第一步求得的分析顺序算出各个子程序程序依赖图PDG和形参依赖集.在计算A_i时,如果A_i→A_j(c)是在第一步的(1)中被断开的条件调用边,则在这次计算中将不考虑A_i对A_j的调用，具体处理与直接递归第一步相似，如果是被断开的不是条件调用边，直接按关于函数的依赖构建方法。

(2)逐次加上在第一步(1)中被断开的条件调用边，增加Ai与Aj之间输入与输出的数据传递，具体处理与直接递归第二步相似

对于递归还有一点要注意：函数参数输入方式有两种，从函数外部输入(外部接口输入，程序内部输入)和函数内部递归调用输入。无论哪种输入实际上都对函数参数产生数据依赖.对于除了从外部输入都需要在程序依赖图中标出。

8)并发程序依赖性

传统的FMEA方法不能够对并行程序进行有效分析，而程序的并发性更容易导致故障模式的影响，而并发性导致影响分析更加复杂，对于并发程序FMEA是采用下述方法进行依赖建模：从全局分析并发程序的依赖关系,构建以程序状态和语句二元组为节点的并发程序依赖模型，使其依赖关系具有可传递性,扩展依赖模型之后，依旧采用图的可达性算法来辅助FMEA。

由于各个线程之间的交互，使得语句间不仅存在一般的由变量的定义和使用引起的数据依赖、控制谓词和判断语句引起的控制依赖，还包括由线程间同步操作引起的同步依赖和各线程因访问、操作共享变量引起的通信依赖关系。如果被分析程序存在并发性，并发层次依赖模型按以下过程构建：

(1)描述程序P的并发程序流图。它由组成P的各个任务的程序流图组成同时添加和删除一些表示并发和同步的节点和边以准确描述并发和同步的语义。用cobegin和coend分别表示线程的创建和终止，将cobegin、coend以及共享变量读写语句统称为交互语句，如附图2(a)所示，表示了一个简单的并发程序，并对带分析的语句进行编号，如S1、S2、S3、S4。

(2)根据交互语句将线程分块，称为线程域。线程域用三元组<B,I,O>表示，B为线程t程序片段中出现的语句集，I为线程域入口处的语句集，O为出口处的语句集。每个线程域用一个节点表示，节点间的边表示交互活动，由此生成线程交互图将每个线程域用一个节点表示，节点间的边表示相应的交互活动，由此生成的图称做线程域交互示意图。如附图2(b)，表示了对附图2(a)的示例程序变换后的线程交互示意图，分为了三个线程，每个线程起始和结束用Start和Exit标记，Start t0、Start t1、Start t2分别表示三个线程的开始，Exit t0、Exit t1、Exit t2分别表示线程的结束，并用1,、2、3…,对每个线程域编号。并在主线程跳转到其他线程或其他线程跳转入主线程处建立线程编号映射，如t0→(t1，t2)，表示线程t0从此处运行线程t1或t2，t0←(t1，t2)表示线程t1或t2转入主线程t0。。

定义(线程域交互示意图)：对于给定线程t，其线程交互图可以用一个五元组<N,E,n_entry,N_exit,L>表示。其中，N表示线程域集；边集E＝{(ni,nj)|ni,nj∈N且在从ni执行到nj之间要与其他线程进行一次交互活动}；标签函数L对E中每条边映射一个标签以指明交互活动类型，如线程激活与等待；n_entry∈N为初态节点，表示线程入口；为终态节点集，表示线程出口的线程域集。

(3)给定p个线程{t0,t1,程程tp1}的线程域交互示意图(<Ni,Ei,nsⁱ,Fi,Li>,0≤i<p,主程序作为t0处理)，根据交互活动的标签,可对由这组线程所构成的并发程序进行可达性分析，生成线程交互可达图。

程交互可达图的节点，也称可达标志，表示并发程序在执行一系列交互活动后所到达的程序状态，用p元组表示，第i个分量为第i个线程即将执行的线程域。可达性分析从初始可达标志ms开始，ms＝(n_s ⁰,⊥,(⊥),其中⊥表示任务未激活或已终止，根据可能发生的交互活动，一次发生一个交互，生成所有可能的后继可达标志，后继可达标志与前驱可达标志除发生交互的线程的分量发生变化外，其余分量不变。

定义(线程交互可达图)：给定一并发程序CP(concurrent program),其线程交互可达图用五元组<M,E_R,ms,M_f,L_R>表示。其中,节点集M为可达标志集；边集E_R＝{(m,m＇)|m,m＇∈M且在从m执行到m＇之间要发生一次线程交互活动}；标签函数L_R对E_R中每条边映射一个标签；ms为初始可达标志；表示终态可达标志集

在构造线程域交互示意图和线程交互可达图时,对并发程序的某次执行来说,可能有多个完全等价的可执行序列表示,实际依赖分析只需选择其中一个即可。

附图2(c)所示的并发程序依赖模型建立过程图中,从初始状态m0＝(1,⊥,⊥)开始，主线程t0激活子线程t1和t2进入状态m1＝(2,5,7)。在m1处，由于语句S2和S3都有可能发生，则m1有两个后继。当S1发生时，生成状态m2＝(2,6,7)。同理当S3发生时，生成状态m3＝(2,5,8)。主线程t0在状态m4等待子线程t1和t2的终止,生成状态m5＝(3,⊥,⊥)，继而生成状态m6＝(4,⊥,⊥)。

(4)对任意可达标志m，在m的各线程域分量中出现的语句都有可能在m下执行，m只能与这些语句进行组合(否则组合无意义)。同一语句与不同的程序状态组合生成不同的M-S对，表示该语句在不同交互上下文下的执行实例。在依赖模型中表现形式是对节点S进行属性扩充，增加一个程序状态属性(M)。附图2(a)至(d)中描述了并发依赖模型的建立过程，附图2(d)是一个简单程序的并发层次依赖模型。实箭头表示控制依赖关系，虚箭头表示数据依赖关系，start、exit、cobegin、coend采用前文讲到的域节点表示，每个表示包含分析变量的语句S1、S2、S3、S4分别用前文讲到的变量节点表示。每个节点与状态组合形成新的节点，如<m1,S2>表示S节点增加状态后的节点，其他节点的含义也是一样。状态是作为节点的一个属性，图中为了便于显示用的如<m1,S2>的表示。

这种并发的层次依赖模型在FMEA分析时，根据依赖关系追踪到相应的节点，同一个语句根据所处的不同状态可能产生不同的失效影响路径。通过与状态相结合，更能准确的分析出失效发生的位置和发生的时机，表达出失效在并发程序中的传播路径，准确的辅助软件FMEA进行。

第六步，根据详细级层次依赖模型，选取要分析的关键变量

一个模块内部有函数、算法、变量，模块在系统级的失效模式，可能是内部某个变量出错、某个函数运算错误等。实际上函数、算法都可看作是变量的依赖关系，所以在详细级规则中明确分析对象是输入变量。算法的失效模式可通过变量失效得到体现，而输出变量的失效模式可在下一调用模块的输入变量失效中得以体现。详细级分析时，变量极其多，如何有效确定要分析的变量是FMEA的关键。穷尽分析所有变量是没有必要的也是不现实的，而且还是分析重点不够突出。采用如下规则选取待分析的变量。

1)变量类型选取法

在软件开发过程中，根据不同需要定义不同类型变量，所以不同类型的变量有着不同的作用以及重要性，FMEA中重点关注一下类型变量：

(1)有多个函数进行调用的全局变量，全局变量发生失效，那么系统将会受到连锁影响，需要对这部分全局变量进行深入分析。

(2)外部的参数变量，人工设置的参数合适与否直接影响着系统的运行。

(3)算法输出变量，对于软件，算法是重要组成部分，计算出的结果直接控制系统的动作。算法的失效模式转化成计算输出的相关变量的失效。

(4)软件接口变量，包括软件和软件之间(函数调用、进程通信等)、软件和硬件之间(设置数模转换端口到指定值)、硬件和软件之间(软件读取温度传感器)、或者硬件和硬件之间的失效。硬件受到环境影响，其在传输过程会出现差错，硬件输入的变量是在实际中常常出现问题的变量。

2)体系结构“度”值选取法

关键变量的重要度从体系重要度和功能重要度两个方面体现：功能重要度描述的是变量所具有的的功能失效造成影响的重要性；体系重要度，描述的是变量在体系结构中的重要性。变量和模块之间的关系越复杂，其体系重要性越高，因为复杂关系的变量更加容易出现失效。立足于依赖模型的特点辅助软件FMEA，根据依赖关系对变量节点、域节点采用内聚度和耦合度算法进行“度”的度量。通过度值的分析可以帮助用户找出关键函数和关键变量。下面给出计算内聚度和耦合度的算法：

定义1图的体积(用V表示)

假设图中节点的总个数为n个,图的层次为m层(这里的层次类似于树的深度),那么这个图的体积V＝n*m。

定义2内聚度(用COH表示)

假设图中边的条数为e条,图的体积为V,那么这个图所代表的模块的内聚度COH＝e/V。内聚度是用来度量图单位体积里所包含的边的条数的,单位体积里包含的边的条数越多,那么内聚度就越强,反之,如果单位体积里包含的边的条数越少,那么内聚度就越弱。

定义3依赖率(用G表示)

用一个依赖图的两个子图A,B分别代表两个模块。假设图A中有n1个节点与B中的节点存在边,图B中有n2个节点与A中的节点存在边。则A对B的依赖率GA＝n2/n1,B对A的依赖率GB＝n1/n2。依赖率反映的是一个图对另一个图的依赖程度,依赖率越大,表示依赖程度越大,反之亦然。

定义4耦合度(用COU表示)

假设子图A中的节点与子图B中的节点存在的边的条数为e1条,A对B的依赖率为η_A,那么A对B的耦合度为COUA＝e1×η_A；假设子图B中的节点与子图A中的节点存在的边的条数为e2,B对A的依赖率为η_B,那么B对A的耦合度为COUB＝e2×η_B

内聚度，反映的是内部成分相关联程度。内聚度越大，内部越复杂，其体系重要度越高。耦合度是指节点间的相关联程度,关联程度越大,则耦合度越强,反之亦然。通过分析各个变量与其他节点之间的耦合度，耦合度比较大的其外部依赖关系越复杂，其体系重要度更高。如果两个节点耦合度相同，可以计算与之相连节点耦合度之和，与之相连节点耦合度之和越大，则本节点体系重要度越大。将体系重要度大的变量也作为要分析的重点变量。

3)系统级FMEA选取法

对系统级FMEA选取的重要模块，向下追踪原因，逐渐追踪到一组变量集，这些变量可能造成这个关键模块的失效，但具体怎么样还需要分析，所以选择这些波及到的变量作为分析对象，然后逐个对每个变量进行失效模式分析。

第七步，确定待分析变量的具体失效模式，由详细级别依赖模型可达性节点分析，分析变量的失效影响及产生原因，提出改进措施。

失效模式影响分析的目的是要分析每个失效模式对当前软件元素输出的影响，详细级FMEA着重关心的是每个输入变量的失效对当前软件元素输出的影响。控制依赖的表示能够很好的表现出程序之间的层次关系，而这种层次关系恰好是FMEA的必要条件。在详细级SFMEA分析中，针对具体的代码，控制依赖和数据依赖具有传递性，准确的定位失效原因及影响所在的位置(即具体的语句或变量)，转化为一个简单的图的可达性问题。

详细级变量的失效模式确定

详细级软件失效模式对象提取后需要确定详细级软件失效模式。与系统级不同是，详细级分析对象是变量，失效模式的确定依据变量的属性确定。变量具有名字、地址、值、作用域、生存期属性。与现有分析方式一样，根据变量的相关属性，查找详细级通用失效模式集，确定变量的具体失效模式。但是仅仅根据节点的属性，确定的失效模式有可能不符合实际，有些故障模式可能在某种情况不会发生，有些节点的故障模式可能不仅仅是模式库里面的，FMEA本身离不开分析人员进行对每个失效模式的检查与补充，在补充的时候，要考虑是否有必要加入到详细级通用失效模式集中。

基于详细级层次依赖模型的失效原因分析

先进行失效原因分析再进行失效影响分析。软件失效原因是由于软件缺陷在运行时被触发而产生的。在对软件失效原因的遍历与失效影响的遍历恰好相反，以当前节点开始，按控制依赖箭头方向，按数据传递箭头反方向遍历。再以下一层被依赖的节点进行迭代搜索，一直搜索到下层没有相依赖的节点或者达到最低约定层次为止。遍历方法与分析方法与系统级一样，下层失效模式是上层的失效原因。与系统级原因分析不一样的是，遍历分析的节点代表的是变量，而不是具有一定功能的软件模块，失效的原因归结到变量而不是功能。

详细级变量失效模式的原因也有内在和外在两类。软件失效内在原因都是在软件开发过程中形成且未被排除的潜在缺陷，如有缺陷的或多余的指令或指令集，这些缺陷来源可能是软件开发者的失误，也可能是恶意逻辑；外在原因都是软件外部给软件提供的各种非期望的条件，这些条件又分为两种，一种是客观存在于软件外部的系统中国的环境异常，也可能是有人恶意的侵袭。软件中的信息收到外部的两类干扰：在传输过程中受到干扰(如通讯线路干扰)；存储过程受到干扰(如受到重粒子轰击等)。另外，常见失效原因参见GJB1391。

基于详细级层次依赖模型的失效影响分析

一个失效是由于程序语句中执行了不正确的变量值而引起的，详细级层次依赖模型中依赖边详尽地描述变量的使用过程，基于层次依赖模型在详细级进行失效影响分析的方法与在系统级方法相似，根据变量失效发生的所在位置，评估软件失效对同一层次其他变量或函数的影响、对上一层次的影响以及对整个软件系统的影响。一个软件变量失效，其影响只可能波及到与该变量有控制依赖和数据依赖关系的其他变量或函数，层次依赖关系模型实际上是一个分层次的网状结构。因此软件失效影响分析问题可以被转化为在系统层次依赖关系模型中图的遍历算法。

以当前节点开始，按控制依赖反箭头方向，按数据传递箭头方向遍历。再以上一层所依赖的节点进行迭代搜索，一直搜索到上层没有相依赖的节点或者达到初始约定层次为止。遍历分析方法与过程和系统级一样。

下面对变量依赖图建模以及依赖搜索的事项加以说明。

●循环依赖情况

两个节点还可能有多条先后顺序的依赖形成环状。如果一个处理过程连续，为了表示同一变量在不同阶段的节点，利用依赖关系的优先级属性辨别依赖的顺序，从而更清楚的表现影响的传递。如果优先级相同，那么在遍历过程中，强行终止，因为影响了一圈后有影响到自己，再查找影响，还是针对本节点的影响，依旧是这条环路，重复分析没有意义。

●依赖有约束情况

一个变量影响另一个变量，中间可能有约束，例如加了限幅：

If(b>100)b＝100；if(b<10)b＝10；

a＝b；

那么a依赖于b，在搜索依赖关系时，a对b的依赖就会给出，但是b出现越界，但是却并不影响到a。这其实就是改进后的效果。

对于这种情况处理方式：是在依赖关系上增加一个条件依赖约束属性，系统在搜索路径过程中，将有约束的依赖关系给予提示，让人辨别这条依赖是否会影响下个节点。

对于采用了余度设计、备用工作方式设计或故障检测与保护设计的产品，在FMEA中应暂不考虑这些设计措施而直接分析产品故障模式的最终影响。并根据这一最终影响确定其严酷度等级。对此情况，应在FMEA表中指明产品针对这种故障模式影响已采取了上述设计措施。若需更仔细分析其影响，则应借助于故障模式危害性分析。

改进措施提出方法

对于详细级所涉及变量的改进措施提出方法也是利用现有的可靠性设计技术，主要利用软件的故障判断和故障处理。故障判断指检测系统中是否发生故障，指示故障状态，软件中常见的故障判断方法是加入判断语句进行条件选择。

软件故障处理包括信息容错和时间容错。

信息容错一种方式是通过在数据中外加一部分冗余信息码以达到故障检测、故障屏蔽或容错的目的。这种方式一般用于数据通信软件系统中，外加的一部分信息常以编码的形式出现，称为检错码或纠错码。常使用的检错和纠错码有奇偶检验码、检验和、海明码、循环冗余校验码(CRC校验)。信息容错的另一种方式是对随机存取存储器(RAM)中的程序和数据，存储在三个或三个以上不同的地方，而访问这些程序和数据都通过表决判断的方式(一致表决或多数表决)来裁决，以防止因数据的偶然性故障造成不可挽回的损失。这种方式一般用于软件中某些重要的程序和数据中。

时间容错是不惜以牺牲时间为代价来换取软件系统高可靠性的一种手段，常被采用而行之有效的方法。对于详细级故障模式，常常用到指令复执和程序卷回这种时间容错的改进措施。指令复执是在指令(语句)级作重复计算。程序卷回是一种后向恢复技术，是以事先建立恢复点为基础的。

软件改进措施方法提出的优先顺序为：更改软件设计，消除导致关键性硬件故障的原因；加强软件对异常情况的处理(例如容错设计技术)，减小故障影响严重程度；采用故障-安全设计技术，降低故障发生的可能性；在软件执行关键性的功能时，应使程序具有自检查的功能，即降低故障的检测难度，提高可检测性；通过软件测试，验证软件中没有存在失效模式引发的缺陷；使用补偿措施，对用户进行专门的训练。

Claims (1)

1.基于层次依赖建模的软件FMEA方法，具体实现步骤如下：

第一步，确定分析目标；

通过目标软件的软件需求规格说明文档，利用需求关键性分析方法，识别目标软件的安全关键需求，根据安全关键需求得到安全关键功能；

第二步，构建系统级层次依赖关系模型；

1)对目标软件进行分解和数据精化；

将安全关键功能进行层次分解，分解出子功能；同时对软件进行结构的层次分解，结构分解出软件模块；数据精化辨别出数据在模块之间的传递关系包括交换数据类型、数据取值范围、实时性约束；

2)基于分解结果，为节点添加属性，构建层次依赖模型控制依赖关系；

(1)增添系统级别层次依赖模型节点的信息

通过现有的软件模块关键性分析方法，辨别分解后的模块与分解后功能对应关系以及模块的安全关键性，将功能作为模块的属性；约定：上层模块功能属性是下层功能属性的综合，下层节点的功能属性是上层的功能分解；

在层次依赖模型中每个节点采用一个八元组Na＝(M，I，O，P，L，G，Q，C)来储存信息，其中：

a)M是节点的名称或编号，能唯一标识这个节点，且不为空值；

b)I是节点代表的模块的输入变量集合，非空，集合中的每个变量又分别是一个变量模型，变量模型包括变量编号、变量名称、变量类型、变量作用域属性；

c)O是节点代表的模块的输出变量集合，其属性与输入变量I相同，即，集合中的每个变量也是一个变量模型，变量模型包括变量编号、变量名称、变量类型、变量作用域属性；

d)P是处理过程描述，描述节点所代表的模块的功能流程，可以是文字性描述，也可以是流程图形式，主要用于分析人员对功能有更深刻理解，P可以为空；

e)L是层次依赖模型中上层相关联节点的集合，即控制依赖本节点的上层节点集合，L包括上个横向层次中相依赖节点集合L1和上个纵向层次相依赖节点集合L2；

f)G是层次依赖模型中节点的功能属性，包括详细描述和功能关键词两个属性，其中功能关键词属性主要由分析人员的通用软件失效模式集确定，功能关键词用于FMEA自动化查找失效模式，详细描述是对功能关键词进行细致的描述，便于分析人员理解；

g)Q是层次依赖模型中下一个层次相关联节点的集合，Q包括下个横向层次相依赖节点集合Q1和下个纵向层次相依赖节点集合Q2；

h)C表示本节点所处的层次，包括横向层次及纵向层次，采用层次对<横向层次，纵向层次>表示；

(2)识别系统级别的层次依赖模型中依赖关系及增添属性

模块间的控制依赖关系是指模块间的调用关系或包含关系，用模块间的控制依赖边表示，从代表调用模块或总模块的节点指向代表被调用模块或子模块的节点，用实箭头表示；逆着箭头方向是寻找失效的影响，顺着箭头是寻找失效的可能原因；

模块间的数据依赖关系是指模块间的数据传递，在本模型中采用数据传递边表示，数据传递边从代表数据定义模块的节点指向代表数据应用模块的节点，用虚箭头表示；顺着箭头是寻找失效的影响，逆着箭头方向是寻找失效的原因；

每个节点间的依赖关系采用一个七元组E＝(I，Q，Z，L，P，C，Y)来储存信息，其中：

a)I表示的是依赖关系的编号，每个依赖关系都有唯一的编号；

b)Q表示的是表示依赖关系箭头的起点的名称或编号，由于不同依赖关系表示方式不同，起点是指箭头连线的起始点，而非依赖关系的起点；

c)Z表示的是表示依赖关系箭头的终点的名称或编号，也是指箭头连线的终点，而非依赖关系的终点；

d)L表示的是依赖的类型，不同的依赖关系所使用的箭头不同，箭头的起点与终点的含义不同，如控制依赖的起点依赖终点，数据传递是数据由起点传递到终点，终点依赖于起点，类型包括数据传递、控制依赖、同步依赖、通信依赖、控制流向，在系统级层次依赖模型中使用的是控制依赖与数据传递；

e)P表示的是依赖的优先级，同一个节点有多条依赖关系时，通过优先级表示此节点被依赖的顺序，默认情况下为0，数值越大，优先级越低；如果在循环依赖的情况下有不同的优先级，影响分析时，优先级越高的首选被遍历，只有在没有更低的依赖关系时循环依赖遍历完成；主要是用于更清楚的表现传播影响路径；在分析失效原因时，优先级低的首选被遍历；

f)C表示依赖关系代表的操作的描述，包括：调用、包含、控制流向、数据读、数据写；

g)Y表示依赖关系的约束，控制依赖的约束有递归、条件调用，数据依赖的约束有数值限幅、实时性要求，对约束还可以进行详细描述；

3)基于数据精化的结果，在只包含控制依赖关系的层次依赖模型中，节点间增加相应的数据传递边；层次依赖模型是一种使用控制依赖和数据依赖表示软件结构的层次关系和数据关系的一种模型，定义为六元组<N，E，Ec，Ed，V，f>表示；其中，N是节点集合；E是节点间的依赖边；Ec为节点间控制依赖边，用实的有向边表示，从调用模块指向被调用模块；Ed为模块间数据传递边，用虚的有向边表示，有向边的方向与模块间数据流动的方向一致；E＝Ec∪Ed，V是目标软件系统的数据集合；f为从Ed到V上函数f：Ed→V，表示数据依赖边上流动的数据流信息；

为降低数据传递的冗余性，在系统级层次依赖模型中，数据传递边只在模型的叶子节点之间构建；通过对目标软件进行分析，在叶子模块间的数据依赖关系表现为以下五种形式：

(1)全局变量和数组的数据传递；

(2)函数调用形参传递；

(3)函数内部静态局部变量的数值传递；

(4)函数返回参数的传递；

(5)其它公共数据交换模式，如文件、数据库；

第三步，选取约定层次，确定约定层次中每个模块的失效模式，由系统级层次依赖模型节点可达性分析，分析失效原因追踪路径和失效影响传播路径,确定失效原因和失效影响，提出改进措施；

1)与现有技术一样，首先选定要分析的层次，确定出合理的初始约定层次和最低约定层次；

(1)确定初始约定层次

它是系统级软件FMEA最终影响的对象；

(2)确定约定层次

它规定了系统级软件FMEA所要分析的软件的范围，超出这个范围的其他所涉及到的因素都应该划归为软件的运行环境范畴；

(3)确定最低约定层次

为使最低约定层次能够明确定义，采用如下规定：

●所有可获得分析数据的软件单元中最低的层次，它能够有完整的输入，或能够对应到软件中的一个或几个有一定功能的函数；

●当软件中某模块的失效将直接导致灾难的(I类)或致命的(II类)的后果时，则最低约定层次至少划分到这一模块所在层次；

●确定或预期需要单元测试的最低产品层次，这些软件单元可能导致临界的(III类)或轻度的(IV类)故障；

2)获取通用软件失效模式集与确定待分析节点具体失效模式的步骤如下：

(1)定义故障判据，它是根据产品的功能、性能指标、使用环境等允许极限进行确定的；本方法故障判据如下：

a)软件在规定的条件下和规定时间内，不能完成规定的功能；

b)软件在规定的条件下和规定时间内，某些性能指标不能保持在规定的范围内；

c)软件在规定的条件下和规定时间内，通过硬件引起对能源和物资的消耗或人员、环境的影响超出了允许范围；

d)技术协议或其他文件规定的故障判据；

(2)对通过故障判据判定的故障进行分析和抽象，采取了“输入-输出-处理-性能”分类方式对软件中常见失效模式进行总结归类，形成通用的失效模式集S；

(3)基于通用的失效模式集S和已经建立的软件系统依赖关系模型中节点的功能属性，分析当前关注的节点所代表的的模块所有可能发生的具体失效模式集T；具体失效模式确定方法有：

a)启发式，直接来自于通用失效模式集的失效模式或某些失效模式的进一步细化或变种；对采用现有的软件，可从该软件在过去的使用中所发生的故障模式为基础，再根据该软件使用环境条件的异同进行分析修正，进而得到该软件的故障模式；

b)借鉴式，从相似功能和相似结构软件中发生的故障模式作基础，分析判断其故障模式；

c)脑力激荡式，通过调查分析软件失效发生机理，即根据常见软件缺陷来预测可能的失效；

d)变异式，从软件使用环境，功能、体系结构和维护要求以及可靠性、安全性要求方面入手理解目标软件系统提取特有失效模式；

e)索取式，对引进国外货架软件，应向外商索取其故障模式

(4)将特有失效模式总结抽象，归结到通用失效模式集S中，为以后分析提供借鉴；

3)基于系统层次依赖关系模型进行失效原因分析

在层次依赖模型中，按照其控制依赖箭头的正方向，数据传递箭头的反方向，采用深度优先遍历算法，来查找目标软件中导致某一模块失效的所有可能模块；

低层次产品的故障模式是紧邻上一层次的故障原因这样对的高层影响的自动生成高层节点的故障模式，同时高层的相应的故障原因也通过低层节点的故障模式自动生成；

对于分析到最低层失效原因时将失效原因归结到软件设计缺陷，或者通过详细级确定失效更本质的原因；

4)利用系统级层次依赖模型进行软件失效影响分析

采用深度优先遍历方法按照其控制依赖箭头的反方向，数据传递箭头的正方向，来查找目标软件中该模块的失效所影响到的所有可能模块对应的节点；低层次的上级影响就是中间层次的故障模式，中间层次的上级影响又是更高层次的故障模式；中间层次和低层次的最终影响同对应的最高层次的最终影响；根据影响到的节点的属性，辨别影响到的节点的某一具体失效模式就是影响结果；

每个节点，都有属性加以信息约束，进行寻找可达节点遍历时由功能关键字搜索通用软件失效模式集，将与之相关的所有失效模式查找出来；在遍历过程中需对相关联的节点之间进行功能关键字匹配，判断是否有冗余；

5)在系统级FMEA中对影响严酷度的判别

首先由研制方从功能角度制定高层功能失效的严酷度，研制方制定功能失效严酷度层次应在分解系统时，功能与结构开始出现不完全对应的一层；

分析人员利用层次依赖模型，将影响定位到结构中的模块，高层的模块与功能对应，辨别影响到的高层功能，通过对高层功能的影响程度以及高层功能失效的严酷度确定底层失效的具体严酷度；如果底层失效引起高层功能完全失效，那么严酷度等级应与高层一致，如果部分影响高层功能，即高层功能并未完全失效，那么严酷度等级应该比高层功能失效低；

6)改进措施的提出

对于软件来讲，改进措施的提出方法主要结合现有的软件可靠性设计方法，在系统级有以下方法：

(1)重新设计方法,利用软件工程化思想，采用合适的软件开发过程、开发方法及工具，贯彻软件避错设计原理，重点考虑抽象与逐步求精、模块独立与信息隐藏、健壮性设计、形式化方法；这种重新设计的措施耗费人力物力，所以采用冗余设计；

(2)冗余设计，针对系统级的故障模式采取的改进措施有结构容错和时间容错；结构容错包括N-版本程序设计NVP和恢复块RB两种基本技术以及一致性恢复块、接受表决、N自检程序设计等先进技术；时间容错针对系统级故障模式主要是建立软件系统运行日志和数据副本，设计较完备的数据备份和系统重构机制，以便在出现修改或删除等严重误操作、硬盘损坏、人为或病毒破坏及遭遇灾害时能恢复或重构系统；

(3)通过详细级改进，对出现的失效模式进行详细级软件FMEA，由于详细级中通过变量线索一步步向上影响到系统级的功能，在详细级针对变量的故障模式提出的改进措施也是对系统级功能设计的改进；

第四步，根据系统级软件FMEA结果，选取详细级FMEA分析对象,

为了降低分析人员选取分析模块的随意性，本方法针制定如下选取规则：

1)功能重要性选取法，系统的核心模块，实现其主要功能；

2)体系重要性选取法，与其它模块有较多的交互，通过耦合度计算度量；

3)逻辑复杂性选取法，通过算法空间复杂度和时间复杂度度量；

4)专家打分法，FMEA本身离不开分析人员的经验，有经验分析人员直觉出问题的模块也是分析的重点；

5)系统级软件FMEA选取法，系统级软件FMEA中查找到的会引起关键用例或功能发生失效的模块，其严酷度或危害度在Ⅱ类(致命的，参见GJB1391)以上；

第五步，以选取的分析对象的详细设计或伪代码为依据，构建详细级层次依赖模型；

1)辨别分析对象的控制流

控制流图是程序依赖图中数据依赖和控制依赖信息的载体，控制流节点中包含对应的存储数据依赖和控制依赖信息的域；

2)识别节点，控制依赖关系与数据依赖关系

(1)识别详细级层次依赖模型中节点；

在详细级依赖模型中包含几种类型的结点：单节点，表示软件中的单语句或某变量；域结点，概括了域中语句间的控制依赖；

域节点可分为以下五大类型：1.模块节点，表示系统级结构分解的模块；2.函数节点，用于表述函数整体功能以及相关参数之间传递；3.复合语句节点，表述了一个复合语句整体的实现，实现一定算法功能的语句块也可视为复合语句节点；4.谓词控制节点，表示程序中的策略或分支条件，包括条件语句包括switch语句和循环语句的判断部分，用该语句谓词的标记表示；5.结构化跳转语句节点，包括break、continue、return语句；

在详细级层次依赖模型每个域节点从功能出发，也约定上层节点功能属性是下层功能属性的综合，用八元组Na＝(M，I，O，P，L，G，Q，C)储存信息，同系统级FMEA中模块节点的定义；

变量节点，包括变量ID、变量名称、数据类型、存储类型、作用域、所处的域，别名属性，采用一个七元组表示Nb＝(ID，Name，L，CL，Y，SY，BN)；其中，

a)ID作为一个变量节点的唯一标识；

b)Name表示变量的名称，同一个名称的变量可能因为作用域表示不同内容；

c)L表示数据类型，数据类型有整型、实型、字符型、数组类型、指针类型、结构体类型、及公用体类型；数据类型决定了变量值的数据类型、表现形式和分配空间的大小以及对变量能执行的操作；每个变量数据类型还应标识是否与时间相关以及时间约束特性；

d)CL表示变量的存储类型，在C/C++语言中，变量的存储类型有4种：自动类(auto)、静态类(static)、寄存器类(register)来和外部类(extern)；

e)Y表示变量的作用域，包括局部变量和全局变量，参数变量视为局部变量；

f)SY表示变量属于某个域节点内，表示变量与某个域节点的从属关系；

g)BN表示数组变量、指针变量或全局变量、静态变量的别名属性，主要是因为出现在不同的语句中，改变一处其他都会改变；别名属性表示方法为<p,<t,i>,d,r>,并定义如下约束规则:

(a)p、t是互为别名的变量编号；它们没有先后顺序之分，但如果其中一个是数组元素，则要把它放在t的位置；

(b)i是数组元素t的下标，如果t是普通的指针变量，则i＝-1；如果t为多维数组元素，则可以用将i扩展为多元组的方法，精确表示其下标信息；

(c)d是p的解引用级别，p＝-1表示取地址；p＝1表示指向；

(d)r表示别名关系，r＝D表示必然别名，r＝P表示可能别名；

(e)<*p,<*t,i>,d,r>与<p,<t,i>,d,r>等价，因此在集合中均表示为<p,<t,i>,d,r>；

(f)p≠t，即不表示自反性导出的别名对；

别名可以准确地表示数组和指针的别名信息；别名问题主要指示了同名变量之间、参数传递之间或指针引用之间的依赖关系；

(2)识别详细级层次依赖模型中依赖关系

定义1控制依赖

令G是一个控制流图，u和w是G中的节点；结点u是控制依赖w的，当且仅当：

①在一条从u到w的有向路径P，v是p中任意一个结点，不包括结点U和w，w是v的后必经结点；

②w不是u的后必经结点；

③控制依赖箭头指向由u指向w；

其简单理解为：如果结点u是控制依赖w，那么u必须有两个出口；沿着其中的一个出口，总是导致执行w，而另外一个出口则导致w不被执行；

定义2数据依赖

设u与v为给定程序中两条不同的语句，如果有一条从u到v的执行路径,同时存在一个在u处定义、v处引用的变量，且该变量在从u到v的执行路径上的其他位置没有被重新定义，则称v数据依赖于u；数据依赖在层次依赖模型中用数据传递表示，由u指向v；

定义3同步依赖:设u与v为给定程序不同线程中的两条语句,如果u执行的开始或终止通过线程间同步直接决定v执行的开始或终止,则称v同步依赖于u；

定义4通信依赖:设u与v为给定程序不同线程中的两条语句,如果u计算的变量的值通过线程间通信直接影响在v计算的变量的值,则称v通信依赖于u；

在详细级层次依赖模型中依赖属性与系统级依赖关系属性定义完全一样，采用一个七元组E＝(I，Q，Z，L，P，C，Y)表示；

2)节点与依赖关系的精简

(1)如果x是条件谓词节点，在信息的传递过程中只充当中介，以它为基础对依赖图进行传递转换，同时删除这个节点以及它依赖于其他节点的依赖边；

(2)详细级FMEA中关注的是待分析变量之间的依赖关系，所以依赖模型中的中间媒介变量就可以省略；

(3)对全局变量和局部变量的不需要区别处理，只要把没有对外可见性的局部变量节点从依赖模型图中删除即可；

(4)两个方法的参数结点之间的数据依赖关系用方法之间的数据依赖来表示；每个过程依赖图只需用过程入口结点表示即可，而不必再展开表示；

3)关于变量的依赖关系构建

如果从变量定义节点到使用变量的节点之间没有该变量的重新定义并且使用变量的节点包含变量定义节点定义的变量，则称该变量使用节点数据依赖于该变量定义结点；添加数据流边由变量定义节点指向使用变量的节点；

在C/C++程序中主要是引用和指针导致别名；对于静态变量、全局变量、静态参数变量，通过别名表示，按别名属性以暗线形式搜索路径；对于变量传递到另一个域节点中，利用变量节点的属于SY属性将变量与相关域节点进行相关联，辨别同名变量的依赖关系；

4)关于谓词控制节点的控制依赖构建

软件中有三种主要的控制结构，分别为顺序结构，判断结构与循环结构；对各种控制节点的构建；

5)关于函数的依赖关系构建

(1)辨别函数调用关系

在每个调用位置节点和相应的过程入口节点之间加入调用边；如果是条件依赖在依赖约束属性Y中要加以限定；

(2)调用关系中构建参数依赖或输入、输出依赖；

变量对函数的依赖有四种形式，一种是传值，另一种是传址或传引用；第三种是通过全局变量或静态变量来联系；第四种，被调函数返回值赋值给变量；

(3)将形参视为内部局部变量，构建被调用函数内部依赖关系；参数和函数调用点之间规定为形参控制依赖于函数定义入口；

(4)对于控制节点和复合语句，可以视为多入口和多出口的函数，出口是通过同名变量；

6)内联与递归函数构建方法

(1)多态函数时可当做一般函数处理，只是将调用的函数名称展开成几个横向层次，每个横向层次描述每一个多态函数的内部层次模型；分析失效影响和原因时等同的每个多态函数遍历；

(2)用函数内联的方法处理将调节点用被调用的函数体替换，在层次依赖模型中，可以视为传引用方式的函数；

(3)确定函数之间调用关系以及标记是否条件调用之后，模拟递归子程序的执行过程，分两步分析递归函数A的依赖关系:

a)去掉S1到S2且通过call A的路径上的所有语句，然后搭建A的依赖模型图，并求出参数之间的依赖关系；这相当于模拟了递归过程中最后一次对A的调用由于语句S1中的条件不能满足而跳过了call A的执行；

b)恢复第一步去掉的语句，建立callA输入与输出的数据传递，增加call A指向A的控制依赖，并标记依赖约束为递归；根据递归中的返回过程，增加call A前面节点到S2后节点的数据传递；

定义A为一个递归过程，call A为递归过程A中进行对自己递归调用的语句，S1为callA语句控制依赖的判断语句，S2为语句S1后最近的向后必经语句；

(4)间接递归建模过程和处理算法

a)求出这些子函数分析的顺序；

(a)在调用回路中，逐条断开条件调用边直到某一节点的出度为0；如果去掉所有能去掉的条件调用边，没有找到出度为0的节点，则此递归调用一定不能终止，出现死循环；

(b)如果节点A的出度为0，则去除节点A和所有指向A的边，包括条件调用边，然后找下一个出度0的节点，直到列出所有节点为止，如果在此过程中，又出现了回路，转(1)；设A0,A1,…,AZ是求得的分析序列；

b)计算所有子程序的参数依赖集；

(a)按第一步求得的分析顺序算出各个子程序程序依赖图PDG和形参依赖集；在计算A_i时,如果A_i→A_j(c)是在a)的(a)中被断开的条件调用边,则在这次计算中将不考虑A_i对A_j的调用，具体处理与直接递归a)相似，如果是被断开的不是条件调用边，直接按关于函数的依赖构建方法；

(b)逐次加上在a)的(a)中被断开的条件调用边，增加Ai与Aj之间输入与输出的数据传递，具体处理与直接递归b)相似；

7)并发程序层次依赖建模

(1)描述程序P的并发程序流图；用cobegin和coend分别表示线程的创建和终止，将cobegin、coend以及共享变量读写语句统称为交互语句；

(2)根据交互语句将线程分块，称为线程域；每个线程域用一个节点表示，节点间的边表示交互活动，由此生成线程交互图将每个线程域用一个节点表示，节点间的边表示相应的交互活动，由此生成的图称做线程域交互示意图；

(3)给定p个线程{t0,t1,…,tp1}的线程域交互示意图，<Ni,Ei,nsⁱ,Fi,Li>,0≤i<p,主程序作为t0处理，根据交互活动的标签,可对由这组线程所构成的并发程序进行可达性分析，生成线程交互可达图；

程交互可达图的节点组合，表示并发程序在执行一系列交互活动后所到达的程序状态，用p元组表示，第i个分量为第i个线程即将执行的线程域；可达性分析从初始可达标志ms开始，ms＝(n_s ⁰,⊥,…,⊥),其中⊥表示任务未激活或已终止，根据可能发生的交互活动，生成所有可能的后继可达标志，后继可达标志与前驱可达标志除发生交互的线程的分量发生变化外，其余分量不变；

(4)对任意可达标志m，在m的各线程域分量中出现的语句都有可能在m下执行，m只能与这些语句进行组合；同一语句与不同的程序状态组合生成不同的M-S对；在依赖模型中表现形式是对节点S进行属性扩充，增加一个程序状态属性M；同一个语句根据所处的不同状态可能产生不同的失效影响路径；M为可达标志集，m为可达标志,表示并发程序在执行一系列交互活动后所到达的程序状态，用p元组表示，第i个分量为第i个线程即将执行的线程域，所有m组成可达标志集M；使用可达标志表示系统状态，即一个m为一个状态，可达标志集M即为系统状态集，所以系统状态属性使用可达标志集M表示；

第六步，根据详细级层次依赖模型，选取要分析的关键变量；

1)变量类型选取法

在软件开发过程中，根据不同需要定义不同类型变量，所以不同类型的变量有着不同的作用以及重要性，FMEA中重点关注一下类型变量：

(1)有多个函数进行调用的全局变量；

(2)外部的参数变量；

(3)算法输出变量；

(4)软件接口变量，尤其是硬件输入的变量

2)体系结构“度”值选取法

根据依赖关系对变量节点、域节点采用内聚度和耦合度算法进行“度”的度量：

(1)图的体积(用V表示)

假设图中节点的总个数为n个,图的层次为m层,那么这个图的体积V＝n*m；

(2)内聚度(用COH表示)

假设图中边的条数为e条,图的体积为V,那么这个图所代表的模块的内聚度COH＝e/V；(3)依赖率(用G表示)

用一个依赖图的两个子图A,B分别代表两个模块；假设图A中有n1个节点与B中的节点存在边,图B中有n2个节点与A中的节点存在边；则A对B的依赖率GA＝n2/n1,B对A的依赖率GB＝n1/n2；

(4)耦合度(用COU表示)

假设子图A中的节点与子图B中的节点存在的边的条数为e1条,A对B的依赖率为η_A,那么A对B的耦合度为COUA＝e1×η_A；假设子图B中的节点与子图A中的节点存在的边的条数为e2,B对A的依赖率为η_B,那么B对A的耦合度为COUB＝e2×η_B；

内聚度越大，内部越复杂，其内部体系重要度越高；节点间的相关联程度越大,则耦合度越强,反之亦然；通过分析各个变量与其他节点之间的耦合度，耦合度比较大的其外部依赖关系越复杂，其外部体系重要度更高；如果两个节点耦合度相同，可以计算与之相连节点耦合度之和，与之相连节点耦合度之和越大，则本节点体系重要度越大；

3)系统级FMEA选取法

对系统级FMEA选取的重要模块，向下追踪原因，逐渐追踪到一组变量集，选择这些波及到的变量作为分析对象，然后逐渐对每个变量进行失效模式分析；

第七步，确定待分析变量的具体失效模式，由详细级别依赖模型可达性节点分析，分析变量的产生原因及失效影响，提出改进措施

1)详细级变量的失效模式确定

详细级分析对象是变量，失效模式的确定依据变量的属性确定；变量具有名字、地址、值、作用域、生存期属性；与现有分析方式一样，根据变量的相关属性，查找详细级通用失效模式集，确定变量的具体失效模式；

2)基于详细级层次依赖模型的失效原因分析

在对软件失效原因的遍历与失效影响的遍历恰好相反，以当前节点开始，按控制依赖箭头方向，按数据传递箭头反方向遍历；再以下一层被依赖的节点进行迭代搜索，一直搜索到下层没有相依赖的节点或者达到最低约定层次为止；遍历方法与分析方法与系统级一样，下层失效模式是上层的失效原因；软件失效原因是由于软件缺陷在运行时被触发而产生的；

3)基于详细级层次依赖模型的失效影响分析

此软件失效影响分析问题可以被转化为在系统层次依赖关系模型中图的遍历算法；

以当前节点开始，按控制依赖反箭头方向，按数据传递箭头方向遍历；再以上一层所依赖的节点进行迭代搜索，一直搜索到上层没有相依赖的节点或者达到初始约定层次为止；遍历分析方法与过程和系统级一样；

4)改进措施提出方法

主要利用软件的故障判断和故障处理；

软件故障处理包括信息容错和时间容错；

信息容错一种方式是通过在数据中外加一部分冗余信息码以达到故障检测、故障屏蔽或容错的目的；外加的一部分信息以编码的形式出现，称为检错码或纠错码；检错和纠错码有奇偶检验码、检验和、海明码、循环冗余校验码；信息容错的另一种方式是对随机存取存储器中的程序和数据，存储在三个或三个以上不同的地方，而访问这些程序和数据都通过表决判断的方式来裁决，即一致表决或多数表决，以防止因数据的偶然性故障造成不可挽回的损失；这种方式用于软件中某些重要的程序和数据中；

时间容错是不惜以牺牲时间为代价来换取软件系统高可靠性的一种手段；对于详细级故障模式，用指令复执和程序卷回这种时间容错的改进措施：指令复执是在指令级作重复计算；程序卷回是一种后向恢复技术，是以事先建立恢复点为基础的。