高清可复制 HB/Z 420-2014(2017) 民用飞机机载电子硬件合格审定保证指南

　　ICS 49.090 V 35

　　HB/Z 420-2014

　　民用飞机机载电子硬件合格审定保证指南

　　Assurance guidance for civil aircraft electronic hardware certification

　　2014-07-09 发布 2014-11-01 实施

　　中华人民共和国工业和信息化部 发 布

　　前 言

　　本指导性技术文件按照 GB/T 1.1-2009 给出的规则起草。

　　本指导性技术文件由中国航空综合技术研究所归口。

　　本指导性技术文件起草单位：中国航空工业集团公司第六三一研究所、中国航空综合技术研究所。

　　本指导性技术文件主要起草人：田莉蓉、朱晓飞、孔德岐、黄永葵、袁晓军、张学宏、赵博龙、母方欣。

　　民用飞机机载电子硬件合格审定保证指南

　　1 范围

　　本指导性技术文件规定了机载电子硬件概念设计、初始认证以及后续为保证持续适航进行的证后产品改进的整个过程要求，并提供了相关指南。

　　本指导性技术文件适用于与机载电子硬件设计生命周期相关的开发和认证活动。

　　本指导性技术文件涉及的机载电子硬件包含(但不局限于)以下硬件项：

　　——外场可更换单元(LRU);

　　——电路板部件;

　　——包含宏功能的用户定制的微代码部件，如专用集成电路(AISC)和可编程逻辑器件(PLD);

　　——采用集成工艺的部件，如混合电路和多芯片组件(MCM);

　　——商用货架产品(COTS)部件。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件， 仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　CCAR-25-R4 运输类飞机适航标准

　　RTCA DO -178B/EUROCAE ED -12B 机载系统和设备合格审定 中的软件考虑(Software considerations in airborne systems and equipment certification)

　　3 术语和定义、缩略语

　　3.1 术语和定义

　　下列术语和定义适用于本文件。

　　3.1.1

　　适航性 airworthiness

　　飞机、飞机系统或者组件能以安全的方式完成其预期功能的状态。

　　3.1.2

　　异常行为 anomalous behavior

　　与所定义的需求不一致的行为。

　　3.1.3

　　申请人 applicant

　　寻求合格审定机构正式批准的个人或组织。

　　3.1.4

　　评估 assessment

　　一种基于工程判断的评价。

　　3.1.5

　　可用性 availability

　　实体(硬件、系统、软件)或功能处于可使用状态的概率。

　　3.1.6

　　基线 baseline

　　作为进一步设计基础的具有标识且被批准的构型，该构型的更改必须通过更改控制程序进行。

　　3.1.7

　　合格审定 certification

　　合格审定机构对一种产品、服务、组织或个人符合要求的法律认可。合格审定包括从技术层面检查产品、服务、组织或个人的活动，并通过颁发国家法律或程序要求的证书、许可证、批文或其他文件，正式地认可其符合适用要求。具体来说，产品的合格审定包括：

　　——对产品设计进行评估，以确保产品符合适用于该类产品的标准，以证明安全性级别是可接受的;

　　——对单个产品进行评估，以确保产品符合经过认证的型号设计;

　　——依照国家法律要求颁发证书，表明与上述两条标准的符合性。

　　3.1.8

　　合格审定机构 certification authority

　　在某一地区或国家中，负责对要求的符合性进行合格审定的组织或个人。

　　3.1.9

　　审定基础 certification basis

　　由合格审定机构与申请人协商确定的特定的合格审定要求，作为飞机、发动或推进器认证的基础。它包括专用条件，对已发布的规章进行补充。

　　3.1.10

　　合格审定的信任 certification credit

　　合格审定机构对过程、产品或演示满足合格审定要求的认可。

　　3.1.11

　　更改控制 change control

　　本术语包含两层意思：

　　a) 对正式建立标识的构型项或基线的更改进行记录、评估、批准/否决以及协调的过程;

　　b) 对批准的正式建立标识的构型项或基线的更改，进行系统的评估、协调、批准/否决以及实现。 3.1.12

　　共模 common mode

　　引起两个或多个实体或功能行为异常的事件。

　　3.1.13

　　复杂硬件项 complex hardware item

　　不属于简单硬件项的硬件项。参见简单硬件项的定义。

　　3.1.14

　　符合性 compliance

　　成功地执行了所有必需的活动，且实际结果与期望或规定的结果一致。

　　3.1.15

　　协同工程 concurrent engineering

　　多个学科参与硬件设计过程的过程以确保关注到每个学科的特殊需求。

　　3.1.16

　　构型 configuration

　　完整地定义某个功能实现的构型项列表。

　　3.1.17

　　构型识别 configuration identification

　　定义和指定构型项的过程。

　　3.1.18

　　构型标识 configuration identity

　　给构型项或构型分配唯一名称作为构型识别的结果。

　　3.1.19

　　构型项 configuration item

　　由一个或多个部件、工具或数据项构成的构型管理单元。

　　3.1.20

　　构型管理 configuration management

　　本术语包含两层意思：

　　a) 构型识别以及构型标识的发布或更改的控制过程;

　　b) 用于标识和记录构型项的功能和物理特性，控制对这些特性的更改，记录并报告更改控制处理和实现状态所采用的技术、管理以及监督制度。

　　3.1.21

　　覆盖分析 coverage analysis

　　确定硬件验证过程活动对目标满足程度的过程。

　　3.1.22

　　缺陷 defect

　　与规定需求不一致的任何特性。

　　3.1.23

　　派生需求 derived requirement

　　在硬件开发过程中产生的附加需求，这些需求不能直接追踪到较高层次的需求。

　　3.1.24

　　设计工具 design tools

　　输出可构成硬件设计一部分的工具。如，ASIC 布线器(软件)或根据逻辑图或其他详细需求产生板卡和芯片的布局工具。

　　3.1.25

　　等价类 equivalence class

　　某一功能的输入空间分区，对该类代表值的测试等同于对该类其他值的测试。

　　3.1.26

　　暴露时间 exposure time

　　从上次确定硬件项能正常工作，到再次确定工作正常之间的时间间隔。

　　3.1.27

　　失效 failure

　　系统或系统部件不能在规定的限制内完成要求的功能。当遇到故障时，可能产生失效。

　　3.1.28

　　失效情况 failure condition

　　由于不正确的行为和环境条件导致的一个或多个失效，直接或间接地对飞机及其乘员造成的影响。

　　3.1.29

　　失效影响 failure effect

　　(1)对实体失效结果的行为的描述。(2)失效模式对系统或实体的行为、功能或状态带来的后果。

　　3.1.30

　　失效模式 failure mode

　　实体发生失效的方式。

　　3.1.31

　　失效率 failure rate

　　在规定的条件下，实体的失效总数，除以实体总的加电小时。

　　3.1.32

　　首件 first article

　　为验证制造图纸、工具和规程提交检验的个体。

　　3.1.33

　　首件检验 first article inspection

