RTCA DO-178C 机载系统和设备认证中的软件注意事项-软件开发的系统相关性（二）

2.0 软件开发的系统相关性 SYSTEM ASPECTS RELATING TO SOFTWARE DEVELOPMENT

本节讨论了解软件生命周期过程所需的系统生命周期过程的那些方面。 系统生命周期流程可以在其他行业文档中找到（例如，SAE ARP4754A）。

This section discusses those aspects of the system life cycle processes necessary to understand the software life cycle processes. System life cycle processes can be found in other industry documents (for example, SAE ARP4754A).

本节讨论的是：Discussed in this section are:

软件的系统需求分配（参见 2.1）。System requirements allocation to software (see 2.1).

•系统和软件生命周期过程之间以及软件和硬件生命周期过程之间的信息流（见2.2）。

The information flow between the system and software life cycle processes and between the software and hardware life cycle processes (see 2.2).

•系统安全评估过程、故障条件、软件级别定义和软件级别确定（参见2.3）。

 The system safety assessment process, failure conditions, software level definitions, and software level determination (see 2.3).

•架构考虑（参见2.4）。Architectural considerations (see 2.4).

•系统生命周期过程中的软件注意事项（参见 2.5）。Software considerations in system life cycle processes (see 2.5).

•软件生命周期过程中的系统注意事项（参见2.6）。System considerations in software life cycle processes (see 2.6).

本文件中的术语“系统”仅指机载系统和设备，而不是可能包括操作员、操作程序等的更广泛的系统定义。

The term “system” in the context of this document refers to the airborne system and equipment only, not to the wider definition of a system that might include operators, operational procedures, etc.

2.1 软件的系统分配需求 System Requirements Allocation to Software

作为系统生命周期过程的一部分，系统需求是根据系统操作需求和其他考虑因素（例如安全相关、安保和性能需求）制定的。 安全相关要求源自系统安全评估过程，可能包括功能、完整性和可靠性需求以及设计约束。

As part of the system life cycle processes, system requirements are developed from the system operational requirements and other considerations such as safety-related, security, and performance requirements. The safety-related requirements result from the system safety assessment process, and may include functional, integrity, and reliability requirements, as well as design constraints.

系统安全评估过程确定系统的故障情况并对其进行分类。 在安全评估过程中，定义了与安全相关的需求，通过指定对这些故障条件的所需免疫力和系统响应来确保系统的完整性。 这些需求是针对硬件和软件确定的，以排除或限制故障的影响，并且可以提供故障检测、容错、故障消除和故障避免。

The system safety assessment process determines and categorizes the failure conditions of the system. Within the safety assessment process, safety-related requirements are defined to ensure the integrity of the system by specifying the desired immunity from, and system responses to, these failure conditions. These requirements are identified for hardware and software to preclude or limit the effects of faults, and may provide fault detection, fault tolerance, fault removal, and fault avoidance.

系统进程负责根据系统架构确定系统需求的细化和分配到硬件和/或软件。

The system processes are responsible for the refinement and allocation of system requirements to hardware and/or software as determined by the system architecture.

分配给软件的系统需求（包括安全相关需求）被开发并细化为由软件验证过程活动验证的软件需求。 这些需求和相关验证应确定软件在任何可预见的操作条件下都能执行其预期功能。分配给软件的系统需求可能包括：

System requirements allocated to software, including safety-related requirements, are developed and refined into software requirements that are verified by the software verification process activities. These requirements and the associated verification should establish that the software performs its intended functions under any foreseeable operating condition. System requirements allocated to software may include:

a. 功能和操作需求。Functional and operational requirements.

b. 接口需求。Interface requirements.

c. 性能需求。 Performance requirements.

d. 与安全相关的需求，包括安全策略、设计约束和设计方法，例如分区、相异性、冗余或安全监控。 在系统是另一个系统的组件的情况下，该另一个系统的需求和故障条件也可以构成分配给软件的系统需求的一部分。Safety-related requirements, including safety strategies, design constraints and design methods, such as, partitioning, dissimilarity, redundancy, or safety monitoring. In cases where the system is a component of another system, the requirements and failure conditions for that other system may also form part of the system requirements allocated to software.

e. 安全需求。Security requirements.

f. 维护需求。Maintenance requirements.

g. 认证需求，包括任何适用的认证机构法规、问题文件等。Certification requirements, including any applicable certification authority regulations, issue papers, etc.

h. 辅助系统生命周期过程所需的附加需求。Additional requirements needed to aid the system life cycle processes.

图 2-1 系统和软件生命周期过程之间的信息流

Figure 2-1 Information Flow Between System and Software Life Cycle Processes

2.2 系统和软件生命周期过程之间的信息流Information Flow Between System and Software Life Cycle Processes

图 2-1 是系统生命周期过程和软件生命周期过程之间的信息流的概述。 该信息流包括系统安全方面。 由于系统安全评估过程和系统设计过程的相互依赖性，这些部分中描述的信息流是迭代的。

Figure 2-1 is an overview of the information flow between system life cycle processes and the software life cycle processes. This information flow includes the system safety aspects. Due to interdependence of the system safety assessment process and the system design process, the flow of information described in these sections is iterative.

