中国民航大学 适航审定研究中心 版次：CDO254-R1

2008/03/05

机载电子硬件设计保证
指 南

编译：王 鹏 杨建忠

国防科工委 中国民航总局
适航审定技术研究与管理中心

声明：本翻译稿所有权归属中国民航大学适航审定研究中心，本资料仅限于内部学习
交流以及授权人士和机构的使用。未经允许，任何个人和机构不得复制、影印、贩卖或传
播本资料。如有需要授权文件请联系RTCA相关部门，如需要相关培训或咨询，请联系中国
民航大学适航审定研究中心，联系电话022-24092410，邮箱：pwang@cauc.edu.cn 。
 航空无线电技术委员会，
美国、华盛顿20036-4001、N.W、康涅狄格大道1020栋1140号
（Incorporated1140 Connecticut Avenue, N.W., Suite 1020
Washington, DC 20036-4001 USA）

机载电子硬件设计保证指南

航空无线电技术委员会/DO-254 筹办方：SC-180
2000.4.19 ©2000，航空无线电技术委员会
 文件副本可以通过航空无线电技术委员会获取
航空无线电技术委员会，
美国、华盛顿20036-4001、N.W、康涅狄格大道1020套房1140公司
（RTCA, Inc.1140 Connecticut Avenue, NW, Suite 1020
Washington, DC 20036-4001 USA）

电话：202-833-9339
传真：202-833-9434
网站：www.rtca.org

了解有关价格情况及订购须知请致电航空无线电技术委员会
 前 言
此文献由美国航空无线电技术委员会特别委员会SC-180组织制定，并于2000年4月19号

通过美国航空无线电技术委员会项目管理委员会的审核。

通过美国航空无线电技术委员会特别委员会SC-180和欧洲民用航空设备组织的通力协

作完成了本指导文献的编制工作，并获得一致评审通过。

美国航空无线电技术委员会是一个为了公众的利益、促进航空科学技术及航空电子系统

的发展而形成的一个非营利性质的组织。这个组织的作用类似一个联邦咨询委员会，针对目

前航空问题，在一致协商的基础上给出推荐的解决办法。美国航空无线电技术委员会的目标

包括但不局限于以下方面：

• 结合航空系统用户及供应商的技术方面的要求，帮助政府及工业界去实现它们共有的

目标及履行相关的职责。

•通过分析推荐有关航空所面临系统技术问题的解决方法，持续增加航空安全性、系统

能力和效率。

•为满足使用者和供应商的需求，对相关技术的应用形成共识，包括制订支持航空电子

系统和设备的最低操作性能标准。

•协助制定相关技术资料，为国际民航组织、国际电信联盟以及一些其它的有意向的国

际组织提供技术支持。

这个组织的建议经常被政府和私营部门当作决策的基础，也是许多联邦航空管理技术标

准规定制定的基础。但是美国航空无线电技术委员会不是一个政府机构，它的建议不能作为

局方的政策除非美国政府组织或者机构赋予它法定权限去处理相关的问题。

-i-
 执行概要
电子硬件的复杂化和集成化使航空工业产生了对其安全性和审定的关注。由此，美国航

空无线电技术委员会SC-180和欧洲民用航空硬件组织WG-46应运而生。WG-46 和SC-180一

致同意尽早成立一个联合委员会以编制这个文献。这个联合委员会被特许授权去编撰一个清

晰、可靠的机载电子硬件设计保证指南，以保证其功能的安全实现。

机载电子硬件包括航线可更换组件、电路板组件、特定用途集成电路、可编程的逻辑器

件等等。这个指南适用于通用的、新近的和新兴的工艺。

本指南应该应用于飞机系统中飞机制造者和供应商的电子硬件项目。硬件设计的生命周

期程序是确定的，其各个步骤的目标和工作行动在文献中都有描述。本指南适用于所有的由

系统安全评估规定的硬件设计保证等级。

伴随着这个文献的发展，委员会考虑了到其它行业文献，包括汽车工业协会（SAE）航

空宇航推荐方法（ARP）的文献《ARP4754/EUROCAE ED-79关于高度综合或复杂的飞机系

统的合格审定考虑》、《SAE ARP4761对民用机载系统和设备进行安全性评估程序的指南

和方法》、《RTCA DO-178/EUROCAE ED-12关于对机载系统和设备合格审定中的软件考

虑》。

- ii -
 目 录
序言 ...............................................................................................................i
执行概要................................................................................................................. ii

1.0 绪论.......................................................................................................................1
1.1目标 ..............................................................................................................................1

1.2 范围 .............................................................................................................................1

1.3与其它文献的关联.................................................................................................2

1.4 相关的文献 .............................................................................................................2

1.5 使用说明..................................................................................................................3

1.6复杂度分析 ............................................................................................................................4

1.7 替代的方法和程序 ....................................................................................4

1.8 文献概况........................................................................................................5

2.0硬件设计保证的系统方面 .........................................................................6
2.1 信息流 ........................................................................................................... 7

2.1.1从系统研制编程到硬件设计的生命周期程序的信息流. ................................ 7

2.1.2从硬件设计的生命周期程序到系统研制程序的信息流............................... . 7

2.1.3硬件设计的生命周期与软件生命周期之间的信息流............................. 8

2.2 系统的安全评估程序 ............................................................................ 8

2.3 硬件安全评估 ........................................................................................ 10

2.3.1硬件安全评估考虑因素.................................................................................10
2.3.2硬件随机故障的定量评估............................................................................ 11

2.3.3硬件设计差错和混乱的定性评估............................................................... 11

2.3.4基于硬件故障状态的分类的的设计保证考虑因素 .......................................11

3.0 硬件设计的生命周期 .............................................................................. 15

3.1硬件设计生命周期的程序..........................................................................15

3.2过渡标准 .......................................................................................................... 15

4.0 计划编制程序.......................................................................................................... 16
4.1 计划编制程序的目标................................................................................................. 16

4.2 计划编制程序的工作 ................................................................................................16

5.0 硬件设计程序.....................................................................................................17
 5.1 需求捕获程序......................................................................................................19

5.1.1需求捕获程序的目标....................................................................................................19

5.1.2需求捕获的工作 ........................................................................................................19

5.2 概念设计的工作...............................................................................................................21

5.2.1 概念设计的目标 ......................................................................................................... 21

5.2.2 概念设计的工作.........................................................................................................21

5.3 详细设计程序 ................................................................................................................21

5.3.1 详细设计目标 .....................................................................................................21

5.3.2 详细设计的工作 .........................................................................................22

5.4 硬件设计实施程序 .......................................................................................................22

5.4.1 设计实施程序的目标 .............................................................................................22

5.4.2 设计实施工作 .................................................................................................22

5.5 产品过渡程序 ................................................................................................................23

5.5.1 生产过渡程序目标..............................................................................23

5.5.2 生产过渡程序的工作..........................................................................................23

5.6 验收试验 .....................................................................................................................23

5.7 批生产...........................................................................................................................24

6.0 确认及验证程序 .......................................................... ................................ 24

6.1 确认程序 .................................................................................................................24

6.1.1确认程序目标.....................................................................................................25

6.1.2确认程序工作..................................................................................................25

6.2 验证程序 ..................................................................................................................26

6.2.1验证程序的目标..................................................................................................26

6.2.2 验证程序的工作....................................................................................................26

6.3 确认及验证的方法 ............................................................................................27

6.3.1试验方法..................................................................................................................27

6.3.2分析方法 ................................................................................................................28

6.3.3 评审........................................................................................................................28

6.3.3.1 需求评审....................................................................................................29

6.3.3.2 设计评审.....................................................................................................30

7.0 构型管理程序 ............................................................. ................................. 31

7.1 构型管理的目标................................................................ .................................31
 7.2 构型管理的工作要求...... ............................................... ................................. 31

7.2.1结构的标识...............................................................................................................31

7.2.2 建立基线............................................................................................................32

7.2.3问题报告、跟踪以及纠正行为..........................................................................32

7.2.4 更改控制 .........................................................................................................33

7.2.5发布、存档及恢复 ......................................................................................33

7.3 数据控制类型..........................................................................................................34

8.0 程序保证.................................................................................................................35
8.1程序保证目标......................................................................................................35

8.2程序保证工作.....................................................................................................35

9.0 审定联络程序 ..................................................................................................35

9.1符合性的方法和计划编制 ..........................................................................................36

9.2 符合性依据.....................................................................................................................36

10.0 硬件的设计生命周期数据.....................................................................................37
10.1 硬件计划 ........................................................................................................................38

10.1.1硬件审定计划.......................................................................................38

10.1.2 硬件设计计划..................................................................................................39

10.1.3 硬件确认计划.................................................................................................39

10.1.4 硬件验证计划......................................................................................................40

10.1.5 硬件的构型管理计划...................................................................................40

10.1.6 硬件程序保证计划 .......................................................................................40

10.2 硬件设计标准和指南.............................................................................................41

10.2.1 需求标准............................................................................................................41

10.2.2 硬件设计标准.......................................................................................................41

10.2.3 确认和验证标准.............................................................................................42

10.2.4 硬件存档标准 .............................................................................................42

10.3 硬件设计数据 ............................................................................................................42

10.3.1 硬件要求 ........................................................................................................42

10.3.2 硬件设计的描述数据 .......................................................................................42

10.3.2.1 概念设计数据 ............................................................................................ 42

10.3.2.2 详细设计数据 ................................................................................................ 43

 10.3.2.2.1顶层图纸 ..................................................................................43

10.3.2.2.2 装配图纸 ..............................................................................43

10.3.2.2.3 安装控制图纸 ......................................................................43

10.3.2.2.4 硬件/软件接口数据.................................................................. 44

10.4 确认和验证数据 ...............................................................................................44

10.4.1 追溯性数据 .......................................................................................................44

10.4.2评审和分析程序................................................................................................44

10.4.3 评审和分析结果...............................................................................................45

10.4.4 试验流程.............................................................................................................45

10.4.5 试验结果 ...................................................................................................................45

10.5 硬件验收试验标准 .......................................................................................................46

10.6 问题报告............................................................................................................................46

10.7 硬件构型管理记录 .............................................................................................46

10.8硬件程序保证记录.........................................................................................................46

10.9硬件工艺概要........................................................................................................46

11.0 附加考虑因素...............................................................................................................48
11.1早期研制硬件的使用 ..........................................................................................48

11.1.1 对早期研制硬件的更改.................................................................. 48

11.1.2 在航空器上安装的更改.................................................................................... 48

11.1.3 对使用和预期设计环境的更改...............................................................49

11.1.4 对设计基线的升级........................................................................................49

11.1.5 附加构型管理的考虑因素 .......................................................................49

11.2成熟商用电子工艺器件（COTS）的使用............................................................49

11.2.1COTS器件的电子元件管理................................................................................. 50

11.2.2 COTS器件的采购 ......................................................................................... 50

11.3 产品使用经验 .......................................................................................................50

11.3.1产品使用经验数据的可接受标准...........................................................................50

11.3.2 产品使用经验数据的评估 .............................................................................51

11.3.3 产品使用经验数据的评估数据 ......................................................................51

11.4 工具评估和鉴定 ........................................................................................................52

11.4.1 工具评估和鉴定程序....................................................................................52

11.4.2 工具评估和鉴定数据...................................................................................... 55
附录A 基于硬件设计保证标准的硬件生命周期数据的调整
附录B A和B级别功能的设计保证考虑因素
附录D 缩写（只取首字母）

图表

图表 1-1 文献概述.................................................................................................................5
图表 2-1机载系统、安全评估、硬件和软件之间的关联 .....................................................6
图表 2-2 系统发展程序................................................................................................7
图表 2-3选择硬件设计保证策略的判定程序...........................................................13
图表 5-1 硬件设计生命周期.......................................................................................18
图表 11-1设计、评估手段的确定验证和限制.......................................................................53

表格

表格 2-1硬件设计保证标准的定义及与系统间的发展保证标准的关系................................9
表格 5-1典型的ASIC/PLD程序映射......................................................................................19
表格 7-1结合HC1及HC2的构型管理程序 ..............................................................34
表格 A-1硬件设计保证标准及硬件控制种类的得到的硬件生命周期数据...........................58
 中国民航大学 适航审定研究中心编译

1.0 绪论
电子硬件使用的日益复杂化给飞机安全性能的评估带来了许多新的挑战。这种挑战源

于： 由于硬件渐增的复杂性所导致硬件的设计差错愈加难以控制，飞机的功能将越来越容

易受到设计差错作用的危害。为了消除这种已经认识到的危险，在硬件的设计和评估程序中

必须保证每个潜在的硬件设计差错都能通过一个更加可靠和可验证的方式被排除。

随着机载电子设备复杂程度的提高、工艺的进步以及本文献在实践中和应用中不断获得

的经验积累，本文献将会采用RTCA/EUROCAE认可的程序进行修订和评估。

1.1 目标
本指南的编制用于协助一些组织，为其提供记载电子硬件研制的设计保证指南，使其在

限定环境下能安全实现其预期功能。本指南适用于所有通用的、新近的和新兴的工艺应用。

本文献的目标在于以下几个方面：

1.定义硬件设计保证的目标。

2.对此目标的基本原则做出描述，以帮助使用者对这个指南做出正确的理解。

3.提供设计目标的描述，能够让使用者制定遵循本指南或其他指南的方法。

4.为设计保证提供工作指南，以达到设计保证的目标。

5.当新的程序技术适用时，允许弹性选择不同的程序去实现本指南的目标。

本指南推荐为实现设计保证目标的所应做的工作，而不给出设计是如何被实现的。

本指南的编撰原则是一种基于电子硬件所承担的系统功能、自顶向下的观点，而不考虑

自底向上的或仅依靠某个特殊的硬件元件单独的实现某个功能的观点，

自顶向下的方法在推动系统和硬件设计决策、有效并充足的验证程序时，能更有效地定

位安全设计差错。比如，验证工作应当在系统、组件、子组件、元部件或硬件项目能达到要

求且验证目标得到满足时的最高级别进行。

1.2 范围
本文献从概念上为机载电子硬件提供设计保证指南，贯穿于初始的适航审定到为保证持

续适航的证后改进。此文献是依从运输类飞机和硬件的审定要求为基础发展起来的，但也可

以应用于其它设备。

系统生命周期和硬件设计生命周期之间的关系在文献中被描述，以帮助理解系统与硬件

设计保证程序之间的关系。对于包括系统安全评估及确认、飞机级的符合性验证程序的完整

系统生命周期描述并非本文献的编制目的。

审定问题只在与硬件设计的生命周期相关时讨论。关于硬件生产、试验、维修方面的能

--1--
 中国民航大学 适航审定研究中心编译

力问题，只在涉及到硬件设计的适航性时提出。

这个文献的指南适用但不局限于以下硬件项目：

1.航线可更换组件（LRU）

2.电路板组件

3.自定义的编码组件，比如特定用途集成电路和可编程逻辑电路，包括相关的系列功能。

4.集成工艺器件，如数模混合模块和多芯片模块。

5. 成熟商用电子工艺器件。

对于成熟商用电子工艺器件，不必遵循这部文献的设计程序以及硬件设计生命周期数

据，有关成熟商用电子工艺器件的附加考虑因素在十一部分中描述。

对于软硬件结合的器件，应当遵循相应规定鉴定为硬件或软件，然后再使用本指南或

RTCA DO-178。

注意：在系统设计和功能分配阶段，允许选取一个有效的设计保证和实施方法。在方案

确定以后，所有的人员必须在系统的方案上达成一致。

硬件设计和验证工具的评估和鉴定在11.4部分中给出。

此文献没有为有关组织结构以及组织的职责划分提供指南。对环境的验证标准也不包括

在此文献的范围之内。

1.3与相关文献的联系
除了适航要求以外，还有许多各种国家或国际的硬件标准，一些管理机构也许会要求遵

循这些标准，但是援引其它国家或国际的标准，以及将可以援引的标准的遵照办法作为本文

献的附录，已经超出了这个文献的范围。在此文献中用到的术语“标准”，是指机载系统/

设备、发动机或飞机的制造商在应用中的特定项目标准。这些标准都是由制造商依据一些通

用标准引申而来的。有关标准的指南在10.2部分中描述。

1.4相关的文献
SAE ARP4754/EUROCAE ED-79《关于高度综合或复杂系统审定考虑》，将作为一个高

复杂度综合度的航空器研制的基本指南材料。

SAE ARP4761, 《对民用机载系统和设备进行安全性评估程序的指南和方法》，将作为

在硬件设计保证程序中系统安全评估方法的基本指南材料。

RTCA DO-178/EUROCAE ED-12,《机载系统和设备合格审定中的软件考虑》，可作为

对软件研制保证的一个补充文件。

RTCA DO-160/EUROCAE ED-14,《机载设备的环境条件和试验程序》，可被硬件设计

-2-
 中国民航大学 适航审定研究中心编译

者作为硬件合格鉴定的主要外部环境试验标准。

1.5使用说明
本文献预期为国际民航组织采用，以使文献在使用时最少地涉及特定国家的法规程序。

同时，本文献采用了一些通用性术语，比如术语“审定当局”，就是那些代表国家的、能对

审定工作负责的组织或者个人。当另一个或者一些国家参加审定时，文献要求在各个国家之

间达成的双边协议或者参与国间的备忘录中对本文献予以认可。

本文献代表了大多数民航组织的意见，是机载电子设备设计保证最优工艺方案的集合。

考虑到本文献的所开发的程序，其目标是为了提供的指南能够适用于完善新的硬件设计及后

期的更改。早期研制的硬件的指南程序在11.1部分中。至于本文献所未描述的方法，也可以

被申请人提出和采用。

当需要举例说明此指南材料该如何被应用时（不管是通过图表或者描述），这些例子

不能被视为推荐的首选方法。

第 11 部分讨论了对于由 2 部分到 9 部分中一些不能被实现的目标，可能导致的特殊情

况的附加考虑因素。这些因素包括早期的研制硬件的应用、成熟商用电子工艺器件的用法、

使用经验、工具的评估和限定等方面。

附录 A 为必要的硬件设计生命周期数据提供指南，此数据基于硬件所实施的研制保证

等级。

附录 B 用于指南除遵循第 2 部分到 11 部分的指南外，实施 A 和 B 级别功能的硬件的

研制保证还应遵循的一些附加技术。对于 C 和 D 级的硬件，可以由申请人选择是否执行。

缩略语解释在附录 D 中。

文中的列表内容不意味着它包括全部的元素，或其中的项目相关于某一特殊的产品。

此文献中注释用于提供说明性的素材、强调要点，或者提醒读者参见相关课题。注释

中不包含指导性内容。

文中使用“应该”一词，来表示需要遵循的指南内容，使用“可以”一词表示可以选

择遵循的内容。

本文中所使用的“硬件”是针对于电子硬件。文中所述的“需求”，只针对电子硬件

-3-
 中国民航大学 适航审定研究中心编译

而言，至于针对系统和软件时，将特别说明“系统需求”或“软件需求”。

注释：各种的工业咨询文献和航空要求文献中不一定适用同样的术语。比如联邦航空规

章21（FAR）和联合航空规章21（JAR）中用“产品”意味着航空器、飞机发动机、

或者推进器。文献SAE ARP4754/EUROCAE ED-79采则用“产品”表示硬件、软件、

项目或者系统。读者要知道这些术语应用上的差别。本文献对术语给出了定义。

1.6 复杂度分析
虽然各种关于术语“复杂度”的分类被用于电子学，例如：简单、复杂和高度复杂，

