一种安全性关键软件的评估模型

姜梦霞，江国华

（南京航空航天大学计算机科学与技术学院，南京 210016）

一种安全性关键软件的评估模型

姜梦霞，江国华

（南京航空航天大学计算机科学与技术学院，南京 210016）

安全性关键软件影响生命财产安全，必须有定量评估模型来反映此类软件的安全性。传统安全性定量评估通过改进可靠性模型并将软件看作整体评估，而未探究软件失效本质，不能很好地评估软件行为安全性。为此，基于软件失效本质及对安全性关键场景的研究，提出软件交互行为模型，给出从各软件运行条件的关系中构造交互模式依赖图的方法，设计基于软件过程行为的安全性评估模型。实例分析表明，该模型能识别出所有软件过程行为及其发生率、失效率，为每个过程行为赋予风险指数，并计算得到整体的软件风险指数。

安全性关键软件；软件交互行为模型；交互模式依赖图；安全性评估模型；软件过程行为

DO I：10.3969/j.issn.1000-3428.2015.10.025

1 概述

随着计算机技术飞速发展，安全性关键软件在各个领域发挥着重要作用，如核电站、航空航天、工业控制、军事等，其安全性一直是国内外研究的焦点。

国内外各领域均提出相应的标准或指南确保软件 安 全 性，国 外 有 AS9100［1］，DO-178C［2］，MIL-STD-882D［3］等，国内有GJB Z102-97［4］，GJB Z142-2004［5］，GJB 900-90［6］等，而评判软件安全性是否达到预期标准离不开安全性评估。

由于安全性与可靠性有很多相似点，现有研究通常通过改进可靠性模型（如J-M）来评估软件安全性［7-9］，试图在可靠性模型上赋予安全性意义，如重要度划分。这类方法依据软件整体失效数据，将其看作整体进行安全性评估，未考虑软件失效本质，不能很好地评估软件行为的安全性。

软件一旦成品，缺陷就已经确定并隐藏在内部，只有某些特定条件发生，缺陷才可能暴露而引起内部状态发生意外变化，最终导致失效，这是软件失效机理［10］。这种特定条件是软件与系统其他元素（如软、硬件，人为操作）交互的一种模式或状态，一旦发生便触发软件某种响应，称软件交互模式。因此，软件失效本质是某些交互模式下缺陷的

暴露，有些交互模式发生率极低，这就是为什么安全性关键软件在大量测试之后仍然会存在安全性隐患的原因。

现有少部分研究从软件与系统交互这个角度考虑安全性。文献［11］将软件失效归因于某些系统场景的软件设计不合理，认为软件安全性评估需识别所有这种场景。文献［12］认为安全性是系统属性，软件只有与系统交互才具备安全性，针对软硬件安全问题不应假设对方行为正确。NASA版本2的概率风险分析（Probabilistic Risk Analysis，PRA）过程指南提出了CSRM［13］，主要结合PRA相关模型识别软件相关风险场景并量化评估软件风险［13-16］。但这些方法有的只提出设想，未能给出安全性评估具体实现，有的未给出如何从失效本质或从系统元素中提取软件安全性相关因素。

针对上述问题，本文首先对软件失效本质进行探讨，分析引起软件功能执行的触发因素，即软件运行条件、软件交互模式；其次对安全性关键场景中的这些触发因素建立联系，并在此基础上提出基于运行条件关系构造交互模式依赖图的方法；最后在交互模式依赖图基础上，给出基于软件过程行为的安全性评估模型。该方法正视了软件失效本质，突破了以往把软件看作整体评估的局限性，认为软件安全性不仅与各功能安全性相关，而且与软件过程行为有关。

2 安全性关键软件失效模型

安全性是系统属性，软件本身不具备安全性，只有在系统环境下才有安全性［12］，评价软件安全与否只有将其置于系统环境中才有意义。安全性关键软件风险源于系统设计范围所规定的条件，软件在支持安全性关键的系统功能实现时功能失效［16］。