2.2.1 从系统进程到软件进程的信息流 Information Flow from System Processes to Software Processes

作为需求分配的一部分或在开发生命周期期间，以下数据由系统进程传递到软件生命周期进程：

The following data is passed to the software life cycle processes by the system processes either as part of the requirements allocation or during the development life cycle:

a. 分配给软件的系统需求。 System requirements allocated to software.

b. 系统安全目标。System safety objectives.

c. 软件组件的软件级别以及相关故障条件的描述（如果适用）。 Software level for software

components and a description of associated failure condition(s), if applicable.

d. 系统描述和硬件定义。System description and hardware definition.

e. 设计约束，包括外部接口、分区要求等。Design constraints, including external interfaces, partitioning requirements, etc.

f. 建议作为软件生命周期的一部分执行的任何系统活动的详细信息。 请注意，系统需求验证通常不是软件生命周期过程的一部分。 系统生命周期过程负责确保建议作为软件生命周期一部分执行的任何系统活动。Details of any system activities proposed to be performed as part of the software life cycle. Note that system requirement validation is not usually part of the software life cycle processes. The system life cycle processes are responsible for assuring any system activities proposed to be performed as part of the software life cycle.

g. 软件进程向已在其上执行任何活动的系统进程提供的任何数据的可接受性或其他证据。 此类活动的示例是系统流程的评估：Evidence of the acceptability, or otherwise, of any data provided by the software processes to the system processes on which any activity has been conducted by the system processes. Examples of such activity are the system processes’ evaluations of:

1. 软件流程提供的派生需求，以确定是否对系统安全评估和系统需求有任何影响。Derived requirements provided by the software processes to determine if there is any impact on the system safety assessment and system requirements.

2. 软件过程提出的与澄清或纠正分配给软件的系统需求有关的问题。Issues raised by the software processes with respect to the clarification or correction of system requirements allocated to software.

h. 系统生命周期过程执行的软件验证活动的证据（如果有）。Evidence of software verification activities performed by the system life cycle processes, if any.

系统进程（见 2.2.1.f 和 2.2.1.g）提供的任何证据应被软件进程视为软件验证结果（见 11.14）。

Any evidence provided by the system processes (see 2.2.1.f and 2.2.1.g) should be considered by the software processes to be Software Verification Results (see 11.14).

2.2.2 从软件进程到系统进程的信息流 Information Flow from Software Processes to System Processes

软件生命周期过程分析分配给软件的系统需求，作为软件需求过程的一部分。 如果此类分析发现任何系统需求不充分或不正确，则软件生命周期流程应捕获问题并将其提交给系统流程进行解决。 此外，随着软件设计和实现的发展，细节的添加和修改可能会影响系统安全评估和系统需求。

The software life cycle processes analyze the system requirements allocated to software as part of the software requirements process. If such an analysis identifies any system requirements as inadequate or incorrect, the software life cycle processes should capture the issues and refer them to the system processes for resolution. Furthermore, as the software design and implementation evolves, details are added and modifications made that may affect system safety assessment and system requirements.

为了帮助评估不断发展的设计和设计变更，软件生命周期过程应该向系统过程（包括系统安全评估过程）提供数据。 这些数据将有助于分析和评估，以确定对系统安全评估和系统需求的影响。 由系统和软件过程联合执行这样的分析和评估可能是有利的。 此类数据包括：

To aid the evaluation of the evolving design and changes to the design, the software life cycle processes should make data available to the system processes including the system safety assessment process. This data will facilitate analyses and evaluations to establish the effect on the system safety assessment and system requirements. It may be advantageous for such analyses and evaluations to be performed jointly by the systems and software processes. Such data includes:

a. 在软件生命周期过程中创建的派生需求的详细信息。Details of derived requirements created during the software life cycle processes.

b. 软件架构的描述，包括软件分区。A description of the software architecture, including software partitioning.

c. 软件生命周期过程执行的系统活动的证据（如果有）。Evidence of system activities performed by the software life cycle processes, if any.

d. 问题或变更文档，包括分配给软件的系统需求中确定的问题以及确定的硬件和软件之间的不兼容性。Problem or change documentation, including problems identified in the system requirements allocated to software and identified incompatibilities between the hardware and the software.

e. 任何使用限制。Any limitations of use.

f. 配置标识和任何配置状态约束。Configuration identification and any configuration status constraints.

g. 性能、计时和准确性特征。Performance, timing, and accuracy characteristics.

h. 数据有助于将软件集成到系统中。Data to facilitate integration of the software into the system.

i. 建议在系统验证期间执行的软件验证活动的详细信息（如果有）。Details of software verification activities proposed to be performed during system verification, if any.

2.2.3 软硬件进程之间的信息流Information Flow between Software Processes and Hardware Processes

作为系统需求分配的一部分或在开发生命周期期间，数据在软件生命周期过程和硬件生命周期过程之间传递。 此类数据包括：

Data is passed between the software life cycle process and the hardware life cycle process either as part of the system requirements allocation or during the development life cycles. Such data includes:

