DO-248C:Do-178C和Do-278A的支持信息-常见问题解答 (FAQ) (2)

3.0 常见问题解答 (FAQ) FREQUENTLY ASKED QUESTIONS (FAQ)

本节汇总了 DO-178C 和 DO-278A 常见问题解答。常见问题解答的目的是对业界经常提出的有关 DO-178C 和/或 DO-278A 材料的问题提供简短而简洁的答复。这些问题经常向认证机构或提供 DO-178C 和/或 DO-278A 解释的其他机构提出。常见问题解答不包含指导材料。This section compiles the DO-178C and DO-278A FAQs. The purpose of a FAQ is to provide short and concise responses to questions that are frequently asked by industry concerning the material of DO-178C and/or DO-278A. These questions are frequently posed to certification authorities or others who provide interpretation of DO-178C and/or DO-278A. A FAQ contains no guidance material.

免责声明：对常见问题解答的答复已由联合委员会 SC-205/WG-71 准备并批准。这些常见问题解答并未得到认证机构的认可，仅供参考。Disclaimer: The responses to FAQs have been prepared and approved by Joint Committee SC-205/WG-71. These FAQs have no recognition by the certification authorities and are provided for information purposes only.

3.1 FAQ #1: DO-178B 第 2 节介绍了与软件开发相关的系统方面，并指出在撰写本文时指南正在制定中。这些系统生命周期指南记录在哪里？FAQ #1: Section 2 of DO-178B provides an introduction to the system aspects relating to software development and notes that guidelines were under development at the time of writing. Where are these system life cycle guidelines documented?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.2 FAQ #2: DO-178B 通篇都提到了系统安全评估过程。在哪里可以找到此过程的指南？ Throughout DO-178B reference is made to the system safety assessment process. Where can guidelines for this process be found?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.3 FAQ #3: DO-178B 第 2.3.2 节第 3 段中遇到瞬变的安全监控软件是什么意思？ What is meant by safety monitoring software experiencing transients in DO-178B Section 2.3.2, paragraph 3?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.4 FAQ #4: DO-178C/DO-278A 对商业现成 (COTS) 软件的定义是否包括为可选软件设计的 COTS 软件？Does DO-178C/DO-278A’s definition of commercial off-the-shelf (COTS) software include COTS software designed for option-selectable software?

参考 Reference:

DO-178C：第 2.5.4、4.2.h、5.2.4 和 6.4.4.3.d 节

DO-278A：第 2.6.4、4.2.h、5.2.4 和 6.4.4.3.d 节;DO-178C: Sections 2.5.4, 4.2.h, 5.2.4, and 6.4.4.3.d

DO-278A: Sections 2.6.4, 4.2.h, 5.2.4, and 6.4.4.3.d

关键字 Keywords:商业现成软件；商用现货；可选软件commercial off-the-shelf software; COTS; option-selectable software

回答 Answer:

DO-178C 术语表将 COTS 软件定义为：“供应商通过公共目录列表出售的商业应用程序。 COTS 软件无意进行定制或增强。为特定应用程序开发的合同协商软件不是 COTS 软件。”The DO-178C glossary defines COTS software as: “Commercially available applications sold by vendors through public catalog listings. COTS software is not intended to be customized or enhanced. Contract-negotiated software developed for a specific application is not COTS software.”

DO-278A 术语表定义的 COTS 软件与 DO-178C 略有不同，以补充 CNS/ATM 系统的说明：“正在考虑在 CNS/ATM 系统中使用的软件可能没有或只有部分证据证明符合本文件第 4 节 – 9个目标。”DO-278A glossary defines COTS software slightly different from DO-178C to add clarification for CNS/ATM systems: “Software under consideration for use in a CNS/ATM system that may have no or only partial evidence of compliance to this document sections 4 – 9 objectives.”

只要 COTS 软件未按照供应商提供的方式进行更改，根据上述定义，它仍被视为 COTS 软件。As long as the COTS software is not changed as supplied from the vendor, it is still considered COTS software per the definitions above.

如果 COTS 软件具有可选功能，则可能存在一些停用的代码。有关如何处理停用代码的说明，请参阅上面引用的 DO-178C 或 DO-278A 部分。If the COTS software has option-selectable functionality, some deactivated code may exist. For an explanation of how to address deactivated code, see the DO-178C or DO- 278A sections referenced above.

对于所有产品，如果供应商不提供用户选择选项或功能的能力，并且客户必须更改软件，则需要将该软件视为先前开发的软件。这不会改变认证/批准要实现的目标。For all products, where the capability for the user to select options or functions is not provided by the vendor, and where the customer has to change the software, one needs to consider this software as previously developed software. This will not change the objectives to be fulfilled for certification/approval.

3.5 FAQ #5: 现场可加载软件中的“端到端检查”是什么？ What are “end-to-end checks” in the context of field-loadable software?

参考 Reference: DO-178C：第 2.5.5.d 节DO-178C: Section 2.5.5.d

DO-278A：第 2.6.5.d 节 DO-278A: Section 2.6.5.d

关键字 Keywords: 端到端检查；现场可加载软件 end-to-end checks; field-loadable software

回答 Answer:

“端到端”检查意味着整个软件加载都被一点一点地验证。它从装载介质的生产开始，到装载成功完成的验证结束。这包括确认显示的部件号等是否正确。“End-to-end” checking means that the entire software load is verified – bit by bit. It starts with the production of the load media and ends with verification of the load being successfully completed. This includes the confirmation that displayed part numbers, etc. are shown to be correct.

执行现场可加载应用软件的加载或负载完整性检查的软件通常在系统不运行时（例如在地面上）运行。Software that performs the loading, or integrity checking of the load, of field-loadable application software is typically operational when the system is not operational, for example, on the ground.

加载后系统的正确运行取决于应用软件的正确加载以及验证配置的能力（例如，维护人员对部件号的审查）。Proper system operation after the load is dependent on a correct load of the application software and the ability to verify the configuration (for example, a review of part numbers by maintenance personnel).