　　过程保证检验，验证硬件的制造符合制造过程文件。该过程在代表首次下线构型的硬件项上进行，作为批量生产批准的前提。

　　3.1.34

　　功能失效路径 functional failure path

　　可能引起实现某功能的硬件或与该功能相关硬件行为异常的一组特定的相互依赖的电路。

　　3.1.35

　　功能路径 functional path

　　实现某一功能的一组特定相互依赖的电路。

　　3.1.36

　　硬件项 hardware item

　　物理存在的一个硬件实体。通常指 LRU、电路板组装件、电源和部件。

　　3.1.37

　　硬件分区 hardware partitioning

　　把实现功能的硬件(包括冗余在内)进行物理分离和隔离，以提高可靠性和安全性的一种方法。这种措施可防止由于共模故障带来的失效影响。

　　3.1.38

　　完整性 integrity

　　用来度量实体执行预定功能可信度的属性。

　　3.1.39

　　实体 item

　　硬件部件、系统或软件的统称。

　　3.1.40

　　符合性方法 means of compliance

　　申请人所采用的、用来满足审定基础中所述飞机或发动机需求的方法。例如，声明、图纸、分析、计算、测试、仿真、检验和环境鉴定。适当时，可使用合格审定机构发布的咨询材料。

　　3.1.41

　　件号 part number

　　一组用来标识构型项以及构型标识的数字、字母或其他字符。

　　3.1.42

　　策划过程 planning process

　　定义和协调硬件设计和支持过程活动的过程。

　　3.1.43

　　初步系统安全性评估 preliminary system safety assessment

　　基于功能性危害评估和失效状况分类，对所提出的系统架构及其实现进行系统的评估，以确定在该架构中所有项的安全性需求。

　　3.1.44

　　过程 process

　　一组相互关联的活动，用来产生规定的输出或产品。

　　3.1.45

　　过程保证 process assurance

　　过程保证的目的是确保策划得到了执行，硬件设计生命周期过程的目标得到满足，并且各项活动已经完成。

　　3.1.46

　　产品 product

　　根据一组定义好的需求产生的实体。

　　3.1.47

　　产品服务经历 product service experience

　　硬件在已知环境中的工作时间以及失效记录。

　　3.1.48

　　制造 production

　　通过文档化的和受控的过程生产产品。

　　3.1.49

　　发布 release

　　正式将硬件项的数据置于构型控制的行为。

　　3.1.50

　　可靠性 reliability

　　实体在规定条件和指定时间间隔下，能执行其预期功能的概率。

　　3.1.51

　　逆向工程 reverse engineering

　　在特殊环境下，通过研究结构、功能和性能，重新实现某种硬件项。

　　3.1.52

　　健壮性缺陷 robustness defects

　　在应力条件和服务期没有超出设计极限的情况下，导致硬件失效或不正确操作的缺陷。这些缺陷的后果可能包括对环境应力敏感和在服务期中不稳定。

　　3.1.53

　　安全 safety

　　风险低于边界风险的状态。边界风险是可接受风险的上限，对于某一技术过程或状态边界是确定的。风险是通过出现的频度或概率以及预测的损害或伤害来定义的。

　　3.1.54

　　类比 similarity

　　将系统与申请人在以前飞机中认证过的系统在特性和应用方面进行比较，并假设系统的任何部分都不会因环境或安装因素而具有更大的风险，并且运行强度绝不会比类比的系统更重。

　　3.1.55

　　简单硬件项 simple hardwar item

　　在所有可预见的工作条件下，通过确定性测试和分析的合理组合，可以确保功能的正确执行而没有异常行为，则认为该硬件项是简单的。

　　3.1.56

　　仿真/模拟器 simulator

　　在硬件验证中使用的设备、计算机程序或系统， 它们与给定系统一样，能接受相同的输入，产生相同的输出。

　　3.1.57

　　支持过程 supporting process

　　用来支持设计过程的过程，包括确认、验证、构型管理、过程保证和认证联络。

　　3.1.58

　　系统架构 system architecture

　　为实现系统需求而选择的硬件和软件结构。

　　3.1.59

　　系统 system

　　组织在一起能完成一个或一组规定功能的软硬件组件的集合。

　　3.1.60

　　系统安全性评估 system safety assessment (SSA)

　　对指定的系统进行系统的全面的评估，以证明满足了相关安全性需求。

　　3.1.61

　　工具评估 tool assessment

　　对硬件项的设计和验证中使用的工具是否能够正确地执行其功能进行的评估活动，为符合硬件项要实现功能的设计保证级别提供信任。

　　3.1.62

　　工具鉴定 tool qualification

　　为工具在特定机载系统环境下使用获得合格审定机构认可需要的过程。

　　3.1.63

　　可追溯性 traceability

　　在硬件项或过程之间某种确定的联系，如某一需求和该需求来源之间，或某种验证方法与其基本需求之间。

　　3.1.64

　　干扰 upset

　　特指由外部事件，如雷电或其他环境事件引起的干扰。

　　3.1.65

　　确认 validation

　　确定需求是正确和完整的过程。

　　3.1.66

　　验证 verification

　　对需求实现的评估，以确定需求得到满足。

　　3.2 缩略语

　　下列缩略语适用于本文件。

　　ALU——算术逻辑单元(arithmetic logic unit)

　　ASIC——专用集成电路(application specific integrated circuit)

　　HC1——1 类硬件控制(hardware control category 1)

　　HC2——2 类硬件控制(hardware control category 2)

　　COTS——商用货架产品(commercial-off-the-shelf)

　　EUROCAE——欧洲民用航空设备组织(european organization for civil aviation equipment)

　　FFP——功能失效路径(functional failure path)

　　FFPA——功能失效路径分析(functional failure path analysis)

　　FHA——功能危害评估(functional hazard assessment)

　　F-FMEA——功能失效模式与影响分析(functional failure modes and effects anaysis)

　　FTA——故障树分析(fault tree analysis)

　　HDL——硬件描述语言(hardware description language)

　　LRU——外场可更换单元(line replaceable unit)

　　PHAC——硬件认证计划(plan for hardware aspects of certification)

　　PLD——可编程逻辑器件(programmable logic device)

　　PSSA——初步系统安全性评估(preliminary system safety assessment)

　　RTCA——航空无线电技术委员会(radio technical commission for aeronautics)

　　SSA——系统安全性评估(system safety assessment)

　　4 系统和硬件设计保证过程的关系

　　4.1 概述

　　硬件设计保证应追溯到系统层面，在系统层面级将系统功能分配给硬件，并且指定其对应的系统开发保证级别。

　　一个单独的系统功能可以分配给硬件项、软件项或者硬件与软件的组合。为了确定满足这些安全性需求所需的可靠性级别以及保证级别，应从系统层面、软件层面以及硬件层面提出与功能相关的安全性需求。

　　图 1 示出了机载系统和设备的系统开发过程与安全性评估、硬件开发、软件开发过程之间的相互关系。

