3、DO-178C核心术语与体系结构：系统、软件生命周期、过程目标、数据、证据等关键术语，以及DO-178C的五个过程（计划、开发、验证、配置管理、质量保证）和附录A的结构

DO-178C作为航空机载软件适航认证的黄金标准，其严谨性根植于一套精确的术语体系和结构化的过程框架。理解这些核心术语与体系结构，是正确解读标准、制定合规计划以及高效通过审查的基石。本章将深入剖析DO-178C的关键术语（系统、软件生命周期、过程目标、数据、证据），并系统阐述其五大过程（计划、开发、验证、配置管理、质量保证）以及附录A的结构化应用逻辑，帮助读者建立从概念到实践的完整认知地图。

上图清晰地展示了DO-178C体系结构的核心逻辑：系统生命周期通过ARP4754A定义系统需求与架构，并将软件需求分配给软件生命周期。软件生命周期由五大过程（计划、开发、验证、配置管理、质量保证）驱动，这些过程产生并维护软件生命周期数据（PLD），最终形成符合性证据。附录A则作为“目标-活动-数据-证据”的映射矩阵，将抽象的过程要求转化为具体、可审查的符合性目标。

3.1 核心术语精解：系统、软件生命周期、过程目标、数据与证据

3.1.1 核心原理：术语的精确边界与关联

DO-178C的术语定义并非学术游戏，而是为了消除歧义、确保适航审查的客观性。理解这些术语的边界是合规工作的第一步。

• 系统（System）：指航空器及其相关设备、软件、硬件、人员、程序等组成的整体。DO-178C关注的是“软件在系统中的角色”，即软件需求来源于系统需求分配。系统级过程（如ARP4754A）定义了系统架构与需求分配，而DO-178C则聚焦于软件实现与验证。
• 软件生命周期（Software Life Cycle）：从软件需求定义到软件退役的全过程。DO-178C定义了五个过程（计划、开发、验证、配置管理、质量保证），这些过程相互交织，而非简单的线性顺序。例如，验证过程在开发过程中同步进行，配置管理贯穿始终。
• 过程目标（Process Objective）：每个过程必须达成的可验证结果。DO-178C附录A将每个过程细化为若干目标（如“软件需求被开发并验证”），每个目标对应特定的活动、数据输出和验证方法。目标满足是适航审查的基本单位。
• 数据（Data）：软件生命周期中产生的所有信息，包括计划、需求、设计、代码、测试用例、评审记录等。数据必须满足“正确性、完整性、一致性、可追溯性、可验证性”等属性，并根据其重要性分为控制类别（CC1/CC2）。
• 证据（Evidence）：证明目标已满足的客观材料。证据可以是数据本身、评审结论、测试报告、分析结果等。证据链必须完整：从目标出发，找到对应的活动记录，再追溯到具体的数据输出，最终形成闭环。

3.1.2 判断方法：如何区分数据与证据？

一个常见的困惑是“数据”与“证据”的区别。简单判断：数据是过程产生的“原材料”，而证据是用于证明目标满足的“成品”。例如，一份软件需求文档是数据；当审查员检查该文档是否满足“需求完整性”目标时，该文档及其评审记录就构成了证据。证据必须经过“符合性评审”确认其有效性。

3.1.3 案例拆解：一个飞控系统软件的需求分配

假设某飞控系统（系统级）定义了“自动着陆功能”需求。系统架构师将该功能分配给软件子系统（软件需求）。此时，软件需求文档（数据）记录了“自动着陆控制律”的详细需求。在验证过程中，测试团队执行了“自动着陆场景测试”，生成了测试报告（数据）。当审查员检查“软件需求被正确实现”这一目标时，测试报告与需求文档的追溯关系构成了证据。若追溯断裂（如测试用例未关联到具体需求），则证据链不完整，目标无法被判定为满足。

3.1.4 常见误区与总结

3.2 五大过程详解：计划、开发、验证、配置管理、质量保证

3.2.1 核心原理：过程的协同与迭代

五大过程并非独立运行，而是形成一个动态的、迭代的闭环。计划过程定义“做什么、怎么做”；开发过程执行“需求→设计→编码→集成”；验证过程确认“做对了没有”；配置管理确保“版本可控、变更可追溯”；质量保证则独立监督“过程是否被遵守”。

