RTCA-DO-178B机载系统和设备合格审定中的软件考虑(共84页).doc

《RTCA-DO-178B机载系统和设备合格审定中的软件考虑(共84页).doc》由会员分享，可在线阅读，更多相关《RTCA-DO-178B机载系统和设备合格审定中的软件考虑(共84页).doc（88页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上专心-专注-专业RTCA DO178B机载系统和设备合格审定机载系统和设备合格审定中的软件考虑中的软件考虑精选优质文档-倾情为你奉上专心-专注-专业签署和注记签署和注记签署签署姓名姓名签名签名精选优质文档-倾情为你奉上专心-专注-专业更改历史更改历史版本号版本号/修订号修订号更改单号更改单号发放日期发放日期作者作者更改描述更改描述精选优质文档-倾情为你奉上专心-专注-专业目录目录签名和注记签名和注记.2更改历史更改历史.31.0 引言（9）1.1 目的（9）1.2 范围（9）1.3 与其他文件的关系（9）1.4 怎样使用本文件（9）1.5 文件综述（10）2.0 与软

2、件开发有关的系统情况（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 软件生存周期环境

3、计划（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）8.1

4、 软件质量保证过程目标（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）1

5、1.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.

6、0 其它考虑（47）12.1 以前开发软件的使用（47）12.2 工具鉴定（49）12.3 替代方法（52）附件 A 按软件等级描述的过程目标和输出（56）附件 B 缩略语和术语汇编（66）附录 A DO178 文件的背景（72）附录 B 委员会全体成员（75）附录 C 术语索引（76）附录 D 改进建议表（81）图和表的清单图和表的清单图图图 11 文件综述（11）图 21 在系统和软件生存周期过程之间与系统安全性有关的信息流（12）图 31 使用四种不同开发顺序的软件项目的例子（19）图 61 软件测试过程（30）精选优质文档-倾情为你奉上专心-专注-专业表表表 71 与 CC1 和 CC

7、2 资料有关 SCM 过程目标（37）表 A1 软件计划过程（56）表 A2 软件开发过程（57）表 A3 软件需求过程输出的验证（58）表 A4 软件设计过程输出的验证（59）表 A5 软件编码和综合过程输出的验证（60）表 A6 综合过程输出的测试（61）表 A7 验证过程结果的验证（62）表 A8 软件配置管理过程（63）表 A9 软件质量保证过程（64）表 A10 合格审定联络过程 （65）AC 20115B（82）精选优质文档-倾情为你奉上专心-专注-专业精选优质文档-倾情为你奉上专心-专注-专业出版说明出版说明RTCA DO178B机载系统和设备合格审定中的软件考虑是美国航空无线电

8、技术委员会为支持含有数字计算机的机载系统和设备的研制工作而开发的软件开发过程中应遵循的准则。RTCA DO178B 适用于机载系统和设备中软件的开发和软件的合格审定。可供机载系统和设备（含软件）开发者使用，也可供合格审定机构审查使用。前言前言本文件由航空无线电技术委员会（RTCA）第 167 号特别委员会制订，由RTCA 于 1992 年 12 月 1 日批准。RTCA 是美国政府与工业界组成的一个航空组织。它致力于推动航空技术的发展，寻求解决在航空营运过程中使用电子设备和通讯设备所遇到问题的深入的精选优质文档-倾情为你奉上专心-专注-专业技术方法。其目标是通过其成员和参加组织来协商解决这种问

9、题的方法。RTCA 的研究成果对所有有关的组织来说是推荐性的。RTCA 不是美国政府的官方机构，除非联邦政府组织或机构对推荐的有关内容声明有法定效力，否则其推荐内容可在官方政府政策的阐述中不予考虑。这些指南的开发是由 RTCA 的 SC167 特别委员会与欧洲民用航空电子组织（EUROCAE）的 WG12 工作组通过协调共同完成的。RTCA DO178B制订：制订：SC167日期：日期：1992.12.1机载系统和设备合格审定中的软件考虑机载系统和设备合格审定中的软件考虑精选优质文档-倾情为你奉上专心-专注-专业1.0 引言引言早在二十世纪八十年代，在航空器和发动机上所用的机载系统和设备中，对