有时可以确保加载的完整性，而无需验证负责此加载的复杂软件并检查与正在加载的软件相同的级别。这可以通过独立于加载检查软件的简单检查来完成。这些检查应根据所加载软件的级别进行开发和验证。这些简单的检查，称为端到端检查，通常使用内存校验和、读/写验证或循环冗余校验（CRC）来确认加载正确性。此类检查独立于实际执行加载的软件以及任何相关的零件编号显示或检查。Integrity of the load can sometimes be assured without verification of the complex software responsible for this loading and checking to the same level as the software being loaded. This can be done via simple checks that are independent of the load checking software. These checks should be developed and verified to the level of the loaded software. These simple checks, referred to as end-to-end checks, generally use memory checksum, read/write verification, or cyclic redundancy checks (CRC) to confirm load correctness. Such checks are independent from the software that actually performed the load and from any associated part number display or checks.

3.6 FAQ #6: D 级系统的设计描述和验证活动目标是什么？为什么附件 A 中要满足的目标存在明显的不一致？ What are the design description and verification activity objectives for a Level D system and why are there apparent inconsistencies in the objectives to be satisfied in Annex A?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.7 FAQ #7: 如何符合 DO-178C/DO-278A 第 5.2.3 节“用户可修改软件的设计”？ How can compliance with DO-178C/DO-278A section 5.2.3, Designing for User-Modifiable Software, be obtained?

参考 Reference: DO-178C/DO-278A：第 5.2.3 节 DO-178C/DO-278A: Section 5.2.3

关键字 Keywords: 不可修改的软件；用户可修改的软件 non-modifiable software; user-modifiable software

回答 Answer:

DO-178C/DO-278A 第 5.2.3.b 节规定：“所提供的用于更改可修改组件的方法应被证明是可以更改可修改组件的唯一方法。” DO-178C/DO-278A section 5.2.3.b states: “The means provided to change the modifiable component should be shown to be the only means by which the modifiable component can be changed.”

从一开始就假设符合 DO-178C/DO-278A 第 5.2.3.a 节；也就是说，不可修改的软件完全受到保护，免受用户可修改部分的干扰，并且还满足 DO-178C/DO-278A 5.2.3.a 的条件。此外，用户可修改软件的效果应通过所采用的保护机制（例如在加载期间）显示出对整体系统安全性没有不利影响。The assumption is made from the outset that compliance with DO-178C/DO-278A section 5.2.3.a is in place; that is, that the non-modifiable software is completely protected from interference from the user-modifiable portion, and that the conditions of DO-178C/DO-278A 5.2.3.a are also met. Further, the effects of the user-modifiable software should be shown to have no adverse effect on the overall system safety through the protection mechanisms employed, for example, during loading.

现在的问题之一是如何实现对用户可修改软件的更改。这是通过申请人规定的方式确定的。这些手段可以以各种方式表示（例如，定义的工具、方法或规则）。只要用户遵守这些方法，就只会产生预期的修改。例如，申请人可以为用户可修改组件定义一组足够具体的设计要求，连同定义的实现方法，它构成了实现更改的唯一手段。申请人应该证明可修改组件周围的保护机制可以保护不可修改组件免受意外更改的影响。应注意，用户可修改软件的更改不会触发不可修改软件的更改。The issue now becomes one of how the change to the user-modifiable software is implemented. This is established through the applicant's defined means. The means can be represented in various ways (for example, defined tools, methodology, or rules). As long as the user adheres to these means, only the intended modification will result. For example, the applicant may define a set of design requirements for the user-modifiable component that is specific enough that, along with a defined implementation methodology, it constitutes the only means to implement the change. The applicant should show that the protection mechanisms around the modifiable component shield the non-modifiable component from unexpected changes. Caution should be exercised that a change in the user-modifiable software does not trigger a change in the non-modifiable software.

3.8 FAQ #8: 可选软件可以包含停用的代码吗？ Can option-selectable software contain deactivated code?

参考 Reference: DO-178C：第 2.5.4、4.2.h、5.2.4 和 6.4.4.3.d 节

DO-278A：第 2.6.4、4.2.h、5.2.4 和 6.4.4.3.d 节

DO-178C: Sections 2.5.4, 4.2.h, 5.2.4, and 6.4.4.3.d

DO-278A: Sections 2.6.4, 4.2.h, 5.2.4, and 6.4.4.3.d

关键字 Keywords: 停用代码；可选软件 deactivated code; option-selectable software

回答 Answer:

是的，请参阅 DO-178C 第 2.5.4 节（DO-278A 第 2.6.4 节）了解可选软件的详细说明，以及 DO-178C/DO-278A 第 4.2.h 和 5.2.4 节的设计已停用的代码。Yes, please refer to DO-178C section 2.5.4 (DO-278A section 2.6.4) for details for description of option-selectable software, and DO-178C/DO-278A sections 4.2.h and 5.2.4 for designing for deactivated code.

3.9 FAQ #9: **所有高级需求都需要硬件/软件集成测试吗？而且，“验证软件需求和组件之间的相互关系”是什么意思？ Do all high-level requirements require hardware/software integration testing? And, what does “To verify the interrelationships between software requirements and components” mean?**

参考 Reference: DO-178C/DO-278A：第 6.4、6.4.1 和 6.4.3 节 DO-178C/DO-278A: Sections 6.4, 6.4.1, and 6.4.3

关键字 Keywords: 软硬件集成测试；高水平要求；一体化; 相互关系；软件集成测试hardware/software integration test; high-level requirements; integration; interrelationships; software integration test

回答 Answer:

DO-178C/DO-278A 第 6.4 节将硬件/软件集成测试定义为验证“软件在目标计算机环境中正确运行”的过程。DO-178C/DO-278A section 6.4 defines hardware/software integration testing as a process that verifies the “correct operation of the software in the target computer environment.”

DO-178C/DO-278A 第 6.4.3.a 节规定：“基于需求的硬件/软件集成测试可确保目标计算机中的软件满足高级要求。”DO-178C/DO-278A section 6.4.3.a states: “Requirements-based hardware/software integration testing ensures that the software in the target computer will satisfy the high-level requirements.”

因此，第一个问题的答案是“否”：不需要所有高级需求测试都在目标计算机上执行。参考 DO-178C/DO-278A 第 6.4.1 节，其中指出“可能需要多个测试环境才能满足软件测试的目标”。然而，在主机（非目标计算机环境）上进行的测试可能需要证明其结果对于目标计算机系统的有效性。So, the answer to the first question is “no”: It is not required that all high-level requirements testing be executed on the target computer. Reference DO-178C/DO-278A section 6.4.1 that states that “more than one test environment may be needed to satisfy the objectives for software testing.” However, testing conducted on a host computer (nontarget computer environment) may need justification for their results validity for the target computer system.