3.2.2 操作流程：各过程的关键活动与输出

1. 计划过程：制定《软件合格审定计划》（PSAC）、《软件开发计划》（SDP）、《软件验证计划》（SVP）等。关键活动包括：确定软件等级（A/B/C/D）、定义生命周期环境、规划标准与工具。
2. 开发过程：包括需求开发、设计、编码、集成。输出包括：软件需求数据、设计描述、源代码、集成文档。关键活动是建立需求追溯性（系统需求↔软件需求↔设计↔代码↔测试）。
3. 验证过程：通过评审、分析、测试三种方法验证需求、设计与代码。输出包括：验证结果、测试用例、测试报告。关键活动是确保“需求覆盖率”和“结构覆盖率”（如MC/DC）。
4. 配置管理过程：包括配置标识、基线管理、变更控制、状态记录、归档与发布。输出包括：配置索引、问题报告（PR）、变更记录。关键活动是确保所有数据项的唯一标识与版本控制。
5. 质量保证过程：独立于开发团队，监督过程符合性。输出包括：质量保证记录、不符合项报告。关键活动是进行过程审计、产品审计，并确认“符合性评审”的完成。

3.2.3 实战场景：一个变更请求的完整流转

假设在开发过程中，发现某软件需求存在歧义。变更流程如下：

• 开发人员提交问题报告（PR），描述问题。
• 配置管理团队评估影响，将PR纳入变更控制委员会（CCB）评审。
• CCB批准变更后，开发团队修改需求文档和代码，并更新追溯性矩阵。
• 验证团队重新执行相关测试，并补充必要的回归测试。
• 质量保证团队审计整个变更过程，确认符合计划要求。
• 配置管理团队更新基线，发布新版本数据。

这个闭环展示了五大过程的协同：计划定义了变更流程，开发执行变更，验证确认正确性，配置管理控制版本，质量保证监督合规性。

3.2.4 常见误区与总结

3.3 附录A的结构与应用：目标-活动-数据-证据的映射矩阵

3.3.1 核心原理：附录A是符合性审查的“地图”

附录A（Annex A）是DO-178C的核心工具，它将五大过程的目标、活动、数据输出和验证方法组织成10张表格（表A-1至A-10）。每张表对应一个过程或子过程，每行定义了一个“目标”，并列出适用的软件等级（A/B/C/D）、建议的活动、输出数据以及验证方法。审查员依据附录A逐项检查目标是否满足。

3.3.2 判断方法：如何阅读附录A表格？

以表A-3（软件需求过程）为例，其目标包括“软件需求被开发”、“软件需求被验证”等。每项目标下，表格会列出：

• 适用性：哪些软件等级必须满足该目标（如A级必须满足所有目标，D级可能豁免部分目标）。
• 输出数据：如“软件需求数据”、“需求评审记录”。
• 验证方法：如“评审”、“分析”、“测试”。

审查时，需逐项核对：是否产生了所需数据？数据是否经过验证？验证结果是否记录？

3.3.3 案例拆解：A级软件的目标满足策略

对于A级软件（如飞控软件），附录A要求满足所有目标，且结构覆盖率需达到MC/DC级别。这意味着：

• 需求验证必须包含“基于需求的测试”和“鲁棒性测试”。
• 代码验证必须进行“结构覆盖率分析”，并补充测试用例以覆盖未达标的条件/决策。
• 所有验证活动必须形成书面记录，并经过独立评审。

一个典型的A级项目，其附录A符合性矩阵可能包含数百个目标，每个目标对应一组数据包。审查员会随机抽样检查数据包，验证其完整性与一致性。

3.3.4 常见误区与总结

综上所述，DO-178C的术语与体系结构构成了一个严密的逻辑闭环：系统定义软件需求，软件生命周期通过五大过程实现需求，过程产生数据，数据经验证成为证据，附录A则提供了目标与证据的映射框架。掌握这一体系，是制定有效合规策略、避免“文档驱动”陷阱、实现高效适航认证的关键。在实际项目中，建议团队在启动阶段即建立“目标-数据-证据”的追踪矩阵，并定期对照附录A进行差距分析，确保过程执行与目标满足始终同步。