10、软件的使用迅速增加，从而导致了要求有一个工业可接受的指南，以满足适航性要求。制定 DO178机载系统和设备合格审定中的软件考虑就是为了满足这个要求。现在，按经验修订的本文件，以可协调的方法和可接受的置信度，为航空界确定机载系统和设备中的软件是否符合适航要求提供了指南。由于软件使用的增加、技术发展和本文件使用中获得的经验，本文件将被评审和修订。附录 A 说明了本文件的历史情况。1.1 目的目的本文件的目的是为机载系统和设备中的软件开发提供指南，以使软件在安全方面以一定的置信度完成其预定功能，并符合适航要求。这些指南是：软件生存周期中各过程的目标为达到这些目标所进行的活动和设计考虑的说明表明这些目

11、标已达到的证据的说明1.2 范围范围本文件讨论了涉及到航空器和发动机上所用机载系统和设备中的软件开发过程中的适航性合格审定方面的问题。在讨论这些问题中，说明系统生存周期及其与软件生存周期之间的关系有助于理解合格审定过程，但并不打算对包括系统安全性评估和确认过程或航空器和发动机合格审定过程中各个过程有一个完整的说明。由于讨论的合格审定问题仅与软件生存周期有关，所以不讨论最终软件运行的问题。例如，用户可更改资料的合格审定就超出了本文件的范围。本文件不为申请人的组织机构、申请人及其供应商之间的关系或责任如何划分提供指南。人员资格准则也超出了本文件的范围。1.3 与其他文件的关系与其他文件的关系除了适

12、航性要求之外，可以使用不同国家的和国际的软件标准。在一些团体中，可能要求软件符合这些标准。然而，引用具体的国家或国际标准，或者建议使用这些标准做为本文件的替代或补充，均超出了本文件的讨论范围。在本文件使用“标准”这一术语之处，应理解为机载系统、机载设备、发动机或航空器制造商使用的具体工程标准。这样的标准可能来自制造商为其活动所编制的或采纳的通用标准。1.4 怎样使用本文件怎样使用本文件当使用本文件时，应注意下列几点：本文件包括说明性内容，以帮助读者理解讨论的主题。例如，第 2 章提供的信息对理解系统生存周期和软件生存周期之间的联系是必需的。同样，第 3 章是对软件生存周期的说明。第 4 章是航

13、空器和发动机合格审定的综述。本文件准备供国际上的航空团体使用。为了有助于这样的使用，应尽量减少引用具体国家的条例和规章，并使用通用的术语。例如，使用的术语“合格审定机构”意指以国家的名义负责航空器或发动机合格审定并给予批准的组织或人员。在第二国或国家集团批准或参与该合格审定之处，如果承认已签订的双边协精选优质文档-倾情为你奉上专心-专注-专业议或涉及到国家之间双边谅解的备忘录，那么可以使用本文件。本文件承认这个指南不是由法律强制的，而是代表了航空团体的意见。它也承认，对申请人来说，用其他方法代替这里描述的方法也是可以的。鉴于这些原因，避免使用像“应”和“必须”这样的词。本文件说明了软件等级的目

14、标，正象 2.2.2 条定义的那样。附件 A 通过软件等级规定了这些目标的变化。如果申请人采用本文件做为合格审定之用，那么它可以作为达到这些目标的一套指南。第 11 章包括通常产生的资料，以帮助软件合格审定过程。文中资料的名称通过该名称每一个字的第一字母的大写注明。如源代码（Source Code） 。第 12 章讨论了其它的一些考虑，包括以前开发软件的使用、工具鉴定和第2 章到第 11 章规定方法的替代方法使用指南。第 12 章并不是对每一个合格审定都适用。软件等级变化表和术语汇编包含在附件中，并且是本文件的正式部分。其它材料包括在附录中，它是本文件的非正式部分。 在使用例子来表明怎样使用本

15、指南的场合，无论图示还是从头到尾的叙述，不要把这些例子理解为是更好的方法。项目清单并不意味着这个清单包括所有一切。本文件使用注来提供解释性材料，强调一点或图，使人们注意不完全在上下文中的相关内容。注不包含指南。1.5 文件综述文件综述图 11 是文件各章及其相互关系的一个图示。2.0 与软件开发有关的系统情况与软件开发有关的系统情况这部分讨论对理解软件生存周期过程所必需的系统生存周期过程的一些情况。主要有：在系统和软件生存周期过程之间资料的交换（2.1 条）失效状态分类、软件等级定义和软件等级的确定（2.2 条）系统结构考虑（2.3 条）系统对用户可更改条件、可选择选项软件和商用成品软件的考虑