对于第二个问题，请参见 DO-178C/DO-278A 第 6.4.3.b 节，其中指出：“基于需求的软件集成测试可确保软件组件彼此正确交互并满足软件需求和软件架构。”For the second question, see DO-178C/DO-278A section 6.4.3.b, which states: “Requirements-based software integration testing ensures that the software components interact correctly with each other and satisfy the software requirements and software architecture.”

3.10 FAQ #10: 是否允许更改基线？第 7.2.2.c 节规定应保护基线免受更改，而第 7.2.4.c 节则讨论基线的更改。 Are baselines allowed to be changed? Section 7.2.2.c states baselines should be protected from change, whereas section 7.2.4.c talks about changes to baselines.

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.11 FAQ #11: DO-178B 第 7.2.7.a 节中的“批准来源”是以前批准的产品还是构建该产品的组织？ Is the "approved source" in section 7.2.7.a of DO-178B the previous approved product or is it the organization building the product?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。 This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.12 FAQ #12: 控制类别 1 和 2（CC1 和 CC2）的定义是什么？ What are the definitions of Control Categories 1 and 2 (CC1 and CC2)?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.13 FAQ #13: 如何使用 7.3 节中的表 7-1 来理解控制类别 1 和 2（CC1 和 CC2）？How is Table 7-1 in section 7.3 used to understand Control Categories 1 and 2 (CC1 and CC2)?

参考 Reference: DO-178C/DO-278A：第 7.3 节 DO-178C/DO-278A: Section 7.3

关键字 Keywords: 配置管理; 控制类别；控制类别1； CC1；控制类别2； CC2 configuration management; control categories; Control Category 1; CC1; Control Category 2; CC2

回答 Answer:

DO-178C/DO-278A 第 7.3 节定义了 CC1 和 CC2 应满足的配置管理目标。表 7-1 第 2 列中的条目引用了适用于软件生命周期数据的所有 SCM 目标，但软件负载控制和软件生命周期环境控制除外。表第 3 列中的黑点表示所有 SCM 目标都适用于应满足 CC1 目标的数据。第 4 列中的黑点表示适用于应满足 CC2 目标的数据的 SCM 目标子集。DO-178C/DO-278A section 7.3 defines the configuration management objectives that should be satisfied for CC1 and for CC2. The entries in column 2 of table 7-1 are references to all the objectives of SCM that apply to software life cycle data, with the exceptions of Software Load Control and Software Life Cycle Environment Control. The black dots in column 3 of the table indicate that all the SCM objectives apply for data which should meet CC1 objectives. The black dots in column 4 indicate the subset of SCM objectives that apply for data which should meet CC2 objectives.

3.14 FAQ #14: 当应用于附件 A 的目标时，控制类别 1 和 2（CC1 和 CC2）意味着什么？What do Control Categories 1 and 2 (CC1 and CC2) mean when applied to the objectives of Annex A?

参考 Reference: DO-178C/DO-278A：第 7.3 节和附件 A DO-178C/DO-278A: Section 7.3 and Annex A

关键字 Keywords: 配置管理; 数据控制类别；控制类别1； CC1；控制类别2； CC2 configuration management; data control categories; Control Category 1; CC1; Control Category 2; CC2

回答 Answer:

CC1 和 CC2 定义了处理生成的数据的流程和活动，以表明每个附件 A 目标均已实现。 CC1 和 CC2 解决配置管理 (CM) 问题。根据数据类型，这些问题的处理方式不同。CC1 and CC2 define the processes and activities for handling the data that is generated to show that each Annex A objective has been achieved. CC1 and CC2 address configuration management (CM) issues. These issues are handled in different ways depending on the type of data.

DO-178C/DO-278A 附件 A 中的表格规定了软件生命周期数据的每个项目按软件级别/保证级别应用的数据控制类别（CC1 或 CC2）。The tables in Annex A of DO-178C/DO-278A specify which data control category (CC1 or CC2) applies by software level/assurance level for each item of software life cycle data.

DO-178C/DO-278A 表 7-1 的最后两列定义了哪些目标适用于 CC1，哪些目标适用于 CC2。一般来说，CC2是一种更简单的控制方法，并且根据数据类型和软件级别/保证级别应用于数据项。附录 A 定义了每种数据类型的分类。The last two columns of DO-178C/DO-278A Table 7-1 define which objectives are applicable to CC1 and which objectives are applicable to CC2. In general, CC2 is a simpler method of control and is applied to data items based on the type of data and the software level/assurance level. Annex A defines the categorization for each type of data.

并非所有数据都需要使用相同的方法进行控制才能满足 CC1 和 CC2 目标。例如，软件质量保证（SQA）记录可以通过将其放入开发库中来控制，而产品可执行代码可以由独立的CM组织来控制。Not all data needs to be controlled using the same method to meet the CC1 and CC2 objectives. For example, Software Quality Assurance (SQA) Records may be controlled by placing them in a development library, whereas the product executable code may be controlled by an independent CM organization.

3.15 FAQ #15: 软件是否被认证为独立产品？ Is software certified as a stand-alone product?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.16 FAQ #16: 先前开发的软件 (PDS) 可以达到的最高软件级别（根据 DO-178C）或保证级别（根据 DO-278A）是多少？ What is the highest software level (per DO-178C) or assurance level (per DO-278A) that can be attained for previously developed software (PDS)?

参考 Reference: DO-178C/DO-278A: Section 12.1

关键字 Keywords: 保证水平；商业现成软件；现货供应；以前开发的软件； PDS；软件级别 assurance level; commercial off-the-shelf software; COTS; previously developed software; PDS; software level

回答 Answer:

先前开发的软件 (PDS) 可获得的最高软件级别/保证级别可以是 A/AL1 级。为了实现这一点，PDS 应满足 DO-178C/DO-278A 的所有适用目标。The highest software level/assurance level obtainable for previously developed software (PDS) can be Level A/AL1. For this to be achieved, the PDS should satisfy all the applicable objectives of DO-178C/DO-278A.

使用 PDS 的商业考虑可能会阻止申请人达到该软件技术上可能的最高水平。Business considerations of using PDS could prevent an applicant from reaching the highest level that is technically possible for that software.

3.17 FAQ #17: 从较早的基线更改先前开发的软件 (PDS) 版本会产生哪些问题？ What are the issues related to changing previously developed software (PDS) versions from an earlier baseline?