　　在图中，有 4 个重叠的区域：安全性/硬件、安全性/软件、硬件/软件和安全性/硬件/软件。这些重叠区域表明了这些过程之间的相互关系和相互作用，即一个系统需求可能会产生这个区域内的需求和多个过程的设计保证指南。例如， 包含安全性需求的硬件功能将涉及安全性评估过程和硬件设计生命周期过程。

　　这些重叠的区域表明在各个过程之间需要协同交互作用，来确保满足系统功能的保证需求。关于系统或软件保证过程，本指导性技术文件不作规定，然而，为了配合硬件功能的设计保证，申请者可能希望利用系统或软件过程的活动所提供的保证。

　　这些相互关系和相互作用将在 4.2.1 至 4.2.3 中详细描述。

　　图 1 机载系统、安全性评估、硬件和软件过程之间的相互关系

　　4.2 信息流

　　4.2.1 从系统开发过程到硬件设计生命周期过程的信息流

　　这类信息流可能包括：

　　a) 分配给硬件的设计和安全性需求;

　　b) 每一个功能的设计保证级别，在条件允许的情况下，还应包括相应的需求和失效状况;

　　c) 分配的硬件功能失效概率和风险暴露时间;

　　d) 硬件/软件接口描述;

　　e) 安全策略要求和设计约束，如可测性、设计方法和硬件结构;

　　f) 要求在硬件验证中进行的系统验证活动;

　　g) 分配给硬件的安装、环境影响及环境适应性需求;

　　h) 可能影响需求的集成问题报告，这些报告可能是由一些活动产生的，如系统验证、系统需求生成或 SSA。

　　4.2.2 从硬件设计生命周期过程到系统开发过程的信息流

　　这类信息流可能包括：

　　a) 需求实现，如机械图、原理图和零部件列表。

　　b) 硬件派生需求，这些需求可能对任何已分配的需求产生影响。

　　c) 实现架构，包括故障容忍边界。

　　d) 要求在硬件设计生命周期中进行的系统验证与确认活动的证据。

　　e) 产品安全性分析数据，如：

　　1) SSA 过程关注的硬件功能失效概率和失效率;

　　2) 共模故障分析;

　　3) 隔离边界和通用的故障缓解策略;

　　4) 与系统需求有关的针对潜在(故障)的分析数据，比如，硬件有关故障监控，故障检测时间间隔以及不可检测故障的规定。

　　f) 要求在系统验证中进行的硬件验证活动。

　　g) 需要确认的分析所需的关于安装要求和环境条件的假设和分析方法。

　　h) 可能会影响系统、软件或分配给硬件需求的问题或更改报告。

　　4.2.3 硬件设计生命周期过程与软件生命周期过程之间的信息流这类信息流可能包括：

　　a) 硬件/软件综合所需要的派生需求，如协议的定义、时序约束以及硬件和软件之间接口的寻址机制;

　　b) 需要协同进行的硬件和软件验证活动;

　　c) 识别出的硬件与软件不兼容的地方;

　　d) 安全性评估数据，这些数据应同时提供给系统过程。

　　4.3 系统安全性评估过程

　　系统安全性评估有三个过程：功能危险性评估(FHA)，初步系统安全性评估(PSSA)和系统安全性评估(SSA)。这些过程用来确定适用于系统开发保证过程的系统安全性目标， 并且用来确定系统功能是否达到了安全性目标。

　　SSA 过程应将安全性目标转换为系统和设备的安全性需求。这些需求应包含系统和设备功能与结构的基本安全性目标和安全性属性。SSA 过程和系统开发过程将这些安全需求分配给硬件。

　　系统开发保证级别划分为 A-E 五级，见表 1，分别与五类失效状况相对应，即灾难性的、危险的 /严重的、重大的、较轻的和无影响的。表 1 将硬件设计保证级别与五类失效状况相关联，并给出了硬件失效状况和其相应的设计保证级别的定义。每个硬件功能的硬件设计保证级别通过 SSA 过程来确定， SSA 过程使用 FHA 来确定潜在的危险，PSSA 过程将安全性需求和相应的失效状况分配给硬件实现的功能。

　　在整个硬件设计生命周期中，在安全性、系统和硬件过程之间， 会存在迭代反馈，以保证设计和实现的硬件满足所分配给硬件的系统安全性、功能及性能需求。

　　4.4 硬件安全性评估

　　4.4.1 概述

　　硬件安全性评估与 SSA 过程结合在一起进行，并支持 SSA 过程。这个安全性过程的目的在于证明系统和设备，包括硬件，已经满足适用的飞机认证要求的安全性需求。

　　硬件安全性评估根据系统过程分配给硬件的安全性、功能和性能需求， 确定每个功能的硬件设计保证级别，并帮助确定恰当的设计保证策略。

　　表 1 硬件设计保证级别定义及其与系统开发保证级别的关系

　　表 1 硬件设计保证级别定义及其与系统开发保证级别的关系(续)

　　4.4.2 硬件安全性评估考虑

　　硬件的设计者，可以通过适当的设计保证策略，来表明符合所分配给硬件的安全性需求和符合硬件设计保证级别。

　　所有硬件项可以采用统一的设计保证级别和策略，或者对硬件项中的独立的功能失效路径(FFP)进行评估，以采用混合的设计保证级别或设计保证策略。功能失效路径分析(FFPA)可以为将部分硬件定义为较低的设计保证级别提供依据，或采用不同技术或产品服务历史实现的不同功能。

　　注：在附录 B 描述了FFPA。尽管是为了解决附录 B 的问题而写的，这种分析方法可用于任何设计保证级别。

　　如果一个硬件项包含的功能各自具有不同的设计保证级别，可以采用下列两种方法之一：

　　a) 所有硬件项采用最高设计保证级别。

　　b) 如果单个硬件项的功能、接口和共享资源可以避免较低设计保证级别功能的不利影响， 可以按照硬件安全性评估中所定义的各自的硬件设计保证级别，单独地进行设计保证。共享资源的设计保证应是具有最高级别的功能的设计保证级别。

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

　　a) 迭代的硬件安全性评估和设计应确定派生的硬件安全性需求，并且保证分配给硬件的系统安全性需求和派生需求都得到满足。

　　b) 这些派生需求应包括对硬件结构、电路和部件以及异常行为保护的安全性需求， 包含具体硬件结构和功能的安全性属性，如：

　　1) 电路或部件余度;

　　2) 电路或部件之间的分离或电气隔离;

　　3) 电路或部件之间的非相似性;

　　4) 电路或部件的监控;

　　5) 保护或重构机制;

　　6) 允许电路和部件随机失效和潜在失效的失效率和失效概率;

　　7) 使用或安装限制;

　　8) 干扰预防与管理及干扰恢复。

　　c) 硬件设计保证过程与硬件安全性评估应联合确定每个功能的具体符合方法及设计保证级别，并且确定已经达到可接受的硬件保证级别。

　　注：硬件的异常行为可能由硬件项内部的随机故障或设计错误引起，也可能由硬件干扰引起。