a. 硬件/软件集成所需的所有需求，包括派生需求，例如协议定义、时序约束以及硬件和软件之间接口的寻址方案。All requirements, including derived requirements, needed for hardware/software integration, such as definition of protocols, timing constraints, and addressing schemes for the interface between hardware and software.

b. 硬件和软件验证活动需要协调的实例。Instances where hardware and software verification activities require coordination.

c. 已确定硬件和软件之间的不兼容性。Identified incompatibilities between the hardware and the software.

2.3 系统安全评估流程和软件级别System Safety Assessment Process and Software Level

本节简要介绍如何确定软件组件的软件级别以及架构考虑因素如何影响软件级别的分配。 本文件的目的不是规定如何执行这些活动； 这必须作为系统生命周期过程的一部分来建立和执行。

This section provides a brief introduction to how the software level for software components is determined and how architectural considerations may influence the allocation of a software level. It is not the intent of this document to prescribe how these activities are performed; this has to be established and performed as part of the system life cycle processes.

软件组件的软件级别基于软件对潜在故障条件的贡献，系统安全评估过程通过确定软件组件中的错误与系统故障条件的关系以及该故障的严重性来确定软件对潜在故障条件的贡献 状况）。 软件级别建立了证明遵守本文档所需的严格性。

The software level of a software component is based upon the contribution of software to potential failure conditions as determined by the system safety assessment process by establishing how an error in a software component relates to the system failure condition(s) and the severity of that failure condition(s). The software level establishes the rigor necessary to demonstrate compliance with this document.

将软件开发到软件级别并不意味着分配该软件的故障率。 因此，基于软件级别的软件可靠性率不能像硬件故障率一样被系统安全评估过程使用。

Development of software to a software level does not imply the assignment of a failure rate for that software. Thus, software reliability rates based on software levels cannot be used by the system safety assessment process in the same way as hardware failure rates.

只有分区的软件组件（参见 2.4.1）可以通过系统安全评估过程分配单独的软件级别。 如果无法证明软件组件之间的划分，则在分配软件级别时应将软件组件视为单个组件（即，为所有组件分配与软件可能导致的最严重故障条件相关的软件级别）。

Only partitioned software components (see 2.4.1) can be assigned individual software levels by the system safety assessment process. If partitioning between software components cannot be demonstrated, the software components should be viewed as a single component when assigning software levels (that is, all components are assigned the software level associated with the most severe failure condition to which the software can contribute).

申请人应根据认证机构的指导建立要使用的系统安全评估流程。 然后应根据此流程分配系统每个软件组件的软件级别，并与认证机构达成一致。

The applicant should establish the system safety assessment process to be used based on certification authority guidance. The software level for each software component of the system should then be assigned based on this process and agreed with the certification authorities.

2.3.1 软件错误和故障情况之间的关系 Relationship between Software Errors and Failure Conditions

图 2-2 显示了软件错误导致飞机级故障情况的一系列事件。 软件错误可能是潜在的，因此不会立即产生故障。 该模型有意采用简单的线性表示。 在实际操作中，从软件错误导致故障情况的事件序列可能很复杂，并且不容易用事件序列来表示，如图2-2所示

Figure 2-2 shows a sequence of events in which a software error leads to the failure condition at aircraft level. A software error may be latent and, thus, not immediately produce a failure. This model is intentionally a simple, linear representation. In actual operation, the sequence of events that leads from a software error to a failure condition may be complex and not easily represented by a sequence of events, as shown in Figure 2-2

重要的是要认识到，软件包含错误的可能性不能以与随机硬件故障相同的方式进行量化。

It is important to realize that the likelihood that the software contains an error cannot be quantified in the same way as for random hardware failures.

.

图 2-2 导致故障情况的软件错误的事件序列

Figure 2-2 Sequence of Events for Software Error Leading to a Failure Condition

在识别故障条件类别并将软件级别分配给每个软件组件时，架构考虑因素（参见 2.4）和/或系统外部因素也可以被视为系统安全评估过程的一部分。

Architectural considerations (see 2.4) and/or system external factors may also be considered as part of the system safety assessment process when identifying the failure condition categories and assigning the software level to each software component.

2.3.2 失效条件分类 Failure Condition Categorization

对于失效条件类别的完整定义，申请人应参考相关认证机构发布的适用法规和指导材料。 表 2-1 中列出的故障条件类别对于基于系统安全评估过程已建立的咨询材料的大型运输机有效，并包括在内以协助使用本文件。

For a complete definition of failure condition categories, the applicant should refer to applicable regulations and guidance material issued by the relevant certification authority. The failure condition categories listed in Table 2-1 are valid for large transport aircraft based on established advisory material for the system safety assessment process, and are included to assist in the use of this document.

表 2-1 故障情况类别说明

Table 2-1 Failure Condition Category Descriptions