但对它们分类的区别并没有严格的定义。本文描述复杂度区别的定义是基于：为达到可接

受的覆盖程度，而采用明确方法实施必要的符合性验证的可行性和困难程度。

硬件应该以集成电路、集成板和航线可替换组件等不同层面、分等级地进行检查其复

杂度，包括检查不能试验的功能，比如在多用途器件中未使用的功能模块和状态机中潜在

的隐藏状态。

当通过综合一组全面、明确的试验以及相应于硬件设计保证等级的设计原理分析，能

够证明硬件功能在可预计的环境条件下正常运行，并且不会出现异常状态，则硬件项目可

以被定义为“简单”。

当一个项目不能定义为“简单”时，就应当被定义为“复杂”。一个由许多简单的小

项目综合而来的产品项目，可能也会构成一个复杂的项目。若产品项目中包含，如 ASIC

或 PLD 的器件，如果能满足上述定义“简单”的标准，也可以认为是“简单”的。

对于复杂的产品项目，用于提供设计保证的方法建议应该在硬件设计生命周期的早期

获得局方的同意，以降低项目的风险。

对于简单的硬件项目，不需要大量设计程序中的文件，但对于支持符合性验证和构型

管理的程序则应当实施并保留证明文件。因此，对于“简单”产品项目，在执行本指南材

料的程序中，会在管理费用上有所降低。此文献的主要作用是针对于复杂硬件项目研制。

1.7 替代的方法或程序
其他替代的方法和程序，也可以用于提供硬件设计保证。但这些方法和程序必须依据

对适用规章符合程度进行评估。选择替代的方法或程序应该在实施前先获得适航当局的批

准。

对替代方法或程序进行评估需要考虑的事项可以包括：

1.用于代替此文献规定的程序，这些程序满足从第 2 部分到第 9 部分的一个或者多个

目标，并能够表明等效水平的设计保证。

-4-
 中国民航大学 适航审定研究中心编译

2.所提议的替代方法或程序对满足硬件设计保证目标的作用效果应该通过评估。

3.所提议的替代方法或程序对生命周期数据的作用效果应该通过评估。

4.对申请人采用替代方法或程序的基本原理，应有证据证明它能达到预期的目标。

1.8文献概况

图1-1是对此文献的一个总的概述以及各章节之间的联系。图标中没有给出数据数据流

图，但是给出相关的章节和外部程序。

系统需求 FAR/JAR 以 系统研制指 安全评估指 环境鉴定试

及咨询材料 导 导 验指导

研制限制 起始需求 必须的更改

• 硬件设计保证的系统方
面考虑
设计程序 生产程序 服务
• 硬件设计生命周期
• 计划编制程序
• 附加考虑因素
• A、B 级功能设计保证考 支持程序：
虑因素 • 确认及验证程序
软件研制指
• 构型管理程序
导
• 程序保证
• 审定联络程序

• 硬件设计生命周期的数据
• 硬件设计保证等级和构型控制规程的硬件设计生命周期
数据

图 1-1 关系概述

-5-
 中国民航大学 适航审定研究中心编译

2.0 硬件设计保证的系统方面
硬件设计保证始于分配给硬件的系统功能以及基于系统研制保证级别的指派等级。

一个单独的系统功能可以分派给一个硬件项目，一个软件或者一个软硬件结合体。对

一个功能的安全性需求需通过系统层面、软件层面以及硬件层面去确定相应的可靠性等级

和研制保证等级，以保证其相应的安全性需求得到满足。

图 2-1 阐明了机载系统和设备的安全评估、硬件研制以及软件研制程序之间的
联系。

系统

安全评估

安全/软
安全/硬
件
件
安全/硬
件/软件
软件
硬件
硬件/软
件

图表 2-1 机载系统、安全评估、硬件和软件之间的关联

图中有四个交叠的区域，安全/硬件、安全/软件、硬件/软件和安全/硬件/软件。由于一

个系统需求可以引入多个指导程序的保证等级和范围要求，这些交叠的区域就阐明了各指

导程序之间的关联和相互作用。比如一个硬件功能如果包含安全要求则会涉及安全评估程

序和硬件设计生命周期两个程序。

交叠区域阐明了各指导程序的协调交联关系，以确保系统功能的保证要求得以满足。

有关系统或者软件保证程序的讨论超出了此文献的范围。但是，为了配合一个硬件功能的

设计保证工作，申请人可能会用到系统和软件程序中提供的保证工作。

-6-
 中国民航大学 适航审定研究中心编译

这些关联和相互作用将在 2.2.1 到 2.1.3 部分中有进一步的描述。

2.1 信息流
图 2-2 中是各生命周期程序之间的信息流。下面将描述从系统研制程序到硬件设计生

命周期程序、从硬件设计生命周期程序到系统研制程序以及硬件设计生命周期程序与软件

生命周期程序之间的信息流。

注：一般会有一些反复性的程序和更改贯穿于整个硬件设计生命周期。

系统研制程序

2.1.1 部分

2.1.1 部分

硬件设计生命周期
软件生命周期程序 2.1.3 部分 程序

图 2-2 系统研制程序

2.1.1 从系统研制程序到硬件设计的生命周期程序的信息流
这些信息流可以包括：

1．分配到部件的设计和安全需求。

2．针对基于相关需求和失效状态（如适用）的每一功能设计保证等级。

3．硬件功能故障的分配概率和风险曝露时间。
4．硬件和软件的接口描述。
5．安全策略和设计约束条件的要求，如可试验性、设计方法和硬件结构。
6．在系统级符合性验证工作中需要硬件方面来完成的要求。
7．分配给硬件的安装、人机环境和运行环境的要求。
8．影响硬件需求方面的综合问题报告。如系统符合性验证、系统需求生成或
SSA 等这些工作中可能产生一些要求。

2.1.2 从硬件设计的生命周期程序到系统研制程序的信息流
这些信息流可以包括：

1．需求的实施，如机械图纸、原理图和零部件目录等。

-7-
 中国民航大学 适航审定研究中心编译

2．可能影响系统分配要求的由硬件本身产生的要求。

3．结构实现，包括故障容限边界。

4．任何要求在硬件设计生命周期里完成的系统验证和“确认”工作的证明材料。

5．产品安全性分析的数据，如：

a.涉及 SSA 程序中分派给硬件的功能性失效概率和故障率。

b.共模故障分析。

c.隔离边界和一般性故障减缓策略。

d.与系统需求相关的潜在分析数据。例如用于监控的硬件、故障探测间隔以及不可

探测的故障。

6．硬件验证需求中需要通过系统级的符合性验证工作完成的部分。

7．需确认的关于安装需求和（分析所必需的）环境条件的假设与分析方法。

8．可能影响系统、软件或分派给硬件的需求的问题或者更改报告。

2.1.3 硬件设计的生命周期与软件生命周期之间的信息流
这个信息流可以包括：
1．由软硬件集成程序中产生的需求，例如协议的定义、时序限制、软硬件接
口的寻址方式。
2．软硬件符合性验证程序中需要联调的程序。
3．判定硬件与软件之间不兼容之处（可以成为报告和纠正系统的一部分）。
4．系统安全评估程序中保证可以提供的数据。

2.2 系统的安全评估程序
系统评估程序有三个：功能风险评估（FHA）、初步系统安全评估（PSSA）和系统安

全评估（SSA）。这些程序用于建立适用于系统研制保证程序的系统安全目标，并确定系

统功能能到达到安全标准。

安全评估程序应该将安全目标转换成系统和硬件的安全需求，这些需求应该具体表达

出系统和设备的功能和结构的基本安全目标和安全特征，安全评估程序和系统研制程序再

将这些安全需求分配给硬件。最初，都是在安全评估程序中采用 FHA 来确定潜在危险，然

后通过 PSSA 程序将安全需求和相应的失效状态分配给硬件的功能执行部件，以确定每个

硬件功能的设计保证等级。

贯穿整个硬件设计生命周期，在安全、系统和硬件之间可以产生重复的反馈以保证硬

件的设计和实现能满足系统的安全要求、功能以及分配给硬件的性能要求。

-8-
 中国民航大学 适航审定研究中心编译

表格 2-1 硬件设计保证等级的定义以及与系统研制保证级别的关系

系统研 失效

制保证 状态 失效状态描述 硬件设计保证等级定义

级别 分类

A：在硬件安全性评估程序中显示，

灾难 由于其功能故障或异常工作可引起
级别 A 影响持续飞行和着陆的故障状态
性的 一个系统功能失效，从而造成飞机

的“灾难性”失效状态。

降低飞机性能或机组应付不利运行条件能力的 B：在硬件安全性评估程序中显示，
危险 失效状态，其影响包括：安全裕度或飞机性能的 由于其功能故障或异常工作可引起
级别 B 的/严 大幅度下降；让机组人员无法精确和完整地完成 一个系统功能失效，从而造成飞机
重的 任务的身体压力或过重的工作负担；或对少量机 的“危险/严重”失效状态。
上乘员的严重或潜在致命伤害。

降低飞机性能和机组应付不利运行条件能力的 C：在硬件安全性评估程序中显示，

重大 失效状态，其影响包括：安全裕度或飞机性能显 由于其功能故障或异常工作可引起
级别 C
的 著下降；显著地增加机组工作量或降低其工作效 一个系统功能失效，从而造成飞机

率；或使机上乘员的感到不适甚至受伤。 的一个重大失效状态。

轻微的降低飞机安全的失效状态，但仍然在机 D：在硬件安全性评估程序中显示，

组人员有能力解决的范围之内。其影响包括： 由于其功能故障或异常工作可引起
轻微
级别 D 安全裕度或飞机性能的轻微下降；稍微增加了 一个系统功能失效，从而造成飞机
的
机组的工作量，比如飞行计划的改变；造成机 的轻微失效状态。

上乘员的不便。

E：在硬件安全性评估程序中显示，

硬件功能故障或异常工作所引起的

无影 不会影响飞机性能以及增加机组工作量的失 系统功能失效，不会影响飞机的操
级别 E
响的 效状态。 作性能和机组的工作量。对于 E 级

功能，不适用于本文献，仅在此作

为参考。

-9-
 中国民航大学 适航审定研究中心编译

2.3 硬件安全评估
硬件安全评估受SSA程序指导，并协同和支持SSA的程序。这个安全程序的目的是表明那

些适用的系统和设备（含硬件）已达到航空器型号合格审定中相应的安全性要求。

当给定分配给硬件的安全、功能和性能的需求时，硬件安全性评估确定针对每一功能的

硬件设计保证等级，并依次确定相应的设计保证策略。

2.3.1 硬件安全评估考虑因素
硬件项目项目设计者需要表明对安全性要求的符合性，以及采用适当设计保证策略以符

合硬件设计保证等级要求。

一个设计保证等级和策略有可能可以应用于整个的硬件项目，同时，一个硬件项目也可

能可以被看作多个执有单独的功能失效路径（FFP）来评估，每个功能失效路径采用各自适

当的设计保证等级和策略。功能失效路径分析（FFPA）可以被用于证明硬件项目中的某个模

块可以采用比产品低的设计保证等级，或者用来证明针对不同的功能可以采用不同的技术或

产品使用经验支持数据来实现。

注释：FFPA在附录B中的第二部分有描述。虽然附录B针对与A级、B级设备，但是FFPA

方法也可应用于任何一种设计保证等级。

如果某个硬件项目本身包含不同设计保证等级的功能，这种情形可以通过以下任一一种

方案解决：

• 整个产品项目全部遵循其最高的设计保证等级。

• 如果单独的硬将功能能够在功能、接口、共用资源上采取保护措施，并不会被低级
别的功能影响，单独的硬件功能按照硬件安全性评估程序中定义的硬件设计保证等

级分别遵循各自的级别保证。对于共用的资源部分，应当采用其最高功能影响所对

应的设计保证等级。

对于硬件的安全性评估指南包括：

1．不断修正的硬件安全评估和设计程序应能确定硬件派生的安全需求，且保证分配给

硬件的系统安全需求以及派生的安全需求能得到满足。

2．衍生需求应该包括对硬件结构、电路和元件的安全需求，而且保护其不受异常工作

状态的侵害。将硬件结构和功能性安全属性结合的保护措施包括：

a.电路或者元件冗余；

b.电路与元件之间的分离和电气隔离；

c.电路和元件之间的非相似性设计；

- 10 -
 中国民航大学 适航审定研究中心编译

d.电路和元件的监控。

e.保护或者重配置机构。

f.电路和元件的随机故障与潜在故障允许的故障比率和概率。

g.用法和安装的限制。

h.扰动和扰动恢复的预防和管理。

3．硬件设计保证程序和硬件安全评估应该共同确定专属的符合性方法和每个功能的设

计保证等级，以及确定达到了一个可被局方接受的设计保证等级。

注释：硬件的异常工作状态可能是由硬件任一故障或者设计差错或者干扰造成的。
硬件的设计者可以为硬件项目功能选择一个更高级别的硬件设计保证水平。例如在安装

中要求对于一个功能的复用就会需要一个更高的设计保证等级。

硬件安全评估可以采用各种各样的定性及定量分析方法，它们可以包括故障树分析

（FTA）、共模分析、故障模式及影响分析和对随机故障定量评估的统计学可靠性分析法。

2.3.2硬件随机故障的定量评估
它是基于硬件故障率、冗余、分区和隔离、故障模式统计、概率分析、元件降级、负荷

分析以及制造程序控制的一种统计学的故障评估和预测方法，此种方法已被证明是一种定量

评估硬件随机故障风险因素的可靠方法。

2.3.3硬件设计差错和混乱的定性评估
不同于硬件的随机故障，设计差错或一些意外扰动因素并不能用统计学来预测，两种因

素可能会以共模故障的形式破坏所有的冗余度边界。冗余的管理技术和采用的定量评估方法

应合理选择，以便在必要的时候能够排除或减轻潜在的共模故障和干扰因素所带来的影响。

虽然定量评估存在一定的困难，由设计差错和干扰因素带来的安全风险仍能够通过实际

应用定性安全评估方法进行有效的评估。比如故障树分析、共模分析以及功能故障模式及影

响分析（F-FMEA），都是用于寻找硬件设计差错和干扰因素的基本定性分析法，这些方法

能够确定硬件设计差错和干扰因素的潜在影响，并且帮助确定排除和减轻影响的方法。通过

使用这些方法，硬件安全评估能够帮助确定应该采取什么样的设计保证策略，并且这些策略

应可以在硬件设计程序的不断地修正，以定性地选择合适策略完成设计保证。

2.3.4 基于硬件故障状态分类的设计保证考虑因素
随着系统失效状态严重性的增加，用于减少相关失效状态的硬件设计保证量也在增加。

对所有的设计保证等级，应该有一种方法和策略来确定合适的设计保证等级。图2-3描述了

设计保证策略的制定程序。

指南包括：

- 11 -
 中国民航大学 适航审定研究中心编译

1．对于实施 A 或 B 级别功能的硬件，设计保证应该关注寻找潜在的异常工作状态和

硬件功能的潜在设计差错。

2．当针对每一硬件功能实现来制定设计保证策略时，图 2-3 描述的决策制定程序应当

被遵循。

3．除本文献第三到第十一部分提供的指南外，A 级和 B 级功能还应采用在附录 B 中

描述的策略。

4．所选用设计保证策略应该作为硬件结构和使用以及硬件实现技术的一个功能。

不同的技术、元件选择和用法导致了硬件设计生命周期信息的多样化以及针对设计差错

及其影响的内部保护措施的多样化。最适当的设计保证方法可以在相同的硬件项目项目中针

对不同的功能路径有所不同。

在图2-3描述了设计保证策略的决策程序，图中的决策和行动项目将在后面对应数字标

号的段落中描述。

- 12 -
 中国民航大学 适航审定研究中心编译

1
起始评估程
序

级别 A 或者 B 2
级别 D 或者 E
决定 FFP 设
计保证等级

级别 C
3
硬件的实现是简
单还是复杂？

复杂 简单

4
制定复杂的
A 级或 B 级 FFPs
设计保证策略

策略修改

4
5 6
否 是
策略是否 证明记录适用的
足够？ 失效-安全性

7
证明记录设计保证
方法和策略

8
执行方法

图表 2-3 选择硬件设计保证策略的判定程序

- 13 -
 中国民航大学 适航审定研究中心编译

1.早期评估程序

对于所有的设计评估级别，必须制定一定的方法或策略来保证选取了一个适当的设计

保证等级。

2.确定 FFP 设计保证等级

对于每个确认的硬件产品项目，结合该项目和设计保证等级确定并证明该项目的

FFPs。应依据惯用的安全评估方法来确定硬件电路是否在 A 级或者 B 级的 FFPs 中。

3.功能故障路径（FFP）的硬件实现是简单还是复杂

对于 A 级和 B 级硬件设计保证 FFPs,应依据 1.6 部分确定硬件的复杂度。

4. 制定复杂的 A 级或 B 级 FFPs 设计保证策略

如果一个 FFP 是复杂的 A 或者 B 级别，采用附录 B 中描述的附加方法去确定适当的

设计保证策略、相应的执行理念和故障减缓方法。对于每个 A 和 B 级别的 FFP，应采用高

级分析方法、使用经验或结构缓和法作为设计保证策略。对于 A 级 FFPs，如果一种保证

方法无法完全实现对潜在故障或异常工作状态的减缓，就可能需要采用多种方法来保证。

5.策略是否足够

确定设计保证策略是否存在不足之处，如果在设计保证策略和预期应可提供的数据中

存在不足之处，应提出附加的设计保证、执行和结构策略以修改纠正原本策略的不足之处。

当设计保证策略可以接受时，对每个 FFP 的设计保证程序做出证明和记录。此策略也

应当明确局方的参与方面，比如进度节点、项目评审和行动监督。

6.证明适用的故障-安全性。

确定适当的故障-安全设计结构和硬件项目特性，并就系统的可用性和完整性进行分

析，证明产品的故障-安全设计和相关的共模分析、概率分析、结构特征以及其他特性。

7.证明、记录设计保证的方法和策略。

在系统审定计划或者硬件审定计划方面（PHAC）中，证明适用的设计保证方法和策

略，并获得局方的批准。

8.方法的实施。

依照被局方批准的计划实施硬件设计，并记录、证明对于已批准的计划和策略符合性

- 14 -
 中国民航大学 适航审定研究中心编译

的证据。

3.0 硬件设计的生命周期
本部分略述了将在4‐‐9部分中讨论的硬件设计生命周期。本文献不会规定一个首选的生

命周期模式，也不会规定一个执行组织的结构。硬件设计生命周期适用于系统或设备的初次

研制以及改装。每个项目生命周期都以由项目特性决定的对程序和行为的选择和安排为基

础，比如硬件的稳定性、早期研制的硬件和硬件设计保证等级的应用。硬件设计保证的生命

周期可能有重复性，更确切的说就是在这个程序中的输入、再输入和不断发展的改进以及反

馈。

3.1硬件设计的生命周期程序。
硬件设计的生命周期程序为：

1．硬件的计划编制程序（文献第四部分），用于定义和协调硬件项目设计和支持程序

的工作。

2．硬件设计程序（文献第五部分），产生设计数据和生成硬件项目。这个程序包括需

求捕获、概念设计、详细设计、设计实现和生产过渡。

3．支持程序（文献第六到九部分），得出硬件设计生命周期资料，以保证对包括计划

编制、设计、硬件安全性评估和支持程序的硬件设计生命周期及其输出的正确性和可控性。

支持程序与计划编制和设计程序一起协同完成，支持程序包括需求确认、符合性验证、构
型管理、程序保证和审定联络。