　　对于一个硬件项的功能，硬件设计者可以选择更高的硬件设计保证级别，比如，预计在一个有较高硬件保证级别要求的装置中复用该硬件项功能。

　　硬件安全性评估可以使用不同的定性或定量评估的方法。这些方法包括故障树分析(FTA)、共模分析、失效模式和影响分析以及适用于随机故障定量评估的统计可靠性分析方法。

　　4.4.3 随机硬件故障的定量评估

　　统计的失效评估和预测方法，是基于硬件失效等级、余度、分离和隔离、失效模式统计、概率分析、部件降额、应力分析和制造过程控制，已证明是对硬件随机失效进行定量风险因素评估的可行方法。

　　4.4.4 硬件设计错误和干扰的定性评估

　　与硬件随机失效不同，设计错误和一些类型的干扰都是不能用统计方法预测的，并且二者都可能以共模故障的形式，跨越余度边界。应对要采用的余度管理技术和定量分析方法进行选择，以便在必要时，可以排除或缓解潜在的共模故障以及干扰的影响。

　　尽管定量评估比较困难，设计错误和干扰引起的安全性风险还是可以通过实际应用定性的安全性评估方法来有效地评估。分析技术，如故障树分析、共模分析、以及功能失效模式和影响分析(F-FMEA)，是基本的定性分析方法，可以用来处理硬件设计错误和干扰。尤其是这些方法可以确定设计错误和干扰的潜在影响，并可以帮助确定排除和缓解设计错误和干扰的方法。通过使用这些方法， 硬件安全性评估可有助于确定应使用的硬件设计保证策略，并且可在整个硬件设计过程中重复使用，来定性地确定选择的策略所达到的保证级别。

　　4.4.5 硬件失效状况分类的设计保证考虑

　　随着系统失效状况严重度的增加，保证相关失效状况已经缓解的所需的硬件设计保证逐渐增多。对于所有的设计保证级别，应开发一种方法或策略，以确保达到合适的设计保证级别。图 2 给出了开发适当的设计保证策略的决策过程。

　　指南包括：

　　a) 对于硬件实现的 A 级或 B 级功能，设计保证考虑应处理硬件功能的潜在异常行为和潜在设计错误。

　　b) 在开发要实现的每一个硬件功能的设计保证策略时，可以使用图 2 给出的决策过程。

　　c) 对于 A 级和 B 级功能，除应用第 5 章到第 13 章提出的指南外，还应使用附录 B 描述的策略。

　　d) 设计保证策略应根据硬件结构和用途以及选用的硬件实现技术来选择不同的技术、部件选择和部件用途，提供不同程度的硬件设计生命周期信息，以及应对设计错误及其影响的不同程度内在防护措施。在同一个硬件项中，最合适的设计保证方法因功能路径的不同而变化。

　　图 2 决策与活动框中的字母，对应于图下面的编号条目，为决策或活动提供进一步的阐述。

　　a) 开始评估过程。对于所有的设计保证级别， 应开发一种方法或策略，来确保设计保证的适当级别。

　　b) 确定 FFP 设计保证级别。对于每一个已识别的硬件项，确定与硬件项相关的 FFP 和设计保证级别，并形成文件。使用常规的安全性评估技术， 确定属于已识别的 A 级或 B 级 FFP 的硬件电路。

　　c) FFP 的硬件实现是简单的还是复杂的?对于硬件设计保证 A 级或 B 级的 FFP，按照复杂及简单部件的定义确定硬件是简单的还是复杂的。

　　图 2 选择硬件设计保证策略的决策过程

　　d) 为 A 级或 B 级复杂 FFP 开发设计保证策略。如果 FFP 是复杂的，并且是 A 级或 B 级，使用附录 B 描述的附加策略来确定适当的设计保证策略、相应的实现思想和错误缓解方法。对于每一个 A 级或 B 级的 FFP，应使用高级的分析、产品服务经历或结构化缓解方法来确定设计保证策略。对一个要实现的 A 级的 FFP，如果所选择的方法不能完全缓解潜在失效或异常行为，可能需要一种以上的方法。

　　e) 策略是否足够?确定设计保证策略是否存在不足?如果策略存在不足，或期望可得到的数据可能存在不足，应通过提出附加的设计保证、实现或结构性策略，来修改策略以消除不足。一旦设计保证策略可以接受，应将每个 FFP 的设计保证过程形成标准。策略还应阐述认证当局参与的情况，如进度里程碑、项目评审和监督活动。

　　f) 形成适用的故障-安全方面的文件。确定硬件项适用的故障-安全设计结构和特性， 并进行分析，以满足系统可用性和完整性需求。故障-安全设计情况和相关的共模分析、概率分析、结构和其他特性应形成文件。

　　g) 形成设计保证方法和策略的文件。适用的设计保证方法和策略， 应包括在系统认证计划或硬件认证计划(PHAC)文件中，并获得认证当局的批准。

　　h) 实现方法。按照已批准的计划中所定义的适用的设计保证方法， 实现硬件设计，并将符合已批准的计划和策略的证据形成文件。

　　5 硬件设计生命周期

　　5.1 概述

　　本节概要介绍将在第 6 章到第 11 章论述的硬件设计生命周期。本指导性技术文件并不规定首选的生命周期模型，也不对组织结构形式提出要求。硬件设计生命周期既适用于新系统或设备的开发， 也适用于现有系统或设备的更改。每个工程的生命周期应该基于由该工程特性(如需求稳定性、使用的先前开发的硬件及硬件设计保证级别)决定的过程选择和安排。硬件设计生命周期过程可以是迭代的，即由于增量开发以及过程间的反馈而形成的进入，再进入和更改过程。

　　5.2 硬件设计生命周期过程

　　硬件设计生命周期过程包括：

　　a) 第 6 章描述的硬件策划过程，定义和协调项目的硬件设计活动和支持过程。

　　b) 第 7 章描述硬件设计过程，生成设计数据，产生硬件项。这些过程包括： 需求获取、概要设计、详细设计、实现和生产转化。

　　c) 第 8 章到第 11 章描述支持过程，包括确认、验证、构型管理、过程保证和认证联络。这些过程生成保证硬件设计生命周期及其输出的正确性及可控性的硬件设计生命周期数据。它们通常与策划和设计过程同时进行。

　　5.3 转换准则

　　当开发的一个硬件项的不同子项目处于不同开发阶段时，需要一种方法对设计过程进行合理控制，以避免在前一个过程的所有要素完成之前就开始下一个过程。转换准则可以用在关键过程点， 定义用于评估从一个过程转换到另一个过程的最低数据要求，策划过程的分析应明确转换准则的使用。没有必要对在计划中定义的每一组过程之间都建立转换准则。转换准则的选择应关注对安全性的影响。例如， 在为认证批准而进行功能验证之前，该功能的需求应形成文件，并且该功能的实现应受构型管理控制。