类别 Category	描述Description
灾难性的Catastrophic	故障情况，会导致多人死亡，通常会导致飞机损失。 Failure Conditions, which would result in multiple fatalities, usually with the loss of the airplane.
危险的Hazardous	故障条件，这会降低飞机的能力或机组人员应对不利运行条件的能力，从而导致： Failure Conditions, which would reduce the capability of the airplane or the ability of the flight crew to cope with adverse operating conditions to the extent that there would be: •安全裕度或功能能力大幅下降；A large reduction in safety margins or functional capabilities; •身体不适或工作量过大，导致机组人员无法准确或完整地执行任务，或Physical distress or excessive workload such that the flight crew cannot be relied upon to perform their tasks accurately or completely, or •除机组人员外，少数乘客受到严重或致命伤害。Serious or fatal injury to a relatively small number of the occupants other than the flight crew.
主要的 Major	会降低飞机能力或机组应对不利运行条件的能力的故障情况，例如安全裕度或功能能力显着降低、机组工作量显着增加或 影响机组效率、机组人员不适、乘客或机组人员身体不适（可能包括受伤）的情况。 Failure Conditions which would reduce the capability of the airplane or the ability of the crew to cope with adverse operating conditions to the extent that there would be, for example, a significant reduction in safety margins or functional capabilities, a significant increase in crew workload or in conditions impairing crew efficiency, or discomfort to the flight crew, or physical distress to passengers or cabin crew, possibly including injuries.
次要的 Minor	不会显着降低飞机安全性且涉及机组人员完全在其能力范围内的行动的故障情况。 轻微故障情况可能包括，例如，安全裕度或功能能力略有下降，机组人员工作量略有增加，例如例行飞行计划的改变，或者乘客或机组人员的身体不适。 Failure Conditions which would not significantly reduce airplane safety, and which involve crew actions that are well within their capabilities. Minor Failure Conditions may include, for example, a slight reduction in safety margins or functional capabilities, a slight increase in crew workload, such as routine flight plan changes, or some physical discomfort to passengers or cabin crew.
无安全影响 No Safety Effect	对安全没有影响的故障情况； 例如，不会影响飞机运行能力或增加机组工作量的故障情况。 Failure Conditions that would have no effect on safety; for example, Failure Conditions that would not affect the operational capability of the airplane or increase crew workload.

2.3.3 软件级别定义 Software Level Definition

本文档识别了五个软件级别，A 级到 E 级。对于第 2.3.2 节中列出的示例故障条件类别，这些软件级别和故障条件之间的关系是：

This document recognizes five software levels, Level A to Level E. For the example failure condition categories listed in section 2.3.2, the relationships between these software levels and failure conditions are:

a. A 级：如系统安全评估过程所示，软件的异常行为或将导致系统功能故障，从而导致飞机发生灾难性故障。Level A: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a catastrophic failure condition for the aircraft.

b. B 级：如系统安全评估过程所示，软件的异常行为将导致或导致系统功能故障，从而导致飞机出现危险故障情况。Level B: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a hazardous failure condition for the aircraft.

c. C 级：如系统安全评估过程所示，软件的异常行为将导致或导致系统功能故障，从而导致飞机发生重大故障。Level C: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a major failure condition for the aircraft.

d. D 级：如系统安全评估过程所示，软件的异常行为将导致或导致系统功能故障，从而导致飞机出现轻微故障。Level D: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a minor failure condition for the aircraft.

e. E级：如系统安全评估过程所示，软件的异常行为会导致或导致系统功能故障，但不会影响飞机的运行能力或飞行员的工作量。 如果软件组件被确定为 E 级并且得到认证机构的确认，则本文档中包含的进一步指导不适用。Level E: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function with no effect on aircraft operational capability or pilot workload. If a software component is determined to be Level E and this is confirmed by the certification authority, no further guidance contained in this document applies.

申请人应始终考虑适当的认证指南和系统开发注意事项，以对故障情况严重性和软件级别进行分类。

The applicant should always consider the appropriate certification guidance and system development considerations for categorizing the failure condition severity and the software level.

2.3.4 软件级别确定 Software Level Determination

系统安全评估过程根据可能由软件的异常行为导致的故障状况来确定适合特定系统的软件组件的软件级别。 应分析功能丧失和故障的影响。 在识别故障条件类别和确定软件级别时，可以考虑外部因素，例如不利的环境条件以及架构策略（如第 2.4 节中所述）。

The system safety assessment process determines the software level(s) appropriate to the software components of a particular system based upon the failure condition which may result from anomalous behavior of the software. The impact of, both loss of function and malfunction should be analyzed. External factors such as adverse environmental conditions as well as architectural strategies (as described in section 2.4) may be considered when identifying the failure condition categories and determining the software level.

注 1：申请人可能需要考虑在未来开发期间添加的计划功能，以及分配给软件的系统需求的潜在变化，这些变化可能导致更严重的故障条件类别和更高的软件级别。 可能需要将软件开发到高于原始应用程序的系统安全评估过程所确定的级别，因为后来开发用于证实更高软件级别应用程序的软件生命周期数据可能很困难。

Note 1: The applicant may want to consider planned functionality to be added during future developments, as well as potential changes in system requirements allocated to software that may result in a more severe failure condition category and higher software level. It may be desirable to develop the software to a level higher than that determined by the system safety assessment process of the original application, since later development of software life cycle data for substantiating a higher software level application may be difficult.