这种系统设计范围规定的条件，即安全性关键软件交互模式（SCSWIM），支持安全性关键系统功能实现的是安全性关键软件功能（SCSWF）。基于软件失效本质及上述风险致因，提出失效模型，如图1所示。

图1 安全性关键软件失效模型

在图1中，M1～Mn是SCSWIM；F1～Fn是系统期望的SCSWF。两者在系统设计范围中一一对应，图中虚线表示一一对应，错误源为软件运行时不能给予系统预期响应的原因，失效点为软件失效发生的位置，失效发生与否通过输出与预期功能是否匹配来判断。软件有2种失效方式：

（1）由错误源 1（Input1）引起，失效过程如“Input1→软件内部交互1→Output1”，表示软件在设计时未充分考虑SCSWIM（如Mi）导致Input1与软件内部交互后无法给出与预期功能匹配的输出；

（2）由错误源 2（Input2）引起，失效过程如“Input2→软件内部交互2→Output2”，表示在软件设计时已完整考虑SCSWIM（如Mj），但软件内部设计时引入缺陷（如需求传递错误、编码错误等）的暴露导致无法给出与预期功能匹配的输出。因此，安全性关键软件失效是因为：

（1）系统需求到软件需求时，SCSWIM提取不完整；

（2）软件某SCSWIM下，内部设计时缺陷引入。

3 软件交互行为影响因素

上述失效模型给出2种失效成因，其表现形式均为某SCSWIM下，相应SCSWF失效，这表明失效是有条件的，与软件交互模式及内部交互同时有关，则在测试并评估一个软件安全性时，可观察软件在各个交互模式下的行为与预期行为是否一致。即什么是交互模式，以及如何表示交互模式，如图 2所示。

图2 软件交互行为示例

5种模式表示为：

（1）状态1-1∨状态1-2⇒软件交互模式1

（2）状态1-3∨状态2-1⇒软件交互模式2

（3）状态1-3∧ 状态2-2∧ （状态 3-1∨ 状态3-2）⇒软件交互模式2

（4）状态1-3∧状态2-2∧状态3-3⇒软件交互模式3

（5）状态1-3∧状态2-2∧状态3-4⇒软件交互模式3

被评估软件与3个交互个体间有3种交互模式，每个交互个体有多种状态表示其行为特征，同一交互个体的状态间互斥；不同交互个体的状态组合能够触发软件不同的交互模式。在 5种模式中，模式（1）表明状态1-1发生或者状态1-2发生可以触发交互模式 1；模式（3）表明状态 1-3，2-2，3及3-1，3-2中的任一个，三者同时发生可以触发交互模式2；其中诸如“状态1-1”、“状态1-2”这种用来描述与软件交互的个体的某种状态或行为，称为软件运行条件，从某种意义上来讲，在其他条件满足时，它是触发软件某种功能的基本条件；模式（2）和模式（3）都能触发软件交互模式，但两者不能同时发生，称模式（2），模式（3）中这种条件为软件基本交互模式，是触发条件某种功能的基本事件；软件交互模式由一种或多种基本交互模式引起，是触发某种功能的基本事件集合；另外，根据失效模型知，软件交互模式下软件完成对应的功能。

本文提出软件交互行为模型（Software Interbehavior Model，SIBM），其组成元素主要有：软件运行条件，软件交互模式及软件功能，也是软件交互行为的影响因素，可从安全性关键场景中提取，这种关键场景生成工具及方法主要有动态流程模型、事件序列图、事件树等［12-13］。然后依据 SIBM中软件交互模式、运行条件及功能之间的关系，从条件依赖图（Conditional Dependence Graph，CDG）生成交互模式依赖图（Interactive Pattern Dependency Graph，IMDG），最后基于IMDG提出安全性评估模型。本文的软件、场景、运行条件、交互模式、功能等皆是安全性领域相关的。

3.1 软件交互行为模型的定义

软件交互行为模型（SIBM）用以描述软件与其交互个体间的交互行为，交互体满足什么情况下，可以触发软件不同功能，其定义如下：

（1）软件运行条件类集 RTS=｛R1，R2，…，Ri，…，Rn｝；