　　转换准则应记录在硬件计划中。转换准则的使用不隐含任何特殊的生命周期模型， 也不限制如快速原型和协同工程等开发策略。

　　6 策划过程

　　6.1 概述

　　本节描述用来控制硬件项开发的硬件策划过程。本过程产生硬件计划， 这些计划可包含在一份或多份文件中。如果使用多个文件， 主计划应包含对支持文件的适当引用，包含如构型管理或过程保证等具体硬件设计生命周期过程的标准文件。

　　6.2 策划过程目标

　　硬件策划过程的目的在于定义一系列的方法，通过这些种方法能将功能和适航需求转化为一个硬件项，并能为该硬件项提供足够数量的、可接受的保证证据，以证明该硬件项将安全地实现其预期功能。硬件策划过程的目标包括：

　　a) 定义硬件设计生命周期的过程;

　　注：在计划中可以包括活动、里程碑、输入、输出和组织责任。

　　b) 选择并定义标准;

　　c) 选择或定义硬件开发和验证环境;

　　d) 向合格审定机构提供满足硬件设计保证目标的符合性方法建议，包括使用 4.4.5 中指南确定的

　　策略。

　　注：新的和正在发展的技术、工具和过程可能要求更改策划过程的细节， 因而，灵活性是策划过程的一个关键因素。

　　6.3 策划过程活动

　　策划过程的指南包括：

　　a) 应确定硬件设计生命周期过程，包括转换准则，适用时，还包括单个过程之间的相互关系，如它们的顺序及反馈机制。

　　b) 应确定并解释所提出的设计方法。包括对期望的硬件设计的考虑和所提出的验证方法的基本原理。

　　c) 应标识工程要使用的任何硬件设计标准和标准的可接受偏差。这些标准包括通用的质量标准、公司或项目专用标准。在新设计和新工艺中使用现有标准时，申请人和硬件开发者应意识到，标准可能不适用。设计约束、与系统需求冲突或与新的技术不兼容可能导致必须与现有标准的偏离。如果使用这些标准，策划过程应审查哪些偏离是可以接受的。

　　注：标准通过提供从以往的开发中确定的已验证过的工程经验汇编，帮助降低遗留设计错误的概率。

　　d) 应确定协调硬件设计过程与支持过程的方法，尤其应关注与系统、软件和飞机认证相关的活动。注：协调可以采用进度表的形式，表明实现本指导性技术文件描述的过程目标的事件的里程碑。

　　e) 应定义每一个硬件过程及相关的支持过程的活动。这些定义应使硬件设计过程及相关的支持过程达到可控的程度。

　　f) 应选择设计环境，包括用来开发、验证和控制硬件项及生命周期数据的工具、过程、软件和硬件;

　　1) 如果期望获得组合工具使用的认证批准，在相应的计划中应规定工具操作的顺序。

　　2) 设计环境可能影响一个产品的设计。13.5 为工具的评估并确定何时必须进行工具鉴定提供了指南。

　　g) 如果与原计划的偏离是必要的，并且这些偏离影响到合格审定，应标识偏离原计划的过程。

　　h) 应描述用来识别、管理和控制硬件、相对应的基线和硬件设计生命周期数据的方针、过程、标准和方法。

　　i) 如果打算对所有或部分硬件设计生命周期进行转包时，申请人应在硬件计划中标识确保设计保证目标可以实现的方法。

　　j) 应描述用于保证实施的硬件设计过程的方针和过程。

　　k) 在 PHAC 中应描述验证过程独立性、过程保证独立性及相关组织的职责。

　　l) 应记录满足本指导性技术文件中目标的方法，并在过程早期与合格审定机构沟通。这些方法应在 PHAC 中记录。

　　注：鼓励对这些方法的任何更改进行及时的协调，以尽可能地增大将形成的认证数据作为满足设计保证需求的合适证据的接受度。

　　7 硬件设计过程

　　7.1 概述

　　硬件设计过程的输出是满足系统分配给硬件的需求的硬件项。本章描述 5 个主要过程，如图 3 所示。这些过程是需求获取、概要设计、详细设计、实现和生产转化。这些设计过程可应用于硬件项的任何层次，如 LRU、电路板部件和 ASIC/PLD。以下章节描述每一个过程、目标及应进行的用于降低影响安全性的设计和实现错误概率的相关活动。对每个过程进行策划， 并且在硬件设计计划中记录过程细节是非常重要的。

　　图 3 硬件设计生命周期

　　每个过程以及过程之间的交互是可迭代的。对每次迭代， 应考虑和评估每个过程更改的结果对以前的迭代结果的影响。

　　注：在整个设计过程中，用文件记录过程，如设计文件、设计评审记录或问题报告是一个好的工程经验。

　　当前实践中提供了许多不同的方法，图形的、数学的、数据库或基于文本的， 来描述需求和设计实现，例如逻辑图、硬件描述语言(HDL)、状态图、布尔表达式和图形化方法。

　　注：一些描述方法适用于一个具体的过程或一组过程，如需求获取、概要设计或详细设计; 一些描述方法适合于高效地实现具体的实现技术。不管采用什么设计描述方法，应提供支持设计保证级别的证据。

　　对于所使用的每一个设计描述方法，应考虑以下事项：

　　a) 不管使用什么描述方法或描述方法的组合，都应遵守本指导性技术文件的指南。

　　b) 设计描述方法应保证硬件项复制的一致性。

　　c) 设计描述的微小更改可能对设计实现产生大的影响。应处理这些更改对设计保证的影响。

　　d) 在设计数据的基线建立之后，设计描述环境或方法可能会改变。如果出现这种情况， 应处理这些更改对设计复制的影响。

　　HDL 设计描述方法使用基于编码文本的技术，形式上与软件描述方法相类似。这种外观上的相似性，可能误导人们试图对 HDL 或其他类似的硬件描述语言的设计描述直接采用软件验证方法。本指导性技术文件提供的指南为使用 HDL 描述方法的设计提供设计保证。

　　贯穿本指导性技术文件所描述的结构化过程，适用于包括 ASIC 和 PLD 的复杂硬件设计。作为例子，表 2 给出了典型的 ASIC/PLD 过程与本指导性技术文件图 3 描述的过程的映射。

　　表 2 典型的 ASIC/PLD 过程映射

　　7.2 需求获取过程

　　7.2.1 概述

　　需求获取过程识别和记录硬件项的需求，包括由于硬件项结构、工艺的选择、基本的和可选的功能、环境的或性能需求所产生的派生需求，以及由系统安全性评估所施加的需求。这个过程可以是迭代的，因为在设计过程中，会产生附加的需求。

　　7.2.2 需求获取目标

　　需求获取过程的目标是：

　　a) 对需求进行了识别、定义并形成了文件。包括 PSSA 过程所分配的需求和来自硬件安全性评估过程的派生需求。

　　注：验证结果到硬件需求的可追溯性在第 6 章陈述。期望在需求获取过程中建立这种可追溯性的方法。

　　b) 产生的派生需求反馈给相应的过程。

