RTCA DO-178C 机载系统和设备认证中的软件注意事项-其他注意事项（十二）

12.0 其他注意事项ADDITIONAL CONSIDERATIONS

本文档的前面部分提供了满足认证要求的指南，其中申请人提交这些部分中所述的软件生命周期过程的证据。 本节提供有关目标和/或活动可能替换、修改或添加到本文档其余部分中定义的部分或全部目标和/或活动的其他注意事项的指导。 其他考虑因素的使用以及对本文件其他部分中提供的指南的拟议影响应根据具体情况与认证机构达成一致。The previous sections of this document provide guidance for satisfying certification requirements in which the applicant submits evidence of the software life cycle processes as described in those sections. This section provides guidance on additional considerations where objectives and/or activities may replace, modify, or add to some or all of the objectives and/or activities defined in the rest of this document. The use of additional considerations and the proposed impact on the guidance provided in the other sections of this document should be agreed on a case-by-case basis with the certification authorities.

12.1 使用以前开发的软件Use of Previously Developed Software

本节的指导讨论了与使用先前开发的软件相关的问题，包括修改的评估； 改变飞机安装、应用环境或开发环境的影响； 更新开发基线； 以及 SCM 和 SQA 考虑因素。 软件方面认证计划中阐述了使用先前开发的软件的意图。 应评估与先前开发的软件相关的未解决问题报告的影响。The guidance of this section discusses the issues associated with the use of previously developed software, including the assessment of modifications; the effect of changing an aircraft installation, application environment, or development environment; upgrading a development baseline; and SCM and SQA considerations. The intention to use previously developed software is stated in the Plan for Software Aspects of Certification. Unresolved Problem Reports associated with the previously developed software should be evaluated for impact.

12.1.1 对先前开发的软件的修改 Modifications to Previously Developed Software

本指南讨论了对先前开发的软件的修改，其中先前软件生命周期过程的输出符合本文档。 修改可能是由需求变化、错误检测和/或软件增强引起的。This guidance discusses modifications to previously developed software where the outputs of the previous software life cycle processes comply with this document. Modification may result from requirement changes, the detection of errors, and/or software enhancements.

活动包括：Activities include:

a. 应考虑拟议的修改来审查系统安全评估过程的修订输出。The revised outputs of the system safety assessment process should be reviewed considering the proposed modifications.

b. 如果软件级别被修改，则应考虑第 12.1.4 节的指导。If the software level is revised, the guidance of section 12.1.4 should be considered.

c. 应该分析软件需求变更的影响和软件架构变更的影响，包括软件需求变更对其他需求的影响以及可能导致涉及超出修改区域的重新验证工作的多个软件组件之间的耦合。Both the impact of the software requirements changes and the impact of software architecture changes should be analyzed, including the consequences of software requirement changes upon other requirements and the coupling between several software components that may result in reverification effort involving more than the modified area.

d. 应确定受变化影响的区域。 这可以通过数据流分析、控制流分析、时序分析、可追溯性分析或这些分析的组合来完成。The area affected by a change should be determined. This may be done by data flow analysis, control flow analysis, timing analysis, traceability analysis, or a combination of these analyses.

e. 受变更影响的区域应按照第 6 条重新核实。Areas affected by the change should be reverified in accordance with section 6.

12.1.2 飞机安装变更 Change of Aircraft Installation

包含先前已在特定软件级别和特定认证基础上"批准"的软件的机载系统或设备可以在新飞机安装中使用。 活动包括：Airborne systems or equipment containing software that has been previously "approved" at a certain software level and under a specific certification basis may be used in a new aircraft installation. Activities include:

a. 系统安全评估过程评估新飞机的安装并确定软件级别和认证依据。 如果新安装的这些内容与先前安装的内容相同，则无需进行额外的工作。The system safety assessment process assesses the new aircraft installation and determines the software level and the certification basis. No additional effort will be required if these are the same for the new installation as they were in the previous installation.

b. 如果新安装需要进行功能修改，则应满足第 12.1.1 节的指导。If functional modifications are required for the new installation, the guidance of section 12.1.1 should be satisfied.

c. 如果先前的开发活动没有产生证实新装置的系统安全目标所需的输出，则应满足第 12.1.4 节的指导。If the previous development activity did not produce outputs required to substantiate the system safety objectives of the new installation, the guidance of section 12.1.4 should be satisfied.

12.1.3 应用或开发环境变更 Change of Application or Development Environment

使用和修改先前开发的软件可能涉及新的开发环境、新的目标处理器或其他硬件，或者与原始应用程序以外的其他软件的集成。Use and modification of previously developed software may involve a new development environment, a new target processor or other hardware, or integration with other software than that used for the original application.

新的开发环境可能会增加或减少软件生命周期内的某些活动。 除了解决修改的软件生命周期过程活动之外，新的应用程序环境可能还需要其他活动。New development environments may increase or reduce some activities within the software life cycle. New application environments may require activities in addition to software life cycle process activities that address modifications.

应识别、分析和验证应用程序或开发环境的更改。Changes to an application or development environment should be identified, analyzed, and reverified.

活动包括： Activities include:

a. 如果新的开发环境使用软件工具，则第 12.2 节的指导可能适用。If a new development environment uses software tools, the guidance of section 12.2 may be applicable.

b. 应用程序变更评估的严格性应考虑编程语言的复杂性和复杂性。 例如，如果新应用程序中的泛型参数不同，则对 Ada 泛型的评估严格性会更高。 对于面向对象的语言，如果继承的对象在新应用程序中不同，那么严格性会更高。The rigor of the evaluation of an application change should consider the complexity and sophistication of the programming language. For example, the rigor of the evaluation for Ada generics will be greater if the generic parameters are different in the new application. For object-oriented languages, the rigor will be greater if the objects that are inherited are different in the new application.

c. 使用不同的自动代码生成器或不同的自动代码生成器选项集可能会更改生成的源代码或目标代码。 应分析任何变化的影响。Using a different autocode generator or a different set of autocode generator options may change the Source Code or object code generated. The impact of any changes should be analyzed.

d. 如果使用不同的编译器或不同的编译器选项集，导致不同的目标代码，则使用该目标代码的先前软件验证过程活动的结果可能无效，并且不应用于新应用程序。 在这种情况下，先前的测试结果对于新应用程序的结构覆盖标准可能不再有效。 同样，编译器关于优化的假设可能无效。If a different compiler or different set of compiler options are used, resulting in different object code, the results from a previous software verification process activity using the object code may not be valid and should not be used for the new application. In this case, previous test results may no longer be valid for the structural coverage criteria of the new application. Similarly, compiler assumptions about optimization may not be valid.

e. 如果使用不同的处理器，则执行变更影响分析以确定：If a different processor is used, then a change impact analysis is performed to determine:

1. 新的软件组件或因更改处理器而需要修改的软件组件，包括对硬件/软件集成的任何修改。Software components that are new or will need to be modified as a result of changing the processor, including any modification for hardware/software integration.

2. 针对可用于新应用程序的硬件/软件接口的先前软件验证过程活动的结果。The results from a previous software verification process activity directed at the hardware/software interface that may be used for the new application.

3. 应该为新应用程序执行先前的硬件/软件集成测试。 预计将始终运行最少的一组测试。Previous hardware/software integration tests that should be executed for the new application. It is expected that there will always be a minimal set of tests to be run.

4. 可能需要进行额外的硬件/软件集成测试和审查。Additional hardware/software integration tests and reviews that may be necessary.

f. 如果除处理器之外的硬件项目发生更改，并且软件设计将接口模块与其他模块隔离，则应执行更改影响分析以：If a hardware item, other than the processor, is changed and the design of the software isolates the interfacing modules from other modules then a change impact analysis should be performed to:

1. 确定新的或将修改的软件模块或接口以适应更改的硬件组件。Determine the software modules or interfaces that are new or will be modified to accommodate the changed hardware component.

2. 确定所需重新验证的范围。Determine the extent of reverification required.

g. 当先前开发的软件与不同的接口软件一起使用时，应进行软件接口的验证。 变更影响分析可用于确定所需重新验证的程度。Verification of software interfaces should be conducted where previously developed software is used with different interfacing software. A change impact analysis may be used to determine the extent of reverification required.

12.1.4 更新开发基线Upgrading a Development Baseline

由于与新应用程序相关的要求，对于先前应用程序的软件生命周期数据被确定为不充分或不满足本文档目标的软件，将遵循以下指南。 本指南旨在帮助实现本文件的目标，适用于：Guidance follows for software whose software life cycle data from a previous application are determined to be inadequate or do not satisfy the objectives of this document, due to the requirements associated with a new application. This guidance is intended to aid in satisfying the objectives of this document when applied to:

• 商用现成软件。COTS software.

• 机载软件开发以其他指导。Airborne software developed to other guidance.

• 在本文档存在之前开发的机载软件。Airborne software developed prior to the existence of this document.

• 先前针对本文档开发的软件处于较低的软件级别。Software previously developed to this document at a lower software level.

更新开发基线的活动包括：Activities for upgrading a development baseline include:

a. 在利用先前开发的软件生命周期数据来满足新应用程序的目标的同时，应该满足本文档的目标。The objectives of this document should be satisfied while taking advantage of software life cycle data of the previous development that satisfy the objectives for the new application.

b. 认证的软件方面应基于系统安全评估过程确定的故障条件和软件级别。 与先前应用程序的故障情况进行比较将确定可能需要升级的区域。Software aspects of certification should be based on the failure conditions and software level(s) as determined by the system safety assessment process. Comparison to failure conditions of the previous application will determine areas that may need to be upgraded.

c. 应评估先前开发的软件生命周期数据，以确保新应用程序满足软件级别的软件验证过程目标所需的严格性和独立性。Software life cycle data from a previous development should be evaluated to ensure that the software verification process objectives of the software level are satisfied for the new application to the necessary level of rigor and independence.

d. 逆向工程可用于重新生成在满足本文档的目标方面不充分或缺失的软件生命周期数据。 除了生产软件产品之外，可能还需要执行其他活动来满足软件验证过程的目标。Reverse engineering may be used to regenerate software life cycle data that is inadequate or missing in satisfying the objectives of this document. In addition to producing the software product, additional activities may need to be performed to satisfy the software verification process objectives.