3.2过渡标准
由于在不同研制阶段可能会包含许多不同子项目，为了应对此种问题的挑战，应有一种

方法，实现对设计程序的合理控制，以管理在前一个程序全部完成前开始进入下一个程序所

带来的风险。过渡标准，定义为用于评估从一个程序到另一个程序转换所需具备的最小数据，

可以用于一些程序的关键节点。在计划编制程序需分析确定过渡标准的使用，不是每两个程

序间都必须要有过渡标准。过渡标准的选择应该评估对安全性的影响，比如，在功能合格审

定中的功能符合性验证前，对于功能的需求应该予以证明、记录，其功能实现则必须在构型

管理的控制之下进行。

过渡标准在硬件计划中应该被证明、记录。过渡标准的使用并不意味着任何特殊的生命

周期模式的产生，或者阻止如快速样机和工程一致性的研制策略等。

- 15 -
 中国民航大学 适航审定研究中心编译

4.0计划编制程序
本部分描述用于控制硬件项目研制的硬件计划编制程序。通过本程序生成可以被编制在

一个或者多个文件中的硬件计划。如果是多个文件的方式，顶层硬件计划中应包括所引用的

支撑材料。对于一些涵盖特定硬件设计生命周期程序（如构型管理或程序保证等）的标准文

件，如果它们达到了适用程序的预计目标，也是可以接受的。

4.1 计划编制程序的目标
计划编制程序的目标是去定义一种方法，通过这种方法，将对硬件项目的功能和适航需

求转化到硬件项目中去，并有足够的证据表明硬件项目将能够安全的执行其预期功能。

硬件计划编制程序的目标包括：

1. 定义硬件设计生命周期程序。
注：工作活动、重大节点、输入、输出及组织机构职责等可以包含在计划之内。

2.选定标准并对其进行说明（定义）。

3.选定或定义硬件研制和验证环境。

4.将遵循硬件设计保证目标的方法（含按照2.3.4部分确定的策略）， 提请审定局方批

准。
注：新进的技术、工具和程序可能需要改变计划编制程序的细节，因此，计划编制程序
需要一定的灵活性。

4.2计划编制程序的工作
对于计划编制程序的指南包括：

1．硬件设计生命周期程序（包括过渡标准，如适用还将包括各程序间的关联，例如顺
序、反馈机制等）。

2．对于建议的设计方法应该进行定义和解释。包括对预期产品的考虑以及与其验证方

法的原理。

3．项目中将使用的硬件设计标准（包括接受范围内的偏离），应当被确立。这些标准

可以来自通用的质量标准，也可以来自公司或项目的特定标准。

注释：这些标准是通过对早期研制中已被证明的工业实践进行整理，以帮助降低不可测

的设计错误的概率。

申请人和硬件的开发者应该明白，在一个新的设计和技术领域应用标准时，标准

可能会不全部适用。由于设计限制、与系统需求的冲突或者与新技术的不兼容性

等因素所造成的对标准的偏离有可能是必要的。计划编制程序可以看成一个检查

对标准偏离可接受程度的时机。
4．协调硬件设计程序和支持程序的方法应该被确定，这些方法应当重点关注系统、软

- 16 -
 中国民航大学 适航审定研究中心编译

件和航空器审定相关的活动。

注释：协调程序可以是以时间节点表的形式进行，该时间节点表主要描述实现本文献所

述程序目标的事件。

5．各个硬件设计程序和关联的支持程序的工作活动应该被定义。且定义应该在让硬件

设计程序和关联的支持程序受控的级别上。

6．选择确定设计环境，包括工具、流程以及用于研制、验证和控制硬件项目与生命周

期资料的软件和硬件。

a.如果验证要用到多项工具，对工具操作顺序应该在各自的计划中详细的说明。

b.设计环境对设计结果会产生影响，第11.4部分对工具的评估和工具使用限制做出了指

导。

7．影响审定又不可避免的偏离如果会发生，则应在已制定的计划中定义偏离程序。

8．用于识别、管理和控制硬件、关联的基准及硬件设计生命周期资料的政策、流程、

标准及方法应该被描述。

9．如果申请人想要在硬件研制生命周期中全部或部分使用转包商，硬件计划应该确立

保证方法，来实现设计保证目标。

10．用于实现硬件设计程序保证的策略和流程应该被描述。

11．验证程序和程序保证的独立性以及相关机构的职责应该在硬件审定计划（PHAC）

里被描述。

12．为满足此指南的目标而用到的方法应该被记录，并在此程序中及早的传达给审定局

方。这些方法应该记录在硬件审定计划（PHAC）中。

注释：有关这些方法的任何更改将被鼓励及时去协调，这种协调将使审定数据作为满足

设计保证要求证据的置信度增大。

5.0硬件设计程序
硬件设计程序设计一个实现从系统需求分配到硬件需求的硬件项目。本部分描述了五个

主体程序，如图5-1所示，包括需求捕获、概念设计、详细设计、设计实现和生产过渡。这

些设计程序可应用于任何层次的硬件项目级别，如航线可更换件、电路板组件和专用集成电

路（ASICs）以及可编程逻辑电路（PLDs）。以下各节描述了每一程序、目标及应被关注的

- 17 -
 中国民航大学 适航审定研究中心编译

（以降低影响安全的设计差错和设计实施差错的概率）有关工作。在硬件设计计划里，每一

个程序的计划和详细资料的记录是很重要的。

每一程序及程序之间的相互作用可以是反复的。对每一次反复，在每个程序中更改的影

响都应该是可追朔的，且要评估对以前反复结果的影响。

注1：对贯穿于整个设计程序中的程序资料进行归档是一种良好的工程实践经验，如设

计注释、设计评注注释和问题报告。

现行实践提供了许多不同的方法（包括图形的、数学的、基于数据库或文本的）描述设

计需求和设计实现，例如图表、硬件描述语言（HDL）、状态图，布尔描述和图形法等。

注2：有些描述方法适用于某一特殊的程序或程序的组合，如需求捕获、概念设计或详

细设计，而有些方法能更有效的实现某一特殊的实施技术。无论采用何种设计描述

方法，都应该提供支持设计保证等级的证据。

对每个设计描述方法，均应考虑以下内容：

1. 无论采用某一描述方法或某些描述方法的组合，都应该遵循本文档的指导方法。

2.设计描述方法应该允许硬件项目能完整地复制。

3.设计描述中某一小更改可能给设计实现带来很大的影响，应当关注这种更改对设计保

证的影响。

4.设计描述环境或方法在设计资料基准确定后可以更改，若果发生这种情况，应当评估

这种更改对设计复制的影响。

支持程序：
• 确认和验证程序
计划编制 • 配置管理
• 程序保证
硬件设
制

• 审定联络
计程序
造
程 序

需求捕 概念设 详细设 设计实 生产过

获 计 计 施 渡

衍生需求
图表 5-1 硬件设计生命周期
- 18 -
 中国民航大学 适航审定研究中心编译

HDL设计描述方法采用基于文本的编码技术，这同软件描述的用法表面上很相似，这种

表面上的相似性可能误导使用者试图在HDL或其它硬件描述语言的设计描述中直接使用软

件验证方法。本文献的指导方法对采用HDL描述方法进行硬件设计的设计保证是适用的。

注 ：整个文献中描述的结构化程序适用于复杂的硬件设计（包括ASICs和PLDs）。例如，

下表是与图5-1中描述程序对应的典型ASIC/PLD设计程序。

表 5-1 典型的 ASIC/PLD 设计程序与本文描述程序的对应关系

典型的 ASIC/PLD 设计程序 描述程序
高级别计划的部分 计划编制（第 4 节）
ASIC/PLD 构架选择 安全评估（第 2.3 节）
ASIC/PLD 需求捕获 需求捕获（第 5.1 节）
ASIC/PLD 初步设计（包括特性设计） 概念设计（第 5.2 节）
ASIC/PLD 详细设计（包括综合、掩模生成及熔丝文件） 详细设计（第 5.3 节）
ASIC/PLD 制作（包括外部制作和试验以及可编程器件 设计实现（第 5.4 节）
编成）
ASIC/PLD 生产过渡 生产过渡（第 5.5 节）
ASIC/PLD 确认及验证（包括定时器分析、性能仿真、 确认和验证程序（第 6
门级仿真和设计 ） 节）
ASIC/PLD 构型管理（包括工具和零件数据库） 构型管理程序（第 7 节）

5.1需求捕获程序
需求捕获程序确定和记录硬件项目需求，包括由预期的硬件结构、工艺选择、、基本和

可选功能、环境和性能需求所带来的衍生需求，以及由系统安全评估附加的需求。这一程序

具有反复性，因为附加需求可能在设计程序中才能知道。

5.1.1需求捕获程序的目标
需求捕获程序的目标是：

1．确认、定义和描述需求。包括由PSSA分配的需求和源自硬件安全评估的衍生需求。

注：验证结果和硬件需求的可追溯性在第6节重点描述。在需求捕获程序的程序中建立

这种可追溯的方法是值得做的。

2．将产生的衍生需求反馈到适当的设计程序。

3．将需求遗漏和差错反馈到合适的设计程序以便解决。

5.1.2需求捕获的活动

- 19 -
 中国民航大学 适航审定研究中心编译

需求捕获活动是一个反复的程序，这个程序帮助保证设计实施需求、系统需求和软件需

求同硬件需求的一致性。

需求捕获活动的指南包括：

1．由系统需求分配到硬件项目的需求应该有文件描述，这些描述可以包括要确认的需

求，在功能、性能以及构架这些方面的考虑，例如隔离、BIT、可试验性、外部接口、环境、

试验和维护要求、电源、物理特性等。。

2．应确定来自PSSA的涉及硬件项目的安全性需求。这些包括：

a.在硬件中对要实现的功能有影响的设计保证等级。

b.对失效或功能丧失的概率要求。

c.选择符合功能分配的硬件构架和功能安全特性，这些概述在2.3.1中。

3．确定由于生产程序、标准、程序、工艺、设计环境和设计手册等原因产生的设计限

制。

4．确定设计实现需要的衍生需求。由硬件安全评估产生的与安全性相关联的需求应当

是唯一的确定。

注 ：衍生需求主要强调条件，比如：

a.特殊限制：确保一个设计保证等级高的功能同一个设计保证等级低的功能接口

时，前者能够承受后者的功能异常的影响。

b.输入数据的范围（包括典型值和最大值），以及在数据字或控制寄存器中位的高、

低状态。

c.电源复位或其它复位状态。

d.供电电压和电流要求

e.与时间相关功能的性能，如滤波器、积分器和延时。

f.可能的状态机转换（无论是否预期到）。

g.正常和最坏情况下的信号时序关系或电气条件。

h.噪音信号和串扰。

i.异步逻辑电路中的信号干扰。

j.对于控制未使用功能的特殊限制。

5．衍生需求应反馈到SSA程序中以便评估其对系统需求的影响。

6．需求信息应以定量的形式在文件中提供，并带有容差（如适用），这不包括设计或

验证方法的描述。

7．在此程序中发现的需求遗漏或差错应该反馈到系统的研发程序。

8．这些需求，包括为满足PSSA要求产生的需求，应可以追朔到更高层级的需求。衍生

需求应尽可能的通过分层级被确定和追踪。

- 20 -
 中国民航大学 适航审定研究中心编译

注 ：分配的硬件安全性需求的系统级确认可在需求捕获程序中进行，衍生硬件需求的

确认在6.1节中描述。

5.2概念设计程序
概念设计程序形成一个高层级的设计概念，通过对这一概念的评估，以确定最终设计实

现符合需求的可能性。用功能框图、设计和结构描述、电路板组装图及机架简图等项目可完

成这一程序。

5.2.1概念设计的目标
概念设计目标是：

1．硬件项目概念设计同其研发需求保持一致。

2．将衍生的需求反馈到需求捕获或其它适当的程序。

3．将需求遗漏和差错反馈到合适的设计程序以便解决。

5.2.2概念设计的工作
对概念设计工作指南包括：

1．形成对硬件项目的高层级描述，包括：

a.硬件结构方面与安全性相关的限制，包括用于寻找设计差错、功能性设计缺陷、元

部件的过负荷运行或可靠性以及耐用性方面的设计缺陷。

b. 鉴别在软件或其他系统组件方面的任何实现限制。

2．鉴别主要部件，并确定其对硬件安全性需求的影响方式，包括未使用功能的影响。

3．衍生需求（包括接口定义）应反馈到需求捕获程序。
4．需求遗漏和差错应反馈到适合的程序用以解决。

5．应确定需要提供的硬件的可靠性、维修和试验特性。

注：在此推荐概念设计目标应在相关人员之间协调并一致同意，采用设计评审完成这

种协调是典型的方法。

5.3详细设计程序
详细设计程序利用硬件项目需求和概念设计信息得出详细设计数据，将其作为详细设计

的基础。

5.3.1详细设计的目标
详细设计程序目标包括：

1．详细设计由硬件项目需求和概念设计数据产生。

2．衍生需求应反馈到概念设计程序或其它适当的程序。

- 21 -
 中国民航大学 适航审定研究中心编译

3．将需求遗漏和差错反馈到合适的设计程序以便解决。

5.3.2 详细设计的工作
详细设计工作的指南包括：

1．根据需求和概念设计数据形成硬件项目详细设计的数据，这些数据可以包括硬件构

型和内部互联的数据、元件数据、HDL、试验方法和软硬件接口数据。

注： 在硬件设计程序中，适当的使用验证方法可以促进技术决策的制定。举例来说，

对设计参数的分析，比如：逻辑的时序和参数偏离， 能够为设计决策提供依据信

息。

2．必要时应采用结构设计技术，这包括为特定的功能建立安全监控、功能和安全监控

之间的非相似性、排除影响安全的设计差错和故障容限设计。

3．在需要时应该在硬件中设计试验特性以实现安全性需求的验证

注 ：安全特性能被验证的硬件设计对研发来说是很重要的，这种验证不仅包括在硬件

设计生命周期程序中，同时也是验收试验的一部分和返回维修试验的内容。

4．应对未使用功能的进行评估以确认对安全性的潜在影响，对不利的影响应予以关注。

5．在影响硬件安全的硬件项目设计、安装和运行方面的限制（若没有遵守）应进行确

认。

6．在详细设计程序中衍生需求应该反馈到概念设计或者其他合适的程序。

7．在详细设计程序中发现的需求遗漏和差错应该提供给适当的程序以便解决。

5.4 硬件设计实施程序
硬件设计实施程序利用硬件详细设计数据形成硬件项目，此硬件是试验工作的输入。

5.4.1设计实施程序的目标
硬件设计实施程序的目标包括：

1．生产的硬件采用典型的制造程序实现了硬件的详细设计。

2．硬件项目的实现、组装及安装数据是完整的。

3．衍生需求应反馈到详细设计或其它适合的程序。

4．需求的遗漏和差错提供给合适的程序以便解决。

5.4.2设计实施的工作
对硬件设计实施工作的指南包括：

1．硬件项目应该根据设计数据和实践中用于生产产品的资源进行生产，这可包括获得

程序、使用的工具、构造、监查和试验。

- 22 -
 中国民航大学 适航审定研究中心编译

2．硬件设计实施程序中产生的衍生需求应该反馈到详细设计程序或者其它适合的程序。

3．硬件设计实施程序中发现的需求遗漏和差错应该提供给合适的程序以便解决。

5.5生产过渡程序
在此程序中，硬件的制造信息、试验工具以及通用设备应该进行检验以保证生产的有效

性和适用性。生产过渡程序采用来自硬件设计实施和验证程序的输出将产品转入生产。

5.5.1生产过渡程序的目标
生产过渡程序的目标包括：

1．建立一个基线，包括支持硬件项目完整复制所需要的设计和制造数据。

2．确定涉及安全的制造需求并用文档证明，同时制定制造的控制程序。

3．衍生需求应反馈到实施程序或其它合适的程序。

4．将差错和遗漏提供给合适的程序以便解决。

5.5.2 生产过渡程序的工作
生产过渡程序的指南包括：

1．应从定型的设计数据中准备制造数据。

2．应该校核制造数据以保证完整性以及同定型设计的一致性。

注:本文献不对生产制造的文档体系的性质作任何规定。

3．在生产过渡程序中的任何更改或整体改进都要求进行评估以保证它们符合所有产品

的需求，尤其是安全性需求。任何与客户需求和审定需求不一致的更改应该由相关组织批准。
4．与安全性有关制造要求应该明确定义以便在生产程序可以控制。

5．应确定制定验收试验准则需要的数据。

6．发现的遗漏和差错应该提供给合适的程序以便解决。

5.6验收试验
验收试验是为了证明产品的制造、改进及修理后硬件的性能与所审定关键属性相一致，

这种关键属性可根据工程判断选择，并表明研发的硬件项目符合需求。

注1：“完成的”产品的构型控制不是验收试验活动要进行的一项工作。在7.2部分中的

构型管理计划讲述的是申请人如何计划去完成这个工作。

本文档关注的是验收试验标准的定义（包括成功/失败条件），但并没有考虑生产程序

（包括验收试验本身）。

注2:验收试验并不是在每个产品单元验证的所有需求。

- 23 -
 中国民航大学 适航审定研究中心编译

子项目的试验可以是验收试验的一部分。

验收试验标准应该确保：

1．确定的电气试验。

2．确定的环境屏蔽试验（必需时）。

3．验收试验要覆盖符合安全性需求所必需的设计特征。对试验没有覆盖的与安全相关

的项目或子项目应该明确指出，且要提供其它的保证方法，这些方法包括分析、设计控制、

统计程序控制或其它合适的方法。

5.7批生产
批生产程序不属于本文档的范围，但对影响硬件设计保证的因素做了简单的描述以形成

完整的生命周期。

批生产程序是按照符合产品数据和需求的程序再生产硬件项目。

考虑因素：

1. 管理设计或生产程序中的更改以确保这种更改不会对已有的安全性、合格审定或符

合需求的特征有不利的影响。

注 : 除了本文档主体建议的指导方法，11.1.1节还覆盖了对已研发硬件的改进，而对涉

及元件更新的内容参考11.2节。

2．对所有涉及更改的文档进行升级时要符合批准的构型管理计划。

6.0 确认及验证程序
本节描述了确认程序和验证程序。确认程序是保证硬件项目所衍生需求相关于分配到硬

件项目的系统需求是正确和完整的。验证程序是保证硬件项目的实现满足所有的硬件需求，

包括衍生需求。

6.1确认程序
这里讨论的确认程序目的是通过采用主观和客观结合的方式保证硬件项目的衍生需求

相关于分配到硬件项目的系统需求是正确和完整的。确认程序的进行可以在硬件项目可用之

前或之后，但典型的确认程序是贯穿整个硬件设计生命周期。

注1:经验表明，关注需求的产生和确认能够在研发周期中及早的辨别隐蔽的差错或遗漏，

并能减少随后重新设计或不充分的硬件特性的风险。

这里讨论的确认程序不是要确认系统需求分配来的需求，因为这些需求的确认是作为系

- 24 -
 中国民航大学 适航审定研究中心编译

统程序的一部分。另外，并非所有的硬件项目衍生需求都要确认。

设计决策中对系统安全或分派给系统其它部分功能需求有影响的部分应该归为衍生需

求，并要确认。此外，限制后续设计任务的设计方案和假设应该作为衍生需求进行确认。

需要确认的衍生需求应该对照分派给硬件项目的系统要求进行确认，对于不能追溯到上

层需求的衍生需求应该对照导出这些需求的设计决策进行确认。

