4、DO-178C核心概念：软件生命周期、数据项、目标、活动与证据
DO-178C（机载系统与设备合格审定中的软件考虑）是民用航空机载软件开发的黄金标准。要真正理解并落地这一标准，首先必须穿透其术语体系。许多团队在实施过程中感到困惑，往往不是因为技术难度，而是因为对“目标（Objective）”、“活动（Activity）”、“数据项（Data Item）”和“证据（Evidence）”之间的逻辑关系缺乏整体认知。本章将逐一拆解这些核心概念，并揭示它们如何共同构成一个闭环的适航论证体系。
4.1 软件生命周期：从“编码”到“全流程治理”的思维转变
核心原理
DO-178C 将软件生命周期定义为从系统需求分配到软件退役的完整过程。它并非简单的瀑布式阶段划分，而是一个包含计划、开发、验证、配置管理、质量保证和适航联络的综合性框架。标准明确要求组织必须定义“软件生命周期环境”，包括编译工具、测试工具、操作系统等，并对其加以控制。生命周期模型的选择（如瀑布、增量、迭代）本身不是目标，关键在于该模型必须能支持所有适用的目标（Objectives）被满足，且能产生相应的数据项。
判断方法与操作流程
在实际项目中，选择生命周期模型时需考虑以下因素：
- 项目规模与复杂度：大型项目可能需要增量开发以降低集成风险。
- 需求稳定性：需求频繁变更时，迭代模型更合适，但需加强变更管理。
- 审定互动：与局方（如 FAA、EASA、CAAC）的沟通节点应嵌入生命周期中。
一个典型的 DO-178C 生命周期流程包含以下阶段：
- 计划阶段：编写 PSAC（软件合格审定计划），定义生命周期、标准、工具和团队职责。
- 需求开发：将系统需求细化为高层软件需求（HLR）和低层软件需求（LLR）。
- 设计阶段：将 LLR 转化为软件架构和详细设计。
- 编码阶段：依据编码标准生成源代码。
- 集成与验证：执行测试、审查和分析，确保满足需求。
- 配置管理与质量保证：贯穿全程，确保可追溯性和过程合规。
案例拆解：某飞控系统项目的生命周期裁剪
某项目开发一款飞行控制计算机，DAL A 级。团队最初计划采用纯瀑布模型，但发现系统需求在首轮评审后变更率高达 30%。若坚持瀑布模型，将导致大量返工。经过分析，团队决定采用“增量开发 + 同步验证”的生命周期模型：将功能划分为三个增量（俯仰控制、滚转控制、偏航控制），每个增量独立完成从需求到验证的闭环。关键操作如下：
- 在 PSAC 中明确描述增量划分策略，并说明每个增量如何覆盖所有 A-1 至 A-7 目标。
- 为每个增量建立独立的配置管理基线。
- 在增量边界设置评审点，邀请局方代表参与。
结果：项目总周期缩短了 20%，且因需求变更导致的返工量减少了 60%。复盘经验：生命周期模型不是一成不变的，但任何裁剪都必须以“目标覆盖”为前提，并在 PSAC 中提前声明。
4.2 目标（Objective）：适航审定的“检查清单”
核心原理
目标是 DO-178C 的核心评估单元。标准附录 A 的表 A-1 至 A-7 定义了不同软件等级（A、B、C、D）下必须满足的目标。每个目标都有对应的“适用性”和“输出”。例如，表 A-1 中的目标 1 是“高层软件需求被开发”，其输出是“高层软件需求数据项”。目标并非抽象原则，而是可验证的具体要求。满足目标的方式可以是审查、分析、测试或组合。
判断方法与操作流程
理解目标的关键在于区分“目标”与“活动”：
| 维度 | 活动（Activity） | 目标（Objective） |
|---|---|---|
| 导向 | 过程导向（做什么） | 结果导向（证明什么） |
| 示例 | 编写代码、执行测试 | 代码与设计一致、测试覆盖需求 |
| 验证方式 | 项目计划跟踪 | 审查、分析、测试 |
| 输出 | 数据项（中间产物） | 证据（符合性证明） |
操作流程上，团队应：
- 在项目启动时，依据软件等级从附录 A 中筛选适用目标。
- 为每个目标分配责任人和验证方法。
- 在项目执行中，通过“目标追踪矩阵”持续监控达成状态。
案例拆解：DAL C 级项目的目标裁剪
一个 DAL C 级的显示控制单元项目，团队发现附录 A 中部分目标标注为“不适用”。例如，表 A-2 中关于“基于需求的测试覆盖”在 C 级下要求降低。团队在 PSAC 中明确列出了裁剪理由，并附上了与局方的沟通记录。关键操作：
- 逐条对照附录 A，标记每个目标的“适用/不适用”。
- 对于不适用目标，提供书面论证（如“该功能无安全性影响”）。
- 在最终符合性总结（FAR）中，再次确认裁剪的合理性。
复盘经验：目标裁剪是高风险行为，必须基于充分的安全性评估，且不能为了减少工作量而随意裁剪。
4.3 数据项（Data Item）：软件开发的“有形资产”
核心原理
数据项是 DO-178C 要求产生的文档或记录，它们是目标达成的载体。标准将数据项分为五类：计划类（如 PSAC）、标准类（如编码标准）、开发类（如需求、设计、代码）、验证类（如测试用例、测试结果）、管理类（如配置管理记录、问题报告）。数据项并非简单的“文档”，其内容、格式和评审要求都有明确规定。
判断方法与操作流程
创建数据项时，应遵循以下原则：
- 完整性：数据项应包含满足目标所需的全部信息。
- 可追溯性：数据项之间应建立双向追溯关系（如需求到设计、设计到代码）。
- 受控性：数据项必须纳入配置管理，变更需经过正式评审。
常见的数据项清单如下：
| 类别 | 典型数据项 | 主要用途 |
|---|---|---|
| 计划类 | PSAC、验证计划、配置管理计划 | 定义项目方法和资源 |
| 标准类 | 需求标准、设计标准、编码标准 | 确保工程活动的一致性 |
| 开发类 | 系统需求、软件需求、架构设计、源代码 | 描述软件的功能和实现 |
| 验证类 | 测试计划、测试用例、测试结果、审查记录 | 证明软件满足需求 |
| 管理类 | 配置索引、问题报告、变更记录 | 记录项目状态和变更历史 |
实战场景：数据项之间的追溯性断裂
某项目在审查中发现，一条低层需求（LLR-102）无法追溯到任何高层需求（HLR）。经分析，原因是需求工程师在编写 LLR 时遗漏了追溯关系。若不修复，将导致表 A-3 中的“需求追溯性”目标无法满足。团队采取的步骤：
- 使用需求管理工具（如 DOORS）生成追溯性报告。
- 定位 LLR-102 的来源，发现其源自一次客户变更请求。
- 补充 HLR 条目，并更新追溯矩阵。
- 重新执行受影响的设计和测试活动。
复盘经验：追溯性不是“事后补录”，而应在开发过程中同步维护。建议在每日构建中自动检查追溯性完整性。
4.4 证据（Evidence）：让“符合性”可被证明
核心原理
证据是证明目标已满足的客观信息。它可以是审查记录、测试报告、分析结果或工具输出。证据必须与目标直接关联，且具有可追溯性。DO-178C 强调“客观证据”，即证据应能独立验证，而非仅依赖个人声明。例如，对于“代码与设计一致”这一目标，证据可以是代码审查记录、静态分析报告或基于模型的验证结果。
判断方法与操作流程
生成证据时，需注意以下要点：
- 充分性：证据应覆盖目标的所有方面。例如，测试证据需包含测试环境描述、输入数据、预期结果、实际结果和结论。
- 独立性：对于 DAL A/B 级，验证活动需由独立于开发的人员执行。
- 可读性：证据应能被局方审查人员理解，避免过度依赖内部工具。
一个完整的证据链通常包括：
目标（Objective） → 验证活动（Verification Activity） → 数据项（Data Item） → 证据（Evidence）案例拆解：测试证据的“闭环”构建
某项目需要证明“软件满足所有高层需求”。团队构建了以下证据链：
- 从需求管理工具导出 HLR 清单。
- 为每条 HLR 设计测试用例，并记录测试用例与 HLR 的追溯关系。
- 在目标硬件上执行测试，记录实际输出。
- 生成测试报告，包含测试环境（硬件版本、软件版本、工具版本）、执行结果和结论。
- 将测试报告与测试用例、需求清单共同提交给局方审查。
结果：局方在审查中要求补充“测试环境与生产环境的差异分析”。团队补充了差异说明，并论证了差异不影响测试有效性。复盘经验：证据不是“越多越好”，而是“越精准越好”。提前与局方沟通证据格式，可避免后期返工。