参考 Reference: DO-178C/DO-278A: Sections 7.2.2, 7.2.4, and 12.1

关键词 Keywords: 基线；改变; 商业现成软件；现货供应；修改; 以前开发的软件； PDS baseline; change; commercial off-the-shelf software; COTS; modification; previously developed software; PDS

回答 Answer:

对于此常见问题解答，商业现成 (COTS) 软件被视为 PDS 的子集。具有相关 PDS 的系统可能已使用 DO-178C/DO-278A 以外的方式进行认证或批准。监管信息旨在为使用 DO-178C/DO-278A 的遗留系统中的软件变更审批提供指导。For this FAQ, commercial off-the-shelf (COTS) software is considered a subset of PDS. The system with PDS in question may have been certified or approved using means other than DO-178C/DO-278A. Regulatory information exists to provide guidance for approval for software changes in legacy systems using DO-178C/DO-278A.

合并更改的 PDS 基线的工作应遵循与根据 DO-178C/DO-278A 的目标合并任何软件产品中的更改相同的流程。这包括但不限于对以下方面的评估：The effort to incorporate the changed PDS baseline should follow the same process as incorporating changes in any software product per the objectives of DO-178C/DO-278A. This includes, but is not limited to, an evaluation of the:

• PDS 需求变更对系统需求的影响。 Impact of PDS requirements changes on system requirements.

• 变更对系统安全分析的影响。 Impact of the change on the system safety analysis.

• 变更对先前接受的认证数据包的影响，以确定变更的范围并决定是否应该或可以完成变更。Impact of the change on the previously accepted certification data package to determine the scope of the change and to decide if the change should or can be accomplished.

• 变更对软件生命周期数据的影响。 Impact of changes on software life cycle data.

• 对重新验证工作的影响。 Impact to re-verification efforts.

• 处理在系统中实施和验证 PDS 修改（如果选择）的工作。 Process effort to implement and verify the PDS modification (if selected) into the system.

假设 PDS 先前已合并到经过认证的系统中。更改 PDS 基线版本的决定基于与最初选择 PDS 时使用的相同考虑因素。在继续进行更改之前，应做出新的接受或拒绝决定。重要的是要访问提供商的问题报告（已纳入变更中）以及修订后的软件要求（新功能），作为合并和重新验证新版本系统软件的路线图。捕获与版本之间修复的问题相关的任何信息非常重要。应获取与 PDS 有关的任何生命周期数据。即使对于 COTS 软件，也可以提供问题报告。修订后的软件需求声明可以通过新功能列表或更新的用户手册获得。The assumption is made that the PDS has been previously incorporated into a certified system. The decision to change the baseline version of PDS is based on the same considerations used in the original selection of the PDS. A new accept or reject decision should be made before going forward with the change. It is important to gain access to the provider’s Problem Reports that were incorporated into the change, as well as the revised software requirements (new functionality) as a roadmap to incorporation and reverification of the new version of the system software. It is important to capture any information related to problems fixed in between versions. Any life cycle data pertaining to the PDS should be obtained. The Problem Reports may be provided, even for COTS software. The revised software requirements statement may be available through a list of new features or an updated user’s manual.

PDS 的配置注意事项应确保申请人控制基线和后续更新。例如，所有收到的具有相同标识的 PDS 副本可能不相同，但申请人交付的所有副本应相同。Configuration considerations for PDS should ensure baseline and subsequent updates are controlled by the applicant. For example, all received copies of PDS with the same identification may not be identical, yet all delivered copies from the applicant should be identical.

有关 PDS 的更多信息可以使用关键字索引（附录 C）获得。 Further information on PDS may be obtained using the keyword index (Appendix C).

3.18 FAQ #18: 由于没有处理飞机运行环境变化的具体指南，DO-178C 的哪一部分解决了此类变化？ Since there is no specific guidance for handling changes to the aircraft’s operational environment, what part of DO-178C addresses this type of change?

参考 Reference: DO-178C: Sections 12.1.1 and 12.1.2

关键词 Keywords: 飞机安装；改变; 修改; 运行环境；以前开发的软件； PDS aircraft installation; change; modification; operational environment; previously developed software; PDS

回答 Answer:

DO-178C 第 12.1.1 节解决了对先前开发的软件 (PDS) 的修改。 DO-178C 第 12.1.2 节解决了飞机安装发生变化的情况。虽然飞机运行环境的变化（例如，最大高度或最大空速）严格来说并不是飞机安装的变化，但 DO-178C 第 12.1.2 节可用于涵盖现有飞机运行环境的变化安装。具体来说，DO-178C 第 12.1.2.b 节涵盖了对飞机的功能修改，其中可能包括由于操作环境的变化而导致的软件要求的变化。当使用 DO-178C 第 12.1.2 节时，应假定术语“飞机安装”包括安装和环境。DO-178C section 12.1.1 addresses modifications to previously developed software (PDS). DO-178C section 12.1.2 addresses the case when the aircraft installation changes. While a change in an aircraft’s operating environment (for example, maximum altitude or maximum airspeed) is not strictly a change in the aircraft installation, DO-178C section 12.1.2 can be used to cover a change to the operating environment of an existing aircraft installation. Specifically, DO-178C section 12.1.2.b covers the functional modifications to the aircraft which may include changes to software requirements due to changes to the operating environment. When using s DO-178C section 12.1.2, it should be assumed that the term “aircraft installation” includes both the installation and the environment.

3.19 FAQ #19: 如何确定使用中的问题是否表明流程不充分，以及是否可以继续追求服务历史记录来遵守某些流程的不足之处？How does one determine if in-service problems indicate an inadequate process, and can one continue to pursue a service history means of compliance with some process inadequacies?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。该信息已纳入 DP #4。 This FAQ has been removed, as approved by the SC-205/WG-71 committee. The information has been incorporated into DP #4.

3.20 FAQ #20: DO-178C、DO-278A 和补充中的术语表的来源是什么？为什么它们看起来与其他标准定义不同？What is the source of the glossary of terms in DO-178C, DO-278A, and the Supplements, and why do they appear to be different from other standard definitions?

参考 Reference: DO-178C/DO-278A: Annex B and Section 1.4

关键字 Keywords: 定义；词汇表；条款 definitions; glossary; terms

回答 Answer:

在可能的情况下，DO-178C/DO-278A 对文档中使用的术语使用标准定义。这些定义在电气和电子工程师协会 (IEEE) 和汽车工程师协会 (SAE) 等行业标准中定义。此外，还使用欧洲航空安全局 (EASA) 和美国联邦航空管理局 (FAA) 文件中的术语。Where possible, DO-178C/DO-278A uses standard definitions for the terms used in the document. These definitions are defined in industry standards such as Institute of Electrical and Electronic Engineers (IEEE) and Society of Automotive Engineers (SAE). Additionally, terms from European Aviation Safety Agency (EASA) and Federal Aviation Administration (FAA) documents are used.

DO-178C/DO-278A 术语表（附件 B）对一些术语进行了更精确或更狭义的定义，其中航空界需要进行特殊解释，并防止在解释文件时出现歧义。然而，制定该文件的联合委员会的目标是尽量减少 DO-178C 中特殊术语或独特定义的使用。 DO-278A 术语表独立于 DO-178C（即 DO-278A 有自己完整的术语表）。它从 DO-178C 术语表开始，并修改或添加了术语来解决 CNS/ATM 非机载软件开发问题。The DO-178C/DO-278A glossary (Annex B) defines some terms more precisely or narrowly, where a special interpretation is required by the aviation community and in order to prevent ambiguity during the interpretation of the document. However, it was a goal of the joint committee developing the document to minimize the use of special terms or unique definitions in DO-178C. The DO-278A glossary stands alone from DO-178C (that is, DO-278A has its own complete glossary). It started with the DO-178C glossary and modified or added terms to address CNS/ATM non-airborne software development.

DO-178C/DO-278A 补充材料还包括术语表。这些术语表包含特定补充中讨论的技术所独有的术语。对于非技术特定的术语，DO-178C/DO-278A 术语表充当补充术语表。The DO-178C/DO-278A supplements also include glossaries. These glossaries contain terms which are unique to the technology discussed in the specific supplement. For terms that are not technology specific, the DO-178C/DO-278A glossary serves as the glossary for the supplements.

3.21 FAQ #21: DO-178C/DO-278A 附件 B 中“补丁”定义的第二句与定义本身有何关系？How is the second sentence of the definition of “patch” in DO-178C/DO-278A Annex B relevant to the definition itself?

参考 Reference: DO-178C/DO-278A: Annex B

关键字 Keywords: 嵌入标识符；修改; 补丁 embedded identifiers; modification; patch

回答 Answer:

DO-178C/DO-278A Annex B defines “patch” as: “Modification to Executable Object Code, in which one or more of the planned steps of re-compiling, re-assembling, or relinking is bypassed. This does not include embedded identifiers.“

该定义的第二句旨在显示正常情况下公认的例外情况。通常，嵌入的标识符是诸如校验和或部件号之类的值。如果在编译时无法确定这些值，则会在链接期间或之后分配内存并插入值。这种类型的修改不被视为补丁，因为它不修改可执行代码。第二句话提供了这种区别。The second sentence of this definition is intended to show recognized exceptions to the normal case. Typically, embedded identifiers are values such as checksums or part numbers. In cases where the values cannot be determined at compile time, memory is allocated and values are inserted during or after linking. This type of modification is not considered a patch since it is not modifying the executable code. The second sentence provides this distinction.

3.22 FAQ #22: 软件工程研究所（SEI）能力成熟度模型集成（CMMI）、软件过程改进能力评估（SPICE）等各种行业过程评估是否可以用于认证积分？ Can various industry process assessments such as the Software Engineering Institute (SEI) Capability Maturity Model Integration (CMMI), Software Process Improvement Capability Evaluation (SPICE), etc. be used for certification credit?

参考 Reference: DO-178C/DO-278A: Sections: 1.3, 9.1, 11, and Annex A

关键字 Keywords: 能力成熟度模型集成； CMMI；过程评估；软件工程学院； SEI；软件过程改进能力评估； SPICE Capability Maturity Model Integration; CMMI; process assessment; Software Engineering Institute; SEI; Software Process Improvement Capability Evaluation; SPICE

Answer:

简单的答案是，申请人不能因使用 SEI CMMI、SPICE 等而声称获得认证“信用”。The simple answer is that an applicant cannot claim certification “credit” for the use of the SEI CMMI, SPICE, etc.

尽管 DO-178C/DO-278A 及其前身提倡良好的过程特性，但过程目标主要是根据过程数据和相关产品的属性给出的。许多 DO-178C/DO-278A 目标在具体术语中专门与开发和验证流程的完整性和严格性相关，而通用流程模型（例如 SEI CMMI 和 SPICE）则更侧重于业务流程测量和改进。他们规定并评估了许多工艺属性，这些属性对于产品的高完整性和安全性来说是必要的，但不是充分条件。例如，SEI CMMI 没有与验证（审查、分析或测试）覆盖范围相关的流程活动或能力或指标，而这是 DO-178C/DO-278A 指南的一个非常重要的方面，因为验证是一个关键因素在系统安全方面。Although DO-178C/DO-278A and its predecessors advocate good process characteristics, process objectives are given primarily in terms of attributes of the process data and the associated product. Many of the DO-178C/DO-278A objectives specifically relate to completeness and rigor of development and verification processes in specific terms, whereas the generalized process models, such as the SEI CMMI and SPICE, are more focused on business process measurement and improvement. They stipulate and assess against many process attributes that are necessary, but not sufficient conditions, for high product integrity and safety. For example, the SEI CMMI has no process activities or capabilities or metrics associated with verification (review, analysis, or test) coverage, whereas this is a very significant aspect of DO-178C/DO-278A guidance, because verification is a key factor in system safety.

尽管存在一些重叠，DO-178C/DO-278A 仍然是针对机载和 CNS/ATM 系统的更全面的指南。寻求使用 SEI CMMI、SPICE 等进行流程认可的申请人可以轻松地重复使用相同的流程合规性数据来证实符合 DO-178C/DO-278A 目标。此类数据仍需要满足 DO-178C/DO-278A 第 11 节的软件生命周期数据属性以及 DO-178C/DO-278A 附件 A 关于独立性和配置控制的目标。Although there is some overlap, DO-178C/DO-278A remains the more comprehensive guidance for airborne and CNS/ATM systems. Applicants seeking process recognition for the use of the SEI CMMI, SPICE, etc. may readily reuse the same process compliance data to substantiate compliance with DO-178C/DO-278A objectives. Such data would still be required to meet the software life cycle data attributes of DO-178C/DO-278A section 11 and the objectives of DO-178C/DO-278A Annex A with respect to independence and configuration control.

