RTCA DO-178B机载系统和设备合格审定中的软件考虑

机载系统和设备合格审定中的软件考虑

RTCA DO——178B

机载系统和设备合格审定

中的软件考虑

1

机载系统和设备合格审定中的软件考虑

签署和注记

签署

姓名 签名 2

机载系统和设备合格审定中的软件考虑

更改历史

版本号/ 修订号 更改单号 发放日期 作者 更改描述 3

机载系统和设备合格审定中的软件考虑

目录

签名和注记 .............................................................................................................................................. 2 更改历史 .................................................................................................................................................. 3

1.0 引言?????????????????????????????（9）

1.1 目的?????????????????????????????（9） 1.2 范围?????????????????????????????（9） 1.3 与其他文件的关系???????????????????????（9） 1.4 怎样使用本文件????????????????????????（9） 1.5 文件综述???????????????????????????（10） 2.0 与软件开发有关的系统情况???????????????????（10） 2.1 系统和软件生存周期过程之间的信息流??????????????（12） 2.2 失效状态和软件等级??????????????????????（13） 2.3 系统结构考虑?????????????????????????（15） 2.4 系统对用户可更改软件、可选择选项软件和商用成品软件的考虑???（16） 2.5 系统设计对外场可加载软件的考虑????????????????（16） 2.6 系统需求对软件验证的考虑???????????????????（17） 2.7 系统验证中的软件考虑?????????????????????（17） 3.0 软件生存周期?????????????????????????（17） 3.1 软件生存周期过程???????????????????????（17） 3.2 软件生存周期定义???????????????????????（18） 3.3 过程之间的转换准则??????????????????????（18） 4.0 软件计划过程?????????????????????????（19） 4.1 软件计划过程目标???????????????????????（19） 4.2 软件计划过程活动???????????????????????（20） 4.3 软件计划???????????????????????????（20） 4.4 软件生存周期环境计划?????????????????????（21） 4.5 软件开发标准?????????????????????????（22） 4.6 软件计划过程的评审和保证???????????????????（22） 5.0 软件开发过程?????????????????????????（23） 5.1 软件需求过程?????????????????????????（23） 5.2 软件设计过程?????????????????????????（24） 5.3 软件编码过程?????????????????????????（24） 5.4 综合过程???????????????????????????（25） 5.5 可追踪性???????????????????????????（26） 6.0 软件验证过程?????????????????????????（26） 6.1 软件验证过程目标???????????????????????（27） 6.2 软件验证过程活动???????????????????????（27） 6.3 软件评审和分析????????????????????????（27） 6.4 软件测试过程?????????????????????????（30） 7.0 软件配置管理过程???????????????????????（33） 7.1 软件配置管理过程目标?????????????????????（34） 7.2 软件配置管理过程活动?????????????????????（34） 7.3 资料控制类??????????????????????????（37） 8.0 软件质量保证过程???????????????????????（37）

4

机载系统和设备合格审定中的软件考虑

8.1 软件质量保证过程目标?????????????????????（38） 8.2 软件质量保证过程活动?????????????????????（38） 8.3 软件符合性评审????????????????????????（38） 9.0 合格审定联络过程???????????????????????（39） 9.1 符合性方法和计划???????????????????????（39） 9.2 符合性声明??????????????????????????（39） 9.3 提交给合格审定机构的最少软件生存周期资料???????????（39） 9.4 与型号设计有关的软件生存周期资料???????????????（39） 10.0航空器和发动机合格审定综述??????????????????（40） 10.1 合格审定基础????????????????????????（40） 10.2 合格审定的软件方面?????????????????????（40） 10.3 符合性确定?????????????????????????（40） 11.0软件生存周期资料???????????????????????（40） 11.1 软件合格审定计划??????????????????????（41） 11.2 软件开发计划????????????????????????（42） 11.3 软件验证计划????????????????????????（42） 11.4 软件配置管理计划??????????????????????（43） 11.5 软件质量保证计划??????????????????????（43） 11.6 软件需求标准????????????????????????（44） 11.7 软件设计标准????????????????????????（44） 11.8 软件编码标准????????????????????????（44） 11.9 软件需求资料????????????????????????（44） 11.10 设计说明??????????????????????????（45） 11.11 源代码???????????????????????????（45） 11.12 可执行目标代码???????????????????????（45） 11.13 软件验证用例和规程?????????????????????（45） 11.14 软件验证结果????????????????????????（46） 11.15 软件生存周期环境配置索引??????????????????（46） 11.16 软件配置索引????????????????????????（46） 11.17 问题报告??????????????????????????（46） 11.18 软件配置管理记录??????????????????????（47） 11.19 软件质量保证记录??????????????????????（47） 11.20 软件实施概要????????????????????????（47） 12.0 其它考虑??????????????????????????（47） 12.1 以前开发软件的使用?????????????????????（47） 12.2 工具鉴定??????????????????????????（49） 12.3 替代方法??????????????????????????（52）

附件A 按软件等级描述的过程目标和输出??????????????（56） 附件B 缩略语和术语汇编?????????????????????（66） 附录A DO—178文件的背景????????????????????（72） 附录B 委员会全体成员??????????????????????（75） 附录C 术语索引?????????????????????????（76） 附录D 改进建议表????????????????????????（81）

5

机载系统和设备合格审定中的软件考虑

图和表的清单

图

图1—1 文件综述?????????????????????????（11） 图2—1 在系统和软件生存周期过程之间与系统安全性有关的信息流???（12） 图3—1 使用四种不同开发顺序的软件项目的例子???????????（19） 图6—1 软件测试过程???????????????????????（30）

表

表7—1 与CC1和CC2资料有关SCM过程目标????????????（37） 表A—1 软件计划过程???????????????????????（56） 表A—2 软件开发过程???????????????????????（57） 表A—3 软件需求过程输出的验证??????????????????（58） 表A—4 软件设计过程输出的验证??????????????????（59） 表A—5 软件编码和综合过程输出的验证???????????????（60） 表A—6 综合过程输出的测试????????????????????（61） 表A—7 验证过程结果的验证????????????????????（62） 表A—8 软件配置管理过程?????????????????????（63） 表A—9 软件质量保证过程?????????????????????（64） 表A—10 合格审定联络过程???????????????????? （65）

AC 20—115B???????????????????????????（82）

6

机载系统和设备合格审定中的软件考虑

出版说明

RTCA DO—178B《机载系统和设备合格审定中的软件考虑》是美国航空无线电技术委员会为支持含有数字计算机的机载系统和设备的研制工作而开发的软件开发过程中应遵循的准则。

RTCA DO—178B适用于机载系统和设备中软件的开发和软件的合格审定。可供机载系统和设备（含软件）开发者使用，也可供合格审定机构审查使用。

前言

本文件由航空无线电技术委员会（RTCA）第167号特别委员会制订，由RTCA于1992年12月1日批准。

RTCA是美国政府与工业界组成的一个航空组织。它致力于推动航空技术的发展，寻求解决在航空营运过程中使用电子设备和通讯设备所遇到问题的深入的技

7

机载系统和设备合格审定中的软件考虑

术方法。其目标是通过其成员和参加组织来协商解决这种问题的方法。

RTCA的研究成果对所有有关的组织来说是推荐性的。RTCA不是美国政府的官方机构，除非联邦政府组织或机构对推荐的有关内容声明有法定效力，否则其推荐内容可在官方政府政策的阐述中不予考虑。

这些指南的开发是由RTCA的SC—167特别委员会与欧洲民用航空电子组织（EUROCAE）的WG—12工作组通过协调共同完成的。

RTCA DO—178B

制订：SC—167 日期：1992.12.1

——————————————————————————————————

机载系统和设备合格审定中的软件考虑

8

机载系统和设备合格审定中的软件考虑

1.0 引言

早在二十世纪八十年代，在航空器和发动机上所用的机载系统和设备中，对软件的使用迅速增加，从而导致了要求有一个工业可接受的指南，以满足适航性要求。制定DO—178《机载系统和设备合格审定中的软件考虑》就是为了满足这个要求。

现在，按经验修订的本文件，以可协调的方法和可接受的置信度，为航空界确定机载系统和设备中的软件是否符合适航要求提供了指南。由于软件使用的增加、技术发展和本文件使用中获得的经验，本文件将被评审和修订。附录A说明了本文件的历史情况。

1.1 目的

本文件的目的是为机载系统和设备中的软件开发提供指南，以使软件在安全方面以一定的置信度完成其预定功能，并符合适航要求。这些指南是：

·软件生存周期中各过程的目标

·为达到这些目标所进行的活动和设计考虑的说明 ·表明这些目标已达到的证据的说明

1.2 范围

本文件讨论了涉及到航空器和发动机上所用机载系统和设备中的软件开发过程中的适航性合格审定方面的问题。在讨论这些问题中，说明系统生存周期及其与软件生存周期之间的关系有助于理解合格审定过程，但并不打算对包括系统安全性评估和确认过程或航空器和发动机合格审定过程中各个过程有一个完整的说明。

由于讨论的合格审定问题仅与软件生存周期有关，所以不讨论最终软件运行的问题。例如，用户可更改资料的合格审定就超出了本文件的范围。

本文件不为申请人的组织机构、申请人及其供应商之间的关系或责任如何划分提供指南。人员资格准则也超出了本文件的范围。

1.3与其他文件的关系

除了适航性要求之外，可以使用不同国家的和国际的软件标准。在一些团体中，可能要求软件符合这些标准。然而，引用具体的国家或国际标准，或者建议使用这些标准做为本文件的替代或补充，均超出了本文件的讨论范围。

在本文件使用“标准”这一术语之处，应理解为机载系统、机载设备、发动机或航空器制造商使用的具体工程标准。这样的标准可能来自制造商为其活动所编制的或采纳的通用标准。

1.4怎样使用本文件

当使用本文件时，应注意下列几点：

·本文件包括说明性内容，以帮助读者理解讨论的主题。例如，第2章提供的信息对理解系统生存周期和软件生存周期之间的联系是必需的。同样，第3章是对软件生存周期的说明。第4章是航空器和发动机合格审定的综述。

·本文件准备供国际上的航空团体使用。为了有助于这样的使用，应尽量减少引用具体国家的条例和规章，并使用通用的术语。例如，使用的术语“合格审定机构”意指以国家的名义负责航空器或发动机合格审定并给予批准的组织或人员。在第二国或国家集团批准或参与该合格审定之处，如果承认已签订的双边协议或

9

机载系统和设备合格审定中的软件考虑

涉及到国家之间双边谅解的备忘录，那么可以使用本文件。

·本文件承认这个指南不是由法律强制的，而是代表了航空团体的意见。它也承认，对申请人来说，用其他方法代替这里描述的方法也是可以的。鉴于这些原因，避免使用像“应”和“必须”这样的词。

·本文件说明了软件等级的目标，正象2.2.2条定义的那样。附件A通过软件等级规定了这些目标的变化。如果申请人采用本文件做为合格审定之用，那么它可以作为达到这些目标的一套指南。

