DO-254标准编译稿

1、 RTCA/DO-254 机载电子设备硬件的设计保证指南 RTCA/DO254标准机载电子设备硬件的设计保证指南二00八年四月目 录I前 言本文件由航空无线电委员会（RTCA）180专委会（SC-180）制订，并于2000年4月19日由RTCA项目管理委员会批准通过。本指南是RTCA SC-180和EUROCAE（欧洲民用航空设备组织）WG-46在协商一致的基础上共同编写完成的。RTCA公司是一家非营利性的组织，其宗旨是推进航空和航空电子系统科学与技术的发展，为公众的福祉服务。本组织起到了联邦顾问委员会的作用，并就当前航空方面的议题提出一致通过的建议。RTCA的目标包括但并不仅限于：l 结合航

2、空系统用户和供应商的技术要求，帮助政府和企业实现和履行彼此的目标及职责；l 对航空业界在追求更高安全、系统性能和效能时所面临的系统技术问题进行分析，并提供解决方案；l 推进相关技术应用的通过，以满足用户和供应商的要求，包括支持飞行的电子系统和设备的最低工作性能标准的制定；l 帮助制定相关技术资料，以此确定国际民航组织、国际电信联盟以及其它感兴趣的国际组织的地位。本组织的建议通常被政府和民间组织作为决策的依据，并且还是众多联邦航空管理技术标准规程的基础。由于RTCA并不是美国政府的官方代理机构，本组织的建议未经美国政府或在这些建议所涉及到的任何问题上拥有法定权限的组织公布，不能被认定为官方政策。

3、执行概要航空业界中复杂电子设备的使用和研发引起了新的安全和验证问题。为解决此问题，成立了RTCA SC-180和EUROCAE WG-46。RTCA SC-180和EUROCAE WG-46早在制订本文件时就已同意并组成了联合委员会。该联合委员会经特许为机载电子设备制定清晰和一致的设计保证指南，从而使机载电子设备可安全地发挥其既定功能。机载电子设备包括线可替代单元、电路板组件、专用集成电路、可编程逻辑器件等。本指南适用于现有的、新的以及刚出现的技术。前 言本文件由航空无线电委员会（RTCA）180专委会（SC-180）制订，并于2000年4月19日由RTCA项目管理委员会批准通过。本指南是RT

4、CA SC-180和EUROCAE（欧洲民用航空设备组织）WG-46在协商一致的基础上共同编写完成的。RTCA公司是一家非营利性的组织，其宗旨是推进航空和航空电子系统科学与技术的发展，为公众的福祉服务。本组织起到了联邦顾问委员会的作用，并就当前航空方面的议题提出一致通过的建议。RTCA的目标包括但并不仅限于：结合航空系统用户和供应商的技术要求，帮助政府和企业实现和履行彼此的目标及职责；对航空业界在追求更高安全、系统性能和效能时所面临的系统技术问题进行分析，并提供解决方案；推进相关技术应用的通过，以满足用户和供应商的要求，包括支持飞行的电子系统和设备的最低工作性能标准的制定；帮助制定相关技术资料

5、，以此确定国际民航组织、国际电信联盟以及其它感兴趣的国际组织的地位。本组织的建议通常被政府和民间组织作为决策的依据，并且还是众多联邦航空管理技术标准规程的基础。由于RTCA并不是美国政府的官方代理机构，本组织的建议未经美国政府或在这些建议所涉及到的任何问题上拥有法定权限的组织公布，不能被认定为官方政策。86执行概要航空业界中复杂电子设备的使用和研发引起了新的安全和验证问题。为解决此问题，成立了RTCA SC-180和EUROCAE WG-46。RTCA SC-180和EUROCAE WG-46早在制订本文件时就已同意并组成了联合委员会。该联合委员会经特许为机载电子设备制定清晰和一致的设计保证指

6、南，从而使机载电子设备可安全地发挥其既定功能。机载电子设备包括线可替代单元、电路板组件、专用集成电路、可编程逻辑器件等。本指南适用于现有的、新的以及刚出现的技术。本文件中的指导措施将供飞机系统所用的电子硬件项的供应商和飞机生产商使用。文件中确定了硬件设计生命周期进程，并对每一进程的目标和活动进行了描述。本指南适用于所有的硬件保证等级（由系统安全评估确定）。在本文件的制定进程中，委员会参考了其它的业内文件，包括美国动力机械工程师协会（SAE）航空推荐准则(ARP)文件ARP4754/EUROCAE ED-79、高度集成或复杂飞机系统的验证准则、民航系统及设备的安全评估进程实施方针及方法以及RTC

7、A DO-178/EUROCAE ED-12机载系统及设备验证的软件考虑因素。目 录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 随机硬件故障的定量分析14