（3）软件基本交互模式集 BMS=｛M1，M2，…，Mi，…，Mm｝；

（4）软件基本交互模式 Mi=（Ai1，Ai2，…，Aij，…，Ain），其中，Aij⊆Rj，若Aij=Rj，Aij用@表示；

（5）软件交互模式集IS=｛I1，I2，…，Ii，…，Ik｝，Ii⊆BMS；

（6）软件功能集合FS=｛F1，F2，…，Fi，…，Fk｝，Fi与Ii存在一一对应关系，用Fi↔Ii表示。

3.2 SIBM性质

定义1 设2个软件基本交互模式A，B，其中，A=（A1，A2，…，An），B=（B1，B2，…，Bn），Ai，Bi⊆软件运行条件集Ri：

（1）∀Ai，Ai⊆Bi，称A包含于B，或B包含A；

性质1 与软件交互的个体在同一时刻只能有一种运行条件，因此有：任一软件运行条件集 R，任2个软件运行条件ri，rj∈R，则ri∧rj=Φ，即同一软件运行条件集中的2个不同运行条件的发生是互斥的。

性质2 软件基本交互模式集BMS中任2个软件基本交互模式Mi，Mj必须满足Mi不包含Mj，且Mj不包含Mi；即基本交互模式集中的任意2个基本交互模式之间不能相互包含。

性质3 任一基本交互模式不能属于不同的交互模式，因此软件交互模式集IS中任2个软件交互模式Ii，Ij，满足Ii∩Ij=Φ。

性质4 任一软件基本交互模式 Mi=（A1，

A2，…，Aj，…，An），Aj⊆软件运行条件集Rj，若Ai= @，表明Ri不影响软件基本交互模式A的发生；A可化简，即将所有@省略，如（Ak，@）=（Ak），其中，Ak≠@。

3.3 SIBM实例说明

本节以姿势控制系统（Attitude Control System，ACS）介绍三元素及三者关系，如图3所示。ACS由传感与命令功能和推进功能控制卫星体姿势，主要由内置软件、3个高度精确的回旋仪传感器、2个较精确的行星跟踪器传感器共同完成传感与命令功能。

图3 姿势控制系统

内置软件根据传感器读数计算卫星到预期姿势所需的控制推动的命令参数，以保证推进功能正确实现。它以正常模式和应急模式2种方式与系统元素交互，如图4所示，对应功能设为正常功能和应急功能，其中，与门表示∩；或门表示∪。由图可知，2个及以上回旋仪传感器可用时软件进入正常模式，选择2个可用的进行高度精确计算；仅1个回旋仪传感器可用时软件进入应急模式，选择一个可用卫星跟踪器传感器与唯一可用的回旋仪传感器进行较精确的计算。因此，当3个回旋仪传感器均不可用，或者2个回旋仪传感器不可用且卫星跟踪器传感器均不可用时，软件进入不可控模式。无论哪种软件，均有包含这种模式，其发生率极低，一般考虑软件不处理仅给出提示，让人员干预。一旦这种模式发生，软件便失去安全控制作用。

假设用GFNi（i=0，1，2，3）表示回旋仪传感器失效数为 i的条件发生事件对应的布尔变量，SFNi（i=0，1，2）表示卫星追踪器传感器失效数为i的条件发生事件对应的布尔变量；Nor，Con，Unc分别表示软件正常、应急及不可控交互模式；FUNNor，FUNCon，FUNUnc分别为3种模式对应的软件正常功能、应急功能及不可控功能，其中不可控功能直接导致ACS失效，如图4所示。

图4 ACS功能与传感器交互关系

则ACS的交互模型行为定义为：

（1）运行条件类集RTS=｛R1，R2｝；

（2）运行条件集R1=｛GFN0，GFN1，GFN2，GFN3｝，运行条件集R2=｛SFN0，SFN1，SNF2｝；