注2：例如，在设计某个实现特定功能的电路时，若设计方案要求电路包含独立电源，

则这种方案可以产生指导这个电源设计的衍生需求。由于电路从此电源获得能量，

这些对电源的衍生需求就包括建立在失效状态（这些失效状态源自电路所实现功能

的故障或失效）基础上的安全性需求，对这些需求应该确认。

另一种由设计决策产生衍生需求的例子是外围器件存储地址分配，通常对地址分

配是没有要求的，但一旦分配了地址，将对后续的设计任务产生约束，为了保证

功能的正确，后续设计必须遵循分配的地址，这种衍生需求可以不确认。

6.1.1 确认程序的目标
衍生硬件需求的确认程序的目标是：

1．衍生的硬件需求相对于要验证的硬件项目的正确性和完整性。

2．评估衍生需求对安全性的影响。

3．遗漏和差错要反馈到合适的程序以便解决。

6.1.2 确认程序的工作
硬件确认的目标可通过多种工作的组合来满足，如设计评审、模拟、样机研究、模型制

造、理论分析、使用经验、工程评估、或试验研发与实施等。

对确认程序工作的指南包括：

1．确定需要确认的衍生硬件需求。

2．对在第1项中确定的每个需求，制订确认程序结束的判据，并要满足以下要求：

a.每个需求都已在在某些层级通过评审、分析或试验的方式完成确认。

b.每个需求的评审、分析或试验是适合确认这个需求的，特别是关于安全性的需求。

c. 与每个需求相关的评审、分析或试验结果是正确的，并且实际结果和预期结果

之间的偏差是合理的。当预期结果不是预先确定而是根据评审和分析决定时，确认工

作的结果应该和对应的需求一致，特别是关于安全性的要求。

注：确认程序结束的判据必须以对应需求、安全因素、运行模式或需求实现为基础。

3．必须评估衍生需求对安全性的影响。

- 25 -
 中国民航大学 适航审定研究中心编译

4．必须评估衍生的硬件需求相对于分配到硬件项目的系统需求的完整性。当所有已经

定义的特性是必要的，且所有必要的特性已经确定，则认为这样一组需求是完整的。

5．必须评估衍生的硬件需求相对于分配到硬件项目的系统需求的正确性。某个需求的

定义是清晰的且在定义的特性中没有错误，则认为这一需求是正确的。

6．应该建立衍生硬件需求和确认工作及结果之间的可追溯性。

7．应将需求的遗漏和差错反馈到合适的程序以便解决。

6.2 验证程序
验证程序是为硬件实现符合需求提供保证，由定义在验证计划中的评审、分析和试验组

成。验证程序应该包括对验证结果的评估。

注：硬件设计的安全性方面以硬件实现要符合的安全性需求表示。

这部分对应该应用于硬件设计的验证程序提供指南。验证程序可应用在硬件验证计划中

定义的设计结构的任何层次。对于安全需求，在设计程序的不同阶段实施验证程序，有利于

增加消除设计差错的概率，提高置信度。某些设计保证等级要求验证程序的目标要独立的符

合，如附录A中所强调的。

这里没有给出软件验证，软/硬件的综合验证以及系统综合验证程序，但在这些程序中

的硬件需求验证是一个硬件验证的有效方法。

对已验证构型的更改可通过相似性、分析、新设计试验或重复部分原始验证等方法重新

验证。

注：建议在归档的验证程序之外增加非正式试验，其程序和结果虽然不需保持在构型

管理控制之下，但对在设计程序中及早的发现和消除设计差错是非常有效的。只

有这些试验正式化后才可作为可信任的验证。

6.2.1验证程序目标
验证程序目标包括：

1．为硬件设计实现符合需求提供根据。

2．建立硬件需求、设计实现、验证程序及结果之间的可追溯性。

3．确定验收试验判据，这些判据能被实施并且同硬件功能的设计保证等级保持一致。

4．遗漏和差错要反馈到适合的程序以便解决。

6.2.2 验证程序的工作
验证程序的目标可通过一些方法的组合满足，如评审、分析以及试验的开发与实施。应

该对验证工作建立验证计划文件以证明符合需求。

- 26 -
 中国民航大学 适航审定研究中心编译

验证工作包括：

1．确定需要验证工作的需求。需求不一定在每个构架层级上都验证，可以在一个更高

的构架层级验证。

2．应选择并实施验证方法，比如试验、模拟、原型机、分析和评审等。

3．建立需求、设计实现、验证程序及结果之间的追溯性，追溯性应和硬件执行功能的

设计保证等级保持一致。除非是出于安全性考虑的要求，追溯性并不要求详细到元件，

如电阻、电容及门电路等。

4．应进行验证覆盖率分析以确定验证程序是否全面，包括：

a.每个需求在某一构架层级上通过评审、分析或试验的方法已验证。

b.为验证需求而对每个需求的评审、分析或试验是适合的，特别是有关安全性的需

求。

c.与每个需求验证相关的评审、分析或试验的结果是正确的，并对实际结果与期望

结果之间的偏差作出解释。当期望结果没有预先定义（可以在检查和分析方法中存在），

验证工作的结果应该跟需求保持一致，特别是有关安全性的需求。

5．验证工作的结果应该归档。

6．遗漏和差错应该反馈回适合的程序以便解决。

6.3 确认及验证的方法
本部分描述了一些适用于确认及验证的方法。

6.3.1 试验方法
试验是用于确认硬件项目对一个或一系列激励正确响应的方法，包括硬件的功能试验、

系统台架试验和机上试验。

试验可以利用手动、自动或专用试验设备进行，也可在验证程序中利用硬件内部的试验

能力进行，如自检（BIT）。

若在预期的运行环境中通过运行硬件验证特定需求不可行时，需要采用其它的验证方

法，并证明这种方法的正确性。

试验可在硬件设计的各个程序中进行。为合格审定进行的试验需要一个已定构型的项

目，系统集成或软硬件集成试验结果也可用于试验置信度。

试验指南包括：

1．确定每一个要通过试验确认或验证的需求，环境鉴定试验需求也是这些需求的一部

分。

2．定义每个试验的试验激励、顺序和试验条件，如环境温度和施加电压等。

- 27 -
 中国民航大学 适航审定研究中心编译

3．在试验进行之前应确定成功/失败的准则和记录结果的方法。

4．对每个试验应记录试验设备完整性的鉴定和校准数据。

5．应该记录要进行试验的硬件项目的构型标识。

6．应该记录并保留试验结果。

7．试验失败应反馈到合适的程序以解决。

6.3.2分析方法
分析是一种详细的、重复的、分解的方法，用于评估特定硬件性能以证明某一特定的需

求是否满足。分析法的例子包括负荷分析、设计裕度分析、共模失效分析、最坏情况分析和

试验覆盖率分析。使用经验可为各种分析提供数据。

注：随着硬件设计复杂度的增加，利用计算机化的工具是有利的，如用于验证需求和设

计实施的模拟。

分析包括对硬件项目的功能、性能、可追溯性和安全性结论以及与机载系统或设备内部

其它功能之间关系的详细检查。用单独分析或与其它验证方法结合来提供证据表明某一需求

的正确实现。分析应该以设计程序、使用经验或者其它可利用的资料库提供的数据作为基础。

对于电路运行的可见度和更高层级功能运行，模拟是一种很重要的设计分析工具。模拟

可用于分析产品参数变化的影响，这种情况下很难再运用其它的验证方法，这样可建立置信

水平，减少由于参数变化而影响安全性的设计差错。因为模拟的结果取决于所建的模型和采

用的方案，单独的模拟结果在没有支持其正确性的证据时不能用作审定信任的目的

分析方法的例子包括：

1．热分析，热分析用于验证当产品暴露在工作的热环境中时设计实现符合需求。

2．负荷分析。负荷分析用于验证部件超出其工作范围时符合降级的标准。

3．可靠性分析。可靠性分析用于确定设计实现是否满足产品的可靠性要求。

4．设计裕度分析。设计裕度分析用于验证设计实现在考虑元件更换性时满足其功能需

求。

5．相似性分析。相似性分析是在特性和用法方面同以前已审定系统的比较。

6．模拟分析。模拟分析是对模拟结果与预期结果的比较。

6.3.3评审
评审是一种定性的分析方法，是对计划、需求、设计资料、设计概念或设计实现的评估。

评审应该贯穿于在相关计划中确定的硬件设计生命周期，所有要用于审定置信度的评审

应在确认和验证计划中确定。

评审指南包括：

- 28 -
 中国民航大学 适航审定研究中心编译

1．评审者应该具备执行评审所必要的知识。

2．硬件评审结果可用于允许或者拒绝硬件设计生命周期中程序工作之间的转换。

3．评审的结果应该归档，包括作出的决定和要采取的行动安排。

6.3.3.1需求评审

需求评审是一种保证需求可接受性的方法，在一个评审中，需求评审可能给出来自确认

和验证两个程序的目标。

初始需求评审后发生的需求更改需经与初始评审程序相同的评审程序或与之等效的评

审程序。确认分派给硬件的系统需求并不是这一评审的目标。

对需求评审指南包括：

1．每个需求应该是明确的、能证实的，并相应于其构架层级有完整充分的描述，而且

不与其它需求相冲突。

2．衍生需求应该跟系统需求或需求衍生源保持一致性。

3．需求应该跟SSA保持一致。

4．衍生安全性需求应该定义并且反馈到SSA。

5．需求应该跟相应的硬件设计标准保持一致性。

6．需求应该同现有工艺的能力和限制相适应。

7．元件的需求，比如性能、温度范围、降级和屏蔽，应该和安全性及可靠性需求保持

一致性。

8．应该关注硬件项目进行试验、维修和制造的能力。

9．应该定义软/硬件接口需求。

10．需求应该按照计划中定义的判据可追踪到上一个构架层级。

11．衍生需求应该捕获设计实施中不能在高层级实施验证的限制条件。

12．遗漏和差错应该反馈到合适的程序以便解决。

注1：下面的问题可能对评估需求的完整性有所帮助：

a.考虑了所有上层的需求吗？

b.考虑了适用的标准和指导材料吗？

c.覆盖了所有硬件功能和接口吗？

d.完整地覆盖了系统结构吗？

e.充分地规定了所有要求验证的硬件实现吗？

f.覆盖了所有安全评估中禁止的行为特征吗？

g.充分地规定了运行环境吗？

h.考虑了假设和约束吗？

- 29 -
 中国民航大学 适航审定研究中心编译

i.这个实现会避免现有和相似硬件的任何已知问题吗？

注2：下面的问题可能对评估需求的正确性有所帮助：

a.这些需求与上层需求一致一致吗？

b.这些需求与分派硬件的系统需求一致吗？

c.这些需求是关于“是什么”而不是“如何做”吗？

d.这些需求是清晰的吗？

e.这些需求能被实现吗？

f. 这些需求能被验证吗？

g.功能模式已经定义了吗？

h.这些需求是与安全评估保持一致吗？

i.对衍生需求，正确地确定了假设和约束吗？

6.3.3.2设计评审

设计评审是一种用于确定设计资料和设计实现满足需求的方法。设计评审应该在硬件设

计生命周期按照确认和验证计划中的规定多次执行，如概念设计、详细设计和设计实现评审。

对跨越多个硬件等级的层次设计，如ASICs和电路板组件，设计评审应该考虑保证一个正确

设计的最大可能。

对设计评审的指南包括：

1．所有的需求应该被描述，而且衍生需求和设计资料应该被正确的定义。

2．环境需求应该被描述。

3．安全和可靠性需求被描述。

4．设计资料的安全性特征应该被明确地确定。

5．设计应该能够被实现、试验和维护。

6．新的生产工艺应该被评估。

7．定义在计划中的元件选择标准应该被满足。

8．设计应该可追溯到需求。

9．遗漏和差错应该反馈到合适的程序以便解决。

- 30 -
 中国民航大学 适航审定研究中心编译

7.0 构型管理程序
构型管理程序用于保证构型管理目标可以被稳固一致地复制，在必要的时候进行信息资

料的重建或在可控的情形下对构型管理目标进行修改。本节将描述硬件构型管理的目标和所

要进行的工作。

7.1构型管理的目标
构型管理程序的目标如下：

1. 构型项目具有唯一性并被归档。

2.可保证产品项目能够精确一致的被复制。

3.能够提供一个可控的方法实施对产品项目的确立以及对更改的跟踪。

7.2 构型管理的工作要求
构型管理工作要求包括：

1．构型项目必须是唯一确认、备有证明文件且可控的。这其中可包括（但是不局限于）：

硬件、硬件的设计描述、用于审定和做基线的工具或其他数据。

2．基线应该是正式确立的。

3．问题应该唯一地被确认、追踪和报告。

4．更改控制和更改的可追溯性应该保持，要求计划中所列的生命周期数据是安全可靠

且可恢复的。

5．构型项目的归档、恢复和发布应该可控。

多种方法可以被选取，以用于满足构型管理的目标和工作要求。下面的章节描述了对可

以接受的方法的指南。

7.2.1构型的标识
构型标识的目标是标明识别每个明确的构型项目，以建立一个用于控制和参照的构型项

目基础。

指南包括：

1．应当为数据项目建立构型标识。

2．对于每一个构型项目、每一个构型项目中单独控制的元部件、以及组成产品并与设

计计划（经局方批准的）一致的各构型项目的结合体，都应该建立构型标识。

注释：比如ASICs、已配置的PLDs、印刷电路板和黑匣子，这些已标识组件的细节是通

过构型管理计划来确定的。

- 31 -
 中国民航大学 适航审定研究中心编译

3．对于COTS组件和早期研制的硬件项目，在基线中使用它们之前应该正式被确立构

型标识。

4．对于每一个构型项目，在新基线中使用它之前，或被其他数据项目参照引用之前，

或在产品制造生产之前，应当正式确立其标识。

7.2.2 建立基线
建立基线的目标是为进一步的工作定义一个基础，以便保证构型项目间的追溯性、可参

照性和可控性。

指南包括：

1．用于审定置信度的构型项目，应当正式确立其基线。

注释：可以建立中期段的基线用于硬件的控制。
2．一旦基线被确立，它将受更改控制程序的控制。

3．当从一个已确立的基线发展一个衍生的基线时也应遵循更改控制指南。

4．如果要生成一个新的基线，采取与先前基线设计相关的资料或活动将会提高审定程

序中的置信度，但这一新基线应当与先前基线的相关性是可追溯的。

注释：基线可以是一个构型项目，一个已经审定过的硬件项目或者一个COTS元部件。

7.2.3问题报告、跟踪以及纠正行为
问题报告、跟踪以及纠正行为的目标是记录问题和保证正确的部署和解决。问题可能包

括计划和标准的不相符、生命周期程序输出的欠缺、产品的异常工作状态、工具和技术程序

的不完备及欠缺。问题报告应该在所审定的基线正式确立前开始执行。

指南包括：

1．问题报告应当涵盖每一个需要报告的问题。

2．问题报告应该确定受影响的构型项目的构型。

3．需要纠正行动的问题报告应当使更改控制程序随之启动。

4．所有关闭的问题报告应该包括一个关于关闭问题报告所采取措施的描述，该描述也

应包括完成纠正行动所需进行的数据项目改变。

5．对于适航审定来说，并非所有的问题报告必须关闭，但是所有的问题报告应该通过

评估，对于那些对安全和审定有影响的问题报告则应该关闭。

6．问题报告系统应该追踪问题报告的状态，包括它们的批准和最终决议。

- 32 -
 中国民航大学 适航审定研究中心编译

7.2.4 更改控制
更改控制的目标是保证更改的记录、评估、解决和批准。更改控制应该遵循构型管理计

划来实行，而且应该在所审定的基线正式确立前开始执行。

指南包括：

1．更改控制应该通过提供能抵御未授权更改的保护，来保持构型项目的完整性。

2．更改控制应该能对更改进行评估，以确定是否需要对其构型标识进行更新。

3．对构型项目的更改应该被记录、批准和跟踪。在构型管理计划中批准机构应予以明

确。

注释1：问题报告与更改控制相关联，因为对于问题报告的解决方案可能导致对构

型项目的更改。

注释2：早期实施更改控制能够对控制和管理程序起到帮助，这是被普遍认可的观

点。

4．更改控制应该保证更改原因的可追溯性。

5．更改控制应保证更改产生的影响被评估，以确定程序输出更改的结果和影响，和输

出数据被同步更新。

注释1：本程序的部分或全部的工作可能需要从对输出有影响的点开始重复。

注释2：应当注意，制造工具、工艺程序或者外部组件的更改可能会影响设计。

6．更改控制应该保证反馈数据可提供给被影响的程序。

7.2.5发布、归档及恢复
发布的目标是将数据项目置于构型管理控制下，以保证在其它的地方只使用批准过的数

据。

归档和恢复的目标是保证与产品相关的数据项目在需要复制、重新生成、重试验以及产

品更改时能够被恢复。

指南包括：

1．构型项目应该在被用于生产前确立和发布，并且发布的授权机构应该是确定的。

2．与产品相关的数据项目的恢复，应当有一个经批准的来源。例如，研制的组织或公

司。

注释：更改控制的数据和问题报告的数据是数据项目的一部分。

3．数据保持程序应当可提供，以满足适航要求和更改需要。

4．应制定程序来保证存储数据的完整性，且保证期达到局方要求的长度。这包括：

a.保证所有更改都是被授权的

- 33 -
 中国民航大学 适航审定研究中心编译

b.选择存储媒介。

c.保持存储数据的可用性。例如，在一定的时间段内，通过使用或更新归档数据，使保

存时间与存储媒介的数据存贮寿命相匹配。

d.保证一个单独的事件不会引起不可挽回的存档数据的丢失，比如通过保存副本，并且

满足档案的物理独立性。

7.3 数据控制类型
相关于构型管理数据项目的类型有两种：硬件控制类型1（HC1）和硬件控制类型2

（HC2）。类型划分允许在特定的一些数据项目构型控制中减少一些要求。HC1要求所有的

构型管理工作要求都被执行，HC2则不全部要求。对被定为HC2类的数据项目，将不被要求

逐步的更改，而是可以直接用新的数据来替代。

表格7-1定义了构型管理在HC1和HC2两种类别下的执行项。例如，表格7-1给出了在附

录A中确立的一些项目，表格A-1中HC2类数据项目须可恢复，但不需要发布。此外，表格

7-1展示了任何一个HC1类数据项目都将有一个基线。

附录A将每一个数据项目的类型作为硬件设计保证等级的一个功能予以明确。比如在表

格A-1中，HC1适用于所有保证等级的硬件需求，而HC2适用于所有保证等级的硬件评审和

分析结果。
表格7-1相关于HC1及HC2的构型管理工作项目
涉及章节 构型管理工作项目 HC1 HC2

7.2.1 构型标识 X X

7.2.2 (1),(2),(3) 基线 X

7.2.2 (4) ① 基线的可追溯性 X X

7.2.3 问题报告 X

7.2.4 (1),(2) 更改控制--完整性和识别 X X

7.2.4 (3),(4),(5), 更改控制--记录、批准和可追溯性 X

7.2.5 (1) 发布 X

7.2.5 (2) 恢复 X X

7.2.5 (3) 数据保持 X X

7.2.5 (4a) 针对未授权更改的保护 X X