8、2.3.3 硬件设计失误及推翻的定性评估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 实施活动275.5 生产转换进程275.

9、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 原始资料的建立407.2.3 问题报告、跟踪和纠正行为407.2.4 更改控制417.2

10、.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 要求标准5110.2.2 硬件设计标准5110.2.3 鉴定和验证标准5210.2.4 硬件存档标准5210.3 硬件设计数据5

11、210.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 测试结果5710.5 硬件验收测试标准5710.6 问题报告5810.7 硬件配置管理记录5810.8 硬件进程保证记录5810.9 硬件完成概要5811 附加考虑

12、事项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 产品服务经验数据可接受性标准6311.3.2 对产品服务经验数据的评估6311.3.3 产品服务经验评估数据6411.4 工具评估和鉴定6411.4.1 工具评估和鉴定进程6511.4.2 工具评估和鉴定数据

13、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 产品服务经验的解决75A.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

14、.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.3 形式法数据841 导言使用日益复杂的电子设备可获得更好的安全关键飞机功能，但这也会带来关于安全和验证的新的挑战。产生这些挑战是由于担心上述飞机功能会由于硬件设计失误的相反效应而变得更加脆弱，并且这些失误会由于硬件的日趋复杂化而更加难以把握。为抵

15、消此风险的扩大，在设计和验证进程中，有必要的采用更一致的和可验证的方式来确保潜在的硬件设计错误的定位。由于机载电子设备的日趋复杂化、技术的进步以及在实际应用中和采用本文件所述程序的进程中获得的经验，必须根据已通过的RTCA/EUROCAE程序对本文件进行修订和审核。1.1 目的本文件帮助研发组织为机载电子设备的开发提供了设计保证指南，从而使机载电子设备可在规定的环境中安全地发挥其预定的功能。本指南同样适用于现有的、新的以及正在开发的技术。本文件的目的是：1 确定硬件设计保证目标；2 描述这些目标的基本原则以确保对本指南的正确阐述；3 提供目标描述，以允许根据本指南和其它指南所作的各种改进；4

16、提供设计保证活动指南以满足设计保证目标；5 只要有合适的新技术，允许灵活选择满足本文件目标（包括对其的改进）必需的进程。本文件介绍的是为满足设计保证目标所应采取的活动，而并未详细介绍怎样进行某项设计。本指导文件所用的基本原理是基于电子设备所体现出来的系统功能的一种自上而下的透视法，而不是一种自下而上的透视法，或者仅基于用于实现某功能的一些特定设备元件的透视法。通过推进已知系统和硬件设计的决定，以及高效且有效的验证进程，自上而下的方法在处理安全设计失误时会更有效。例如，应在系统、组件、子组件、元件或硬件项的最高等级上进行验证；并且在此等级上，硬件项可满足其要求，验证目标也可实现。1.2 范围本文

17、件为机载电子设备（源自初始验证和后续验证后产品改进进程的概念）提供设计保证指南，以便确保连续的适航性。本文件基于与运输类飞机和设备所需的验证要求一致的陈述制定，但本文件的一部分并不适用于其它设备。本文件描述了系统生命周期和硬件设计生命周期间的关系，以帮助理解系统和硬件设计保证进程的相互关系。文件中并未包括对系统生命周期（包括系统安全评估（SSA）和有效性）以及飞机验证进程的完整描述。只有与硬件设计生命周期有关时，才会讨论验证问题。而只有与硬件设计的适航性有关时，才会处理与生产、检测和维护硬件项的能力相关的方面。本文件指南适用于但不仅限于以下硬件项:1 线路可替代单元（LRU）；2 电路板组件；

18、3 定制微码元件，如专用集成电路(ASIC)和可编程逻辑器件（PLD），还包括任何相关的宏功能；4 集成技术元件：如混合电路和多芯模块；5 商业成品元件（COTS）。由于COTS元件供应商可能不会遵从本文件所述的设计进程，或提供必要的设计生命周期数据，因此其它的情形，尤其是针对COTS的考虑，会在第11节中进行讨论。本文件并未试图定义固件。固件应归类为硬件或软件，并且应采用适当的进程对其进行处理。本文件假设，在系统定义时，功能已分配给了硬件或软件。RTCA DO-178/EUROCAE ED-12提供了针对分配给软件执行程序的功能的指南。本文件提供的是针对分配给硬件的功能的指南。注：在系统确定