（3）基本交互模式集BMS=｛M1，M2，M3，M4｝；M1=（｛GFN0，GFN1｝，@）=（｛GFN0，GFN1｝），M2=（｛GFN2｝，｛SFN0，SFN1｝），M3=（｛GFN2｝，｛SFN2｝），M4=（｛GFN3｝，@）=（｛GFN3｝）；

（4）软件交互模式集 IS=｛Nor，Con，Unc｝；Unc=｛M1｝=｛（｛GFN0，GFN1｝）｝，Con=｛M2｝=｛（｛GFN2｝，｛SFN0，SFN1｝）｝，Unc=｛M3，M4｝=｛（｛GFN2｝，｛SFN2｝），（｛GFN3｝）｝；

（5）软件功能集合FS=｛FUNNor，FUNCon，FUNUnc｝，满足FUNNor↔Nor，FUNCon↔Con，FUNCon↔Unc。

4 符号定义

本文提出2种依赖图：条件依赖图和交互模式

依赖图。在依赖图的构造过程中，为方便说明，定义一些符号并描述其含义。

4.1 相关符号

A，B表示为同一属性的事件；事件为条件、基本交互模式或交互模式发生；运行周期表示软件所在系统运行一次所需时间，则：

（1）PS（A）：A的启动率，表示系统启动时某事件发生的概率；

（2）PC（A）：A的触发率，表示运行周期内，由其他事件迁移引起的发生概率，而非启动时发生率；

（3）PC（B/A）：A到B的迁移率，表示运行周期内，事件 A发生后B发生的概率，称 A到B的迁移率；

（4）PC（A，B）：为A对B的贡献率，表示运行周期内，事件A直接迁移导致事件 B发生的概率，称A→B的贡献率，等于A的发生率与A到B的迁移率之积；

（5）PH（A）：A的发生率，表示运行周期内，事件发生概率，由启动率和触发率构成；

（6）PU（A）：A的非迁移率，表示运行周期内，事件发生后不向其他条件发生迁移的概率。

4.2 依赖图性质

本文中的2种依赖图主要是由节点和边构成的有向图。这2种依赖图符合马尔科夫链［17］的一些性质：

性质5 任一节点到其他各节点的一步转移概率之和为1。

5 条件依赖图

一个条件依赖图（Conditional Dependence Graph，CDG）描述一个运行条件类集中各条件的关系，由一个或多个子条件依赖图（Sub Conditional Dependence Graph，SCDG）构成，每个SCDG由开始节点、终端节点、条件节点和有向边构成，描述与软件交互的某种系统元素可能发生的状态、状态变化及相应的概率。

5.1 SCDG定义

定义2 子条件依赖图SCDG=＜N，E，s，t＞。其中，＜N，E＞是一个有向图；s是开始节点；t是终端节点；N=｛n｝是一系列条件节点的集合；E=｛e｝是有向边的集合，示例图如图 5所示。其中，节点ni=｛Ri｝；Ri表示运行条件i；ek=（（A，B），Mk）表示连接节点A，B的有向边；Mk为边上标注，连接s与Ri的有向边上标注的是Ri的启动率；连接Ri与Rj的有向边上标注的是Ri到 Rj的迁移率；若无连接Ri与Rj的有向边，则Ri到Rj迁移率为0；连接Ri与t的有向边上标注的是Ri的非迁移率。

图5 SCDG示例图

5.2 SCDG性质

已知软件运行条件集Ri=｛ri1，ri2，…，ris｝；以此构造SCDG，不考虑依赖图中存在环路的情况，即不考虑硬件或软件等自我修复的可能，在这种情况下依赖图满足以下性质：

性质6 由性质5知：s节点到各条件节点的转移概率和为1，即各条件的启动率和为1。

性质7 由性质5知：任一条件节点到其他节点的迁移率之和为1。

性质8 若依赖图中存在一种条件节点，该节点不能迁移到其他条件节点，则该节点属于“不可控”运行条件节点，为最不安全的运行条件，一旦发生，无法恢复到更安全的运行条件，则非迁移率为1。

5.3 SCDG规则

规则1 任2个不同软件运行条件Rij，Rik∈软件运行条件集Ri，前者对后者的贡献率满足：

