DO-254通读--11.0 附加考虑

11.0 附加考虑本节提供了前几节未涵盖的设计保证附加考虑事项的指南。申请人可酌情使用这些附加考虑来满足第2节至第9节的部分目标。任何附加考虑的使用均应征得审定机构的同意。11.1 使用先前已开发的硬件本节讨论与使用先前已开发的硬件相关的问题。指南包括对硬件修改、飞机安装更改、应用环境更改或设计环境更改以及设计基线升级的评估。COTS组件一种特殊的先前已开发硬件的使用指南见第11.2节。每次使用先前已开发的硬件时还应考虑配置管理和过程保证方面的问题。使用先前已开发硬件的意图应在PHAC中说明。11.1.1 对先前已开发硬件的修改本节讨论对先前已开发硬件的修改。修改可能源于需求变更、检测到错误、硬件或技术改进或采购困难。对拟议修改的分析活动包括评审系统安全评估过程的输出。如果硬件设计保证等级提高则应用第11.1.4节的指南。应分析更改的影响包括更改可能导致涉及超出更改区域的重新验证工作的后果。该区域可通过信号流分析、功能分析、时序分析、可追溯性分析或其他合适的方法确定。11.1.2 飞机安装的更改本节讨论将在新的飞机安装中使用先前已按特定硬件设计保证等级和特定审定基础认证的硬件。在新的飞机安装中使用先前已开发的硬件时应遵循以下指南系统安全评估过程评估新的飞机安装并确定硬件设计保证等级和审定基础。如果新安装的要求与先前安装相同或宽松则无需额外工作。如果新安装需要功能修改则应满足第11.1.1节“对先前已开发硬件的修改”的指南。如果先前的设计活动未能产生证实新安装安全目标所需的输出则应满足第11.1.4节“升级设计基线”的指南。11.1.3 应用或设计环境的更改使用先前已开发的硬件可能涉及新的设计环境或与原始应用所使用的其他软件或硬件集成。新的设计环境可能会增加或减少硬件设计生命周期过程中的某些活动。指南包括如果新的设计环境使用硬件设计工具则可能适用第11.4节“工具评估与鉴定”的指南。当先前已开发的硬件与不同的接口硬件一起使用时应进行硬件接口验证。当先前已开发的硬件使用不同的软件时应解决硬件/软件接口重新验证的需求。11.1.4 升级设计基线以下指南适用于那些来自先前应用的生命周期数据被确定为不足以满足新应用相关安全目标的硬件项。本指南旨在帮助申请人就先前以较低硬件设计保证等级开发的硬件与审定机构达成一致升级设计基线的指南包括应满足本文件的目标同时利用先前开发的生命周期数据。审定硬件方面应基于系统安全评估过程确定的失效状态和硬件设计保证等级。应分析先前应用变更的影响以确定不足之处。应评估先前开发的生命周期数据以确保计划用于以所需硬件设计保证等级实现升级功能的硬件的验证过程目标得到满足。可使用逆向工程来重新生成缺失或不足的硬件生命周期数据以满足本文件的设计保证目标。如果计划在升级设计基线时使用产品使用经验来满足本文件的设计保证目标则应处理第11.3节“产品使用经验”的指南。申请人应在PHAC中说明实现符合本文件的策略。11.1.5 额外的配置管理考虑对于先前已开发硬件的新应用除第7节的指南外配置管理过程还应包括从先前应用的硬件产品和生命周期数据到新应用的可追溯性。能够管理来自通用项目不同应用的变更请求的变更控制过程。11.2 商用现成COTS组件的使用COTS组件在硬件设计中广泛使用通常COTS组件的设计数据不可供审查。审定过程不具体针对单个组件、模块或子组件因为这些是作为正在审定的特定飞机功能的一部分涵盖的。因此COTS组件的使用将通过本文件定义的整体设计过程包括支持过程进行验证。使用电子元器件管理过程与设计过程相结合为COTS组件的使用提供了基础。11.2.1 COTS 组件的电子元器件管理针对COTS组件的电子元器件管理是与硬件设计和开发相关的重要支持过程。电子元器件管理的过程适用于COTS电子元器件。虽然此过程涉及业务和技术两方面但本节仅处理影响审定的技术方面。通过确定以下方面可以获得审定信用组件制造商能够证明其生产高质量组件的业绩记录。组件制造商建立了质量控制程序。有使用经验支持组件的成功运行。组件已由制造商或通过额外测试进行鉴定从而确定了组件可靠性。组件制造商控制了组件质量水平或者通过额外的组件测试确保了这一点。组件是根据预期应用的技术适用性例如组件温度范围、功率或电压额定值选择的或者已通过额外测试或其他方法确定了这些。持续监控组件性能和可靠性并向组件制造商反馈需要改进的领域。11.2.2 COTS 组件采购COTS组件采购指南并非本文件的意图但当采购问题对硬件设计保证产生重大影响时申请人应管理和解决这些问题。主要关注点包括本文件要求的COTS组件设计保证数据的实际可用性。依赖于生产批次的组件参数变化可能无法识别即使通过稳健性测试也无法识别。电子元器件技术的不断发展。COTS组件变得无法采购。11.3 产品使用经验使用经验可用于证实先前已开发硬件和COTS组件的设计保证。使用经验涉及从组件任何先前或当前使用中收集的数据。来自非航空应用的数据不被排除。注某个项目在服役中广泛且成功的使用可提供信心表明该项目的设计是成熟的、无错误的并且其制造质量已得到证明。11.3.1 产品使用经验数据的可接受性标准当使用经验数据用于设计保证时使用经验数据的相关性和可接受性取决于以下一项或多项硬件项目在使用、功能、运行环境和设计保证等级方面的相似性。设计保证数据基于硬件项目拟议配置的程度。在被评估的使用期间发现的设计错误在将要使用的配置中已被消除、缓解或经分析确定无安全影响的程度。运行中的实际失效率。注PHAC应具体说明应用中部分内容的设计保证依赖使用经验数据的那些方面。11.3.2 产品使用经验数据的评估为满足上述标准申请人应基于工程分析评估先前应用、安装和环境与目标应用的相关性。注用于确定使用适宜性和使用限制的数据可能在规范、数据表、应用笔记、服务通告、用户通信和勘误通知中找到。这些信息来源也可能描述与硬件项相关的功能因此可以将预期的空中使用与先前使用相关联。评估预期使用对安全评估过程的影响包括可能缓解数据中识别出的设计错误的影响。评估任何可用的关于设计错误的统计数据及其对安全评估过程的影响。如果统计数据不可用可使用定性评估。评估可用的问题报告。问题报告可能表明使用经验已导致改进这些改进现已在当前配置中可用。已识别但未解决的问题仍可能通过架构手段或执行额外的验证来缓解。建立或评估问题报告与硬件项或产品需求变更之间的关系。注对于电子元器件大量的使用可能会增加错误已被检测和消除或可获得临时“修复”的可能性。11.3.3 产品使用经验评估数据用于证实拟议应用设计保证的使用经验评估数据应包括组件的标识及其在航空系统中的预期功能。标识设计保证等级或者对于在A级和B级功能中使用的组件描述该组件的额外保证手段例如应用的架构手段和额外的或高级的验证策略。使用经验数据收集和评估过程的描述包括确定数据充分性和有效性的标准。使用经验数据包括正在考虑的详细使用信息、变更历史、用于分析使用经验数据的假设以及分析结果摘要。使用经验数据相对于预期用途和所需设计保证等级充分性的理由。11.4 工具评估与鉴定工具包括硬件和软件工具通常在硬件设计和验证过程中使用。当使用设计工具生成硬件项或硬件设计时工具中的错误可能会将错误引入硬件项。当使用验证工具验证硬件项时工具中的错误可能导致工具未能检测到硬件项或硬件设计中的错误。在使用工具之前应进行工具评估。应记录并维护此评估的结果以及必要时进行的工具鉴定。工具评估与鉴定的目的是确保工具能够以可接受的置信水平执行其将被用于的特定设计或验证活动。11.4.1 工具评估与鉴定过程工具评估评估工具在设计生命周期过程中的作用并且可能包括根据工具的作用和硬件功能的设计保证等级需要执行的鉴定活动。此评估指南以流程图形式呈现适用于为实现目标或生成满足这些目标的数据项而使用的设计工具和验证工具。该流程图将引导申请人对某些类别的工具进行有限评估并对其他类别的工具进行工具鉴定。工具评估与鉴定过程可应用于单个工具或工具集合。工具通常包含超出任何特定项目上特定设计或验证活动所需范围的能力。仅需评估用于特定硬件生命周期活动的那些工具功能而非整个工具。需认识到工具在各个生命周期阶段通常是集成和共享的。如果同一工具在设计和验证阶段均使用则该工具可能需要作为设计工具进行评估除非可以建立两种功能之间的分离和保护。注1如果对给定工具的评估表明其某些功能用于设计但其他功能用于验证则分别处理这些功能并对该工具被评估的每组功能进行评估可能是值得的。注2此评估活动关注的重点与工具本身同样多甚至更多地关注工具的应用。图11-1的流程图指出了工具评估的考虑因素和活动并提供了何时可能需要进行工具鉴定的指南。决策和活动框内的数字引用了图后提供的编号项以进一步阐明该决策或活动。识别工具。包括工具的名称、来源、版本号及其所依赖的主机环境。工具的更新应被记录和跟踪。注更新工具时应评估工具更新对现有结果以及硬件剩余生命周期的潜在影响。识别工具所支持的过程。识别工具所支持的设计或验证过程、工具的任何相关限制以及它为在硬件设计生命周期中使用而产生的输出。如果已知工具存在某些问题应提供工具使用可接受性的声明并说明理由。工具的输出是否被独立评估独立评估使用独立的方法验证工具输出的正确性。如果工具输出被独立评估则无需进一步评估。注对于全部或部分由工具生成的设计工具输出其独立评估可通过对该项目如组件、网表或组件执行的验证活动来确定。在这种情况下最终项目的完整性并不仅仅依赖于设计工具输出的正确性。对验证工具输出的独立评估可包括对工具输出的人工评审或与能够执行与被评估工具相同验证活动的独立工具的输出进行比较。申请人也可提议其他独立评估方法。该工具是A、B或C级设计工具还是A或B级验证工具如果该工具用于D级功能、作为C级功能的验证工具或用于评估验证测试的完成情况如附录B第3.3.1.1.2节所述的元素分析则无需进一步评估。如果该工具用作实现A、B或C级功能的硬件设计工具或用作实现A或B级功能的硬件验证工具则需要进一步评估。工具是否有相关历史当能够证明该工具先前已被使用且被发现能产生可接受的结果时则无需进一步评估。理由中应包含对先前工具使用与拟议工具使用相关性的讨论。注工具的历史可基于空中或非空中应用前提是有数据证实工具历史的相关性和可信度。为工具鉴定建立基线和问题报告。建立工具配置管理和工具问题报告的基线为工具鉴定做准备。基础工具鉴定。制定并执行一项计划通过分析或测试确认工具能为其预期应用产生正确的输出。工具的用户指南或其他描述工具功能及其使用的文档可用于生成要求。工具类型和等级所考虑的工具是A级或B级硬件设计工具还是C级硬件设计工具或是A级或B级硬件验证工具设计工具鉴定。使用本文件附录B中描述的策略、RTCA DO-178B / EUROCAE ED-12B中关于软件开发工具的工具鉴定指南或审定机构可接受的其他方法对A级或B级设计工具进行鉴定。还应确保此活动独立于工具开发。注由于工具使用情况、所涉及技术、工具实现的可见性和生命周期数据以及其他因素的变化此处未提供针对A级和B级设计工具鉴定的具体指南。不建议在未对工具输出进行独立评估或未建立相关历史的情况下使用此类设计工具因为这可能被证明与开发拟使用该工具的硬件一样具有挑战性。完成。记录工具评估、评估决策的理由以及如适用工具鉴定数据。根据需要提供对安装指南、用户手册和工具鉴定数据的具体引用以支持工具分配和鉴定。11.4.2 工具评估与鉴定数据工具评估与鉴定数据应包括识别工具、其所支持的过程以及如适用以下项目a. 根据图11-1第3项进行独立评估的理由和结果。b. 根据图11-1第4项确定的工具指定。c. 用于满足图11-1第5项要求的工具历史记录。理由中应包含对先前工具使用与拟议工具使用相关性的讨论。根据图11-1第6项用于工具鉴定的明确配置定义并且如果测试的配置与实际用于设计或验证最终硬件项的配置不同应说明测试配置适用性的理由。工具鉴定的详细信息包括测试中使用的需求、测试程序、预期结果、用于解释和补充测试结果的分析程序以及如何建立独立性。鉴定设计工具的计划包括适用的程序以及计划中确定的任何活动的结果。已知工具勘误的处理情况包括解决方法以及如适用因工具鉴定而产生的问题报告。回到目录