　　c) 需求遗漏和错误由相应的过程来解决。

　　7.2.3 需求获取活动

　　需求获取活动形成一个迭代的过程，帮助保证需求与设计实现、系统需求和软件需求的一致性。

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

　　a) 应形成分配给硬件项的系统需求文件，包括识别出的需求，如功能和性能，以及结构性考虑，如隔离、机内测试(BIT)、测试能力、外部接口、环境、测试和维护性考虑、功耗和物理特性。

　　b) 应识别来自 PSSA 过程、与硬件项相关的安全性需求，可能包括：

　　1) 硬件所实现功能的设计保证级别;

　　2) 功能故障或丧失的概率要求;

　　3) 所选择的、用来满足功能分配的硬件结构和功能的安全性属性(如 4.4.2 所述)。

　　c) 应识别由生产过程、标准、程序、工艺、设计环境和设计指南带来的设计约束。

　　d) 应确定硬件实现所需的派生需求。应单独识别从硬件安全性评估派生出的安全性需求。注：派生的需求可能涉及的情况如：

　　1) 一些专门的约束，用来确保较高设计保证级别的功能，可以容忍较低设计保证级别的功能异常，如较低设计保证级别的功能的接口;

　　2) 典型的和满量程数据值的数据输入范围，以及数据字或控制寄存器高低位状态;

　　3) 上电复位和其他复位状态;

　　4) 电源电压和电流要求;

　　5) 时间相关功能的性能，如滤波器、积分器和延时器;

　　6) 可能的状态机转换准则，不论是不是可预期的;

　　7) 在通常和最坏条件下，信号时序关系或电气条件;

　　8) 信号噪声和串扰;

　　9) 异步逻辑电路中的信号毛刺;

　　10) 控制未使用功能的专门约束。

　　e) 派生需求应反馈给 SSA 过程，以便评估其对系统需求的影响。

　　f) 需求数据应以定量的形式形成文件，需要时应提供公差，但不包括设计或验证解决方案的描述。

　　g) 本过程发现的需求遗漏或错误，应提供给系统开发过程。

　　h) 需求(包括为满足 PSSA 需求而产生的需求)，应可追溯到其上一层次的需求。应识别派生的需求，并尽可能地在整个需求层次中具有可追溯性。

　　注：在需求获取过程中，可以对分配给硬件的安全性需求进行系统级确认。派生硬件需求的确认在 8.2 描述。

　　7.3 概要设计过程

　　7.3.1 概述

　　概要设计过程输出高层设计原理，可用来评估以确定最终的设计实现满足需求的可能性。概要设计过程可以使用诸如功能块框图、设计和结构描述、电路板装配外形和机架草图等形式来完成。

　　7.3.2 概要设计目标

　　概要设计的目标是：

　　a) 所开发的硬件项概要设计与其需求一致;

　　b) 所产生的派生需求反馈给需求获取或其他相应的过程;

　　c) 需求遗漏和错误提交给相应的过程进行纠正。

　　7.3.3 概要设计活动

　　概要设计活动指南包括：

　　a) 应产生硬件项的高层描述，可以包括：

　　1) 与安全性相关的结构约束，包括处理设计错误以及功能、部件超限使用、可靠性和健壮性的缺陷所需的约束;

　　2) 对软件或其他系统部件的任何实现约束的识别。

　　b) 应识别主要部件，应确定其影响硬件安全性需求的方式，包括未使用功能的影响。

　　c) 派生的需求包括接口定义，应反馈给需求获取过程。

　　d) 需求遗漏和错误应反馈给相应的过程进行纠正。

　　e) 应识别需要提供的可靠性、可维护性和测试特性。

　　注：推荐的做法是，所有相关方应就概要设计目标是否得到满足达成共识。一般情况下，使用设计评审来达成共识。

　　7.4 详细设计过程

　　7.4.1 概述

　　详细设计过程以硬件项需求和概要设计数据为基础，输出详细设计数据。

　　7.4.2 详细设计目标

　　详细设计过程的目标是：

　　a) 应根据硬件项需求和概要设计数据开发详细设计;

　　b) 派生需求反馈给概要设计或其他相应的过程;

　　c) 需求遗漏或错误反馈给相应的过程进行纠正。

　　7.4.3 详细设计活动

　　详细设计活动指南包括：

　　a) 硬件项的详细设计数据应基于需求和概要设计数据来产生，详细设计数据可能包括装配和互连数据、部件数据、HDL、测试方法和硬/软件接口数据。

　　注：在详细设计过程中，非正式地使用验证方法，来帮助在这个过程中进行技术决策。例如： 类似逻辑时序和参数变化等的设计参数分析，可提供设计决策的依据信息。

　　b) 必要时应采用结构设计技术，这些技术可能包括对适当功能建立安全性监控器、功能与安全性监控器的非相似性、影响安全性的设计错误排除和容错设计。

　　c) 应在需要的地方设计测试特性，以保证可以对安全性需求进行验证。

　　注：重要的是，开发设计应保证确定的安全性特性不仅能在硬件设计生命周期中可以验证，而且应作为验收

　　测试和返场服务测试的一部分。

　　d) 应对未使用的功能进行评估，来确定其对安全性的潜在影响。不利影响应得到处理。

　　e) 应确定必须遵循的可能影响安全性的硬件项设计、安装或操作约束。

　　f) 在详细设计过程中产生的派生需求，应反馈给概要设计或其他相应的过程。

　　g) 在详细设计过程中发现的需求遗漏和错误，应反馈给概要设计或其他相应的过程进行纠正。

　　7.5 实现过程

　　7.5.1 概述

　　实现过程使用详细设计数据生成硬件项，作为测试活动的输入。

　　7.5.2 实现目标

　　实现过程的目标是：

　　a) 使用典型的制造过程实现硬件详细设计，生成硬件项;

　　b) 硬件项的实现、装配和安装数据完整;

　　c) 派生的需求反馈给详细设计过程或其他相应的过程;

　　d) 需求遗漏或错误反馈给相应的过程进行处理。

　　7.5.3 实现活动

　　实现活动指南包括：

　　a) 应使用设计数据，并在可能的条件下使用实际生产资源来生产硬件项;

　　b) 在实现过程中产生的派生需求应反馈给详细设计过程和其他相应的过程;

　　c) 在实现过程中发现的需求遗漏和错误应提供给相应的过程进行纠正。

　　7.6 生产转化过程

　　7.6.1 生产转化目标

　　在这个过程中，应检查制造数据、测试设备和常规的资源， 以确保其在生产中可用性和适宜性。生产转化过程使用实现和验证过程的输出，将产品转入生产制造阶段。

　　这个过程的目标是：

　　a) 建立包括支持硬件项复制一致性所需的全部设计和制造生产数据基线;

　　b) 识别与安全性相关的制造需求并形成文件，建立制造控制系统;

　　c) 派生需求反馈给实现过程或其他相应的过程;

　　d) 错误和遗漏反馈给相应的过程进行纠正。

　　7.6.2 生产转化活动

