1、DO254标准编译稿 RTCA/DO254标准机载电子设备硬件的设计保证指南二00八年四月目 录前 言本文件由航空无线电委员会（RTCA）180专委会（SC-180）制订，并于2000年4月19日由RTCA项目管理委员会批准通过。本指南是RTCA SC-180和EUROCAE（欧洲民用航空设备组织）WG-46在协商一致的基础上共同编写完成的。RTCA公司是一家非营利性的组织，其宗旨是推进航空和航空电子系统科学与技术的发展，为公众的福祉服务。本组织起到了联邦顾问委员会的作用，并就当前航空方面的议题提出一致通过的建议。RTCA的目标包括但并不仅限于： 结合航空系统用户和供应商的技术要求，帮助政府和
2、企业实现和履行彼此的目标及职责； 对航空业界在追求更高安全、系统性能和效能时所面临的系统技术问题进行分析，并提供解决方案； 推进相关技术应用的通过，以满足用户和供应商的要求，包括支持飞行的电子系统和设备的最低工作性能标准的制定； 帮助制定相关技术资料，以此确定国际民航组织、国际电信联盟以及其它感兴趣的国际组织的地位。本组织的建议通常被政府和民间组织作为决策的依据，并且还是众多联邦航空管理技术标准规程的基础。由于RTCA并不是美国政府的官方代理机构，本组织的建议未经美国政府或在这些建议所涉及到的任何问题上拥有法定权限的组织公布，不能被认定为官方政策。执行概要航空业界中复杂电子设备的使用和研发引起
3、了新的安全和验证问题。为解决此问题，成立了RTCA SC-180和EUROCAE WG-46。RTCA SC-180和EUROCAE WG-46早在制订本文件时就已同意并组成了联合委员会。该联合委员会经特许为机载电子设备制定清晰和一致的设计保证指南，从而使机载电子设备可安全地发挥其既定功能。机载电子设备包括线可替代单元、电路板组件、专用集成电路、可编程逻辑器件等。本指南适用于现有的、新的以及刚出现的技术。前 言本文件由航空无线电委员会（RTCA）180专委会（SC-180）制订，并于2000年4月19日由RTCA项目管理委员会批准通过。本指南是RTCA SC-180和EUROCAE（欧洲民用航
4、空设备组织）WG-46在协商一致的基础上共同编写完成的。RTCA公司是一家非营利性的组织，其宗旨是推进航空和航空电子系统科学与技术的发展，为公众的福祉服务。本组织起到了联邦顾问委员会的作用，并就当前航空方面的议题提出一致通过的建议。RTCA的目标包括但并不仅限于：结合航空系统用户和供应商的技术要求，帮助政府和企业实现和履行彼此的目标及职责；对航空业界在追求更高安全、系统性能和效能时所面临的系统技术问题进行分析，并提供解决方案；推进相关技术应用的通过，以满足用户和供应商的要求，包括支持飞行的电子系统和设备的最低工作性能标准的制定；帮助制定相关技术资料，以此确定国际民航组织、国际电信联盟以及其它感
5、兴趣的国际组织的地位。本组织的建议通常被政府和民间组织作为决策的依据，并且还是众多联邦航空管理技术标准规程的基础。由于RTCA并不是美国政府的官方代理机构，本组织的建议未经美国政府或在这些建议所涉及到的任何问题上拥有法定权限的组织公布，不能被认定为官方政策。执行概要航空业界中复杂电子设备的使用和研发引起了新的安全和验证问题。为解决此问题，成立了RTCA SC-180和EUROCAE WG-46。RTCA SC-180和EUROCAE WG-46早在制订本文件时就已同意并组成了联合委员会。该联合委员会经特许为机载电子设备制定清晰和一致的设计保证指南，从而使机载电子设备可安全地发挥其既定功能。机载
6、电子设备包括线可替代单元、电路板组件、专用集成电路、可编程逻辑器件等。本指南适用于现有的、新的以及刚出现的技术。本文件中的指导措施将供飞机系统所用的电子硬件项的供应商和飞机生产商使用。文件中确定了硬件设计生命周期进程，并对每一进程的目标和活动进行了描述。本指南适用于所有的硬件保证等级（由系统安全评估确定）。在本文件的制定进程中，委员会参考了其它的业内文件，包括美国动力机械工程师协会（SAE）航空推荐准则(ARP)文件ARP4754/EUROCAE ED-79、高度集成或复杂飞机系统的验证准则、民航系统及设备的安全评估进程实施方针及方法以及RTCA DO-178/EUROCAE ED-12机载系
7、统及设备验证的软件考虑因素。目 录1 导言 11.1 目的 11.2 范围 11.3 与其它文件的关系 21.4 相关文件 31.5 如何使用本文件 31.6 复杂性考虑 41.7 其它方法或进程 51.8 文件概览 52 系统方面的硬件设计保证 72.1 信息流 82.1.1 从系统开发进程到硬件设计生命周期进程的信息流 82.1.2 从硬件设计生命周期进程到系统开发进程的信息流 92.1.3 硬件设计生命周期进程与软件生命周期进程之间的信息流 92.2 系统安全评估进程 92.3 硬件安全评估 132.3.1 硬件安全评估考虑事项 132.3.2 随机硬件故障的定量分析 142.3.3 硬
8、件设计失误及推翻的定性评估 142.3.4 关于硬件故障情况分类的设计保证考虑事项 153 硬件设计生命周期 183.1 硬件设计生命周期进程 183.2 过渡标准 184 计划进程 194.1 计划进程目标 194.2 计划进程活动 195 硬件设计进程 215.1 要求捕获进程 235.1.1 要求捕获目标 235.1.2 要求捕获活动 235.2 概念设计进程 245.2.1 概念设计目标 255.2.2 概念设计活动 255.3 详细设计进程 255.3.1 详细设计目标 255.3.2 详细的设计进程活动 265.4 实施进程 265.4.1 实施目标 275.4.2 实施活动 27
9、5.5 生产转换进程 275.5.1 生产转换目标 275.5.2 生产转换活动 285.6 验收测试 285.7 连续生产 296 鉴定与验证进程 306.1 鉴定进程 306.1.1 鉴定进程目标 306.1.2 鉴定进程活动 316.2 验证进程 316.2.1 验证进程目标 326.2.2 验证进程活动 326.3 鉴定和验证方法 336.3.1 测试 336.3.2 分析 346.3.3 审核 356.3.3.1 要求审核 356.3.3.2 设计审核 377 配置管理进程 397.1 配置管理目标 397.2 配置管理活动 397.2.1 配置识别 397.2.2 原始资料的建立
10、407.2.3 问题报告、跟踪和纠正行为 407.2.4 更改控制 417.2.5 发布、归档以及检索 427.3 数据控制类别 428 进程保证 448.1 进程保证目标 448.2 进程保证活动 449 认证联络进程 459.1 符合方法与规划 459.2 符合证明 4510 硬件设计生命周期数据 4710.1 硬件计划 4710.1.1 硬件方面认证计划 4810.1.2 硬件设计计划 4910.1.3 硬件鉴定计划 4910.1.4 硬件验证计划 5010.1.5 硬件配置管理计划 5010.1.6 硬件进程保证计划 5110.2 硬件设计标准和指南 5110.2.1 要求标准 511
11、0.2.2 硬件设计标准 5110.2.3 鉴定和验证标准 5210.2.4 硬件存档标准 5210.3 硬件设计数据 5210.3.1 硬件要求 5210.3.2 硬件设计表示数据 5310.3.2.1 概念设计数据 5310.3.2.2 详细设计数据 5410.3.2.2.1 顶级图 5410.3.2.2.2 组装图 5410.3.2.2.3 安装控制图 5410.3.2.2.4 硬件/软件接口数据 5510.4 鉴定和验证数据 5510.4.1 可追溯性数据 5510.4.2 审核和分析程序 5610.4.3 审核或分析结果 5610.4.4 测试程序 5710.4.5 测试结果 571
12、0.5 硬件验收测试标准 5710.6 问题报告 5810.7 硬件配置管理记录 5810.8 硬件进程保证记录 5810.9 硬件完成概要 5811 附加考虑事项 6011.1 先前开发硬件的使用 6011.1.1 对先前开发硬件的变更 6011.1.2 飞机设备的更改 6011.1.3 应用或设计环境的改变 6111.1.4 设计原始资料的升级 6111.1.5 配置管理的附加考虑事项 6211.2 商业化成品（COTS）元件的使用 6211.2.1 对COTS元件的电子元件管理 6211.2.2 COTS元件的采购 6311.3 产品服务经验 6311.3.1 产品服务经验数据可接受性标
13、准 6311.3.2 对产品服务经验数据的评估 6311.3.3 产品服务经验评估数据 6411.4 工具评估和鉴定 6411.4.1 工具评估和鉴定进程 6511.4.2 工具评估和鉴定数据 68A.1 简介 72A.2 功能故障路径分析 72A.2.1 功能故障路径分析方法 73A.2.2 功能故障路径分析数据 73A.3 A级与B级功能的设计保证方法 74A.3.1 架构缓解 74A.3.1.1 架构缓解方法 74A.3.1.2 架构缓解的解决 74A.3.1.3 架构缓解数据 75A.3.2 产品服务经验 75A.3.2.1 产品服务经验方法 75A.3.2.2 产品服务经验的解决 7
14、5A.3.2.3 产品服务经验数据 75A.3.3 先进验证方法 76A.3.3.1 元素分析 77A.3.3.1.1 元素分析法 77A.3.3.1.1.1 选择元素分析标准 77A.3.3.1.1.2 执行元素分析 78A.3.3.1.2 元素分析结果的解决 79A.3.3.1.3 元素分析生命周期数据输出 79A.3.3.2 特定安全分析 80A.3.3.2.1 特定安全分析法 81A.3.3.2.2 特定安全分析的解决 81A.3.3.2.3 特定安全分析数据 82A.3.3.3 形式法 82A.3.3.3.1 形式法的方法论 83A.3.3.3.2 形式法的解决 84A.3.3.3.
15、3 形式法数据 841 导言 使用日益复杂的电子设备可获得更好的安全关键飞机功能，但这也会带来关于安全和验证的新的挑战。产生这些挑战是由于担心上述飞机功能会由于硬件设计失误的相反效应而变得更加脆弱，并且这些失误会由于硬件的日趋复杂化而更加难以把握。为抵消此风险的扩大，在设计和验证进程中，有必要的采用更一致的和可验证的方式来确保潜在的硬件设计错误的定位。 由于机载电子设备的日趋复杂化、技术的进步以及在实际应用中和采用本文件所述程序的进程中获得的经验，必须根据已通过的RTCA/EUROCAE程序对本文件进行修订和审核。1.1 目的 本文件帮助研发组织为机载电子设备的开发提供了设计保证指南，从而使机
16、载电子设备可在规定的环境中安全地发挥其预定的功能。本指南同样适用于现有的、新的以及正在开发的技术。本文件的目的是：1 确定硬件设计保证目标；2 描述这些目标的基本原则以确保对本指南的正确阐述；3 提供目标描述，以允许根据本指南和其它指南所作的各种改进；4 提供设计保证活动指南以满足设计保证目标；5 只要有合适的新技术，允许灵活选择满足本文件目标（包括对其的改进）必需的进程。本文件介绍的是为满足设计保证目标所应采取的活动，而并未详细介绍怎样进行某项设计。本指导文件所用的基本原理是基于电子设备所体现出来的系统功能的一种自上而下的透视法，而不是一种自下而上的透视法，或者仅基于用于实现某功能的一些特定
17、设备元件的透视法。通过推进已知系统和硬件设计的决定，以及高效且有效的验证进程，自上而下的方法在处理安全设计失误时会更有效。例如，应在系统、组件、子组件、元件或硬件项的最高等级上进行验证；并且在此等级上，硬件项可满足其要求，验证目标也可实现。1.2 范围本文件为机载电子设备（源自初始验证和后续验证后产品改进进程的概念）提供设计保证指南，以便确保连续的适航性。本文件基于与运输类飞机和设备所需的验证要求一致的陈述制定，但本文件的一部分并不适用于其它设备。本文件描述了系统生命周期和硬件设计生命周期间的关系，以帮助理解系统和硬件设计保证进程的相互关系。文件中并未包括对系统生命周期（包括系统安全评估（SS
18、A）和有效性）以及飞机验证进程的完整描述。只有与硬件设计生命周期有关时，才会讨论验证问题。而只有与硬件设计的适航性有关时，才会处理与生产、检测和维护硬件项的能力相关的方面。本文件指南适用于但不仅限于以下硬件项:1 线路可替代单元（LRU）；2 电路板组件；3 定制微码元件，如专用集成电路(ASIC)和可编程逻辑器件（PLD），还包括任何相关的宏功能；4 集成技术元件：如混合电路和多芯模块；5 商业成品元件（COTS）。由于COTS元件供应商可能不会遵从本文件所述的设计进程，或提供必要的设计生命周期数据，因此其它的情形，尤其是针对COTS的考虑，会在第11节中进行讨论。本文件并未试图定义固件。固
19、件应归类为硬件或软件，并且应采用适当的进程对其进行处理。本文件假设，在系统定义时，功能已分配给了硬件或软件。RTCA DO-178/EUROCAE ED-12提供了针对分配给软件执行程序的功能的指南。本文件提供的是针对分配给硬件的功能的指南。注：在系统确定和功能指定后，就可确定执行程序和设计保证的有效方法。在进行指定时，所有团体都应同意此系统决定。硬件项设计和验证所用工具的评估和规格见第11.4节。本文件并未提供关于组织结构或在这些结构中如何划分职责的指南。环境条件标准也不在本文件所涉及的范围之内。1.3 与其它文件的关系除了飞行性能要求外，各种关于硬件的国家和国际标准也是适用的。在有些团体中
20、，可能会要求遵从这些标准。但是，本文件并未援引具体的国家或国际标准，也未提供某种方法使得这些标准可用作本文件的选项或补充。当本文件使用“标准”这一术语时，意指机载系统、机载设备、发动机或飞机制造商所用的工程特定标准。这些标准可能来自于制造商制定或采用的通用标准。标准指南见第10.2节。1.4 相关文件SAE ARP4754/EUROCAE ED-79，即高度集成或复杂飞行系统验证准则，是关于高度集成或复杂飞行系统的开发指南的源文件。SAE ARP4761，即民航系统及设备的安全评估进程实施方针及方法，是用于硬件设计保证进程的安全评估方法的源文件。RTCA DO-178/EUROCAE ED-1
21、2，即关于机载系统及设备验证的软件考虑因素，是软件开发保证的补充文件。RTCA DO-160/EUROCAE ED-14，即机载设备的环境条件及测试进程，可为设备设计者用作硬件项规格的初级环境测试标准。1.5 如何使用本文件本文件供国际航空团体使用。为便于使用，尽可能少地参考了具体的国家规定和程序；相反，使用更多的还是通用术语。例如，术语“认证机构”用来指代表有权认证的国家进行审核的组织或个人。当另外一个国家或国家集团批准或参加此认证时，本文件就可使用，并且会在所涉及到的国家间的双边协议或谅解备忘录中相应地体现出来。本文件指南代表了航空团体的一致意见，囊括了机载电子设备设计保证方面最好的行业实
22、践经验。对于本文件中提出的进程，其目的是提供可用于完成新硬件设计和后续改造的指南。先前为其它进程提供的硬件指南见第11.1节。可以理解，除了在此介绍的方法外，其它方法也可能为申请人获取并采用。在使用实例说明如何使用本指南时，不管是用图表形式还是叙述方式，不能认为这些实例是首选的方法。第11节讨论了关于特定已知情况（在这些已知情况下，第2节至第9节的一些目标可能不会实现）的其它情形。这些情形包括：已开发出的硬件的使用指南、COTS元件使用指南、产品服务经验指导、工具评估及规格指南。在附录A中，基于执行中的硬件设计保证等级，提供了关于必需的硬件设计生命周期数据的指南。附录B包括了执行A级和B级功能
23、（除了第2节至第11节的指南外，也应使用这些功能）所用硬件的设计保证技术指南；根据申请人的意愿，附录B也可应用于硬件的C级和D级设计保证。本文件中所用的术语表见附录C。附录D是本文件所用的缩略词汇表，列出了这些缩略词的全称。对于列出的表单，并不意味着其下的子项在任何情况下都是全面的，也不是说所有的子项都对应于任何特定的产品。本文件中的注释用于提供说明性材料、强调某一点或者引起对相关主题的注意。当然，这些注释并不仅限于上下文范围之内。注释并不包含指南。当提供指南时会用“应该”一词。“可能”则用于选择性文本。本文件所用的术语“硬件项”则是用来描述作为本文件主题的电子设备。除非特意说明，在本文件中都
24、会采用限定词“硬件”。使用术语“要求”时是指“硬件要求”。系统或软件限定词通常会特意说明，如“系统要求”。注：各种行业咨询文件和航空要求文件并不总是使用一致的术语。例如，联邦航空规程（FAR）21和联合航空要求（JAR）21中使用“产品”来指代飞机、飞机发动机、或螺旋桨。文件SAE ARP4754/EUROCAE ED-79使用“产品”这一术语来指代硬件、软件、部件或根据确定的一组要求形成的系统。请读者注意在使用术语时的这些以及其它差异。本文件使用的是词汇表中的定义。1.6 复杂性考虑尽管有各种关于术语“复杂性”的分类被用于描述电子器件，比如简单、复杂和高度复杂，但这些分类之间的区别并未严格确
25、定。要在此确定复杂性间的区别，需要根据使用确定性方法达到可行性验证范围所必需的可行性和困难程度而进行。应分等级，按照集成电路、电路板和LRU的顺序对硬件的复杂性进行检查；其中，复杂性包括可能不可测的寻址功能，如多用途设备中未用的模式和时序机中可选的隐藏状态。在不存在异常现象的所有可预见的操作条件下，只有当符合设计保证等级的确定性测试和分析可确保正确的操作性能时，硬件项才可定义为简单。若某硬件项不能归入简单一类，它就应归入复杂一类。全部由简单部件构成的部件可能是复杂部件。对于含有器件（如ASIC或PLD）的部件，若其符合本节描述的简单标准，就可认为是简单的。对于复杂部件，推荐的提供设计保证方式应
26、该早已在硬件设计生命周期中经认证机构同意使用，以减小进程风险。对于简单硬件项，设计进程不需要提供大量文件。对于简单硬件项，需要执行并证明验证和配置管理支持进程，但并不需要提供大量文件。因此，为遵从本文件，在设计简单硬件项时削减了费用。本文件的主要影响将体现在复杂硬件项的设计上。1.7 其它方法或进程除了本文件所述的以外，其它方法或进程也可能被用于提供硬件设计保证。对于这些方法和进程，应根据其满足可用准则的能力来进行评估。可选方法或进程应在执行前由认证机构批准。当通过比较本文件来评估可选方法或进程时，除了直接与可用准则比较外，申请人还可使用以下的指南来降低进程风险。评估可选方法或进程应考虑的因素
27、包括：1 在代替本文件介绍的进程使用时，满足第2节至第9节中一个或多个目标的进程应体现出同等的设计保证等级；2 应该评估所推荐的其它方法或进程在满足硬件设计保证目标时产生的影响；3 应该评估所推荐的其它方法或进程对生命周期数据产生的影响；4 使用推荐方法或进程的合理性应该用这样的证据来证明：使用这些方法或进程可产生预期结果。1.8 文件概览图1-1是本文件所有章节的概图，表明了这些章节彼此之间的关系，以及与其它相关进程的关系。这并不是为了描述数据流，而是为了表明哪些章节及外部进程是相关的。图1-1 文件概览2 系统方面的硬件设计保证硬件设计保证从系统等级开始，系统功能会分配给硬件，而同时也会指
28、定其相应的系统开发保证等级。单个的系统功能可以分配给硬件项、软件元件或软硬件组。与功能相关的安全要求来自于系统透视、软件透视和硬件透视，从而就可确定满足这些要求所必需的可靠性等级和保证等级。图2-1阐示了机载电子系统和设备的系统开发进程与安全评估、硬件开发以及软件开发进程的关系。图2-1 机载系统、安全评估、硬件和软件进程间的关系在图中有四处重叠区域，分别为：安全/硬件，安全/软件，硬件/软件和安全/硬件/软件。这些重叠表明了这些进程间的关系和相互作用；而在这些进程中，系统要求可能会产生一些在多进程范围及设计保证指南之内的要求。例如，包含安全要求的硬件功能会包括安全评估进程和硬件设计生命周期进
29、程。这些重叠表明，需要用进程间的相互作用来确保系统功能保证要求的满足。本文件并未探讨系统或软件保证进程。但是，在协调硬件功能的设计保证时，申请人也可能想利用系统或软件进程中的活动提供的保证。这些关系和相互作用在第2.1.1节至第2.1.3节中会进一步探讨。2.1 信息流生命周期进程间的信息流如图2-2所示。以下部分所述的是从系统开发进程到硬件设计生命周期进程间的信息流、从硬件设计生命周期进程到系统开发进程间的信息流以及硬件设计生命周期进程与软件生命周期进程间的信息流。注：这些都被认为是反复的进程，并且在硬件设计生命周期中还会产生变化。图2-2 系统开发进程从系统开发进程到硬件设计生命周期进程的
30、信息流此信息流可能包括：1 分配给硬件的设计和安全要求；2 每种功能的设计保证等级，还有其相关要求和故障条件，但前提是此功能可用；3 分配的可能性，以及风险出现时，硬件功能故障出现的可能性；4 硬件/软件接口描述5 关于安全策略及设计限制的要求，如可测试性、设计方法以及硬件结构；6 将通过硬件等级验证来执行的系统验证活动的要求；7 分配给硬件的安装要求、人体工程学要求以及环境要求；8 可能会对要求产生影响的综合问题报告。之所以会这样，是由于一些活动的缘故，如：系统验证、系统要求的产生或SSA。从硬件设计生命周期进程到系统开发进程的信息流此信息流可能包括：1 要求的执行进程，如：机械制图、简图和
31、零件列表；2 可能会影响任何分配的要求的硬件衍生要求；3 装置结构，包括故障限度；4 在硬件设计生命周期中进行的任何必需的系统验证和审核活动的证明；5 产品安全分析数据，如：a. 与SSA进程有关的特定硬件功能故障的可能性及故障率；b. 常见故障分析；c. 隔离范围及普通故障缓解策略；d. 与系统要求相关的潜在分析数据。例如：故障监视、故障检测周期和不可测故障的硬件准备。6 将通过系统等级验证来实施的硬件验证活动的要求；7 关于安装要求和环境条件（是将要进行的分析所必需的）的假设和分析方法；8 可能会影响系统、软件或分配的硬件要求的问题或变化报告。硬件设计生命周期进程与软件生命周期进程之间的信息流此信息流可能包括:1 硬件/软件集成所需的衍生要求，如：草案的确定、定时限制以及软硬件间接口