16、（2.4 条）系统设计对外场可加载软件的考虑（2.5 条）系统需求对软件验证的考虑（2.6 条）系统验证中对软件的考虑（2.7 条）与软件开发有关的系统情况第 2 章航空器和发动机合格审定综述第 10 章精选优质文档-倾情为你奉上专心-专注-专业图 11 文件综述2.1 系统和软件生存周期过程之间的信息流系统和软件生存周期过程之间的信息流图 21 是系统生存周期过程和软件生存周期过程之间的安全性方面的信息流综述。由于系统的安全性评估过程和系统设计过程是相互关联的，所以在这些部分描述的信息流是重叠的。注：在本文件出版的时候，对系统生存周期过程的指南正由一个国际委员会编制。尽管用各种办法力图保持过

17、程之间的信息流和定义的兼容性，但在最终出版的文件间可能还存在一些差异。任何差异将在未来的文件修订中进行协调。软件生存周期过程软件生存周期第 3 章软件计划过程第 4 章软件开发过程第 5 章综合过程软件验证第 6 章软件配置管理第 7 章软件质量保证第 8 章合格审定联络第 9 章软件生存周期资料第 11 章其它考虑第 12 章精选优质文档-倾情为你奉上专心-专注-专业图 21 在系统和软件生存周期过程之间与系统安全性有关的信息流2.1.1 从系统过程到软件过程的信息流系统安全性评估过程要确定系统的失效状态并对之进行分类。在系统安全性评估过程中，系统设计分析要定义希望避免这些失效状态的与安全性

18、有关的要求及系统对这些失效状态的响应。对软件和硬件规定的这些要求要清除或限制故障的影响，并可提供故障检测和故障容差。当在硬件设计过程和软件开发过程中做这些决策时，系统安全性评估过程要分析最终的系统设计以验证它是否满足与安全有关的要求。与安全有关的要求是系统需求的一部分，作为软件生存周期过程的输入。为了保证在整个软件生存周期中合理地实现与安全性有关的要求，系统需求主要应包括或引用：系统说明和硬件定义合格审定要求，包括适用的联邦航空条例（FAR美国） 、联合适航要求 （JAR欧洲） 、咨询通报（AC美国）等分配给软件的系统需求，包括功能要求、性能要求和与安全性有关的要求软件等级及确定它们的资料、失

19、效状态及其类别、分配给软件的有关功能安全性策略和设计限制，包括设计方法。如划分、非相似性、冗余或安全性监控当该系统是另外一个系统的一部分时，那个系统的与安全性有关的要求和 适航性要求 系统运行要求系统生存周期过程系统安全性评估过程分配给软件的系统需求软件等级设计限制硬件定义软件生存周期过程故障限制范围标明的 / 消除的错误源软件需求和结构精选优质文档-倾情为你奉上专心-专注-专业失效状态系统生存周期过程可以规定对软件生存周期过程的要求，这样有助于系统的验证活动2.1.2 从软件过程到系统过程的信息流利用软件生存周期过程提供的信息，系统安全性评估过程要确定软件设计和实施对系统安全性的影响。这些信

20、息包括故障限制范围、软件需求、软件结构和在软件设计过程中通过使用工具或其它方法检测或消除的软件结构中的错误源。在系统需求和软件设计资料之间的可追踪性对系统安全性评估是重要的。对软件的更改可能会影响到系统的安全性，所以必须明确用于评估的系统安全性评估过程。2.2 失效状态和软件等级失效状态和软件等级下列指南涉及到系统失效状态分类、软件等级的定义、软件等级和失效状态类别之间的关系和如何确定软件等级。系统失效状态的类别是通过确定失效状态对航空器及其乘客的危害度来确定的。软件错误可能引起导致失效状态的故障，因此，对安全操作是必需的软件等级的完整性关系到系统的失效状态。2.2.1 失效状态类别为了全面地