注2：对于运行规则强制要求但不影响航空器适航性的机载系统和设备，例如飞行数据记录器，其软件级别需要与预期功能相匹配。 在某些情况下，软件级别可能会在设备最低性能标准中指定。

Note 2: For airborne systems and equipment mandated by operating regulations, but which do not affect the airworthiness of the aircraft, for example, a flight data recorder, the software level needs to be commensurate with the intended function. In some cases, the software level may be specified in equipment minimum performance standards.

如果软件组件的异常行为导致不止一种故障情况，则应为该软件组件分配与该软件可能导致的最严重故障情况（包括组合故障情况）相关的软件级别。

If the anomalous behavior of a software component contributes to more than one failure condition, then the software component should be assigned the software level associated with the most severe failure condition to which the software can contribute, including combined failure conditions.

2.4 架构考虑 Architectural Considerations

本节提供有关几种架构策略的信息，这些策略可以限制故障的影响，或检测故障并提供可接受的系统响应来遏制故障。 这些架构技术通常是在系统设计期间确定的，不应被解释为首选或必需的解决方案。

This section provides information on several architectural strategies that may limit the impact of failures, or detect failures and provide acceptable system responses to contain them. These architectural techniques are typically identified during system design and should not be interpreted as the preferred or required solutions.

串行实现是一种系统功能使用多个软件组件的实现，因此任何组件的异常行为都可能产生故障情况。 在该实现中，软件组件将具有与系统功能的最严重故障条件类别相关联的软件级别。

A serial implementation is one in which multiple software components are used for a system function such that anomalous behavior of any of the components could produce the failure condition. In this implementation, the software components will have the software level associated with the most severe failure condition category of the system function.

在需要两个或更多个分区软件组件的异常行为以引起故障状况的实现中，系统安全评估过程在为这些软件组件分配软件级别时可以考虑这一点。

In implementations where anomalous behavior of two or more partitioned software components is needed in order to cause the failure condition, this may be taken into consideration by the system safety assessment process when assigning the software level for these software components.

系统安全评估过程需要确定软件组件之间在功能（即高级需求）和设计（例如通用设计元素、语言和工具）方面存在足够的独立性。

The system safety assessment process needs to establish that sufficient independence exists between software components with respect to both function (that is, high-level requirements) and design (for example, common design elements, languages, and tools).

如果无法证明软件组件之间的分区和独立性，则在分配软件级别时，应将软件组件视为单个软件组件（即，为所有组件分配与软件可能导致的最严重故障条件相关的软件级别） ）。

If partitioning and independence between software components cannot be demonstrated, the software components should be viewed as a single software component when assigning software levels (that is, all components are assigned the software level associated with the most severe failure condition to which the software can contribute).

2.4.1 分区 Partitioning

分区是一种在软件组件之间提供隔离以包含和/或隔离故障并可能减少软件验证过程的工作量的技术。 软件组件之间的划分可以通过为每个组件分配唯一的硬件资源（即，系统中的每个硬件平台上仅执行一个软件组件）来实现。 或者，可以进行分区规定以允许多个软件组件在同一硬件平台上运行。 无论采用哪种方法，分区软件组件都应确保以下几点：

Partitioning is a technique for providing isolation between software components to contain and/or isolate faults and potentially reduce the effort of the software verification process. Partitioning between software components may be achieved by allocating unique hardware resources to each component (that is, only one software component is executed on each hardware platform in a system). Alternatively, partitioning provisions may be made to allow multiple software components to run on the same hardware platform. Regardless of the method, the following should be ensured for partitioned software components:

a. 不应允许分区软件组件污染另一个分区软件组件的代码、输入/输出 (I/O) 或数据存储区域。A partitioned software component should not be allowed to contaminate another partitioned software component’s code, input/output (I/O), or data storage areas.

b. 应允许分区软件组件仅在其计划执行期间消耗共享处理器资源。A partitioned software component should be allowed to consume shared processor resources only during its scheduled period of execution.

c. 分区软件组件特有的硬件故障不应对其他分区软件组件造成不利影响。Failures of hardware unique to a partitioned software component should not cause adverse effects on other partitioned software components.

d. 提供分区的任何软件都应具有与分配给任何分区软件组件的最高级别相同或更高的软件级别。Any software providing partitioning should have the same or higher software level as the highest level assigned to any of the partitioned software components.

e. 任何提供分区的硬件都应通过系统安全评估流程进行评估，以确保其不会对安全产生不利影响。Any hardware providing partitioning should be assessed by the system safety assessment process to ensure that it does not adversely affect safety.

软件生命周期过程应解决分区设计考虑因素。 这些包括分区组件之间允许的交互的程度和范围，以及保护是通过硬件还是通过硬件和软件的组合来实现。

The software life cycle processes should address the partitioning design considerations. These include the extent and scope of interactions permitted between the partitioned components and whether the protection is implemented by hardware or by a combination of hardware and software.

2.4.2 多版本非相似软件 Multiple-Version Dissimilar Software

多版本异种软件是一种系统设计技术，涉及生产两个或多个软件组件，这些组件以可以避免组件之间某些常见错误源的方式提供相同的功能。 多版本异种软件也称为多版本软件、多版本独立软件、异种软件、N版本编程或软件多样性。