e. 如果计划使用产品服务历史来满足本文件更新开发基线的目标，则应考虑第 12.3.4 节。If use of product service history is planned to satisfy the objectives of this document in upgrading a development baseline, section 12.3.4 should be considered.

f. 申请人应在软件方面的认证计划中指定实现遵守本文件的策略。The applicant should specify the strategy for accomplishing compliance with this document in the Plan for Software Aspects of Certification.

12.1.5 软件配置管理注意事项 Software Configuration Management Considerations

如果使用以前开发的软件，则新应用程序的软件配置管理流程活动除第 7 节的活动外还应包括：If previously developed software is used, the software configuration management process activities for the new application should include, in addition to the activities of section 7:

a. 提供从先前应用程序的软件产品和软件生命周期数据到新应用程序的可追溯性。Providing traceability from the software product and software life cycle data of the previous application to the new application.

b. 提供变更控制，支持问题报告、问题解决以及跟踪多个应用程序中使用的软件组件的变更。Providing change control that enables problem reporting, problem resolution, and tracking of changes to software components used in more than one application.

12.1.6 软件质量保证注意事项 Software Quality Assurance Considerations

如果使用以前开发的软件，除第 8 节的活动外，软件质量保证活动还应包括：If previously developed software is used, the software quality assurance activities should include, in addition to the activities of section 8:

a. 确保软件组件满足或超过新应用程序软件级别的软件生命周期标准。Providing assurance that the software components satisfy or exceed the software life cycle criteria of the software level for the new application.

b. 确保软件计划中规定了软件生命周期过程的变更。Providing assurance that changes to the software life cycle processes are stated in the software plans.

12.2 工具鉴定 Tool Qualification

12.2.1 确定是否需要工具鉴定 Determining if Tool Qualification is Needed

当通过使用软件工具消除、减少或自动化本文档的流程而未按照第 6 节的规定验证其输出时，需要对工具进行资格认证。Qualification of a tool is needed when processes of this document are eliminated, reduced, or automated by the use of a software tool without its output being verified as specified in section 6.

工具鉴定过程的目的是确保该工具提供的信心至少相当于消除、减少或自动化过程的信心。The purpose of the tool qualification process is to ensure that the tool provides confidence at least equivalent to that of the process(es) eliminated, reduced, or automated.

工具鉴定过程可以应用于单个工具、工具集合或者工具内的一个或多个功能。 对于具有多种功能的工具，如果可以证明对工具功能的保护，则只需限定那些用于消除、减少或自动化软件生命周期过程且其输出未经验证的功能。 保护是使用一种机制来确保工具功能不会对另一个工具功能产生不利影响。The tool qualification process may be applied to a single tool, a collection of tools, or one or more functions within a tool. For a tool with multiple functions, if protection of tool functions can be demonstrated, only those functions that are used to eliminate, reduce or automate software life cycle processes, and whose outputs are not verified, need be qualified. Protection is the use of a mechanism to ensure that a tool function cannot adversely impact another tool function.

工具仅适用于特定系统，其中支持该系统的软件方面认证计划中规定了使用该工具的意图。 如果先前在一个系统上合格的工具建议在另一个系统上使用，则应在该另一个系统的上下文中重新对其进行资格认证。A tool is qualified only for use on a specific system where the intention to use the tool is stated in the Plan for Software Aspects of Certification that supports the system. If a tool previously qualified on one system is proposed for use on another system, it should be requalified within the context of that other system.

12.2.2 确定鉴定的工具等级 Determining the Tool Qualification Level

如果需要工具资格认证，则应评估工具使用对软件生命周期过程的影响，以确定其工具鉴定等级（TQL）。 应使用以下标准来确定该工具的影响：If tool qualification is needed, the impact of the tool use in the software life cycle processes should be assessed in order to determine its tool qualification level (TQL). The following criteria should be used to determine the impact of the tool:

a. 标准 1：工具的输出是机载软件的一部分，因此可能会插入错误。Criteria 1: A tool whose output is part of the airborne software and thus could insert an error.

b. 标准 2：自动化验证过程的工具，因此可能无法检测到错误，其输出用于证明消除或减少的合理性：Criteria 2: A tool that automates verification process(es) and thus could fail to detect an error, and whose output is used to justify the elimination or reduction of:

1. 除工具自动执行的验证过程之外，或Verification process(es) other than that automated by the tool, or

2. 可能对机载软件产生影响的开发过程。Development process(es) that could have an impact on the airborne software.

c. 标准 3：工具在其预期用途范围内可能无法检测到错误。Criteria 3: A tool that, within the scope of its intended use, could fail to detect an error.