3.23 FAQ #23: DO-178C/DO-278A 是否解决了软件可靠性问题？ Is software reliability addressed by DO-178C/DO-278A?

Reference: DO-178C/DO-278A: Sections 2.3 and 12.3.3

Keywords: software reliability

Answer:

DO-178C/DO-278A 确实提到了软件可靠性；然而，DO-178C/DO-278A 中通过以下观察驳回了对软件使用数字可靠性数字的概念：DO-178C/DO-278A does mention software reliability; however, the concept of using numerical reliability figures for software is dismissed in DO-178C/DO-278A by making the following observations:

• DO-178C/DO-278A 第 2.3 节规定，软件级别/保证级别不能解释为故障率。 DO-178C/DO-278A section 2.3 states that a software level/assurance level cannot be interpreted as a failure rate.

• DO-178C/DO-278A 第 12.3.3 节指出，基于开发指标的软件可靠性分析不能提供足够的置信度。 DO-178C/DO-278A section 12.3.3 indicates that software reliability analysis based on development metrics does not provide sufficient confidence.

3.24 FAQ #24: ARP4754A/ED-79A和DO-178C有什么关系？ What is the relationship between ARP4754A/ED-79A and DO-178C?

Reference: DO-178C: Section 2

Keywords: ARP4754A； ED-79A；硬件开发；系统开发流程；系统安全评估； SSA；系统安全评估流程 ARP4754A; ED-79A; hardware development; system development processes; system safety assessment; SSA; system safety assessment process

Answer:

汽车工程师学会 (SAE) 航空航天推荐实践 ARP4754A 或 EUROCAE 文件 ED-79A，“民用飞机和系统开发指南”，旨在为实现飞机级功能的系统和设备提供系统级指导，并提供特定相关学科的链接，例如软件开发生命周期。 DO-178C 第 2 节讨论了系统安全评估过程、硬件开发过程和软件开发过程之间的关系。下图说明了这些关系。Society of Automotive Engineers (SAE) Aerospace Recommended Practice ARP4754A or EUROCAE document ED-79A, “Guidelines for Development of Civil Aircraft and Systems,” was produced to provide guidance at the system level for systems and equipment that implement aircraft-level functions and to provide links to specific related disciplines, such as the software development life cycle. The relationships between the system safety assessment process, hardware development process, and software development process are discussed in DO-178C section 2. The following diagram illustrates these relationships.

Figure 3-1 ARP4754/ED-79 Relationship To Other Documents

3.25 FAQ #25: 是否可以使用架构手段来降低将先前开发的软件 (PDS) 合并到系统中所需的软件级别/保证级别？Can architectural means be used to reduce the software level/assurance level needed for the incorporation of previously developed software (PDS) in a system?

Reference: DO-178C/DO-278A: Section 2.4

Keywords: 架构方法；架构; 保证水平；商业现成的；现货供应；分区；以前开发的软件； PDS；软件级别 architectural means; architecture; assurance level; commercial off-the-shelf; COTS; partitioning; previously developed software; PDS; software level

Answer:

是的，架构方法可用于通过减轻 PDS 异常行为可能导致的所有已识别风险来降低所需的软件级别/保证级别。 DO-178C/DO-278A 第 2.4 节中讨论的方法适用于包括 PDS 在内的所有类型的软件。对于 PDS 和任何其他软件来说，与这些方法相关的所需论证（例如设计独立性的分析等）也是相同的。如果无法获得足够的论证数据，这可能会限制架构手段的使用范围。 SAE ARP4754A（和 EUROCAE ED-79A）和 DO-178C/DO-278A 中讨论的用于实现架构手段的方法也可能适用于 PDS。下面列出了这些文档中引用的一些架构方法：Yes, architectural means can be used to reduce the software level/assurance level needed by mitigating all identified risks that could result from anomalous behavior of the PDS. The methods discussed in DO-178C/DO-278A section 2.4 are applicable to all types of software including PDS. The required justification associated with these methods (such as analysis with respect to design independence, etc.) is also the same for PDS as for any other software. If sufficient justification data cannot be obtained, this may limit the extent to which the architectural means may be used. Methods for implementing architectural means discussed in SAE ARP4754A (and EUROCAE ED-79A) and DO-178C/DO-278A are also potentially applicable to PDS. Some of the architectural means referenced in these documents are listed below:

• 分区 Partitioning.

• 安全监控。 Safety monitoring.

• 多版本不同的软件（使用监视器、比较器和轮询）可用于冗余或备份。 DO-178C/DO-278A 第 2.4 节还讨论了实施这些方法所需的保证。实施这些方法的进一步考虑包括但不限于：Multiple-version dissimilar software (with use of monitors, comparators, and polling) may be used for redundancy or backup. Assurance needed to implement these methods is also discussed in DO-178C/DO-278A section 2.4. Further considerations in the implementation of these methods include but are not restricted to:

• 所得函数是主要函数还是次要函数。 Whether the resulting function is a primary or a secondary function.

• 共模故障的概率。 Probability of common mode failures.

• 常见原因错误分析。 Analysis of common cause errors.

根据最终的架构，可能需要比 PDS 更好的架构手段保证。 Depending upon the resultant architecture, more assurance of the architectural means may be needed than that of the PDS.

还要注意，在 PDS 的情况下可能会使用功能限制。一般来说，许多 PDS 产品包括任何给定应用程序可能不需要的各种功能，因此可能有必要对所有这些产品进行相同程度的审查，除非不需要的功能受到限制。应该提供分析来说明为什么以及如何停用不需要的代码。功能限制可能会导致生成的 PDS 组件中的代码被停用。此外，PDS 还可能包含无关代码或死代码。所有关于停用、无关和死代码的目标也适用于 PDS。Note also that restriction of functionality may be used in the case of PDS. In general, many PDS products include a variety of functions that might not be needed for any given application and thus it might be necessary to subject all of them to the same degree of scrutiny unless unneeded functions are restricted. There should be an analysis provided to show why and how unneeded code is deactivated. Restriction of functionality may result in deactivated code in the resultant PDS component. Additionally, PDS may also contain extraneous or dead code. All objectives regarding deactivated, extraneous, and dead code also apply to PDS.