　　生产转化活动指南包括：

　　a) 基于设计数据构型准备制造数据。

　　b) 应检查制造数据的完整性及与构型的设计数据的一致性。

　　注：本指导性技术文件不对生产文件应增加的内容进行规定。

　　c) 应评价在产品转化过程中加入的任何更改或改进，以确保其遵循所有的产品需求，尤其是安全性需求。任何不符合顾客或认证需求的更改均应通过相关组织的批准。

　　d) 有关安全性的制造生产需求应明确地定义，使它们在生产过程中得到控制。

　　e) 应确定开发验收测试标准所需要的数据。

　　f) 确定的遗漏和错误应反馈给相应的过程进行纠正。

　　7.7 验收测试

　　验收测试表明制造生产、更改或维修后产品的性能符合该部件的关键属性，这些属性是认证的基础。关键属性可表明产品能满足开发需求，通过工程判断来选择。

　　注：所创建的产品的构型控制不是验收测试活动所要执行的功能。在本指导性技术文件第 9 章描述的构型管理计划，应描述申请人计划如何进行这个活动。

　　本指导性技术文件的范围包括确定验收测试标准，包括合格判据，但不包括生产活动(包括验收测试)。

　　注：验收测试不是试图验证每一个产品部件的所有需求。

　　子项目测试可以作为验收测试的一部分。

　　验收测试标准应保证：

　　a) 识别必要的电气测试。

　　b) 必要时确定环境筛选试验项目。

　　c) 验收测试应覆盖满足安全性需求的设计内容。应识别测试没有覆盖的安全性相关的项目或子项目，并提供其他保证方法。这些方法可以包括分析、设计控制、统计过程控制或其他合适的方法。

　　7.8 批量生产

　　这个过程在本指导性技术文件中不作规定，为体现生命周期的完整性，这里对该过程影响设计保证的要素进行简要描述。

　　该过程按照符合生产数据和需求的既定流程，重复生产硬件项。

　　需要考虑的事项包括：

　　a) 生产过程或设计的更改管理应保证更改不会对现有的安全性、认证或与需求的符合性产生负面影响。

　　注：除在本指导性技术文件正文提出的指南之外，在 13.2.1 包含有对先前开发硬件的更改。关于部件停产，参见 13.3。

　　b) 与更改相关的所有文件更新，应符合已批准的构型管理计划。

　　8 确认与验证过程

　　8.1 概述

　　本节描述确认过程和验证过程。确认过程保证硬件项派生需求， 验证过程保证硬件项的实现满足包括派生需求在内的所有硬件需求。

　　8.2 确认过程

　　8.2.1 确认过程目标

　　确认过程的目的在于通过客观的和主观的过程相结合的方法，保证派生需求相对于分配给硬件项的系统需求是正确的和完整的。确认可以在硬件项可用之前或之后进行，但通常是在设计生命周期中进行。

　　注：经验证明，注重需求的开发与确认可以在开发周期的早期发现一些不十分明显的错误或遗漏，减少后续的重新设计或硬件性能不足。

　　这里讨论的确认过程的目的不在于确认系统分配的需求，因为这些需求的确认属于系统过程的一部分，另外也不是所有硬件项派生的需求都需要确认。

　　影响系统安全性及分配给系统其他部件功能需求的设计决策，属于需要确认的派生需求。另外， 约

　　束后续设计任务的设计决策和假设，应作为派生需求进行确认。

　　需要确认的派生需求，应根据分配给硬件项的系统需求进行确认。不能追溯到高一级需求的派生需求，应根据派生出这些需求的设计决策进行确认。

　　注：对执行某个具体功能的电路提供一个单独电源的设计决策，可能导致产生指导电源设计的需求。这些派生的需求可能包括基于失效状况的安全性需求，这些失效状况可以由从电源接收电能的电路所支持的功能故障或失效产生。这些需求应进行确认。

　　设计决策成为派生需求的另外一个例子是外围设备的存储器地址分配。这种分配通常没有上层需求，然而，一旦地址分配确定，就会约束后续的设计任务，使其符合这些分配，以便设计能正确工作。这种派生的需求不需要确认。

　　派生的硬件需求确认过程目标是：

　　a) 用于验证硬件项的派生的硬件需求是正确和完整的;

　　b) 派生需求对安全性的影响得到评估;

　　c) 遗漏和错误反馈给了相应的过程进行纠正。

　　8.2.2 确认过程活动

　　确认的目标可以通过一系列活动来满足，如评审、仿真、原型、建模、分析、服务经历、工程评估或测试的开发与执行。

　　确认过程活动指南包括：

　　a) 应识别需要确认的派生的硬件需求。

　　b) 对于条目 a)所识别的每一个需求，应识别并满足如下确认完成准则：

　　1) 每一个需求应在某个特定层次上，通过评审、分析或测试得到确认。

　　2) 每一个需求的评审、分析或测试，适用于被确认的需求(尤其是与安全性相关的需求)。

　　3) 与每一个需求确认相关的评审、分析和测试结果应是正确的， 并且实际结果与期望值之间的差异能够得到合理解释。对于评审和分析， 当没有预先定义的期望结果时，确认活动的结果应与需求、尤其是与安全性相关的需求一致。

　　注：确认完成的准则可以基于需求、安全性考虑、工作模式或实现。

　　c) 应评估派生需求对安全性的影响。

　　d) 应评估派生的硬件需求相对于分配给硬件项的系统需求的完整性。当所有已定义的属性是必须的，并且所有必需的属性已经定义，则认为需求是完整的。

　　e) 应评估派生的硬件需求相对于分配给硬件项的系统需求的正确性。当需求定义没有歧义， 并且在定义的属性中没有错误时，则认为需求是正确的。

　　f) 应建立派生的硬件需求与确认活动和结果之间的追溯性。

　　g) 需求遗漏和错误应反馈给相应的过程进行纠正。

　　8.3 验证过程

　　8.3.1 验证过程目标

　　验证过程保证硬件项的实现满足其需求。验证包括在验证计划中定义的评审、分析和测试。验证过程应包含对结果的评估。

　　注：硬件安全性设计内容以硬件实现满足的安全性需求的形式体现。

　　本节为应用于硬件设计的验证过程提供指南。验证过程可按照验证计划中定义的设计架构的任一层次进行。对于安全性需求， 在设计过程的不同阶段应用验证过程，有利于将设计错误被消除的概率提高到高度可信的程度。如在附录 A 中所指出的，一些设计保证级别要求独立地满足验证过程的目标。

　　软件验证、软/硬件综合验证和系统综合验证过程在本指导性文件中不做规定。然而，在这些过程

　　中对硬件需求进行验证是硬件验证的一种有效方式。

　　对已经过验证的构型的更改，可以通过相似性、分析、新设计的测试或重复进行部分原有的验证等方法重新验证。

　　注：推荐使用在验证过程文件之外的非正式测试。然而， 这些程序和结果，不必要受构型管理控制，但对于在设计过程早期发现和消除设计错误是非常有效的。这类测试只有形式化后，才能用作获取验证信任。