如果该工具消除、减少或自动化了本文档中的流程，并且其输出未按照第 6 节中的规定进行验证，则相应的 TQL 如表 12-1 所示。 根据工具的使用及其在软件生命周期过程中的潜在影响，确定了五个级别的工具资格（TQL-1 到 TQL-5）。 TQL-1 是最严格的级别，TQL-5 是最不严格的级别。 在评估给定工具的影响时，应按从标准 1 到标准 3 的顺序考虑标准。工具资格级别应尽早与认证机构协调。If the tool eliminates, reduces, or automates processes in this document and its output is not verified as specified in section 6, the appropriate TQL is as shown in Table 12-1. Five levels of tool qualification, TQL-1 to TQL-5, are identified based on the tool use and its potential impact in the software life cycle processes. TQL-1 is the most rigorous level and TQL-5 is the least rigorous level. When assessing the impact of a given tool, the criteria should be considered sequentially from criteria 1 to criteria 3. The tool qualification level should be coordinated with the certification authority as early as possible.

表 12-1 工具鉴定等级确定

Table 12-1 Tool Qualification Level Determination

|--------------------|-------|-------|-------|
| Software Level | Criteria |||
| Software Level | 1 | 2 | 3 |
| A | TQL-1 | TQL-4 | TQL-5 |
| B | TQL-2 | TQL-4 | TQL-5 |
| C | TQL-3 | TQL-5 | TQL-5 |
| D | TQL-4 | TQL-5 | TQL-5 |

12.2.3 工具鉴定流程 Tool Qualification Process

DO-330"软件工具资格注意事项"中描述了每个工具资格级别所需的目标、活动、指南和生命周期数据。The objectives, activities, guidance, and life cycle data required for each Tool Qualification Level are described in DO-330, "Software Tool Qualification Considerations."

12.3 替代方法 Alternative Methods

由于编写本文档时成熟度不够或机载软件的适用性有限，因此本文档前面的部分未讨论某些方法。 本文件无意限制任何当前或未来方法的实施。 本节中讨论的任何单一替代方法均可用于满足本文档中的一个或多个目标。 此外，可以使用替代方法来相互支持。Some methods were not discussed in the previous sections of this document because of inadequate maturity at the time this document was written or limited applicability for airborne software. It is not the intention of this document to restrict the implementation of any current or future methods. Any single alternative method discussed in this section may be used in satisfying one or more of the objectives in this document. In addition,alternative methods may be used to support one another.

不能脱离软件开发过程套件来考虑替代方法。 获得替代方法可信认证的努力取决于软件级别以及替代方法对软件生命周期过程的影响。 使用替代方法的指南包括：An alternative method cannot be considered in isolation from the suite of software development processes. The effort for obtaining certification credit of an alternative method is dependent on the software level and the impact of the alternative method on the software life cycle processes. Guidance for using an alternative method includes:

a. 应展示一种替代方法来满足本文件或适用补充文件的目标。An alternative method should be shown to satisfy the objectives of this document or the applicable supplement.

b. 申请人应在《软件认证计划》中明确以下内容，并取得认证机构的同意：The applicant should specify in the Plan for Software Aspects of Certification, and obtain agreement from the certification authority for:

1. 所提出的方法对软件开发过程的影响。The impact of the proposed method on the software development processes.

2. 所提出的方法对软件生命周期数据的影响。The impact of the proposed method on the software life cycle data.

3. 使用替代方法的理由表明系统安全目标得到满足。 提出使用替代方法的基本原理的一种技术是保证案例，其中明确给出论据，将证据与符合系统安全目标的声明联系起来。The rationale for use of the alternative method that shows that the system safety objectives are satisfied. One technique for presenting the rationale for using an alternative method is an assurance case, in which arguments are explicitly given to link the evidence to the claims of compliance with the system safety objectives.

c. 应通过软件计划、流程、预期结果和方法使用证据来证实其基本原理。The rationale should be substantiated by software plans, processes, expected results, and evidence of the use of the method.

12.3.1 详尽的输入测试 Exhaustive Input Testing

在某些情况下，机载系统或设备的软件组件很简单且隔离，使得输入和输出集可以受到限制。 如果是这样，则可以证明该输入空间的详尽测试可以替代第 6 节中确定的一个或多个软件验证过程活动。There are situations where the software component of an airborne system or equipment is simple and isolated such that the set of inputs and outputs can be bounded. If so, it may be possible to demonstrate that exhaustive testing of this input space can be substituted for one or more of the software verification process activities identified in section 6.

对于这种替代方法，活动包括：For this alternative method, activities include:

a. 定义软件的完整有效输入和输出集。Defining the complete set of valid inputs and outputs of the software.

b. 执行分析以确认软件输入的隔离。Performing an analysis that confirms the isolation of the inputs to the software.

c. 为详尽的输入测试用例和程序制定基本原理。Developing rationale for the exhaustive input test cases and procedures.

d. 开发测试用例、测试过程和测试结果。Developing the test cases, test procedures, and test results.

12.3.2 多版本异种软件验证的注意事项 Considerations for Multiple-Version Dissimilar Software Verification

以下指南涉及软件验证过程，因为它适用于多个版本的不同软件。 如果由于使用多个版本的不同软件而修改了软件验证过程，则应提供证据证明软件验证过程目标得到满足，并且每个软件版本都实现了等效的错误检测。Guidance follows concerning the software verification process as it applies to multiple version dissimilar software. If the software verification process is modified because of the use of multiple-version dissimilar software, evidence should be provided that the software verification process objectives are satisfied and that equivalent error detection is achieved for each software version.