规则2 任一软件运行条件Rij∈软件运行条件集Ri，满足：

规则3 任一软件运行条件Rij∈软件运行条件集Ri，满足：

6 基本交互模式相互关系

软件基本交互模式之间的相互关系主要起到过渡作用，此处定义了软件基本交互模式必须满足的性质，即相关概率的计算规则，目的是通过此处计算及软件交互模式与基本交互模式之间的包含关系获得各软件交互模式之间的关系。

6.1 基本交互模式集性质

一个软件的基本交互模式集应该包含了所有该软件可能的不重复的（不相互包含）运行状态组合，因此，满足下面的性质：

设一个软件基本交互模式集为 BMS=｛M1，M2，…，Mi，…，Mm｝，则有：

6.2 单类条件的基本交互模式规则

只有一种条件集的软件基本交互模式规则的定义如下：

规则4 若不含@的基本交互模式Mi=（Aik），Aik⊆软件运行条件集 Rk，Aik=｛rka1，rka2，…，rkaχ｝，Rk=｛rk1，rk2，…，rks｝，则：

规则5 若不含@的基本交互模式Mi，Mj，满足Mi=（Aik），Mj=（Ajk），Aik，Ajk⊆软件运行条件集Rk，Aik=｛rka1，rka2，…，rkaχ｝，Ajk=｛rkb1，rkb2，…，rkby｝，则：

6.3 多类条件的基本交互模式规则

由多种条件集构成的软件基本交互模式规则的定义如下：

规则6 若不含@的基本交互模式Mi=（Aia1，Aia2，…，Aiaχ），则：

规则7 若不含@的基本交互模式 Mi，Mj，Mi=（Aia1，Aia2，…，Aiaχ），Mj=（Ajb1，Ajb2，…，Ajby），则：

7 交互模式依赖关系

7.1 IM DG定义

定义3 交互模式依赖图IMDG=＜N，E，s，t＞，其中，＜N，E＞是一个有向图；s是开始节点；t是终端节点；N=｛n｝是一系列交互模式节点的集合；E=｛e｝是有向边的集合。IMDG示例图如图6所示。节点ni=｛IMi，FUNi｝，其中，IMi表示交互模式i；FUNi表示软件功能i，IMi与FUNi对应；ek=｛（A，B），Mk｝表示连接节点A，B的有向边；Mk为边上标注。连接s与IMi的有向边上标注为IMi的启动率，连接IMi与IMj的有向边上的标注为IMi到IMj的迁移率，若无连接IMi与IMj的有向边，则IMi到IMj迁移率为0；连接IMi与t的有向边上的标注为IMi的非迁移率。

图6 IM DG示例图

7.2 IM DG性质

已知软件交互模式集IS=｛I1，I2，…，Ii，…，Is｝，以此构造IMDG，满足以下性质：

性质9 由性质5知，各交互模式节点的启动率之和为1：

性质10 由性质5知，任一交互模式节点的非迁移率与其到其他交互模式节点的迁移率之和为1：

7.3 IMDG规则

规则8 设一个软件的基本交互模式集为BMS=｛M1，M2，…，Mm｝，一个软件交互模式 Ii⊆BMS，设Ii=｛Ma1，Ma2，…，Mas｝，a1，a2，as=1，2…，m且各不相等，则：

规则9 设一个软件的基本交互模式集为BMS=｛M1，M2，…，Mm｝，软件交互模式Ii，Ij⊆BMS，设Ii=｛Ma1，Ma2，…，Mas｝，a1，a2，…，as=1，2，…，m且各不相等，Ij=｛Mb1，Mb2，…，Mbt｝，b1，b2，bt=1，2，…，m且各不相等，则：

规则10 设一个软件的基本交互模式集为BMS=｛M1，M2，…，Mm｝，软件交互模式Ii，Ij⊆BMS：

8 基于过程行为的评估模型