7.2.5 (4b),(4c),(4 媒介选择、更新和复制 X

①当对 HC2 数据的标识在新基线采用时并不意味 HC1 的数据需重新分类

- 34 -
 中国民航大学 适航审定研究中心编译

8.0 程序保证
程序保证是确保生命周期程序目标能被实现，在计划中要求的工作已经完成，或偏离已

经处理。本部分描述了用于程序保证的目标以及支持这一目标的工作。这里并不是要求建立

特定的组织结构。

为了客观的评估生命周期程序、确定偏离和保证纠正措施，程序保证工作应该独立的完

成。

8.1程序保证目标
程序保证的目标是保证：

1．生命周期程序遵循批准的计划。

2．遵照批准的计划形成硬件设计生命周期数据。

3．建立用于符合性评估的硬件项目以符合相关的生命周期数据。

8.2程序保证工作
对程序保证工作的指南包括：

1．应该保证在本文献的计划编制程序中规定的且与PHAC中一致的硬件计划的可用性。

2．应该保证评审符合批准的计划并追踪行动的结果直至其关闭。

3．应该保证硬件计划和标准中规定的对偏离的探测、记录、评估、批准、追踪和解决。

4．应该保证硬件生命周期程序的过渡标准符合批准的计划。

注：对于执行以上1-4步的工作，审核（audit）是一种有效的方法。

5．应该进行检验以保证硬件项目的建立符合其设计数据。

注：首件检验（FAI）就是这个工作的例子。

6．应该形成程序保证工作的纪录，包括设计工作完成的评估证据。

7．若适用，申请人应该保证子承包商采用的程序与硬件计划一致。

9.0 审定联络程序
审定联络程序的目标是在整个硬件设计生命周期中建立申请人和审定当局之间的交流

和谅解，用来促进审定程序的完成。审定联络程序应该按照硬件计划编制程序（见第4节）

以及PHAC（第10.1.1节）中描述的执行，附录A中的表格A-1给出了这个程序输出的概要。 此

外，联络工作可包括设计方法介绍（为及时批准）、关于审定基础符合性方法的协商、设计

- 35 -
 中国民航大学 适航审定研究中心编译

方法的批准、资料批准的方法、以及任何需要的局方审查和试验目击。

在项目完成后，接下来需要做的是设计程序概要、生产的输出和硬件的状态应该在硬件

工艺概要（第10.9节）中描述。

9.1符合性方法和计划编制
申请人在PHAC定义计划的硬件符合性方法。对此的指南包括：

1．在某个节点，即当设计更改对项目的影响最小时，应该及时地提交PHAC、硬件验

证计划及其它需要的资料给局方，以便审查。

2．由审定当局确定的关于硬件方面的合格审定计划（PHAC）的问题应该得到解决。

3．PHAC应该得到审定当局的认同。

4．局方在设计和审定周期的联络应该像计划中的提纲是连续的，并且由局方提出的问

题应该得到及时的解决。

在某些程序里，审定的联络不是由设备生产商提供得的，而是由飞机或者其它支持角色

的设备生产商提供的。这种关系应该在PHAC里定义，并且在审定中和局方的联系应该通过

取证申请人。取证申请人有责任保证数据能够提供给局方。

当某些内含在装备里的硬件项目由转包商获得时，审定计划应该标识哪一部分数据将是

从转包商处得来和哪一部分数据由申请人完成。

申请人在顶层的审定计划中将PHAC和其他相关审定计划中包含其中是可以接受的。

9.2 符合性依据
申请人为硬件设计生命周期满足硬件计划提供证据。局方可以在申请人或申请人供应商

的生产试验场所进行检查。应由申请人来安排这些检查活动并且保证硬件设计生命周期的数

据是可供检查的。

申请人应该当：

1．解决由局方检查所提出的问题。

2．向局方递交硬件工艺概要、10.9部与10.3.2.2.1部分描述的数据和顶层图纸。

3．递交局方要求的其他符合性证明或数据，或使其可被检查。

- 36 -
 中国民航大学 适航审定研究中心编译

10.0 硬件设计生命周期的数据

这部分描述了在硬件设计生命周期中生成并用于证明设计保证和符合审定要求的硬件

设计生命周期数据项目。局方所要求设计保证证据的范围、数量和细节可能因为诸多因素

而发生改变，这些因素包括局方对机载系统的适用要求、所分配的设计保证等级、硬件的

复杂度和产品使用经验。设计保证证据的细节应当被确定和记录在 PHAC 中，并获得局方的

认可。

第 11 部分所描述的附加考虑因素和附录 B 中描述的 A 和 B 级功能的设计保证考虑因素

可能导致产生附加的生命周期数据。

附录 A 给出了在第 7 部分定义的需开发的硬件设计生命周期数据、验证的独立性以及

适用的数据控制类别，并以设计保证等级的方式加以划分。

1．硬件设计生命周期数据特性应包括：

a.明确性。对所记录的信息/数据，只会有一种理解方式。

b.完整性。信息/数据包括必要和相关的需求与描述性材料、已标识图示、定义的术

语和测量单位。

c.可验证性。信息/数据能够通过人工或者工具检查其正确性。

d.一致性。信息/数据不互相矛盾。

e.可更改性。信息/数据是结构化的，并且在保持结构的前提下，信息/数据可以被

完整、统一和正确地进行更改。

f.可追溯性。信息/数据的来源能被确定。

本部分描述并不意味着推荐了某种特殊的数据打包方法，以及数据包内的硬件生命周期

数据的形式或组构。例如，所有的计划、标准和程序可以会在一个单独的或者多个文档中描

述。

2．数据打包的方法、形式和组构应该在PHAC中被提出，并在项目的早期获得局方的

认可。

3．获得认可的上述信息和数据应该在机载系统或硬件的整个使用寿命中都是可恢复的

和可用的。

- 37 -
 中国民航大学 适航审定研究中心编译

10.1 硬件计划
硬件计划描述了在硬件审定、设计、确认、验证、程序保证和构型控制中所采用的过程、

程序、方法和标准。

10.1.1硬件审定计划
为实现本指南的目标并且获得局方对包含硬件项目的系统审定的批准，PHAC定义了其

中所采用的过程、程序、方法和标准。PHAC一旦被批准，则表明申请人和局方应该在程序

和行为要求之间达成一致，并且得出一个用于满足硬件审定要求证据的依据。PHAC可以是

另一个计划的一部分，比如机载系统审定计划。

PHAC应该包括：

1．系统概述。这部分为机载系统提供一个概述，在这个概述中硬件项目将被使用，包

括系统功能描述、系统失效状态、系统结构、给硬件和软件的功能分配的描述和现有系统文

件的基准。

2．硬件概述。这部分描述硬件功能、硬件项目、结构、新技术的使用以及任何“故障-

安全”装置、故障容限、冗余和隔离技术的使用。

3．审定考虑因素。这部分描述了审定基础、预期的符合性方法、对硬件每一功能的设

计保证等级。安全评估基于硬件以及硬件在机载系统使用情况做出了对硬件设计保证等级的

分配，在这里则为分配提供了理由，这包括对在2.3.4部分讨论的潜在硬件失效状态的描述。

适用时，关于FFPA的概要或者FFPA的执行计划和应用结果也应包括在内。

4．硬件设计生命周期。本部分描述了为实现硬件设计保证等级目标所采用的程序、方

法、涉及的标准、程序和工作。它描述所要进行的工作、各项工作的结合与先后程序、各个

程序和工作之间的关联、转换标准、职责、工具的使用以及系统/软件与硬件间的反馈和交

互作用的方法。本部分可以引用适用的计划、政策、标准、程序及项目对于这些计划和标准

的偏离。

5．硬件设计生命周期的数据。这部分描述和引用作为对本指南和计划符合性证据的一

些需要开发、递交或可提供的数据。

6．附加的考虑因素。本部分描述了附加的考虑因素，包括早期研制硬件的使用，包含

引用的重新采用的适用数据、COTS的使用、产品使用经验、工具的评估和鉴定（如第11部

分中描述），或者在附录B中描述的A和B级功能的设计保证考虑因素。

7．替代方法。这部分描述了没有在此指南中描述或不同于本指南描述但可利用的方法，

采用替代方法的理由应该被提供。

8．审定的进度表。本部分确定主要项目的时间节点和向局方递交硬件设计生命周期各

- 38 -
 中国民航大学 适航审定研究中心编译

数据的日期。

10.1.2 硬件设计计划

硬件设计计划描述了将采用的程序、方法和选定的标准，以及硬件项目设计所将实施的

程序和行动。这个计划可以包含在PHAC中也可以引用设计的策略和标准。

硬件设计计划应当包括：

1．硬件设计生命周期。对采纳的设计策略和标准的引用说明，对为实现硬件设计保证

等级的设计目标而使用的硬件设计生命周期程序和行动的描述。

2．硬件项目描述。确定所要实现的硬件项目规范、替代性使用、计划的使用寿命和升

级考虑事项。

3．硬件设计方法。描述硬件的需求捕获和技术说明方法、概念设计方法、细节设计方

法、综合技术、硬件实现方法和生产过渡转换方法。如果对A级或B级功能采用在附录B3.1

部分中描述的结构缓和方法，但在计划写完时还没有完全确定，需说明如何将决定应用到涉

及程序中去。

4．硬件设计环境。描述使用的设计工具。

5．硬件项目数据。标识硬件项目将产生的设计数据或参照早期研制硬件的技术说明、

文件、图号和件号。

6．其它考虑事项。描述计划程序的技术选择、使用和组装的选择、产品包装和硬件安

装的选择。

10.1.3 硬件确认计划
确认计划描述了将采用的程序、方法和标准，以及为实现本指南确认目标和“确认硬件

项目衍生需求而将实施的程序和行动。这个计划可以包含在PHAC中，也可以引用所采用的

确认标准。

确认计划应该包括：

1．确认方法。对使用的确认程序、标准和方法的描述和引用。方法可以包括分析、评

审和试验。

2．确认数据。对硬件确认程序所获得证据的标识和描述。

3．确认环境。对完成确认程序使用的分析和试验设备，以及确认工具的标识和描述。

- 39 -
 中国民航大学 适航审定研究中心编译

10.1.4 硬件验证计划
验证计划描述了将采用的程序、方法和标准，以及为实现本指南的验证目标和验证硬件

项目而将实施的程序和行动。这个计划可以包含在PHAC中也可以引用所采用的验证策略和

标准。

验证计划应当包括：

1．验证方法。对作为硬件项目完整性的客观证据所将采用得的验证策略、程序、标准

和方法的描述和引用，包括COTS元件和未使用功能。方法可以包括分析、评审和试验。如

果采用了在附录B的3.3部分描述得高级分析法，则需包含对适用的FFPs和适用的验证完整性

标准做详细的方法描述。

2．验证数据。对作为硬件验证结果的证据的标识和描述。

3．验证独立性。对于要求独立性的目标，为保证验证独立性所使用方法的描述。

4．验证环境。对用来实施验证程序和行动的分析与预测设备和验证工具进行标识和描

述。

5．组织职责。标明对验证程序实施负责的组织。

10.1.5硬件构型管理计划
硬件构型管理计划描述了用于满足本指南的构型管理目标而采用的策略、程序、标准和

方法。

硬件构型管理计划应当包括：

1．硬件构型管理方法。描述和引用用于标识、管理和控制硬件及其生命周期数据的策

略、程序、标准和方法。

2．硬件基线。描述用于建立设计和生产基线和提供基线追溯性的方法和程序。

3．问题报告和解决方案。描述用于记录、跟踪和解决问题报告的方法和程序。

4．更改控制。描述控制数据项中使用的标识、控制和跟踪更改的方法、程序和程序。

5．存储和恢复。描述硬件生命周期数据的颁布、存档和恢复程序，描述包括存档内容、

格式以及媒介的规格、准则、方法和标准。

6．环境控制。描述用于标识和控制在研制和检验硬件中使用的工具的程序和方法。

7．构型管理工具。描述用于构型管理程序和行动的工具和资源。

10.1.6 硬件程序保证计划
硬件程序保证计划描述将采用的程序、方法和标准，以及为实现本指南保证目标而将实

施的程序和行动。

硬件程序保证计划应当包括：

- 40 -
 中国民航大学 适航审定研究中心编译

1．程序控制。描述实施硬件设计程序保证的策略和程序。

2．组织责任。明确实施程序保证中的组织责任。

3．一致性。描述确定程序和生产一致性的策略、程序和标准。

4．程序保证行动。描述为证明程序对计划和标准的符合性而使用的程序保证评审和审

核。

5．偏离：描述用来探测、记录、评估、解决和批准与计划和标准偏离的方法。

10.2硬件设计标准和指南
硬件设计标准和指南可以定义硬件设计、确认、验证、保证和控制程序中的规则、程序、

方法以及目标标准，也可以用于评估硬件设计结果的可接受性和质量。标准可以不是必需的，

但是如果申请人采纳了它们，它们将成为审定基础和计划的一部分。依据这些计划，这些的

标准和指南可以打包成一个单独的文件或者多个的文件。可以采用工具执行标准。

10.2.1需求标准
在需求获得程序中可以使用需求标准去定义需求开发的规则、程序、方法、指南和目标

标准。

需求标准可以包括开发和技术说明需求的方法和目标标准、确认需求的方法和目标标

准、表述需求的符号、需求技术说明工具的使用指南和用于提供系统设计程序中衍生需求的

方法。

10.2.2硬件设计标准
在概念设计和详细设计程序中可以使用硬件设计标准去定义研制和说明硬件设计的规

则、程序、方法、指南和目标标准。

硬件设计标准可以包括：

1．硬件设计的表示方法和符号。

2．设计技术说明和命名习惯。

3．设计方法指南。

4．硬件设计工具使用指南。

5．电子器件选用指南。

6．设计替代性评估指南。

7．“故障-安全”和故障容限力设计结构评估的指南。

8．描述给需求程序提供反馈和阐明需求的方法。

- 41 -
 中国民航大学 适航审定研究中心编译

10.2.3 确认和验证的标准
在确认和验证程序中可以使用硬件确认和验证标准去定义确认和验证硬件设计和实现

的规则、程序、方法、指南和目标标准。

10.2.4硬件存档标准
硬件存档标准定义用于保留与存档产品数据、研制与维护项目与工程档案的程序、方法

和目标标准。硬件存档标准可以包括存档的内容、格式和媒介标准、规则、方法和目标标准。

10.3硬件设计数据
硬件设计数据就是定义硬件项目的技术说明书、证明档案材料和图纸。

10.3.1硬件需求
需求具体说明了在研硬件项目的功能、性能、安全性、质量、可维护性以及可靠性需求。

这些需求应包括：

1．分派给硬件的系统设计和安全性需求。

2．标识硬件适用的标准。

3．硬件功能性和性能需求，包括衍生需求和正常使用负荷限制。

4．硬件可靠性和质量需求，包括故障率、风险暴露时间和设计限制。

5．贯穿硬件使用寿命的硬件维护和修理需求

6．硬件的生产和装配需求

7．硬件试验性需求。

8．硬件存储和操作需求。

9．安装需求。

10.3.2 硬件设计描述数据
硬件设计描述数据对硬件项目进行定义，它包括图纸、文档和用于建立硬件项目的技

术说明书。下面的段落详细地给出了一些典型的硬件设计数据和它们的内容。对于一个给

定的硬件设计的数据类型、图纸和文档随硬件尺寸、复杂度及组件的数目而改变。

10.3.2.1 概念设计数据

概念设计数据用于描述硬件项目体系结构和功能设计，它可以包括：

1．一个高级别的描述，比如结构框图或者 HDL 定义，他们用于描述主体功能和表示

各功能之间的信息流。

2．描述硬件项目装置的机械机构，比如外部包装的图纸或者草图、印刷电路图、连接

- 42 -
 中国民航大学 适航审定研究中心编译

器的选择和位置，以及主要连接配线。

3．其他适航性相关的重要结构特征和隔离。这些可以包括 EMI、闪电和振动或冲击

防护，主要部件未使用的功能，以及人机接口中中的人为因素、照明特性和显示器分辨率

等。

4．顶层硬件项目功能描述。

5．硬件项目功能体系结构。

6．初步的硬件安全评估数据。

10.3.2.2 详细设计数据

详细设计数据描述按照需求实现硬件项目的必要数据。取决于硬件项目的等级，它可以

包括顶层图纸、装配图纸、内部交联数据、元部件数据、HDL硬件描述、可靠性数据、试验

方法数据、所选用的有未使用功能部件的清单和保证不危害硬件安全性的措施、安装控制数

据、以及硬软件结口数据。对这些数据的说明在下面描述。

注释：除了上述数据外可能还有其他适用的审定要求，比如技术标准规定（TSO），其

他详细设计数据的内容和可用性，由申请人在PHAC中向局方提议。

10.3.2.2.1 顶层图纸

每个硬件都对应唯一的顶层图纸，标识硬件项和标识所有组件、子组件、元部件和定义

硬件项的相关文件。

10.3.2.2.2 装配图纸

装配图纸包括用于装配硬件、组件或子组件的必要的附加详细信息。

装配图纸可以包括：

1．组装程序中的硬件定位。

2．标识用于保证正确和无差错组装程序的指示顺序或方法。

3．后续操作需使用的标记、标签、版本的标识位置。

10.3.2.2.3 安装控制图纸

安装控制图纸用于保证正确地将硬件项安装在系统或者将硬件安装在其他硬件上。对于

一些低级别的硬件，更高级别硬件项目的装配图纸可以当作它的安装控制图纸使用。

安装控制图纸可以包括：

1．尺寸。

2．清洁需求。

- 43 -
 中国民航大学 适航审定研究中心编译

3．冷却和固定信息。

4．用于保证能安全、正确安装的重量、重心和其他必要参数信息。

10.3.2.2.4 硬件软件接口数据

由需求技术说明确定的硬件性能可能依赖于由软件确定的硬件构型、由软件确定的硬件

校准、或取决于软硬件之间必要的接口。

硬软件接口数据可以包括：

1．内存地址。

2．能够载入数据的内存地址域分配。

3．时序信息。

4．其他必要的软硬件接口数据。

10.4确认和验证的数据
确认和验证数据是硬件设计结果和硬件本身完整性和正确性的证据。它保证硬件的研制

符合了它的需求和设计、被正确的生产，并且实现了设计目标。数据包括硬件评审、分析和

试验的程序与结果。除本部分描述的数据项外，对于在附件B中描述A级B级功能附加数据项

可能也会需要。

10.4.1追朔性数据
硬件的可追溯性在需求、详细设计、实现和验证数据间建立了关联性，以促进硬件的构

型管理、更改和验证。

硬件的追溯型数据应包括：

1．分配给硬件的系统需求和硬件需求间的相互关系。

2．硬件需求和硬件详细设计数据间的相互关系。

3．硬件详细设计数据和在制造的硬件或组件的相互关系。

4．需求（包含衍生硬件需求）与详细设计数据和验证程序及结果间的相互关系。

5．可追溯性分析结果。

10.4.2评审和分析程序
硬件评审和分析程序定义指导评审和分析的程序和目标标准。

硬件的评审和分析程序应该包括：

1．评审或分析的目的。

- 44 -
 中国民航大学 适航审定研究中心编译

2．参与检查的组织。

3．评审或分析目标标准。

4．指导检查或分析的详细说明。

5．评审或者分析的可接受性和完成标准。

10.4.3评审和分析结果
评审和分析结果是验证评审和分析是否已批准程序和标准完成的证据。

硬件的评审和分析结果应该包括：

1．评审或分析程序的鉴定。

2．要评审或分析的数据项的鉴定。

3．参与评审或分析的人员。

4．评审或分析结果。

5．评审或分析结果产生纠正措施，比如列出问题报告清单或措施项。

6．评审结论包括对评审项目的定性评估；分析结论包括对分析项目的定量分析和分析

数据。

10.4.4试验流程
硬件的试验流程定义在验证硬件项中用于指导功能和环境鉴定试验的方法、环境和说

明。

硬件试验流程应该包括：

1．试验的目的。

2．确立每一硬件试验的试验装置、软件和试验设备装配说明。

3．指导试验程序的详细说明。

4．试验的输入数据。

5．预期结果，比如合格/失败判据和试验所能覆盖的需求。

10.4.5试验结果
硬件的试验结果是试验已经按照批准程序完成的客观证据，用来支持硬件项的验证。

硬件试验结果应该包括：

1．试验流程的鉴定。

2．试验项目的鉴定。

3．实施试验的实际结果。

4．实施和目击试验程序的人员资质鉴定，如适用，所实施试验数据的鉴定。

5．以分析或评审及实际试验覆盖率对结果进行解释。

- 45 -
 中国民航大学 适航审定研究中心编译

10.5硬件验收试验标准
此数据为试验及相关试验结果是否能够保证硬件项被正确地生产修理提供标准和评估

数据。

目标标准应当包括：

1．被试验的关键属性。

2．关键属性的合格/失败判据。

3．任何的试验约束。

4．关键属性及合格/失败判据的印证。

5．对设计方面必须满足安全需求的覆盖率。

6．表明试验标准是严格按照试验程序实施的评估数据，以及相关试验结果。

10.6问题报告
问题报告是一种用于标识和记录硬件设计问题、不符合硬件计划的程序以及硬件生命周

期数据缺陷的方法。

问题报告应该包括：

1．标识用于监测问题的构型项目和程序行动。

2．标识需要改进的构型项目或描述要改变的程序。

3．有助于问题理解和解决的问题描述。

4．解决报告的问题的纠正措施描述。

10.7硬件构型管理记录
构型管理程序行动的结果被记录在构型管理记录中。它们可以包括构型标识清单、基线

或者电子记录、更改历史报告、问题报告概要、工具标识数据、文件存档和发布记录。

10.8硬件程序保证记录
程序保证结果被记录在程序保证记录中，它们可以包括报告的评审或核查报告、会议记

要、局方批准程序的偏离记录、或者是符合性评审记录。

10.9 硬件工艺概要
硬件工艺概要是用来表明遵循PHAC和向局方展示本指南的目标得以实现的最主要的

数据项。这个概要可以与系统工艺概要是结合的，在PHAC中存档的硬件工艺摘要应该包括

以下信息：

1．系统概述。

- 46 -
 中国民航大学 适航审定研究中心编译

2．硬件概述。

3．审定考虑因素。

4．硬件设计生命周期描述。

5．硬件设计生命周期数据。

6．早期研制的硬件。

7．附加考虑因素。

8．替代方法。

背离已批准的PHAC的差别应该被识别，下面的四个项目应该被处理：

1．硬件标识。这部分通过件号和版本来标识硬件构型和硬件项。

2．更改历史记录。如果适用，这部分包括了影响安全的故障带来的硬件改变概要，标

识了自硬件设计生命周期前期审定后的更改。

3．硬件状况。这部分包含了一个在审定时还未解决的问题报告的概要，包括一个功能

限制的声明。

4．符合性声明。这部分包括一个对本指南的符合性声明和一个证明对硬件计划中详述

的目标标准符合所使用方法的概要。这部分也记录了硬件计划、程序和本指南文档中的附

加规定和对它们的偏离。

注释：在PHAC中包括的数据没有必要再在硬件工艺概要中重复，然而重复却可能对审

定程序有所促进。

- 47 -
 中国民航大学 适航审定研究中心编译

11.0附加考虑因素
这部分提供关于在前面部分没有提到的设计保证的附加考虑因素的指南。这些附加的考

虑因素可以由申请人的自主选择以满足第2部分到第9部分的一些目标。任何附加的考虑因素

的使用都应经过局方的认可。

11.1早期研制的硬件的使用
这部分论述使用早期研制的硬件而产生的问题。

指南包含了对硬件更改的评估、在航空器上的安装更改的评估、使用的环境更改的评估、

以及设计环境更改的评估和改造设计基线的评估。指南对COTS部件的使用（这是早期研发

硬件的一个特殊情况），将在11.2部分叙述。每一个早期研制硬件的构型管理和程序保证考

虑因素也应当被处理。

使用早期研制的硬件的目的都应该在PHAC中声明。

11.1.1对早期研制硬件的更改
这部分论述对早期研制的硬件的更改。更改可以源于需求的改变、设计差错的发现、技

术或硬件的改进以及采购困难。

建议的更改分析包括：

1．系统安全评估程序评审的输出。

2．如果硬件设计保证的等级提高了，本指南11.1.4部分的适用部分。

3．更改的影响应予以分析，包括那些可能导致重新审定的范围超出了自身区域的更改

的结果分析。这些区域可以由信息流分析、功能分析、时序分析、追溯性分析来确定。

11.1.2在航空器上安装的更改
这部分论述在某种硬件设计保证等级和特定审定基础上已经过审定的硬件，现用于在航

空器上进行新的安装。当新的航空器安装使用早期研制的硬件时，应遵循以下指南:

1．系统安全评估程序评估了新的航空器安装并且确定了硬件设计保证等级和审定基础。

如果新的安装和早期的安装一样或要求更为宽松，则不需要进行附加的工作。

2．如果对新的安装需要进行功能性修改,那么应该遵循11.1.1部分关于早期研制的硬件

更改的指南。

3．如果以前的设计活动没有包含对新安装安全目标所需要的证明，则应遵循11.4部分

关于改造设计基线的指南。

- 48 -
 中国民航大学 适航审定研究中心编译

11.1.3对使用或预期设计环境的更改
早期研制的硬件的使用可能涉及新的设计环境或者其他有别于原来所使用的软硬件的

综合。新的设计环境可能在硬件设计生命周期程序中增加或者减少一些工作。指南包括:

1．如果新的设计环境使用硬件设计工具,可以遵循11.4部分关于工具评估和鉴定。

2．早期研制硬件中采用了不同接口的硬件应实施硬件接口验证。

3．当早期研制的硬件用于不同的软件时,需要重新验证软硬件接口。

11.1.4对设计基线的升级
当早期研制硬件应用的生命周期数据不能满足与新的应用相关的安全目标时，下面的指

南将适用。这部分的指南是为了帮助申请人在早期研制的较低设计保证等级的硬件上与局方

达成一致。

对设计基线的升级指南包括:

1．想要利用早期研制硬件的生命周期数据,需要满足此文献的目标。

2．硬件的审定应该根据失效状态和由系统安全评估程序确定的硬件设计保证等级。对

早期应用变动的影响应该经过分析，以确定不足之处。

3．按所要求设计保证等级升级的功能，其执行硬件早期研制的生命周期数据应该被评

估，从而保证达到验证程序的目标。

4．逆向工程可被用于再生不足或丢失的硬件生命周期数据，以满足设计保证目标。

5．如果产品使用经验的使用是为了满足设计基线升级的设计保证目标，11.3部分的产

品使用经验指南应该被实施。

6．申请人应该在PHAC中对如何实现遵循本指南要求的策略给出详细说明。

11.1.5附加构型管理的考虑因素
对早期研制硬件新的应用的构型管理程序应该包括第7部分和以下内容。

1. 对早期研制的硬件新应用的硬件生产和生命周期数据的追溯性。

2. 更改控制程序，它应可以管理由同一项目的不同应用而需要的更改。

11.2成熟商用工艺器件（COTS）的使用
COTS器件被广泛地使用在硬件设计中，并且通常COTS器件无法提供设计数据以供检

查。 审定程序无法详细的处理单独的元部件、模块和子组件，这被审定特定飞机功能的一

部分内容所覆盖。同样的，COTS器件的使用将通过总设计程序来验证的，包括本指南中定

义的支持程序。电子元件使用管理程序将与设计程序一起，为COTS器件的使用提供基础。

- 49 -
 中国民航大学 适航审定研究中心编译

11.2.1COTS器件的电子元件管理
COTS器件的电子元件管理对硬件的设计和研制来说是一个重要支持程序。电子元件的

管理程序应用与COTS器件，然而这个程序既有商业又有技术方面的影响，这部分仅仅处理

影响审定的技术方面。

审定置信度是通过确立以下方面来达到的：

1．部件制造商能对产品的高质量给出一个追踪记录证明。

2．部件制造商能够建立质量控制程序。

3．有产品的成功运行的使用经验支持。

4．元件已经通过厂商或者其他质量鉴定，确定了元件的可靠性。

5．部件制造商控制了部件质量等级或采用其他附加产品试验来保证。

6．部件已被选择了适用于部件预期使用的技术基础，例如，部件温度范围、功率或电

压规定值, 或那些用于确立这些方面的附加试验或其它方法。

7．部件的性能和可靠性有持续的基础进行监测, 并反馈给部件制造商关于需要改善的

地方。

11.2.2COTS器件的采购
COTS 器件的采购指南并不适本文献的编写目的，而用于存在严重影响硬件设计保证

时申请人应当管理和解决的采购问题的反馈。主要包括：

1．COTS 器件设计保证数据的真实有效性。

2．由生产批次不同所可能造成的元件参数改变，甚至包括耐用性试验。

3．电子元件工艺的进步。

4．无法采购的 COTS 器件。

11.3产品使用经验
产品使用经验可以用于早期研制的硬件和 COTS 器件的设计保证证明中。产品使用经

验涉及到早期或者当前的元件使用的数据收集，这并不排斥非机载设备的数据。

注释： 使用产品项的广泛和成功应用可以说明产品的置信度，它说明目标产品项的

设计是成熟没有差错的，也是产品制造质量的一个证明。

11.3.1产品使用经验数据的可接收标准
当使用经验数据被用于设计保证时，使用经验数据的相关性和可接受性取决与下面的

一点或者几点：

1．关于硬件应用中的使用、功能、运行环境和设计保证等级的相似性。

- 50 -
 中国民航大学 适航审定研究中心编译

2．设计保证数据采纳范围是基于硬件项的预期构型。

3．在使用期间发现的设计差错已得到消除、缓解优化或者经分析不会对安全造成影响。

4．运行中实际的故障率。

注释：PHAC 应该明确的说明依靠于使用经验数据实施设计保证的部分。

11.3.2对产品使用经验数据的评估
为了满足以上标准，申请人应该：

1．基于工程分析评估目标早期使用、安装、目标运行环境的相关性。

注释：确定应用的适用性和使用限制数据可以在技术说明、数据单、应用注释、服务通

告、使用者信函和勘误表中提供。这些信息源也可以描述硬件相应功能，以便于

在机载设备运用中能够关联于以前的使用

2．评估预期使用对系统安全评估程序的影响，包括对数据所确定设计差错的可能减缓

措施。

3．评估设计差错任何可用统计数据对系统安全评估程序的影响，如果统计不是可利用

的可以采用定性评估。

4．评估可用的问题报告。问题报告可能表明使用经验导致的改进在当前配置中是可用

的。已标识但未解决的问题可能仍然可以采用结构化的减缓或实施附加的验证。确立或者

评估问题报告与硬件项目或产品需求改变之间的关联。

注释：对于电子部件，实际运用可以增加错误被检测出和消除的可能性，或者临时修正

是可行的可能性。

11.3.3产品使用经验数据的评估数据
用于印证预期使用的设计保证的使用经验评估数据应包括：

1．机载系统中部件及其功能的鉴定。标识设计保证等级或者在 A 级 B 级别功能中使

用的部件，部件附加保证方法的描述，例如所采用的结构方法和附加或高级的验证策略。

2．使用经验数据收集和评估程序的描述，包括决定数据充分性和有效性的标准。

3．使用经验数据，包括需考虑的详细使用信息、更改历史、用于分析使用数据的假设

和分析结果的概要。

4．涉及预期使用和要求的设计保证等级的使用经验数据充分性证明。

- 51 -
 中国民航大学 适航审定研究中心编译

11.4工具评估和鉴定
工具（包括硬件和软件）在硬件设计和验证中被普遍的用到。当设计工具用于生成硬

件项目或者硬件设计时，工具的错差将可能导致硬件项的错误。当验证工具被用于验证硬

件项时，工具错误可能导致工具无法检测到硬件项或硬件设计中的差错。在使用工具前应

该对工具进行评估。必要时，工具评估结果和工具鉴定应该被记录和保持。

工具评估和鉴定的目标是确保工具能在一个可接受的置信度上完成特定的设计或验证

活动。

11.4.1工具评估和鉴定程序
工具评估对在设计生命周期程序中工具的任务进行评估，可以包括由工具任务和硬件功

能设计保证等级确定的需要实施的鉴定活动。本评估指南采用一个流程图进行说明，适用于

达到目标或生成满足这些目标的数据而采用的设计工具或验证工具。此流程图示意申请人对

某些种类工具的有限评估和鉴定其他工具的工具。

工具评估和鉴定程序可以用于单独的工具也可以用于一组工具。一般情况下工具的性能

都超出了任何特定项目设计和验证的需求。只需要对在特定的硬件设计生命周期工作中所使

用工具的功能部分进行评估，而不是工具全部。

在不同的生命周期阶段工具可以综合利用以及共享，这是被公认的。如果在设计和验证

阶段用到相同的工具，那么这个工具可能需要作为一个设计工具进行评估，除非能够确立工

具这两个功能之间的分离和保护。

注释 1：如果对一个给定工具的评估显示它的一部分功能用于设计，但其它功能用于验

证，它可能值得去分别定位功能，并且评估每一组所需评估功能。

注释 2：此评估工作的核心是尽可能多的去评估工具的使用而并非工具本身。

图11-1的流程图给出了工具评估考虑因素和工作行动，提供了必要的工具鉴定指南。图

中在决断框和行动框中的数字表示，在图后提供了更为明确的描述。

- 52 -
 中国民航大学 适航审定研究中心编译

1
工具评估

2
工具支持程序的评估

是 3
工具的输出量是否
进行独立的评估?

否 4
是否为 A B 或 C 级的 6
设计工具/或者 A B 级 否 对工具的鉴定建立基
的验证工具？ 线和问题报告
是

5
工具是否有相应
的历史记录？
7
是 基本的工具鉴定

A 、B 级别的设计工具 8
9
工具的类型
设计工具的鉴定
和级别？

C 级别的设计工具或者 A B 级别的验证工具
10
完成

图 11-1 设计和验证工具的评估和鉴定

- 53 -
 中国民航大学 适航审定研究中心编译

1．标识工具。包括名字、来源、版本号以及主要的运行环境。工具的更新应该是有证

明文件和可追溯的。

注释：当对一个工具进行更新时，应该评估工具更新对现有的结果和剩余的硬件生命

周期带来的潜在影响。

2．标识工具所支持的程序。标识工具所支持的设计或验证程序，在硬件设计生命周期

中任何的工具和工具输出的相关限制。如果某个工具存在已发现的问题，在使用此工具时要

提供一个有论证的可接受的声明。

3．工具的输出量是否进行独立的评估?采用一个独立的方法对工具输出量的正确性进行

验证，如果工具的输出量已经被独立评估过了，那么不需要进行进一步的评估。

注释：对设计工具全部或部分输出独立的评估可以由项目验证活动建立，例如部件、

网表或组件。在这种情况下，最终产品的完整性不仅仅依赖于设计工具输出的正

确性。

对验证工具输出的独立性评估可以包括一个对工具输出手动的检查，或者可以

包括与其他独立的具有相同验证功能工具输出的比对。

申请人也可以建议其它独立评估的方法。

4．工具是否为A、B 或C级的设计工具或者A、B级的验证工具？如果是作为D级功能

的设计工具（或作为C级功能的验证工具）、或者是作为验证试验完成度评估的工具，比如

用于一个如附件B，第3.3.1.1.2 部分描述的元素分析，则没有必要进行进一步的评估。如果

是作为于A、B、C级功能的硬件设计工具或座位A、B级功能的硬件验证工具，那么需要进

行进一步的评估。

5．工具是否有相应的历史记录？如果一个有使用先例并且达到了预期结果，那么不需

要进行进一步的评估。对工具早期的使用与建议的用法的相关性讨论应该包括在工具使用的

论证中。

注释：工具的历史记录可以来源于机载或者非机载的应用中，它提供了工具的相关性

和置信度的历史数据证明。

6．为工具的鉴定确立基线和问题报告。为工具的构型管理建立一个基线，为工具的鉴

定准备一份问题报告。

- 54 -
 中国民航大学 适航审定研究中心编译

7．基本的工具鉴定。 采用分析和试验的方法建立和执行一个确定工具输出量正确性的

计划。工具的使用指南或者工具功能及使用的其他描述可以用于得出这些需求。

8．工具的类型和级别？ 考虑一个工具是一个A或B级的硬件设计工具，或者是一个C

级别的硬件设计工具，或者一个A或B级别的硬件验证工具？

9．设计工具的鉴定。采用附件B中描述的策略、RTCA DO-178B / EUROCAE ED-12B

的工具鉴定指南或者其他局方的可接受的方法来鉴定A或B级设计工具。从工具研制开始，

此项工作的独立性应当被确立。

注释：对于 A 级 B 级设计工具鉴定的详细指南并不在这里提供，这是由于工具使用环

境、涉及的技术、工具执行得可见度河生命周期数据以及其它因素的多样性。使

用输出和相关使用历史未经过独立评估的设计工具是不被鼓励的，这样可能会被

证明是一个苦差事，它的挑战不亚于此工具所开发硬件的研制。

10．完成。存档工具评估程序、评估决议的论证、（如适用）还有工具鉴定的数据。为

安装指南、使用手册和工具鉴定数据提供详细的参考，用于支持工具指派和鉴定的。

11.4.2工具评估和鉴定的数据
工具评估和鉴定的数据应该包括：

1．标识工具、其支持的程序，适用时还包括以下项目：

a.图11-1项目3独立性评估的基本原理和结果。

b.图11-1项目4的工具指定

c.用来满足图11-1项目5条件的工具的历史记录。对工具早期的使用与建议的用法相

关性的讨论应该包括在工具使用的论证中。

2．在工具的鉴定中使用一个清晰的构型定义，以依从图11-1项目6的要求，如果被试验

的构型与实际用于设计或验证的最终硬件存在差异，那么就需要论证证明它的适用性。

3．工具鉴定的细节，包括用于试验的需求、试验程序、预期结果、用于解释和补充试

验结果的分析程序，以及如何建立独立性。

- 55 -
 中国民航大学 适航审定研究中心编译

4．设计工具的鉴定计划，包括应用的程序，以及计划中任何标识的工作的结果。

5．对已知的工具勘误的处理，包括工作区，以及（如适用）由工具鉴定结果得出的问

题报告。

- 56 -
 中国民航大学 适航审定研究中心编译

可附录 A
基于硬件设计保证等级对硬件生命周期数据的调整
本附录为基于硬件设计保证等级的硬件设计生命周期数据调整提供指导。同时，也为

符合性验证程序的独立性要求提供相关的指导规范。

表 A-1 标识了每个数据单元的数据交付类型和构型管理数据控制类型。查看表 7-1，

可以看到两种数据交付类型的描述。

1．提交：数据项必须提交给认证机构。

2．不提交：数据项不是要求的。

所有等级 A 和等级 B 功能的符合性验证应当是独立的。等级 C 及更低等级的功能不需

要独立的验证，仅当符合性验证时设计不符合要求的设计层级才需要独立性验证。一些能

解决共模故障问题的方法都可以作为与独立性等效的方法被接受。

在设计人员自己验证硬件项目时，可能仅发现正在研制的硬件项目符合了他的设计，

然而却有另外一种可能，硬件设计并没有完全遵循对硬件的需求。独立性就是一种发现此

种潜在共模故障的方法。为了解决这个问题，应该采用除了设计人员之外的独立个人、方

法或者工具，来保证符合性验证程序与设计需求一致。有很多确立独立性的方法，但符合

性验证方案应根据特定的验证项目选择合适的方法。

下面是一些可以使用方法的举例:

1. 需求或设计由其他人员进行评审。

2. 试验案例或程序由其他人员编写。

3. 由设计人员本人提出试验实例或程序，但由其他人来评审。

4. 由设计人员本人做出分析，但由其他人或评审小组进行评审。

5. 采用不同的试验来证实设计人员自己完成的试验结果，如一个飞行试验可以

确认硬件项试验或软件验证试验结果的正确性；独立研发并实施在目标硬件

上的软件验证试验可以证实硬件设计人员自身试验的结果。

6. 通过工具来验证试验或分析结果。

注释 1：通常的验证试验是自动执行的，并且操作简单，例如仅需要按下试验按钮。

若试验经过独立的评估和设计，独立性的含义并不是指必须要除设计人员以外的

人来执行这种试验。但结果仍然需要独立的检查来证实使用了正确适当的程序方

案，并且结果能够证明对硬件的需求已得到满足。
注释 2：组织结构分离不需要达到独立性要求。表 A-1 中画圈的数字可以查阅表后的
注释。
 中国民航大学 适航审定研究中心编译

表 A-1 基于硬件设计保证等级和硬件控制等级的硬件生命周期数据

数据参考章 硬件生命周期数据① 目标② 提 等级 等级 等级 等 级

节 交 A B C D

10.1 硬件计划

10.1.1 硬件合格审定的专项计划 4.1(1,2,3,4) S HC1 HC1 HC1 HC1

10.1.2 硬件设计计划 4.1(1,2,3,4) HC2 HC2 HC2 NA

10.1.3 硬件确认计划③④ 4.1(1,2,3,4);6.1.1(1) HC2 HC2 HC2 NA

10.1.4 硬件符合性验证计划 4.1(1,2,3,4);6.2.1(1) S HC2 HC2 HC2 HC2

10.1.5 硬件构型管理计划 4.1(1,2,3,4);7.1(3) HC1 HC1 HC2 HC2

10.1.6 硬件程序保证计划 4.1(1,2,3,4);8.1(1,2,3) HC2 HC2 NA NA

10.2 硬件设计标准

10.2.1 对“需求”的标准③ 4.1(2) HC2 HC2 NA NA

10.2.2 硬件设计标准③ 4.1(2) HC2 HC2 NA NA

10.2.3 确认和验证标准③ 4.1(2) HC2 HC2 NA NA

10.2.4 硬件归档标准③ 4.1(2);5.5.1(1);7.1(1,2) HC2 HC2 NA NA

10.3 硬件设计数据

10.3.1 硬件需求 5.1.1(1,2);5.2.1(2);5.3. HC1 HC1 HC1 HC1

1(2);5.4.1(3);5.5.1(1,2,

3);6.1.1(1,2);6.2.1(1)

10.3.2 硬件设计典型数据

10.3.2.1 概念设计数据③ 5.2.1(1) HC2 HC2 NA NA

10.3.2.2 详细设计数据 5.3.1(1); 5.4.1(2) ⑤ ⑤ ⑤ ⑤

10.3.2.2.1 顶层图纸 5.3.1(1); 5.4.1(2); S HC1 HC1 HC1 HC1

5.5.1(1)

10.3.2.2.2 组装图纸 5.3.1(1); 5.4.1(2); HC1 HC1 HC1 HC1

5.5.1(1)

10.3.2.2.3 安装控制图纸 5.4.1(2); 5.5.1(1) HC1 HC1 HC1 HC1

10.3.2.2.4 硬件软件接口数据③ 5.3.1(1); 5.5.1(1) HC1 HC1 HC1 HC1

10.4 确认和验证数据

10.4.1 硬件可追溯性数据 6.1.1(1); 6.2.1(1,2) HC2 HC2 HC2⑥ HC2⑥

10.4.2 硬件检查和分析程序③ 6.1.1(1,2); 6.2.1(1) HC1 HC1 NA NA

 中国民航大学 适航审定研究中心编译

10.4.3 硬件检查和分析结果③ 6.1.1(1,2); 6.2.1(1) HC2 HC2 HC2 HC2

10.4.4 硬件试验流程③ 6.1.1(1,2); 6.2.1(1) HC2 HC2 HC2 HC2⑦

10.4.5 硬件试验结果③ 6.1.1(1,2); 6.2.1(1) HC2 HC2 HC2 HC2⑦

10.5 硬件验收试验标准 HC2 HC2 HC2 HC2

10.6 问题报告 5.1.1(3);5.2.1(3);5.3.1( HC2 HC2 HC2 HC2

3);5.4.1(4);5.5.1(4);6.1

.1(3);6.2.1(4);7.1(3)

10.7 硬件配置管理记录 5.1.1(1);7.1(1,2,3) HC2 HC2 HC2 HC2

10.8 硬件程序保证记录 7.1(2) 8.1(1,2,3); HC2 HC2 HC2 HC2

10.9 硬件工艺概要 8.1(1,2,3) HC1 HC1 HC1 HC1

①．应当提交的数据在提交栏中用“S”进行了标注。用来进行合格审定的 HC1 和 HC2 数据

不需要提交，但应该是可提供给局方的。参加 7.3 节。

②．这里列出的目标仅供参考。不是所有的目标都适用于全部的保证等级。

③．如果数据是用来进行合格审定的，那么它的可提供性也列在表中。数据并非是合格审定

中全部使用的，也可能不会要求。

④．对于等级 C 和等级 D，非正式情况下可以通过合格审定联络程序完成。文件可以是会议

记录或陈述性材料的形式。

⑤．如果请求者在提交的数据中参照了某个数据项，那它应当是可提供给局方的。

⑥．只需要从需求到试验阶段的可追溯性数据。

⑦．试验不需要覆盖硬件自身需求或更低级的需求。
 中国民航大学 适航审定研究中心编译

附录 B 关于 A 级、B 级硬件设计保证的考虑因素
1.0 引言

硬件设计者对于 A 级和 B 级的功能做出的设计决策可能对安全性有影响。随着设计保证

等级的增加，需要一种方法来验证给定的设计是否符合安全要求，该方法可能需要各种设计

保证方法的交叉、分级、综合使用。这就需要使用者能在这些方法中选择出一种或多种方法

或者提出能提供设计保证的其他方法。

本附录将在如何借助 FFPA 提出和执行一个设计保证策略以及一些可以用于设计保证的

特定方法两个方面为设计者提供指南。

2.0 功能失效路径分析

FFPA 是结构化的、自顶向下的、循环分析法。它标识了设计中执行功能的特定硬件部

分，也就是和每条路径相关联的组件、部件和元件；标识了用于确定硬件结构和实现是否符

合安全要求的相关故障模及影响。FFPA 也标识了设计中执行 A 级和 B 级功能的组件、部件

和元件。

FFPA 从 PSSA 开始分析，PSSA 用来标识系统等级 FFPs，系统等级 FFPs 也可以被分解并

分配到硬件 FFPs.

FFPA 的目标是标识单个的 FFPs,因此：

1. 采用本附录中描述的适当的设计保证方法或其他局方认可的高级方法，来定位执行

A 级和 B 级功能的硬件。

2. 本附录考虑的事项对执行 C 级或更低等级功能的硬件是可选的。也就是说采用本文

献中第 3 至第 11 章的指南就可以保证执行 C 级或更低等级功能的硬件。

注释：由于整个硬件项目的设计保证可能由多个设计保证方法完成，对于采用不同技术

的功能实现或者不同的设计可察度，独立的 FFPs 标识通常会很有用。每个 FFP 的

分解等级可以是不同的。

FFPs 的分解采用传统的自顶向下安全性评估方法进行，如故障树分析方法。对于每个

分解的层次等级，可以采用如 F-FMEA、相关性流图以及共模分析等方法来辅助。对每个系

统等级 FFP 来说，分解等级可能是不同的，它取决于设计保证策略，相关于硬件设计所要采

用的执行思想和错误排除方法。

分解程序始自：

系统级 FFPs 到 硬件级 FFPs；

 中国民航大学 适航审定研究中心编译

从硬件级 FFPs 到 电路级 FFPs；

从电路级 FFPs 到 部件级 FFPs；

从部件级 FFPs 到 元件级 FFPs。

2.1 功能失效路径分析方法
FFPA 分析方法应按下述方式执行：

1. 对每个 A 级和 B 级功能，基于功能的硬件需求和系统 FHA，标识其功能及其设计保

证等级。功能可能有很多子功能组合而成，每个子功能都有一套相应的衍生需求和

一个相关的设计保证等级。这些子功能必要时可能需要进一步往下分解。

2. 对每个等 A 级和 B 级功能，确定实现功能或子功能的方法，并且分析设计保证方法

选择。为了功能或子功能的实现，可用或预期可用的设计保证数据应该是完整的，

并且是被设计保证策略或所选取策略容许的。如果可用或预计可用的保证数据是完

整、正确并且达到标准的，那就不必进行下一步的分解。

3. 对于非 A 级或 B 级的 FFPs,它们与 A 级或 B 级 FFPs 之间的关联应当采用 F-FMEA、共

模分析或相关性流图予以评估，从而保证非 A 级或 B 级 FFPs 不会给 A 级或 B 级 FFPs

带来负面影响。

评估程序是迭代进行的。如果没有适用且合格的 FFP 设计保证方法，分解和评估程序会

一直重复，或者改变硬件功能实现方式或结构，直到一个适用且合格的设计保证方法被确定

下来，并且合格适用的保证数据已经提供或能够提供给每个 A 级或 B 级的 FFP。

FFPA 的结果和硬件设计保证选定的方法会传送给飞机系统研制程序，如本文件 2.1 节所

述。这些结果用来检查和确认飞机级的一些设计假设，尤其是有关于系统交叉使用的相似硬

件等级的假定是否仍然是正确的。

2.2 功能失效路径分析数据
FFPA 数据应当：

1. 能标识从系统分配到硬件功能的功能性故障和异常工作状态。

2. 能标识 FFPs，它们异常工作后或功能失效后的影响，以及在设计层面经过分析的分

解等级和应当可提供且合格的保证数据的类型和定位。

3. 能描述 FFPs 之间的相互关系，从而确定他们的独立性及其对其他 FFPs 和部件的依

赖性。定性的 FTA 或其他的自顶到下的分析方法、共模分析、F-FMEA,或相关性流图

都可用来描述 FFPs 之间的相互关系。这种关系描述应该能确定它们之间的路径、元

部件和内在的依赖性。

4. 能追溯 FFPs、硬件需求及其衍生需求。
 中国民航大学 适航审定研究中心编译

3.0 A 级或 B 级功能的设计保证方法
本附录的目的并不是用任何现有或将来的方法来限制设计保证的实现。本附录讨论的方

法可适用于实现在本文献第 4 至第 6 章中所述的一个或多个程序的目标。

3.1 结构缓和
结构设计特点，如非相似性，冗余度，监控，隔离，分区和命令/权限限制,都可以用来

减轻或抑制硬件设计错误和设计实现错误的不良影响。PSSA 中的一些措施，如定性故障树

分析、共模分析，可以为确定需要减轻和抑制硬件故障、失效、设计和设计实现错误的范围

提供保证。确切地说，这种方法需要与附录 B 中第 2 部分的硬件 FFPA 方法联合使用，并用

共模分析程序来确定特殊减缓策略对硬件设计错误和设计实现错误覆盖能力的适用性。举个

例子来说，冗余度通常主要针对于随机故障和扰动，但是当共模方面的问题已解决时，冗余

度设计也可以有效地减轻硬件设计错误和设计实现错误。

3.1.1 结构缓和措施
确定与将采用的硬件实现方法相关的 FFPs，然后分析设计方法选项，以确立预期用来

减轻 FFPs 影响的设计特征和策略，这就是执行结构缓和措施的程序。为减轻 FFPs 的影响，

预期结构的全部影响都应被评估并提出相应措施。结构缓和措施策略的采用必将引入一些衍

生要求，这些衍生要求应当被验证。特别地，结构的设计特性应能抵御已标识的 FFPs 的部

分或全部负面影响，此外还应对额外引入的故障路径实施评估，这些额外因入的故障路径当

然也需要进一步实施结构缓和或其他本附录中描述设计保证策略。

3.1.2 结构缓和解决方案
安全性评估程序确定结构缓和方法是否符合要求。FFPA 首先应当标识所有采用结构缓

和措施的 A 级 B 级硬件 FFPs，并且应当确认所要采用方法，以及确定结构缓和措施的原理。

缓和方案是否足够，是由对该方案支持功能的评估来确定，此评估应当结合整体结构背景的

关联，这有可能涉及或多或少的复杂结构缓和策略的综合应用。

共模分析应能解决在需求、设计实现、生产制造和维护中影响结构缓和措施的各种潜在

共模错误。设计者还要考虑实现结构缓和功能硬件的各种潜在随机故障，以防止结构缓和措

施无效。丧失缓和措施可能导致的安全裕度的降低，因此缓和措施功能的可用性概率应与丧

失缓和措施导致的影响相匹配。

整体方案应保证正常运作和各个必要功能间的可接受的独立性的要求得到满足并保持。

任何用于消除、隔离或限制剩余共模影响的特殊保障措施应予以标识，并与其他的结构缓和

方法或本文涉及的其他的设计保证策略结合使用。
 中国民航大学 适航审定研究中心编译

当结构定义已完成，不能缓和或缓和度不够的 A 级和 B 级 FFPs 的硬件功能应使用本附

录中其他的设计保证方法进行再处理。举例来说，对未采取结构缓和措施的电路或部件部分，

当用安全特质分析为其标识和提供验证覆盖时，个体电路和元件的局部缓和结构措施可以与

安全特质分析结合使用。

3.1.3 结构缓和措施数据
用于保护硬件中 A 级和 B 级 FFPs 的结构缓和措施文件，应该以安全评估数据、安全性

需求数据和追溯性数据的形式提供。安全评估数据以硬件 FFPs 评估和共模故障分析为基础

（尤其关注硬件设计方面的结构缓和措施）。

结构缓和措施数据应包括：

1．标识结构缓和措施所要保护的 A 级和 B 级的 FFPs。

2．描述结构缓和措施的方案和确认该方案覆盖度的基本原理。

3．确定共模故障的边界基本原理和用于该结构的共模设计考虑的基本原理。

4．标识由于未缓和或缓和度不足，而采用其他的设计保证方法的 A 级和 B 级的 FFPs。

5．关于功能运算和结构缓和机制必要设计特征的规格要求。

6．满足安全要求的缓和机制，并包括软件，如软件隔离、安全监控和非相似性软件，

这些机制和软件安全需求提交给系统研制程序和软件开发程序。

7．结构缓和措施中适用的各硬件的故障率数据和潜在故障暴露时间的评估数据。

8．关联安全需求、适用安全性评估数据及设计验证数据的追溯性数据。

3.2 产品使用经验
关于如何评估机载硬件适用的产品使用经验数据，11.3 节提供了基本的指南。对于用

以前的开发硬件作为设计一部分的 A 级和 B 级功能，额外的设计保证是必须的。下面就是提

供了这些设计保证方法。

3.2.1 产品使用经验方法
实施 11.3 节的评估方法之后，应参考所有的应用使用经验分析开发硬件实现中的 FFPs。

申请人或设计者应确定标识使用经验数据，并确定经验数据能证明在以前的硬件使用历史

中，已充分实践了现在再次使用的硬件功能。

3.2.2 产品使用经验解析
产品使用经验数据的分析完成后，确定未实践运用或不能充分实践运用，或者在使用中

的经验数据不可用的 FFPs 中 A 级和 B 级的功能，应该使用其他的设计保证方法或能实践运

 中国民航大学 适航审定研究中心编译

用功能的附加验证方法进行处理。

3.2.3 产品使用经验数据
硬件中用来保护等级 A 和等级 B FFPs 的产品使用经验数据应该包括：

1. 11.3 节所述的产品使用经验评估数据。

2. 标识由产品使用经验提供的设计保证的 FFPs 和认定使用经验数据充足的理由

3. 标识使用经验数据不充足的 FFPs，标识用来完成 FFPs 设计保证的试验环境、试验

程序、分析和结果。

4. 标识没有被使用经验证实而需要其他的结构缓和或高级验证的运行条件和 FFPs。

5. 10.4.1 节所述的可追溯性数据，它说明了数据使用资料和对每个 FFP 所提供设计保

证覆盖范围的验证之间的直接联系。

3.3 高级验证方法
高级验证方法的运用可以增加的设计保证的置信度和提供保证证明，例如元素分析法、

形式分析方法、安全特质验证分析法或其他请求者建议或局方认可的方法。

设计保证的高级验证方法可以使用和拓展附录 B 第 2 部分中 FFPA 方法的范围。FFPA 方

法多用在设备级、电路级和部件级来决定 A 级和 B 级的 FFPs 实现。然后，使用 FFPA 的数据

确定被预期的设计保证方法是否适用于 A 级和 B 级 FFPs 中的硬件电路、部件和元件。

这里总结了三种方法，如下所述：

1．元素分析法

元素分析法是一种自下向上的方法，提供了一种硬件验证完整性的检测方法。使用符合

6.1 验证目标要求的验证试验方案，来确认、标识并验证 FFP 中的每个功能元素。这种分析

方法也会标识需要关注并需要其他适当方法处理的地方。

2．安全特质分析法

这种方法着眼于找出并纠正从系统安全性的角度对硬件输出造成不良影响的设计错

误。它分析并确定对硬件安全敏感部分的输入和输出端口区域。在敏感部分的硬件输入端口

将加入激励，然后观测输出响应，同时验证安全敏感的预期功能需求，以及其异常的工作状

太。对于输出端口的观测方法应该在验证之前使用传统的安全分析技术确立。

3．形式分析方法

形式分析法采用来自形式逻辑和离散数学里用于详细描述、设计和验证计算机系统的技

术。这种方法可以将硬件设计生命周期的各个不同程序的使用的推理进行证实

除了本部分提到的方法，其它的高级验证方法也可由申请者推荐。
 中国民航大学 适航审定研究中心编译

3.3.1 元素分析
元素分析可表明 FFPs 已由相关验证试验案例验证。元素分析法将复杂 FFP 的实施程序

分解为设计人员选用的元素层级，以保证和证实设计错误得到排除。这种方法提供了一种支

持确定验证覆盖率和完整性的验证程序的检测方法，它最适合用在设计细节可见并在构型控

制下的情况。如在 ASIC 或 PLD 中，在同一设计保证等级上执行功能，或者不同设计保证等

级的功能被隔离或分离。为了保证预期功能的正确性，通过实施为达到第 6.1 部分验证目标

要求的验证程序，每个使用的电路和部件的功能元素都应当被标识和验证。元素分析法通常

用于整个部件或与组件（与其包括的 FFPs 数量无关），但是，当不同 FFPs 的隔离、独立性

或分离原理已知时，元素分析法也可用于元素或组件的一部分。

注：当将元素分析法运用于被 PLD 执行的一个功能时，应包含编程内容和 PLD 特性的

应用。对于未编程的部件，应由单独的方法来处理，比如前面所述的产品使用经验。

元素分析法标识需要适当处理的关注区域。没有这种分析的验证程序可能导致电路试验

不充分。经验来看，这种不充分主要是由于基于需求的试验程序不足、不明确或不完整的硬

件需求、未使用的电路、初始化电路和程序库功能等的缺陷造成的。元素分析法检查所关注

FFPs 中的元素，并确定是否涉及到每个元素的验证都已覆盖并完成。如果验证对元素的覆

盖率被证明不完整，那就需要其它的附加验证或适当处理方法。

申请者应就元素是在设计层次的哪个等级定义的，以及元素的验证覆盖率是如何被分析

等问题做出计划。

3.3.1.1 元素分析方法

元素分析方法从定义一系列相关于硬件设计保证等级的分析标准、硬件技术标准和硬件

实施细节可见性的标准开始。

标准应包括：

1．在适当的硬件设计层级，对于元素的标识和定义。

2．确认验证的覆盖率，要求在此覆盖率中每个元素都应该被验证。

这些标准用于进行验证工作的分析，从而确定依据验证计划的验证覆盖率是否达到完成

标准。如果没有达到完成标准，每个元素应实施下面的方法来检查：对每个元素实施一组适

当的激励信号，并因此在试验中监控的信号上产生适当的可以观测的响应。

注：此程序检查了硬件本身的试验，它可以检测到试验程序中的不足之处。定位和处理

试验的不足，将能够提供额外的置信度和证据来表明试验是充分的，然后执行一个

新的或修订得案例就能发现出硬件中的错误。

3.3.1.1.1 元素分析法标准的选择
 中国民航大学 适航审定研究中心编译

根据硬件元素类型、复杂性和明确的元素执行功能，逐项选择要用的元素分析标准。分

析能说明所有的低级别基本模块，如计数器，寄存器，多路复用器，加法器，运算放大器和

滤波器已充分检测，或者说明所有互联的基本模块都已经充分检测并达到验证覆盖率的标

准。试验程序分析标准应基于元素的执行功能评估以及综合其他元素来执行更高级别硬件功

能的评估。

注 1：举例来说：如果一个元素是一个用做时间延迟的模 N 计数器，试验程序可以选择

适当输入数据的等价信号来验证：计数器能够在启动时计数器开始计数，当关闭时

停止计数，以正确的速率计数，在指定的时间计数到 N 并跳转。并不要求试验程

序一定要验证到组成计数器的触发器和单个电门的功能。

举一个用内部交联模块作为一个元素的例子，一个运算逻辑单元 ALU 由寄存器、

加法器和控制逻辑电路等基本模块组成。可以通过对 ALU 的模拟表明基本模块共

同的组成了 ALU，但是，元素分析法的验证程序还应运用适当的等价输入数据来

验证 ALU 功能的执行。

不必在低于硬件设计者指定的设计等级上定义元素。只有在设计是明确采用门电路来实

现组合逻辑或状态机控制时，门电路等级的分析可能才是适合的。

注 2：分析低于设计者指定等级的执行硬件，如门电路或晶体管等级，是没有必要的，

因为这如同在汇编语言或在二进制模式等级上分析软件是一样的。实际上，在硬件

验证试验和成功评估过的后仿真中的元素分析，已经包含了对低级别模块的分析，

需要的话，还应考虑到符合 11.4 要求的对模拟工具的鉴定。

ASIC 或 PLD 可能包含特有的、无法得知内部设计的库函数，也就不能进行人工分析。

可以把库函数看作元素分析中 COTS 的元素，它具有 11.2 和附录 B 的 2.2 定义的 COTS 硬件

特征。库函数使用的验证应表明与库函数厂商提供的说明书或描述一致，并在检测结果可观

测的环境中进行。

注 3：此处并非限制库函数的使用，支持新函数的建立。而是鼓励使用实践过的库函数，

从而减少错误带入硬件的可能性。

对采用更高级别的 HDL 综合而成的 ASIC 或 PLD，其分析标准应基于能表述硬件的高级

语言代码。但是，由于 HDL 表述的综合程序可能包含并行逻辑结构和非时序特点，综合的输

 中国民航大学 适航审定研究中心编译

出则应包含在分析是否完成的判定中。同时对综合的工具进行评估。

3.3.1．1.2 实施元素分析

元素分析使用基于需求的符合性验证试验，验证试验应在下面一个或多个试验环境中进

行：

1．在目标组件中执行功能路径的电路试验

2．独立原型样机的试验。对 ASIC 或 PLD 来说，这样的试验是较典型的。

3．制造验收试验。

注：由于生产制造试验通常不是基于需求，制造验收试验在元素分析法中的适用性可

能是有限的。

4．一个后仿真，特别对 ASIC 或 PLD 来说，此实验应已被评估，需要的话，还应通过 11.4

要求的验证工具的鉴定。

元素分析方法本身可用仿模拟试验检测完成情况，所提供的将要分析的试验程序应与元

素所实施的元素分析标准相关，且能用来提高硬件功能验证置信度并达到第 6 部分要求的目

标。如果所分析的试验程序源自在电路中试验或独立原型机试验并且采用了模拟，试验的激

励和预期的结果应能转换成模拟器的适用模式，且所提供的转换程序已经作为元素分析法的

一部分经过核查是准确的。用来实施元素分析的模拟器应能正确判定采用的各类型元素是否

满足了分析标准。

3.3.1.2 元素分析结果解析
元素分析可以发现未被验证的硬件元素，这意味着需要额外的符合性验证程序，或者

需要删除未验证的元素，或者需要减少由系统结构问题引起的非正常状态。硬件元素的漏检

可能由下列原因导致：

1．验证试验案例或程序本身的缺陷。试验案例如未按照附录 B3.3.1.1 部分的标准进行

硬件元素试验，就会产生这种缺陷。同样，如果忽略功能性需求，只将硬件项目想当然地设

计成能够产生相应可重复的响应，也会出现这种缺陷。在这些情况下，应该增补或改变试验

程序和试验案例。更进一步说，在硬件项对相应系统需求符合程度的试验能力上，应检验其

论断。

2．所提出的需求不充分。应对需求进行更改，或附加的衍生需求应予以确立。同时，

应开发、执行和分析为新的或修正的需求所附加的符合性验证试验。

3．未使用的功能。硬件项可能包含目标电路没使用的功能，如库函数中未使用的子功

能或仅在元部件等级验收试验中使用的试验结构体。这些功能应与其他使用中的功能隔离
 中国民航大学 适航审定研究中心编译

开，或者证明它们不会对安全带来负面影响，造成潜在的异常状态。只要证明未使用元素在

硬件中或安装时确实被抑制（屏蔽）了。如果未使用的功能将在未来使用，而这些功能没有

经过充分验证，将来使用它们时，需要重新进行元素分析。

4．不会造成安全影响的元素。元素不正常状态的通过分析可以限制并表明不会给飞机

或乘客带来安全问题。记录分析就可以验证这些不会导致安全后果的元素。

3.3.1.3 元素分析方法生命周期数据输出

元素分析法生命周期数据输出应该包括：

1. 标识元素分析要定位的 FFPs，提出在哪个设计等级定义元素的预案，提出怎样进

行分析以便充分验证（这是验证覆盖率完整性标准的一部分）的预案。这些都该包

括在 PHAC 或硬件验证计划中。

2. 描述采用的方法，标识此种方法分析中要定位的 FFPs 和分析执行的设计等级。

3. 保证 10.4.1 所述的追溯性数据能表明验证程序到元素分析法中元素之间的确切联

系。

4. 标识验证试验中的案例，以及依据元素分析结果所确定增加或修正的需求。

5. 陈述关于元素分析中定位的 FFPs 所达到的验证完备性等级，包括对由验证试验或

需求的修改造成的分析偏差和可接收性原理的标识。

3.3.2 安全特质分析
如适用，通过对选定电路和部件更加深入的分析，安全特质分析方法拓展了硬件 FFPA

概念。运用拓展的 FFPA 获得并确认电路和部件内部运行的安全特质需求。这些获取的安全

需求将采用下面要讨论的验证试验来定位。

安全特质分析基于这样的理念：只有当输入特定一些激励，休眠状态潜在的设计错误才

会影响硬件项的输出。所以，为了输入合适的激励和发现所关心的安全错误，确立需要安全

运行所必需的输入案例子集，然后把这个子集适当的等价类包含到验证试验中。当执行这些

试验案例时，评估硬件项的输出以避免导致不安全输出的特殊异常状态。用安全特质分析法

限制这组输入条件以便用于验证试验案例中，这样就不必处理无穷组可能的输入试验案例。

注：此操作可能会限制输入信号集和条件，这样试验界限以外的信号就不能或极不可能

的被允许作为输入。

安全特质分析方法也能确定一些电路和部件功能不能缓和缓解方面，虽然这些电路和部

件功能中局部结构缓和方法是可用的。这种情况下，额外的安全特质分析将是一种适用和有

效的方法来确定需要什么附加的设计保证来完善安全覆盖率。
 中国民航大学 适航审定研究中心编译

安全特质分析方法同样适用于 COTS 硬件或定制的电路和部件，因为它能够使用关于电

路和部件的用户指南资料而不是详细的内部设计数据。综合用户指南资料和更为详尽的

FFPA 方法，安全特质分析就能成功地确定电路、部件使用和相关内部 FFPs（需要重点消除

设计错误的地方）的敏感安全问题。用此信息可成功地导出电路和部件的验证试验，当这些

试验完成时，就可以使验证程序最大可能的发现、纠正、减缓电路与部件对系统的安全性方

面造成负面影响的设计错误或为其提供相应的措施。

3.3.2.1 安全特质分析方法

一旦在设计保证中选择了安全特质分析法的电路和部件，就应用附加的 FFPA 方法对其

进行更详细的检查。这样就可以更清楚地确定哪些电路和部件功能用于已标识等级 A 和等级

B 的功能。这个程序还需要在功能边界逐个检查每个所用的电路和部件，并考虑到电路或部

件在完成等级 A 和等级 B 的 FFPs 中更高级别的硬件功能中实际功能使用情况。

注 ：在电路和部件用户指南资料中可能具备足够的信息，以便用户成功地使用该电路

和部件的功能从而完成更高级别的硬件功能。如果有足够的电路和部件内部功能资

料，那就可以做评估分析了。如果没有充足的信息，不能执行本评估分析，应由其

他的方法代替或和本方法联合进行评估分析。

基于电路和部件的实际使用功能，标识了该电路和部件相关的敏感安全功能后，下一步

是更加详细的功能分析。即确定电路和部件功能中特定影响安全的和不能缓解的特性，以便

在安全特质验证条件中进行更详细的分析处理。用 F-FMEA 技术导出和确认验证条件，确定

安全敏感的特定功能品质，从而进一步确定电路和部件中组成等级 A 和等级 B FFP 功能的所

有特殊的异常状态。

通过上面的安全特质分析获得验证条件，并与下面的指南联合使用，来达到等级 A 和等

级 B FFP 中电路和部件验证的安全特质分析标准。指南包括：

1．标识功能的相关输入信号空间。基于已标识了的安全敏感功能特征和不正常状态，

确定相关的输出响应是正确还是失败的标准。开发有关的输入信号空间需要覆盖的等价信号

类。

2．标识每个所考虑功能的相关可观察的检测方法和输入信号激励方法。

注:可能会用到特殊的工具和执行功能部件以保证可观察性和可试验性。

3．对定位潜在错误来源和相互依赖性验证的试验环境进行说明。

注：部件级功能应在可行的最高集成等级上进行试验。较高综合等级试验通常能提供最

准确的错误来源覆盖区域，如混乱状态，相互依赖性和潜在的功能交叉现象。

应使用等价信号类进行试验开发。试验应该定位关键逻辑判定、算术、定时、状态转

换和实时等属性特征。
 中国民航大学 适航审定研究中心编译

3.3.2.2 安全特质分析法解决方案

根据所有适用的电路和部件安全特质分析的完成度，来确立安全特质验证完成标准。由

分析或验证本身发现的任何缺陷都应通过下面的方法之一进行解决。

1．更改设计以纠正错误

2．增加结构缓和，即通过从相关 FFP 上删除错误来解决问题

3．增加适当的试验

3.3.2.3 安全特质分析数据

安全特质分析用于等级 A 和等级 B FFP 的电路和部件时，它的归档证明材料应提供安

全评估数据和安全需求数据、验证程序和结果、追溯性数据。验证程序应源于安全需求和安

全特质分析。安全特质分析数据应包括：

1．标识确定安全特质分析方法要分析的电路和部件

2．标识确定每个电路和部件所在的等级 A 和等级 B 的 FFPs

3．对于采用安全特质分析方法提供设计保证的电路和部件的，标识确定其局部结构缓

和方案

4．为每个适用的电路和部件，确定哪些是能影响安全的功能

5．为每个标识的安全敏感功能，确定安全敏感属性和所关注的异常状态。

6．关于应用电路、部件、内部功能、功能属性和异常状态的验证条件

7．关于要验证的输入独立性和输出端口状态的验证条件

8．验证程序和结果

9．关联验证程序、硬件安全验证条件和安全特质硬件分析数据的追溯性数据。

3.3.3 形式分析法
形式分析法涉及到计算机系统规范说明、设计和架构中的逻辑和离散数学的使用。

注：本部分资料来源于：关于软件和计算机系统验证的形式分析方法规范和分析指南，

第二册：初学者指南，1997.5，NASA-GB001-97。这里将给出更详细的形式方法，

通过一个工作的实例来说明其使用。

使用形式分析法可归结为两个方面，即描述和演绎。描述方法使用形式规范语言，以清

楚明确地描述需求和其它设计。演绎方法遵循这样的原则，即要求清楚列举所有的假设和推

理步骤。另外，每个推理步骤只容许使用较少的推理法则。最严谨的形式分析方法运用这些

技术推理论证以证明需求或者设计、实施复杂关键系统的其他方面。形式分析法的目的是为
 中国民航大学 适航审定研究中心编译

了减少评估论证中对人知觉和判断的依赖性。演绎形式方法将可接受性的论证简化为一种运

算（原则上可以采用工具检查），避免在检查程序中保持固有的主观性，并且其程序是可重

现的。

设计程序中有许多地方采用形式分析法来提供附加的保证。虽然形式分析法可能在整个

设计程序中都适用，但锁定关键目标的选用会增加设计保证度。下面各项指出了其中的一些

可能性：

1．形式分析可用于开发生命周期的不同阶段。通常，在生命周期的最开始阶段使用形

式分析法最有效，尤其是需求捕获和高等级设计阶段。

2．形式分析法可用于整个设计或针对某个具体的部件。FFPA 确定用形式分析法分析哪

些 FFPs。复杂并行通信协议和执行容错功能的硬件可由形式分析法进行有效的分析。

3．形式分析法可用于验证系统功能或建立特定的功能属性。虽然，形式分析法通常用

来进行正确性证明，即确认部件符合其功能规范要求，但是，它也可以只用于最重要的功能

属性。通常，比起证明一个设计有完整的功能属性，证明其没有某些不良的功能属性更加重

要。

典型形式分析方法的实际运用需要工具支持。使用的工具需要经过验证，必要时，应达

到 11.4 部分所述的要求。

3.3.3.1 形式分析方法论

使用形式分析方法，首先要用形式语言说明需求。需求的详细说明提供了重要的描述性

功能，采用无意义的符号，为系统的工作情况和属性提供了建档、通信和建立模型的基础。

此外，需求的详细说明还提供了一个运算或形式化预测系统工作情况的基础。采用形式语言

构建需分析部件的形式模型，需考虑形式陈述需求并使用选定的形式逻辑准则分析模型。执

行的形式分析类型决定了模型的特性。

选定的形式分析技术目标决定了部件模型描述的详细程度。一些定制的方法则用于定位

试验不到的设计错误，同时其他方法力求保证不存在某些类别的设计错误。

1．检错

检错最常用的形式方法是模型检查。需求以判断时序逻辑形式被表述成公式形式，部件

模型就设计成了一个抽象的状态机，这样可保存需试验项的属性。试验证明程序自动进行。

若试验证明尝试失败说明了建模的部件有设计错误。试验证明失败的结果是一组输入激励序

列，它能证明部件如何未满足规定的需求。

2．错误排除

防止错误的形式方法主要基于支持试验证明理论的规范表述语言。随着表述力要求的提

高，所描述的需求也会越来越复杂，构建的部件模型也该越来越详细。然而，试验证明程序
 中国民航大学 适航审定研究中心编译

可能仅是半自动的。对于部件模型描述的适当详细程度可能是一个可综合的 HDL 描述。某些

情况下，同一模型可能同时用于仿真分析和形式分析。试验证明完成就证明了部件逻辑正确，

符合对需分析的输入信号端口的需求。

3.3.3.2 形式分析方法的解决方案

有三种可能的演绎形式分析结果：

1．试验证明成功，就完成了验证。设计保证等级取决于使用模型的逼真度。举例来说，

如果硬件模型符合一个详细设计，试验证明则提供了功能正确性保证，等效于穷举试验所提

供的保证。

2．某些情况下，失败的试验证明产生了一个明显的反例，就是说，它标识了一种能清

楚表明设计不符合需求的试验情况。这预示了设计或需求中的某些缺陷，可通过校正设计、

修正需求、表明是非物理可实现环境条件造成的，或用其他的方法来消除这些缺陷。所有的

反例都应被标识，以便解决。设计或需求的更改需反馈回相应的程序。

a.在修改设计或需求并处理由试验证明试验失败结果所发现的缺陷后，应再实施一

次试验证明，以确定修正成功处理了这些标识的问题。如此循环试验证明，直到出现成功的

试验证明试验。

b.若发现了一个反例，在未改变需求或设计的情况下就认定对其进行了处理，但工

具只是标识了一个反例（被处理过的那个），则应该修改程序以便能标识所有其他的反例。

3．最难解决的是提不出试验证明并且不能标识反例。一个可选的方法是修正设计以简

化验证工作。或者将验证程序分解，并清楚区分描述由试验证明处理的情况和需由其它方法

处理需求的情况。设计变动和衍生的需求应反馈回 FFPA。

3.3.3.3 形式分析方法数据

形式分析方法运用期间，应开发的数据包括：

1．对细节形式分析方法和采用此方法的部件或 FFPs 的描述

2．对需求的形式描述

3．部件的形式模型

4．将部件模型和需求的形式描述关联的试验证明或者能产生证明且足够详细的程序

脚本，并包括可追溯性数据中的相互关系

5．标识使用的工具和工具评估结果

6．标识验证试验实例，以及依据试验结果增补或修改的需求

7．关于依据分析所确定的 FFPs 的验证完整性等级的描述，包括不是经过更改验证试

验案例或需求来解决的分析差异性的清单，以及这种差异性可被接受的缘由。
 中国民航大学 适航审定研究中心编译

附录 D 缩写词

ALU 算术逻辑部件

ARP 航空推荐实践方法

ASIC 特殊功能集成电路

HC1 硬件控制等级 1

HC2 硬件控制等级 1

COTS 成熟商用工艺器件

EUROCAE 欧洲民航电子设备组织

FAR 联邦航空条例

FFP 功能失效路径

FFPA 功能失效路径分析

F-FMEA 功能失效模式及影响分析

FTA 故障树分析

HDL 硬件描述语言

JAR 联合航空要求

LRU 航线可更换组件

PHAC 硬件审定计划

PLD 可编程逻辑器件

PSSA 初步系统安全评估

RTCA 航空无线电技术委员会

SAE 汽车工业协会

SC 特别委员会

SSA 系统安全评估

WG 工作组