DO-254标准编译稿

ID:65632422

大小:340.83 KB

页数:95页

时间:2021-10-14

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。
网站客服:3074922707
  
RTCA/DO-254机载电子设备硬件的设计保证指南DO-254标准编译稿RTCA/D0254标注nRTCA/DO-254机载电子设备硬件的设计保证指南机载电子设备硬件的设计保证指南二00八年E9月n前言本文件由航空无线电委员会(RTCA)180专委会(SC-180)制订,并于2000年4月19日由RTCA项目管理委员会批准通过。本指南是RTCASC-180和EUROCAE(欧洲民用航空设备组织)WG-46在协商一致的基础上共同编写完成的。RTCA公司是一家非营利性的组织,其宗旨是推进航空和航空电子系统科学与技术的发展,为公众的福祉服务。本组织起到了联邦顾问委员会的作用,并就当前航空方面的议题提出一致通过的建议。RTCA的目标包括但并不仅限于:•结合航空系统用户和供应商的技术要求,帮助政府和企业实现和履行彼此的目标及职责;•对航空业界在追求更高安全、系统性能和效能时所面临的系统技术问题进行分析,并提供解决方案;•推进相关技术应用的通过,以满足用户和供应商的要求,包括支持飞行的电子系统和设备的最低工作性能标准的制定;•帮助制定相关技术资料,以此确定国际民航组织、国际电信联盟以及其它感兴趣的国际组织的地位。本组织的建议通常被政府和民间组织作为决策的依据,并且还是众多联邦航空管理技术标准规程的基础。由于RTCA并不是美国政府的官方代理机构,本组织的建议未经美国政府或在这些建议所涉及到的任何问题上拥有法定权限的组织公布,不能被认定为官方政策。执行概要航空业界中复杂电子设备的使用和研发引起了新的安全和验证问题。为解决此问题,成立了RTCASC-180和EUROCAEWG-46oRTCASC-180和EUROCAEWG-46早在制订本文件时就已同意并组成了联合委员会。该联合委员会经特许为机载电子设备制定清晰和一致的设计保证指南,从而使机载电子设备可安全地发挥其既定功能。机载电子设备包括线可替代单元、电路板组件、专用集成电路、可编程逻辑器件等。本指南适用于现有的、新的以及刚出现的技术。n前言本文件由航空无线电委员会(RTCA)180专委会(SC-180)制订,并于2000年4月19日由RTCA项目管理委员会批准通过。本指南是RTCASC-180和EUROCAE(欧洲民用航空设备组织)VVG-46在协商一致的基础上共同编写完成的。RTCA公司是一家非营利性的组织,其宗旨是推进航空和航空电子系统科学与技术的发展,为公众的福祉服务。本组织起到了联邦顾问委员会的作用,并就当前航空方面的议题提出一致通过的建议。RTCA的目标包括但并不仅限于:结合航空系统用户和供应商的技术要求,帮助政府和企业实现和履行彼此的目标及职责;对航空业界在追求更高安全、系统性能和效能时所面临的系统技术问题进行分析,并提供解决方案;推进相关技术应用的通过,以满足用户和供应商的要求,包括支持飞行的电子系统和设备的最低工作性能标准的制定;帮助制定相关技术资料,以此确定国际民航组织、国际电信联盟以及其它感兴趣的国际组织的地位。本组织的建议通常被政府和民间组织作为决策的依据,并且还是众多联邦航空管理技术标准规程的基础。由于RTCA并不是美国政府的官方代理机构,本组织的建议未经美国政府或在这些建议所涉及到的任何问题上拥有法定权限的组织公布,不能被认定为官方政策。2n执行概要航空业界中复杂电子设备的使用和研发引起了新的安全和验证问题。为解决此问题,成立了RTCASC-180和EUROCAEWG_46。RTCASC-180和EUROCAEWG-46早在制订本文件时就已同意并组成了联合委员会。该联合委员会经特许为机载电子设备制定清晰和一致的设计保证指南,从而使机载电子设备可安全地发挥其既定功能。机载电子设备包括线可替代单元、电路板组件、专用集成电路、可编程逻辑器件等。本指南适用于现有的、新的以及刚出现的技术。本文件中的指导措施将供飞机系统所用的电子硬件项的供应商和飞机生产商使用。文件中确定了硬件设计生命周期进程,并对每一进程的目标和活动进行了描述。本指南适用于所有的硬件保证等级(由系统安全评估确定)。在本文件的制定进程中,委员会参考了其它的业内文件,包括美国动力机械工程师协会(SAE)航空推荐准则(ARP)文件ARP4754/EUROCAEED_79、高度集成或复杂飞机系统的验证准则、民航系统及设备的安全评估进程实施方针及方法以及RTCADO-178/EUROCAEED-12机载系统及设备验证的软件考虑因素。nL3与其它文件的关系L4相关文件111233455781导言L1目的L2范围L6复杂性考虑1.7其它方法或进程.....1.8文件概览2系统方面的硬件设计保证息流1.8.1从系统开发进程到硬件设计生命周期进程的信息流1.8.2从硬件设计生命周期进程到系统态发进程的信息流周期进程之间的信息流2.2系统安全评估进程.……2.3硬件安全评估1¥231硬件安全评估考虑事项10101414n232随机硬件故障的定量分析15233硬件设计失误及推翻的定性评估15234关于硬件故障情况分类的设计保证考虑事项163.1硬件设计生命周期进程3.2过渡标准4计划进程191919204.1计划进程目标204.2计划进程活动205硬件设计进程225」要求捕获进程5.1.1要求捕获目标5・1.2要求捕获活动5.2概念设计进程5.2.1概念设计目标5.2.2概念设计活动5.3详细设计进程5.3.1详细设计目标5.3.2详细的设计进程活动5.4实施进程24242425262627272728n541实施目标28542实施活动285・5生产转换进程28552生产转换活动295.6验收测试295・7连续生产306鉴定与验证进程316.1鉴定进程316.1.1鉴定进程目标316.1.2鉴定进程活动326・2验证进程326.2.1验证进程目标33622验证进程活动336.3鉴定和验证方法34631测试346.3.2分析35633审核36633.1要求审核36ivn6・3・3・2设计审核387配置管理进程40ivn7」配置管理目标7.2配置管理活动721配置识别7.2.2原始资料的建立uaj可题报告、跟踪和纠正行为724更改控制725发布、归档以及检索73数据控制类别8进程保证8.1进程保证目标8.2进程保证活动9认证联络进程9.1符合方法与规划…9.2符合证明10硬件设计生命周期数据10」硬件计划10.L1硬件方面认证计划10.1.2硬件设计计划..…10.1.3硬件鉴定计划..…10.L4硬件验证计划10.L5硬件配置管理计划404041414242434445454547474749495051515252vn10.L6硬件进程保证计划10.2硬件设计标准和指1021要求标准10.2.2硬件设计标准1023鉴定和验证标准.……10.2.4硬件存档标准10.3硬件设计数据10・3.1硬件要求10.3.2硬件设计表示数据…10.3.2.1概念设计数据10.3.2.2详细设计数据10・3.2・2・1顶级图.10・3・2・2.2组装图.10・3.2・2.3安装控制图5353535354545454555556565656103224硬件/软件接口数据10.4鉴定和验证数据10.4.1可追溯性数据10.4.2审核和分析程序10.4.3审核或分析结果1044测试程序575757585859Vn10.4.5测试结果5910.5硬件验收测试标准5910・6问题报告6010.7硬件配置管理记录6010.8硬件进程保证记录6010.9硬件完成概要6011附加考虑事项6211」先前开发硬件的使用6211.1.1对先前开发硬件的变更62机设备的更改62636364641LL3应用或设计环境的改变1U5JH置管理的附加考虑事项11.2商业化成品(COTS)元件的使用1LL4设计原始资料的升级.…牛的电子元件管理64的采购11・3产品服务经验65651131产品服务经验数据可接受性标准651132对产品服务经验数据的评估.•…651133产品服务经验评估数据66VIn1L4工具评估和鉴定6611.4.1工具评估和鉴定进程6711.4.2工具评估和鉴定数据70A.1简介74A.2功能故障路径分析A21功能故障路径分析方法A22功能故障路径分析数据或功能的设计保证方法A.3.l架构缓解A.3.L1架构缓解方法•…A.3.L2架构缓解的解决747575767676767777A3L3架构缓解数据区”出品服务经验A.321产品服务经验方法77A.3.2.2产品服务经验的解决77A.3.2.3产品服务经验数据78A.3.3先进验证方法78元素分析79A.3・3・L1元素分析法79A.33LL1选择元素分析标准viiin80A.3.3.LL2执行元素分析••…80A.3.3・L2元素分析结果的解决•…81出82A•邓安全分析82A3321特定安全分析法83A.3.322特定安全分析的解决....84A・3・3・2・3特定安全分析数据8484A.3.3.3形式法A.3・3.3.l形式法的方法论85A.333.2形式法的解决86区3&形式法数据86viiin1导言使用日益复杂的电子设备可获得更好的安全关键飞机功能,但这也会带来关于安全和验证的新的挑战。产生这些挑战是由于担心上述飞机功能会由于硬件设计失误的相反效应而变得更加脆弱,并且这些失误会由于硬件的日趋复杂化而更加难以把握。为抵消此风险的扩大,在设计和验证进程中,有必要的采用更一致的和可验证的方式来确保潜在的硬件设计错误的定位。由于机载电子设备的日趋复杂化、技术的进步以及在实际应用中和采用本文件所述程序的进程中获得的经验,必须根据已通过的RTCA/EUROCAE程序对本文件进行修订和审核。1.1目的本文件帮助研发组织为机载电子设备的开发提供了设计保证指南,从而使机载电子设备可在规定的环境中安全地发挥其预定的功能。本指南同样适用于现有的、新的以及正在开发的技术。本文件的目的是:1.确定硬件设计保证目标;2.描述这些目标的基本原则以确保对本指南的正确阐述;3.提供目标描述,以允许根据本指南和其它指南所作的各种改进;4.提供设计保证活动指南以满足设计保证目标;5.只要有合适的新技术,允许灵活选择满足本文件目标(包括对其的改进)必需的进程。本文件介绍的是为满足设计保证目标所应采取的活动,而并未详细介绍怎样进行某项设计。本指导文件所用的基本原理是基于电子设备所体现出来的系统功能的一种自上而下的透视法,而不是一种自下而上的透视法,或者仅基于用于实现某功能的一些特定设备元件的透视法。通过推进已知系统和硬件设计的决定,以及高效且有效的验证进程,自上而下的方法在处理安全设计失误时会更有效。例如,应在系统、组件、子组件、元件或硬件项的最高等级上进行验证;并且在此等级上,硬件项可满足其要求,验证目标也可实现。1.2范围本文件为机载电子设备(源自初始验证和后续验证后产品改进进程的概念)提供设计保证指南,以便确保连续的适航性。本文件基于与运输类飞机和设备所需的验证要求一致的陈述制定,但本文件的一部分并不适用于其它设备。n本文件描述了系统生命周期和硬件设计生命周期间的关系,以帮助理解系统和硬件设计保证进程的相互关系。文件中并未包括对系统生命周期(包括系统安全评估(SSA)和有效性)以及飞机验证进程的完整描述。只有与硬件设计生命周期有关时,才会讨论验证问题。而只有与硬件设计的适航性有关时,才会处理与生产、检测和维护硬件项的能力相关的方面。本文件指南适用于但不仅限于以下硬件项:1.线路可替代单元(LRU);2.电路板组件;3.定制微码元件,如专用集成电路(ASIC)和可编程逻辑器件(PLD),还包括任何相关的宏功能;4.集成技术元件:如混合电路和多芯模块;5.商业成品元件(COTS)o由于COTS元件供应商可能不会遵从本文件所述的设计进程,或提供必要的设计生命周期数据,因此其它的情形,尤其是针对COTS的考虑,会在第11节中进行讨论。本文件并未试图定义固件。固件应归类为硬件或软件,并且应采用适当的进程对其进行处理。本文件假设,在系统定义时,功能已分配给了硬件或软件。RTCADO-178/EUROCAEED_12提供了针对分配给软件执行程序的功能的指南。本文件提供的是针对分配给硬件的功能的指南。注:在系统确定和功能指定后,就可确定执行程序和设计保证的有效方法。在进行指定时,所有团体都应同意此系统决定。硬件项设计和验证所用工具的评估和规格见第1L4节。本文件并未提供关于组织结构或在这些结构中如何划分职责的指南。环境条件标准也不在本文件所涉及的范围之内。]3与其它文件的关系除了飞行性能要求外,1种关于硬件的国家和国际标准也是适用的。在有些团体中,可能会要求遵从这些标准。但是,本文件并未援引具体的国家或国际标准,也未提供某种方法使得这些标准可用作本文件的选项或补充。10n当本文件使用“标准”这一术语时,意指机载系统、机载设备、发动机或飞机制造商所用的工程特定标准。这些标准可能来自于制造商制定或采用的通用标准。标准指南见第10.2节。1.4相关文件SAEARP4754/EUROCAEED-79,即高度集成或复杂飞行系统验证准则,是关于高度集成或复杂飞行系统的开发指南的源文件。SAEARP4761,即民航系统及设备的安全评估进程实施方针及方法,是用于硬件设计保证进程的安全评估方法的源文件。RTCADO-178/EUROCAEED-12,即关于机载系统及设备验证的软件考虑因素,是软件开发保证的补充文件。RTCADO-160/EUROCAEED-14,即机载设备的环境条件及测试进程,可为设备设计者用作硬件项规格的初级环境测试标准。1.5如何使用本文件本文件供国际航空团体使用。为便于使用,尽可能少地参考了具体的国家规定和程序;相反,使用更多的还是通用术语。例如,术语“认证机构”用来指代表有权认证的国家进行审核的组织或个人。当另外一个国家或国家集团批准或参加此认证时,本文件就可使用,并且会在所涉及到的国家间的双边协议或谅解备忘录中相应地体现出来。本文件指南代表了航空团体的一致意见,囊括了机载电子设备设计保证方面最好的行业实践经验。对于本文件中提出的进程,其目的是提供可用于完成新硬件设计和后续改造的指南。先前为其它进程提供的硬件指南见第11.1节。可以理解,除了在此介绍的方法外,其它方法也可能为申请人获取并采用。在使用实例说明如何使用本指南时,不管是用图表形式还是叙述方式,不能认为这些实例是首选的方法。第11节讨论了关于特定已知情况(在这些己知情况下,第2节至第9节的一些目标可能不会实现)的其它情形。这些情形包括:已开发出的硬件的使用指南、COTS元件使用指南、产品服务经验指导、工具评估及规格指南。在附录A中,基于执行中的硬件设计保证等级,提供了关于必需的硬件设计生命周期数据的指南。附录B包括了执行A级和B级功能(除了第2节至第11节的指南外,也应使用这些功能)所用硬件的设计保证技术指南;根据申请人的意愿,附录B也可应用于硬件的C级和D级设计保证。10n本文件中所用的术语表见附录C。附录D是本文件所用的缩略词汇表,列出了这些缩略词的全称。对于列出的表单,并不意味着其下的子项在任何情况下都是全面的,也不是说所有的子项都对应于任何特定的产品。本文件中的注释用于提供说明性材料、强调某一点或者引起对相关主题的注意。当然,这些注释并不仅限于上下文范围之内。注释并不包含指南。当提供指南时会用“应该”一词。“可能”则用于选择性文本。本文件所用的术语“硬件项”则是用来描述作为本文件主题的电子设备。除非特意说明,在本文件中都会采用限定词“硬件”。使用术语“要求”时是指“硬件要求系统或软件限定词通常会特意说明,如“系统要求”。注:各种行业咨询文件和航空要求文件并不总是使用一致的术语。例如,联邦航空规程(FAR)21和联合航空要求(JAR)21中使用“产品”来指代飞机、飞机发动机、或螺旋桨。文件SAEARP4754/EUROCAEED_79使用“产品”这一术语来指代硬件、软件、部件或根据确定的一组要求形成的系统。请读者注意在使用术语时的这些以及其它差异。本文件使用的是词汇表中的定义。]6复杂性考虑尽管有W种关于术语“复杂性”的分类被用于描述电子器件,比如简单、复杂和高度复杂,但这些分类之间的区别并未严格确定。要在此确定复杂性间的区别,需要根据使用确定性方法达到可行性验证范围所必需的可行性和困难程度而进行。应分等级,按照集成电路、电路板和LRU的顺序对硬件的复杂性进行检查;其中,复杂性包括可能不可测的寻址功能,如多用途设备中未用的模式和时序机中可选的隐藏状态。在不存在异常现象的所有可预见的操作条件下,只有当符合设计保证等级的确定性测试和分析可确保正确的操作性能时,硬件项才可定义为简单。若某硬件项不能归入简单一类,它就应归入复杂一类。全部由简单部件构成的部件可能是复杂部件。对于含有器件(如ASIC或PLD)的部件,若其符合本节描述的简单标准,就可认为是简单的。对于复杂部件,推荐的提供设计保证方式应该早已在硬件设计生命周期中经认证机构同意使用,以减小进程风险。对于简单硬件项,设计进程不需要提供大量文件。对于简单硬件项,需要执行并证明验证和配置管理支持进程,但并不需要提供大量文件。因此,为遵从本文件,在10n设计简单硬件项时削减了费用。本文件的主要影响将体现在复杂硬件项的设计上。1.7其它方法或进程除了本文件所述的以外,其它方法或进程也可能被用于提供硬件设计保证。对于这些方法和进程,应根据其满足可用准则的能力来进行评估。可选方法或进程应在执行前由认证机构批准。当通过比较本文件来评估可选方法或进程时,除了直接与可用准则比较外,申请人还可使用以下的指南来降低进程风险。评估可选方法或进程应考虑的因素包括:1.在代替本文件介绍的进程使用时,满足第2节至第9节中一个或多个目标的进程应体现出同等的设计保证等级;2.应该评估所推荐的其它方法或进程在满足硬件设计保证目标时产生的影响;3.应该评估所推荐的其它方法或进程对生命周期数据产生的影响;4.使用推荐方法或进程的合理性应该用这样的证据来证明:使用这些方法或进程可产生预期结果。1.8文件概览图1”是本文件所有章节的概图,表明了这些章节彼此之间的关系,以及与其它相关进程的关系。这并不是为了描述数据流,而是为了表明哪些章节及外部进程是相关的。10n图1”文件概览10n2系统方面的硬件设计保证硬件设计保证从系统等级开始,系统功能会分配给硬件,而同时也会指定其相应的系统开发保证等级。单个的系统功能可以分配给硬件项、软件元件或软硬件组。与功能相关的安全要求来自于系统透视、软件透视和硬件透视,从而就可确定满足这些要求所必需的可靠性等级和保证等级。图2-1阐示了机载电子系统和设备的系统开发进程与安全评估、硬件开发以及软件开发进程的关系。图2“机载系统、安全评估、硬件和软件进程间的关系在图中有四处重叠区域,分别为:安全/硬件,安全/软件,硬件琳件和安全/硬件/软件。这些重叠表明了这些进程间的关系和相互作用;而在这些进程中,系统要求可能会产生一些在多进程范围及设计保证指南之内的要求。例如,包含安全要求的硬件功能会包括安全评估进程和硬件设计生命周期进程。这些重叠表明,需要用进程间的相互作用来确保系统功能保证要求的满足。本文件并未探讨系统或软件保证进程。但是,在协调硬件功能的设计保证时,申10n请人也可能想利用系统或软件进程中的活动提供的保证。这些关系和相互作用在第2.1.1节至第2.1.3节中会进一步探讨。2」信息流生命而加进程间的信息流如图2-2所示。以下部分所述的是从系统开发进程到硬件设计生命周期进程间的信息流、从硬件设计生命周期进程到系统开发进程间的信息流以及硬件设计生命周期进程与软件生命周期进程间的信息流。注:这些都被认为是反复的进程,并且在硬件设计生命周期中还会产生变化。软件卜|空1硬件设图2-2系统开发进程2.1.1从系统开发进程到硬件设计生命周期进程的信息流此信息流可能包括:1.分配给硬件的设计和安全要求;2.每种功能的设计保证等级,还有其相关要求和故障条件,但前提是此功能可用;3.分配的可能性,以及风险出现时,硬件功能故障出现的可能性;10n1.硬件儆件接口描述2.关于安全策略及设计限制的要求,如可测试性、设计方法以及硬件结构;3.将通过硬件等级验证来执行的系统验证活动的要求;4.分配给硬件的安装要求、人体工程学要求以及环境要求;5.可能会对要求产生影响的综合问题报告o之所以会这样,是由于一些活动的缘故,如:系统验证、系统要求的产生或SSA。2.1.2从硬件设计生命周期进程到系统开发进程的信息流此信息流可能包括:1.要求的执行进程,如:机械制图、简图和零件列表;2.可能会影响任何分配的要求的硬件衍生要求;3.装置结构,包括故障限度;4.在硬件设计生命周期中进行的任何必需的系统验证和审核活动的证明;5.产品安全分析数据,如:a.与SSA进程有关的特定硬件功能故障的可能性及故障率;10nb.常见故障分析;c.隔离范围及普通故障缓解策略;d.与系统要求相关的潜在分析数据。例如:故障监视、故障检测周期和不可测故障的硬件准备。1.将通过系统等级验证来实施的硬件验证活动的要求;2.关于安装要求和环境条件(是将要进行的分析所必需的)的假设和分析方法;3.可能会影响系统、软件或分配的硬件要求的问题或变化报告。2.1.3硬件设计生命周期进程与软件生命周期进程之间的信息流此信息流可能包括:1.硬件/软件集成所需的衍生要求,如:草案的确定、定时限制以及软硬件间接口的寻址方案;2.需要协调硬件和软件验证活动的情况;3.硬件和软件之间所确定的不兼容性,这可能也是报告和校正行动系统的一部分;4.也可应用的系统进程的安全评估数据。5.2系统安全评估进程现有三个系统安全评估进程,它们分别是:功能危险性评估(FHA),初步系统安全评估(PSSA)和SSA。这些进程被用于建立可应用于系统开发保证进程的系统安全目标,还用于确定系统功能是否达到了安全目标。SSA进程应该把安全目标转化成系统和设备安全要求。这些要求应包括系统及设备的功能及结构的基本安全目标和安全特征。SSA进程和系统开发进程把这些安全要求分配给了硬件。系统开发保证等级现有五个等级,A级至E级,对应五类故障情况:灾难性的、危险的/极严重的、严重的、轻微的和无影响的。表2-1把硬件设计保证等级和五类故障情况联系了起来,并确定了硬件故障条件和它们对应的设计保证等级。首先,各个硬件功能的硬件设计保证等级是通过SSA进程、使用FHA辨别可能的危险来确定的;然后,PSSA进程把安全要求和相关的故障情况分配给硬件执行的功能。在硬件设计生命周期中,安全、系统和硬件进程间可能存在循环反馈,以确保设计制造的硬件会满足分配给硬件的系统安全、功能和性能要求。10n表2”硬件设计保证等级的定义及其与系统保证等级的关系系统开发保证等级故障情况分类故障情况描述硬件设计保证等级定义A级灾难性的故障情况会妨碍持续安全飞行和着陆。对于硬件功能,通过如硬件安全评估可以看到,硬件功能故障或异常行为会引起能导致飞机发生灾难性故障情况的系统功能故障。B级危险的/极严重的故障情况会降低飞机的性能或空勤组处理异常运行情况的能力,从而极大地降低安全系数或功能,导致身体痛苦或增加工作量;这样,就不能依靠空勤组精确地或完全地执行其任务;并且还会对乘员产生不利影响,包括对这些成员中的一小部分造成严重伤害或潜在的严重伤害。对于硬件功能,通过如硬件安全评估可以看到,硬件功能故障或异常行为会引起能导致飞机发生危险的/极严重的故障情况的系统功能故障。C级严重的故障情况会降低飞机的性能或空勤组处理异常运行情况的能力,从而极大地降低安全系数或功能,并极大地加重空勤组的工作量或降低空勤组的效率,使乘员产生不适,包括对其造成伤害对于硬件功能,通过如硬件安全评估可以看到,硬件功能故障或异常行为会引起能导致飞机发生严重故障情况的系统功能故障。12nD级轻微的故障情况不会极大地降低飞机安全,并且空勤组的活动也控制在其能力范围之内。轻微故障情况可能包括:安全系数或功能的轻微降低、空勤组的工作量的轻微增加(如,例行飞行计划的改变)或给乘员造成的一些不便。对于硬件功能,通过如硬件安全评估可以看到,硬件功能故障或异常行为会引起能导致飞机发生轻微故障情况的系统功能故障。E级无影响的故障情况不会影响飞机的运行能力,也不会增加空勤组的工作量。对于硬件功能,通过如硬件安全评估可以看到,硬件功能故障或异常行为会引起系统功能故障,但不会对飞机的运行能力或空勤组的工作量产生影响。对于确定为E级的功能,不需要本文件的进一步指导,但本文件的指南可用做参考。12n1.3硬件安全评估硬件安全评估与SSA进程一起执行,并用于支持SSA进程。该安全进程是为了证明可应用的系统和设备(包括硬件)满足了可应用的飞机验证要求的安全要求。若系统进程把安全、功能和性能要求分配给硬件,硬件安全评估就可确定各种功能的硬件设计保证等级,并有助于确定将要用到的合适的设计保证策略。1.1.1硬件安全评估考虑事项硬件项设计者可能会采取适当的设计保证策略,遵从分配给硬件的安全要求和硬件设计保证等级。单独的设计保证等级和策略可以应用于整个硬件项,而也可认为硬件项拥有独立的功能故障路径(FFP),这样就可提供混合设计保证等级或设计保证策略。功能故障路径分析(FFPA)可以用来判断硬件项部件较低的设计保证等级,或提供由不同方法或不同的产品服务历史来执行的不同功能。注:FFPA将在附录B的第2部分介绍。此分析方法尽管在书面上规定用于处理附录B中的问题,但它也适用于任何设计保证等级。若硬件项所含功能单独拥有不同的设计保证等级,这种情形可用下列方法之一处理:•可以保证整个硬件项为最高设计保证等级。•若硬件的功能、接口和共享资源可免受较低保证等级的功能的不利影响,就可根据硬件安全评估确定的那样,单独地确保单个硬件功能为各自的硬件设计保证等级。共享资源的设计保证应该就是最高级功能的设计保证等级。针对硬件安全评估的建议包括:1.反复的硬件安全评估和设计应该确定衍生硬件安全要求,并保证满足分配给硬件的系统安全要求,还要保证满足衍生要求;2.这些衍生要求应包括硬件结构安全要求、电路及元件的安全要求、以及防止异常行为的安全要求(包括结合特定硬件结构及功能的安全特征),例如:a.电路和元件冗余;b.电路或元件间的分离或电隔离;c.电路或元件间的差异;81nd.电路或元件的监视;e.保护或重新配置机器;f.电路和元件的随机故障和潜在故障的容许故障率和可能性;g.使用或安装的限制;1】.干扰的防止、管理以及恢复。1.硬件设计保证进程和硬件安全评估应共同确定具体的遵从方式及每种功能的设计保证等级,还应确定已达到了可以接受的设计保证等级。注」异常行为可能由硬件项中的随机故障或设计失误引起,或者对硬件的干扰引起。硬件设计者可能会为硬件项功能选择较高的硬件设计保证等级。例如,在进行需要较高等级设计保证的安装时,会预料到硬件项功能的重新利用。硬件安全评估可能会运用各种定性和定量的评估方法。这可能包括:故障树分析(FTAX常规分析、故障形式和后果分析、以及可用于随机故障的定量评估所用的统计可靠性分析法。2.3.2随机硬件故障的定置分析基于硬件故障率、冗余、分离与隔离、故障形式统计、可能性分析、元件减少、压力分析和制造进程控制的统计故障评估和预测方法已经证明,这些都是对随机硬件故障进行定量风险因素评估可以接受的方法。2.3.3硬件设计失误及推翻的定性评估不像硬件随机故障那样,设计失误和一些类型的“推到重来”在统计学上都是不可预测的,并且它们都可能以普通故障的形式越过冗余界限。应该对将要使用的冗余管理方法和定量分析方法进行选择,以便在必要时可以排除或减轻潜在的普通故障以及“推到重来”的影响。尽管定量评估很困难,但仍可利用定性安全评估方法有效地评估由设计失误和“推到重来”带来的安全风险。像故障树分析、普通分析和功能故障形式及影响分析(F-FMEA)这样的分析方法基本是定性的方法,可以用来处理硬件设计失误和“推到重来:更具体地说,这些方法可以确定硬件设计失误和“推到重来”的潜在影响,还有助于确定通过何种方式可以排除或减轻这些影响。使用这些方法后,硬件安全评估就有助于确定将要使用的硬件设计保证策略,并且在硬件设计进程中可反复使用,从而就可定性地确定所选策略达到的保证等级。81n2.3.2关于硬件故障情况分类的设计保证考虑事项由于系统故障情况越来越严重,为确保相关故障情况的减轻而必需的硬件设计保证量也随之增长。对于所有的设计保证等级,应该研究出一种方法或策略来确保合适的设计保证等级。图2-3列出了研究适当设计保证策略的决定生成流程。建议包括:1.对于在硬件中执行的A级或B级功能,设计保证考虑事项应处理硬件功能潜在的异常行为和潜在的设计失误;2.当研究每个执行中的功能的设计保证策略时,应该使用图2-3中列出的决定生成流程;3.除了在第3节至第1节中提供的建议外,附录B中所述的策略也应该用于A级和B级功能;4.设计保证策略应选择为硬件结构和用途的功能,以及已选的硬件执行技术的功能。不同的技术、元件选择和元件用途提供了各种程度的硬件设计生命周期信息和各种程度的防止相关设计失误及其影响的措施。在相同的硬件项之内,对于不同的功能路径,最适合的设计保证方法也会有所不同。在图2-3中,决策和活动块中的数字指的是根据进一步说明决定或活动的图表得出的编号项。1.启动评估进程。对于所有的设计保证等级,都应该研究出相应的方法或策略来保证合适的设计保证等级。2.确定FFP设计保证等级。对于每个确定的硬件项,确定并证明与部件和设计保证等级相关的FFPO81n启动评估:D级或E级图2-3硬件设计保证策略的决定进程3.FFP的硬件执行是简单的还是复杂的?对于硬件设计保证的A级或B级FFP,按L6所述来确定硬件是简单还是复杂。4.研究A级或B级复杂FFP的设计保证策略。若FFP是复杂的并且为A级或B级,就可使用附录B中所述的附加策略来确定合适的设计保证策略、相应的执行概念以及失误缓解方法。对于每个A级或B级FFP,应使用深层分析、产品服务经验或结构缓解来确定设计保证策略。81n若所选方法不能完全缓解潜在的故障和异常行为,装置中的A级FFP就可能需要不止一种方法。3.策略合适吗?确定设计保证策略中是否有不足之处;若策略中存在不足或希望获取的数据中可能会存在不足,请提出别的设计保证、执行或结构策略来修改该策略以便弥补不足之处。当设计保证策略可接受时,请为每个FFP的设计保证进程提供文件证明。该策略还应该用来处理认证机构参与的项目,如计划中的重大事件、项目审核和监督活动。4.证明可应用的故障安全情况。确定合适的故障安全设计结构和硬件项特征,然后进行分析,以满足系统的有效性和完整性。证明故障安全设计情况和相关的普通分析、可能性分析、结构或其它特征。5.证明设计保证方法及策略。对于系统验证计划或硬件验证方面的计划(PHAC)中可应用的设计保证方法和策略,应进行证明并获取认证机构的审批。6.应用此方法。根据已通过的计划和文件(明显遵从了已通过的计划和策略)中确定的适当设计保证方法进行硬件设计。81n3硬件设计生命周期本节列出了第4节至第9节中讨论的硬件设计生命周期。本文件既未规定首选的生命周期模型,也未为执行组织暗示一种结构。硬件设计生命周期同样适用于新系统或设备以及现有系统或设备的改进型的开发。每项工程的生命周期都应基于进程和活动的选择和安排,并且这些进程和活动应由工程特性决定,如:要求稳定性、己开发硬件的使用以及硬件设计保证等级。硬件设计生命周期可以是反复的,也就是说,根据逐渐的发展和进程间的反馈,可以进入、重新进入以及修改生命周期。3.1硬件设计生命周期进程硬件设计生命周期进程是:1.如第4节所述,硬件计划进程可以对一项工程的硬件设计和支持进程进行确定和调整;2.如第5节所述,硬件设计进程可产生设计数据和最终的硬件项。这些进程是要求捕获、概念设计、详细设计、执行以及产品过渡;3.如第6节至第9节所述,支持进程产生的硬件设计生命周期数据可以保证硬件设计生命周期及其输出的正确性以及对其的控制,这包括:计划、设计、硬件安全评估和支持进程。这些进程特别与计划和设计进程同时执行。这些进程是:鉴定、验证、配置管理、进程保证以及认证联络。3.2过渡标准在不同开发平台上用不同的子项来开发硬件项是一个挑战,因而需要一种方法来适度地控制设计进程,以便在先前进程所有的项目都完成前不会启动下一个进程。过渡标准,即用来评估从一个进程到另一个进程的运动进程的最小数据,可以用在关键的进程点上。在计划进程中进行的分析应该确定了过渡标准的使用。没有必要在计划中确定的每对进程步骤间建立过渡标准。过渡标准的选择应该可以处理对安全的影响。例如,在为获得某项功能的认证证书而进行的验证前,该功能的要求需要用文件证明,并且应在配置管理下执行该功能。应在硬件计划中对过渡标准进行证明。使用过渡标准并不暗指任何特殊的生命周期模型,也不会阻止像快速原型设计和并行工程这样的开发策略的实施。81n4计划进程本节讲述的是用来控制硬件项开发的硬件计划进程。本进程提出了可能包含于一个或多个文件中的硬件计划。若使用了多个文件,主计划应该包含有关于支持文件的适当参考书目。对于涵盖特定的设计生命周期进程(如:配置管理或进程保证)的标准文件,若其满足可应用的计划目标,就是可接受的。4.1计划进程目标硬件计划进程的目的是确定功能和适航性要求转换成硬件项的方式,并且硬件项还要有适度的保证使其可以安全地执行预定功能。硬件计划进程的目标是:1.硬件设计生命周期已确定;注:活动、重大事件、输入、输出和组织职责都可能包含于计划之中。2.标准已选择和确定;3.硬件开发及验证环境已选择或确定;4.遵从硬件设计保证目标的方式(包括用234中的方法确定的策略)已上报认证机构。5.些新的和正在开发的技术、工具和进程可能需要改变计划进程的细节。因此,灵活性是本计划进程的一个关键因素。4.2计划进程活动计划进程指南包括:1.应该确定硬件设计生命周期进程(如果可以应用,还包括过渡标准)和单个进程间的相互关系,比如其时序和反馈机制;2.应确定并说明推荐的设计方法。这包括对预计硬件设计的考虑和推荐的验证方法的合理性;3.硬件设计标准(包括标准的衍生标准)若要用于工程中,应对其进行定义。这包括从通用标准到公司或项目的具体标准;注」通过提供从以前开发中得到且已证明的工程惯例,标准就有助于减小不可测设计失误出现的可能性◎当把标准应用到新设计和新技术上时,申请人和开发者应注意:可适用性可能已经失效。由于设计限制、与系统要求的矛盾或与新技术的不兼容性,这些标准的衍生81n标准可能也是必需的。若使用了标准,计划进程就是审核合适的衍生标准的机会。1.应该确定协调硬件设计进程和支持进程所用的方法;对于上述进程,特别要注意与系统、软件和飞行认证相关的活动。法二协调可能是以表明事件(用于达成本文件所述的进程目标)转折点的进度表的形式出现。2.应定义各个硬件设计进程和相关支持进程的活动。此定义应处于一个可使硬件设计进程和相关支持进程受到控制的等级上。3.应选择设计环境,包括用来开发、验证和控制硬件项和生命周期数据的工具、程序、软件和硬件。a.若认证证书要求联合使用工具,就应在相应的计划中详细说明工具使用顺序;b.设计环境会影响产品的设计。第11.4节所提供的建议可用于工具评估并确定何时工具规格是必需的。4.若衍生物是必需的并且还会影响验证,就应确定从已定计划进行衍生所需的进程。5.应该描述用来确定、管理和控制硬件、相关原始资料和硬件设计生命周期数据的方针、进程、标准和方法。6.当申请人希望让转包商来负责整个或部分硬件设计生命周期时,硬件计划应能确定方法来保证满足设计保证目标。7.应该描述用于执行硬件设计进程的进程保证方针和进程。8.应在PHAC中描述验证进程独立性、进程保证独立性和相关的组织职责。9.应在进程早期记录满足此建议的目标所用的方法,并把其通报给认证机构。这些方法应记录在PHAC中。注3鼓励针对这些方法的任何变化所作的及时调整,以便尽可能地接受最终验证结果,并把其作为满足设计保证要求的适当证据。5硬件设计进程硬件设计进程产生的硬件项可以满足从系统要求分配到硬件的要求。如图5-1所述,81n本节描述了五个主要的进程。它们是:要求捕获、概念设计、详细设计、执行及产品过渡。这些设计进程可应用于任何等级的硬件项上,比如:LRU、电路板组以及ASIC/PLDO以下介绍的是每个进程、其目标以及应该用来减少可影响安全的设计和执行失误可能性的相关活动。重要的是,所有的进程都做了计划,并且细节都记录在硬件设计计划中。每个进程以及进程之间的相互作用都可以是反复的。对于每个反复操作,应处理所发生的变化对每个进程产生的影响,还应评估对先前的反复操作的结果产生的影响。注h在设计进程中,证明像设计记录、设计审核记录和问题报告这样的进程产物是一个好的工程惯例。现有惯例提供了许多不同的方法(图表式的、数学的、基于数据库或文本的)来表示要求和设计执行进程,例如,示意图、硬件描述语言(HDL)、状态图、布尔表示法和图表法。漫2:有些表示法适用于特定的进程或进程组,如:要求捕获、概念设计或详细设计;而有些则是用来更有效地实现具体的执行技术。无论使用何种表示方法,都应提供支持设计保证等级的证据。对于所用的每种设计表示法,都应考虑以下几点:1.不管使用何种表示法或组合表示法,都应遵从本文件的指导;2.设计表示法应该能让硬件项被可靠地复制;3.设计表示法中发生的微小变化可能会极大地影响设计执行进程;4.建立设计数据原始资料后,设计表示环境或方法可能会发生变化。若发生了这种情况,就应该评估所发生的变化对设计复制产生的影响;81n81支持进程•审核与验证比用/砧a过、图5-1硬件设计生命周期HDL设计表示法使用的基于编码文本的方法表面上类似于软件表示法所用的方法。这种表面上的相似性会误导人们直接把软件验证方法用于HDL或其它硬件规范语言的硬件表示法。对于使用HDL表示法的设计,本文件的建议可用于其设计保证。注j本文件中所述的构造进程适用于复杂硬件设计,包括ASIC和PLD。例如,T表就建立了典型ASIC/PLD进程到本文件图51所述进程的映射。表5“典型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)81nASIC/PLD产品过渡产品过渡(5.5)ASIC/PLD鉴定及验证(包括定时分析、行为仿真、门电平仿真及设计)审核及验证进程(5.6)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.应确定执行进程必需的衍生要求。应单独确定涉及安全问题的硬件安全评估衍81n生出的要求。注:衍生要求可以处理诸如以下一些情形:“•特定限制,用于确保较高设计保证等级的功能可经受较低设计保证等级功能的异常情况(可在较低设计保证等级功能的界面上看到)。b.顾及到典型及全刻度数据值还有数据字或控制寄存器里比特高低状态的数据输入范围。c.上电复位和其它复位状态。d.电源电压及电流要求。e.执行与时间相关的功能,如滤波器、积分器以及延迟。f无论预期与否,状态机的转换都是可能的。g.正常和最坏情况下的信号定时关系或电气状态。h.信号噪声和串绕。i.异步逻辑电路的信号失灵。j.对控制未用功能的明确限制。5.应将衍生要求反馈到SSA程序,以便评估对系统要求所造成的影响。6.具有适用公差情况下,应该以定量术语的方式来证明要求数据。这并不包括对设计或验证解决方案的说明。7.应将此进程中发现的要求遗漏或错误提供给系统开发进程。8.这些要求,包括那些生成用以满足PSSA需求的要求在内,应该可追踪到下一个更高级别的要求。衍生要求应通过分级等级来进行识别并追踪到尽可能远。注:在要求捕获进程中,对所分配的硬件安全性要求的系统等级鉴定可能会发生。对于获得的硬件要求的认证,见第6.1优5.2概念设计进程概念设计进程产生高级设计概念,此概念可以被评估以测定最终设计实施满足要求的可能性。通过使用诸如功能框图、设计和结构说明、电路卡装配略图以及底座略81n图之类的项目,这是可以完成的。5.2.1概念设计目标概念设计的目标如下:1.根据要求来开发硬件项“概念设计九2.将产生的衍生要求反馈到要求捕获或其它适8181当的程序。3.要求遗漏和错误被提供给适当的程序以解决O81815.2.2概念设计活动概念设计活动指南包括:1.应对硬件项进行高级描述。可以包括:a.与安全性有关的结构约束,包括那些有必要对设计错误、功能和元件过压、可靠性及严重缺陷进行处理的结构约束。b.确定对软件或其它系统元件的任何应用约束。2.应该进行识别的主要元件。应该确定它们满足硬件安全要求的作用方式,包括不使用的功能所造成的影响。3.应该将包括接口定义在内的衍生要求反馈到要求捕获进程。4.应将要求遗漏和错误反馈到适当的进程予以解决。5.应该确定待提供的可靠性、维护及测试特征。81n注J相关方面就概念设计目标已经得以满足的一致意见是备受推荐的。设计审核典型地用于实现这种一致性意见。5.3详细设计进程利用硬件项要求和概念设计数据,详细设计进程产生详细设计数据作为详细设计的基础。5.3.1详细设计目标详细设计进程目标为:1.从硬件项要求和概念设计数据中开发详细设计。2.将衍生要求反馈到概念设计进程或其它相关进程。3.将要求遗漏或错误提供给适当的进程以解决。5.3.2详细的设计进程活动详细设计进程活动指南包括:1.硬件项的详细设计数据应该基于要求和概念设计数据产生。可以包括装配和互相连接数据、元件数据、HDL、测试方式和软硬件接口数据。注」在详细设计进程中,验证方法被非正式地用于帮助在本进程所做出的技术决定。例如,对诸如逻辑定时和参数变化等设计参数的分析能够提供以设计决定为基础的信息。2.在必要时应该应用结构设计技术。这些技术可以包括为适当的功能而建立安全监控器,功能和安全监控器的不同排除了会影响安全的设计错误以及故障容许设计。3.在需要的地方设计测试特征,以允许验证安全要求。注:从某种程度上说,开发这种设计是很重要的:不但在硬件设计生命周期,而且作为验收测试和恢复性能测试场的一部分,某些测试特征都可以被验证。4.应该对不使用的功能进行评估,以确定可能对安全造成的影响。应该对反作用进行处理。5.应该确定硬件项设计、安装或操作方面的约束,如果不遵守这些约束;就有可能影响这些项的安全。6.应该将详细设计进程期间产生的衍生要求反馈到概念设计或其他相关进程。7.应将详细设计进程期间发现的要求遗漏或错误提供给相关进程以解决。5.4实施进程81n实施进程利用详细的设计数据来产生作为测试活动输入的硬件项。5.4.1实施目标实施进程目标为:1.产生利用典型制造进程实施硬件详细设计的硬件项。2.硬件项实施、装配以及安装数据均完整。3.衍生要求反馈到详细设计进程或其它适当进程。4.要求遗漏及错误被提供给相关进程以解决。5.4.2实施活动实施活动指南包括:1.应该利用设计数据产生硬件项,实际上,这些资源打算供产品生产使用。这可能包括采购、配备、构造、检查和测试。2.将实施进程产生的衍生要求反馈到详细设计进程或其它适当进程。3.将实施进程发现的遗漏及错误提供给相关进程以解决。5.5生产转换进程在该进程中,生产数据、测试设备和所有资源都应被检查以确保生产的有效性和适宜性。生产转换进程利用实施输出和验证进程将产品投入生产。5.5.1生产转换目标此进程目标如下:1.建立原始资料,包括需要来支持硬件项一致复制的所有设计和生产数据。2.确定并证明关于安全性的生产要求,并建立生产控制。3.衍生要求被反馈到实施进程或其它相关进程。81n1.错误及遗漏被提供给相关进程以解决。5.5.2生产转换活动生产转换活动指南包括:1.生产数据应该根据配置好的设计数据进行准备。2.为了其完整性以及与设定的设计数据一致,应该检查生产数据。注:将任何条件强加到生产构造文件上,这都超出了本文件范围。3.生产转换进程中的任何变化或改善都应该被评估以确保符合所有的产品要求,尤其是安全要求。任何不适应消费者或合格证明要求的变化都应该由相关部门批准。4.应该明确说明与安全相关的生产要求,以便在生产进程中控制。5.应该确定开发验收测试标准所必须的数据。6.确定的遗漏或错误提供给相关进程以解决。7.6验收测试验收测试证明生产的、改良的或修理后的产品符合标准基以建立的单元的根本属性。通过工程判断选择这些根本属性,并表明产品能够符合单元开发的要求。注1:“样品”产品的配置控制并不是验收测试活动的功能。本文件第7部分所描述的配置管理计划应该说明申请计划怎样进行此活动。此文件的范围包括了验收测试标准的确定,而后者则包括通过/失败条件。包括验收测试在内的生产活动被认为不在本文件范围之内。»2:验收测试并不会验证对每个生产单元的要求。子项测试可以作为验收测试的一部分。验收测试标准应该确保:1.确定电气测试。2.必要时应确定环境屏蔽测试。81n1.验收测试覆盖了符合安全要求所必要的那些设计方面。测试没有包含的有关安全的项或子项应该被确定,并且提供其它保证方法。这些方法可以包括分析、设计控制、统计进程控制或其它适当的方法。2.7连续生产此进程不在本文件范围之内,但是简要说明了影响设计保证的因素以完成生命周期。在符合生产数据及要求的常规基础上,此程序复制硬件项。需考虑的事项包括:1.生产进程或设计的变化管理保证:变化并不对现存的安全、标准或符合要求情况产生相反的影响。注:除文件正文提供的指南外,第〃./•/节包含了对先前开发的硬件的改良。当介绍元件退化时,参考第1L2节。2.在符合批准的配置管理计划情况下,更新所有与变化相关的文件。81n6鉴定与验证进程本部分说明了鉴定进程和验证进程。鉴定进程保证:根据分配给硬件项的系统要求,硬件项衍生要求是正确并完整的。验证进程保证:硬件项实施满足包括衍生要求在内的所有硬件要求。6.1鉴定进程此处所讨论的鉴定进程要确保:通过结合使用目标进程和主观进程,根据分配给硬件项的系统要求,硬件项衍生要求是正确并完整的。鉴定可以在硬件项生效前后进行,然而,鉴定一般会贯穿整个设计生命周期来进行。注1:经验表明,关注这些要求的开发和鉴定可以较早发现开发周期中的细微错误或遗漏之处,并减少它们在以后设计或不适当的硬件性能中暴露的机会。此处讨论的鉴定进程并不会鉴定从系统要求分配而来的要求,因为这些要求已被假定为系统进程的一部分。另外,并不是所有的硬件项衍生要求都需要鉴定。可能影响系统安全或影响分配给系统其它部分的功能要求的系统决定应该被分类作为衍生要求并被鉴定。另外,可能约束以后的设计任务的设计决定和假设应该被鉴定为衍生要求。需要鉴定的衍生要求应该根据分配给硬件项的系统要求来鉴定。不能追踪到更高级要求的衍生要求应该根据它们被推导出的设计决定来鉴定。注2:包括电路执行特殊功能使用的单独电源的设计决定,可能导致要求的衍生以引导此电源的设计。这些衍生要求可能包括基于故障状态的安全要求,故障状态可能由接收来自此供电电源的电源的电路所支持的故障或功能故障导致。这些要求应该进行鉴定。设计决定转化为衍生要求的另一示例就是外围设备的存储地址分配。通常没有分配的要求依据,一旦有了,就会强迫随后的设计适应那些分配以确保设计能正确地转化到功能上。此衍生要求不必鉴定。6.1.1鉴定进程目标衍生硬件要求的鉴定进程目标如下:1.对照待验硬件项,衍生硬件要求是正确和完整的。2.对衍生要求的影响及安全性进行评估。3.遗漏及错误被反馈到相关进程以处理。4.1.2鉴定进程活动通过结合多种行为,可以满足硬件鉴定目标,如:审核、仿真、建立原型、建模、分析、服务经验、工程评估、开发及进行实验。81n鉴定进程活动的指南包括:1.应该确定需要鉴定的衍生硬件要求。2.对于条款1所确定的每项要求,应指出鉴定完成标准并满足如下条件:a.通过审核、分析或测试,对每项要求都进行了某种级别的鉴定。b.对每项要求的审核、分析或测试都是适合鉴定此要求的,尤其是关于安全性。c.与每项要求相联系的审核、分析或测试结果是正确的,并且要解释实际结果和预期结果之间的差异。当预先说明的预期结果跟审核和分析的情形不一样时,鉴定行为的结果应该跟要求一致,尤其是与安全要求一致。注:鉴定完成标准或许基于要求、安全考虑、操作模式或实施。3.应该对衍生要求对安全性的影响进行评估。4.根据分配给硬件项的系统要求,应该对衍生的硬件要求评估完整。为此进程起见,当所有被说明的属性都是必要的,并且所有必要属性都得以确定时,一套要求才算完整。5.根据分配给硬件项的系统要求,应该对衍生的硬件要求评估正确。为此文件起见,当所说明的要求没有含糊不清,并且所说明的属性没有错误时,一项要求才算正确。6.应该建立衍生硬件要求,鉴定行为和结果之间的可追踪性关系。7.要求遗漏和错误应该反馈到相关进程以处理。8.2验证进程验证进程确保了硬件项的实施满足要求。验证由验证计划所阐述的审核、分析和测试组成。验证进程应该包括结果评估。班硬件设计的安全方面采取硬件实施符合的安全要求的形式。本部分为实施于硬件设计的验证进程的指南。验证进程可以实施于硬件验证计划所阐述的任何级别的设计层次。对安全要求而言,实施验证进程到不同级别的设计进程以增加这种可能性:达到设计错误已被排除的高度信任状态,这是有利的。一些设计保证等级要求:验证进程目标要如附录A所述独立达到。软件验证、软件/硬件综合验证和系统综合验证进程在此处不做说明。然而,这些进程中的硬件要求验证是一种有效的硬件验证方法。81n经验证的配置发生变化后,可能要重新验证,通过相似性、分析、最新设计测试或者通过重复原先验证的一部分来完成。注2:经证明的验证测试之外的非正式测试也被推荐。这些进程和结果是没有必要维持在配置管理控制之下的,但是能极大影响设计进程早期发现及排除设计错误。只有在正式化后,才可以对此测试产生验证信任。6.2.1验证进程目标验证进程目标如下:1.提供硬件实施满足要求的证据。2.建立在硬件要求、实施、验证进程和结果之间的可追踪性。3.验收测试标准的确定可以实施,并与硬件功能的硬件设计保证等级一致。4.遗漏和错误被反馈到相关进程以处理。6.2.2验证进程活动通过结合多种方法,例如审核、分析以及开发和执行测试可以达到验证进程目标。验证计划证明了验证行为应用于证明对要求的符合性。验证活动包括:1.需要验证行为的要求应该被确定。这并不意味着在每个等级都应该验证要求;在更高的等级可以验证要求。2.应该选择并执行的验证方法如:测试、仿真、建立原型、分析和审核。3.应该建立要求、实施、验证进程和结果之间的可追踪性。可追踪性应该与硬件所执行功能的设计保证等级一致。这并不意味着要求追踪性细化到诸如电阻器、电容器或门之类的具体元件,除非出于安全考虑的要求。4.应该执行验证所包括的分析以测定验证进程的完整性,包括:a.通过审核、分析或测试,每项要求都在某一等级上被验证。b.每项要求的审核、分析或测试都适于验证该要求,尤其是和安全要求有关的要求。c.与每项要求的验证相联系的审核、分析或测试结果都正确并且要解释实际和预期结果之间的差异。当预先说明的预期结果跟审核和分析的情形不一样时,鉴定行为的结果应该跟要求一致,尤其和安全要求有关的要求。5.应该证明验证活动的结果。81n1.遗漏和错误应该被反馈到相关进程以处理。6.3鉴定和验证方法本部分描述了对鉴定和验证都适用的一些方法。6.3.1测试测试是确保硬件项能正确响应一种或一系列激励的方法。实例包括功能测试、系统台架测试、系统鉴定设备测试和飞行测试。使用手动、自动或特殊化的测试设备都可以进行测试。测试也可以利用内置硬件项测试能力,例如验证进程里的内部测试。当在其规划操作环境中实验硬件项不容易验证特殊要求时,可以提供其它方法并被证明。在不同的硬件设计进程中可以执行测试。为认证信用而执行的测试需要一个配置好的项。系统集成或软件/硬件集成测试结果也可以用于测试信用度。测试指南包括:1.应该确定由测试所鉴定或验证的每项要求。环境质量测试要求是这些要求的一部分。2.诸如元件环境温度和施加电压之类的测试激励、时序和测试条件应该针对每种测试进行确定。3.通过/失败标准以及记录结果的方法应该先于测试执行而进行确定。4.应记录对测试设备的完全鉴定以及对每个设备的校准日期。5.应记录正被测试的硬件项目的配置特性。6.测试结果应该被记录和限制。7.测试故障应反馈到相关进程以处理。6.3.2分析分析是一种详细的、可重复的分析方法,用于评估特殊的硬件项特征,以证明特殊的要求被满足。分析实例如:应力分析、设计裕量分析、共模故障分析、最坏情况分析以及测试覆盖分析。服务经验可以为不同的分析提供数据。81n注:由于硬件设计复杂性的增加,使用诸如仿真之类的计算机化工具来验证设计要求及实施是很有利的。分析可以包括详细的功能性、性能、可追踪性以及硬件项功能的安全含义,以及与机载系统或设备内的其它功能的关系。单独的分析或结合其它验证方法的分析提供了要求被正确实施的证据。分析应该基于设计进程、服务经验或其它有效数据库所提供的数据。对于电路操作以及更高等级的功能操作的验证来说,仿真都是一种重要的设计分析工具。仿真可以分析生产变化对硬件参数所造成的影响,这是使用其它验证方法很难做到的,因而在减少(由于这些变化而导致的)影响安全的设计错误方面建立了信任。由于这些结果依赖于模型以及所使用的想定,所以为了在没有有效支持证据的情况下的认证信用,仿真结果不能单独使用。分析实例如下:1.热分析。热分析验证:当暴露在热环境下操作时,设计实施符合要求。2.应力分析。应力分析验证符合大于要求操作范围的等级标准。3.可靠性分析。可靠性分析确定设计实施是否满足产品的可靠性要求。4.设计裕量分析。设计裕量分析验证:设计实施满足给出元件可变性的功能要求。5.相似性分析。相似性分析将这些特征和用法与系统先前证明的特征和用法做比较。6.仿真分析。仿真分析比较仿真结果和预期结果。7.3.3审核审核是对计划、要求、设计数据、设计概念或设计实施进行评估的一种定性方法。审核应该贯穿相关计划所确定的整个硬件设计生命周期。应该在鉴定和验证计划里确定用于认证信用的所有审核。审核指南可以包括:1.参与者应该具有执行审核所必需的知识。2.硬件审核结果可以用于允许或拒绝硬件设计生命周期进程活动之间的转换。3.审核结果应该予以证明,包括所做的决定以及对将采取行为的处理。81n6.3.3.1要求审核要求审核是确保要求可接受性的一种方法。要求审核可以指出来自同一审核内的鉴定和验证进程的目标。发生在最初要求审核之后的要求变化应该从属于最初使用的审核进程或同等审核进程。本审核的目的并不是使分配到系统硬件的系统要求生效。要求审核指南包括:1.每项要求应该清楚、可验证,对分级情况进行了完整详细的说明,并且不能和其它要求冲突。2.衍生要求应该与系统要求或衍生出它们的要求一致。3.这些要求应该与SSA一致。4.衍生安全要求应被确定并反馈给SSA。5.这些要求应该与相关的硬件设计标准一致。6.这些要求应该适合有效技术的性能以及限制。7.对元件的要求,例如性能、温度范围、分级情况和屏蔽,应该与安全及可靠性要求一致。8.应介绍测试、维护和生产硬件项的能力。9.应该阐明软件/硬件接口要求。10.根据计划中所定义的标准,这些要求可向上追踪到其次的分级标准。11.衍生要求应该捕获不会被更高级标准验证的实施限制。12.遗漏和错误应该被反馈到相关进程以处理。以下问题可以有助于对要求的完整性进行评估:a.考虑到所有较高等级的要求了吗?员考虑到实用的标准和指南了吗?81nc.包含所有的硬件功能和接口吗?d.架构被完全覆蛊了吗?e.对硬件实施所需的所有验证都充分说明了吗?和包含了安全评估里所有的禁止行为特征吗?g.对工作环境进行了充分说明吗?h.考虑了假设以及限制情况吗?I.本实施会避免现有硬件或相似硬件所具有的任何己知问题吗?注2:以下问题有助于评估要求的正确性:a.这些要求与更高等级的要求一致吗?b.这些要求与分配给硬件项的系统要求一致吗?c.这些要求将“什么”与“怎么样”相对照了吗?d.这些要求清楚吗?e.可以实现这些要求吗?f.可以验证这些要求吗?g.已经定义了功能模式吗?h.要求符合安全评估吗?i.假设及限制正确地定义为衍生要求了吗?6.332设计审核设计审核是一种确定设计数据和实施满足要求的方法。正如在硬件设计生命周期内多次所作的说明,应该执行设计审核。实例如概念设计、细节设计及实施审核。对于会跨越几个硬件等级的分级设计,例如ASIC和电路卡装配,应该在最可能保证正确设计的地方考虑设计审核。设计审核指南包括:81n1.应指出所有要求,并且应该正确定义衍生要求和设计数据。2.应指出环境要求。3.应指出安全和可靠性要求。4.应该对设计数据的安全方面进行明确鉴定。5.设计应该可以进行实施、测试和维护。6.应该对新的生产技术进行评估。7.应该达到计划里确定的元件选择标准。8.从设计可以追踪到要求。9.遗漏和错误应该被反馈到相关进程以处理。81n7配置管理进程配置管理进程计划提供一致复制配置项的能力,并且再产生必要的信息并以一种控制了的形式更改配置项(如果有必要修改的话)。本部分说明了硬件配置管理的目标以及支持这些目标的活动。7.1配置管理目标配置管理进程的目标为:1.对配置项进行唯一的识别和证明。81812.保证可以一致并精确地复制配置项。3.为配置项提供进行识别和跟踪更正的可控方8181法。7.2配置管理活动配置管理活动的指南包括:1.配置项应被唯一识别、证明和控制。这可以包括但不限于:硬件、硬件设计表示、工具或其它用于认证信用和原始资料的数据项。2.应该建立原始资料。3.应对问题进行唯一识别、跟踪和报告。4.应该维持更改控制以及变化的可跟踪性。这要求计划所识别的生命周期数据应该保密并且是可检索的。5.应该控制配置项的归档、检索和发布。81n可以用不同的方法满足配置管理目标和活动,以下段落提供了可以用作验收方法的活动指南。721配置识别配置识别活动的目的是将每个配置项清楚地分类,以便建立配置项控制和参考的基础。指南包括:1.应该为数据项建立配置识别。2.应针对每个配置项、一个配置项的每个单独受制元件以及组成一个(与认证机构所同意的计划一致的)产品的每个配置项组合来建立配置识别。对包含AS1C、配置好的PLD、印制电路板以及黑盒子在内的识别元件进行识别的细节由配置管理计划进行确定。3.应该在COTS元件以及先前开发的硬件项在原始资料里使用之前就为其建立配置识别。4.在新的原始资料里使用之前,应该为每个配置项建立配置识别,而该原始资料被其它数据项参考或用于产品制造。7.2.2原始资料的建立建立原始资料的目的是为进一步的活动定义一个基础,并允许参考、控制配置项以及配置项之间的可追踪性。指南包括:1.应该为用于认证信用的配置项建立原始资料。注:可以建立中间原始资料以帮助控制硬件活动。2.一旦原始资料被建立,它就应该受更改控制程序的支配。3.当根据己建原始资料来开发衍生原始资料时,应遵从更改控制指南。4.如果在开发新原始资料的进程中,对与先前原始资料的设计相联系的活动或数据,试图认证其信任度,那么新原始资料应可追溯到导出它的先前原始资料。注:原始资料可以是一个配置项、先前经认证的硬件项或一个COTS元件。7.2.3问题报告、跟踪和纠正行为81n问题报告、跟踪和纠正行为的目的是记录问题并确保正确的处理和解决。问题可以包括与计划或标准不符、生命周期进程输出的缺乏、产品异常行为以及工具和技术进程的不足和缺陷。问题报告的执行应不晚于获得认证信用的原始资料的建立。指南包括:1.每个被报告的问题都应由一个问题报告所覆盖。2.问题报告应该确定受影响的配置项的配置情况。3.需要纠错行为的问题报告应该借助于更改控制活动。4.所有封闭问题报告都应该包括对关闭问题报告所采取的行为的说明,其中包括执行纠正行为所需的数据项变化的完成。5.并非为了获得认证所有的问题报告都必须关闭;然而,所有的问题报告都应被评估,并且那些确定对安全或认证有影响的问题报告应被关闭。6.问题报告系统应该跟踪问题报告状况,包括对它们的批准和处理。7.2.3更改控制更改控制活动的目的是为了确保更改的记录、评估、解决和批准。更改控制的执行应该符合配置管理计划,并且其启动应该不晚于获得认证信任度的原始资料的建立。指南包括:1.更改控制应该通过提供防止未授权更改保护来保持配置项的完整。2.更改控制应该保证:更改被评估以确定配置特征是否需要更新。3.在更改控制之下对配置项所做的更改应该被记录、批准并跟踪。在配置管理计划里阐明了批准授权。注1:因为所报告问题的解决可能导致对配置项的更改,所以问题报告与更改控制相关。一般认为,较早的更改控制实施有助于进程活动的控制和管理。4.更改控制应该确保从变化到变化原因的可追踪性。5.更改控制应该确保:评估更改以确定更改对进程输出产生的影响以及输出数据更新情况。81n从输出受到影响的那一点开始,这些进程中的一些或所有活动可能需要重复。应该认识到,对生产工具、技术进程或外部元件的更改可能会影响到设计。1.更改控制应该确保受影响的进程可以进行反馈。7.2.5发布、归档以及检索发布活动的目的是将数据项置于配置管理控制之下,从而确保只有经过授权的数据才可以用于其它活动。归档以及检索活动的目的是确保在需要复制、再生、再测或更改产品的情况下可以检索与产品有关的数据项。指南包括:1.配置项应该在用于生产之前被识别并发布,而且应该建立发布授权。2.与产品有关的数据项应该可以从经过批准的数据源检索,例如开发组织或公司。弟更改控制数据和问题报告数据是数据项的一部分。3.数据保存程序应该可以有效满足适航性要求并保证可以更改。4.应该通过以下行为来建立程序,用以确保在认证机构所要求的时间里,所存储的数据是完整的:a.保证不会发生未经授权的更改。b.选择存储媒介。c.维持被存储数据的有效性。例如,通过符合媒介存储寿命的频率来使用或刷新归档数据。d.保证不会发生导致归档数据不可检索的事件。例如,通过在物理分离的文档里存储复件。7.3数据控制类别有关数据项的配置管理可以分为两类,它们分别被定义为:1类硬件控制(HC1)和2类硬件控制(HC2)。对这两个类别的指定使得对某些数据项进行不太严格的控制管理成为可能。HC1要求执行所有的配置管理活动,而HC2则少了一些限制。HC2类数据项不会进行增量改变,但是会为新数据所替代。表定义了在HC1和HC2下将要执行的配置管理活动。例如表7-1表明,在附录A的表中确定为HC2的数据项需要可检索但是不需要被发布。另外,表表明任何HC181n数据项都有一个原始资料。附量△确定每个数据项的控制类别为硬件设计保证等级的一个功能。例如在表A-1中,HC1适用于所有保证等级的硬件要求,而HC2则适用于所有保证等级的硬件审核和分析结果。表7・1有关HC1和HC2的配置管理进程活动参考配置管理活动HC1HC27.2.1配置识别XX7.2.2(1)(2)(3)原始资料X7.2.2(4)①原始资料可追溯性XX7.2.3问题报告X7.2.4(1)(2)更改控制•完整性及识别XX7.2.4(3)(4)(5)(6)更改控制•记录、批准及可追溯性X7.2.5(1)发布X7.2.5(2)检索XX7.2.5(3)数据保存XX7.2.5(4a)未授权变更保护XX7.2.5(4b)(4c)(4d)媒介选择、刷新、复制X与新原始资料一起使用的HC2数据的确定并不意味着对HC1数据重新分类。81n8进程保证进程保证确保了生命周期进程目标得以满足而活动得以完成,正如计划中所概述的那样,或者确保了偏差得以处理。本部分说明了进程保证的目标和支持那些目标的行为。不存在利用特殊组织结构的意图。为了客观地评估生命周期进程、确定偏差并确保校正行为,应该独立地完成进程保证活动。8.1进程保证目标进程保证的目标是为了确保:1.生命周期进程符合所批准的计划。2.产生的硬件生命周期数据符合所批准的计划。3.建立用于一致性评估的硬件项,以符合相关的生命周期数据。8.2进程保证活动进程保证活动的指南包括:1.本文件计划进程部分所确定的以及PHAC所同意的硬件计划的有效性应该得以确保。2.应该保证:维持符合批准计划的审核,并跟踪所产生的行为项直到关闭。3.应该保证:检测、记录、评估、批准、跟踪并解决硬件计划和标准之间的偏差。4.应该保证:满足符合所批准计划的硬件生命周期进程的转换标准。注:执行以上第一项到第四项的行为时,审计是一种有效的方法。5.为了确保硬件项的构成符合其设计数据,应该进行检查。注:该项活动的一个实例是第一项检查。6.应该产生进程保证活动的记录,其中包括设计活动完成的评估证明。7.在适用的地方,申请者应该确保转包商使用的进程符合硬件计划。81n9认证联络进程证明联络进程的目的是在整个硬件设计生命周期中建立申请者和认证管理机构之间的交流和理解,从而对认证进程有所帮助。应该按照第4部分的硬件计划进程以及PHAC第10.1.1节所述来完成认证联络进程。附录A表A-1给出了对该进程输出的概述。另外,联络活动可以包括为了及时获批而进行的设计方法介绍、和符合认证基础的方式有关的商议、设计方法批准、数据批准方法以及任何所需的认证机构审核和测试证明。当一个项目在设计进程概述之后完成时,所产生的输出和硬件项状态应该在第10.9节的硬件完成概述中进行说明。9.1符合方法与规划申请者提出一种硬件符合方法,而PHAC对所提出的符合方法进行了定义。指南包括:1.当设计更改对计划的影响最小时,PHA、硬件验证计划和其它所需数据应该提交认证管理机构进行审核。2.认证机构所确定的关于认证硬件方面规划的问题应该得以解决。3.应该就PHAC与认证管理机构取得一致意见。4.计划中所概述的在设计和认证周期内与认证管理机构的联络应该继续,而且认证机构所提出的问题也应及时得以解决。在一些计划中,认证联络并不由设备制造商提供,而是由机体或制造商的其他顾客以支持角色来完成。这个关系应该在PHAC里确定,而且与认证管理机构的联系应该通过认证申请者进行。确保数据提供到认证管理机构是认证申请者的责任。当设备中的一些嵌入式硬件项要从转包商手中采购时,认证计划应该确定哪些数据将从转包商手中得到,而哪些数据将由申请者产生。对申请者来说,将PHAC和验证计划与其它相关计划包含在顶级认证计划之内是可以接受的。5.2符合证明申请者提供硬件设计生命周期进程满足硬件计划的证明。认证管理机构可以对申请者的设备或申请者供应商的设备进行审核。申请者安排这些审核并且使硬件设计生命周期数据可以根据需要进行提供。申请者应该:1.解决认证管理机构在审核之后所提出的问题。81n1.向认证管理机构提交硬件完成概述一第10.9节和顶级图纸一第10.322.1节。2.提交认证机构所需要的其它数据或符合证明,或者使其可以得到。81n10硬件设计生命周期数据本节叙述了在硬件设计生命周期中可能产生的硬件设计生命周期的数据项从而为设计保证和认证要求提供根据。生命周期数据的范围、数量及细节为认证机构所需而作为设计保证的依据,这些数据会受一系列因素的影响而发生改变。这些因素包括认证机构对机载系统的适用要求、所定的设计保证等级以及硬件的复杂性和服务经验。有关设计保证依据的详情应加以确定,记录在PHAC中且并要经认证机构认可。第11节中的附加事项和附录B中A级和B级功能的设计保证考虑事项会产生额外的生命周期数据。附录A根据硬件设计保证等级说明了将要开发的硬件设计生命周期数据、验证独立性程度以及适用的数据控制类别,正如第7节中所述。1.硬件设计生命周期数据的特性如下:a.明确性。信息/数据采用只有一种解释的术语写成。b.完整性。信息/数据包括必要的和相关的要求及说明性材料,所有的图形都作了标识,而且术语和计量单位都已经确定。c.可验证性。信息/数据可通过人员或工具来检验其正确性。d.一致性。信息/数据内部不存在任何冲突。e.可修改性。信息/数据在构成时具有一种格式使之可以完全、连续和正确地进行修改而又保留其结构。f.可追溯性。信息/数据的来源可确定。本节的记述不是用来暗示硬件生命周期数据中某一特定的数据打包方法或某一数据包内的数据编排方式。例如,所有的计划、标准和程序可以打包作为单个文件,或者在几个文件中记述。2.数据打包方法以及编排方式应该在PHAC和在项目初期与认证权威机构签署的协议中给出建议。3.经各方同意的信息和数据应该在机载系统或设备服务期间都能获得并利用。10.1硬件计划硬件计划介绍了在硬件认证、设计、鉴定、验证、进程保证和配置控制中所涉及的进程、程序、方法和标准。81n10.1.1硬件方面认证计划为了达到本文件的目标要求和获取认证机构对包含硬件项的系统的认证许可所用到的进程、程序、方法和标准,在PHAC中都进行了阐述。PHAC一经通过,即代表了认证申请人和认证机构之间在为完成硬件方面的认证目标时所执行的进程和活动以及所出示的结论性的依据方面达成协议。PHAC会是另一个计划的一个组成部分,比如机载系统认证计划。PHAC应包括:1.系统综述。本节简述了包含这些硬件项的机载系统,包括系统功能描述、系统破坏条件、系统架构、软硬件的功能分配介绍以及现有系统文件的参考文献。2.硬件综述。本节简述了硬件功能、硬件项、架构、所用新工艺以及所涉及的故障安全、故障容差、冗余和分区技术。3.认证考虑事项。本节介绍了认证的基本原则、认证方面的符合性措施以及硬件项的各个功能的保证等级。它还通过总结硬件安全评估及硬件在机载系统的应用为硬件设计保证等级的确定提供相关证据,包括潜在的硬件破坏条件的介绍,如234节中所述。如果适用,FFPA的概要或执行FFPA和应用其结论的计划也应包括进去。4.硬件设计生命周期。本节叙述了为了达到硬件设计保证的目标要求而采用的程序、方法和标准以及执行的进程和活动。它介绍了活动、活动的组合和程序化、进程与活动之间的关系、转换标准、责任、工具用途及提供硬件各进程之间及硬件进程与系统与软件进程之间的反馈与交互信息的手段。本部分还为本项目的计划和标准提供适用计划、政策、标准、程序和偏差等参考资料。5.硬件设计生命周期数据。本节介绍或参照将要研究和出示的或可利用的资料以此作为证明与本文件和计划目标相符的依据。6.附加考虑事项。本节记述了附加考虑事项。这些包括以前所开发硬件的应用,其中又包括再次利用的适用资料的参考、COTS的使用、产品服务经验以及如11节中所介绍的工具评估和资格鉴定,或A级或B级功能的设计保证考虑事项,如附录B中所述。7.替代方法。本节介绍了本计划中任何可供替代的建议方法,这些方法或在本文件之中没有提及,或将要以不同于本文件所介绍的方式被运用。还应包含替代方法能够替用的合理理由。8.认证进度。本节确定了计划中的重大事件以及硬件设计生命周期数据将何时提交给认证权威机构的日期。10.1.2硬件设计计划硬件设计计划说明了所用的程序、方法和标准,以及为硬件项设计而进行的进程和活动。这个计划可包含在PHAC中并为其应用的政策和标准提供参考。硬件设计计划应包括:81n1.硬件设计生命周期。将要使用的设计政策和标准的参考资料,对硬件设计生命周期进程以及为实现硬件设计保证等级的设计目标而进行的活动的描述。2.硬件产品介绍。确认硬件所达到的规格、备选用途、预定服务期限和更新升级的考虑事项。3.硬件设计方法。介绍要求俘获及说明方法、概念设计方法、详细设计方法、合成技术、执行方法以及在硬件项中所用到的生产转换方法。如附录B第3.1节所述,当已考虑A级或B级功能的架构减轻但在本计划拟定之时尚未最终确定时,需声明如何将此决定引入到设计进程中去。4.硬件设计环境。描述所用的设计工具。5.硬件项数据。确认所产生的硬件项设计数据或以前开发的硬件项的规范、文件和图号及零件号的参考资料。6.其它考虑事项。介绍预定的可供选用的处理技术、用途和装配、产品封装以及硬件安装方法。10.1.3硬件鉴定计划鉴定计划描述了为达到文件中的鉴定目标要求所用的程序、方法和标准以及对硬件项鉴定所进行的进程活动。这个计划可能包含在PHAC中并为所用的鉴定标准提供参考。鉴定计划应包括:1.鉴定方法。描述和说明所用的鉴定程序、标准和方法。方法可能包括分析、审核和测试。2.鉴定数据。确认和说明在硬件鉴定进程中产生的作为证据的结果。3.鉴定环境。确认和说明在鉴定进程和活动中所用到的分析和测试设备及鉴定工具。10.1.4硬件验证计划验证计划记述了为达到文件中的验证目标所用的程序,方法和标准,及在硬件验证进程中所进行的进程活动。这个计划可能包含在PHAC中并为其所用的验证政策和标准提供参考。验证计划应包括:1.验证方法。描述了为硬件项的完整性提供客观依据时所用到的验证政策、程序、标准和方法,完整性包括COTS和未用到的功能。方法可能包括分析、审核和测试。当采用附录B第3.3节中的先进分析方法时,应详尽说明适用FFP和适用验证完成标准的方法。2.验证数据。鉴定和说明在硬件验证进程中作为证据的结果。81n1.验证独立性。描述了为确保达到对验证独立性的要求而使用的方法。2.验证环境。确认和描述了在验证进程和活动中所用到的分析和测试设备及验证工具。3.机构责任。明确组织机构在验证进程中的责任。10.1.5硬件配置管理计划硬件配置管理计划描述了为符合本文件中对配置管理的目标要求而应用的政策、标准和方法。硬件配置管理计划应包括:1.硬件配置管理方法。描述和说明了在确定、管理和控制硬件及其生命周期数据时所用政策、程序、标准和方法。2.硬件原始资料。介绍了在建立设计和产品的原始资料和提供原始资料来源时所应用的方法和程序。3.问题报告和解决措施。介绍了在记录、跟踪及处理问题报告时所用到的方法和程序。4.更改控制。介绍了在确定、控制和跟踪变更的管理资料时所用到的方法、程序和进程。5.存储与检索。介绍了公布、存档及检索硬件设计生命周期资料的程序。该介绍应包含档案内容、格式以及介质标准、规则、方法和评判标准。6.环境控制。介绍了对用于开发及验证硬件的工具进行确认和管理时所涉及的程序和方法。7.配置管理工具。介绍在配置管理进程和活动中所用的工具和资源。10.1.6硬件进程保证计划硬件进程保证计划叙述了为满足本文件对进程保证的目标要求所应用的程序、方法和标准以及所进行的进程和活动。硬件进程保证计划应包括:1.进程控制。记述了为满足硬件设计进程中的进程保证要求而采用的政策和程序。2.机构责任。明确各组织机构在实施进程保证时的责任。3.一致性。介绍了在确定进程和产品性能时的政策、程序和标准。81n1.进程保证活动。描述了为确定此进程与计划和标准的相符性而执行的进程保证审核和审计。2.偏差。介绍了检查、记录、评估、解决和批准偏离计划和标准的方法。10.2硬件设计标准和指南硬件设计标准和指南对规则、程序、方法和硬件设计标准、鉴定、验证、保证和控制进程进行阐释,同时还可用于评估硬件设计结果的可接受性和质量。标准可不作要求,但如果申请人将它们包含在项目中,那么它们就成为项目认证依据和计划的一部分。对于计划,这些标准和指南可作为单个文件或多个文件进行打包。工具可用来执行这些标准。10.2.1要求标准要求标准可用在俘获进程中对制定要求的规则、程序、方法、指南和标准进行阐释。要求标准包含制定和详细说明要求的方法和标准,验证要求的方法和标准,用来阐释要求的注释,指导使用制定要求的工具的指南以及对系统设计进程提出衍生要求的方法。10.2.2硬件设计标准硬件设计标准用在概念设计进程和详细设计进程中,对用于研发和详细说明设计的规则、程序、方法、指南和标准进行阐释。硬件设计应包括:1.硬件设计表示方法和注释。2.设计规范和命名约定。3.设计方法指南。4.硬件设计工具使用指南。5.选择电子元件指南。6.评估备选设计指南。7.评估故障安全和容差设计方案的指南。8.给要求进程提供反馈信息以及阐述要求时所用方法的说明。10.2.3鉴定和验证标准81n硬件鉴定和验证标准是在鉴定和验证进程中对鉴定和验证硬件设计及应用时所涉及的规则、程序、方法、指南及标准进行阐释。10.2.3硬件存档标准硬件存档标准可用在保管和存储产品数据及完善和保管项目档案时对其所涉及的程序、方法和标准进行阐释。硬件档案标准应包含档案内容、介质标准、规则、方法以及判别标准。10.3硬件设计数据硬件设计数据包括阐释硬件项的规范、文件和图纸。10.3.1硬件要求要求中对所开发硬件项的功能、性能、安全、质量、可维护性以及可靠性都做出了具体要求。这些要求包括:1.指定给硬件的系统设计和安全要求。2.对硬件适用标准的确定。3.硬件功能和性能要求,包括衍生要求和正常使用下的极限应力。4.硬件可靠性和质量要求,包括有关故障率、曝光时间和设计约束条件等方面的要求。5.在硬件项使用寿命内对硬件维护和维修的要求。6.硬件可生产与装配方面的要求。7.硬件易测性方面的要求。8.硬件储存和处理方面的要求。9.安装要求。10.3.2硬件设计表示数据81n硬件设计表示数据阐释了硬件项的含义,它由组图、文件和硬件项构造规范所组成。以下段落阐述了部分典型的硬件设计数据及其内容。在某个特定的硬件设计中所出示的数据、图纸和文件类型依赖于硬件项自身包含的元件的尺寸大小、复杂程度以及数目多少。10.3,2.1概念设计数据概念设计数据是对硬件项的架构及功能设计进行描述的数据,它应包括:1.高级描述,例如框图或HDL定义,它能概括出主要功能和显示出这些功能之间的信息流。2.机械构造,其描述了硬件项的布置,例如,用绘图或草图展示其外部包装、印制电路板的排列、连接器的选择与位置以及主要接线。3.其它的架构特征和分区,这从适航性的角度来看非常重要。它可包含诸如EMI、防雷、防电击或防振、主要元件和人机接口的未用功能(如人类环境改造学的因素、照明特点和显示器分辨率)。4.高级硬件项的功能描述。5.硬件项功能架构。6.硬件安全评估基本数据。10.3.2.2详细设计数据详细设计数据叙述了在按要求操作硬件项时所必需的数据。根据硬件项的等级划分,这些数据可包括顶级制图、装配图、互连数据、零件数据、HDL硬件说明、可靠性数据、测试方法论数据、所选元件的未用功能清单以及为了保证不损害硬件项和安装控制数据及软硬件接口数据的安全所采取的措施。部分特殊数据将在下文阐述。注:除了其它适用认证要求所需的细节设计数据之外,像技术标准规程以及其它详细设计数据项的内容和适用性,也被申请人要求认证权威机构包含在PHAC中。10.3.2.2.1顶级图顶级图把硬件项以及所有组件、分组件、元件和阐述硬件项的相关文件都标示了出来。10.3.2.2.2组装图组装图纸包括组装硬件项、组件和分组件所需的附加详细信息。81n该图应包括:1.硬件组件内的硬件项的位置和方位。2.在确保正确的和无故障装配时所使用的装配指令序列或方法的说明。3.对后续操作中所使用的标识、标签和图像参考的位置说明。10.3.2.2.3安装控制图安装控制图是为了确保把硬件项正确地安装到系统中或安装到其它硬件项中。对于较低等级的硬件项,比其高一级的硬件项或组件的组装图可以充当安装控制图。安装控制图包括:1.尺寸。2.间隙要求。3.冷却和安装信息。4.有关重量、重心以及为确保安全准确安装所需的其它参数的信息。10.3.2.2.4硬件/软件接口数据由要求规范所确定的硬件性能可能会取决于软件对硬件的配置、软件对硬件的校准或硬件软件之间必要的交互作用。有关硬件/软件接口数据应包括:1.存储地址。2.承载数据的存储地址字段的分配。3.定时和时序信息。4.其它有关硬件/软件接口运行的必要信息。10.4鉴定和验证数据鉴定和验证数据既是鉴定硬件设计结果的完整性和正确性的依据,又是验证硬件本身的依据。它保证了硬件按要求和设计被开发和生产出来,从而达到设计目的。该81n数据包含审核、分析和测试硬件的程序和结果。除本节所介绍的数据以外,其它的附加数据项有可能为A级和B级功能所需,如附录B中所述。10.4.1可追溯性数据硬件可追塑性建立了要求、细节设计、实现和验证数据之间的联系,从而使硬件项的配置控制、调制和验证变得容易。硬件可追塑性数据包括:1.分配给硬件的系统要求与总要求之间的联系。2.要求与硬件详细设计数据之间的联系。3.硬件详细设计数据与依此数据所开发的硬件项或组件之间的联系。4.要求(包括衍生的硬件要求)与详细设计数据和验证程序与结果之间的联系。可追溯性分析的结果。10.4.2审核和分析程序硬件审核和分析程序阐释了进行审核和分析的进程和标准。硬件审核和分析程序应包括:1.审核或分析的目的。2.参与审核的机构。3.审核或分析的标准。4.进行审核或分析的详细指南。5.审核或分析的可接受性和完成标准。10.4.3审核或分析结果硬件审核和分析结果是评估审核和分析是否是按规定程序和标准完成的依据。硬件审核和分析结果应包括:1.审核或分析程序的确定。81n1.接受审核或分析的数据项的确定。2.参与审核或分析的人员。3.审核或分析结果。4.在审核或分析中出现的校正行为(如问题报告或行为项的列出)。5.审核或分析结论,包括对所审核项目的定性评估(对于审核)以及对所分析项目和分析数据的定量评估(对于分析)。10.4.4测试程序硬件测试程序阐述了执行用于硬件项验证的功能和环境质量测试时所涉及的方法、环境以及操作说明。硬件测试程序应包含:1.测试目的。2.确认每次硬件测试所需的硬件测试设置以及软件和测试设备设置说明。3.测试程序的详细指导说明。4.测试输入数据。5.预期结果,如测试中包含的通过/失败标准和要求。10.4.5测试结果硬件测试结果是评判测试是按照验证硬件项的规定程序完成的客观依据。硬件测试结果应包含:1.确认测试程序。2.确认所测项目。3.实施测试的实际结果。4.确认实施和证实测试的人员,如果适用也对测试实施日期进行确认。5.对分析或审核结果以及测试实际覆盖范围的解释说明。81n10.5硬件验收测试标准本数据提供了标准和评估数据,从而使得测试以及相关的测试结果能够确保硬件项被正确地生产或修理。本标准应包括:1.要进行测试的关键属性。2.判定各个关键属性通过/失败的标准。3.所有测试约束条件。4.对关键属性以及通过/失败标准的具体说明。5.满足安全要求所必需的设计方面的覆盖范围。6.评估数据,该数据可以显示测试标准在实际测试程序和相关测试结果的基础上被完全执行。10.6问题报告问题报告是确定和记录解决诸如硬件设计问题、进程与硬件计划和标准不一致以及硬件生命周期数据缺陷等问题的方案的一种方法。问题报告应包含:1.确认有问题的配置项和进程活动。2.确认需要调整的配置项或需要更改的进程描述。3.能使问题得到理解并得以解决的问题描述。4.为解决上报问题而采取的校正行为的描述。10.7硬件配置管理记录配置管理进程活动的结果都在配置管理记录中加以记载。这些可能包含配置标识清单、原始资料或电子记录、变更历史报告、问题报告概要、工具标识数据、存档记录以及发布记录。10.8硬件进程保证记录81n进程保证进程活动的结果都在进程保证记录中加以记载。这些可能包含审核或审计报告、会议备忘录、特许进程偏离的记录或者一致性审核记录。10.7硬件完成概要硬件完成概要是显示符合PHAC并向认证机构证明本文件中对硬件项的目标要求己经实现的主要数据项。该概要可与系统完成概要结合起来。硬件完成概要应包含以下引自PHAC的信息:1.系统综述。2.硬件综述。3.认证考虑事项。4.硬件设计生命周期的描述。5.硬件设计生命周期数据。6.先前开发的硬件。7.附加考虑事项。8.替代方法。与已获批准的PHAC有差异之处应加以确定。另外,以下四项也应包括:1.硬件识别。本部分用零件号和版本号来标识硬件配置及硬件项。2.更改历史。在适用的情况下,本节包括那些由于影响安全的故障而对硬件做出的更改,并将前一认证以来所做的更改与硬件设计生命周期进程加以区分。3.硬件状态。该部分包含一个在认证之时尚未解决的问题报告的总结,其中包含对功能局限性的申明。4.一致性陈述。该部分包含了一个符合本文件要求的陈述以及用来说明与硬件计划所述标准相符的方法的总结。该部分还对附加规则以及与硬件计划、程序和本文件发生的偏离进行了说明。注:PHAC中所含数据并一定非要在硬件完成概要里再次陈述,但是重述会加快认证进程。H附加考虑事项本节为前几节未涉及到的设计保证的附加考虑事项提供指南。这些附加考虑事项可由申请人决定是否使用以达到第2节至第9节中的一些目标。附加考虑事项81n的任何使用都应征得认证机构的同意。11.1先前开发硬件的使用本节讨论有关以前开发硬件的使用问题。指南应包括对硬件修改、飞机设备更改、适用环境和设计环境的改变以及升级设计原始资料所做的评估。COTS元件用法指南以及先期开发硬件的一个特例都将在11.2节中有所涉及。配置管理和进程保证考虑事项也应针对先前开发硬件的各种用途而提出。使用先前开发硬件的意图应在PHAC中阐明。H.1.1对先前开发硬件的变更本节讨论了对先前开发硬件的变更。变更可能是要求改变、检错、硬件或技术加强或者购置困难的结果。对建议性变更的分析活动包括:1.对系统安全评估进程的输出的审核。2.如果硬件设计保证等级提高,则利用1LL4节中的指南。3.对变更所产生的影响应进行分析,包括对变更引起的结果的分析,而更改可能会导致对不仅仅是更改区域的重新验证。这个区域可通过信号流分析、功能分析、定时分析、可追溯性分析或其它适宜手段来确定。1LL2飞机设备的更改本节讨论了硬件在新的飞机设备中的使用,此硬件是以前已经在某个硬件设计保证等级并在某个特定的认证基础之下经过认证的。当在新飞机设备中使用先前开发的硬件时,应使用以下指南:1.系统安全评估进程评估新飞机设备并确定硬件设计保证等级和认证基础。如果这些数据都和以前的设备相同或对新的飞机设备的要求并不十分严格的话,就无需再做评估。2.如果新的设备有功能修改要求,那么11.L1节中的指南“对先前开发硬件的修改”的相关要求应该得到满足。3.如果以前的设计活动并未产生用以证明新设备中的安全目标所需要的输出信息时,1L1.4节中的指南“升级设计原始资料”应该得到满足。H.1.3应用或设计环境的改变使用以前开发的硬件可能会涉及新的设计环境,或者与其它软件或硬件的集成而非那些最初使用时的软硬件。新的设计环境可能会增加或减少硬件设计生命周期进程中的一些活动。指南包括:1.如果一个新的设计环境使用硬件设计工具,那么11.4节的“工具评估和资格”指南可以适用。81n1.以前开发的硬件采用不同的接口硬件时,就应该进行软件接口的验证。2.当以前开发的硬件使用不同软件时,需要对硬件儆件接口重新验证。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元件提供了根据。H.2.1对COTS元件的电子元件管理对COTS81n元件的电子元件管理是一个与硬件设计和开发相关的重要支持进程。电子元件管理进程对COTS元件也同样适用。在此进程中涉及到商业和技术两方面,但在本节只对技术方面进行讨论。认证信用可通过以下途径获得:1.元件制造商可以出示高质量元件生产的追踪记录。2.该元件制造厂商建有质量管理程序。3.具备保证元件良好运转的服务经验。4.元件已被制造商或通过其它测试方法认定为合格产品,这就确立了元件的可靠性。5.元件生产商具有控制元件质量等级的能力或通过其它元件测试手段来确定获得。6.元件是基于预期应用的技术适用性而筛选出来的,例如元件温度范围、功率或额定电压,或者基于使用其它测试或方式来建立这些。7.元件性能和可靠性在持续的基础上受到监控,同时向元件生产商回馈有关需要改进之处的信息。11.2.2COTS元件的采购指导COTS元件的采购不是本文件的意图,但是当采购反馈意见对硬件设计保证产生巨大影响时应该由申请人设法解决。所涉及的主要问题有:1.本文件所需的COTS元件设计保证数据的实际可用性。2.对于受生产批次影响的元件参数的变化情况未进行说明,甚至未经坚韧性试验鉴别。3.电子元件技术的发展。4.现已无法采购的COTS元件。11.3产品服务经验利用产品服务经验可使先前开发的硬件和COTS元件的设计保证具体化。产品服务经验所涉及的资料是从先前或者目前对元件的使用中搜集而来的。非机载应用方面的数据并未排除在外。81n注:使用中的元件被广泛而成功的应用为证明元件设计已成熟且无缺陷,以及对元件所显示出的生产质量都增加了可信度。11.3.1产品服务经验数据可接受性标准当服务经验数据被用于设计保证时,服务经验数据的相关性和可接受性取决于以下内容中的一项或多项:1.硬件项在应用、功能、工作环境和设计保证水平等方面的用途相似性。2.设计保证数据以硬件项的建议配置为基础的程度。3.在进行评估的使用阶段内所发现的设计错误被消除、被减少或者经分析后被确定对所要用到的配置不会产生安全隐患的程度。4.在工作中的实际故障率。注:PHAC应该对应用零件的设计保证依赖于服务经验数据的这些方面加以特别说明。11.3.2对产品服务经验数据的评估为了达到以上标准,申请人应该:1.基于工程分析来评估先前应用、安装及环境与目标应用之间的相关性。注:用以决定用途适当性和使用限制的数据可在规范、数据表单、应用注解、使用手册和用户勘误表中查到。这些信息资源也会对与硬件相关的功能进行叙述,因此机载预定用途可与先前的用途联系起来。2.评估预期用法对安全评估进程的影响,包括如数据中所述的设计错误造成效能的可能性降低。3.评估一切有关设计错误及其对安全评估进程的影响的统计资料。如果无法得到统计资料可采取定性评估。4.评估可以用到的问题报告。问题报告可表明服务经验在目前的配置中已经得以改进。对于已经发现但尚未解决的问题可能仍然只能用架构方法或通过其它的验证活动来缓解。建立或评估问题报告与硬件项或产品要求变化的联系。注:对于电子元件,对实物的实际使用可使错误被发现并排除或使临时^修理”的可能性增大。11.3.3产品服务经验评估数据服务经验评估数据用来使设计保证具体应用到所建议的使用中,它应包括:81n1.元件及其在机载系统的特定功能的说明。确认设计保证等级,或者对于用在A级和B级功能中的元件来说则是对其它元件保证方法的描述,比如架构方法以及将要用到的补充或先进的验证策略。2.对服务经验数据采集和评估进程的介绍,包括评定数据充分性和有效性的标准。3.服务经验数据,包括正在研究的详细服务信息、变更记录、用来分析服务经验数据的假设以及分析结果总结。4.对与预期使用和所要求的设计保证等级有关的服务经验数据的充分性的合理解释。H.4工具评估和鉴定硬件和软件工具通常都会在硬件设计和验证中用到。当设计工具被用于制造硬件项或硬件设计时,工具上的故障可能会导致硬件项的错误。当验证工具用于检验硬件项时,工具上的故障可能会导致工具不能检测出硬件项或硬件设计中的错误。在使用工具之前,先要对工具进行测评。如有必要,评估结果以及工具资格鉴定应该记录并保存下来。工具评估和鉴定是为了确信工具在执行特定的设计或验证活动能够达到足以满足要求的水平。11.4.1工具评估和鉴定进程工具评估是对工具在设计生命周期进程中的作用进行评价,它包括依赖工具的作用和硬件功能的设计保证等级而进行的资格鉴定活动。本评估指导用流程图来表示,它适用于那些为满足目标要求或产生满足这些目标要求的数据项而使用的设计工具和验证工具。此流程图可引导申请人对部分工具进行有限的评估以及对其它的工具进行资格鉴定。工具评估和鉴定进程可应用于单个工具或一套工具。工具通常都具有完成一个具体项目中的某个特定设计或验证活动所需性能之外的其它性能。但是我们只需对那些在特定的硬件生命周期活动中所涉及到的工具功能进行评估,而不需要评估整个工具。工具通常被认为在不同的生命周期阶段都是被集成并共享的。如果同一个工具在设计和验证阶段都被用到,并且如果这两种功能不能分开或两种功能之间的保护不能建立,那么我们只需对其在作为设计工具时进行评估。注1:如果对给定工具的评估显示它的一部分功能被用于设计但其它的部分被用于验证,那么就值得分别对两种功能进行说明并对每组的工具评估功能进行评估。注2:该评估活动对工具应用的关注程度与对工具本身的关注相当或更甚。图11-1中的流程图说明了工具评估考虑事项和活动,并为何时需要工具资格鉴定提供指导意见。决定和活动方框中的数字指的是数字后面已编号的项目,这些编号项对决定或活动进行进一步解释。81n□确认工具图11-1设计和验证工具的评估与鉴定1.确认工具。包括名称、来源、版本号以及它所基于的主环境。工具更新应用文件记录下来以便跟踪。注:当更新工具时,应对工具更新对现有结果以及硬件的剩余生命周期可能造成的影响进行评估。2.确认进程和工具支持。确认工具所支持的设计或验证进程、工具的任何相关局限性以及它所产生的并用于硬件设计生命周期的输出。如果已经知道工具存在问题,那么提供可以使用工具的合理说明。3.工具输出是否被独立评估?独立评估是对使用一套独立方法的工具输出的81n正确性进行验证。如果工具输出被独立评估过,那么就不需要进一步的评估。注:对于工具所产生的全部或部分工具输出的独立评估可通过对诸如元件、连线表或组件之类的项目进行验证。在这种情况下,成品的完整性不单独依赖于设计工具输出的正确性。对验证工具输出的独立评估可包括工具输出的手动检查,或者包括和被测工具一样也能够执行验证活动的单个工具输出的对比。申请人也可以推荐其它的独立评估方法。1.工具是A、B或C级设计工具还是A或B级验证工具?如果工具是用于D级功能,作为C级功能或用于评估验证测试的完成情况的验证工具,像在附录B中3.3.LL2节所介绍的元件分析,那么就不需要进一步的评估。如果工具是用作硬件执行A、B或C级功能的设计工具或用作硬件执行A或B级功能的验证工具,那么就需要进一步的评估。2.工具是否有相关历史记录?如果可以表明工具以前使用过并且产生过满足要求的结果,那么就不需要进一步的评估。在给出合理理由时应该包含早先的工具用途与推荐工具用途之间的对比讨论。注:只要有资料可以证实工具的历史记录的相关性和可靠性,那么工具的历史记录可基于机载应用或基于非机载应用。3.为工具鉴定建立原始资料和问题报告。建立工具配置管理和工具问题报告的原始资料从而为工具资格鉴定做好准备。4.基本工具鉴定。拟定并执行计划以确定工具通过分析或测试为其预期的应用产生正确的输出。工具用户指南或其它有关工具功能和用法的说明可用来制定要求。5.工具类型和等级?此工具是A或B级硬件设计工具还是C级硬件设计工具还是A或B级硬件验证工具?6.设计工具鉴定。证明A或B级设计工具是否合格,可运用本文件的附录B中所介绍的策略,或RTCADO-178/EUROCAEED_128针对软件开发工具的合格鉴定指南,或者认证机构所认可的其它方法。注:A级和B级设计工具鉴定的具体指南在此不作叙述是因为工具使用环境和所涉及技术的可变性、工具的应用和生命周期资料的可见性以及其它因素。在对工具输出未进行单独的评估或没有建立相关的历史记录的情况下是不鼓励使用此类工具的,因为它有可能是一项和软件开发一样复杂的工作,其中会用到工具。7.完成。对工具评估、评估决定的合理理由进行记录,如果适用还应包括工具鉴定数据。为安装指南、用户手册和工具鉴定数据提供具体的参考,这对支持工具分配和资格鉴定很有必要的。81nH.4.2工具评估和鉴定数据工具评估和鉴定数据应包括:1.确认工具以及其所支持的进程,如可行,还包括以下项目:a.按照图11-1中的第3款所进行的独立评估的基本原理与结果。图H・1中第4条中的工具名称。b.当符合图11-1中第5条时工具的历史记录。c.对工具先前用途与所推荐用途之间的相关性的讨论也应包含在合理理由里。2.与图11-1中第6条相一致的关于工具鉴定中所用到的明确的配置定义,如果所测试的配置与实际中用来设计或验证终端硬件项不同,那么关于所测试配置的适用性也要给出合理解释。3.工具鉴定的详细资料,包括测试中所用到的要求、测试程序、预期结果、用来解释和补充测试结果的分析进程以及如何建立其独立性。4.证明设计工具合格的计划,包括适用程序及计划中所涉及的所有活动的结果。5.对已知正误表的处理,包括工作区,如有可能还应包括进行工具鉴定时所产生的问题报告。81n附录A该附录提供了基于硬件设计保证等级对硬件设计生命周期数据进行调制的指南,同时也提供了验证过程中有关独立要求的指南。表A-1确定了每个数据元素的数据传送分类和配置管理数据控制类别。参见表7・1。这里规定了两种数据传送分类类型:1.需要提交。这种数据项应提交认证管理机构。2.未用。不需要这种数据项。A级和B级的所有验证都是独立的。C级和更低级别的功能不要求单独验证。只在层次结构等级上需要独立性,而设计正是在此等级上针对要求进行验证。可以接受能够对共模故障问题进行寻址的独立性等效方法。独立性是一种能够对潜在的共同模式错误进行寻址的方法,当设计者验证处于开发过程中的硬件项是随设计而非要求运行时这些错误就可能发生。为了对这个问题进行寻址,确保验证过程与满足设计要求的证明一致的责任应由与设计者无关的个人、过程或工具来执行。这里有许多建立独立性的方法,而验证计划应提出用于特殊验证活动的具体方法。几个可接受的方法实例列举如下:1.由另一个人来审核要求或设计。2.由另一个人来开发测试用例或程序。3.将设计者开发的案例或程序交由另一个人审核。4.将设计者所做的分析交由另一个人或设计小组进行审核。5.进行不同的测试来确认由设计者所做的测试结果,例如:飞行实验过程中的一项测试确认了硬件项测试,或者独立开发并针对目标硬件项所执行的软件验证测试确认了由设计者所做的测试结果。6.通过工具来验证测试或分析结果。注通常验证测试是自动进行的,它们只需"按下一个按键"即可执行。一旦进行独立性评估或开发,不要求除设计者以外的其它人完成测试。结果仍需单独进行审核以确保适当的程序得以遵从而要求也得以满足。注2:不要求为了获得独立性而需要组织结构分离。表A-1中划圈的数字参见表后注释。81n表硬件设计保证等级与硬件控制类别的硬件生命周期数据数据章节硬件生命周期数据①目标②A级B级C级D级10.1硬件计划10.L1硬件方面认证计划4.1(1,2,3,4)SHC1HC1HC1HC110.L2硬件设计计划4.1(1,23,4)HC2HC2HC2NA10.13硬件鉴定计划③④4.1(1,2,3,4);6.1.1(1)HC2HC2HC2NA10.1.4硬件验证计划4.1(1,2,3,4);6.2.1(f)SHC2HC2HC2HC210.1.5硬件配置管理计划4.1(1,2,3,4);7.1(3)HC1HC1HC2HC210.1.6硬件进程保证计划4.1(1,2,4);8.1(1,2,3)HC2HC2NANA10.2硬件设计标准10.2.1要求标准③4.1(2)HC2HC2NANA10.2.2硬件设计标准③4.1(2)HC2HC2NANA10.2.3鉴定与验证标准③4.1(2)HC2HC2NANA10.2.4硬件存档标准③4.1(2);5.5.1(1);7.1(1,2)HC2HC2NANA10.3硬件设计数据10.3.1硬件要求5.1.1(1,2);5.2.1(2);53.1(2);54.1(3);5.5.1(1,23);6.1.1(1,2);6.24(1)HC1HC1HC1HC1103.2硬件设计表示数据103.2.1概念设计数据③521(1)HC2HC2NANA103.2.2详细设计数据53.1(1);541(2)⑤⑤⑤⑤103.2.2.1顶级图53.1(1);5.4.1(2);551(1)SHC1HC1HC1HC110.3.2.2.2装配图53.1(1);5.4.1(2);551(1)HC1HC1HC1HC110.3.2.23安装控制图541(2);551⑴HC1HC1HC1HC110.3.2.2.4软硬件接口数据③531(1);551⑴HC1HC1HC1HC181n10.4鉴定和验证数据10.4.1硬件可追溯性数据6.1.1(1);621(1,2)HC2HC2HC2⑥HC2⑥10.4.2审核与分析程序③6.1.1(1,2);6.2.1(1)HC1HC1NANA10.43审核与分析结果③6.1.1(1,2);6.2.1(1)HC2HC2HC2HC210.4.4硬件测试程序③6.1.1(1,2);6.2.1(1)HC1HC1HC2HC2©10.4.5硬件测试结果③6.1.1(1,2);621(1)HC2HC2HC2HC2⑦10.5硬件验收测试标准10.6问题报告5.L1(3);5.2.1(3);531(3);54.1(4);5.5.1(4);6.1.1(3);6.24(4);7.1(3)HC2HC2HC2HC210.7硬件配置管理记录551(1);71(1,2,3)HC2HC2HC2HC210.8硬件进程保证记录7.1(2);8.1(1,2,3)HC2HC2HC2NA10.9硬件完成概要8.1(1,23)HC1HC1HC1HC11)需要提交的数据在“提交”一栏中以s表示。用于验证但无需提交的HC1和HC2数据应该提供。参见7・3节。2)此处所列目标仅供参考。并非所有目标都适用于全部保证等级。3)若这些数据用于认证,则其可用性在表中给出。这些数据不常用于认证,因此无需要求。4)通过C级和D级认证联络过程,这可以非正式地完成。文件可以会议备忘录或呈报资料的形式进行提供。5)若申请者参考提交数据项中的这些数据,它们就应该提供。6)只需要从要求到测试的可追溯性数据。7)不需要较低分层结构要求或推导出来的测试范围。附录BA级和B级功能的设计保证考虑事项A.1简介81n执行A级和B级功能的硬件的设计者做出可能影响安全的决定。当设计保证等级提高时,需要验证所给定设计是否满足其安全要求的方法可能需要设计保证方法的重叠和分层组合。由申请者选择这些方法中的一个或多个或者提出另一个能够提供设计保证的方法。此附录为设计者提供了如何操作和使用FFPA以开发一个设计保证策略以及有关一些能够用于设计保证的特殊方法的指南。A.2功能故障路径分析功能故障路径分析(FFPA)是一种自顶向下的结构迭代分析。它确定了设计中执行功能的特定部分,也就是与各路径相关的组件及元部件;相关的故障模式和需要分析的影响以确定硬件架构和执行是否符合安全要求。FFPA还确定了设计中实现A级和B级功能的那些组件和元部件。FFPA从PSSA开始,PSSA用于确定系统等级FFP,而FFP则可以分解为并分配给硬件FFPOFFPA的目标是确定单个的FFP以便:1.通过此附录所述的适当设计保证方法或者认证机构可以接受的其它先进方法来对执行A级和B级功能的硬件进行寻址。2.本附录的考虑事项对执行C级或更低级功能的硬件来说是可选的,这些更低级功能就是那些仅通过使用此文件第三节至第十一节中的指南就可以确保的功能。注:因为通过使用多个设计保证方法就可实现整个硬件项的设计保证,因此确定以不同技术实现的功能的单独FFP或者提供不同程度的设计可见性常常是有用的。每个FFP的分解等级都有所不同。通过使用常规的自顶向下的安全评估技术(如故障树分析)来进行分解。使用F・FMEA、从属图以及对分解的每个连续等级所进行的共同模式分析可以补充分解。每个系统等级FFP的分解等级或许不同,这与设计的保证对策、相应的实现概念以及计划用于硬件设计的错误减少方法有关。分解:从系统级FFP进行到硬件级FFP;从硬件级FFP进行到电路级FFP;从电路级FFP进行到元件级FFP;并从元件级FFP进行到元素级FFP.A.2.1功能故障路径分析方法FFPA按下列过程执行:81n1.对于A级和B级的每一项功能,都应根据硬件要求和适合该项功能的FHA来确定功能及其设计保证等级。每一项功能都可构成一组子功能,而每一个子功能都有一组相应的衍生要求和相关的设计保证等级。若有必要,这些子功能还可再分解。2.对于A级和B级的每一项功能而言,确定执行功能或子功能的方法并分析设计保证选项。执行功能或子功能所要使用的保证数据或期望使用的保证数据都应该是完整的,而且对于设计保证策略或选定测量是可接受的。若使用的保证数据或期望使用的保证数据是完整的、正确的而且是可接受的,那么无需进一步分解。3.对于不是A级或B级的FFP,它们与A级或B级FFP的相互关系用F-FMEA,共同模式分析或从属图来评估,以便确保A级或B级FFP不会受到非A级或B级FFP的不利影响。该评估过程是迭代的。如果FFP没有可接受的设计保证方法,重复进行分解和评估过程或改变硬件功能的架构或实现,直到确定出一个可接受的设计保证方法并提供满意的保证数据,或者能为每个A级或B级FFP提供保证数据。FFPA的结果以及用于硬件设计保证的所选方法的结果可以传给本文件2.1节所描述的飞机系统进程。这些结果过去常用来检查并验证飞机等级的假定(尤其是与那些类似硬件项的多重交叉系统应用有关的假定)现在仍然有效。A.2.2功能故障路径分析数据FFPA数据应该:1.确定已从系统级委托给硬件项的异常行为和功能故障。2.确定FFP、异常行为或功能故障的影响、分析执行的设计结构分解等级以及应该提供的可接受保证数据的类型和位置。3.描述FFP之间的关系以确定它们对于其它FFP和元件的独立性。这种关系可使用定性FTA或其它自顶向下的分析、共同模式分析、F-FMEA或从属图进行描述。该关系描述应确定那些相互有关联的路径和元件以及相互依赖关系。4.在FFP、硬件要求以及衍生要求之间进行追溯。A.3A级与B级功能的设计保证方法此附录不通过任何现在使用的或将来使用的方法来限制设计保证的实现。此附录中讨论的方法可用于满足文件第4节至第6节描述的一个或多个进程目标。A.3.1架构缓解诸如相异实现、冗余、监视器、隔离、分割和指令放限限度之类的架构设计特征可以特别应用于减少或限制硬件设计和执行错误的不利影响。作为PSSA的一部分,诸如定性故障树分析和共同模式分析之类的活动都能为确定架构属性范围提供保证,而这些属性用于减少或抑制硬件缺陷、故障以及设计和执行错误81n的影响。更特别的是,此方法应连同FFPA法一起用于附录B第2节所描述的硬件,此法还应使用共同模式分析进程来确定硬件设计和执行错误范围的特殊缓解策略的适用性。例如,冗余主要是对随机故障和翻转有用,但如果共同模式方面已被寻址,那它也可有效用于减少设计和执行错误。A311架构缓解方法通过确定与提出的送件实现相关的FFP,而后分析设计选项以确定并建议可减少对这些FFP影响的设计特征和策略,架构缓解就得以实施。与减少所有FFP影响有关的建议架构的全部影响都应被评估和寻址。采用架构缓解策略的同时还引入了一些衍生要求,正是根据这些要求来对执行进行验证。架构特征尤其应防止已确定FFP的某些或所有负面影响,并应对引入的其它故障路径进行评估,这些路径而后又通过进一步的架构缓解或通过此附录中描述的另外一些设计保证策略进行寻址。A3]2架构缓解的解决安全评估进程确定了架构缓解的可接受性。FFPA首先应确定所有A级和B级硬件的FFP,而架构缓解将在这些FFP里用于信用,另外FFPA应确定需要使用的方法,还应确定缓解的基本原理。通过评估每个功能确定充分程度,而每个功能都支持整个架构缓解的方法,此方法包括或多或少架构策略的组合。共同模式分析应提出对共同模式错误在要求、执行、制造商和维护等方面的潜在可能性,而这些方面可使缓解失去作用。设计者还应考虑行成架构缓解功能的硬件的潜在随机故障,这些故障可以使得缓解不可用。支持缓解可用性的概率应与缓解损失的结果相称,这会导致安全边限的缩小。全部方法应保证必要功能之间的正确操作和可接受独立性能够获得并得以维持。必须确定任何用于消除、隔离或限制剩余共同模式影响的特殊保证措施,而且这些措施应以附加架构缓解或其它设计保证策略的形式进行合并。当架构定义完整时,确定没有缓解的、或缓解不够的A级和B级FFP的硬件功能都应使用此附录中另外的设计保证方法来进行再次寻址。例如:当分析用于确定和提供适用电路和元件未缓解部分的验证范围时,单个电路和元件的局部体架构缓解可以连同安全特别分析法一起使用。A.3.1.3架构缓解数据用于保护硬件A级和B级FFP的架构缓解手段的文件应以安全评估数据、安全要求数据以及可追溯性数据的形式来提供。安全评估数据应基于硬件FFP评估和共同模式故障分析,而该分析特别提出了硬件设计架构缓解方面的问题。架构缓解数据应包括:1.需要通过结构手段来保护的A级和B级硬件FFP的确认。2.对架构方法以及该方法所提供的有关覆盖的鉴定基本原理的描述。81n1.共模边界和适用于该架构的共模设计方面的基本原理。2.对需要通过其它设计保证方法来寻址的未缓解或缓解不足的A级和B级FFP的确定。3.有关架构缓解机理的功能操作和必要设计属性的要求。4.用于满足包括软件在内的安全要求的缓解机理,如软件划分、安全监控和相异软件。这些机理和安全软件要求都应提供给系统进程和软件开发进程。5.执行适用的架构缓解的任何硬件的常规失效率数据和潜在的故障暴露评估数据。6.可追溯性数据,该数据将安全要求与适用的安全评估数据以及适用的设计验证数据相连。A.3.2产品服务经验第113节提供了有关如何评估产品服务经验数据的基本指南,这些数据适用于机载硬件。对于将先前开发的硬件作为设计一部分的A级和B级功能来说,附加设计保证是必要的。该保证以下列方式进行提供。A.3.2.1产品服务经验方法完成11.3节的评估后,由考虑中的硬件所执行的FFP应相对于任意适用服务经验进行分析。申请者或设计者应确定服务经验数据,并且确定服务经验数据可以论证以前使用硬件期间硬件重新使用的功能性是否充分使用。A.3.2.2产品服务经验的解决当服务经验数据分析完整时,已决定不使用的、不充分使用的或在实际操作中不可用服务经验的A级和B级FFP的硬件功能都应使用其它设计保证方法或依据应用于执行功能的其它验证的确认进行寻址。A.3.2.3产品服务经验数据应用于保护硬件A级和B级FFP产品服务经验的数据应包括:1.第1132节中的产品服务经验数据。2.FFP的确认,而通过服务经验和服务经验数据的充足性证明来为这些FFP提供设计保证。3.对服务经验数据不足的FFP的确认,以及对用于完成FFP设计保证的测试环境、测试程序、分析以及结果的确认。4.对未经服务经验证明的FFP和操作状态的确认,该服务经验将需要附加架构缓解或高级验证方法。81n1.第10.4.1节说明的可追溯性数据,它显示了服务经验数据和检验之间的明确关系,该验证提供了每个FFP的设计保证范围。A.3.3先进验证方法通过诸如元素分析、形式法、特定安全验证分析之类的先进验证方法或其它申请者提出并且认证机构接受的方法的应用,就可以达到附加设计保证置信度。设计保证先进验证法可以使用并扩大附录B第2节提到的FFPA法的范围。FFPA法可以渐进式地应用于设备级、电路级和元件级以便确定A级和B级FFP的硬件执行。由FFPA而来的数据随后用于确定适用于包含在那些A级和B级FFP中的硬件电路、元件和部件的设计保证建议方法。这里总结了三种方法,并在以下几节做了描述:1.元素分析。元素分析提供了一个自底向上透视的硬件验证完整性测量方法。通过使用满足6.1节验证目的的验证测试用例来确定和验证FFP内的每个功能元素。该分析还可确定需要通过其它适当方法来寻址的需要加强的领域。2.特定安全分析。根据系统安全透视,该策略集中于暴露并更正会对硬件输出产生不利影响的设计错误。硬件输入空间和输出空间的适用安全敏感部分被分析确定。对硬件输入空间的敏感部分进行仿真,并观察输出空间以不只获得安全敏感计划功能要求验证,而且还获取异常行为。通过使用传统安全分析方法来完成的分析,预先确定输出空间观察方法。3.形式法。形式法将形式逻辑和离散数学方面的方法用于计算机系统的规范、设计和验证中。这些方法用于证明硬件设计生命周期的不同进程中所使用的推理。除了那些在本部分中所介绍的方法之外,申请者也可以提出其它一些先进的验证方法。A.3.3.1元素分析元素分析用于显示通过相关的验证测试用例来验证FFPo通过将一个复杂FFP执行分解成设计者设计出的等级元素,元素分析提供了排除设计错误的置信度和证据。此分析法提供了一个验证进程测量方法来支持验证范围和完整性的决定,特别适于详细设计可视而且处于配置控制之下的地方。这是一个ASIC或PLD中的实例,它们中的功能在相同的设计保证等级上被寻址,或对不同设计保证等级的功能进行分开或隔离。使用达到6.1节验证目标的验证程序来确定并验证适用电路或元件的每一个功能元素的正确性。元素分析通常应用于一个完整的元件或组件而无需考虑在其内所执行的各种FFP的数量,但如果为不同FFP的分立、独立或隔离提供了论据,那它也可用于元件或组件的一部分。乱当对PLD内所实现的一个功能进行元素分析时,应包括程序化内容和PLD特征应用,未编程的元件可以使用一个分离方法(如前面的服务经验)进行寻址。81n该分析确定了需要加强的方面,而这些方面需要通过适当手段进行寻址。无此分析的验证进程会留下一些测试不当的电路。从历史的观点来说,此类不当性归因于基于要求的测试程序的缺点、不明确或不完整的硬件要求、未用电路、初始化电路和库函数。该分析检查了所关注FFP内元素的验证,并确定和每个元素有关的验证范围是否完整。如果元素验证范围被确定为不完整,就表明有必要进行附加验证或适当活动。申请者应就元素被确定在设计结构的什么等级以及对它们怎样进行分析以获得验证范围这两方面提出建议。A.3.3.1.1元素分析法通过确定一组应用于分析的标准来开始元素分析法,这是出于对所实现硬件的硬件设计保证等级、硬件技术以及细节可见度的考虑而决定的。这些标准应包括:1.对处于硬件设计适当等级的元素的确认和定义。2.每个接受验证的元素的验证范围。然后这些标准就可应用于验证活动的分析,以便确定计划验证是否可以达到验证范围的完成标准。若没达到标准,那么正在接受检验的每个元素都应通过一组适当的激励,并且对测试中的受监控信号造成适当的、可察觉的影响。注」由于该进程检查的是针对硬件本身的测试,所以它能发现测试程序中的不足之处。对这些测试不足进行寻址就能提供测试充分的附加置信度和证据,而执行新的或已修正的测试用例能暴露硬件错误。A.3.3.1.1.1选择元素分析标准将要用到的元素分析标准应根据每一个实例的具体情况进行选择,要取决于硬件元素类型和复杂度以及元素可确认的功能操作。该分析要么显示所有低级的基本块(如计数器、寄存器、多路复用器、加法器、运算放大器和过滤器)己被充分测试,要么显示所有互连基本组都已被充分测试并达到验证范围标准。为了执行下一个更高结构等级的硬件功能,应基于元素功能操作的评估及其与其它硬件元素的集成来得出测试程序的分析标准。注:举例来说,若元素是一个用作延时的模N计数器,测试程序可以使用输入数据的适当等价类选择来验证它在启动时进行计数、禁止时停止计数、以正确速率进行计数以及在规定时间达到n并且翻转。没有必要显示对共同组成计数器的单个的门或触发器执行测试程序。作为用互连基元作为一个元素的例子,算术逻辑单元(ALU)可以由诸如寄存嶷加法器和控制逻辑之类的基元构成。可以仿真ALU来显示基元共同组成了运算器,但用于元素分析的验证程序应使用适当等价类的输入数据来显示ALU执行其功能。无需确定元素处于一个低于硬件设计者指定等级的设计等级。只有当设计被明81n确表示为用于组合逻辑或状态机控制的门时,门级分析才适用。注2:分析设计者规定等级以下的执行,比如门级或晶体管级,是没有必要的,因为它类似于分析处于汇编语言或二元模式级的软件。通过硬件验证测试以及经过成功评估的布设后仿真进行元素分析,这些较低提取等级被隐含寻址,而且若有必要,可依据U.4节来充当验证工具。ASIC或PLD包括专有库函数,这些函数不能提供其内部设计的可见度,因此它们不适于手动分析。在元素分析中可以将库函数视为COTS元素,而COTS硬件方面则需根据11.2节和附录B第2.2节所定进行寻址。对库函数应用的验证应显示它符合库制造商所提供的规范或说明,而测试也应在允许观察测试结果的环境条件下执行。注本来是不鼓励使用有利于建立新功能的设计库;但为了将错误引入硬件的机会降至最低,鼓励设计库的实际使用。对于从HDL中的高级描述合成而来的ASIC或PLD,分析标准基于代表硬件的高级行为语言码。然而,由于从HDL表示法合成而来的执行包括并行逻辑结构和非顺序时间方面,所以合成输出应被包含在分析完成的决定中。合成器也要进行评估。A.3.3.1.1.2执行元素分析元素分析应使用在下列一个或多个测试环境内进行的基于要求的验证测试:1.具有执行功能路径的电路的测试,该电路安装在目标组件内。2.对一个独立样机所执行的测试。对于ASIC或PLD来说,此类测试具有代表性。3.制造验收测试。注:由于制造测试常常没有基于要求,因此制造验收测试应在其应用中被限制在元素分析。4.已经进行过评估而且典型针对ASIC或PLD的布设后仿真;若有必要,它适于用作验证工具,如1L4节中所述。倘若要分析的测试程序和正在应用的元素分析标准有关,而且属于那些用于为了实现第6节目标的硬件功能验证信用的程序,则通过使用一个仿真来测量所达到的完整性就可以执行元素分析。如果所分析的测试程序是由硬件电路内测试或独立样机引出,并使用仿真来检查,则测试激励和预期结果就会针对仿真器进行转换(倘若准确度的转换过程作为元素分析的一个部分而接受准确度检查)。应该显示用于执行元素分析的仿真器能够准确确定执行内所包含的每一类元素是否都符合分析标准。A.3.3.1.2元素分析结果的解决元素分析能暴露出未验证的硬件元素,指出有进行附加验证进程活动的必要或者有通过架构方法取消未测试元素或缓解异常行为的必要。未经测试硬件元素81n可能是以下原因的结果:1.验证测试用例或程序的缺点。如果测试用例只是没有按照附录B第3.3.1.1节的标准来测试硬件项元素中的元素,那就可能出现缺点。如果功能要求中出现“不必在意”但硬件项被适当设计以用于产生重复响应,那么也会出现缺点。在这些情况下,应补充和改变测试程序和用例。而且要对测试验证其重复相应的能力的断定进行审核。2.要求的不足之处。修改要求或确定另外引出的要求。然后针对新的或经过修改的要求来开发、执行和分析附加验证测试。3.未用功能。硬件项包含没有在目标电路应用中使用的功能,如仅用于元件级验收测试的库函数或测试结构内未经使用的子功能。这些功能要么与其它有用功能隔离,要么不能出现可能对安全产生不利影响的潜在异常行为。这可以通过显示未用元素在硬件中或者当安装时肯定无效的方式来实现。若在以后的某些应用中会使用这些未用功能,就会再次重新遇到元素分析不足的情况(倘若这些功能被确认为未经全面检验的话)。4.无保证结果的元素。利用分析来限制并说明元素异常行为的结果不会引发对飞机或占有物不利的安全影响。通过记录限制元素异常行为结果的分析就可以解决这些项。A.3.3.1.3元素分析生命周期数据输出元素分析生命周期数据输出应包括:1.通过元素分析来确定FFP被寻址,并提出在设计结构的哪个等级来确定元素以及如何进行验证充分的分析,这是验证范围完成标准的组成部分。这应包含在PHAC内或硬件验证计划内。2.描述方法并确定分析中被寻址的FFP以及执行分析的设计结构等级。3.如10.4.1节所述,确保可追溯数据显示元素分析中验证程序与元素的清晰关系。4.确定因元素分析而添加或修改的验证测试用例和要求。5.说明针对由元素分析寻址的FFP所达到的验证完整等级,包括对未经更改所解决的、与验证测试或要求之间的分析矛盾以及可接受原因的确认OA.3.3.2特定安全分析应用时,特定安全分析法通过对所选电路和元件进行更为深入的分析,扩展了硬件FFPA概念。经扩展的FFPA用于得出和鉴定有关那些电路和元件内部操作的特定安全要求。而后通过下面讨论的验证测试对这些衍生出来的安全要求进行寻址。特定安全分析基于这种概念:只有当特定的输入激励将其暴露时,潜在隐藏的81n设计错误才会影响硬件项的输出。因此,为了适当仿真并暴露所关注安全错误,应确定必须安全操作的输入用例子集,然后在验证测试中包含来自该子集的适当等价类。在这些测试用例的执行期间,对项的输出进行评估以确定不存在导致不安全输出状况的特定异常行为。特定安全分析用于限制应用于验证测试用例的输入条件这样就没必要对输入测试用例的潜在无限集进行寻址。注」该执行也会限制输入集和条件,从而使得执行不可能允许测试限制外的一个输入。特定安全分析法也能用于确定电路和元件功能的未缓解方面,而在这些功能中部分架构缓解是适用的。在这种情况下,特定安全分析是一个确定需要什么附加设计保证来完善安全覆盖范围的有用而且有效的方法。特定安全分析法对COTS硬件或定制电路和元件而言同样适用,因为它能使用关于那些电路和元件的用户指南数据(而非详细的内部设计数据)。通过将用户指南数据和这个更为详细的FFPA方法应用组合在一起,特定安全分析能够顺利地确定电路和元件使用的安全敏感方面以及有关的内部FFP,在这里有必要强调设计错误的消除。然后该信息能成功用于引出电路元件的验证测试;当完成时,这些测试将使验证进程已经暴露、更正、缓解那些电路和元件设计错误并为其提供工作区的可能性增至最大,而从系统安全角度来讲,这些设计错误会对硬件造成不利影响。A.3.3.2.1特定安全分析法一旦选用了将通过使用设计保证的特定安全分析法来进行寻址的电路和元件,就会执行一个附加FFPA来更为详细地对它们进行检查。此分析更明确地确定了哪些电路和元件功能会对已确定而且使用这些电路和元件的A级和B功能产生影响。考虑到该电路或元件的实际功能用途,而该电路和元件执行包含在已经确认的A级和B级FFP中的较高等级硬件功能,这可以通过在其功能边界逐例检查每个适用的电路和元件来完成。注L电路和元件用户指南数据中有足够的可用信息,从而使得用户能够成功使用该电路或元件的功能去执行更高等级的硬件功能。若提供有足够有关电路或元件内部机能的充足信息,它也就足以进行这一评估。若信息不足,便不能进行该评估,而且取而代之其它方法,或连同此方法一起使用。在基于那些电路和元件的实际用途对这些电路和元件的安全敏感功能进行确定之后,下一步便是更详细的功能分析。此分析应确定那些电路和元件功能具体的安全敏感和未缓解特性,这些电路和元件功能将利用特定安全验证条件进行更详细的寻址。通过使用F-FMEA法导出并鉴定这些验证条件,以便确定属于安全敏感的具体功能特性,进而确定在电路或元件内组成A级和B级FFP的那些功能的任何特定异常行为。通过上述特定安全分析活动所获得的导出验证条件而后连同下列指南一起用于完善对包含在A级和B级FFP内的电路和元件进行验证的特定安全分析标准。该指南包括:1.确定功能的相关输入空间。基于已经确定的安全敏感功能特性和异常行为来81n确定有关输出空间的通过/失败标准,并开发将会提供必要的相关输入空间范围的等价类。1.确定每个被考虑功能相关的可观察检测手段以及输入空间仿真手段。注:使用特殊工具和执行特征来确保可观察性和易测性。2.规定对潜在错误源和相互依存性的验证进行寻址的测试环境。注」在可行的最高集成等级上测试元件级功能。在较高等级上进行的集成测试通常提供了错误源(如翻转、相互依存性以及潜在的交叉功能相互作用)的最佳作用范围。应使用等价类来开发测试。测试应对关键逻辑决策、算术、定时、状态转换和实时特性进行寻址。A.3.3.2.2特定安全分析的解决应通过完成所有适用电路和元件的特定安全分析来建立特定安全验证完成标准。通过此分析或验证本身发现的任何不足均应通过以下方法解决:1.改变设计以更正错误。2.增加架构缓解,这样可通过从相关FFP中消除错误来解决这个错误。增加适当的测试。3.增加适当的测试A.3.3.2.3特定安全分析数据当应用于A级和B级FFP中的电路和元件时,特定安全分析的文件应以安全评估数据、安全要求数据、验证程序和结果以及可追溯性数据的形式进行提供。验证程序应可追溯到安全要求以及特定安全分析。特定保证分析数据应包括:1.通过特定安全分析法来寻址的电路和元件的确认。2.每个电路和元件所在的A级和B级FFP的确认。3.适用于电路和元件的部分架构缓解的确认,而设计保证完成将在这些电路和元件里通过特定安全分析法进行提供。4.对于每个适用的电路和元件而言,安全敏感功能的确认。5.对于每个已经确认的安全敏感功能而言,安全敏感特性以及所关注的异常行为的确认。6.对适用的电路、元件、内部功能、功能特性以及异常行为进行寻址的验证条件。81n1.对需要验证的输入依赖性和输出空间行为进行寻址的验证条件。2.验证程序和结果。3.将验证程序和硬件安全验证条件与特定安全硬件分析数据相连的可追溯数据。A.3.3.3形式法形式法这个术语指的是在计算机系统的规格、设计和结构中使用来自逻辑和离散数学的方法。注:本节中的材料来源于《用于软件和计算机系统验证的形式法规范与分析手册》第二卷:“从业者指南”,1997年5月,NASA-GB-001-07.这里可以查到带有实例说明的形式法应用更为详细的表述。形式法应用可大致分为两大类,即描述式的和演绎式的。描述式方法使用的是形式规范语言,这些语言规定了清晰明确的对要求以及其它制品的描述。演绎式方法依赖于一条要求清楚列举所有假定和推理步骤的规定。另外,每个推理步骤必须是一小部分容许干扰规则的一个实例o最严格的形式法应用这些方法来证实用于认明复杂或关键系统设计或实现的要求或其它方面的推理。形式法的目的是为了减少在评估论据方面对人类直觉和判断的依赖。也就是说,演绎形式法将论据的可接受性减少到一个计算;该计算原则上可以通过工具进行检查,从而用一个可重复操作代替了审核进程的固有主观性。在设计进程中,形式法的应用在几个区里提供附加保证。尽管形式法适用于整个设计进程,但通过目标应用可以获得设计保证的增加。下面的列表突出了某些可能性:1.形式法可以应用于开发生命周期的不同阶段。通常,形式法的应用在生命周期的早期阶段最为有效,尤其在要求捕获和高级设计期间。2.形式法可适用于整个设计,也可以特定元件为目标。FFPA用于确定要用形式法分析哪些FFPO处理复杂并行通信的协议和执行容错功能的硬件都可以利用形式法进行有效分析。3.形式法可用于检验系统的功能性,或者它们也可用于建立特有属性。尽管形式法在传统上和“正确性证明”有关联,也就是说,在确保元件符合功能规范的情况下,它们也能只应用于最重要的属性。通常更重要的是确定设计没有出现某些不合需要的属性,而非证明它具有全面功能性。形式法的实际应用一般需要工具支持。所使用的工具应进行评估,而且如有必要,这些工具应被证明合格,正如11.4节所述。A.3.3.3.1形式法的方法论通过用形式语言表达要求的方式来开始形式法的应用。要求规范起到一个重要81n的描述性功能。它用明确的注释为系统行为和属性的证明、通信和样机设计提供了的基础。此外,要求规范充当对系统行为进行计算或形式上预测的基础。使用形式语言来构造将要接受分析的元件的形式模型。使用所选择的形式逻辑的规则,根据要求的正式陈述来分析该模型。该模型的特征由将要执行的形式分析的类型来决定。该元件模型的细节等级由所选形式分析法的目标来确定。某些方法适合于查找可能逃过测试的设计错误,而其它一些方法却寻找某些类别的设计错误不存在的保证。1.检错。进行检错最普通的形式方法叫做模型检查。在这里,要求被表示为可判定瞬态逻辑里的公式。元件模型是一个抽象状态机,其设计目的让将要测试的特性可以保留。证明程序是自动的。一个失败的证明企图表明所仿真的元件存在设计错误。失败证明的结果是一个输入激励序列,这些激励明确地演示了元件为什么没有满足规定要求。2.排除错误。以预防错误为目标的形式法通常基于带有一个支持证明理论的表达式规范语言。随着表示的增加,可能要规定更复杂的要求以及构建更详细的元件模型。但是,证明程序只可以部分自动化。对于元件模型,适当等级的细节可以是一个可合成的HDL描述。在某些情况下,同一个模型既可用于仿真,也可用于形式分析。根据所分析的输入空间的规定要求,一个已经完成的证明是元件在逻辑上正确的证据。A.3.3.3.2形式法的解决一个演绎式形式分析有三个可能性结果:1.若证明尝试取得成功,验证活动就完整。设计保证等级依赖于所使用模型的保真度。举例来说,如果硬件项模型符合详细设计,那么该证明就提供了相当于穷举测试保证的功能正确性保证。2.在某些情况下,失败的证明导致了一个清晰的反例;也就是说,它确定了一个测试想定,尤其对设计为何未满足规定要求做出了阐明。这表明不是设计中有缺陷,就是要求上有缺陷。此类缺陷可通过更正设计、修改要求(显示为不是一个物理上可实现的条件)或使用其它方法来解决。确定所有反例以便解决。设计或要求的变化需要反馈回适当进程。a.当为了解决通过失败的证明尝试而确认的缺陷而对设计或要求进行修改之后,应再次尝试证明以确定修改已经成功解决了所确认的问题。重复此周期直至获得一个成功的证明。b.在某些认为不需要改变要求或设计就可解决反例但工具只确认了一个反例(即得以解决的反例)的情况下,应修改进程以便确定所有其它反例。3.需要解决的最困难的用例是当不能产生一个证明而反例也不能进行确认的时候。一个可能性选择就是修改设计以减少验证努力。另外可以用通过证明进行寻址的用例与那些需要其它手段来寻址的用例之间的一个清晰描绘来81n分解验证活动。对设计及条件的修改应反馈回FFPA。A.3.3.3.3形式法数据在形式法应用期间所开发的数据包括:1.需要使用的特定形式法途径以及形式法将要应用的元件或FFP的描述。2.要求的形式陈述。3.元件的形式模型。4.证明或充分详细的脚本,其目的是为了产生将元件模型与要求的形式陈述相联系而且包含可追溯性数据相关性的证明。5.所用工具和工具评估结果的确认。6.对验证测试用例以及作为分析结果而添加或修改的要求的确认。7.对针对通过分析进行寻址的FFP所获得的验证完整性等级的陈述。包括一列通过修改验证测试用例或要求也未能解决的分析差异及其差异可接受性的合理解释。81
关闭