安全性存在2种常见的定义，一个为软件在运行过程中不引起系统危害（hazard）的能力［3］，另一个为软件在系统环境中运行不产生不可接受的风险［18］。根据这2种不同定义，一般有 2种定量评估软件安全性的指标：传统的可靠性指标（如事故率、安全可靠度、平均事故间隔时间等）和风险指数。前者未考虑失效的后果，而后者不仅考虑了不安全性因素发生率，同时考虑了不安全因素发生引起的后果。

8.1 软件风险评估模型

本文将使用风险指数作为安全性评估的指标，风险通常被定义为所有危险可能性与危险后果严重性乘积之和。文献［19］由软件失效导致Hazardj引起的风险为：

其中，ε（Hazardi）表示Hazardi的风险指数。

因此，软件总风险为：

其中，上标NPP表示非软件过程行为评估方式。该方法是基于测试的运行剖面的，而本文方法是基于软件过程行为的。不同交互模式的变化对应不同的软件过程行为，一种交互模式发生即对应一种软件功能的执行，则一种可能的交互模式的组合代表软件运行的一种过程行为。

由于软件运行中系统环境因素的不确定性，导致软件在一次运行中可能经历多种交互模式，则软件一次运行存在多种可能的过程行为。每种过程行为的发生将给系统带来不同的后果，即有不同的风险指数，如飞控系统在正常模式和异常模式下飞控指令计算采用的参数来源不同，则计算准确度不同，存在的风险则不同。这表明在软件运行周期

其中，PPj表示第j个过程行为；上标PP表示软件过程行为的评估方式；Pfailed表示某行为过程对应的软件失效率。

此外，对风险指数可通过专家经验结合软件复杂性分析、测试覆盖率评价和失效模式与影响分析等方法的分析结果指定，风险指数应该在 0～1之间，值越高，说明风险越大。

8.2 软件过程行为定义

设交互模式集合 IS=｛I1，I2，…，IS｝，则软件过程行为PPi=［Ia1，Ia2，…，Iat|Ii∈IS］表示软件交互模式以 Ia1，Ia2，…，Ian顺序依次发生，一种软件存在多种软件过程行为，每种软件过程行为以一定的概率发生。

基于IMDG，可以找到所有可能的软件过程行为并能根据图中参数计算出各种过程行为发生概率，各过程行为的发生率计算规则如下：

一个软件的所有软件过程行为能描述所有该软件可能的软件行为，则各软件过程行为发生率之和应满足：

对任一过程行为下软件的失效率，只与该过程行为的最后一个软件交互模式下软件功能失效率有关，则失效率满足：

其中，Funat为Iat下对应的软件功能。

如何根据IMDG找到所有可能的软件过程行为，方法如下：

（1）若交互模式 IMj满足 PS（IMj）＞0且存在

IMk使得PC（IMk/IMj）＞0，则存在软件过程行为［IMj］与［IMj，…］；

（2）若交互模式IMj满足PS（IMj）＞0且不存在IMk，使得PC（IMk/IMj）＞0，则只存在软件过程行为［IMj］；

（3）设2个交互模式IMj，IMk，若PC（IMj/IMk）＞0且PU（IMk）＞0，则存在软件过程行为［…，IMk］与［…，IMk，IMj］；

（4）设2个交互模式IMj，IMk，若PC（IMk/IMj）＞0且PU（IMk）=0，则只存在软件过程行为［…，IMj，IMk］。

该方法不仅考虑了软件安全性相关功能失效的概率及对应后果的严重性，相比之下还考虑了软件在运行中所有可能的过程行为，更好地评估了软件行为的安全性。

9 实例分析

9.1 实例1

该实例基于上述规则从一个确定的CDG构建IMDG，通过证明各依赖图均满足依赖图性质来证明IMDG生成过程的正确性及可行性。

图7为3.2节中ACS的CDG，由SCDG1和SCDG2（满足性质SCDG性质）构成，设条件GFNi表示Gyro失效数为i（i=0，1，2，3）的软件运行条件；SFNi表示S-Tracker失效数为i（i=0，1，2）的软件运行条件，S1和E1，S2和E2分别是各自的初始节点和终端节点，已知ACS系统的交互模式行为定义如3.3节所述，已知各软件运行条件启动率、迁移率、非迁移率满足：