21、定义失效状态的类别，可参考有关的条例和指导性材料、联邦航空局 AC 2513091A 和 / 或联合航空管理局 AMJ251309 及其修订内容。列举的失效状态是从这些指南材料中引伸过来的并包括了其中的类别，以利于本文件的使用。这些类别是：a.灾难性的 阻止继续安全飞行和着陆的失效状态。b.危险的 / 严重的 降低航空器的性能和机组人员克服不利操纵状态的能力的失效状态。这些不利操纵状态达到的程度是：（1）大大降低了安全性余量或功能能力；（2）身体疲劳或高负荷使飞行机组不能精确或完整地完成他们的任务；或（3）对乘客的不利影响，包括对少数乘客严重的或潜在的致命伤害。c.较重的 可能降低航空器的性能

22、和机组人员克服不利操纵状态的能力的失效状态。这些不利操纵状态达到的程度如：较大地降低安全余量或功能能力、较大地增加了机组人员的工作量或削弱机组人员工作效率的状态，或造成乘客不舒服，可能包括伤害。d.较轻的 不会严重降低航空器安全性及有关机组的活动在他们的能力内能很好完成的失效状态。较轻的失效状态可能包括：如稍微减少安全余量或功能能力；稍微增加机组人员的工作量，如航线飞行计划更改或乘客的某些不方便。e.无影响的 不影响航空器的工作性能或不增加机组工作量的失效状态。2.2.2 软件等级定义软件等级是基于在系统安全性评估过程中确定的软件对潜在失效状态的影响。软件等级意味着用来表明符合合格审定要求的努

23、力程度随失效状态的类别而变化。这些软件等级的定义是：a.A 级 可能引起或导致系统功能失效进而引起航空器灾难性失效状态的精选优质文档-倾情为你奉上专心-专注-专业异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。b.B 级 可能引起或导致系统功能失效进而引起航空器危险的/严重的失效状态的异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。c.C 级 可能引起或导致系统功能失效进而引起航空器较重失效状态的异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。d.D 级 可能引起或导致系统功能失效进而引起航空器较轻失效状态的异常状态的软件，这种异常状态可通过系统安全性评估过

24、程来表明。e.E 级 可能引起或导致系统功能失效的异常状态的软件。这种异常状态可通过系统安全性评估过程来表明。它不会影响航空器的工作性能或驾驶员工作量。一旦软件由合格审定机构定位 E 级，本文件就不再提供进一步的指南。2.2.3 软件等级确定 系统安全性评估过程首先要确定与特定系统中的软件有关的软件等级，而不考虑系统设计。当做这个决定时，必须表明失效的影响，无论是功能丢失还是故障。 注：（1）在进一步的开发过程中，申请人可能考虑增加的功能能力以及可能导致更严重的失效状态类别和更高软件等级的分配给软件的系统需求中潜在的更改，可能希望开发的软件能达到高于原申请人在系统安全性评估过程中确定的软件等级

