DO-254标准编译稿

DO-254 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 编译稿RTCA/DO254标准机载电子设备硬件的设计保证指南二00八年四月 目录 工贸企业有限空间作业目录特种设备作业人员作业种类与目录特种设备作业人员目录1类医疗器械目录高值医用耗材参考目录 前言本文件由航空无线电委员会（RTCA）180专委会（SC-180）制订，并于2000年4月19日由RTCA项目管理委员会批准通过。本指南是RTCASC-180和EUROCAE（欧洲民用航空设备组织）WG-46在协商一致的基础上共同编写完成的。RTCA公司是一家非营利性的组织，其宗旨是推进航空和航空电子系统科学与技术的发展，为公众的福祉服务。本组织起到了联邦顾问委员会的作用，并就当前航空方面的议题提出一致通过的建议。RTCA的目标包括但并不仅限于：结合航空系统用户和供应商的技术要求，帮助政府和企业实现和履行彼此的目标及职责；对航空业界在追求更高安全、系统性能和效能时所面临的系统技术问题进行分析，并提供解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 ；推进相关技术应用的通过，以满足用户和供应商的要求，包括支持飞行的电子系统和设备的最低工作性能标准的制定；帮助制定相关技术资料，以此确定国际民航组织、国际电信联盟以及其它感兴趣的国际组织的地位。本组织的建议通常被政府和民间组织作为决策的依据，并且还是众多联邦航空管理技术标准规程的基础。由于RTCA并不是美国政府的官方代理机构，本组织的建议未经美国政府或在这些建议所涉及到的任何问题上拥有法定权限的组织公布，不能被认定为官方政策。执行概要航空业界中复杂电子设备的使用和研发引起了新的安全和验证问题。为解决此问题，成立了RTCASC-180和EUROCAEWG-46。RTCASC-180和EUROCAEWG-46早在制订本文件时就已同意并组成了联合委员会。该联合委员会经特许为机载电子设备制定清晰和一致的设计保证指南，从而使机载电子设备可安全地发挥其既定功能。机载电子设备包括线可替代单元、电路板组件、专用集成电路、可编程逻辑器件等。本指南适用于现有的、新的以及刚出现的技术。前言本文件由航空无线电委员会（RTCA）180专委会（SC-180）制订，并于2000年4月19日由RTCA项目管理委员会批准通过。本指南是RTCASC-180和EUROCAE（欧洲民用航空设备组织）WG-46在协商一致的基础上共同编写完成的。RTCA公司是一家非营利性的组织，其宗旨是推进航空和航空电子系统科学与技术的发展，为公众的福祉服务。本组织起到了联邦顾问委员会的作用，并就当前航空方面的议题提出一致通过的建议。RTCA的目标包括但并不仅限于：结合航空系统用户和供应商的技术要求，帮助政府和企业实现和履行彼此的目标及职责；对航空业界在追求更高安全、系统性能和效能时所面临的系统技术问题进行分析，并提供解决方案；推进相关技术应用的通过，以满足用户和供应商的要求，包括支持飞行的电子系统和设备的最低工作性能标准的制定；帮助制定相关技术资料，以此确定国际民航组织、国际电信联盟以及其它感兴趣的国际组织的地位。本组织的建议通常被政府和民间组织作为决策的依据，并且还是众多联邦航空管理技术标准规程的基础。由于RTCA并不是美国政府的官方代理机构，本组织的建议未经美国政府或在这些建议所涉及到的任何问题上拥有法定权限的组织公布，不能被认定为官方政策。执行概要航空业界中复杂电子设备的使用和研发引起了新的安全和验证问题。为解决此问题，成立了RTCASC-180和EUROCAEWG-46。RTCASC-180和EUROCAEWG-46早在制订本文件时就已同意并组成了联合委员会。该联合委员会经特许为机载电子设备制定清晰和一致的设计保证指南，从而使机载电子设备可安全地发挥其既定功能。机载电子设备包括线可替代单元、电路板组件、专用集成电路、可编程逻辑器件等。本指南适用于现有的、新的以及刚出现的技术。本文件中的指导措施将供飞机系统所用的电子硬件项的供应商和飞机生产商使用。文件中确定了硬件设计生命周期进程，并对每一进程的目标和活动进行了描述。本指南适用于所有的硬件保证等级（由系统安全评估确定）。在本文件的制定进程中，委员会参考了其它的业内文件，包括美国动力机械工程师协会（SAE）航空推荐准则(ARP)文件ARP4754/EUROCAEED-79、高度集成或复杂飞机系统的验证准则、民航系统及设备的安全评估进程实施方针及方法以及RTCADO-178/EUROCAEED-12机载系统及设备验证的软件考虑因素。目录TOC\o"1-5"\h\z\u1导言1目的1范围1与其它文件的关系2相关文件3如何使用本文件3复杂性考虑4其它方法或进程5文件概览52系统方面的硬件设计保证7信息流8从系统开发进程到硬件设计生命周期进程的信息流8从硬件设计生命周期进程到系统开发进程的信息流9硬件设计生命周期进程与软件生命周期进程之间的信息流9系统安全评估进程9硬件安全评估13硬件安全评估考虑事项13随机硬件故障的定量分析14硬件设计失误及推翻的定性评估14关于硬件故障情况分类的设计保证考虑事项153硬件设计生命周期18硬件设计生命周期进程18过渡标准184计划进程19计划进程目标19计划进程活动195硬件设计进程21要求捕获进程23要求捕获目标23要求捕获活动23概念设计进程24概念设计目标25概念设计活动25详细设计进程25详细设计目标25详细的设计进程活动26实施进程26实施目标27实施活动27生产转换进程27生产转换目标27生产转换活动28验收测试28连续生产296鉴定与验证进程30鉴定进程30鉴定进程目标30鉴定进程活动31验证进程31验证进程目标32验证进程活动32鉴定和验证方法33测试33分析34审核35要求审核35设计审核377配置管理进程39配置管理目标39配置管理活动39配置识别39原始资料的建立40问题报告、跟踪和纠正行为40更改控制41发布、归档以及检索42数据控制类别428进程保证44进程保证目标44进程保证活动449认证联络进程45符合方法与规划45符合证明4510硬件设计生命周期数据47硬件计划47硬件方面认证计划48硬件设计计划49硬件鉴定计划49硬件验证计划50硬件配置管理计划50硬件进程保证计划51硬件设计标准和指南51要求标准51硬件设计标准51鉴定和验证标准52硬件存档标准52硬件设计数据52硬件要求52硬件设计表示数据53概念设计数据53详细设计数据54.1顶级图54.2组装图54.3安装控制图54.4硬件/软件接口数据55鉴定和验证数据55可追溯性数据55审核和分析程序56审核或分析结果56测试程序57测试结果57硬件验收测试标准57问题报告58硬件配置管理记录58硬件进程保证记录58硬件完成概要5811附加考虑事项60先前开发硬件的使用60对先前开发硬件的变更60飞机设备的更改60应用或设计环境的改变61设计原始资料的升级61配置管理的附加考虑事项62商业化成品（COTS）元件的使用62对COTS元件的电子元件管理62COTS元件的采购63产品服务经验63产品服务经验数据可接受性标准63对产品服务经验数据的评估63产品服务经验评估数据64工具评估和鉴定64工具评估和鉴定进程65工具评估和鉴定数据68简介72功能故障路径分析72功能故障路径分析方法73功能故障路径分析数据73A级与B级功能的设计保证方法74架构缓解74架构缓解方法74架构缓解的解决74架构缓解数据75产品服务经验75产品服务经验方法75产品服务经验的解决75产品服务经验数据75先进验证方法76元素分析77A.元素分析法77A..1选择元素分析标准77A..2执行元素分析78A.元素分析结果的解决79A.元素分析生命周期数据输出79特定安全分析80A.特定安全分析法81A.特定安全分析的解决81A.特定安全分析数据82形式法82A.形式法的方法论83A.形式法的解决84A.形式法数据841导言使用日益复杂的电子设备可获得更好的安全关键飞机功能，但这也会带来关于安全和验证的新的挑战。产生这些挑战是由于担心上述飞机功能会由于硬件设计失误的相反效应而变得更加脆弱，并且这些失误会由于硬件的日趋复杂化而更加难以把握。为抵消此风险的扩大，在设计和验证进程中，有必要的采用更一致的和可验证的方式来确保潜在的硬件设计错误的定位。由于机载电子设备的日趋复杂化、技术的进步以及在实际应用中和采用本文件所述程序的进程中获得的经验，必须根据已通过的RTCA/EUROCAE程序对本文件进行修订和审核。1.1目的本文件帮助研发组织为机载电子设备的开发提供了设计保证指南，从而使机载电子设备可在规定的环境中安全地发挥其预定的功能。本指南同样适用于现有的、新的以及正在开发的技术。本文件的目的是：1．确定硬件设计保证目标；2．描述这些目标的基本原则以确保对本指南的正确阐述；3．提供目标描述，以允许根据本指南和其它指南所作的各种改进；4．提供设计保证活动指南以满足设计保证目标；5．只要有合适的新技术，允许灵活选择满足本文件目标（包括对其的改进）必需的进程。本文件介绍的是为满足设计保证目标所应采取的活动，而并未详细介绍怎样进行某项设计。本指导文件所用的基本原理是基于电子设备所体现出来的系统功能的一种自上而下的透视法，而不是一种自下而上的透视法，或者仅基于用于实现某功能的一些特定设备元件的透视法。通过推进已知系统和硬件设计的决定，以及高效且有效的验证进程，自上而下的方法在处理安全设计失误时会更有效。例如，应在系统、组件、子组件、元件或硬件项的最高等级上进行验证；并且在此等级上，硬件项可满足其要求，验证目标也可实现。1.2范围本文件为机载电子设备（源自初始验证和后续验证后产品改进进程的概念）提供设计保证指南，以便确保连续的适航性。本文件基于与运输类飞机和设备所需的验证要求一致的陈述制定，但本文件的一部分并不适用于其它设备。本文件描述了系统生命周期和硬件设计生命周期间的关系，以帮助理解系统和硬件设计保证进程的相互关系。文件中并未包括对系统生命周期（包括系统安全评估（SSA）和有效性）以及飞机验证进程的完整描述。只有与硬件设计生命周期有关时，才会讨论验证问题。而只有与硬件设计的适航性有关时，才会处理与生产、检测和维护硬件项的能力相关的方面。本文件指南适用于但不仅限于以下硬件项:1．线路可替代单元（LRU）；2．电路板组件；3．定制微码元件，如专用集成电路(ASIC)和可编程逻辑器件（PLD），还包括任何相关的宏功能；4．集成技术元件：如混合电路和多芯模块；5．商业成品元件（COTS）。由于COTS元件供应商可能不会遵从本文件所述的设计进程，或提供必要的设计生命周期数据，因此其它的情形，尤其是针对COTS的考虑，会在第11节中进行讨论。本文件并未试图定义固件。固件应归类为硬件或软件，并且应采用适当的进程对其进行处理。本文件假设，在系统定义时，功能已分配给了硬件或软件。RTCADO-178/EUROCAEED-12提供了针对分配给软件执行程序的功能的指南。本文件提供的是针对分配给硬件的功能的指南。注：在系统确定和功能指定后，就可确定执行程序和设计保证的有效方法。在进行指定时，所有团体都应同意此系统决定。硬件项设计和验证所用工具的评估和规格见第节。本文件并未提供关于组织结构或在这些结构中如何划分职责的指南。环境条件标准也不在本文件所涉及的范围之内。1.3与其它文件的关系除了飞行性能要求外，各种关于硬件的国家和国际标准也是适用的。在有些团体中，可能会要求遵从这些标准。但是，本文件并未援引具体的国家或国际标准，也未提供某种方法使得这些标准可用作本文件的选项或补充。当本文件使用“标准”这一术语时，意指机载系统、机载设备、发动机或飞机制造商所用的工程特定标准。这些标准可能来自于制造商制定或采用的通用标准。标准指南见第节。1.4相关文件SAEARP4754/EUROCAEED-79，即高度集成或复杂飞行系统验证准则，是关于高度集成或复杂飞行系统的开发指南的源文件。SAEARP4761，即民航系统及设备的安全评估进程实施方针及方法，是用于硬件设计保证进程的安全评估方法的源文件。RTCADO-178/EUROCAEED-12，即关于机载系统及设备验证的软件考虑因素，是软件开发保证的补充文件。RTCADO-160/EUROCAEED-14，即机载设备的环境条件及测试进程，可为设备设计者用作硬件项规格的初级环境测试标准。1.5如何使用本文件本文件供国际航空团体使用。为便于使用，尽可能少地参考了具体的国家规定和程序；相反，使用更多的还是通用术语。例如，术语“认证机构”用来指代表有权认证的国家进行审核的组织或个人。当另外一个国家或国家集团批准或参加此认证时，本文件就可使用，并且会在所涉及到的国家间的双边 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 或谅解备忘录中相应地体现出来。本文件指南代表了航空团体的一致意见，囊括了机载电子设备设计保证方面最好的行业实践经验。对于本文件中提出的进程，其目的是提供可用于完成新硬件设计和后续改造的指南。先前为其它进程提供的硬件指南见第节。可以理解，除了在此介绍的方法外，其它方法也可能为申请人获取并采用。在使用实例说明如何使用本指南时，不管是用图表形式还是叙述方式，不能认为这些实例是首选的方法。第11节讨论了关于特定已知情况（在这些已知情况下，第2节至第9节的一些目标可能不会实现）的其它情形。这些情形包括：已开发出的硬件的使用指南、COTS元件使用指南、产品服务经验指导、工具评估及规格指南。在附录A中，基于执行中的硬件设计保证等级，提供了关于必需的硬件设计生命周期数据的指南。附录B包括了执行A级和B级功能（除了第2节至第11节的指南外，也应使用这些功能）所用硬件的设计保证技术指南；根据申请人的意愿，附录B也可应用于硬件的C级和D级设计保证。本文件中所用的术语表见附录C。附录D是本文件所用的缩略词汇表，列出了这些缩略词的全称。对于列出的表单，并不意味着其下的子项在任何情况下都是全面的，也不是说所有的子项都对应于任何特定的产品。本文件中的注释用于提供说明性材料、强调某一点或者引起对相关主题的注意。当然，这些注释并不仅限于上下文范围之内。注释并不包含指南。当提供指南时会用“应该”一词。“可能”则用于选择性文本。本文件所用的术语“硬件项”则是用来描述作为本文件主题的电子设备。除非特意说明，在本文件中都会采用限定词“硬件”。使用术语“要求”时是指“硬件要求”。系统或软件限定词通常会特意说明，如“系统要求”。注：各种行业咨询文件和航空要求文件并不总是使用一致的术语。例如，联邦航空规程（FAR）21和联合航空要求（JAR）21中使用“产品”来指代飞机、飞机发动机、或螺旋桨。文件SAEARP4754/EUROCAEED-79使用“产品”这一术语来指代硬件、软件、部件或根据确定的一组要求形成的系统。请读者注意在使用术语时的这些以及其它差异。本文件使用的是词汇表中的定义。1.6复杂性考虑尽管有各种关于术语“复杂性”的分类被用于描述电子器件，比如简单、复杂和高度复杂，但这些分类之间的区别并未严格确定。要在此确定复杂性间的区别，需要根据使用确定性方法达到可行性验证范围所必需的可行性和困难程度而进行。应分等级，按照集成电路、电路板和LRU的顺序对硬件的复杂性进行检查；其中，复杂性包括可能不可测的寻址功能，如多用途设备中未用的模式和时序机中可选的隐藏状态。在不存在异常现象的所有可预见的操作条件下，只有当符合设计保证等级的确定性测试和分析可确保正确的操作性能时，硬件项才可定义为简单。若某硬件项不能归入简单一类，它就应归入复杂一类。全部由简单部件构成的部件可能是复杂部件。对于含有器件（如ASIC或PLD）的部件，若其符合本节描述的简单标准，就可认为是简单的。对于复杂部件，推荐的提供设计保证方式应该早已在硬件设计生命周期中经认证机构同意使用，以减小进程风险。对于简单硬件项，设计进程不需要提供大量文件。对于简单硬件项，需要执行并证明验证和配置管理支持进程，但并不需要提供大量文件。因此，为遵从本文件，在设计简单硬件项时削减了费用。本文件的主要影响将体现在复杂硬件项的设计上。1.7其它方法或进程除了本文件所述的以外，其它方法或进程也可能被用于提供硬件设计保证。对于这些方法和进程，应根据其满足可用准则的能力来进行评估。可选方法或进程应在执行前由认证机构批准。当通过比较本文件来评估可选方法或进程时，除了直接与可用准则比较外，申请人还可使用以下的指南来降低进程风险。评估可选方法或进程应考虑的因素包括：1．在代替本文件介绍的进程使用时，满足第2节至第9节中一个或多个目标的进程应体现出同等的设计保证等级；2．应该评估所推荐的其它方法或进程在满足硬件设计保证目标时产生的影响；3．应该评估所推荐的其它方法或进程对生命周期数据产生的影响；4．使用推荐方法或进程的合理性应该用这样的证据来证明：使用这些方法或进程可产生预期结果。1.8文件概览图1-1是本文件所有章节的概图，表明了这些章节彼此之间的关系，以及与其它相关进程的关系。这并不是为了描述数据流，而是为了表明哪些章节及外部进程是相关的。图1-1文件概览2系统方面的硬件设计保证硬件设计保证从系统等级开始，系统功能会分配给硬件，而同时也会指定其相应的系统开发保证等级。单个的系统功能可以分配给硬件项、软件元件或软硬件组。与功能相关的安全要求来自于系统透视、软件透视和硬件透视，从而就可确定满足这些要求所必需的可靠性等级和保证等级。图2-1阐示了机载电子系统和设备的系统开发进程与安全评估、硬件开发以及软件开发进程的关系。图2-1机载系统、安全评估、硬件和软件进程间的关系在图中有四处重叠区域，分别为：安全/硬件，安全/软件，硬件/软件和安全/硬件/软件。这些重叠表明了这些进程间的关系和相互作用；而在这些进程中，系统要求可能会产生一些在多进程范围及设计保证指南之内的要求。例如，包含安全要求的硬件功能会包括安全评估进程和硬件设计生命周期进程。这些重叠表明，需要用进程间的相互作用来确保系统功能保证要求的满足。本文件并未探讨系统或软件保证进程。但是，在协调硬件功能的设计保证时，申请人也可能想利用系统或软件进程中的活动提供的保证。这些关系和相互作用在第2.1.1节至第节中会进一步探讨。2.1信息流生命周期进程间的信息流如图2-2所示。以下部分所述的是从系统开发进程到硬件设计生命周期进程间的信息流、从硬件设计生命周期进程到系统开发进程间的信息流以及硬件设计生命周期进程与软件生命周期进程间的信息流。注：这些都被认为是反复的进程，并且在硬件设计生命周期中还会产生变化。图2-2系统开发进程2.1.1从系统开发进程到硬件设计生命周期进程的信息流此信息流可能包括：1．分配给硬件的设计和安全要求；2．每种功能的设计保证等级，还有其相关要求和故障条件，但前提是此功能可用；3．分配的可能性，以及风险出现时，硬件功能故障出现的可能性；4．硬件/软件接口描述5．关于安全策略及设计限制的要求，如可测试性、设计方法以及硬件结构；6．将通过硬件等级验证来执行的系统验证活动的要求；7．分配给硬件的安装要求、人体工程学要求以及环境要求；8．可能会对要求产生影响的综合问题报告。之所以会这样，是由于一些活动的缘故，如：系统验证、系统要求的产生或SSA。2.1.2从硬件设计生命周期进程到系统开发进程的信息流此信息流可能包括：1．要求的执行进程，如：机械制图、简图和零件列表；2．可能会影响任何分配的要求的硬件衍生要求；3．装置结构，包括故障限度；4．在硬件设计生命周期中进行的任何必需的系统验证和审核活动的证明；5．产品安全分析数据，如：a.与SSA进程有关的特定硬件功能故障的可能性及故障率；b.常见故障分析；c.隔离范围及普通故障缓解策略；d.与系统要求相关的潜在分析数据。例如：故障监视、故障检测周期和不可测故障的硬件准备。6．将通过系统等级验证来实施的硬件验证活动的要求；7．关于安装要求和环境条件（是将要进行的分析所必需的）的假设和分析方法；8．可能会影响系统、软件或分配的硬件要求的问题或变化报告。2.1.3硬件设计生命周期进程与软件生命周期进程之间的信息流此信息流可能包括:1．硬件/软件集成所需的衍生要求，如：草案的确定、定时限制以及软硬件间接口的寻址方案；2．需要协调硬件和软件验证活动的情况；3．硬件和软件之间所确定的不兼容性，这可能也是报告和校正行动系统的一部分；4．也可应用的系统进程的安全评估数据。2.2系统安全评估进程现有三个系统安全评估进程，它们分别是：功能危险性评估（FHA）,初步系统安全评估（PSSA）和SSA。这些进程被用于建立可应用于系统开发保证进程的系统安全目标，还用于确定系统功能是否达到了安全目标。SSA进程应该把安全目标转化成系统和设备安全要求。这些要求应包括系统及设备的功能及结构的基本安全目标和安全特征。SSA进程和系统开发进程把这些安全要求分配给了硬件。系统开发保证等级现有五个等级，A级至E级，对应五类故障情况：灾难性的、危险的/极严重的、严重的、轻微的和无影响的。表2-1把硬件设计保证等级和五类故障情况联系了起来，并确定了硬件故障条件和它们对应的设计保证等级。首先，各个硬件功能的硬件设计保证等级是通过SSA进程、使用FHA辨别可能的危险来确定的；然后，PSSA进程把安全要求和相关的故障情况分配给硬件执行的功能。在硬件设计生命周期中，安全、系统和硬件进程间可能存在循环反馈，以确保设计制造的硬件会满足分配给硬件的系统安全、功能和性能要求。表2-1硬件设计保证等级的定义及其与系统保证等级的关系系统开发保证等级故障情况分类故障情况描述硬件设计保证等级定义A级灾难性的故障情况会妨碍持续安全飞行和着陆。对于硬件功能，通过如硬件安全评估可以看到，硬件功能故障或异常行为会引起能导致飞机发生灾难性故障情况的系统功能故障。B级危险的/极严重的故障情况会降低飞机的性能或空勤组处理异常运行情况的能力，从而极大地降低安全系数或功能，导致身体痛苦或增加工作量；这样，就不能依靠空勤组精确地或完全地执行其任务；并且还会对乘员产生不利影响，包括对这些成员中的一小部分造成严重伤害或潜在的严重伤害。对于硬件功能，通过如硬件安全评估可以看到，硬件功能故障或异常行为会引起能导致飞机发生危险的/极严重的故障情况的系统功能故障。C级严重的故障情况会降低飞机的性能或空勤组处理异常运行情况的能力，从而极大地降低安全系数或功能，并极大地加重空勤组的工作量或降低空勤组的效率，使乘员产生不适，包括对其造成伤害对于硬件功能，通过如硬件安全评估可以看到，硬件功能故障或异常行为会引起能导致飞机发生严重故障情况的系统功能故障。D级轻微的故障情况不会极大地降低飞机安全，并且空勤组的活动也控制在其能力范围之内。轻微故障情况可能包括：安全系数或功能的轻微降低、空勤组的工作量的轻微增加（如，例行飞行计划的改变）或给乘员造成的一些不便。对于硬件功能，通过如硬件安全评估可以看到，硬件功能故障或异常行为会引起能导致飞机发生轻微故障情况的系统功能故障。E级无影响的故障情况不会影响飞机的运行能力，也不会增加空勤组的工作量。对于硬件功能，通过如硬件安全评估可以看到，硬件功能故障或异常行为会引起系统功能故障，但不会对飞机的运行能力或空勤组的工作量产生影响。对于确定为E级的功能，不需要本文件的进一步指导，但本文件的指南可用做参考。2.3硬件安全评估硬件安全评估与SSA进程一起执行，并用于支持SSA进程。该安全进程是为了证明可应用的系统和设备（包括硬件）满足了可应用的飞机验证要求的安全要求。若系统进程把安全、功能和性能要求分配给硬件，硬件安全评估就可确定各种功能的硬件设计保证等级，并有助于确定将要用到的合适的设计保证策略。2.3.1硬件安全评估考虑事项硬件项设计者可能会采取适当的设计保证策略，遵从分配给硬件的安全要求和硬件设计保证等级。单独的设计保证等级和策略可以应用于整个硬件项，而也可认为硬件项拥有独立的功能故障路径（FFP），这样就可提供混合设计保证等级或设计保证策略。功能故障路径分析（FFPA）可以用来判断硬件项部件较低的设计保证等级，或提供由不同方法或不同的产品服务历史来执行的不同功能。注：FFPA将在附录B的第2部分介绍。此分析方法尽管在书面上规定用于处理附录B中的问题，但它也适用于任何设计保证等级。若硬件项所含功能单独拥有不同的设计保证等级，这种情形可用下列方法之一处理：可以保证整个硬件项为最高设计保证等级。若硬件的功能、接口和共享资源可免受较低保证等级的功能的不利影响，就可根据硬件安全评估确定的那样，单独地确保单个硬件功能为各自的硬件设计保证等级。共享资源的设计保证应该就是最高级功能的设计保证等级。针对硬件安全评估的建议包括：1．反复的硬件安全评估和设计应该确定衍生硬件安全要求，并保证满足分配给硬件的系统安全要求，还要保证满足衍生要求；2．这些衍生要求应包括硬件结构安全要求、电路及元件的安全要求、以及防止异常行为的安全要求（包括结合特定硬件结构及功能的安全特征），例如：a.电路和元件冗余；b.电路或元件间的分离或电隔离；c.电路或元件间的差异；d.电路或元件的监视；e.保护或重新配置机器；f.电路和元件的随机故障和潜在故障的容许故障率和可能性；g.使用或安装的限制；h.干扰的防止、管理以及恢复。3．硬件设计保证进程和硬件安全评估应共同确定具体的遵从方式及每种功能的设计保证等级，还应确定已达到了可以接受的设计保证等级。注：异常行为可能由硬件项中的随机故障或设计失误引起，或者对硬件的干扰引起。硬件设计者可能会为硬件项功能选择较高的硬件设计保证等级。例如，在进行需要较高等级设计保证的安装时，会预料到硬件项功能的重新利用。硬件安全评估可能会运用各种定性和定量的评估方法。这可能包括：故障树分析（FTA）、常规分析、故障形式和后果分析、以及可用于随机故障的定量评估所用的统计可靠性分析法。2.3.2随机硬件故障的定量分析基于硬件故障率、冗余、分离与隔离、故障形式统计、可能性分析、元件减少、压力分析和制造进程控制的统计故障评估和预测方法已经证明，这些都是对随机硬件故障进行定量风险因素评估可以接受的方法。2.3.3硬件设计失误及推翻的定性评估不像硬件随机故障那样，设计失误和一些类型的“推到重来”在统计学上都是不可预测的，并且它们都可能以普通故障的形式越过冗余界限。应该对将要使用的冗余管理方法和定量分析方法进行选择，以便在必要时可以排除或减轻潜在的普通故障以及“推到重来”的影响。尽管定量评估很困难，但仍可利用定性安全评估方法有效地评估由设计失误和“推到重来”带来的安全风险。像故障树分析、普通分析和功能故障形式及影响分析（F-FMEA）这样的分析方法基本是定性的方法，可以用来处理硬件设计失误和“推到重来”。更具体地说，这些方法可以确定硬件设计失误和“推到重来”的潜在影响，还有助于确定通过何种方式可以排除或减轻这些影响。使用这些方法后，硬件安全评估就有助于确定将要使用的硬件设计保证策略，并且在硬件设计进程中可反复使用，从而就可定性地确定所选策略达到的保证等级。2.3.4关于硬件故障情况分类的设计保证考虑事项由于系统故障情况越来越严重，为确保相关故障情况的减轻而必需的硬件设计保证量也随之增长。对于所有的设计保证等级，应该研究出一种方法或策略来确保合适的设计保证等级。图2-3列出了研究适当设计保证策略的决定生成流程。建议包括：1．对于在硬件中执行的A级或B级功能，设计保证考虑事项应处理硬件功能潜在的异常行为和潜在的设计失误；2．当研究每个执行中的功能的设计保证策略时，应该使用图2-3中列出的决定生成流程；3．除了在第3节至第1节中提供的建议外，附录B中所述的策略也应该用于A级和B级功能；4．设计保证策略应选择为硬件结构和用途的功能，以及已选的硬件执行技术的功能。不同的技术、元件选择和元件用途提供了各种程度的硬件设计生命周期信息和各种程度的防止相关设计失误及其影响的措施。在相同的硬件项之内，对于不同的功能路径，最适合的设计保证方法也会有所不同。在图2-3中，决策和活动块中的数字指的是根据进一步说明决定或活动的图表得出的编号项。1．启动评估进程。对于所有的设计保证等级，都应该研究出相应的方法或策略来保证合适的设计保证等级。2．确定FFP设计保证等级。对于每个确定的硬件项，确定并证明与部件和设计保证等级相关的FFP。图2-3硬件设计保证策略的决定进程3．FFP的硬件执行是简单的还是复杂的对于硬件设计保证的A级或B级FFP，按所述来确定硬件是简单还是复杂。4．研究A级或B级复杂FFP的设计保证策略。若FFP是复杂的并且为A级或B级，就可使用附录B中所述的附加策略来确定合适的设计保证策略、相应的执行概念以及失误缓解方法。对于每个A级或B级FFP，应使用深层分析、产品服务经验或结构缓解来确定设计保证策略。若所选方法不能完全缓解潜在的故障和异常行为，装置中的A级FFP就可能需要不止一种方法。5．策略合适吗确定设计保证策略中是否有不足之处；若策略中存在不足或希望获取的数据中可能会存在不足，请提出别的设计保证、执行或结构策略来修改该策略以便弥补不足之处。当设计保证策略可接受时，请为每个FFP的设计保证进程提供文件证明。该策略还应该用来处理认证机构参与的项目，如计划中的重大事件、项目审核和监督活动。6．证明可应用的故障安全情况。确定合适的故障安全设计结构和硬件项特征，然后进行分析，以满足系统的有效性和完整性。证明故障安全设计情况和相关的普通分析、可能性分析、结构或其它特征。7．证明设计保证方法及策略。对于系统验证计划或硬件验证方面的计划（PHAC）中可应用的设计保证方法和策略，应进行证明并获取认证机构的审批。8．应用此方法。根据已通过的计划和文件（明显遵从了已通过的计划和策略）中确定的适当设计保证方法进行硬件设计。3硬件设计生命周期本节列出了第4节至第9节中讨论的硬件设计生命周期。本文件既未规定首选的生命周期模型，也未为执行组织暗示一种结构。硬件设计生命周期同样适用于新系统或设备以及现有系统或设备的改进型的开发。每项工程的生命周期都应基于进程和活动的选择和安排，并且这些进程和活动应由工程特性决定，如：要求稳定性、已开发硬件的使用以及硬件设计保证等级。硬件设计生命周期可以是反复的，也就是说，根据逐渐的发展和进程间的反馈，可以进入、重新进入以及修改生命周期。3.1硬件设计生命周期进程硬件设计生命周期进程是：1．如第4节所述，硬件计划进程可以对一项工程的硬件设计和支持进程进行确定和调整；2．如第5节所述，硬件设计进程可产生设计数据和最终的硬件项。这些进程是要求捕获、概念设计、详细设计、执行以及产品过渡；3．如第6节至第9节所述，支持进程产生的硬件设计生命周期数据可以保证硬件设计生命周期及其输出的正确性以及对其的控制，这包括：计划、设计、硬件安全评估和支持进程。这些进程特别与计划和设计进程同时执行。这些进程是：鉴定、验证、配置管理、进程保证以及认证联络。3.2过渡标准在不同开发平台上用不同的子项来开发硬件项是一个挑战，因而需要一种方法来适度地控制设计进程，以便在先前进程所有的项目都完成前不会启动下一个进程。过渡标准，即用来评估从一个进程到另一个进程的运动进程的最小数据，可以用在关键的进程点上。在计划进程中进行的分析应该确定了过渡标准的使用。没有必要在计划中确定的每对进程步骤间建立过渡标准。过渡标准的选择应该可以处理对安全的影响。例如，在为获得某项功能的认证证书而进行的验证前，该功能的要求需要用文件证明，并且应在配置管理下执行该功能。应在硬件计划中对过渡标准进行证明。使用过渡标准并不暗指任何特殊的生命周期模型，也不会阻止像快速原型设计和并行工程这样的开发策略的实施。4计划进程本节讲述的是用来控制硬件项开发的硬件计划进程。本进程提出了可能包含于一个或多个文件中的硬件计划。若使用了多个文件，主计划应该包含有关于支持文件的适当参考书目。对于涵盖特定的设计生命周期进程（如：配置管理或进程保证）的标准文件，若其满足可应用的计划目标，就是可接受的。4.1计划进程目标硬件计划进程的目的是确定功能和适航性要求转换成硬件项的方式，并且硬件项还要有适度的保证使其可以安全地执行预定功能。硬件计划进程的目标是：1．硬件设计生命周期已确定；注：活动、重大事件、输入、输出和组织职责都可能包含于计划之中。2．标准已选择和确定；3．硬件开发及验证环境已选择或确定；4．遵从硬件设计保证目标的方式（包括用2.3.4中的方法确定的策略）已上报认证机构。5．注：新的和正在开发的技术、工具和进程可能需要改变计划进程的细节。因此，灵活性是本计划进程的一个关键因素。4.2计划进程活动计划进程指南包括：1．应该确定硬件设计生命周期进程（如果可以应用，还包括过渡标准）和单个进程间的相互关系，比如其时序和反馈机制；2．应确定并说明推荐的设计方法。这包括对预计硬件设计的考虑和推荐的验证方法的合理性；3．硬件设计标准（包括标准的衍生标准）若要用于工程中，应对其进行定义。这包括从通用标准到公司或项目的具体标准；注：通过提供从以前开发中得到且已证明的工程惯例，标准就有助于减小不可测设计失误出现的可能性。当把标准应用到新设计和新技术上时，申请人和开发者应注意：可适用性可能已经失效。由于设计限制、与系统要求的矛盾或与新技术的不兼容性，这些标准的衍生标准可能也是必需的。若使用了标准，计划进程就是审核合适的衍生标准的机会。4．应该确定协调硬件设计进程和支持进程所用的方法；对于上述进程，特别要注意与系统、软件和飞行认证相关的活动。注：协调可能是以表明事件（用于达成本文件所述的进程目标）转折点的进度表的形式出现。5．应定义各个硬件设计进程和相关支持进程的活动。此定义应处于一个可使硬件设计进程和相关支持进程受到控制的等级上。6．应选择设计环境，包括用来开发、验证和控制硬件项和生命周期数据的工具、程序、软件和硬件。a.若认证证书要求联合使用工具，就应在相应的计划中详细说明工具使用顺序；b.设计环境会影响产品的设计。第节所提供的建议可用于工具评估并确定何时工具规格是必需的。7．若衍生物是必需的并且还会影响验证，就应确定从已定计划进行衍生所需的进程。8．应该描述用来确定、管理和控制硬件、相关原始资料和硬件设计生命周期数据的方针、进程、标准和方法。9．当申请人希望让转包商来负责整个或部分硬件设计生命周期时，硬件计划应能确定方法来保证满足设计保证目标。10．应该描述用于执行硬件设计进程的进程保证方针和进程。11．应在PHAC中描述验证进程独立性、进程保证独立性和相关的组织职责。12．应在进程早期记录满足此建议的目标所用的方法，并把其通报给认证机构。这些方法应记录在PHAC中。注：应鼓励针对这些方法的任何变化所作的及时调整，以便尽可能地接受最终验证结果，并把其作为满足设计保证要求的适当证据。5硬件设计进程硬件设计进程产生的硬件项可以满足从系统要求分配到硬件的要求。如图5-1所述，本节描述了五个主要的进程。它们是：要求捕获、概念设计、详细设计、执行及产品过渡。这些设计进程可应用于任何等级的硬件项上，比如：LRU、电路板组以及ASIC/PLD。以下介绍的是每个进程、其目标以及应该用来减少可影响安全的设计和执行失误可能性的相关活动。重要的是，所有的进程都做了计划，并且细节都记录在硬件设计计划中。每个进程以及进程之间的相互作用都可以是反复的。对于每个反复操作，应处理所发生的变化对每个进程产生的影响，还应评估对先前的反复操作的结果产生的影响。注1：在设计进程中，证明像设计记录、设计审核记录和问题报告这样的进程产物是一个好的工程惯例。现有惯例提供了许多不同的方法（图表式的、数学的、基于数据库或文本的）来表示要求和设计执行进程，例如，示意图、硬件描述语言（HDL）、状态图、布尔表示法和图表法。注2：有些表示法适用于特定的进程或进程组，如：要求捕获、概念设计或详细设计；而有些则是用来更有效地实现具体的执行技术。无论使用何种表示方法，都应提供支持设计保证等级的证据。对于所用的每种设计表示法，都应考虑以下几点：1．不管使用何种表示法或组合表示法，都应遵从本文件的指导；2．设计表示法应该能让硬件项被可靠地复制；3．设计表示法中发生的微小变化可能会极大地影响设计执行进程；4．建立设计数据原始资料后，设计表示环境或方法可能会发生变化。若发生了这种情况，就应该评估所发生的变化对设计复制产生的影响；图5-1硬件设计生命周期HDL设计表示法使用的基于编码文本的方法表面上类似于软件表示法所用的方法。这种表面上的相似性会误导人们直接把软件验证方法用于HDL或其它硬件 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 语言的硬件表示法。对于使用HDL表示法的设计，本文件的建议可用于其设计保证。注：本文件中所述的构造进程适用于复杂硬件设计，包括ASIC和PLD。例如，下表就建立了典型ASIC/PLD进程到本文件图5-1所述进程的映射。表5-1典型ASIC/PLD进程映射典型ASIC/PLD进程进程部分较高等级的计划计划（第4节）ASIC/PLD结构确定安全评估（）ASIC/PLD要求捕获要求捕获（）ASIC/PLD初步设计（包括活动设计）概念设计（）ASIC/PLD详细设计（包括合成、掩码生成和融合文件）详细设计（）ASIC/PLD制造（包括外部制造和测试以及进程设计可编程元件）执行进程（）ASIC/PLD产品过渡产品过渡（）ASIC/PLD鉴定及验证（包括定时分析、行为仿真、门电平仿真及设计）审核及验证进程（）ASIC/PLD配置管理（包括工具及零件数据库）配置管理进程（第7节）5.1要求捕获进程要求捕获进程确定并记录了硬件项要求。这包括推荐的硬件项结构所用的衍生要求、技术选择、基本及可选功能性、环境和性能要求以及系统安全评估所用的要求。由于在设计中可能会出现其它的要求，此进程可能是反复的。5.1.1要求捕获目标要求捕获进程的目标是：1．确定、定义并证明要求。这包括从PSSA分配的要求以及从硬件安全评估衍生出来的要求；注：硬件要求的验证结果的溯源性将在第6节中讲述。在要求捕获进程中，建立这种溯源性是必要的。2．产生的衍生要求被反馈到适当的进程；3．要求冗长和失误被提供给适当的进程进行解决。5.1.2要求捕获活动要求捕获活动形成了一个反复的进程，有助于确保设计执行要求、系统要求和软件要求的一致性。要求捕获活动指南如下：1．应该证明分配给硬件项的系统要求。这可能包括识别要求，如：功能性和性能以及诸如分离、自检、可测性、外部接口、环境、测试及维修考虑事项、功率以及物理特性之类的架构考虑事项；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需求的要求在内，应该可追踪到下一个更高级别的要求。衍生要求应通过分级等级来进行识别并追踪到尽可能远。注：在要求捕获进程中，对所分配的硬件安全性要求的系统等级鉴定可能会发生。对于获得的硬件要求的认证，见第节。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．将衍生要求反馈到概念设计进程或其它相关进程。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．应该利用设计数据产生硬件项，实际上，这些资源打算供产品生产使用。这可能包括采购、配备、构造、检查和测试。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：验收测试并不会验证对每个生产单元的要求。子项测试可以作为验收测试的一部分。验收测试标准应该确保：1．确定电气测试。2．必要时应确定环境屏蔽测试。3．验收测试覆盖了符合安全要求所必要的那些设计方面。测试没有包含的有关安全的项或子项应该被确定，并且提供其它保证方法。这些方法可以包括分析、设计控制、统计进程控制或其它适当的方法。5.7连续生产此进程不在本文件范围之内，但是简要说明了影响设计保证的因素以完成生命周期。在符合生产数据及要求的常规基础上，此程序复制硬件项。需考虑的事项包括：1．生产进程或设计的变化管理保证：变化并不对现存的安全、标准或符合要求情况产生相反的影响。注：除文件正文提供的指南外，第11.1.1节包含了对先前开发的硬件的改良。当介绍元件退化时，参考第节。2．在符合批准的配置管理计划情况下，更新所有与变化相关的文件。6鉴定与验证进程本部分说明了鉴定进程和验证进程。鉴定进程保证：根据分配给硬件项的系统要求，硬件项衍生要求是正确并完整的。验证进程保证：硬件项实施满足包括衍生要求在内的所有硬件要求。6.1鉴定进程此处所讨论的鉴定进程要确保：通过结合使用目标进程和主观进程，根据分配给硬件项的系统要求，硬件项衍生要求是正确并完整的。鉴定可以在硬件项生效前后进行，然而，鉴定一般会贯穿整个设计生命周期来进行。注1：经验表明，关注这些要求的开发和鉴定可以较早发现开发周期中的细微错误或遗漏之处，并减少它们在以后设计或不适当的硬件性能中暴露的机会。此处讨论的鉴定进程并不会鉴定从系统要求分配而来的要求，因为这些要求已被假定为系统进程的一部分。另外，并不是所有的硬件项衍生要求都需要鉴定。可能影响系统安全或影响分配给系统其它部分的功能要求的系统决定应该被分类作为衍生要求并被鉴定。另外，可能约束以后的设计任务的设计决定和假设应该被鉴定为衍生要求。需要鉴定的衍生要求应该根据分配给硬件项的系统要求来鉴定。不能追踪到更高级要求的衍生要求应该根据它们被推导出的设计决定来鉴定。注2：包括电路执行特殊功能使用的单独电源的设计决定，可能导致要求的衍生以引导此电源的设计。这些衍生要求可能包括基于故障状态的安全要求，故障状态可能由接收来自此供电电源的电源的电路所支持的故障或功能故障导致。这些要求应该进行鉴定。设计决定转化为衍生要求的另一示例就是外围设备的存储地址分配。通常没有分配的要求依据，一旦有了，就会强迫随后的设计适应那些分配以确保设计能正确地转化到功能上。此衍生要求不必鉴定。6.1.1鉴定进程目标衍生硬件要求的鉴定进程目标如下：1．对照待验硬件项，衍生硬件要求是正确和完整的。2．对衍生要求的影响及安全性进行评估。3．遗漏及错误被反馈到相关进程以处理。6.1.2鉴定进程活动通过结合多种行为，可以满足硬件鉴定目标，如：审核、仿真、建立原型、建模、分析、服务经验、工程评估、开发及进行实验。鉴定进程活动的指南包括：1．应该确定需要鉴定的衍生硬件要求。2．对于条款1所确定的每项要求，应指出鉴定完成标准并满足如下条件：a.通过审核、分析或测试，对每项要求都进行了某种级别的鉴定。b.对每项要求的审核、分析或测试都是适合鉴定此要求的，尤其是关于安全性。c.与每项要求相联系的审核、分析或测试结果是正确的，并且要解释实际结果和预期结果之间的差异。当预先说明的预期结果跟审核和分析的情形不一样时，鉴定行为的结果应该跟要求一致，尤其是与安全要