图7 ACS对应的条件依赖图

各条件的发生率满足：

经检验，满足IMDG性质。

因此，根据描述各软件运行条件依赖关系的CDG及软件交互行为模型（SIBM），可以根据本文定义的相关规则正确地生成IMDG，识别各软件交

互模式的关系，从而确定各功能的关系。ACS的交互模式依赖图如图8所示。

图8 ACS的交互模式依赖图

9.2 实例2

根据软件过程行为提取的方法及其发生率计算方法，实例1中对应的所有软件过程行为及相关参数如表1所示。

表1 ACS过程行为清单

设Nor，Con下软件功能失效率为0.001，0.000 1；Unc表示软件无法控制，则失效率为1。

发生率是按照发生率计算规则获得，根据软件过程行为提取的方法可以列举所有软件相关的过程行为，则软件整体风险为：

观察各过程行为的风险值，可以发现影响整体风险值降低的瓶颈因素为包含Unc的过程行为，如［Nor］，［Nor，Unc］，这意味着影响软件风险的因素不仅在于软件内部结构，也有部分原因在于外界系统不安全状态的发生率过高，此时为提高系统安全性更应该注重对于软件交互的环境安全性的提高。

在Unc对系统安全性影响可以忽略的情况下，可以发现Nor和Con中Nor交互模式下软件失效的风险比Con大很多，为了较快地提高软件的安全性，在各过程发生率不变的前提下，需要采取措施降低Nor对应功能的失效率。

10 结束语

安全性关键软件是安全性系统的重要组成部分，其行为直接影响生命财产安全，本文对该类软件提出安全性评估方法。首先基于软件失效本质并提出软件失效模型，然后在对软件交互行为理解的基础上提出软件交互行为模型（SIBM）并探讨软件运行条件、软件基本交互模式、交互模式及功能之间的关系，同时以条件依赖图（CDG）描述运行条件之间的关系，基于SIBM和CDG生成软件交互模式依赖图（IMDG）的方法，最后在IMDG提出基于过程行为的安全性评估模型。基于该模型，本文以姿势控制系统（ACS）为实例生成对应的SIBM、CDG及IMDG，并识别出所有软件过程行为及对应发生率、失效率、风险，最后计算得到软件整体风险。经实例证明，该评估方法能方便地识别影响系统安全性的瓶颈，这种瓶颈可能是软件自身设计或是与软件交互的环境，通过这种方法可以很方便地识别软件安全性设计的不足或软件交互环境安全性设计的不足。

此外该方法还有以下优点：（1）运行条件是生成测试用例的基本元素，交互模式可作为用例分区的一个标准；（2）各运行条件（硬件失效情况等）的发生率等参数可从系统元素历史数据获得，则软件安全性测试可与系统测试并行，时间少并相互反馈；（3）不需用传统测试剖面生成测试用例，而是对不同功能基于其运行条件生成用例进行测试，避免随机性引起不平衡性，防止低发生率的安全性功能测试被遗漏；因此，该模型具有一定的可行性，在后续研究中，将进一步探讨该模型在安全性测试指标分配中的应用，对安全性测试有一定的指导作用。

［1］ G-14 Americas Aerospace Quality Standards Committee. AS9100C-2009 Quality Management Systems-requirements for Aviation，Space and Defense Organizations［S］.2009.

［2］ RTCA.DO-178C Software Considerations in Airborne System s and Equipment Certification［Z］.Radio Technical Commission for Aeronautics，Inc.，2008.

［3］ MIL-STD-882D Standard Practice for System Safety Program Requirements［Z］.Department of Defense，USA Military，1996.

［4］ 国防科学技术工业委员会.GJB Z102-97软件可靠性和安全性设计准则［M］.北京：国防工业出版社，1998.

［5］ 国防科学技术工业委员会.GJB Z142-2004军用软件安全性分析指南［M］.北京：国防工业出版社，2004.