19、和功能指定后，就可确定执行程序和设计保证的有效方法。在进行指定时，所有团体都应同意此系统决定。硬件项设计和验证所用工具的评估和规格见第11.4节。本文件并未提供关于组织结构或在这些结构中如何划分职责的指南。环境条件标准也不在本文件所涉及的范围之内。1.3 与其它文件的关系除了飞行性能要求外，各种关于硬件的国家和国际标准也是适用的。在有些团体中，可能会要求遵从这些标准。但是，本文件并未援引具体的国家或国际标准，也未提供某种方法使得这些标准可用作本文件的选项或补充。当本文件使用“标准”这一术语时，意指机载系统、机载设备、发动机或飞机制造商所用的工程特定标准。这些标准可能来自于制造商制定或采用的通用

20、标准。标准指南见第10.2节。1.4 相关文件SAE ARP4754/EUROCAE ED-79，即高度集成或复杂飞行系统验证准则，是关于高度集成或复杂飞行系统的开发指南的源文件。SAE ARP4761，即民航系统及设备的安全评估进程实施方针及方法，是用于硬件设计保证进程的安全评估方法的源文件。RTCA DO-178/EUROCAE ED-12，即关于机载系统及设备验证的软件考虑因素，是软件开发保证的补充文件。RTCA DO-160/EUROCAE ED-14，即机载设备的环境条件及测试进程，可为设备设计者用作硬件项规格的初级环境测试标准。1.5 如何使用本文件本文件供国际航空团体使用。为便于

21、使用，尽可能少地参考了具体的国家规定和程序；相反，使用更多的还是通用术语。例如，术语“认证机构”用来指代表有权认证的国家进行审核的组织或个人。当另外一个国家或国家集团批准或参加此认证时，本文件就可使用，并且会在所涉及到的国家间的双边协议或谅解备忘录中相应地体现出来。本文件指南代表了航空团体的一致意见，囊括了机载电子设备设计保证方面最好的行业实践经验。对于本文件中提出的进程，其目的是提供可用于完成新硬件设计和后续改造的指南。先前为其它进程提供的硬件指南见第11.1节。可以理解，除了在此介绍的方法外，其它方法也可能为申请人获取并采用。在使用实例说明如何使用本指南时，不管是用图表形式还是叙述方式，不

22、能认为这些实例是首选的方法。第11节讨论了关于特定已知情况（在这些已知情况下，第2节至第9节的一些目标可能不会实现）的其它情形。这些情形包括：已开发出的硬件的使用指南、COTS元件使用指南、产品服务经验指导、工具评估及规格指南。在附录A中，基于执行中的硬件设计保证等级，提供了关于必需的硬件设计生命周期数据的指南。附录B包括了执行A级和B级功能（除了第2节至第11节的指南外，也应使用这些功能）所用硬件的设计保证技术指南；根据申请人的意愿，附录B也可应用于硬件的C级和D级设计保证。本文件中所用的术语表见附录C。附录D是本文件所用的缩略词汇表，列出了这些缩略词的全称。对于列出的表单，并不意味着其下的

23、子项在任何情况下都是全面的，也不是说所有的子项都对应于任何特定的产品。本文件中的注释用于提供说明性材料、强调某一点或者引起对相关主题的注意。当然，这些注释并不仅限于上下文范围之内。注释并不包含指南。当提供指南时会用“应该”一词。“可能”则用于选择性文本。本文件所用的术语“硬件项”则是用来描述作为本文件主题的电子设备。除非特意说明，在本文件中都会采用限定词“硬件”。使用术语“要求”时是指“硬件要求”。系统或软件限定词通常会特意说明，如“系统要求”。注：各种行业咨询文件和航空要求文件并不总是使用一致的术语。例如，联邦航空规程（FAR）21和联合航空要求（JAR）21中使用“产品”来指代飞机、飞机发

24、动机、或螺旋桨。文件SAE ARP4754/EUROCAE ED-79使用“产品”这一术语来指代硬件、软件、部件或根据确定的一组要求形成的系统。请读者注意在使用术语时的这些以及其它差异。本文件使用的是词汇表中的定义。1.6 复杂性考虑尽管有各种关于术语“复杂性”的分类被用于描述电子器件，比如简单、复杂和高度复杂，但这些分类之间的区别并未严格确定。要在此确定复杂性间的区别，需要根据使用确定性方法达到可行性验证范围所必需的可行性和困难程度而进行。应分等级，按照集成电路、电路板和LRU的顺序对硬件的复杂性进行检查；其中，复杂性包括可能不可测的寻址功能，如多用途设备中未用的模式和时序机中可选的隐藏状态