该软件的多个不同版本是使用这些技术的组合来生成的：Multiple, dissimilar versions of the software are produced using combinations of these techniques:

• 源代码以两种或多种不同的编程语言实现。The Source Code is implemented in two or more different programming languages.

• 目标代码是使用两个或多个不同的编译器生成的。The object code is generated using two or more different compilers.

• 可执行目标代码的每个软件版本都在单独的不同处理器上执行，或者在具有在软件版本之间提供分区的方式的单个处理器上执行。Each software version of Executable Object Code executes on a separate, dissimilar processor, or on a single processor with the means to provide partitioning between the software versions.

• 软件需求、软件设计和/或源代码由两个或多个开发团队开发，其交互受到管理。The software requirements, software design, and/or Source Code are developed by two or more development teams whose interactions are managed.

• 软件需求、软件设计和/或源代码在两个或多个软件开发环境中开发，和/或每个版本使用单独的测试环境进行验证。The software requirements, software design, and/or Source Code are developed in two or more software development environments, and/or each version is verified using separate test environments.

• 使用两个或多个不同的链接编辑器和两个或多个不同的加载器来链接和加载可执行目标代码。The Executable Object Code is linked and loaded using two or more different linkage editors and two or more different loaders.

• 软件需求、软件设计和/或源代码的开发分别符合两个或多个不同的软件需求标准、软件设计标准和/或软件代码标准。The software requirements, software design, and/or Source Code are developed in conformance with two or more different Software Requirements Standards, Software Design Standards, and/or Software Code Standards, respectively.

当使用多个版本的软件时，可以对用于验证单一版本软件的软件验证方法进行修改。 它们将适用于多线程的软件开发过程活动，例如单独的多个开发团队。 软件验证过程取决于组合的硬件和软件架构，因为这会影响多个软件版本的差异。 要满足的其他软件验证过程目标是证明：When multiple versions of software are used, the software verification methods may be modified from those used to verify single version software. They will apply to software development process activities that are multi-thread, such as separate, multiple development teams. The software verification process is dependent on the combined hardware and software architectures since this affects the dissimilarity of the multiple software versions. Additional software verification process objectives to be satisfied are to demonstrate that:

a. 满足版本间兼容性要求，包括正常和异常操作以及状态转换时的兼容性。Inter-version compatibility requirements are satisfied, including compatibility during normal and abnormal operations and state transitions.

b. 实现了等效的错误检测。Equivalent error detection is achieved.

如果软件验证过程活动的其他变更得到了认证机构的同意，前提是这些变更得到了确认等效软件验证覆盖范围的理由的证实。Other changes in software verification process activities may be agreed with the certification authority, if the changes are substantiated by rationale that confirms equivalent software verification coverage.

12.3.2.1 多版本异种软件的独立性 Independence of Multiple-Version Dissimilar Software

当使用托管方法独立开发多个版本的不同软件版本时，开发过程有可能揭示某些类别的错误，使得每个软件版本的验证等同于软件开发过程的独立验证。 活动包括：When multiple-version dissimilar software versions are developed independently using a managed method, the development processes have the potential to reveal certain classes of errors such that verification of each software version is equivalent to independent verification of the software development processes. Activities include:

a. 申请人应证明每个软件版本的软件需求、软件设计和源代码是由不同的有限互动团队开发的。The applicant should demonstrate that different teams with limited interaction developed each software version's software requirements, software design, and Source Code.

b. 独立测试覆盖率分析仍应像单个版本一样进行。Independent test coverage analyses should still be performed as with a single version.

注：第 12.3.2.1 节仅讨论独立性主题。 没有讨论或有意降低软件级别。

Note: Section 12.3.2.1 only addresses the subject of independence. Reduction of software levels is not discussed or intended.

12.3.2.2 与多处理器相关的验证 Multiple Processor-Related Verification

当不同版本的软件在不同类型的处理器上执行时，代码与处理器的兼容性的某些方面的验证（见6.4.3.a）可以被验证所取代，以确保多种类型的处理器产生相同的结果。 正确的输出。 此验证包括集成测试，其中在基于需求的测试用例中交叉比较多个版本的输出。 申请人应完成以下活动：When each version of dissimilar software executes on a different type of processor, the verification of some aspects of compatibility of the code with the processor (see 6.4.3.a) may be replaced by verification to ensure that the multiple types of processor produce the correct outputs. This verification consists of integration tests in which the outputs of the multiple versions are cross-compared in requirements-based test cases. The applicant should complete the following activities:

a. 表明实现了等效的错误检测。Show that equivalent error detection is achieved.

b. 表明每个处理器都是由不同的开发人员设计的。Show that each processor was designed by a different developer.

c. 证明多个版本的输出是等效的。Show that the outputs of the multiple versions are equivalent.

12.3.2.3 多版本源代码验证 Multiple-Version Source Code Verification