·第11章包括通常产生的资料，以帮助软件合格审定过程。文中资料的名称通过该名称每一个字的第一字母的大写注明。如源代码（Source Code）。

·第12章讨论了其它的一些考虑，包括以前开发软件的使用、工具鉴定和第2章到第11章规定方法的替代方法使用指南。第12章并不是对每一个合格审定都适用。

·软件等级变化表和术语汇编包含在附件中，并且是本文件的正式部分。其它材料包括在附录中，它是本文件的非正式部分。 ˙˙

˙˙˙

·在使用例子来表明怎样使用本指南的场合，无论图示还是从头到尾的叙述，不要把这些例子理解为是更好的方法。

·项目清单并不意味着这个清单包括所有一切。

·本文件使用注来提供解释性材料，强调一点或图，使人们注意不完全在上下文中的相关内容。注不包含指南。

1.5 文件综述

图1—1是文件各章及其相互关系的一个图示。

2.0 与软件开发有关的系统情况

这部分讨论对理解软件生存周期过程所必需的系统生存周期过程的一些情况。主要有：

·在系统和软件生存周期过程之间资料的交换（2.1条） ·失效状态分类、软件等级定义和软件等级的确定（2.2条） ·系统结构考虑（2.3条）

·系统对用户可更改条件、可选择选项软件和商用成品软件的考虑（2.4条） ·系统设计对外场可加载软件的考虑（2.5条） ·系统需求对软件验证的考虑（2.6条） ·系统验证中对软件的考虑（2.7条）

与软件开发有关 航空器和发动机

的系统情况 合格审定综述 第2章 第10章

10

机载系统和设备合格审定中的软件考虑

软件生存周期过程 软件生存周期——第3章 软件计划过程——第4章 软件开发过程——第5章 综合过程 软件验证——第6章 软件配置管理——第7章 软件质量保证——第8章 合格审定联络——第9章 软件生存周期资料——第11章 其它考虑——第12章 图1—1 文件综述

2.1 系统和软件生存周期过程之间的信息流

图2—1是系统生存周期过程和软件生存周期过程之间的安全性方面的信息流综述。由于系统的安全性评估过程和系统设计过程是相互关联的，所以在这些部分描述的信息流是重叠的。

注：在本文件出版的时候，对系统生存周期过程的指南正由一个国际委员会编制。尽管用各种办法力图保持过程之间的信息流和定义的兼容性，但在最终出版的文件间可能还存在一些差异。任何差异将在未来的文件修订中进行协调。

11

机载系统和设备合格审定中的软件考虑

适航性要求 系统运行要求 系统生存周期过程 系统安全性评估过程 分配给软件的系统需求 软件等级 设计限制 硬件定义 故障限制范围 标明的 / 消除的错误源 软件需求和结构 软件生存周期过程 图2—1 在系统和软件生存周期过程之间与系统安全性有关的信息流

2.1.1 从系统过程到软件过程的信息流

系统安全性评估过程要确定系统的失效状态并对之进行分类。在系统安全性评估过程中，系统设计分析要定义希望避免这些失效状态的与安全性有关的要求及系统对这些失效状态的响应。对软件和硬件规定的这些要求要清除或限制故障的影响，并可提供故障检测和故障容差。当在硬件设计过程和软件开发过程中做这些决策时，系统安全性评估过程要分析最终的系统设计以验证它是否满足与安全有关的要求。

与安全有关的要求是系统需求的一部分，作为软件生存周期过程的输入。为了保证在整个软件生存周期中合理地实现与安全性有关的要求，系统需求主要应包括或引用：

·系统说明和硬件定义

·合格审定要求，包括适用的联邦航空条例（FAR—美国）、联合适航要求 （JAR—欧洲）、咨询通报（AC—美国）等

·分配给软件的系统需求，包括功能要求、性能要求和与安全性有关的要求 ·软件等级及确定它们的资料、失效状态及其类别、分配给软件的有关功能 ·安全性策略和设计限制，包括设计方法。如划分、非相似性、冗余或安全性监控

·当该系统是另外一个系统的一部分时，那个系统的与安全性有关的要求和失

12

机载系统和设备合格审定中的软件考虑

效状态

系统生存周期过程可以规定对软件生存周期过程的要求，这样有助于系统的验证活动

2.1.2 从软件过程到系统过程的信息流

利用软件生存周期过程提供的信息，系统安全性评估过程要确定软件设计和实施对系统安全性的影响。这些信息包括故障限制范围、软件需求、软件结构和在软件设计过程中通过使用工具或其它方法检测或消除的软件结构中的错误源。在系统需求和软件设计资料之间的可追踪性对系统安全性评估是重要的。

对软件的更改可能会影响到系统的安全性，所以必须明确用于评估的系统安全性评估过程。

2.2 失效状态和软件等级

下列指南涉及到系统失效状态分类、软件等级的定义、软件等级和失效状态类别之间的关系和如何确定软件等级。

系统失效状态的类别是通过确定失效状态对航空器及其乘客的危害度来确定的。软件错误可能引起导致失效状态的故障，因此，对安全操作是必需的软件等级的完整性关系到系统的失效状态。

2.2.1 失效状态类别

为了全面地定义失效状态的类别，可参考有关的条例和指导性材料、联邦航空局 AC 25—1309—1A和 / 或联合航空管理局AMJ25—1309及其修订内容。列举的失效状态是从这些指南材料中引伸过来的并包括了其中的类别，以利于本文件的使用。这些类别是：

a. 灾难性的 阻止继续安全飞行和着陆的失效状态。

b. 危险的 / 严重的 降低航空器的性能和机组人员克服不利操纵状态的能力的失效状态。这些不利操纵状态达到的程度是： （1）大大降低了安全性余量或功能能力；

（2）身体疲劳或高负荷使飞行机组不能精确或完整地完成他们的任务；或 （3）对乘客的不利影响，包括对少数乘客严重的或潜在的致命伤害。 c. 较重的 可能降低航空器的性能和机组人员克服不利操纵状态的能力的 失效状态。这些不利操纵状态达到的程度如：较大地降低安全余量或功能能力、较大地增加了机组人员的工作量或削弱机组人员工作效率的状态，或造成乘客不舒服，可能包括伤害。

d. 较轻的 不会严重降低航空器安全性及有关机组的活动在他们的能力内 能很好完成的失效状态。较轻的失效状态可能包括：如稍微减少安全余量或功能能力；稍微增加机组人员的工作量，如航线飞行计划更改或乘客的某些不方便。

e. 无影响的 不影响航空器的工作性能或不增加机组工作量的失效状态。

2.2.2 软件等级定义

软件等级是基于在系统安全性评估过程中确定的软件对潜在失效状态的影 响。软件等级意味着用来表明符合合格审定要求的努力程度随失效状态的类别而变化。这些软件等级的定义是：

a. A 级 可能引起或导致系统功能失效进而引起航空器灾难性失效状态的

13

机载系统和设备合格审定中的软件考虑

异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。

b. B 级 可能引起或导致系统功能失效进而引起航空器危险的/严重的失效状态的异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。

c. C 级 可能引起或导致系统功能失效进而引起航空器较重失效状态的异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。

d. D 级 可能引起或导致系统功能失效进而引起航空器较轻失效状态的异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。

e. E 级 可能引起或导致系统功能失效的异常状态的软件。这种异常状态可通过系统安全性评估过程来表明。它不会影响航空器的工作性能或驾驶员工作量。一旦软件由合格审定机构定位E 级，本文件就不再提供进一步的指南。

2.2.3 软件等级确定

系统安全性评估过程首先要确定与特定系统中的软件有关的软件等级，而不考虑系统设计。当做这个决定时，必须表明失效的影响，无论是功能丢失还是故障。

注：（1）在进一步的开发过程中，申请人可能考虑增加的功能能力以及可能导致更严重的失效状态类

别和更高软件等级的分配给软件的系统需求中潜在的更改，可能希望开发的软件能达到高于原申请人在系统安全性评估过程中确定的软件等级，因为为了证实较高的软件等级的应用，软件生存周期资料的后续开发可能是困难的。