25、。在不存在异常现象的所有可预见的操作条件下，只有当符合设计保证等级的确定性测试和分析可确保正确的操作性能时，硬件项才可定义为简单。若某硬件项不能归入简单一类，它就应归入复杂一类。全部由简单部件构成的部件可能是复杂部件。对于含有器件（如ASIC或PLD）的部件，若其符合本节描述的简单标准，就可认为是简单的。对于复杂部件，推荐的提供设计保证方式应该早已在硬件设计生命周期中经认证机构同意使用，以减小进程风险。对于简单硬件项，设计进程不需要提供大量文件。对于简单硬件项，需要执行并证明验证和配置管理支持进程，但并不需要提供大量文件。因此，为遵从本文件，在设计简单硬件项时削减了费用。本文件的主要影响将体现

26、在复杂硬件项的设计上。1.7 其它方法或进程除了本文件所述的以外，其它方法或进程也可能被用于提供硬件设计保证。对于这些方法和进程，应根据其满足可用准则的能力来进行评估。可选方法或进程应在执行前由认证机构批准。当通过比较本文件来评估可选方法或进程时，除了直接与可用准则比较外，申请人还可使用以下的指南来降低进程风险。评估可选方法或进程应考虑的因素包括：1 在代替本文件介绍的进程使用时，满足第2节至第9节中一个或多个目标的进程应体现出同等的设计保证等级；2 应该评估所推荐的其它方法或进程在满足硬件设计保证目标时产生的影响；3 应该评估所推荐的其它方法或进程对生命周期数据产生的影响；4 使用推荐方法或

27、进程的合理性应该用这样的证据来证明：使用这些方法或进程可产生预期结果。1.8 文件概览图1-1是本文件所有章节的概图，表明了这些章节彼此之间的关系，以及与其它相关进程的关系。这并不是为了描述数据流，而是为了表明哪些章节及外部进程是相关的。系统要求FAR/JAR及咨询材料安全评估指南系统开发指南环境条件测试指南开发限制l 系统方面的硬件设计保证（2节）l 硬件设计生命周期（第3节）l 计划进程（第4节）l 附加考虑（第11节）l 关于A级和B级功能的设计保证考虑（附录B）衍生要求（所要求的）要求的变化设计进程（第5节）生产 使用中进程支持进程：l 审批及验证进程（6节）l 配置管理进程（第7节）

28、l 进程保证（第8节）l 验证联络进程（第9节）l 硬件设计生命周期数据（第11节）l 硬件设计保证等级和配置控制码的硬件设计生命周期数据（附录A）软件开发指南图1-1 文件概览2 系统方面的硬件设计保证硬件设计保证从系统等级开始，系统功能会分配给硬件，而同时也会指定其相应的系统开发保证等级。单个的系统功能可以分配给硬件项、软件元件或软硬件组。与功能相关的安全要求来自于系统透视、软件透视和硬件透视，从而就可确定满足这些要求所必需的可靠性等级和保证等级。图2-1阐示了机载电子系统和设备的系统开发进程与安全评估、硬件开发以及软件开发进程的关系。系统FAR/JAR和咨询材料安全评估硬件软件硬件/软件

29、安全/硬件安全/软件安全/硬件/软件图2-1 机载系统、安全评估、硬件和软件进程间的关系在图中有四处重叠区域，分别为：安全/硬件，安全/软件，硬件/软件和安全/硬件/软件。这些重叠表明了这些进程间的关系和相互作用；而在这些进程中，系统要求可能会产生一些在多进程范围及设计保证指南之内的要求。例如，包含安全要求的硬件功能会包括安全评估进程和硬件设计生命周期进程。这些重叠表明，需要用进程间的相互作用来确保系统功能保证要求的满足。本文件并未探讨系统或软件保证进程。但是，在协调硬件功能的设计保证时，申请人也可能想利用系统或软件进程中的活动提供的保证。这些关系和相互作用在第2.1.1节至第2.1.3节中会

30、进一步探讨。2.1 信息流生命周期进程间的信息流如图2-2所示。以下部分所述的是从系统开发进程到硬件设计生命周期进程间的信息流、从硬件设计生命周期进程到系统开发进程间的信息流以及硬件设计生命周期进程与软件生命周期进程间的信息流。注：这些都被认为是反复的进程，并且在硬件设计生命周期中还会产生变化。系统开发进程软件设计生命周期进程硬件设计生命周期进程第2.1.3节第2.1.1节第2.1.2节图2-2 系统开发进程2.1.1 从系统开发进程到硬件设计生命周期进程的信息流此信息流可能包括：1 分配给硬件的设计和安全要求；2 每种功能的设计保证等级，还有其相关要求和故障条件，但前提是此功能可用；3 分配