3.26 FAQ #26: 满足“多版本不同软件的独立性”（DO-178B 第 12.3.3.1 节）是否取代 DO-178B 附件 A 中定义的独立性要求？Does the fulfillment of “independence of multiple-version dissimilar software” (DO-178B section 12.3.3.1) supersede the independence requirements as defined in Annex A of DO-178B?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.27 FAQ #27: “用户可修改的软件”是什么意思？ What is meant by “user-modifiable software”?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。 This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.28 FAQ #28: 删除死代码或未使用的变量有什么价值？ **What is the value of removing dead code or unused variables?**

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。 This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.29 FAQ #29: 如果 DO-178C 第 2.5.5.b 节（DO-278A 第 2.6.5.b 节）解决了与默认模式相关的要求（如果提供了一种默认模式来防止软件加载错误），那么它意味着什么？ What does DO-178C section 2.5.5.b (DO-278A section 2.6.5.b) mean, when it addresses requirements related to a default mode, if one is provided to protect against software load errors?

Reference: DO-178C: Section 2.5.5.b

DO-278A: Section 2.6.5.b

Keywords: default mode; load

Answer:

DO-178C 第 2.5.5.b 节（DO-278A 第 2.6.5.b 节）规定：“如果系统在检测到损坏或不适当的软件负载后恢复到默认模式或安全状态，则系统的每个分区组件系统应具有指定的恢复到此模式并在此模式下运行的安全相关要求。接口系统可能还需要进行审查，以便在默认模式下正常运行。”DO-178C section 2.5.5.b (DO-278A section 2.6.5.b) states: “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.”

当将新软件加载到系统中时，可能会出现许多问题，包括加载中断和不正确的软件加载。在大多数情况下，系统设计者会考虑这些问题并找到一种机制来确保可以建立已知的系统状态。When loading new software into a system, a number of problems can arise including interrupted loads and incorrect software loads. In most cases, the system designer will have considered these problems and arrived at a mechanism for ensuring a known system state can be established.

DO-178C 第 2.5.5.b 节（DO-278A 第 2.6.5.b 节）只是说已经捕获了恢复到此已知状态的要求。根据定义，这些要求被视为与安全相关的要求，因为它们建立了系统可以返回到安全状态的机制，并且包含了加载期间遇到的问题。请注意，可能需要检查接口系统是否可以在默认模式下正常运行。DO-178C Section 2.5.5.b (DO-278A section 2.6.5.b) is simply saying that the requirements for recovering to this known state have been captured. These requirements are, by definition, considered safety-related requirements since they establish the mechanism by which the system can be returned to a safe state and that the problem encountered during loading is contained. Note that interfacing systems may need to be reviewed for proper operation with the default mode.

3.30 FAQ #30: DO-178B 第 2.6a(2) 节对于解决系统异常行为的系统安全要求意味着什么？What does DO-178B section 2.6a(2) mean regarding system safety requirements addressing system anomalous behavior?

This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.31 FAQ #31: 产品验证与“编译器可接受性”有何关系？ How does verification of product relate to “compiler acceptability”?

This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.32 FAQ #32: 什么是防御性编程实践？ What are defensive programming practices?

Reference: DO-178C/DO-278A: Sections 1.4 and 4.5

Keywords: defensive programming; software development standards

Answer:

DO-178C/DO-278A 第 4.5 节的注释 1 提到了防御性编程，其中指出：“可以考虑防御性编程实践来提高鲁棒性。” DO-178C/DO-278A 第 1.4.m 节规定，注释旨在“提供解释性材料、强调某一点或引起人们对不完全在上下文中的相关项目的注意”。Note 1 of DO-178C/DO-278A section 4.5 mentions defensive programming when it states, “Defensive Programming practices may be considered to improve robustness.” Section 1.4.m of DO-178C/DO-278A states that notes are intended to “provide explanatory material, emphasize a point, or draw attention to related items that are not entirely within context.”

防御性编程实践是可用于通过限制可能导致操作失败和代码中引入错误的结构、构造和实践的使用来防止代码执行非预期或不可预测的操作的技术。Defensive programming practices are techniques that may be used to prevent code from executing unintended or unpredictable operations by constraining the use of structures, constructs, and practices that have the potential to introduce failures in operation and errors into the code.

防御性编程与软件的稳健性有关，而不是其正确性或可维护性。应该承认，“良好”的编程实践将促进软件的健壮性，因此可以被视为防御性编程。此外，应该注意的是，软件的稳健性应该由软件需求来定义，软件需求指定对异常条件和输入的正确软件响应。设计和编码标准中可以考虑防御性编程。Defensive programming is related to the robustness of the software, not its correctness or maintainability. It should be acknowledged that “good” programming practice will promote robust software and hence could be considered defensive programming. Additionally, it should be noted that the robustness of the software should be defined by software requirements specifying the correct software response to abnormal conditions and inputs. Defensive programming may be considered in the design and coding standards.

注意：请参阅面向对象技术和相关技术补充，了解可能提供支持信息的相关技术。Note: Reference the Object-Oriented Technology and Related Techniques supplement for related techniques that may provide supporting information.

下面包含一些防御性编程的示例（这不是详尽的列表）：Some examples of defensive programming are included below (this is not an exhaustive list):

a. 避免输入数据错误：尽量减少输入数据错误：Avoidance of input data errors: To minimize input data errors:

1. 检查数据输入中的错误或界限，无论是来自人类用户还是来自其他系统。Check errors or bounds in data input whether it is from a human user or from another system.

2. 对传入数据进行合理性检查。Use reasonableness checks on the incoming data.

3. 考虑潜在的数据缓冲区溢出情况（例如，排队控制）和数据老化（例如，时间戳）。Account for potential data buffer overflow conditions (for example, queuing controls) and data aging (for example, time-stamps).

4. 考虑系统之间的接口中可能发生的数据类型强制、缩放以及精度或准确度损失。Account for data type coercion, scaling, and loss of precision or accuracy that may occur in the interface between systems.

5. 包括允许检测错误的运行时检查（例如，由于不正确的实现）。Include run-time checks that allow detection of errors (for example, due to incorrect implementation).

b. 避免非确定性：可以通过以下一种或多种做法来减少非确定性：Avoidance of non-determinism: Non-determinism may be reduced through one or more of the following practices:

1. 选择具有明确标准的语言。Choose a language with a well-defined standard.

