软件失效模式与影响分析在武器火控软件中的应用研究

2017-11-30赵昶宇

科技与创新 2017年15期

关键词：可靠性武器安全性

赵昶宇

（天津津航计算技术研究所，天津300308）

软件失效模式与影响分析在武器火控软件中的应用研究

赵昶宇

（天津津航计算技术研究所，天津300308）

软件失效模式与影响分析（SFMEA）是将传统的基于硬件的FMEA技术应用于软件，对软件以及软件所嵌入的系统所进行的一种可靠性分析方法。在研究SFMEA原理的基础上，结合武器火控软件的特点，提出了一种适合该类软件的SFMEA分析方法和实施流程，并成功地应用于某型号武器火控软件的可靠性与安全性分析中，提出了工程准则以及实施过程中的注意事项。

软件失效模式；嵌入式系统；软件可靠性；武器火控软件

软件失效模式及影响分析（SFMEA）是一种传统的可靠性和安全性分析方法，应用在安全关键级别比较高的软件中，基本思想是在软件研发的不同阶段，通过识别软件失效模式，研究分析各种失效模式产生的原因及其造成的影响，寻找消除或减少其有害影响的措施。然而，SFMEA在实践中开展的并不顺利，一方面，软件开发人员对可靠性、安全性理论知识缺乏了解，相应的指导步骤和方法也不具体，实施起来有一定的难度；另一方面，实施SFMEA的工作量较大，实施过程也较为烦琐，实施成本较高。本文旨在通过研究SFMEA的实施要求，提出工程准则与注意事项，使得SFMEA方法具有可操作性，步骤具有可指导性，效果具有规范性。

1 SFMEA概述

SFMEA是一种“自底向上”的分析，最底层一级的影响逐级向上传播，直到系统的最顶层。通过识别软件失效模式，分析失效机理，查找失效原因，评价软件失效对系统造成的影响，并提出有针对性的改进措施。

SFMEA关心的是“如果软件的部件运行不正确会带来怎样的影响”“对软件的部件进行失效假设，然后分析到系统级看导致的后果是什么”。根据分析阶段和对象的不同，可将SFMEA分为系统级SFMEA和详细级SFMEA。系统级SFMEA在软件需求分析和概要设计阶段进行，详细级SFMEA主要在详细设计完成以后或者编码阶段。

2 SFMEA在武器火控软件中的应用

2.1 武器火控软件的特点

武器火控软件负责完成武器发射准备和发射控制、武器系统检查和维护任务，是武器控制系统的核心，其特点如下：①嵌入式。武器火控软件都是和所属的计算机系统一起嵌入到整个型号系统中联合工作的，该类软件和硬件是密不可分的。②软件规模大且结构复杂。随着武器火控系统的功能越来越强大，其软件代码的规模也在急剧增加，且软件算法的复杂度、软件架构的复杂度也呈现上升趋势。③高可靠性和高安全性。武器发射任务的高风险性决定了作为控制系统核心的武器火控软件必须要求高可靠性和高安全性。④强实时性。武器控制系统对实时性要求很高，这就要求武器火控软件能够在第一时间在严格的时限内作出响应，且响应时间不应随负载的增加而延长。⑤高精度和严格的时序要求。此外，武器火控软件还具有硬件资源受限、长寿命、运行环境恶劣等特点。

武器火控软件的上述特点以及日益增长的型号任务需求，给武器火控软件的研制提出了更高的要求，使得我们不得不解决在软件研制过程中暴露出的下列问题：①软件研制前期的可靠性和安全性分析工作不足或缺乏，导致前期的软件缺陷不易被发现，严重影响后续软件研制的质量和进度；②缺乏系统、规范的可靠性和安全性分析方法和相关工具支持，主要依赖设计师的经验来进行软件可靠性和安全性设计；③对于软件的关键失效模式和薄弱环节未能有效识别，同时未进行有效的跟踪和控制，造成测试用例和软件审查的针对性不强。因此，只有从软件研制早期就引入并贯穿至整个研制过程的可靠性安全性分析方法，才能从源头上保证武器火控软件这类安全关键软件的可靠性。

2.2 武器火控软件的SFMEA方法

本文在前人研究成果的基础上，结合武器火控软件的特点，研究了适用于该类软件的SFMEA方法，下面详细说明针对武器火控软件进行SFMEA的实施流程和分析方法[3]。

2．2．1 关键安全部件识别