31、的可能性，以及风险出现时，硬件功能故障出现的可能性；4 硬件/软件接口描述5 关于安全策略及设计限制的要求，如可测试性、设计方法以及硬件结构；6 将通过硬件等级验证来执行的系统验证活动的要求；7 分配给硬件的安装要求、人体工程学要求以及环境要求；8 可能会对要求产生影响的综合问题报告。之所以会这样，是由于一些活动的缘故，如：系统验证、系统要求的产生或SSA。2.1.2 从硬件设计生命周期进程到系统开发进程的信息流此信息流可能包括：1 要求的执行进程，如：机械制图、简图和零件列表；2 可能会影响任何分配的要求的硬件衍生要求；3 装置结构，包括故障限度；4 在硬件设计生命周期中进行的任何必需的系统

32、验证和审核活动的证明；5 产品安全分析数据，如：a. 与SSA进程有关的特定硬件功能故障的可能性及故障率；b. 常见故障分析；c. 隔离范围及普通故障缓解策略；d. 与系统要求相关的潜在分析数据。例如：故障监视、故障检测周期和不可测故障的硬件准备。6 将通过系统等级验证来实施的硬件验证活动的要求；7 关于安装要求和环境条件（是将要进行的分析所必需的）的假设和分析方法；8 可能会影响系统、软件或分配的硬件要求的问题或变化报告。2.1.3 硬件设计生命周期进程与软件生命周期进程之间的信息流此信息流可能包括:1 硬件/软件集成所需的衍生要求，如：草案的确定、定时限制以及软硬件间接口的寻址方案；2 需

33、要协调硬件和软件验证活动的情况；3 硬件和软件之间所确定的不兼容性，这可能也是报告和校正行动系统的一部分；4 也可应用的系统进程的安全评估数据。2.2 系统安全评估进程现有三个系统安全评估进程，它们分别是：功能危险性评估（FHA）,初步系统安全评估（PSSA）和SSA。这些进程被用于建立可应用于系统开发保证进程的系统安全目标，还用于确定系统功能是否达到了安全目标。SSA进程应该把安全目标转化成系统和设备安全要求。这些要求应包括系统及设备的功能及结构的基本安全目标和安全特征。SSA进程和系统开发进程把这些安全要求分配给了硬件。系统开发保证等级现有五个等级，A级至E级，对应五类故障情况：灾难性的、

34、危险的/极严重的、严重的、轻微的和无影响的。表2-1把硬件设计保证等级和五类故障情况联系了起来，并确定了硬件故障条件和它们对应的设计保证等级。首先，各个硬件功能的硬件设计保证等级是通过SSA进程、使用FHA辨别可能的危险来确定的；然后，PSSA进程把安全要求和相关的故障情况分配给硬件执行的功能。在硬件设计生命周期中，安全、系统和硬件进程间可能存在循环反馈，以确保设计制造的硬件会满足分配给硬件的系统安全、功能和性能要求。表2-1 硬件设计保证等级的定义及其与系统保证等级的关系系统开发保证等级故障情况分类故障情况描述硬件设计保证等级定义A级灾难性的故障情况会妨碍持续安全飞行和着陆。对于硬件功能，通

35、过如硬件安全评估可以看到，硬件功能故障或异常行为会引起能导致飞机发生灾难性故障情况的系统功能故障。B级危险的/极严重的故障情况会降低飞机的性能或空勤组处理异常运行情况的能力，从而极大地降低安全系数或功能，导致身体痛苦或增加工作量；这样，就不能依靠空勤组精确地或完全地执行其任务；并且还会对乘员产生不利影响，包括对这些成员中的一小部分造成严重伤害或潜在的严重伤害。对于硬件功能，通过如硬件安全评估可以看到，硬件功能故障或异常行为会引起能导致飞机发生危险的/极严重的故障情况的系统功能故障。C级严重的故障情况会降低飞机的性能或空勤组处理异常运行情况的能力，从而极大地降低安全系数或功能，并极大地加重空勤组

36、的工作量或降低空勤组的效率，使乘员产生不适，包括对其造成伤害对于硬件功能，通过如硬件安全评估可以看到，硬件功能故障或异常行为会引起能导致飞机发生严重故障情况的系统功能故障。D级轻微的故障情况不会极大地降低飞机安全，并且空勤组的活动也控制在其能力范围之内。轻微故障情况可能包括：安全系数或功能的轻微降低、空勤组的工作量的轻微增加（如，例行飞行计划的改变）或给乘员造成的一些不便。对于硬件功能，通过如硬件安全评估可以看到，硬件功能故障或异常行为会引起能导致飞机发生轻微故障情况的系统功能故障。E级无影响的故障情况不会影响飞机的运行能力，也不会增加空勤组的工作量。对于硬件功能，通过如硬件安全评估可以看到，