2. 不允许自修改代码。 Do not permit self-modifying code.

3. 最大限度地减少内存分页和交换。Minimize memory paging and swapping.

4. 避免使用动态绑定。 Avoid use of dynamic binding.

5. 不要为未显式初始化的变量假定初始值。 Do not assume initial values for variables that are not explicitly initialized.

6. 避免使用内存分配和释放，或者在适用时使用面向对象技术补充的指导。 Avoid use of memory allocation and deallocation or when applicable, use the guidance of the Object Oriented Technologies supplement.

c. 避免复杂性：可以通过以下做法降低复杂性： Avoidance of complexity: Complexity may be reduced through the following practices:

1. 最大化内聚性并最小化耦合。 Maximize cohesion and minimize coupling.

2. 谨慎使用运算符和变量名的重载。Use overloading of operators and variable names cautiously.

3. 对子程序使用单点入口和出口。 Use a single point of entry and exit for subprograms.

4. 尽量减少中断驱动处理的使用。 Minimize use of interrupt-driven processing.

5. 尽量减少架构中多任务和多处理的使用。Minimize use of multi-tasking and multi-processing in the architecture.

6. 当心使用内置函数和编译库时的副作用。Beware of side effects in the use of built-in functions and compiled libraries.

d. 避免接口错误：可以通过以下做法最大限度地减少接口错误：Avoidance of interface errors: Interface errors may be minimized through the following practices:

1. 最大限度地减少接口的复杂性（例如，大量参数、神秘名称等）。 Minimize the complexity of interfaces (for example, a large number of arguments, cryptic names, etc.).

2. 在整个软件应用程序中使用一组标准的单位和精度。Use a standard set of units and precision throughout the software application.

3. 避免过程之间的接口中的类型强制（例如，隐式或自动类型转换、混合模式操作、定点缩放等），或遵循面向对象技术补充的指导。Avoid type coercion (for example, implicit or automated type conversions, mixed mode operations, fixed point scaling, etc.) in interfaces between procedures or follow the guidance of the Object Oriented Technologies supplement.

4. 限制全局变量的使用。 Restrict use of global variables.

e. 避免逻辑错误：为了最大限度地减少引发这些错误的可能性：Avoidance of logical errors: To minimize the potential for inducing these errors:

1. 了解计算过程中可能出现的准确性损失。Understand possible loss of accuracy during computation.

2. 请注意转换错误（例如定点缩放）。Be mindful of conversion errors (for example, fixed point scaling).

3. 避免使用具有副作用的表达式，例如求值语句中的赋值语句。Avoid using expressions with side effects such as assignment statements within evaluation statements.

4. 验证计算索引和数组边界的正确实现。Verify the proper implementation of computed indices and array-bounds.

5. 本地统一处理异常。 Handle exceptions locally and uniformly.

3.33 FAQ #33: 是否可以通过证明任何偏离设计标准的合理性来不满足安全目标？ Is it permissible to NOT meet the safety objectives by justifying any deviations from the design standards?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除 This FAQ has been removed, as approved by the SC-205/WG-71 committee.

3.34 FAQ #34: DO-178B 中使用的独立性概念是什么？What is the concept of independence as used in DO-178B?

经 SC-205/WG-71 委员会批准，此常见问题解答已删除。该信息已纳入 DP #19。This FAQ has been removed, as approved by the SC-205/WG-71 committee. The information has been incorporated into DP #19.

3.35 FAQ #35: 什么是低级需求以及如何测试它们？ What are low-level requirements and how may they be tested?

Reference: DO-178C/DO-278A: Sections 5.0, 5.5, 6.0, 6.5, and Annex A

Keywords: 架构; 派生需求；高水平需求；低级别需求；基于需求的测试；测试；可追溯性 architecture; derived requirements; high-level requirements; low-level requirements; requirements-based testing; testing; traceability

Answer:

特定项目的软件需求是根据系统需求、依赖于硬件架构的软件需求以及任何附加的派生需求而开发的。The software requirements for a particular project are developed from system requirements, hardware architecture-dependent software requirements, and any additional derived requirements.

“在软件设计过程中，定义了软件架构并开发了低级需求”（参考 DO-178C/DO-278A 第 5.0 节）。架构设计的目的是分解软件需求的功能，以便将它们重新组合成逻辑软件结构。“During the software design process, the software architecture is defined and low-level requirements are developed” (reference DO-178C/DO-278A section 5.0). The aim of the architectural design is to break down the functions of the software requirements so that they can be regrouped into a logical software structure.

一旦架构设计完成，就开始各个软件功能的详细设计。在此过程中，将开发低级需求和任何附加的派生需求。这些需求是生成源代码的需求。 “但是，如果源代码直接从高级需求生成，则高级需求也被视为低级需求。可执行目标码对低级需求的符合性可以使用基于需求的测试来证明。测试用例是针对所有级别的需求而开发的。然后需求覆盖率分析评估测试用例对所有需求的覆盖率。

...”（参考 DO-178C/DO-278A 第 5.0 节）。为了能够验证需求的完整实施，提供派生需求的可见性，并支持基于需求的测试覆盖率分析，应开发跟踪数据（参考 DO-178C/DO-278A 第 5.5 和 6.5 节）。Once the architectural design is completed, the detailed design of the individual software functions is initiated. During this process, low-level requirements and any additional derived requirements are developed. These requirements are those from which the Source Code will be generated. “However, if Source Code is generated directly from high-level requirements, then the high-level requirements are also considered low-level requirements Compliance of the executable object code to the low-level requirements may be demonstrated using requirements-based tests. Test cases are developed for all levels of requirements. Then the requirements coverage analysis assesses the coverage of all requirements by the test cases.

…” (reference DO-178C/DO-278A section 5.0). In order to enable the verification of complete implementation of the requirements, to give visibility to derived requirements, and to support the requirements-based test coverage analysis, Trace Data should be developed (reference DO-178C/DO-278A sections 5.5 and 6.5).

可以使用基于需求的测试来证明可执行目标代码对低级需求的符合性。测试用例是针对所有级别的需求而开发的。然后需求覆盖率分析评估测试用例对所有需求的覆盖率。Compliance of the executable object code to the low-level requirements may be demonstrated using requirements-based tests. Test cases are developed for all levels of requirements. Then the requirements coverage analysis assesses the coverage of all requirements by the test cases.