对于使用多版本不同软件的系统或设备，结构覆盖分析指南（见 6.4.4.2）可能会进行修改。 对于结构覆盖分析，无需执行随附的 A 级活动（参见 6.4.4.2.b），以评估无法直接追溯到源代码语句的任何附加代码（由编译器、链接器或其他方式生成），前提是： 申请人完成以下活动：The guidance for structural coverage analysis (see 6.4.4.2) may be modified for systems or equipment using multiple-version dissimilar software. For structural coverage analysis, the accompanying Level A activity (see 6.4.4.2.b) to evaluate any additional code (generated by a compiler, linker, or other means) that is not directly traceable to Source Code statements need not be done provided that the applicant completes the following activities:

a. 表明每个版本的软件都是使用不同的编程语言进行编码的。Show that each version of software is coded using a different programming language.

b. 表明使用的每个编译器都来自不同的开发人员。Show that each compiler used is from a different developer.

12.3.2.4 多版本不同软件的工具资格 Tool Qualification for Multiple-Version Dissimilar Software

如果使用多个版本不同的软件，并且有证据表明软件开发过程中使用的多个软件工具不同，则可以修改工具鉴定过程。 这取决于使用不同软件工具开发多个软件版本时等效软件验证过程活动的演示。 申请人应完成以下活动：If multiple-version dissimilar software is used, the tool qualification process may be modified, if evidence is available that the multiple software tools used in the software development process are dissimilar. This depends on the demonstration of equivalent software verification process activity in the development of the multiple software versions using dissimilar software tools. The applicant should complete the following activities:

a. 表明每个工具都是从不同的开发人员那里获得的。Show that each tool was obtained from a different developer.

b. 表明每个工具都有不同的设计。Show that each tool has a dissimilar design.

12.3.2.5 多模拟器和验证 Multiple Simulators and Verification

如果使用单独的不同模拟器来验证多个版本的不同软件版本，则可以修改模拟器的工具鉴定方法。 这取决于使用多个模拟器模拟多个软件版本时等效软件验证过程活动的演示。 除非有理由证明多个模拟器没有必要不同，否则申请人应完成以下活动：If separate, dissimilar simulators are used to verify multiple-version dissimilar software versions, then the approach to tool qualification of the simulators may be modified. This depends on the demonstration of equivalent software verification process activity in the simulation of the multiple software versions using multiple simulators. Unless it can be justified as unnecessary for multiple simulators to be dissimilar, the applicant should complete the following activities:

a. 提供证据证明每个模拟器是由不同的团队开发的。Provide evidence that each simulator was developed by a different team.

b. 提供证据证明每个模拟器都有不同的要求、不同的设计和不同的编程语言。Provide evidence that each simulator has different requirements, a different design, and a different programming language.

c. 供每个模拟器在不同处理器上执行的证据。Provide evidence that each simulator executes on a different processor.

注意：当使用多个不同版本的软件的多处理器系统在相同的处理器上执行时，由于依赖于从公共来源（例如处理器制造商）获得的信息，可能很难证明模拟器的差异。

Note: When a multiple processor system using multiple, dissimilar versions of software are executing on identical processors, it may be difficult to demonstrate dissimilarity of simulators because of the reliance on information obtained from a common source, for example, the processor manufacturer.

12.3.3 软件可靠性模型 Software Reliability Models

已经发布了许多基于开发指标来预测软件可靠性的方法，例如软件结构、缺陷检测率等。本文档没有为这些类型的方法提供指导，因为在撰写本文时，当前可用的方法没有 提供值得信赖的结果。

Many methods for predicting software reliability based on developmental metrics have been published, for example, software structure, defect detection rate, etc. This document does not provide guidance for those types of methods, because at the time of writing, currently available methods did not provide results in which confidence can be placed.

12.3.4 产品服务历史 Product Service History

如果可以通过使用该软件的产品服务历史来证明该软件具有同等的安全性，则可以授予一些可信认证。 该方法的可接受性取决于：If equivalent safety for the software can be demonstrated by the use of the software's product service history, some certification credit may be granted. The acceptability of this method is dependent on:

• 软件的配置管理。 Configuration management of the software.

• 问题报告活动的有效性。 Effectiveness of problem reporting activity.

• 软件的稳定性和成熟度。 Stability and maturity of the software.

• 产品服务历史环境的相关性。 Relevance of product service history environment.

• 产品服务历史的长度。 Length of the product service history.

• 产品服务历史记录中的实际错误率。 Actual error rates in the product service history.

• 修改的影响。 Impact of modifications.

可信认证的服务历史数据的使用取决于服务历史期间发生的问题的充分性、相关性和类型。 软件服务历史的使用、使用条件和结果应由系统过程（包括系统安全评估过程）进行定义和评估，并提交给适当的认证机构。 下面介绍了确定服务历史的适用性和所需的服务历史长度的指南。Use of service history data for certification credit is predicated upon sufficiency, relevance, and types of problems occurring during the service history period. The use, conditions of use, and results of software service history should be defined, assessed by the system processes, including the system safety assessment process, and submitted to the appropriate certification authority. Guidance for determining applicability of service history and the length of service history needed is presented below.

12.3.4.1 服务历史的相关性 Relevance of Service History

以下内容适用于建立服务历史的相关性：The following applies for establishing the relevance of service history:

a. 服务历史类型：应定义要使用的服务历史并获得认证机构的同意。 应使用与系统操作相关的措施来提供服务历史数据。 例如，飞行小时是飞行期间连续使用的软件（例如飞行控制软件）的适当度量，而需求数量是按需执行的软件（例如起落架软件）的适当度量。Type of service history: Service history to be used should be defined and agreement obtained from the certification authority. Service history data should be provided using a measure relevant to the operations of the system. For example, flight hours is an appropriate measure for software that is used continuously during flight, such as flight control software, and the number of demands is an appropriate measure for software that is executed on demand, such as landing gear software.

b. 已知配置：申请人应证明用于遵守系统安全目标的软件和相关证据在整个产品服务历史中一直处于配置管理之下。Known configuration: The applicant should show that the software and associated evidence used to comply with system safety objectives have been under configuration management throughout the product service history.

c. 运行时间收集过程：申请人应证明飞行过程中连续使用的软件的飞行时间或按需执行的软件的需求数量的收集和计算手段足够准确和完整。 飞行时间或需求数量应考虑对预期应用重要的任何因素的变化，包括但不限于：Operating time collection process: The applicant should show that the means of collecting and calculating flight hours for software that is used continuously during flight or number of demands for software that is executed on demand is sufficiently accurate and complete. Flight hours or number of demands should account for changes in any factors that are important to the intended application including but not limited to:

1. 软件及系统配置。Software and system configuration.

2. 操作模式或状态。Operational mode or state.

3. 运行环境。Operating environment.

d. 软件更改：应识别产品服务历史期间的配置更改。 应进行分析以确定对软件所做的更改是否会改变更改之前的时期的服务历史数据的适用性。Changes to the software: Configuration changes during the product service history should be identified. An analysis should be conducted to determine whether the changes made to the software alter the applicability of the service history data for the period preceding the changes.

e. 使用和环境：应分析预期的软件使用情况，以显示产品服务历史的相关性。Usage and Environment: The intended software usage should be analyzed to show the relevance of the product service history.

1. 应确保所使用的软件功能在所有操作模式下都能发挥作用。It should be assured that software capabilities to be used are exercised in all operational modes.

2. 还应进行分析以确保执行输入数据的相关排列。Analysis should also be performed to assure that relevant permutations of input data are executed.

3. 应评估用于收集服务历史数据的操作环境，以显示与拟议应用中预期用途的相关性。 如果现有和拟议应用程序的操作环境不同，则应进行额外验证以确认符合目标环境中的系统安全目标。The operating environment used to collect the service history data should be assessed to show relevance to the intended use in the proposed application. If the operating environments of the existing and proposed applications differ, additional verification should confirm compliance with the system safety objectives in the target environment.

4. 如果寻求与硬件环境的兼容性，则应解决服务历史环境与预期环境之间的关系。 还应评估服务历史期间任何硬件修改的影响。If credit is being sought for compatibility with the hardware environment, then the relationship between the service history environment and the intended environment should be addressed. The impact of any hardware modifications during the service history period should also be assessed.

f. 停用的代码：应进行分析以表明在服务历史期间停用的任何代码在新环境中都不会激活。 如果发现之前停用的代码在新环境中被激活，则应进行额外验证。Deactivated code: Analysis should be performed to show that any code that was deactivated during the period of service history is not activated in the new environment. If it is found that previously deactivated code is activated in the new environment, additional verification should be conducted.

12.3.4.2 累积服务历史记录的充分性 Sufficiency of Accumulated Service History

所需的服务历史记录量由以下因素确定：The required amount of service history is determined by:

a. 软件的系统安全目标和软件级别。The system safety objectives of the software and the software level.

b. 服务历史环境和系统运行环境是否存在差异。Any differences in service history environment and system operational environment.

c. 第 4 节到第 9 节的目标通过服务历史记录来实现。The objectives from sections 4 to 9 being addressed by service history.

d. 除了服役历史之外，还有解决这些目标的证据。Evidence, in addition to service history, addressing those objectives.

12.3.4.3 服务历史中发现问题的收集、报告和分析 Collection, Reporting, and Analysis of Problems Found During Service History

a. 问题报告流程：申请人应证明产品服务历史期间的问题报告可以保证代表性数据可用，并且服务历史期间的问题已报告和记录并且可检索。Problem reporting process: The applicant should show that problem reporting during the product service history period provides assurance that representative data is available and that problems during the service history period were reported and recorded, and are retrievable.

1. ：要收集的具体数据应与认证机构达成一致，并且除了第 11.17 节中的项目外，还应包括每个记录问题的以下内容：The specific data to be collected should be agreed on with the certification authority and should include the following for each recorded problem, in addition to the items in section 11.17:

i. 问题发生时有效的硬件/软件配置。The hardware/software configuration in effect when the problem occurred.

ii. 发生问题的操作环境。The operating environment within which the problem occurred.

iii. 发生问题的操作模式或状态。The operating mode or state within which the problem occurred.

iv. 问题评估所需的任何特定于应用程序的信息。Any application-specific information needed for problem assessment.