37、硬件功能故障或异常行为会引起系统功能故障，但不会对飞机的运行能力或空勤组的工作量产生影响。对于确定为E级的功能，不需要本文件的进一步指导，但本文件的指南可用做参考。2.3 硬件安全评估硬件安全评估与SSA进程一起执行，并用于支持SSA进程。该安全进程是为了证明可应用的系统和设备（包括硬件）满足了可应用的飞机验证要求的安全要求。若系统进程把安全、功能和性能要求分配给硬件，硬件安全评估就可确定各种功能的硬件设计保证等级，并有助于确定将要用到的合适的设计保证策略。2.3.1 硬件安全评估考虑事项硬件项设计者可能会采取适当的设计保证策略，遵从分配给硬件的安全要求和硬件设计保证等级。单独的设计保证等级和

38、策略可以应用于整个硬件项，而也可认为硬件项拥有独立的功能故障路径（FFP），这样就可提供混合设计保证等级或设计保证策略。功能故障路径分析（FFPA）可以用来判断硬件项部件较低的设计保证等级，或提供由不同方法或不同的产品服务历史来执行的不同功能。注：FFPA将在附录B的第2部分介绍。此分析方法尽管在书面上规定用于处理附录B中的问题，但它也适用于任何设计保证等级。若硬件项所含功能单独拥有不同的设计保证等级，这种情形可用下列方法之一处理：l 可以保证整个硬件项为最高设计保证等级。l 若硬件的功能、接口和共享资源可免受较低保证等级的功能的不利影响，就可根据硬件安全评估确定的那样，单独地确保单个硬件功能

39、为各自的硬件设计保证等级。共享资源的设计保证应该就是最高级功能的设计保证等级。针对硬件安全评估的建议包括：1 反复的硬件安全评估和设计应该确定衍生硬件安全要求，并保证满足分配给硬件的系统安全要求，还要保证满足衍生要求；2 这些衍生要求应包括硬件结构安全要求、电路及元件的安全要求、以及防止异常行为的安全要求（包括结合特定硬件结构及功能的安全特征），例如：a. 电路和元件冗余；b. 电路或元件间的分离或电隔离；c. 电路或元件间的差异；d. 电路或元件的监视；e. 保护或重新配置机器；f. 电路和元件的随机故障和潜在故障的容许故障率和可能性；g. 使用或安装的限制；h. 干扰的防止、管理以及恢复。

40、3 硬件设计保证进程和硬件安全评估应共同确定具体的遵从方式及每种功能的设计保证等级，还应确定已达到了可以接受的设计保证等级。注：异常行为可能由硬件项中的随机故障或设计失误引起，或者对硬件的干扰引起。硬件设计者可能会为硬件项功能选择较高的硬件设计保证等级。例如，在进行需要较高等级设计保证的安装时，会预料到硬件项功能的重新利用。硬件安全评估可能会运用各种定性和定量的评估方法。这可能包括：故障树分析（FTA）、常规分析、故障形式和后果分析、以及可用于随机故障的定量评估所用的统计可靠性分析法。2.3.2 随机硬件故障的定量分析基于硬件故障率、冗余、分离与隔离、故障形式统计、可能性分析、元件减少、压力分

41、析和制造进程控制的统计故障评估和预测方法已经证明，这些都是对随机硬件故障进行定量风险因素评估可以接受的方法。2.3.3 硬件设计失误及推翻的定性评估不像硬件随机故障那样，设计失误和一些类型的“推到重来”在统计学上都是不可预测的，并且它们都可能以普通故障的形式越过冗余界限。应该对将要使用的冗余管理方法和定量分析方法进行选择，以便在必要时可以排除或减轻潜在的普通故障以及“推到重来”的影响。尽管定量评估很困难，但仍可利用定性安全评估方法有效地评估由设计失误和“推到重来”带来的安全风险。像故障树分析、普通分析和功能故障形式及影响分析（F-FMEA）这样的分析方法基本是定性的方法，可以用来处理硬件设计失

42、误和“推到重来”。更具体地说，这些方法可以确定硬件设计失误和“推到重来”的潜在影响，还有助于确定通过何种方式可以排除或减轻这些影响。使用这些方法后，硬件安全评估就有助于确定将要使用的硬件设计保证策略，并且在硬件设计进程中可反复使用，从而就可定性地确定所选策略达到的保证等级。2.3.4 关于硬件故障情况分类的设计保证考虑事项由于系统故障情况越来越严重，为确保相关故障情况的减轻而必需的硬件设计保证量也随之增长。对于所有的设计保证等级，应该研究出一种方法或策略来确保合适的设计保证等级。图2-3列出了研究适当设计保证策略的决定生成流程。建议包括：1 对于在硬件中执行的A级或B级功能，设计保证考虑事项应