( 2）对由运行条例管理的机载系统和设备，只要不影响航空器的适航行性，如事故飞行数据记录仪，软件等级要与预定功能相匹配，在某些场合，可在设备最低性能标准中规定软件等级。

如果软件部分的异常状态引起多个失效状态，那么那个部件的最严重的失效状态类别决定了那个软件部件的软件等级。在系统设计评估过程中，如在2.3中规定的那些，存在可能导致软件等级被更改的结构方法。

系统功能可以分配到一个或多个已划分的软件部件中，并行实施是用多个软件部件来实现一个系统功能。这样，只有多个部件的异常状态才能产生一个失效状态。对并行实施，至少有一个软件部件具有与那个系统功能最严重的失效状态相应的软件等级，其它部件的软件等级使用与那个功能丢失有关的失效状态类别来确定。这种实施的例子在2.3.2条——多版本非相似软件和2.3.3条——安全性监控中预以描述。

一个系统功能亦可用多个软件部件来串行实施。这样，任何部件的异常状态都能产生失效状态。在这种实施中，软件部件将具有与系统功能的最严重的失效状态类别相应的软件等级。

开发某一等级的软件并不意味着对那个软件失效率的分配。这样，软件等级或基于软件等级的软件可靠率（reliability rates）不能象硬件失效率那样在系统安全性评估过程中使用。

不符合2.2.3条指南的方法需要通过系统安全性评估过程来证明是正确的。

2．3 系统结构考虑

如果系统安全性评估过程确定系统结构可消除可能导致系统最严重失效状态的软件的异常状态，那么要根据引起软件异常状态的失效状态的最严重类别来确定软件等级。系统安全性评估过程考虑了结构设计方法，以确定它们是否影响软件等级或软件的功能性。本指南提供了几种结构方法，它们可限制错误的影响或利于检测错误和对某些错误提供可接受的系统响应。

这些结构技术不要理解为是更好的或要求的方法。

14

机载系统和设备合格审定中的软件考虑

2.3.1 划分

划分是在功能上独立的软件部件之间提供隔离的技术，以确定和/或隔离故障，并潜在地减少软件验证过程的工作量。如果通过划分提供了保护，那么对每一个划分的软件等级，可使用与那个部件相关的最严重的失效状态类别来确定。

对划分的指南包括：

a. 当设计了划分保护时，要考虑系统的下列方面，以确定它们是否防碍了那个保护：

（1）硬件资源 处理器、存储器设备、输入 / 输出设备、中断和定时器； （2）控制耦合器 外部存取易损性；

（3）数据耦合器 共享或重复占位数据，包括堆栈和处理器寄存器； （4）与保护机制相关的硬件设备的失效模式。

b. 软件生存周期过程要表明划分的设计考虑，包括划分的部件之间允许的内部连接的程度和范围，无论保护是通过硬件还是通过软件和硬件的组合来实现的。

c. 如果划分保护涉及到软件，那么软件的等级要与划分的软件部件的最高等级相对应。

2.3.2 多版本非相似软件

多版本非相似软件是系统设计技术，它涉及到产生两个或更多的软件部件。这些部件以可在部件间避免某些共同错误源的方式提供同样的功能。多版本非相似软件也称为多版本软件、非相似软件、N版本程序设计或软件多样性。

在非相似性引入到开发之前，完成的或进行的软件生存周期过程保留了潜在的错误源。系统需求规定了执行多版本多版本非相似软件提供的硬件配置。

非相似的程度进而防护的程度通常是不可计量的。系统功能丢失的可能性将增加到这样的程度，即与非相似软件版本相关的安全性监控能检测到实际的错误或超过比较器门限的经验瞬变。所以，通常使用非相似软件版本作为某等级的软件在其验证过程目标（正象第6章规定的那样）被满足之后提供附加保护的手段。对非相似软件验证方法，如果它能表明系统功能的最终潜在失效通过系统安全性评估过程能确定是否可以接受，那么它可以减少验证单一版本软件时所用的那些方法。

多版本非相似软件的验证在12.3.3条中讨论。

2.3.3 安全性监控

安全性监控是通过直接检测可能引起失效状态的功能失效而防止具体失效状态的一种手段。监控功能可通过硬件、软件或硬件和软件的组合来实现。

通过监控技术的使用，所监控的功能的软件等级可以降低到与其相关的系统功能的失效相应的等级。为了允许这个等级的降低，要确定三个重要的属性：

a. 软件等级 安全性监控软件的软件等级要与被监控功能的最严重的失效状态类别相对应。

b. 系统故障范围 监控器的系统故障范围的评估要确保监控器的设计和实施能使想要检测的故障在所有必要的条件下得以检测。

c. 功能和监控器的独立性 监控器和防护措施不会由于引起这种危害的同一失效状态而不予动作。

2．4 系统对用户可更改软件、可选择选项软件和商用成品软件的考虑

15

机载系统和设备合格审定中的软件考虑

用户更改的潜在影响由系统安全性评估过程确定，并用于开发软件需求和软件验证过程的活动。在5.2.3条中，进一步讨论用户可更改软件的设计。影响不可更改的软件、它的保护或可更改软件界限的更改是一种软件更改，并在12.1.1条中讨论。在本文件中，可更改部件是准备由用户更改的软件的那部分，不可更改部件是不准备由用户更改的软件的那一部分。

一些机载系统和设备可包括选择性的功能。它是由软件编程来选项，而不是通过硬件连接器引脚来选择，可选择选项的软件功能用于在目标机中选择特定的配置。对无效码的指南见5.4.3条。

系统对用户可更改软件、可选择选项软件和商用成品软件进行考虑的指南包括：

a. 用户可更改软件 如果系统需求中提供了用户更改，那么用户可在更改限制范围内修改软件，而无需经过合格审定机构的评审。

b. 系统需求将规定防止用户更改影响到系统安全性而没有正确实施更改的方法。为用户更改提供保护的软件将具有与防止更改部件出错的功能软件一样的等级。

c. 如果系统需求不包括用户更改的条款，除非证明更改符合本文件，否则软件不得由用户更改。

d. 在用户更改时，用户要对用户可更改软件的所有方面负责。例如软件配置管理、软件质量保证和软件验证

e. 可选择选项软件 当包括编程选项的软件时，要提供手段确保不会为安装环境中的目标机偶然选择到涉及未经批准的配置。

f. 商用成品软件 包括在机载系统或设备中的商用成品软件要满足本文件的目标。

g. 如果在商用成品软件的软件生存周期资料中存在缺项，那么要增加资料，以满足本文件的目标。12.1.4条－－开发基线升级和12.3.5－－产品服务历史的指南与这种情况有关。

2．5 系统设计对外场可加载软件的考虑

外场可加载机载软件是无需把系统或设备从它安装位置上拆下来即可装入的软件或数据表。与软件数据加载功能相关的有关安全性的需求是系统需求的一部分。如果软件数据加载功能可能偶然会引起系统失效状态，那么对于软件数据的加载功能，与安全性有关的要求要在系统需求中规定。

与外场可加载软件有关的系统安全性考虑包括： ·不可靠的或部分加载的软件的检测 ·加载不合适软件的影响的确定 ·硬件/软件兼容性 ·软件/软件兼容性 ·航空器/软件兼容性

·外场加载功能的偶然使能

·软件配置标识显示的丢失或不可靠 对外场可加载软件的指南包括：

a. 除非由系统安全性评估过程证明是正确的，否则部分或不可靠软件加载的检测机制要有与软件加载功能有关的最严重的失效状态或软件等级一样的失效状态或软件等级。

16

机载系统和设备合格审定中的软件考虑

b. 如果当不合适的软件或数据加载时系统有一个缺省模式，那么在这个模式表明的潜在失效状态中，系统的每一个划分部件要有为运行规定的与安全性有关的需求。

c. 软件加载功能，包括支持系统和过程，要包括检测不正确软件和/或硬件和/或航空器组件的手段，并对功能的失效状态提供合适的保护。

d. 如果软件是确保航空器符合合格审定配置的机载显示方法的一部分，那么该软件要么按最高级软件开发并加载，要么系统安全性评估过程要能够说明软件配置标识的不断检查的完整性。

2．6 系统需求对软件验证的考虑

根据系统运行要求和由系统安全性评估过程产生的与安全性有关的要求来开发系统需求。考虑包括：

a. 机载软件的系统需求要确定软件的两个特性： （1） 软件完成了系统需求中定义的指定功能；

（2） 软件没有呈现出系统安全性评估过程确定的具体的异常状态。为了消除异常状态，要求增加系统需求。

b. 这些系统需求进而发展到由软件验证过程活动验证的软件高级需求。

2．7 系统验证中的软件考虑

系统验证的指南超出了本文件的范围。然而，软件生存周期过程可帮助系统验证过程并与系统验证过程相互作用。与系统功能性相关的软件设计细节也可用于帮助系统验证。

系统验证可提供代码结构的主要覆盖范围。可使用系统验证测试的覆盖范围分析来实现软件验证中说明的各种不同测试活动的覆盖范围的目标。

3．0 软件生存周期

本章讨论软件生存周期过程、软件生存周期定义和软件生存周期过程之间的转换准则。本文件的指南并未描述一个特定的软件生存周期，而是描述了大多数生存周期的分离的过程及其间的相互联系。过程的分离并不打算表明完成他们的组织结构。对每一个软件产品，要构造包括这些过程的软件生存周期。

3．1软件生存周期过程

软件生存周期过程是：

·软件计划过程 定义并协调一个项目的软件开发和综合过程的活动。第4章描述了软件计划过程。

·软件开发过程 这些过程是软件需求过程、软件设计过程、软件编码过程和综合过程。第5章描述了软件开发过程。

·综合过程 保证软件生存周期及其输出正确、受控和可信。综合过程是软件验证过程、软件配置管理过程、软件质量保证过程和合格审定联络过程。在整个软件生存周期中，了解同软件开发过程同时完成的综合过程是重要的。第6～9章描述了综合过程过程。

3．2 软件生存周期定义

通过选择每一个过程的活动、规定活动的顺序和分配给活动的责任，一个项目

17

机载系统和设备合格审定中的软件考虑

可以定义一个或多个软件生存周期。

对一个具体项目，由项目的特性来确定这些过程的顺序，如系统功能性和复杂性，软件大小和复杂性，需求稳定性，以前开发结果的使用，开发策略和硬件可用性。整个软件开发过程的一般顺序是需求、设计、编码和综合。

图3－1对具有不同软件生存周期的单个软件的几个部件的软件开发过程的顺序进行了说明。通过开发软件需求，部件W实施一系列系统需求，使用那些需求来确定软件设计，将设计转化为源代码，并且把软件部分综合到硬件中去。部件X是对在已经合格审定的航空器或发动机中使用的以前开发的软件的使用说明。部件Y说明了利用能从软件需求直接编码的简单的、划分的功能。部件Z说明了使用原型策略。通常，原型的目标是更好理解软件需求并减少开发和技术的冒险。用原始需求作为开发原型机的基础。这个原型机在代表被开发系统的预定的使用环境中进行评估。评估结果被用来改进需求。

软件生存周期过程可反复迭代，即进入和再进入。迭代的时机和程度随系统功能、复杂性、需求开发、硬件可用性、对以前过程的反馈和项目的其它特征的进一步开发而变化。

选择的软件生存周期的各个不同部分与进一步的综合过程和软件验证的活动紧密连在一起。

3．3 过程之间的转换准则

使用转换准则来确定一个过程是否可以进入或再进入。每一个软件生存周期过程完成输入到产生输出的活动。一个过程可对其他过程产生反馈，并从其他过程接受反馈。反馈的定义包括如何通过接受过程识别、控制和处理信息。一个反馈定义的例子是问题报告。

转换准则将取决于软件开发过程和综合过程的预定顺序，并且可能会受到软件等级的影响。可供选择的转换准则的例子是：已完成的软件验证过程评审；输入是一个被标识的配置项；完成了输入的可追踪分析。

如果为过程确定的转换准则是满意的，那么过程的每一个输入不必在过程开始前完成。指南包括：

a. 如果一个过程对部分输入起作用，那么要检查过程的后续输入以确定软件开发和软件验证过程的以前的输出仍然有效。

18

机载系统和设备合格审定中的软件考虑

分配给软件的系统 需求 软件部件： R－D－C－I 部件W?? R－I 部件X?? R－C－I 部件Y?? 部件Z?? R－C－I－C－I－R－D－C－I 代号 软件产品 R = 需求 C = 编码 D = 设计 I = 综合 注：为了简单，并未表明软件计划和综合过程 图3－1 使用四种不同开发顺序的软件项目的例子

4．0 软件计划过程

本章讨论软件计划过程的目标和活动。这个过程产生指导软件开发过程和综合过程的软件计划和标准。附件A的表A－1是各级软件的软件计划过程的目标和输出的总结。

4．1 软件计划过程目标

软件计划过程的目标是定义产生满足系统需求并提供与适航要求相一致的置信度水平的软件方法。软件计划过程的目标是：

a. 定义表明系统需求和软件等级的软件生存周期的软件开发过程和综合过程

19

机载系统和设备合格审定中的软件考虑

的活动（4.2条）

b. 确定软件生存周期，包括过程之间的内部关系、它们的顺序、反馈机理和转换准则（第3章）。

c. 选择软件生存周期环境，包括用于每一个软件生存周期过程活动的方法和工具（4.4条）。

d. 其它考虑。如果必要，可提出如第12章1讨论的那些。 e. 定义与被生产软件的系统安全目标相符的软件开发标准。 f. 编制了符合4.3条和第11章的软件计划。 g. 协调软件计划的开发和修订。

4．2 软件计划过程活动

有效的计划是生产的软件满足本文件指南的决定因素。软件计划过程的指南包括：

a. 软件计划要及时地在软件生存周期的某一点予以开发，以便及时地为完成软件开发过程和综合过程的人员提供指导。也可参见9.1条。

b. 要明确或选择用于项目的软件开发标准

c. 要选择在软件开发过程中提供防止错误的方法和工具。

d. 软件计划过程将在软件开发和综合过程之间提供协调，以保证在软件计划中的策略之间保持一致。

e. 软件计划过程要包括随项目进展修订软件计划的方法。

f. 在系统中使用多版本非相似软件时，软件计划过程要选择满足系统安全性目标所必需的避免错误或进行必要检测的方法和工具。

g. 对将被完成的软件计划过程，软件计划和软件开发标准要在更改控制之下并完成对它们的评审（4.6条）。

h. 如果准备使用无效码（2.4条），软件计划过程将描述怎样定义验证和处理无效码（选择的选项、飞行试验），以达到系统安全性目标。

i. 如果准备使用用户可更改代码，在软件计划和标准中将规定证实5.2.3条指南的过程、工具、环境和数据项。

如果计划和方法对具体的过程活动是可用的，那么其它软件生存周期过程可在软件计划过程完成之前开始。

4．3 软件计划

软件计划的目标是确定满足本文件目标的方法。它们规定了将完成那些活动的组织。软件计划是：

·软件合格审定计划（11.1条）为征得合格审定机构对建议的开发方法的同意而与其进行联络的主要手段，并且定义了符合本文件的方法

·软件开发计划（11.2条）定义了软件生存周期和软件开发环境 ·软件验证计划（11.3条）定义了满足软件验证过程目标的方法

·软件配置管理计划（11.4条）定义了满足软件配置管理过程目标的方法 ·软件质量保证计划（11.5条）定义了满足软件质量保证过程目标的方法 软件计划的指南包括：

a. 软件计划要符合本文件。

b. 软件计划要定义规定的软件生存周期过程之间的转换准则； （1） 过程的输入，包括从其它过程的反馈；

20

机载系统和设备合格审定中的软件考虑

（2） 可能需要的对这些输入起作用的任何综合过程的活动； （3） 工具、方法、计划和规程的可用性。

c. 在合格审定的航空器或发动机上使用之前，软件计划要表明用于实施软件更改的规程。这种更改可能是由于其它过程的反馈的结果，且可能引起软件计划的更改。

4．4 软件生存周期环境计划

对软件生存周期环境，计划的目标将用于定义开发、验证、控制和编制软件生存周期资料（第11章）和软件产品所使用的方法、工具、规程、程序设计语言和硬件。选择的软件环境如何对机载软件产生有利的影响的例子包括强化标准、检测错误、实施错误防护和故障容错方法。软件生存周期环境是一个可能引起失效状态的潜在的错误源。这个软件生存周期环境的构成可能受在系统安全性评估过程中确定的与安全性有关的要求的影响，例如非相似的使用，冗余部件。

错误防止方法的目标是在软件开发过程期间避免可能引起失效状态的错误。基本原则是选择需求开发和限制引入错误机会的设计方法、工具和程序设计语言以及保证能检测到引入错误的验证方法。故障容错方法的目标要包括软件设计或源代码中的安全特性，以保证软件正确地响应输入数据错误，并防止输出和控制错误。用系统需求和系统安全性评估过程确定对错误防护或故障容错方法的要求。

上述考虑可能影响到：

·软件需求过程和软件设计过程中所用的方法和表示法 ·软件编码过程使用的程序设计语言和方法 ·软件开发环境工具

·软件验证和软件配置管理工具 ·工具鉴定要求（12.2条）

4.4.1 软件开发环境

软件开发环境是生产高质量软件的主要因素。软件开发环境可以几种方式对机载软件的生产产生不利影响。例如，编译程序可通过产生一个错误输出而引入错误，或者连接器不能暴露出表现出来的存储器分配错误。选择软件开发环境方法和工具的指南包括：

a. 在软件计划过程期间，选择的软件开发环境要把最终机载软件的潜在风险减至最小。

b. 要选择有资格的工具或工具的组合以及软件开发环境的部件的使用，以便由另一个部件检测到的某个部件引入的错误能达到必要的置信度水平。当两个部件同时一起使用时，能产生一个可接受的环境。

c. 定义的软件验证过程活动或软件开发标准，包括对软件等级的考虑，要使与软件开发环境有关的潜在错误减至最少。

d. 对组合工具的使用，如果寻求合格审定置信度，那么工具操作的顺序要在有关计划中规定。

e. 如果在项目使用中选择了软件开发工具的可选择特性，那么选项的效果要加以检查并在有关计划中规定。

注：工具直接产生软件产品的一部分是特别重要的。在本文中，编译程序可能是考虑的最重要的工具。

4.4.2 语言和编译程序考虑

21

机载系统和设备合格审定中的软件考虑

在成功地完成软件产品的验证时，要考虑编译程序对那个产品的可接受性。为了确认这一点，软件验证过程活动要考虑编程语言和编译程序的特殊特征。当选择编程语言和计划验证时，软件计划过程要考虑这些特征。指南包括：

a. 一些编译程序具有优化目标代码性能的特征。如果测试用例给出的覆盖范围与软件等级一致，那么不需要验证优化的正确性，否则这些特征对结构覆盖范围分析的影响要按6.4.4.2条的指南来确定。

b. 为了实施某些特征，对一些语言的编译程序可能产生不能直接追踪到源代码的目标代码，例如初始化、机内错误检测或异常处理(6.4.4.2条b 项)。软件计划过程要提供检测这个目标代码的方法，以保证验证的覆盖范围并在有关计划中定义了这些方法。

c. 如果引入了一个新的编译程序、连接编辑程序或加载程序版本或者在软件生存周期间更改了编译程序的选项，那么以前的测试和覆盖范围分析可能不再是有效的。验证计划要提供与第6章和12.1.3条的指南相符的重新验证的方法。

4.4.3 软件测试环境

软件测试环境计划的目标是定义将用于测试综合过程输出的方法、工具、规程和硬件。测试可使用目标计算机、目标计算机的模拟器或宿主机仿真器来完成。指南包括：

a. 模拟器或仿真器可能需要按12.2条规定进行鉴定。

b. 要考虑在目标机和模拟器或仿真器之间的差异以及这些差异对检测错误和验证功能的能力的影响。那些错误的检测要由其它的软件验证过程活动提供并在软件验证计划中规定。

4．5 软件开发标准

软件开发标准的目标是为软件开发过程定义规则和限制。软件开发标准软件需求标准、软件设计标准和软件编码标准。软件验证过程使用这些标准作为评估过程实际输出与预定输出符合性的基础。对软件开发标准的指南包括：

a. 软件开发标准要符合第11章；

b.软件开发标准要保证某给定的软件产品或相关的一套产品的软件部件的设计和实施是一致的；

c.软件开发标准不允许使用产生不能验证或与安全性有关的需求不相符的输出的结构或方法。

注：在开发标准中，要考虑以前的经验。要包括在开发、设计和编码方法中的限制和规则，以控制复杂性。要考虑保护程序的方法以改进耐用性。

4．6软件计划过程的评审和保证

要改进软件计划过程的评审和保证，以确保软件计划和软件开发标准符合本文件的指南，并提供执行它们的方法。指南包括：

a. 选择的方法将能够满足本文件的目标； b. 软件生存周期过程一直适用；

c. 每一过程产生其输出能追溯到它们活动和输入的证据，并表明活动、环境和使用方法的独立程度；

d. 软件计划过程的输出是一致的，且符合第11章要求。

5．0 软件开发过程

22

机载系统和设备合格审定中的软件考虑

这一章讨论软件开发过程的目标和活动。应用的软件开发过程由软件计划过程（第4章）和软件开发计划（第11.2章）来定义。附件A的表A－2是按软件等级划分的软件开发过程的目标和输出的总结。软件开发过程是：

·软件需求过程 ·软件设计过程 ·软件编码过程 ·综合过程

软件开发过程产生一个或多个等级的软件需求。高级需求直接通过系统需求和系统结构的分析来产生。通常，这些高级需求在软件设计过程中进一步开发，这样产生一个或多个成功的较低级需求。然而，如果源代码直接从高级需求产生，高级需求也要考虑低级需求，并且对低级需求的指南也适用。

软件开发过程产生一个或多个等级的软件需求。高级需求直接通过系统需求和系统结构的分析来产生。通常，这些高级需求在软件设计过程中进一步开发，这样产生一个或多个成功的较低级需求。然而，如果源代码直接从高级需求产生，高级需求也要考虑低级需求，并且对低级需求的指南也适用。

软件结构的开发涉及到关于该软件结构所做的决策。在软件设计过程期间，要定义软件结构并开发低级需求。低级需求是不用进一步信息而直接实现源代码的软件需求。

每一个软件开发过程可能产生派生需求。派生需求是不能直接追溯到更高级需求的需求。这样，一个派生需求的例子是为选择的目标主计算机而开发中断处理软件的需求。高级需求可包括派生需求，低级需求也可包括派生需求。派生需求对与安全性有关的需求的影响由系统安全性评估过程确定。

5．1 软件需求过程

软件需求过程使用系统生存周期的输出来开发软件高级需求。这些高级需求包括功能、性能、接口和与安全性有关的需求。

5.1.1 软件需求过程目标

软件需求过程目标： a. 开发高级需求

b. 系统安全性评估过程要表明派生的高级需求。

5.1.2 软件需求过程活动

软件需求过程的输入包括来自系统生存周期过程的系统需求、硬件接口和系统结构（在需求中并未包括）以及来自软件计划过程的软件开发计划和软件需求标准。当计划的转换准则已被满足时，这些输入用于开发软件高级需求。

这个过程的主要输出是软件需求资料（11.9条）。

当它的目标和与它有关的综合过程的目标被满足时，软件需求过程就完成了。对这个过程的指南包括：

a. 对不明确的、不一致的和未定义的状态，要分析分配给软件的系统功能和接口要求；

b. 要报告软件需求过程检测到的不合适的或不正确的输入，并反馈到输入的源过程以澄清或纠正；

c. 要在高级需求中规定分配给软件的每一个系统需求；

23

机载系统和设备合格审定中的软件考虑

d. 表明分配给软件以减小系统危害性的系统需求的高级需求要加以定义； e. 高级需求要符合软件需求标准，并且是可验证的和一致的； f. 若适用，高级需求要用容差的定量术语来说明；

g. 除了规定的和合理的设计限制外，高级需求不应详细描述设计和验证细节； h. 分配给软件的每一个系统需求要追溯到一个或多个软件高级需求； i. 除派生的需求外，每一个高级需求要追溯到一个或多个系统需求； j. 要为系统安全性评估过程提供派生的高级需求。

5．2 软件设计过程

在软件设计过程中，通过一次或多次迭代，逐步完善出软件高级需求，以开发软件结构和能用于实现源代码的低级需求。

5.2.1 软件设计过程目标：

软件设计过程目标是：

a. 根据高级需求开发软件结构和低级需求；

b. 要为系统安全性评估过程提供派生的低级需求。

5.2.2 软件设计过程活动

软件设计过程输入是软件需求资料、软件开发计划和软件设计标准。当预定的转换准则已被满足是，在设计过程中使用高级需求来开发软件结构和低级需求。这可能涉及到一个或多个较低级的需求。

这个过程的主要输入是包括软件结构和低级需求的设计说明（11.10条）。 当其目标和与其有关的综合过程的目标被满足是，软件设计过程就完成了。对这个过程的指南包括：

a. 在软件设计过程期间，开发的低级需求和软件结构要符合软件设计标准，并且是可追踪、可验证和一致的。

b. 要定义和分析派生的需求，以保证不损害高级需求。

c. 软件设计过程的活动能引入可能的失效模式到软件中或相反地，干扰其他的软件。在软件设计中采用划分或其他结构方法对软件的某些部件可改变软件等级的分配。在这些情况下，将定义附加资料作为派生需求，并把这些资料提供给系统安全性评估过程。

d. 当规定与安全有关的需求时，要监控控制流和数据流，如看门狗定时器、合理的检查和交叉通道比较。

e. 对失效状态的响应要与安全性有关的要求一致。

f. 在软件设计过程中检测到的不合适的或不正确的输入将提供给系统的生存周期过程、软件需求过程或软件测试过程，作为澄清或纠正的反馈。

注：软件工程目前的状态不允许在复杂性和达到安全性目标之间进行定量对比。当不能提供目标指南时，软件设计过程要避免引入复杂性，因为当软件复杂性增加时，验证设计和表明软件的安全性目标得以满足均是更困难的。

5.2.3 用户可更改软件的设计

下列指南涉及到设计可由其用户更改的软件开发。更改的部件是准备由用户更改的软件的那一部件，而非更改部件是不准备由用户更改的那个部件。用户可更改软件在复杂程度上是可以变化的。例如为了航空器的维护功能，用来选择两设备选项中之一的单个存储位、信息表或能够编程、编译和连接的存储区域。任何

24

机载系统和设备合格审定中的软件考虑

等级的软件能包括一个可更改的部件。

对设计用户可更改软件的指南包括：

a． 非更改部件要预计保护，以防止非更改部件在安全运行中受到更改部件的干扰。这种保护可用硬件、软件、用于更改的工具或三者的组合来实现。

b． 要表明申请人提供的方法是更改可更改部分的唯一方法。

5．3 软件编码过程

在软件编码过程中，由软件结构和低级需求实现源代码。

5.3.1 软件编码过程目标

软件编码过程目标是：

a. 开发的源代码是可追踪的、可验证的、合理的且正确的实现了低级需求。

5.3.2 软件编码过程活动

软件编码过程的输入是来自软件设计过程的低级需求和软件结构、软件开发计划。当预定的转换准则被满足时，软件编码过程可以进入或重新进入。由这个过程产生的源代码取决与软件结构和低级需求。

这个过程的主要结果是源代码（11.11条）和目标代码。

当其目标和与其有关的综合过程的目标被满足时，软件编码过程也就完成了。对这个过程的指南包括：

a. 源代码要实现低级需求并符合软件结构； b. 源代码要符合软件编码标准；

c. 源代码对设计说明来说将是可追踪的；

d. 在软件编码过程中检测到的不合适的或不正确的输入要提供给软件需求过程、软件设计过程和软件计划过程，以作为澄清或纠正的反馈。

5．4 综合过程

目标计算机和来自软件编码过程的源代码和目标代码被用来在综合过程中连接和加载数据，以开发综合的机载系统或设备。

5.4.1 综合过程目标

综合过程目标是：

a. 把可执行目标代码加载到软件/硬件综合的目标硬件中。

5.4.2 综合过程活动

综合过程由软件综合和硬件/软件综合组成。

当预定的转换准则被满足是，综合过程可以进入或重新进入。综合过程的输入是来自软件设计过程的软件结构和来自软件编码过程的源代码和目标代码。

综合过程的输出是可执行目标代码（正象11.12条定义的那样）及连接和加载数据。当其目标和与之有关的综合过程的目标被满足是，就完成了综合过程。这个过程的指南包括：

a. 可执行目标码要从源代码对和连接加载数据产生。 b. 把软件加载到硬件/软件综合的目标计算机中。

c. 在综合过程中检测到的不合格的或不正确的输入将提供给软件需求过程、

25

机载系统和设备合格审定中的软件考虑

软件设计过程、软件编码过程或软件计划过程，以作为澄清或纠正的反馈。

5.4.3 综合考虑

下列是对无效码和软件修补的考虑。设计的机载系统或设备可包括几种配置，但不是所有的都计划在每一种应用中使用。这可能产生不能被执行的无效的编码或不被使用的数据。着一点不用于在术语汇编中定义的或在6.4.4.3条中讨论的死码。对无效编码和修补的指南包括：

a. 无效代码不能在不打算使用它的环境中使用。由于异常的系统状态造成的无效代码的不希望动作与活化代码的不希望动作是一样禁止的。

b.处理无效码的方法要符合软件计划。

c.提交给合格审定的航空器或发动机使用的软件不使用修补来实现需求或结构中的更改，或在软件验证过程中发现必须的更改。例如，修补使用于受限的具体实例，以解决软件开发环境中已知的缺陷，如一个已知的编译程序问题。

d. 当使用修补时，这些将是可用的： （1） 软件配置管理过程能有效地追踪修补的证实； （2） 能提供修补满足由正常方法开发的软件的所有目标的证据的回归分析； （3） 在软件实施概要中使用修补的理由。

5．5 可追踪性

可追踪性指南包括：

a. 要提供在系统需求和软件需求之间的可追踪性，以能够验证实施系统需求的完整性，并给出明确的派生需求。

b. 要提供在低级需求和高级需求之间的可追踪性，以便在软件设计过程期间给出明确的派生需求和所做的结构设计决策，并容许验证实现高级需求的完整性。

c. 要提供在源代码和低级需求之间的可追踪性，以能够验证非书面源代码的缺乏性以及验证低级需求实现的完整性。

6．0 软件验证过程

这一章论述软件验证过程的目标和活动。验证是软件开发过程和软件验证过程两者结果的技术评估。在软件计划过程（第4章）和软件验证计划（11.3条）中定义了实施的和软件验证过程。

验证不仅仅是测试。一般来说，测试不能表明没有错误。所以，在以下几节中当所述的软件验证过程目标兼有评审、分析和测试时，则使用术语“验证”而不用“测试”。

附录A中表A—３到表A—７按软件等级列出了软件验证过程的目标和输出。

注：对较低的软件等级，较少强调如下方面： ? 低层需求的验证 ? 软件体系结构的验证 ? 测试覆盖程度 ? 验证规程的控制 ? 软件验证过程活动的独立性 ? 软件验证过程活动的重叠，即在几种软件验证活动中，每一种活动都能检测到同一类 错误

? 鲁棒测试 ? 对预防错误或检测错误有间接作用的验证活动，如软件开发标准的符合性验证

26

机载系统和设备合格审定中的软件考虑

6.1 软件验证过程目标

软件验证过程的目的是检测和报告在软件开发过程中可能已形成的错误。消除这些错误是软件开发过程的一种活动。软件验证过程的总目标是验证：

a. 分配给软件的系统需求已发展成满足这些系统需求的软件高层需求。 b. 高层需求已发展成满足这些高层需求的软件体系结构和低层需求。如果在高层需求和低层需求之间建立了一层或多层软件需求，那么相邻层次需求的建立应使每一相邻的较低层需求满足其较高层需求。如果从高层需求直接生成代码，那么本项目标不适用。

c. 软件体系结构和低层需求已发展成满足低层需求和软件体系结构的源代码。

d. 可执行目标码满足软件需求。

e. 用于满足上述目标的方法对所定的软件等级而言在技术上是正确的且完整的。

6.2 软件验证过程活动

通过评审、分析、开发测试用例和规程，以及运行测试规程等各种活动的组合来达到软件验证过程的目标。评审和分析对软件需求、软件体系结构和源代码的准确性、完整性和可验证性给予评估。测试用例的开发可对需求的内部一致性和完整性提供进一步的评估。测试规程的运行提供是否符合需求的演示。

软件验证过程的输入包括系统需求、软件需求和结构、可追踪性数据、源代码、可执行目标码和软件验证计划。

软件验证过程的输出记录在软件验证用例和规程（第11.13小节）和软件验证结果（第11.14小节）中。

在软件中实现了需求之后，由于要求需求是可验证的，因此要对软件开发过程提出额外的要求和约束。

软件验证过程要提供在软件需求的实现与对软件需求的验证之间的可追踪性： ? 由基于需求的覆盖分析完成软件需求与测试用例之间的可追踪性 ? 由结构覆盖分析完成代码结构与测试用例之间的可追踪性 软件验证活动的指导原则是：

a. 应验证高层需求以及到高层需求的可追踪性。

b. 可追踪性分析以及基于需求和结构的覆盖分析应表明每一项软件需求可追踪到实现它的代码以及验证它的评审、分析或测试用例。

c. 如果被测代码与机载软件不完全相同，应规定并说明其差别。

d. 如果不能通过在真实的测试环境中运行软件来验证具体的软件需求时，应提供其它手段及说明来满足软件验证计划或软件验证结果中所定义的软件验证目标。

e. 应向软件开发过程报告在软件验证过程中发现的缺陷和错误，以便于澄清和纠正。

6.3 软件评审和分析

评审和分析适用于软件开发过程和软件验证过程的结果。评审与分析的一个差别是分析提供正确性的可重复证据，而评审提供正确性的定性评估。评审可以是一种以一张检查清单或类似辅助手段为指导而进行的对某种输出的检查过程。分析可以是对一个软件部件的功能、性能、可追踪性、安全性影响、以及它与机载

27

机载系统和设备合格审定中的软件考虑

系统或设备中其它部件的关系进行详细检查。

6.3.1 高层需求的评审和分析

高层需求的评审和分析的目标是发现和报告在软件需求开发过程中可能已产生的需求错误。这些评审和分析要证实高层需求满足下列目标：

a. 与系统需求的符合性：该目标是确保已定义了的软件要完成的系统功能，软件的高层需求能满足系统的与功能、性能和有关安全的需求，并正确地定义了派生的需求及其成立的原因。

b. 准确性和一致性：该目标是确保每一项高层需求被准确地、无歧义地和充分地细化，并且需求之间没有冲突。

c. 与目标机的兼容性：该目标是确保在高层需求与目标机的硬件/软件特征之间，特别是与系统的响应时间和输入/输出硬件之间不存在冲突。

d. 可验证性：该目标是确保每一项高层需求是可验证的。 e. 与标准的符合性：该目标是确保在软件需求开发过程中遵循了软件需求标准，并对偏离标准的方面作了说明。

f. 可追踪性：该目标是确保分配到软件的系统功能、性能和有关安全的需求已发展成软件的高层需求。

g. 算法方面：该目标是确保所提出的算法的精度和特性，特别是在不连续区域。

6.3.2 低层需求的评审和分析

低层需求的评审和分析的目标是发现和报告在软件设计过程中可能已产生的需求错误。这些评审和分析要证实软件低层需求满足下列目标：

a. 与高层需求的符合性：该目标是确保软件低层需求满足软件高层需求，并正确地定义了派生需求及其之所以成立的设计基础。

b. 准确性和一致性：该目标是确保每一项低层需求是准确的、无歧义的，并且低层需求之间没有冲突。

c. 与目标机的兼容性：该目标是确保在软件需求与目标机的硬件/软件特征之间，特别是与资源的使用（如总线负载）、系统响应时间和输入/输出硬件之间不存在冲突。

d. 可验证性：该目标是确保每一项低层需求是可验证的。

e. 与标准的符合性：该目标是确保在软件设计过程中遵循了软件设计标准，并对偏离标准的方面作了说明。

f. 可追踪性：该目标是确保高层需求及派生需求已发展成低层需求。

g. 算法方面：该目标是确保所提出的算法的精度和特性，特别是在不连续区域。

6.3.3 软件体系结构的评审和分析

软件体系结构的评审和分析的目标是发现和报告在开发软件体系结构中可能已产生的错误。这些评审和分析要证实软件体系结构满足下列目标：

a. 与高层需求的符合性：该目标是确保软件体系结构与高层需求没有矛盾，特别是与保证系统完善性的功能（如划分方案）没有矛盾。

b. 一致性：该目标是确保软件体系结构中各部件的关系是正确的。这种关系存在于数据流和控制流之中。

c. 与目标机的兼容性：该目标是确保在软件体系结构与目标机的硬件/软件

28

机载系统和设备合格审定中的软件考虑

之间，特别是与初始化、异步操作、同步和中断之间不存在冲突。

d. 可验证性：该目标是确保软件体系结构是可验证的，如没有无限递归算法。 e. 与标准的符合性：该目标是确保在软件设计过程中遵循了软件设计标准，并对偏离标准的方面，特别是不符合系统安全性目标的复杂性限制和设计结构作了说明。

f. 划分的完整性：该目标是确保防止或隔离了划分的分叉。

6.3.4 源代码的评审和分析

源代码的评审和分析的目标是发现和报告在软件编码过程中可能已产生的错误。这些评审和分析要证实软件编码过程的输出是准确的、完整的和可验证的。应主要考虑代码相对于软件需求和软件体系结构的正确性以及与软件编码标准的符合性。这些评审和分析通常局限于源代码。应包括下列论题：

a. 与低层需求的符合性：该目标是确保源代码对于软件低层需求而言是准确的和完整的，并且源代码中没有实现未规定的功能。

b. 与软件体系结构的符合性：该目标是确保源代码与软件体系结构中定义的数据流和控制流相匹配。

c. 可验证性：该目标是确保源代码不包含不能被验证的语句和结构，也不包含只有通过更改才能对其测试的代码。

d. 与标准的符合性：该目标是确保在代码开发过程中，特别是建立应符合系统安全性目标的复杂性限制和代码约束时，遵循了软件编码标准。复杂性包括软件部件之间的耦合、控制结构的嵌套层数以及逻辑或数值表达式的复杂程度。这种分析也要确保对偏离标准的方面作出说明。

e. 可追踪性：该目标是确保软件低层需求已发展成源代码。

f. 准确性和一致性：该目标是确保源代码的正确性和一致性，包括堆栈的使用，定点算术运算溢出和处理，资源争夺、最恶劣情况的执行时间、异常处理、未初始化变量或常量的使用、未使用的变量或常量以及由于任务或中断冲突造成的数据失效。

6.3.5 集成过程输出的评审和分析

对集成过程输出进行评审和分析的目标是确保集成过程的输出是完整的和正确的。可通过详细检查链接、加载数据和内存映象来进行这类评审和分析。应考虑的论题是：

a. 不正确的硬件地址。 b. 内存重叠。 c. 遗漏软件部件。

6.3.6 测试用例、规程和结果的评审和分析

测试用例、规程和结果的评审和分析的目标是确保已开发了代码测试，并正确和完整地执行了测试。应考虑的论题是：

测试用例：在6.4.4节中说明了测试用例的验证。

测试规程：该目标是要验证测试用例已被正确地发展成测试规程和期望的结果。

测试结果：该目标是确保测试结果是正确的，并且解释了真实结果与期望结果之间的差异。

29

机载系统和设备合格审定中的软件考虑

基于软件需求的 测试生成

低级测试 软件综合测试 硬件/软件综合测试

软件需求覆盖分析

软件结构覆盖分析 直接路径

条件路径 附加验证 测试结束

图6-1 软件测试过程

注： 如果已为硬件/软件综合测试或软件综合测试开发和执行了一个测试用例及其相应的测试规程，并且满足了基于需求的覆盖和结构覆盖，那么就不必对低层测试重复这个测试。因减少全部功能测试总量而用标称等价的低层测试来替代高层测试可能是低效的。

6.4 软件测试过程

机载软件的测试有两个相互补充的目标。一个目标是演示软件满足其需求。另一个目标是以高置信度演示可能导致由系统安全性评估过程确定为不可接受的失效状态的错误已被消除。

图6-1 是软件测试过程图。图中三类测试的目标是： ? 硬件/软件综合测试：验证软件在目标机环境中的正确运行。 ? 软件综合测试：验证软件需求和部件之间的内部关系，验证软件需求和软件部件在软件体系结构中的实现。

? 低层测试：验证软件低层需求的实现。

为了满足软件测试目标：

a. 测试用例应主要以软件需求为基础。

b. 测试用例应开发成能验证正确的功能和建立能暴露潜在错误的条件。 c. 软件需求覆盖分析应确定哪些软件需求未被测试。 d. 结构覆盖分析应确定哪些软件结构未被运行。 6.4.1 测试环境

为满足软件测试的目标，可能需要多个测试环境。一个优秀的测试环境应能把

30

机载系统和设备合格审定中的软件考虑

软件加载到目标机中，并在目标机环境的高保真仿真环境中对其进行测试。

注：在许多情况下，只有在一个全综合环境中通过比一般情况更为精确的控制和监视测试输入和代码执行才能达到必要的基于需求的覆盖和结构覆盖。可能需要对一个与其他软件部件功能隔离的小的软件部件进行这种测试。

用目标机仿真器或宿主机模拟机进行测试可给出取证置信度。这类测试环境的指导原则是：

a. 应在综合的目标机环境中运行选定的测试，因为某些错误只能在这种环境中被发现。

6.4.2 基于需求的测试用例的选择

强调基于需求的测试是因为这类测试发现错误的效率是最高的。选择基于需求测试用例的指导原则是：

a. 为实现软件测试目标，应包括两类测试用例：正常范围测试用例和鲁棒(异常范围)测试用例。

b. 应根据软件需求和软件开发过程中内在的错误源来开发专用的测试用例。

6.4.2.1 正常范围测试用例

正常范围测试用例的目标是演示软件响应正常输入和状态的能力。正常范围测试用例包括：

a. 应该用有效等价类和边界值方法来测试实型和整型输入变量。

b. 对与时间有关的功能，如滤波器、积分器和延时，应该用代码的多次迭代来检查该功能在上下文环境中的特性。

c. 对于状态转换，应开发能在正常运行中遍历各种可能的转换的测试用例。 d. 对于用逻辑方程表达的软件需求，正常范围测试用例应能验证变量的使用和布尔算符。

注：一种方法是使用测试变量的所有组合。对于复杂表达式，由于所需的测试用例数很大，这种方法是不可行的。 另一种策略是保证能建立所需的覆盖。例如，对于A级软件，可通过分析或评审来验证布尔算符，为了补充这种活动，可建立满足修改的条件/判定覆盖的测试用例。

6.4.2.2 鲁棒测试用例

鲁棒测试用例的目标是演示软件响应异常输入和状态的能力。鲁棒测试用例包括：

a. 应该用无效值的等价类来测试实型和整型量。 b. 应在异常状态下测试系统的初始化。 c. 应确定输入数据的可能的失效模式，特别是来自外部系统的复杂的数字数据串。

d. 对于循环计数是一个计算值的循环，应开发企图计算超出范围的循环计数值的测试用例，然后演示与循环有关代码的鲁棒性。

e. 应检查用于超出帧时间的保护机制是否能正确响应。

f. 对与时间有关的功能，如滤波器、积分器和延时，应开发算术溢出保护机制的测试用例。

g. 对于状态转换，应开发能引发软件需求不允许的转换的测试用例。 6.4.3 基于需求的测试方法

基于需求的测试方法包括基于需求的硬件/软件综合测试，基于需求的软件综合测试和基于需求的低层测试。除硬件/软件综合测试外，这些方法不规定具体的测试环境或策略。指导原则是：

31

机载系统和设备合格审定中的软件考虑

a. 基于需求的硬件/软件综合测试：这种测试方法应把重点放在与目标机环境中运行的软件有关的错误源和高层功能上。基于需求的硬件/软件综合测试的目标是确保目标机中的软件满足高层需求。通过这种测试方法揭示的典型错误有：

? 不正确的中断处理。 ? 不能满足执行时间需求。 ? 对软件瞬变或硬件失效的不正确的软件响应，如启动顺序、瞬变输入负载和输入电压瞬变。

? 数据总线和其它资源争用问题，如存储映象。 ? 机内自测试不能检测到失效。 ? 硬件/软件接口错误。 ? 反馈回路的不正确行为。 ? 对存储器管理硬件或其它硬件设备的不正确的软件控制。 ? 堆栈溢出。 ? 用于确认外场可加载软件的正确性和兼容性的机制的不正确运行。

? 软件划分的越界。 b. 基于需求的软件综合测试：这种测试方法应把重点放在软件需求之间的内部关系，以及软件体系结构对需求的实现。基于需求的软件综合测试的目标是确保软件部件之间正确地相互作用并满足软件需求和软件体系结构。这种方法的实施途径可以是通过逐步地综合软件部件和相应地扩大测试用例的作用域来扩展需求的作用域。用这种测试方法揭示的典型错误是：

? 变量和常量的不正确的初始化。 ? 参数传递错误。 ? 数据失效，特别是全局数据。 ? 不适当的端点间分辨率。 ? 不正确的事件和操作顺序。 c. 基于需求的低层测试：这种测试方法应把重点放在演示每个软件部件符合其低层需求。基于需求的低层测试的目标是确保软件部件满足其低层需求。

用这种测试方法揭示的典型错误是： ? 一个算法不能满足软件需求。 ? 不正确的循环操作。 ? 不正确的逻辑判定。 ? 不能正确地处理输入状态的合法组合。 ? 不能正确地响应丢失的或失效的输入数据。 ? 不能正确地处理异常，如算术故障或数组越界。 ? 不正确的计算顺序。 ? 不适当地算法精度，准确度或性能。

6.4.4测试覆盖分析

测试覆盖分析分两步进行，即基于需求的覆盖分析和结构覆盖分析。第一步分析与软件需求有关的测试用例，以证实所选的测试用例满足指定的准则。第二步证实基于需求的测试规程测试了代码结构。结构覆盖分析可能不满足指定的准则。对于处理死代码这样情况的解决方法提出了附加的指导原则(见6.4.4.3节)。

32

机载系统和设备合格审定中的软件考虑

6.4.4.1 基于需求的测试覆盖分析

这种分析的目标是确定基于需求的测试对软件需求的实现的验证情况。这种分析可能要求增加基于需求的测试用例。基于需求的测试覆盖分析应表明：

a. 每一项需求都有测试用例。

b. 测试用例满足6.4.2节定义的正常和鲁棒测试准则。

6.4.4.2 结构覆盖分析

这种分析的目标是确定基于需求的测试规程未测试到的代码结构。基于需求的测试用例可能没有测试到所有代码结构，所以要执行结构覆盖分析，并进行额外的验证以达到结构覆盖。指导原则包括：

a. 分析应证实结构覆盖的程度适应所定的软件等级。

b. 除软件等级是 A 级并且编译器产生的目标码不能直接追踪到源代码语句外, 可以对源代码直接进行结构覆盖分析。然后,对目标码进行附加验证以确定所产生的代码序列的正确性。由编译器生成的数组边界检查的目标码是不能直接追踪到源代码的一个例子。

c. 分析应证实代码部件之间的数据耦合和控制耦合。

6.4.4.3 结构覆盖分析方法

结构覆盖分析可揭示在测试中未被执行到的代码结构。解决方法是进行附加的软件验证活动。这种未执行的代码结构可能是下列原因造成的：

a. 基于需求的测试用例或规程的不足：应补充测试用例或修改测试规程以补全遗漏的覆盖。可能需要评审用以执行基于需求的覆盖分析的方法。

b. 软件需求的缺陷：应修改软件需求， 增加测试用例和运行相应的测试规程。

c. 死代码：应消除这种代码，并进行分析以评定其影响和是否需要重新验证。 d. 停止使用的代码：对于在飞机或发动机的任何配置中不打算被执行的停止使用的代码， 应结合分析和测试来表明已采用了某种手段，它能防止，隔离或消除因疏忽而运行这类代码。对于只在目标机环境的某些配置中执行的停止使用代码，应建立正常执行这类代码所需的运行配置，并开发附加的测试用例和测试规程来满足所需的覆盖目标。

7. 0 软件配置管理过程

这一章讨论软件配置管理（SCM）过程的目标和活动。在软件计划过程（第4章）和软件配置管理计划（11.4条）中定义了SCM过程。SCM过程的输出记录在软件配置管理记录（11.18条）或其它的软件生成周期资料中。

附件A中的表A－8总结了SCM过程的目标和输出。

7.1 软件配置管理过程目标

SCM过程同其它软件生成周期过程一并进行，这有助于满足总的目标： a．提供在软件整个生存周期中定义的和受控的软件配置。

b．提供始终为软件制造重现可执行目标代码或在对要求调查或修改的场合重新产生可执行目标代码的能力。

c．在软件生存周期期间，提供过程输入和输出的控制，以保证过程活动的一致性和可重复性。

33

机载系统和设备合格审定中的软件考虑

d．通过对配置项控制和基线的确定，为评审、评估状态和更改控制提供已知的点。

e．要提供控制，以保证问题引起注意且更改得以记录、批准和实施。 f．通过控制软件生成周期过程的输入，来提供软件批准的证据。 g．帮助软件产品符合需求的评估。

h．确保对配置项安全地进行物理归档、恢复和控制的维护工作。

SCM的目标与软件等级无关。然而，两类软件生成周期资料的存在是基于适用于该种资料的SCM控制。

7.2 软件配置管理过程活动

SCM过程包括配置标识、更改控制、基线确定和软件产品（包括有关的软件生存周期资料）归档活动。下列指南定义了每一个SCM过程活动的目标。当软件产品被合格审定机构接受时，SCM过程不能停止，而是持续到机载系统或设备的使用期限。

7.2.1 配置标识

配置标识活动的目标是清楚地为每一个配置项（及其逐次版本）打标记，以便为配置项的控制和参考确定一个基准。指南包括：

a． 要对软件生存周期资料确定配置标识。

b． 要对每一个配置项、配置项的每一个独立的控制部件和组成一个软件产品的配置项的组合确定配置标识。

c． 要在更改控制实施并记录可追踪资料之前对配置项进行配置标识。 d． 在其它的软件生成周期使用之前、其它的软件生成周期资料引用之前或软件制造或软件使用之前，要对该配置项进行配置标识。

e． 如果软件产品标识不能有物理检查（如部件号铭牌检查）确定，那么可执行目标码要包含可由机载系统或设备的其它部件存取的配置标识。这可能适用于外场可加载软件（2.5条）。

7.2.2 基线和可追踪性

确定基线的目标是为进一步的软件生成周期过程活动确定一个基准，并允许在配置项之间参照、控制和可追踪。指南包括：

a． 要为用于合格审定置信度的配置项确定基线（确定的中间基线有助于控制软件生存周期过程的活动）。

b． 要对软件产品确定软件产品基线，并在软件配置索引（11.16条）中定义。 注：在软件产品基线中并不包括用户可更改软件，但它的有关防护和边界部件例外。所以，只要不影响软件产品基线的配置标识，就可以对用户可更改软件进行更改。

c． 要在受控的软件库（物理的、电子的或其它的）中确定基线，以保证它们的完整性。一旦确定了基线，不要对其进行更改。

d． 更改控制活动将从一个确定的基线跟随到开发一个派生基线。 e． 如果合格审定置信度被看作是软件生存周期过程的活动，或者是与以前基线的开发有关的资料，那么基线要能追踪到其派生出的那个基线。

f． 如果合格审定置信度被看作是软件生存周期过程的活动，或者是与以前配置项的开发有关的资料，那么配置项要能追踪到其派生出的那个配置项。

34

机载系统和设备合格审定中的软件考虑

g． 基线或配置项要追踪到它表明的输出或与之有关的过程。

7.2.3 问题报告、追踪和纠正活动

问题报告、追踪和纠正活动的目标是记录不符合软件计划和标准的过程、记录软件生存周期过程输出的缺陷、记录软件产品的异常状态并确保这些问题的解决。

注：软件生存周期过程和软件产品问题可在问题报告系统中分别记录。 指南包括： a． 要编制描述过程不符合计划、输出缺陷或软件异常状态及采取的纠正措施的问题报告，正象11.17条定义的那样。

b． 对受影响的配置项的配置标识或受影响的过程活动、问题报告的状态报告和问题报告的批准和封存，要提交问题报告。

c． 对软件产品或软件生存周期过程的输出的纠正活动的问题报告将引用更改控制活动。

注：问题报告和更改控制活动是相关的。

7.2.4 更改控制

更改控制活动的目标是在软件生存周期内为更改提供记录、评估、处理和批准。指南包括：

a． 更改控制要通过对它们的更改提供防护来保持配置项和基线的完整性。 b． 更改控制确保对每一个配置项的任何更改都需要对其配置标识进行更改。 c． 在更改控制下对基线和配置项的更改要加以记录、批准和追踪。由于报告的问题的处理可能导致配置项或基线的更改，所以问题报告与更改控制有关。 注：一般认为，尽早实现更改控制有助于软件生存周期过程活动的控制和管理。

d． 软件更改要追踪到更改影响它们输出的原始处，并从该处重复软件生存周期过程。例如，在硬件 / 软件综合阶段发现的错误，如果表明由不正确设计引起的，那么将导致与综合过程活动有关的设计更改、编码更改和重复。

e． 在整个更改活动中，要更新受更改影响的软件生存周期资料。要保存更改控制活动的记录。

可通过更改评审活动帮助更改控制活动。

7.2.5 更改评审

更改评审活动的目标是确保问题及更改得以评定、批准或不批准，批准的更改得以实施，并给在整个问题报告中受影响的过程和在软件计划过程期间所定义的更改控制方法提供反馈。更改评审活动将包括：

a． 证实受影响的配置项得以配置标识；

b． 对影响反馈到系统安全性评估过程的与安全性有关的需求的评估； c． 问题或更改（包括采取措施的决定）的评估； d． 问题报告的反馈或更改影响过程的决定。

7.2.6 配置状态纪实

状态纪实活动的目标是为软件生存周期过程的配置管理提供资料。主要关系到配置标识、基线、问题报告和更改控制。状态纪实活动将包括：

a． 对配置项标识、基线标识、问题报告状态、更改历史和发放状态的报告。

35

机载系统和设备合格审定中的软件考虑

b． 定义保存的资料及记录和报告这些资料的状态的方法。

7.2.7 归档、检索和发放

归档和检索活动的目标是确保与软件产品有关的软件生存周期资料在需要复制、再生、重新测试或更改软件产品的情况下能够检索。发放活动的目标是确保归档、可检索和只能使用认可的软件，特别是对软件制造来说。指南包括：

a． 与软件产品有关的软件生存周期资料将能从批准源（如开发组织或公司）处检索。

b． 要确定通过下列方法保证贮存资料完整性的规程（不考虑贮存介质）： (1) 保证不进行未批准的更改；

(2) 选择可使再生错误或缺陷降至最低的贮存介质；

(3) 以与介质的贮存寿命相符的频率使用和 / 或更新归档资料； (4) 贮存复制的副本要在物理上分别归档，以把由灾难事件引起的丢失的风险减至最小。 c． 要验证复制过程以产生正确的副本，且要有规程保证可执行目标代码无错误地进行复制。

d． 在软件制造使用前，要对配置项加以标识和发放，并且对它们发放的权限要加以规定。作为一个最低要求，加载到机载系统或设备中的软件产品部件（包括可执行目标码，也可能包括用于软件加载的有关介质）将被发放。

注：为加载到机载系统或设备中的批准软件定义的资料一般也要求发放。那些资料的确定超出了本文件

的范围，但可包括软件配置索引。

e． 要规定资料保存规程，以满足适航要求且使软件能够更改。

注：其它资料保存的考虑可包括诸如商业性需要和进一步合格审定批准的评审所需的项目，但它超出了本文件的范围。

7.2.8 软件加载控制

软件加载控制的目标是用合适的保安措施保证可执行目标代码被加载到机载系统或设备中。软件加载控制是指把已编程的指令和数据从主机存储器传输到机载系统或设备中的过程。例如，方法（经合格审定机构批准）可包括工厂编程前的存储设备的安装或在原处使用外场加载设备的机载系统或设备的再编程。无论使用什么方法，软件加载控制将包括：

a． 标明为加载到机载系统或设备中而打算批准的软件配置的部件编号和介质标识的规程。

b． 无论软件作为最终项目交付还是安装机载系统或设备中交付，要保存证实软件与机载系统或设备硬件兼容的记录。

注：对软件加载控制的其它指南在2.5条中提供。

7.2.9 软件生存周期环境控制

软件生存周期环境控制的目标是确定产生软件被标识、控制和检索所用到的工具。软件生存周期环境工具有软件计划过程定义并在软件生存周期环境配置索引（11.15条）中标明。指南包括：

a． 要对用于开发、控制、制作、检查和加载软件所用工具的可执行目标代码（或等效代码）确定配置标识。

b． 用于控制鉴定工具的SCM过程要符合12.2.3b中规定的与控制类1或2资料(7.3条)有关的目标。

c． 除7.2.9b适用外，对制作和加载软件（如编译程序、汇编程序、连接编辑器）所用工具的可执行目标代码（或等效代码）的控制，SCM过程最低要符合与控制类2资料有关的目标。

36

机载系统和设备合格审定中的软件考虑

7.3 资料控制类

软件生存周期资料可定义为以下两类：控制类1（CC1）和控制类2（CC2）。这些分类关系到资料的配置管理控制。表7－1定义了与每一个控制类有关的SCM过程目标。其中·表示这个目标使用于那一类的软件生存周期资料。

附件A中的表格通过软件等级为每一个软件生存周期资料项目规定了控制类别。对资料控制类的指南包括：

a． 对划分为CC1类的软件生存周期资料，SCM过程的目标要按表7－1实行； b． 对划分为CC2类的软件生存周期资料，SCM 过程的目标要按表7－1作为最低要求实行。

表7－1

与CC1和CC2资料有关的SCM过程目标

SCM过程目标 参考 CC1 CC2 配置标识 基线 可追踪性 问题报告 更改控制—完整性和标识 更改控制—追踪 更改评审 配置状态纪实 检索 防止未认可的更改 介质选择、更新、复制 发放 资料保存 7.2.1 7.2.2a、b、c、d、e 7.2.2f、g 7.2.3 7.2.4a、b 7.2.4c、d、e 7.2.5 7.2.6 7.2.7a 7.2.5b(1) 7.2.7b(2) 、(3) 、(4)、c 7.2.7d 7.2.7e · · · · · · · · · · · · · · · · · · · 8.0 软件质量保证过程

这一章讨论软件质量保证（SQA）过程的目标和活动。SQA过程在软件过程（第4章）和软件质量保证计划（11.5条）中定义。 SQA过程活动的输出是软件质量保证记录（11.19条）或其他软件生存周期资料中的记录。

SQA过程评估软件生存周期过程及其输出，以保证目标得以满足，故障得以检测、评估、追踪和解决，并保证软件产品和软件生存周期资料符合合格审定要求。 8.1 软件质量保证过程目标

SQA过程的目标是为软件生存周期过程产生的软件符合其需求提供置信度。这可通过保证完成这些过程符合批准的软件计划及标准来完成。

SQA过程的目标是保证：

a．软件开发过程和综合过程符合批准的软件计划和标准； b．满足软件生存周期过程的转换规则； c．进行软件产品的符合性评审。

依据软件等级，目标的适用性在附件A 的表A－9中规定。

37

机载系统和设备合格审定中的软件考虑

8.2 软件质量保证过程活动

为满足SQA过程目标：

a． SQA过程将在软件生存周期过程中主动进行，要使完成SQA过程的那些活动具有一定的权限、职责和独立性，以保证满足SQA过程的目标；

b． SQA过程将为开发和评审软件计划和标准的一致性提供保证；

c． SQA过程将为软件生存周期过程符合批准的软件计划和标准提供保证； d． SQA过程将包括在软件生存周期期间软件开发和综合过程的审核，以获得下列保证：

(1) 可采用4.2条*规定的软件计划;

*原文可能有误，译者认为应是4.3条。

(2) 对软件计划和标准的偏离得以检测、记录、评估、追踪和解决；

注：过程偏离的早期检测有助于软件生存周期过程目标的有效改进。

(3) 批准的偏离得以记录；

(4) 软件开发环境已在软件计划中规定；

(5) 问题报告、追踪和纠正活动过程符合软件配置管理计划；

(6) 通过进展中的系统安全性评估过程表明提供给软件生存周期过程的输入。

注：可完成对软件生存周期过程活动的检测，以提供活动在控制之下的保证。

e． SQA过程将依据批准的软件计划提供的软件生存周期过程的转换规则得以满足的保证。

f． SQA过程将依据7.3条定义的控制类别及附件A的表格提供控制软件生存周期资料的保证。

g． 在作为合格审定申请的一部分提交的软件产品交付之前，将进行软件符合性评审。

h． SQA过程将产生SQA过程活动的记录（11.19条）。对每一个作为合格审定申请一部分提交的软件产品，包括审核结果和完成软件符合性评审的证据。

8.3 软件符合性评审

软件符合性评审的目标是为作为合格审定申请一部分提交的软件产品获得软件生存周期过程得以完成、软件生存周期资料得以完成且可执行目标代码得以控制并能再生的保证。

这一评审要确定：

a． 为了合格审定的置信度，已经完成了预定的软件生存周期过程活动，包括软件生存周期资料的产生。完成它们的记录得以保存。

b． 从具体的系统需求、与安全性有关的需求或软件需求开发的软件生存周期资料能追踪到那些需求。

c． 软件生存周期资料符合软件计划和标准，并按照SCM计划进行控制。 d． 符合SCM计划的问题报告已经评估并且记录了它们的状态。 e． 软件需求偏离被记录和批准。

f． 可执行目标代码能从归档的源代码中重新产生。 g． 通过使用发布指令，成功地加载了批准的软件。

h． 来自以前软件符合性评审的问题报告被重新评估以确定它们的状态。 i． 如果合格审定的置信度用于以前开发的软件，那么目前的软件产品基线可追踪到以前的基线和对那个基线批准的更改。

注：对合格审定后的软件更改，可能要求完成一系列的软件符合性评审活动，这取决于更改的重要性。

38

机载系统和设备合格审定中的软件考虑

9.0 合格审定联络过程

合格审定联络过程的目标是在整个软件生存周期中在申请人和合格审定机构之间建立通信和相互了解,以有助于合格审定过程。

合格审定联络过程在软件计划过程（第4章）和软件合格审定计划（11.1条）中定义。附件A 的表A－10是这一过程的目标和输出的总结。

9.1 符合性方法和计划

申请人要建议确定机载系统或设备的开发怎样满足合格审定基础的符合性方法。软件合格审定计划（11.1条）定义了在建议的符合性方法内对机载系统或设备软件方面的内容。这个计划也规定了由系统安全性评估过程确定的软件等级。申请人要：

a． 提交软件合格审定计划或其它要求的资料到合格审定机构，以便在更改影响最小，即能在项目限制内预以控制的那一点及时评审。

b． 解决涉及计划软件合格审定的由合格审定机构指明的有争议的问题。 c． 得到合格审定机构对软件合格审定计划的认可。

9.2 符合性证明

申请人要提供软件生存周期过程满足软件计划的证据。合格审定机构的评审可发生在申请人的工厂或申请人的供应商工厂。这可能涉及到与申请人或其供应商讨论。申请人安排软件生存周期过程活动的这些评审并编制必要的有效的软件生存周期资料。申请人要：

a． 解决由合格审定机构评审结果引起的有争议的问题。 b． 向合格审定机构提交软件实施概要（11.20条）和软件配置索引（11.16条）。

c． 提交或编制合格审定机构要求的有效的其它资料或符合性证据。

9.3 提交给合格审定机构的最少软件生存周期资料

提交给合格审定机构的最少软件生存周期资料是： ·软件合格审定计划 ·软件配置索引 ·软件实施概要

9.4 与型号设计有关的软件生存周期资料

除非合格审定机构同意,否则关系到与型号设计有关的软件生存周期资料的检索和批准的条例适用于：

·软件需求资料 ·设计说明 ·源代码

·可执行目标代码 ·软件配置索引 ·软件实施概要

10.0 航空器或发动机合格审定综述

这一章是关系到机载系统和设备软件方面的航空器和发动机合格审定过程的

39

机载系统和设备合格审定中的软件考虑

综述，并仅提供信息。合格审定机构考虑到软件是安装在航空器和发动机上的机载系统或设备的一部分，即合格审定机构不把软件作为唯一的独立的产品加以批准。

10.1 合格审定基础

合格审定机构与申请人协商确定航空器或发动机的合格审定基础。合格审定基础要定义专用条例和可用来补充已出版条例的任何专用条件。

对已更改的航空器或发动机，合格审定机构考虑更改对航空器或发动机原始合格审定基础的影响。在某些场合，更改可能不改变原始的合格审定基础，然而，原始的符合性方法不再适用于表明更改是否符合合格审定基础。所以可能要求更改原始的符合性方法。

10.2 合格审定的软件方面

合格审定机构借助认可的满足合格审定基础的符合性方法来评定软件合格审定计划的完整性和一致性。合格审定机构要查明由申请人建议的软件等级是否符合系统安全性评估过程的输出及其它系统生存周期资料。合格审定机构通知申请人在合格审定机构同意前满足建议的软件计划中的争议性问题。

10.3 符合性确定

在合格审定之前,合格审定机构要确定航空器或发动机（包括其系统或设备的软件方面）满足的合格审定基础。对软件，可通过评审软件实施概要和符合性证据来完成。合格审定机构使用软件实施概要作为对软件方面进行合格审定的一个综述。

合格审定机构可在9.2条讨论的软件生存周期期间自行决定评审的软件生存周期过程及其输出。

11.0 软件生存周期资料

软件生存周期期间产生一些资料用于计划、指导、解释、定义、记录或提供活动的证据。这些资料能使软件产品的软件生存周期过程、系统或设备合格审定和合格审定后的更改得以进行。这一章讨论软件生存周期资料的特性、形式、配置管理控制及其内容。

软件生存周期资料的特性是：

a． 不含糊的 如果措词仅有唯一的解释，必要时借助于定义，那么信息是不含糊的。

b． 完整的 当它包括了必要的、相关的要求和 / 或说明材料；为有效输入资料的范围定义了响应；已标识了所用的图；定义了计量的术语和单位时，信息是完整的。

c． 可验证的 如果它可以由人或工具检查正确性，那么信息就是可验证的。 d． 一致的 如果在其中没有冲突，那么信息就是一致的。

e． 可更改的 如果它已是结构化的、有风格的，以致当保持这个结构时，能完整地、正确地完成更改，那么信息是可更改的。

f． 可追踪的 如果能够确定部件的原始情况，那么信息是可追踪的。 另外，指南适用于：

g． 形式 在机载系统或设备的整个使用期限内，为了有效地检索和评审软

40

本文来源：https://www.bwwdw.com/article/vam.html