v. 根据严重性、安全重要性以及问题是否是自服务历史数据收集开始以来软件配置更改的结果对问题进行分类。Classification of the problem with respect to severity, safety significance, and whether the problem was the result of a change in the software configuration since the start of service history data collection.

vi. 评估问题是否为：Assessment of whether the problem was:

• 可重复。Reproducible.

• 可恢复。Recoverable.

• 与之前报告的其他问题相关，包括但不限于常见原因。Related to other previously reported problems, including, but not limited to, a common cause.

2. 应评估问题报告的时间趋势并解释任何增加的趋势。The chronological trend of Problem Reports should be evaluated and any increasing trend explained.

3. 还应解决软件错误历史记录的完整性问题。 这包括：The completeness of the software's error history should also be addressed. This includes:

i. 检测故障并维护故障日志的能力。The ability to detect faults and maintain a fault log.

ii. 操作员报告问题的方式。The means for operators to report problems.

iii. 问题报告记录的完整性。The completeness of the problem reporting records.

iv. 申请人确定任何开放问题报告对系统安全影响的方法，并确定服务历史期间与安全无关的问题在预期环境中是否与安全相关。 在服务体验环境中与安全无关但在预期环境中与安全相关的问题可能表明需要进行额外的验证。The means for the applicant to determine the system safety impact of any open Problem Reports, and to determine whether problems that were not safety-related during the service history will be safety-related in the intended environment. Problems that were not safety-related in the service experience environment, but which will be safety-related in the intended environment, might indicate the need for additional verification.

v. 申请人确定特定问题出现次数的方法。The means for the applicant to determine the number of occurrences of a specific problem.

b. 与流程相关的问题：那些表明流程不完善的问题（例如设计或代码错误）应与那些其原因超出本文档范围的问题（例如硬件或系统需求错误）分开指出。Process-related problems: Those problems that are indicative of an inadequate process, such as design or code errors, should be indicated separately from those whose cause are outside the scope of this document, such as hardware or system requirements errors.

c. 安全相关问题：那些表明流程不完善的问题（例如设计或代码错误）应与那些其原因超出本文档范围的问题（例如硬件或系统需求错误）分开指出。Safety-related problems: Those problems that are indicative of an inadequate process, such as design or code errors, should be indicated separately from those whose cause are outside the scope of this document, such as hardware or system requirements errors.

12.3.4.4 将包含在软件方面认证计划中的服务历史信息 Service History Information to be Included in the Plan for Software Aspects of Certification

在寻求服务历史可信认证时，应在《软件方面认证计划》中明确以下事项，并与认证机构达成一致：The following items should be specified in the Plan for Software Aspects of Certification and agreed with the certification authority when seeking certification credit for service history:

a. 声明相关服务历史记录的基本原理，解决第 12.3.4.1 节中的项目。Rationale for claiming relevant service history, addressing the items in section 12.3.4.1.

b. 所需的服务历史记录数量及其理由。 这应包括第 12.3.4.2 节中的项目、估计中使用的数据的任何审查规则以及测量参数（如果适用）。 应使用与系统操作相关的措施来提供该数据。Amount of service history needed together with the rationale. This should include the items in section 12.3.4.2, any censoring rules for data used in estimation, and measured parameters, if applicable. This data should be provided using measures relevant to the operations of the system.

c. 计算总相关服务历史期间的依据，包括运行模式、安装和运行中独立运行的副本数量以及"正常运行"和"正常运行时间"的定义等因素。Rationale for calculating the total relevant service history period, including factors such as operational modes, the number of independently operating copies in the installation and in service, and the definition of "normal operation" and "normal operation time."

注：如果错误率大于计划中确定的错误率，则应对这些错误进行分析，并与认证机构一起审查分析结果。 服务历史期限的长度可能需要延长，或者服务历史可能不适用于替代的合规方式。

Note: If the error rate is greater than that identified in the plan, these errors should be analyzed and the analyses reviewed with the certification authority. The length of the service history period may need to be extended or service history may be inapplicable as an alternative means of compliance.

d. 被视为错误的定义以及该定义的基本原理。 这应该解决第 12.3.4.3a 节中的项目。Definition of what was counted as an error and rationale for that definition. This should address the items in section 12.3.4.3a.

e. 建议可接受的错误率以及与系统安全和建议错误率相关的产品服务历史周期的基本原理。 这应解决第 12.3.4.3b 和 12.3.4.3c 节中的项目。Proposed acceptable error rates and rationale for the product service history period in relation to the system safety and proposed error rates. This should address the items in sections 12.3.4.3b and 12.3.4.3c.

f. 根据第 12.3.4.3 节或其他原因定义导致服务历史无效的问题的标准。Definition of criteria for problems that would invalidate service history under section 12.3.4.3 or for other reasons.

g. 将纠正错误的标准； 如何纠正和验证它们； 以及不采取任何行动的任何缺陷的理由。Criteria for errors that will be corrected; how they will be corrected and verified; and rationale for any defects for which no action will be taken.

h. 第 4 节至第 9 节中的目标将通过使用服务历史记录来实现。 Objectives in sections 4 to 9 to be addressed through the use of service history.