43、处理硬件功能潜在的异常行为和潜在的设计失误；2 当研究每个执行中的功能的设计保证策略时，应该使用图2-3中列出的决定生成流程；3 除了在第3节至第1节中提供的建议外，附录B中所述的策略也应该用于A级和B级功能；4 设计保证策略应选择为硬件结构和用途的功能，以及已选的硬件执行技术的功能。不同的技术、元件选择和元件用途提供了各种程度的硬件设计生命周期信息和各种程度的防止相关设计失误及其影响的措施。在相同的硬件项之内，对于不同的功能路径，最适合的设计保证方法也会有所不同。在图2-3中，决策和活动块中的数字指的是根据进一步说明决定或活动的图表得出的编号项。1 启动评估进程。对于所有的设计保证等级，都应

44、该研究出相应的方法或策略来保证合适的设计保证等级。2 确定FFP设计保证等级。对于每个确定的硬件项，确定并证明与部件和设计保证等级相关的FFP。启动评估进程确定FFP设计保证等级硬件执行是简单还是复杂？研究A级或B级复杂FFP的设计保证策略策略合适吗？证明可应用的故障安全情况证明设计保证方法及策略应用此方法修改策略A级或B级D级或E级C级简单复杂是否图2-3 硬件设计保证策略的决定进程3 FFP的硬件执行是简单的还是复杂的？对于硬件设计保证的A级或B级FFP，按1.6所述来确定硬件是简单还是复杂。4 研究A级或B级复杂FFP的设计保证策略。若FFP是复杂的并且为A级或B级，就可使用附录B中所述

45、的附加策略来确定合适的设计保证策略、相应的执行概念以及失误缓解方法。对于每个A级或B级FFP，应使用深层分析、产品服务经验或结构缓解来确定设计保证策略。若所选方法不能完全缓解潜在的故障和异常行为，装置中的A级FFP就可能需要不止一种方法。5 策略合适吗？确定设计保证策略中是否有不足之处；若策略中存在不足或希望获取的数据中可能会存在不足，请提出别的设计保证、执行或结构策略来修改该策略以便弥补不足之处。当设计保证策略可接受时，请为每个FFP的设计保证进程提供文件证明。该策略还应该用来处理认证机构参与的项目，如计划中的重大事件、项目审核和监督活动。6 证明可应用的故障安全情况。确定合适的故障安全设计

46、结构和硬件项特征，然后进行分析，以满足系统的有效性和完整性。证明故障安全设计情况和相关的普通分析、可能性分析、结构或其它特征。7 证明设计保证方法及策略。对于系统验证计划或硬件验证方面的计划（PHAC）中可应用的设计保证方法和策略，应进行证明并获取认证机构的审批。8 应用此方法。根据已通过的计划和文件（明显遵从了已通过的计划和策略）中确定的适当设计保证方法进行硬件设计。3 硬件设计生命周期本节列出了第4节至第9节中讨论的硬件设计生命周期。本文件既未规定首选的生命周期模型，也未为执行组织暗示一种结构。硬件设计生命周期同样适用于新系统或设备以及现有系统或设备的改进型的开发。每项工程的生命周期都应基

47、于进程和活动的选择和安排，并且这些进程和活动应由工程特性决定，如：要求稳定性、已开发硬件的使用以及硬件设计保证等级。硬件设计生命周期可以是反复的，也就是说，根据逐渐的发展和进程间的反馈，可以进入、重新进入以及修改生命周期。3.1 硬件设计生命周期进程硬件设计生命周期进程是：1 如第4节所述，硬件计划进程可以对一项工程的硬件设计和支持进程进行确定和调整；2 如第5节所述，硬件设计进程可产生设计数据和最终的硬件项。这些进程是要求捕获、概念设计、详细设计、执行以及产品过渡；3 如第6节至第9节所述，支持进程产生的硬件设计生命周期数据可以保证硬件设计生命周期及其输出的正确性以及对其的控制，这包括：计划

48、、设计、硬件安全评估和支持进程。这些进程特别与计划和设计进程同时执行。这些进程是：鉴定、验证、配置管理、进程保证以及认证联络。3.2 过渡标准在不同开发平台上用不同的子项来开发硬件项是一个挑战，因而需要一种方法来适度地控制设计进程，以便在先前进程所有的项目都完成前不会启动下一个进程。过渡标准，即用来评估从一个进程到另一个进程的运动进程的最小数据，可以用在关键的进程点上。在计划进程中进行的分析应该确定了过渡标准的使用。没有必要在计划中确定的每对进程步骤间建立过渡标准。过渡标准的选择应该可以处理对安全的影响。例如，在为获得某项功能的认证证书而进行的验证前，该功能的要求需要用文件证明，并且应在配置管