［6］ 国防科学技术工业委员会.GJB 900-90系统安全性通用大纲［M］.北京：国防工业出版社，1991.

［7］ Ma Sasa，Liu Dongqing，Xu Aihua.Research on Safety Evaluation Method of Military Software［C］// Proceedings of the 8th International Conference on Reliability，Maintainability and Safety.New York，USA：ACM Press，2009：718-722.

［8］ 严 黎，吴芳美.铁路车站计算机联锁软件的安全性评估策略［J］.同济大学学报，2002，30（9）：1116-1120.

［9］ 王小丽，徐中伟，杜军威.改进的J-M模型及其在软件安全性评估中的应用［J］.小型微型计算机系统，2008，29（2）：269-273.［10］ 陈德金.军用实时软件失效机理及可靠性提高途径初探［J］.系统工程与电子技术，2000，22（4）：91-93.

［11］ Garrett C，Apostolakis G.Context and Software Safety Assessment［C］//Proceedings of the 2nd Workshop on Human Error，Safety and System Development.Berlin，Germ any：Springer，1998：46-57.

［12］ Houtermans M，Apostolakis G，Brombacher A，et al.The Dynamic Flowgraph Methodology as a Safety Analysis Tool：Programmable Electronic System Design and Verification［J］.Safety Science，2002，40（9）：813-833.

［13］ NASA.NASA/SP-2011-3421 Probabilistic Risk Assessment Procedures Guide for NASA Managers and Practitioners［Z］.NASA Headquarters，2011.

［14］ Ayyub B M，Beach J E，Sarkani S，et al.Risk Analysis and Management for Marine System s［J］.Naval Engineers，2008，114（2）：181-206.

［15］ EPRI/NRC-RES Fire PRA Methodology for Nuclear Pow er Facilities［Z］.Office of Nuclear Regulatory Research，U.S.Nuclear Regulatory Commission，2005.

［16］ 赵丽艳，顾基发.概率风险评估（PRA）方法在我国某型号运载火箭的安全性分析中运用［J］.系统工程理论与实践，2000，（6）：91-97.

［17］ 熊 冰，郭 兵，沈 艳.基于马尔科夫链的构件化嵌入式软件能耗估算模型［J］.小型微型计算机系统，2012，33（3）：655-659.

［18］ Leveson N G.Software Safety：Why，W hat，and How［J］.ACM Computing Surveys，1986，18（2）：125-163.

［19］ 覃志东.高可信软件可靠性和防危性测试与评价理论研究［D］.成都：电子科技大学，2005.

编辑 顾逸斐

An Evaluation Model of Safety-critical Software

JIANG Mengxia，JIANG Guohua
（School of Computer Science and Technology，Nanjing University of Aeronautics and Astronautics，Nanjing 210016，China）

Safety-critical software behavior directly affects life and property safety，so a quantitative evaluation model is indispensible to reflect its safety.Similarities are between safety and reliability，traditional safety assessment method always takes software as a whole to evaluate through improved reliability models，but it ignores failure nature and can not evaluate behavior safety.Based on the study of software failure nature and safety-critical scenario，Software Interbehavior Model（SIBM）is proposed，and tells how to generate Interraction Mode Dependency Graph（IMDG）through relationships of software operation conditions.A safety evaluation model based on process behavior is proposed，it identifies all process behaviors with incidence rates and failure rates，risk indexes are given to every process behavior，then total risk index can be calculated.

safety-critical software；Software Interbehavior Model（SIBM）；Interraction Mode Dependency Graph（IMDG）；safety evaluation model；software process behavior

姜梦霞，江国华.一种安全性关键软件的评估模型［J］.计算机工程，2015，41（10）：130-138，143.

英文引用格式：Jiang Mengxia，Jiang Guohua.An Evaluation Model of Safety-critical Software［J］.Computer Engineering，2015，41（10）：130-138，143.

1000-3428（2015）10-0130-09

A

TP311

姜梦霞（1989-），女，硕士，主研方向：软件安全；江国华，副教授。

2014-10-10

2014-11-12E-mail：1024775461@qq.com