可以从以下几个方面鉴别软件是否为安全关键性软件：①控制程度，即软件在系统危险控制上的参与度。②危险性。能导致危险发生的软件是安全关键性的软件，比如需要识别危险条件，实现自动的安全控制，提供安全关键性信息，禁止危险事件发生的软件。③复杂度。越复杂的软件越危险，随着软件用于控制危险的安全性相关需求的增长，软件也随之复杂。④时效性。控制危险的软件实时性是一个关键因素，软件必须在危险发生之前就识别危险，并采取措施。

2．2．2 选取约定层次

在定义软件约定层次时应根据实际需要，重点考虑关键、重要功能的软件部件或模块。划分约定层次应注意以下3个方面：①当分析的软件比较复杂时，应按照系统总体单位和软件开发单位的技术责任关系明确开展SFMEA的软件范围。系统总体单位首先应将研制的系统定义为初始约定层次，并对其他配套研制单位（包括软件开发单位）提出最低约定层次的划分原则。②约定层次划分得越多越细，SFMEA的工作量就越大。对于采用了成熟设计、继承性较好且经过了可靠性、维修性和安全性等良好验证的软件，其约定层次可划分得少而粗；反之，可划分得多而细。③每个约定层次的软件应有明确定义，当约定层次的级数较多（一般大于3级）时，应自下而上按约定层次的级别不断分析，直至初始约定层次相邻的下一个层次为止，进而构成完整的SFMEA。对最低约定层次按以下原则划分：①所有可获得分析数据的软件单元中最低的层次，它能有完整的输入，或能对应到软件中的一个或几个有一定功能的函数；②当软件中某模块的失效将直接导致灾难的（I类）或致命的（II类）后果时，则最低约定层次至少划分到这一模块所在的层次；③确定或预期需要单元测试的最低层次，这些软件单元可能导致临界的（III类）或轻度的（IV类）故障。

2．2．3 失效模式分析

对于系统级SFMEA，根据软件功能描述、失效判据要求，确定所有可能功能的失效模式；对于详细级SFMEA，根据模块中变量的类型特征，确定所有可能变量的失效模式。需要注意以下事项：①每个模块的每个失效模式是单一的，避免复合的失效模式，各个失效模式之间是互相独立的，彼此不相关；②对失效模式的表达要正确且清楚，不要把被分析对象的外部输入错误作为失效模式，实际上这是输入模块的某种失效模式对被分析模块的失效影响，不是被分析对象本身发生的失效模式；③不要把被分析对象内部的组成变量、算法的某种失效模式当作系统级分析对象的一种失效模式，其实这是详细级分析的变量的失效模式，而不是模块功能的失效模式。

2．2．4 失效原因分析

分析软件的失效原因时，应注意以下几点：①软件失效原因首先在自身范围查找，大多数为开发过程中的“设计缺陷”。②在自身范围查找完后，应考虑软件相邻结构层次的关系，在分析失效原因时，可通过下一个或更深一个层次失效模式去寻找。③当某个失效模式存在2个以上失效原因时，在“失效原因”栏中分别注明，要对每个原因进行独立分析；而当某个失效模式是由2个及以上的失效原因共同导致时，这些失效原因应该列在一起。④失效模式一般是可观察到的失效表现形式，而失效模式直接原因或间接原因是设计缺陷、外部因素；失效原因的描述应该采用精确的工程术语表述。

2．2．5 失效影响分析

失效影响是失效模式导致的各种后果，应注意以下事项：①分析失效影响时，应明确层次间的传递关系，应把握程序模块之间的功能联系而不是简单的结构关系。②当同一部件具有许多功能时，必须考虑每种功能可能的失效模式。软件失效不仅包括功能失效，还包括性能失效。③对于采用了冗余设计、备用工作方式设计或者故障检测与保护设计的软件，在SFMEA中应暂不考虑这些设计措施而直接分析软件故障模式的最终影响。

2．2．6 改进措施分析

SFMEA的目的在于尽早发现潜在的问题，并采取相应的改进措施，从而提高软件的可靠性和安全性。改进措施可按如下优先顺序加以考虑：①更改软件设计，消除导致关键性硬件故障的原因；②若不能消除，加强软件对异常情况的处理（比如容错技术），降低故障影响的严重程度；③在软件执行关键性的功能时，应使程序具有自检查的功能，降低故障的检测难度，提高可检测性。

2．2．7 形成分析报告并建立失效模式库

将以上结果形成分析报告，这部分工作可通过专门的计算机辅助分析工具进行，并进行相关失效数据的统计和图表分析。同时，利用计算机技术将失效数据保存并整理，通过不断积累和丰富失效模式库的数据，可为今后的分析工作提供重要的参考价值。