49、理下执行该功能。应在硬件计划中对过渡标准进行证明。使用过渡标准并不暗指任何特殊的生命周期模型，也不会阻止像快速原型设计和并行工程这样的开发策略的实施。4 计划进程本节讲述的是用来控制硬件项开发的硬件计划进程。本进程提出了可能包含于一个或多个文件中的硬件计划。若使用了多个文件，主计划应该包含有关于支持文件的适当参考书目。对于涵盖特定的设计生命周期进程（如：配置管理或进程保证）的标准文件，若其满足可应用的计划目标，就是可接受的。4.1 计划进程目标硬件计划进程的目的是确定功能和适航性要求转换成硬件项的方式，并且硬件项还要有适度的保证使其可以安全地执行预定功能。硬件计划进程的目标是：1 硬件设计生命

50、周期已确定；注：活动、重大事件、输入、输出和组织职责都可能包含于计划之中。2 标准已选择和确定；3 硬件开发及验证环境已选择或确定；4 遵从硬件设计保证目标的方式（包括用2.3.4中的方法确定的策略）已上报认证机构。5注：新的和正在开发的技术、工具和进程可能需要改变计划进程的细节。因此，灵活性是本计划进程的一个关键因素。4.2 计划进程活动计划进程指南包括：1 应该确定硬件设计生命周期进程（如果可以应用，还包括过渡标准）和单个进程间的相互关系，比如其时序和反馈机制；2 应确定并说明推荐的设计方法。这包括对预计硬件设计的考虑和推荐的验证方法的合理性；3 硬件设计标准（包括标准的衍生标准）若要用于

51、工程中，应对其进行定义。这包括从通用标准到公司或项目的具体标准；注：通过提供从以前开发中得到且已证明的工程惯例，标准就有助于减小不可测设计失误出现的可能性。当把标准应用到新设计和新技术上时，申请人和开发者应注意：可适用性可能已经失效。由于设计限制、与系统要求的矛盾或与新技术的不兼容性，这些标准的衍生标准可能也是必需的。若使用了标准，计划进程就是审核合适的衍生标准的机会。4 应该确定协调硬件设计进程和支持进程所用的方法；对于上述进程，特别要注意与系统、软件和飞行认证相关的活动。注：协调可能是以表明事件（用于达成本文件所述的进程目标）转折点的进度表的形式出现。5 应定义各个硬件设计进程和相关支持进

52、程的活动。此定义应处于一个可使硬件设计进程和相关支持进程受到控制的等级上。6 应选择设计环境，包括用来开发、验证和控制硬件项和生命周期数据的工具、程序、软件和硬件。a. 若认证证书要求联合使用工具，就应在相应的计划中详细说明工具使用顺序；b. 设计环境会影响产品的设计。第11.4节所提供的建议可用于工具评估并确定何时工具规格是必需的。7 若衍生物是必需的并且还会影响验证，就应确定从已定计划进行衍生所需的进程。8 应该描述用来确定、管理和控制硬件、相关原始资料和硬件设计生命周期数据的方针、进程、标准和方法。9 当申请人希望让转包商来负责整个或部分硬件设计生命周期时，硬件计划应能确定方法来保证满足

53、设计保证目标。10 应该描述用于执行硬件设计进程的进程保证方针和进程。11 应在PHAC中描述验证进程独立性、进程保证独立性和相关的组织职责。12 应在进程早期记录满足此建议的目标所用的方法，并把其通报给认证机构。这些方法应记录在PHAC中。注：应鼓励针对这些方法的任何变化所作的及时调整，以便尽可能地接受最终验证结果，并把其作为满足设计保证要求的适当证据。5 硬件设计进程硬件设计进程产生的硬件项可以满足从系统要求分配到硬件的要求。如图5-1所述，本节描述了五个主要的进程。它们是：要求捕获、概念设计、详细设计、执行及产品过渡。这些设计进程可应用于任何等级的硬件项上，比如：LRU、电路板组以及AS

54、IC/PLD。以下介绍的是每个进程、其目标以及应该用来减少可影响安全的设计和执行失误可能性的相关活动。重要的是，所有的进程都做了计划，并且细节都记录在硬件设计计划中。每个进程以及进程之间的相互作用都可以是反复的。对于每个反复操作，应处理所发生的变化对每个进程产生的影响，还应评估对先前的反复操作的结果产生的影响。注1：在设计进程中，证明像设计记录、设计审核记录和问题报告这样的进程产物是一个好的工程惯例。现有惯例提供了许多不同的方法（图表式的、数学的、基于数据库或文本的）来表示要求和设计执行进程，例如，示意图、硬件描述语言（HDL）、状态图、布尔表示法和图表法。注2：有些表示法适用于特定的进程或进程组，如：要求捕获、概