　　验证过程的目标是：

　　a) 提供硬件实现满足其需求的证据;

　　b) 在硬件需求、实现与验证过程和结果之间建立追踪关系;

　　c) 确定并执行与硬件功能的设计保证级别一致的验收测试准则;

　　d) 遗漏和错误反馈给相应的过程进行纠正。

　　8.3.2 验证过程活动

　　验证过程目标可以通过组合使用诸如评审、分析、以及测试的开发与执行等方法来满足。验证计划规定了应采用的证明符合需求的验证活动。

　　验证活动包括：

　　a) 识别需要验证活动的需求。不要求在每一个层次上都对需求进行验证，需求可以在较高层次级别上进行验证。

　　b) 选择并执行验证方法，如测试、仿真、构造原型、分析和评审。

　　c) 应建立需求、实现、验证过程与结果之间可追溯性。可追溯性应与硬件执行的功能的设计保证级别一致。除非出于安全性考虑要求， 否则不要求追溯到具体的部件，如电阻、电容或门电路;

　　d) 应进行验证覆盖率分析，以确定验证过程是否结束，结束准则包括：

　　1) 每一个需求都在某个层次上通过评审、分析或测试验证。

　　2) 每一个需求的评审、分析或测试，适用于被验证的需求(尤其是与安全性需求相关的需求)。

　　3) 与每一个需求的验证相关的评审、分析和测试结果是正确的， 并对实际与期望结果之间的差异进行了合理解释。对于评审和分析， 当没有预先定义的期望结果时，验证活动的结果应与需求、尤其是与安全性相关的需求一致。

　　e) 验证活动的结果应形成文件。

　　f) 遗漏和错误应反馈给相应的过程进行纠正。

　　8.4 确认和验证方法

　　8.4.1 测试

　　测试是一种确认硬件项对一个激励或一系列激励正确响应的方法。测试的例子包括对在硬件项上进行的功能测试、在系统平台上进行的测试、系统确认测试和飞机级测试。

　　测试可以通过手工、自动或专用测试设备进行。在验证过程中，测试也可利用内部硬件项测试能力，如 BIT 测试。

　　如果不能通过在其预期的工作环境中使用硬件来验证具体的需求，应提供其他的验证方法，并且证明方式是合适的。

　　测试可以在不同的硬件设计过程中进行。用于作为认证证据的测试需要构型确定的硬件项。系统综合或软/硬件综合测试结果也可用作测试认证证据。

　　测试指南包括：

　　a) 应识别每一个需要通过测试来确认或验证的需求。环境条件测试需求是这些需求的一部分。

　　b) 应定义每一个测试的测试激励、序列和测试条件，如环境温度和适用电压。

　　c) 在测试执行之前，应定义通过/失败条件及记录结果的方法。

　　d) 应记录每一个测试设备的完整标识及校准日期。

　　e) 应记录被测硬件项的构型标识。

　　f) 应记录并保留测试结果。

　　g) 测试失败应反馈给相应的过程进行处理。

　　8.4.2 分析

　　分析是一个具体的、可重复的、解析的方法， 用于评估具体硬件项的特性，来证明某一具体需求得到满足。分析的例子包括应力分析、设计余量分析、共模故障分析、最坏情况分析和测试覆盖率分析。服务经历可以为不同的分析提供数据。

　　注：随着硬件设计复杂度的增加，利用计算机工具，如仿真，来验证需求和设计的实现，具有很多优点。

　　分析可以包括对以下内容的详细检查：功能、性能、可追溯性、硬件项功能涉及的安全性以及与机载系统或设备中其他功能的关系。分析可以单独使用， 也可以与其他验证方法结合使用，可提供需求被正确实现的证据。分析应基于设计过程、服务经历提供的数据或其他可用的数据库进行。

　　仿真对于电路工作的可视化和更高级别功能操作，是一个很重要的设计分析工具。仿真可用来分析硬件参数生产变化所带来的影响，使用其他验证方法可能难以做到。仿真方法对于减少由于参数变化带来的影响安全性的设计错误树立了信心。由于结果依赖于使用的模型和场景， 在没有其有效的支撑证据的情况下，单纯的仿真结果不足以用于认证证据。

　　分析的例子包括：

　　a) 热分析：热分析用于验证当置于工作的热环境中时，设计实现满足需求;

　　b) 应力分析：应力分析用于验证在要求的工作范围之外，部件满足降额标准;

　　c) 可靠性分析：可靠性分析确定设计实现是否满足产品的可靠性需求;

　　d) 设计余量分析：设计余量分析验证在给定的部件变化范围内，设计实现满足其功能需求;

　　e) 相似性分析：相似性分析将特征和使用情况与以前认证过的系统进行比较;

　　f) 仿真分析：仿真分析将仿真结果和期望的结果进行比较。

　　8.4.3 评审

　　8.4.3.1 需求评审

　　需求评审是一种保证需求可接受性的方法。在初始需求评审之后发生的需求更改， 应进行与初始评审相同的评审过程或一个同等的评审过程。需求评审的目的不是确认分配给硬件项的系统需求。

　　需求评审包括：

　　a) 每一个需求应是明确的、可验证的， 在其结构层次上描述完整、详细， 并且与其他需求不冲突;

　　b) 派生需求应与系统需求或派生出该需求的要求一致;

　　c) 需求应与系统安全性评估过程保持一致;

　　d) 应定义派生的安全性需求，并反馈给系统安全性评过程;

　　e) 需求应符合相关的硬件设计标准;

　　f) 需求应符合可用的工艺能力和限制;

　　g) 部件的需求，如性能、温度范围、降额和筛选，应与安全性和可靠性需求一致;

　　h) 应提出测试、维护和制造硬件项的能力要求;

　　i) 应定义软/硬件接口的需求;

　　j) 需求应可根据计划中定义的准则，追溯到其上一层次;

　　k) 派生需求应获取不在较高结构层次上进行验证的实现约束;

　　l) 遗漏和错误应反馈给相应的过程进行纠正。

　　注 1：下列问题有助于评估需求的完整性：

　　a) 是否考虑了全部的上层需求?

　　b) 是否考虑了适用的标准和指南?

　　c) 是否覆盖了全部硬件功能和接口?

　　d) 是否完整地覆盖了结构?

　　e) 是否充分说明了要求验证的所有硬件实现?

　　f) 是否覆盖了所有在安全性评估中所禁止的行为特性?

　　g) 是否充分说明了工作环境?

　　h) 是否考虑了假设和约束?

　　i) 这个实现是否能避免任何当前的或类似硬件已知的问题?

　　注 2：下列问题有助于评估需求的正确性：

　　a) 需求是否与上层需求一致?

　　b) 需求是否与分配给硬件项的系统需求一致?

　　c) 需求是否是陈述了“是什么”而不是“如何做”?

　　d) 需求是否无歧义?

　　e) 需求能否实现?

　　f) 需