25、，因为为了证实较高的软件等级的应用，软件生存周期资料的后续开发可能是困难的。( 2）对由运行条例管理的机载系统和设备，只要不影响航空器的适航行性，如事故飞行数据记录仪，软件等级要与预定功能相匹配，在某些场合，可在设备最低性能标准中规定软件等级。 如果软件部分的异常状态引起多个失效状态，那么那个部件的最严重的失效状态类别决定了那个软件部件的软件等级。在系统设计评估过程中，如在 2.3 中规定的那些，存在可能导致软件等级被更改的结构方法。 系统功能可以分配到一个或多个已划分的软件部件中，并行实施是用多个软件部件来实现一个系统功能。这样，只有多个部件的异常状态才能产生一个失效状态。对并行实施，至少有

26、一个软件部件具有与那个系统功能最严重的失效状态相应的软件等级，其它部件的软件等级使用与那个功能丢失有关的失效状态类别来确定。这种实施的例子在 2.3.2 条多版本非相似软件和 2.3.3 条安全性监控中预以描述。 一个系统功能亦可用多个软件部件来串行实施。这样，任何部件的异常状态都能产生失效状态。在这种实施中，软件部件将具有与系统功能的最严重的失效状态类别相应的软件等级。开发某一等级的软件并不意味着对那个软件失效率的分配。这样，软件等级或基于软件等级的软件可靠率（reliability rates）不能象硬件失效率那样在系统安全性评估过程中使用。不符合 2.2.3 条指南的方法需要通过系统安全

27、性评估过程来证明是正确的。2 23 3 系统结构考虑系统结构考虑如果系统安全性评估过程确定系统结构可消除可能导致系统最严重失效状态的软件的异常状态，那么要根据引起软件异常状态的失效状态的最严重类别来确定软件等级。系统安全性评估过程考虑了结构设计方法，以确定它们是否影响软件等级或软件的功能性。本指南提供了几种结构方法，它们可限制错误的影响或利于检测错误和对某些错误提供可接受的系统响应。这些结构技术不要理解为是更好的或要求的方法。精选优质文档-倾情为你奉上专心-专注-专业2.3.1 划分划分是在功能上独立的软件部件之间提供隔离的技术，以确定和/或隔离故障，并潜在地减少软件验证过程的工作量。如果通过

28、划分提供了保护，那么对每一个划分的软件等级，可使用与那个部件相关的最严重的失效状态类别来确定。 对划分的指南包括：a. 当设计了划分保护时，要考虑系统的下列方面，以确定它们是否防碍了那个保护：（1）硬件资源 处理器、存储器设备、输入 / 输出设备、中断和定时器；（2）控制耦合器 外部存取易损性；（3）数据耦合器 共享或重复占位数据，包括堆栈和处理器寄存器；（4）与保护机制相关的硬件设备的失效模式。b. 软件生存周期过程要表明划分的设计考虑，包括划分的部件之间允许的内部连接的程度和范围，无论保护是通过硬件还是通过软件和硬件的组合来实现的。c. 如果划分保护涉及到软件，那么软件的等级要与划分的软件

29、部件的最高等级相对应。2.3.2 多版本非相似软件多版本非相似软件是系统设计技术，它涉及到产生两个或更多的软件部件。这些部件以可在部件间避免某些共同错误源的方式提供同样的功能。多版本非相似软件也称为多版本软件、非相似软件、N 版本程序设计或软件多样性。在非相似性引入到开发之前，完成的或进行的软件生存周期过程保留了潜在的错误源。系统需求规定了执行多版本多版本非相似软件提供的硬件配置。非相似的程度进而防护的程度通常是不可计量的。系统功能丢失的可能性将增加到这样的程度，即与非相似软件版本相关的安全性监控能检测到实际的错误或超过比较器门限的经验瞬变。所以，通常使用非相似软件版本作为某等级的软件在其验证

30、过程目标（正象第 6 章规定的那样）被满足之后提供附加保护的手段。对非相似软件验证方法，如果它能表明系统功能的最终潜在失效通过系统安全性评估过程能确定是否可以接受，那么它可以减少验证单一版本软件时所用的那些方法。多版本非相似软件的验证在 12.3.3 条中讨论。2.3.3 安全性监控安全性监控是通过直接检测可能引起失效状态的功能失效而防止具体失效状态的一种手段。监控功能可通过硬件、软件或硬件和软件的组合来实现。通过监控技术的使用，所监控的功能的软件等级可以降低到与其相关的系统功能的失效相应的等级。为了允许这个等级的降低，要确定三个重要的属性：a. 软件等级 安全性监控软件的软件等级要与被监控功

31、能的最严重的失效状态类别相对应。b. 系统故障范围 监控器的系统故障范围的评估要确保监控器的设计和实施能使想要检测的故障在所有必要的条件下得以检测。c. 功能和监控器的独立性 监控器和防护措施不会由于引起这种危害的同一失效状态而不予动作。精选优质文档-倾情为你奉上专心-专注-专业2 24 4 系统对用户可更改软件、可选择选项软件和商用成品软件的考虑系统对用户可更改软件、可选择选项软件和商用成品软件的考虑用户更改的潜在影响由系统安全性评估过程确定，并用于开发软件需求和软件验证过程的活动。在 5.2.3 条中，进一步讨论用户可更改软件的设计。影响不可更改的软件、它的保护或可更改软件界限的更改是一种

32、软件更改，并在 12.1.1条中讨论。在本文件中，可更改部件是准备由用户更改的软件的那部分，不可更改部件是不准备由用户更改的软件的那一部分。一些机载系统和设备可包括选择性的功能。它是由软件编程来选项，而不是通过硬件连接器引脚来选择，可选择选项的软件功能用于在目标机中选择特定的配置。对无效码的指南见 5.4.3 条。系统对用户可更改软件、可选择选项软件和商用成品软件进行考虑的指南包括：a. 用户可更改软件 如果系统需求中提供了用户更改，那么用户可在更改限制范围内修改软件，而无需经过合格审定机构的评审。b. 系统需求将规定防止用户更改影响到系统安全性而没有正确实施更改的方法。为用户更改提供保护的软

33、件将具有与防止更改部件出错的功能软件一样的等级。c. 如果系统需求不包括用户更改的条款，除非证明更改符合本文件，否则软件不得由用户更改。d. 在用户更改时，用户要对用户可更改软件的所有方面负责。例如软件配置管理、软件质量保证和软件验证e. 可选择选项软件 当包括编程选项的软件时，要提供手段确保不会为安装环境中的目标机偶然选择到涉及未经批准的配置。f. 商用成品软件 包括在机载系统或设备中的商用成品软件要满足本文件的目标。g. 如果在商用成品软件的软件生存周期资料中存在缺项，那么要增加资料，以满足本文件的目标。12.1.4 条开发基线升级和 12.3.5产品服务历史的指南与这种情况有关。2 25

34、 5 系统设计对外场可加载软件的考虑系统设计对外场可加载软件的考虑外场可加载机载软件是无需把系统或设备从它安装位置上拆下来即可装入的软件或数据表。与软件数据加载功能相关的有关安全性的需求是系统需求的一部分。如果软件数据加载功能可能偶然会引起系统失效状态，那么对于软件数据的加载功能，与安全性有关的要求要在系统需求中规定。与外场可加载软件有关的系统安全性考虑包括：不可靠的或部分加载的软件的检测加载不合适软件的影响的确定硬件/软件兼容性软件/软件兼容性航空器/软件兼容性外场加载功能的偶然使能软件配置标识显示的丢失或不可靠对外场可加载软件的指南包括：a. 除非由系统安全性评估过程证明是正确的，否则部分

35、或不可靠软件加载的检测机制要有与软件加载功能有关的最严重的失效状态或软件等级一样的失效精选优质文档-倾情为你奉上专心-专注-专业状态或软件等级。b. 如果当不合适的软件或数据加载时系统有一个缺省模式，那么在这个模式表明的潜在失效状态中，系统的每一个划分部件要有为运行规定的与安全性有关的需求。c. 软件加载功能，包括支持系统和过程，要包括检测不正确软件和/或硬件和/或航空器组件的手段，并对功能的失效状态提供合适的保护。d. 如果软件是确保航空器符合合格审定配置的机载显示方法的一部分，那么该软件要么按最高级软件开发并加载，要么系统安全性评估过程要能够说明软件配置标识的不断检查的完整性。2 26 6

36、 系统需求对软件验证的考虑系统需求对软件验证的考虑根据系统运行要求和由系统安全性评估过程产生的与安全性有关的要求来开发系统需求。考虑包括：a. 机载软件的系统需求要确定软件的两个特性：（1）软件完成了系统需求中定义的指定功能；（2）软件没有呈现出系统安全性评估过程确定的具体的异常状态。为了消除异常状态，要求增加系统需求。b. 这些系统需求进而发展到由软件验证过程活动验证的软件高级需求。2 27 7 系统验证中的软件考虑系统验证中的软件考虑系统验证的指南超出了本文件的范围。然而，软件生存周期过程可帮助系统验证过程并与系统验证过程相互作用。与系统功能性相关的软件设计细节也可用于帮助系统验证。系统验

37、证可提供代码结构的主要覆盖范围。可使用系统验证测试的覆盖范围分析来实现软件验证中说明的各种不同测试活动的覆盖范围的目标。3 30 0 软件生存周期软件生存周期本章讨论软件生存周期过程、软件生存周期定义和软件生存周期过程之间的转换准则。本文件的指南并未描述一个特定的软件生存周期，而是描述了大多数生存周期的分离的过程及其间的相互联系。过程的分离并不打算表明完成他们的组织结构。对每一个软件产品，要构造包括这些过程的软件生存周期。3 31 1 软件生存周期过程软件生存周期过程软件生存周期过程是：软件计划过程 定义并协调一个项目的软件开发和综合过程的活动。第 4章描述了软件计划过程。软件开发过程 这些过

38、程是软件需求过程、软件设计过程、软件编码过程和综合过程。第 5 章描述了软件开发过程。综合过程 保证软件生存周期及其输出正确、受控和可信。综合过程是软件验证过程、软件配置管理过程、软件质量保证过程和合格审定联络过程。在整个软件生存周期中，了解同软件开发过程同时完成的综合过程是重要的。第69 章描述了综合过程过程。3 32 2 软件生存周期定义软件生存周期定义精选优质文档-倾情为你奉上专心-专注-专业通过选择每一个过程的活动、规定活动的顺序和分配给活动的责任，一个项目可以定义一个或多个软件生存周期。对一个具体项目，由项目的特性来确定这些过程的顺序，如系统功能性和复杂性，软件大小和复杂性，需求稳定

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

40、使用环境中进行评估。评估结果被用来改进需求。软件生存周期过程可反复迭代，即进入和再进入。迭代的时机和程度随系统功能、复杂性、需求开发、硬件可用性、对以前过程的反馈和项目的其它特征的进一步开发而变化。选择的软件生存周期的各个不同部分与进一步的综合过程和软件验证的活动紧密连在一起。3 33 3 过程之间的转换准则过程之间的转换准则使用转换准则来确定一个过程是否可以进入或再进入。每一个软件生存周期过程完成输入到产生输出的活动。一个过程可对其他过程产生反馈，并从其他过程接受反馈。反馈的定义包括如何通过接受过程识别、控制和处理信息。一个反馈定义的例子是问题报告。转换准则将取决于软件开发过程和综合过程的预

41、定顺序，并且可能会受到软件等级的影响。可供选择的转换准则的例子是：已完成的软件验证过程评审；输入是一个被标识的配置项；完成了输入的可追踪分析。如果为过程确定的转换准则是满意的，那么过程的每一个输入不必在过程开始前完成。指南包括：a. 如果一个过程对部分输入起作用，那么要检查过程的后续输入以确定软件开发和软件验证过程的以前的输出仍然有效。精选优质文档-倾情为你奉上专心-专注-专业分配给软件的系统需求 软件部件： RDCI 部件 W RI 部件 X RCI 部件 Y 部件 Z RCICIRDCI 代号 软件产品 R = 需求 C = 编码 D = 设计 I = 综合 注：为了简单，并未表明软件计划

42、和综合过程 图 31 使用四种不同开发顺序的软件项目的例子40 软件计划过程软件计划过程本章讨论软件计划过程的目标和活动。这个过程产生指导软件开发过程和综合过程的软件计划和标准。附件 A 的表 A1 是各级软件的软件计划过程的目标和输出的总结。4 41 1 软件计划过程目标软件计划过程目标软件计划过程的目标是定义产生满足系统需求并提供与适航要求相一致的置信度水平的软件方法。软件计划过程的目标是：a.定义表明系统需求和软件等级的软件生存周期的软件开发过程和综合过程精选优质文档-倾情为你奉上专心-专注-专业的活动（4.2 条）b.确定软件生存周期，包括过程之间的内部关系、它们的顺序、反馈机理和转换

43、准则（第 3 章） 。c.选择软件生存周期环境，包括用于每一个软件生存周期过程活动的方法和工具（4.4 条） 。d.其它考虑。如果必要，可提出如第 12 章 1 讨论的那些。e.定义与被生产软件的系统安全目标相符的软件开发标准。f.编制了符合 4.3 条和第 11 章的软件计划。g.协调软件计划的开发和修订。4 42 2 软件计划过程活动软件计划过程活动有效的计划是生产的软件满足本文件指南的决定因素。软件计划过程的指南包括：a. 软件计划要及时地在软件生存周期的某一点予以开发，以便及时地为完成软件开发过程和综合过程的人员提供指导。也可参见 9.1 条。b. 要明确或选择用于项目的软件开发标准c

44、. 要选择在软件开发过程中提供防止错误的方法和工具。d. 软件计划过程将在软件开发和综合过程之间提供协调，以保证在软件计划中的策略之间保持一致。e. 软件计划过程要包括随项目进展修订软件计划的方法。f. 在系统中使用多版本非相似软件时，软件计划过程要选择满足系统安全性目标所必需的避免错误或进行必要检测的方法和工具。g. 对将被完成的软件计划过程，软件计划和软件开发标准要在更改控制之下并完成对它们的评审（4.6 条） 。h. 如果准备使用无效码（2.4 条） ，软件计划过程将描述怎样定义验证和处理无效码（选择的选项、飞行试验） ，以达到系统安全性目标。i. 如果准备使用用户可更改代码，在软件计划

45、和标准中将规定证实 5.2.3 条指南的过程、工具、环境和数据项。如果计划和方法对具体的过程活动是可用的，那么其它软件生存周期过程可在软件计划过程完成之前开始。4 43 3 软件计划软件计划软件计划的目标是确定满足本文件目标的方法。它们规定了将完成那些活动的组织。软件计划是：软件合格审定计划（11.1 条）为征得合格审定机构对建议的开发方法的同意而与其进行联络的主要手段，并且定义了符合本文件的方法软件开发计划（11.2 条）定义了软件生存周期和软件开发环境软件验证计划（11.3 条）定义了满足软件验证过程目标的方法软件配置管理计划（11.4 条）定义了满足软件配置管理过程目标的方法软件质量保证

46、计划（11.5 条）定义了满足软件质量保证过程目标的方法软件计划的指南包括：a. 软件计划要符合本文件。b.b. 软件计划要定义规定的软件生存周期过程之间的转换准则；（1）过程的输入，包括从其它过程的反馈；精选优质文档-倾情为你奉上专心-专注-专业（2）可能需要的对这些输入起作用的任何综合过程的活动；（3）工具、方法、计划和规程的可用性。c. 在合格审定的航空器或发动机上使用之前，软件计划要表明用于实施软件更改的规程。这种更改可能是由于其它过程的反馈的结果，且可能引起软件计划的更改。4 44 4 软件生存周期环境计划软件生存周期环境计划对软件生存周期环境，计划的目标将用于定义开发、验证、控制和

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

48、地响应输入数据错误，并防止输出和控制错误。用系统需求和系统安全性评估过程确定对错误防护或故障容错方法的要求。上述考虑可能影响到：软件需求过程和软件设计过程中所用的方法和表示法软件编码过程使用的程序设计语言和方法软件开发环境工具软件验证和软件配置管理工具工具鉴定要求（12.2 条）4.4.1 软件开发环境软件开发环境是生产高质量软件的主要因素。软件开发环境可以几种方式对机载软件的生产产生不利影响。例如，编译程序可通过产生一个错误输出而引入错误，或者连接器不能暴露出表现出来的存储器分配错误。选择软件开发环境方法和工具的指南包括：a. 在软件计划过程期间，选择的软件开发环境要把最终机载软件的潜在风险

49、减至最小。b. 要选择有资格的工具或工具的组合以及软件开发环境的部件的使用，以便由另一个部件检测到的某个部件引入的错误能达到必要的置信度水平。当两个部件同时一起使用时，能产生一个可接受的环境。c. 定义的软件验证过程活动或软件开发标准，包括对软件等级的考虑，要使与软件开发环境有关的潜在错误减至最少。d. 对组合工具的使用，如果寻求合格审定置信度，那么工具操作的顺序要在有关计划中规定。e. 如果在项目使用中选择了软件开发工具的可选择特性，那么选项的效果要加以检查并在有关计划中规定。注：工具直接产生软件产品的一部分是特别重要的。在本文中，编译程序可能是考虑的最重要的工具。精选优质文档-倾情为你奉上

50、专心-专注-专业4.4.2 语言和编译程序考虑在成功地完成软件产品的验证时，要考虑编译程序对那个产品的可接受性。为了确认这一点，软件验证过程活动要考虑编程语言和编译程序的特殊特征。当选择编程语言和计划验证时，软件计划过程要考虑这些特征。指南包括：a. 一些编译程序具有优化目标代码性能的特征。如果测试用例给出的覆盖范围与软件等级一致，那么不需要验证优化的正确性，否则这些特征对结构覆盖范围分析的影响要按 6.4.4.2 条的指南来确定。b. 为了实施某些特征，对一些语言的编译程序可能产生不能直接追踪到源代码的目标代码，例如初始化、机内错误检测或异常处理(6.4.4.2 条 b 项)。软件计划过程要