Multiple-version dissimilar software is a system design technique that involves producing two or more components of software that provide the same function in a way that may avoid some sources of common errors between the components. Multiple-version dissimilar software is also referred to as multi-version software, multi-version independent software, dissimilar software, N-version programming, or software diversity.

在将差异引入开发之前完成或激活的软件生命周期过程仍然是潜在的错误源。 系统需求可以指定提供执行多版本不同软件的硬件配置。

Software life cycle processes completed or activated before dissimilarity is introduced into a development, remain potential error sources. System requirements may specify a hardware configuration that provides for the execution of multiple-version dissimilar software.

差异程度以及保护程度通常是不可测量的。 如果与不同软件版本相关的安全监控使用大于阈值限制的比较器差异来检测实际错误，则系统功能丧失的可能性将增加。 因此，通常使用不同的软件版本作为在满足第 6 节中所述的软件级别的软件验证过程目标之后提供额外保护的手段。

The degree of dissimilarity, and hence the degree of protection, is not usually measurable. Probability of loss of system function will increase to the extent that the safety monitoring associated with dissimilar software versions detects actual errors using comparator differences greater than threshold limits. Dissimilar software versions are usually used, therefore, as a means of providing additional protection after the software verification process objectives for the software level, as described in section 6, have been satisfied.

如果可以证明系统安全评估过程所确定的所导致的系统功能的潜在损失是可接受的，则可以从用于验证单一版本软件的方法中减少不同的软件验证方法。 多版本不同软件的验证在 12.3.2 节中讨论。

Dissimilar software verification methods may be reduced from those used to verify single version software if it can be shown that the resulting potential loss of system function is acceptable as determined by the system safety assessment process. Verification of multiple-version dissimilar software is discussed in section 12.3.2.

2.4.3 安全监控 Safety Monitoring

安全监控是一种通过直接监控可能导致故障情况的功能来防止特定故障情况的方法。 监控功能可以以硬件、软件或硬件和软件的组合来实现。

Safety monitoring is a means of protecting against specific failure conditions by directly monitoring a function for failures that would result in a failure condition. Monitoring functions may be implemented in hardware, software, or a combination of hardware and software.

通过使用监控技术，被监控软件的软件级别可以被分配与其相关系统功能的损失相关联的软件级别。 为了允许此分配，应确定监视器的三个重要属性：

Through the use of monitoring techniques, the software level of the monitored software may be assigned a software level associated with the loss of its related system function. To allow this assignment, there are three important attributes of the monitor that should be determined:

a. 软件级别：安全监控软件被分配与受监控功能的最严重故障条件类别相关的软件级别。Software level: Safety monitoring software is assigned the software level associated with the most severe failure condition category for the monitored function.

b. 系统故障覆盖率：对监视器的系统故障覆盖率的评估可确保监视器的设计和实现能够在所有必要的条件下检测到其要检测的故障。System fault coverage: Assessment of the system fault coverage of a monitor ensures that the monitor's design and implementation are such that the faults which it is intended to detect will be detected under all necessary conditions.

c. 功能和监视器的独立性：监视器和保护机制不会因导致故障情况的同一故障而变得不起作用。Independence of function and monitor: The monitor and protective mechanism are not rendered inoperative by the same failure that causes the failure condition.

2.5 系统生命周期过程中的软件注意事项 Software Considerations in System Life Cycle Processes

本节概述了系统生命周期过程应酌情考虑的与软件相关的问题（不一定是相互排斥的）：

This section provides an overview of those software-related issues (not necessarily mutually exclusive) that should be considered, as appropriate, by the system life cycle processes:

a. 参数数据项。 Parameter data items.

b. 用户可修改的软件。User-modifiable software.

c. 商用现成 (COTS) 软件。Commercial-Off-The-Shelf (COTS) software.

d. 可选软件。Option-selectable software.

e. 现场可加载软件。Field-loadable software.

f. 系统验证中的软件注意事项。 Software considerations in system verification.

2.5.1 参数数据项 Parameter Data Items

软件由可执行目标码和/或数据组成，并且可以包括一个或多个配置项。 在不修改可执行目标码的情况下影响软件行为并作为单独的配置项进行管理的数据集称为参数数据项。 即，当讨论参数数据项和可执行对象代码时，暗示参数数据项不是可执行对象代码的一部分。

Software consists of Executable Object Code and/or data, and can comprise one or more configuration items. A data set that influences the behavior of the software without modifying the Executable Object Code and is managed as a separate configuration item is called a parameter data item. That is, when discussing parameter data items and Executable Object Code, it is implied that the parameter data items are not part of the Executable Object Code.

参数数据项包括单独元素的结构，其中每个元素可以被分配单个值。 每个元素都有类型、范围或允许值集等属性。

A parameter data item comprises a structure of individual elements where each element can be assigned a single value. Each element has attributes such as type, range, or set of allowed values.

参数数据项的示例包括配置表和数据库，但不包括航空数据，因为它们超出了本文档的范围。 参数数据项可以包含以下数据：

Examples of parameter data items include configuration tables and databases but not aeronautical data as they are beyond the scope of this document. Parameter data items may contain data that can:

a. 影响通过可执行目标码执行的路径。 Influence paths executed through the Executable Object Code.

b. 激活或停用软件组件和功能。Activate or deactivate software components and functions.

c. 使软件计算适应系统配置。Adapt the software computations to the system configuration.

d. 用作计算数据。Be used as computational data.

e. 建立时间和内存分区分配。Establish time and memory partitioning allotments.

f. 为软件组件提供初始值。Provide initial values to the software component.

根据参数数据项在机载系统中的使用方式，应解决以下问题：

Depending on how the parameter data item is to be used in the airborne system, the following should be addressed:

• 用户可修改的软件指南。User-modifiable software guidance.

• 可选软件指导。 在参数数据项激活或停用功能的情况下，还应解决停用代码的指导。Option-selectable software guidance. In cases where the parameter data item activates or deactivates functions, the guidance for deactivated code should be addressed as well.

• 现场可加载软件指导。 特别值得关注的是损坏的参数数据项的检测，以及可执行对象代码和参数数据项之间的不兼容性。 Field-loadable software guidance. Of particular concern is detection of corrupted parameter data items, as well as incompatibility between the Executable Object Code and parameter data items.

参数数据项应该被分配与使用它的软件组件相同的软件级别。

The parameter data item should be assigned the same software level as the software component using it.

有关参数数据项验证的更多信息，请参见 6.6。

For more information regarding verification of parameter data items, see 6.6.

2.5.2 用户可修改的软件 User-Modifiable Software

用户可修改组件是如果系统需求允许用户修改，则用户可以在修改限制内更改而无需认证机构审查的软件部分。 不可修改的组件是用户不希望更改的组件。 用户修改的潜在影响由系统安全评估过程确定，并用于开发软件需求，然后是软件验证过程活动。 用户可修改软件的设计将在 5.2.3 节中进一步讨论。 影响不可修改软件、其保护或可修改软件边界的变更称为软件修改，将在 12.1.1 节中讨论。

A user-modifiable component is that part of the software that may be changed by the user within the modification constraints without certification authority review, if the system requirements provide for user modification. A non-modifiable component is that which is not intended to be changed by the user. The potential effects of user modification are determined by the system safety assessment process and used to develop the software requirements, and then, the software verification process activities. Designing for usermodifiable software is discussed further in section 5.2.3. A change that affects the nonmodifiable software, its protection, or the modifiable software boundaries is a software modification and is discussed in section 12.1.1.

用户可修改软件的指南包括：Guidance for user-modifiable software includes:

a. 用户可修改的软件不应对安全、操作能力、机组人员工作量、任何不可修改的软件组件或使用的任何软件保护机制产生不利影响。 除非可以确定这一点，否则该软件可能不会被归类为用户可修改的。 还应考虑基于用户可修改软件显示信息的安全影响。The user-modifiable software should not adversely affect safety, operational capabilities, flight crew workload, any non-modifiable software components, or any software protection mechanism used. Unless this can be established, the software may not be classified as user-modifiable. The safety impact of displaying information based on user-modifiable software should also be considered.

b. 当系统需求规定允许用户修改时，用户可以在修改限制内修改软件，无需认证机构审查。When the system requirements provide for user modification, then users may modify software within the modification constraints without certification authority review.

c. 系统需求应指定防止用户修改影响系统安全的机制，无论这些机制是否正确实施。 为用户修改提供保护的软件应与其保护可修改组件免受错误影响的功能处于同一软件级别。The system requirements should specify the mechanisms that prevent the user modification from affecting system safety whether or not they are correctly implemented. The software that provides the protection for user modification should be at the same software level as the function it is protecting from errors in the modifiable component.

d. 如果系统需求不包括用户修改的规定，则用户不应修改软件，除非证明修改符合本文档。 If the system requirements do not include provision for user modification, the software should not be modified by the user unless compliance with this document is demonstrated for the modification.

e. 用户修改时，应对用户可修改的软件的各个方面负责，例如软件配置管理、软件质量保证、软件验证等。At the time of the user modification, the user should take responsibility for all aspects of the user-modifiable software, for example, software configuration management, software quality assurance, and software verification.

f. 申请人应提供必要的信息，以使用户能够以不损害飞机安全的方式管理软件。The applicant should provide the necessary information to enable the user to manage the software in such a way that the safety of the aircraft is not compromised.

2.5.3 商用现成软件 Commercial-Off-The-Shelf Software

机载系统或设备中包含的 COTS 软件应满足本文件的目标。

COTS software included in airborne systems or equipment should satisfy the objectives of this document.

如果 COTS 软件的软件生命周期数据存在缺陷，则应补充数据以满足本文档的目标。 第 12.1.4 节“升级开发基线”和第 12.3.4 节“产品服务历史记录”中的指南在这种情况下可能相关。

If deficiencies exist in the software life cycle data of COTS software, the data should be augmented to satisfy the objectives of this document. The guidance in section 12.1.4, Upgrading a Development Baseline, and section 12.3.4, Product Service History, may be relevant in this instance.

2.5.4 可选软件 Option-Selectable Software

