软件可靠性分析技术

雷云 陈圣斌 丁杰

（中国直升机设计研究所，江西景德镇 333001）

0.引言

本文研究对象是应用领域有经验机构开发的重大软件和其所经受的试验以及其他演示/验证技术。该种软件不是因编制101程序太繁琐而引发编码差错造成失效或故障。硬件的发展在一定程度上降低了“有效编程”在使用处理步骤和内存时强调经济的要求。自动程序生成器、高级语言和先进的编译程序，实际上已经消除了编码差错。这样，防止软件故障就意味着关注需求阶段和设计阶段潜在的或可能的差错源。当软件遇到了未经试验的条件或者已经试验但并未确认失效的状态时，软件就会故障。因此，该文重要的一部分就是要认可以下两方面中的关键功能：它们干扰了提供基本服务；它们引起不安全状态。确认这些领域的模式是故障树分析、故障模式和影响分析。对于这两种分析，本文将以实例详细说明。

1.使用剖面

1.1 定义

（1）软件失效（software failure）— 软件失效（另一种称呼即称之为缺陷）即是软件有缺陷或差错（这可能是因错误编码、设计差错或需求和规范问题产生的），这种缺陷或差错有可能引起软件故障或内部缺陷。（2）使用（operation）— 使用定义为主要的逻辑工作，这种逻辑工作与其他工作或任务是很不相同的，一个主要的工作或任务通常与功能需求相关。（3）使用剖面（operation profile）— 一组完整的使用和它们发生的概率。（4）否认或拒绝。当考虑减少软件相关故障时，人们需对故障进行限止和按优先顺序处理。是考虑故障导致降低可靠性和使用性还是关注故障可能引起灾难性/重大的系统故障，这二者之间是排它性的。

1.2 研发使用剖面所需的步骤

开发使用剖面是一循序渐进的过程。（1）确定使用。通常是根据参与者（系统用户和系统操作人员）列表来完成。（2）确定第一步所确定的每一项使用的发生率。根据系统类型，以各种方法收集发生率。如果系统是在现有系统上改进，那么可使用现有系统的实际应用剖面。如果是一新的系统，便可从相似系统和从将要实现自动化的手动系统中收集使用信息。其使用的发生可以是近似值，并且随着新版本的发展予以修改[1]。（3）确定发生的概率。这是根据发生率来确定的，是对测试工作进行优先处理所需输入。

2.软件FMEA

2.1 软件FMEA作用

故障模式和影响分析（FMEA）的应用在硬件中是标准化的，其作用与获益是很明确的：

在确认安全性关键硬件时，FMEA是一种标准（文件）；确保审查过程的完整性；确定重大故障的发生者；验证保护和降低（故障影响）的程序；弥补系统和部件工程师之间间隙或差距。

FMEA在验证软件方面的作用和获益与硬件是很相似的。图1所示FMEA的结构形式适用于软件。软件专家负责故障定义、原因、中间级影响、部件识别（identification parts）以及软件级降低影响措施。系统工程师们的任务是确认最终影响（系统级）和故障识别及纠正措施[2]。

图1 应用于软件的FMEA结构

2.2 软件FMEA实例

以一个主/辅系统为例。这一系统可以描述为一个双余度的服务器系统，双套的无人装备系统或任何其他具有主/辅作用的余度系统。在这一实例中，主、辅系统能互换“心跳”，从而使它们能持续的实现其功能。失效的心跳将触发一个开关，于是余度或辅助系统→主系统。（跟随者→主导者；余度服务器→主服务器等）。

图2所示描述了这样一个计算机系统使用情景，它们能互换心跳。失效心跳将引起“建立作用”动作的发生，一个从“主”到“备用”作用的开关或转换也将发生。这一示例情景描述强调动作的发生，这启示人们可考虑面向对象设计。这些就是一个软件FMEA中的“部件”。

图2 主/备构型的交换心跳的2台计算机状态图

以“计数器”为对象举例，它接受心跳以及对心跳计数，同时检查连续心跳之间的时间。

计数器有下列“方法”：接受心跳；心跳计数；时间间隔开始；时间间隔结束；第二次再起动。

每一种方法有多种故障模式，在FMEA中全部都要予以分析，详见表1。

表1 计数器为对象的FMEA表

列在FMEA（表1）的最终影响，它包括主装置失效时，“无法转换”的严重结果，最终影响严酷度为Ⅰ，这是安全性危险事件。当没有故障时，这种不必要的转换也没有严重后果。必须指出，当单独考虑这一系统时，它便没有补偿措施，并且检测方法都是外部的。这样就完成了一个系统级的FMEA分析。

3.软件故障树分析

当审查安全性关键和任务关键系统时，普遍使用故障树分析（FTA）。FTA，在用于硬件时，往往是定量分析。这包括故障率，某一输入和状态的概率值，其能产生系统级的最终影响概率值。当软件处于混合状态时，通常无法定量分析，定性分析也是有效的。

3.1 软件故障树分析的简化

软件可能是遍布的、复杂的，有很多简化和方法用来使软件的故障分析能易于实现[3]。（1）规模（大小）的简化：首先审查整个系统故障树以便找到可能仅影响系统安全性的这些模块。这样仅对与故障树接口且导致严重的（安全性或任务关键）最终影响的部分进行故障树分析。（2）截去分支或支路。在达成一个逻辑上的矛盾之前（参见上面），通过包括断言或异常状态，对分析表明能导致危险的不安全状态进行检测且采取缓解措施，可以终结这些分支。（3）模板使用。FTA通过常用的语言模板（例如通过IF-THEN-ELSE block进行追溯的模板）便能使故障树分析自动化。（4）在部件级工作。这正如产生故障模式和影响分析的情况一样，在部件级的工作能简化故障树分析。

3.2 软件故障树实例

以图2描述的主/辅余度系统互换心跳的实例作简单的故障树。这一故障树是在方法层次上进行的，它表示了无法转换这一最严重的最终影响，主装置的故障没有触发所要求的开关接通到辅助装置。“无法转换”的最终影响是由于“计数器”丢失故障造成，这可能是由4种目标方法的任一个不工作造成的：接受心跳、第二次再起动、时间间隔结束或心跳计数，如图3所示。

图3 基于图2所示系统的软件FTA实例

4.总结

本文阐述了与软件相关的故障源和提出多种能减少故障（特别是严重故障）或降低它们后果的方法和策略，包括软件FMEA、软件FTA。这些方法和对策能应用于安全性/任务关键系统，或用于高可靠性系统。另外，应用于这两个领域的方法是很不同的，从可靠性定义和要实现的目标开始就要正确处理和对待。