一些机载系统和设备可能包括可选功能，这些功能可以通过软件编程选项而不是通过硬件连接器引脚来选择。 可选软件功能用于选择目标计算机内的特定配置。 有关停用代码的指导，请参阅 4.2.h、5.2.4 和 6.4.4.3.d.2。

Some airborne systems and equipment may include optional functions that may be selected by software-programmed options rather than by hardware connector pins. The option-selectable software functions are used to select a particular configuration within the target computer. See 4.2.h, 5.2.4, and 6.4.4.3.d.2 for guidance on deactivated code.

当包含软件编程选项时，应提供一种方法来确保不会在安装环境中对目标计算机做出涉及未经批准的配置的无意选择。

When software programmed options are included, a means should be provided to ensure that inadvertent selections involving non-approved configurations for the target computer within the installation environment cannot be made.

2.5.5 现场可加载软件 Field-Loadable Software

现场可加载机载软件是指无需从安装中移除系统或设备即可加载的软件。 与软件加载功能相关的安全相关要求是系统需求的一部分。 如果无意中启用软件加载功能可能导致系统故障情况，则在系统需求中指定软件加载功能的安全相关要求。

Field-loadable airborne software refers to software that can be loaded without removing the system or equipment from its installation. The safety-related requirements associated with the software loading function are part of the system requirements. If the inadvertent enabling of the software loading function could induce a system failure condition, then a safety-related requirement for the software loading function is specified in the system requirements.

与现场可加载软件相关的系统安全考虑因素包括：

System safety considerations relating to field-loadable software include:

• 检测损坏或部分加载的软件。Detection of corrupted or partially loaded software.

• 确定加载不适当软件的影响。Determination of the effects of loading the inappropriate software.

• 硬件/软件兼容性。Hardware/software compatibility.

• 软件/软件兼容性。Software/software compatibility.

• 飞机/软件兼容性。Aircraft/software compatibility.

• 无意中启用了现场加载功能。Inadvertent enabling of the field-loading function.

• 软件配置标识显示丢失或损坏。Loss or corruption of the software configuration identification display.

现场可加载软件指南包括：Guidance for field-loadable software includes:

a. 除非系统安全评估过程另有证明，否则应为部分或损坏的软件负载的检测机制分配与使用该软件负载的功能相关的最严重故障条件或软件级别相同的故障条件或软件级别。Unless otherwise justified by the system safety assessment process, the detection mechanism for partial or corrupted software loads should be assigned the same failure condition or software level as the most severe failure condition or software level associated with the function that uses the software load.

b. 如果系统在检测到损坏或不适当的软件负载后恢复到默认模式或安全状态，则系统的每个分区组件都应该具有指定的恢复到此模式并在此模式下运行的安全相关要求。 可能还需要检查接口系统是否能够在默认模式下正常运行。If a system recovers to a default mode or safe state upon detection of a corrupted or inappropriate software load, then each partitioned component of the system should have safety-related requirements specified for recovery to and operation in this mode. Interfacing systems may also need to be reviewed for proper operation with the default mode.

c. 软件加载功能，包括支持系统和程序，应包括检测不正确的软件和/或硬件和/或飞机组合的手段，并应提供适合功能故障情况的保护。 如果软件由多个配置项组成，应保证它们的兼容性。The software loading function, including support systems and procedures, should include a means to detect incorrect software and/or hardware and/or aircraft combinations and should provide protection appropriate to the failure condition of the function. If the software consists of multiple configuration items, their compatibility should be ensured.

d. 如果软件是机载显示机制的一部分，而机载显示机制是确保飞机符合认证配置的手段，那么该软件应该开发到要加载的软件的最高软件级别，或者系统安全评估过程应该 证明软件配置标识的端到端检查的完整性。 If software is part of an airborne display mechanism that is the means for ensuring that the aircraft conforms to a certified configuration, then that software should either be developed to the highest software level of the software to be loaded, or the system safety assessment process should justify the integrity of an end-to-end check of the software configuration identification.

2.5.6 系统验证中的软件注意事项 Software Considerations in System Verification

系统验证指南超出了本文档的范围。 然而，软件生命周期过程有助于系统验证过程并与之交互，并且可能能够满足某些系统验证过程目标。 需要提供与系统功能相关的软件设计细节以帮助系统验证。

Guidance for system verification is beyond the scope of this document. However, the software life cycle processes aid and interact with the system verification process and may be able to satisfy some system verification process objectives. Software design details that relate to the system functionality need to be made available to aid system verification.

2.6 软件生命周期过程中的系统注意事项 System Considerations in Software Life Cycle Processes

可以从系统生命周期过程中获得满足或部分满足本文档中定义的软件目标的信用。 在这种情况下，应证明正在寻求信用的系统活动满足本文件的适用目标，并提供计划活动完成的证据及其作为软件生命周期数据一部分的输出。

Credit may be taken from system life cycle processes for the satisfaction, or partial satisfaction, of the software objectives as defined in this document. In such cases, the system activities for which credit is being sought should be shown to meet the applicable objectives of this document with evidence of the completion of planned activities and their outputs identified as part of the software life cycle data.