4、DO-178C标准概述：DO-178C的由来、与DO-178B的差异、标准结构、目标（Objectives）与符合性方法
DO-178C（Software Considerations in Airborne Systems and Equipment Certification）是民用航空机载软件适航认证的基石性标准，由RTCA（Radio Technical Commission for Aeronautics）第180委员会（SC-180）与EUROCAE WG-71联合制定，于2011年12月正式发布，取代了自1992年起沿用了近二十年的DO-178B。该标准并非一次简单的修订，而是针对过去二十年中软件工程方法（尤其是模型化开发、形式化方法、基于工具的验证）的飞速发展，对机载软件研制与适航审查框架进行的系统性重构。本章将深入剖析DO-178C的演进动因、核心结构、目标体系以及符合性方法，帮助读者建立对适航认证标准的整体认知框架。
4.1 DO-178C的由来：从DO-178B到DO-178C的演进动因
4.1.1 核心原理：为什么需要替代DO-178B
DO-178B自1992年发布以来，为全球民航机载软件适航认证提供了统一框架。然而，随着软件工程技术的飞速发展，DO-178B的局限性日益凸显。首先，DO-178B对模型化开发（Model-Based Development）和自动代码生成（Automatic Code Generation）缺乏明确指导，导致使用这些技术的项目在适航审查时面临巨大的解释成本。其次，DO-178B对形式化方法（Formal Methods）的认可度不足，尽管形式化方法在数学上能提供更强的正确性保证。第三，DO-178B对工具鉴定（Tool Qualification）的准则不够清晰，尤其是对基于工具的验证（如自动测试用例生成）缺乏可操作的判定标准。第四，DO-178B对面向对象技术（OOT）和基于组件的开发（CBD）的支持不足，这些技术在现代航空软件中已广泛使用。
此外，DO-178B在目标（Objectives）的表述上存在模糊性，导致不同审查代表（DER，Designated Engineering Representative）对同一目标的判定标准不一致。例如，DO-178B中关于"需求的可验证性"（Verifiability of Requirements）和"源代码与低层需求的一致性"（Consistency between Source Code and Low-Level Requirements）等目标，缺乏明确的度量方法和证据要求。这种模糊性在全球化适航合作的背景下，造成了跨地区审查的协调困难。
4.1.2 判断方法：DO-178C的制定过程与关键决策
DO-178C的制定始于2004年，RTCA SC-180和EUROCAE WG-71联合工作组历时七年完成。制定过程中，工作组广泛征集了来自飞机制造商（如波音、空客）、发动机供应商（如GE航空、罗尔斯·罗伊斯）、机载系统供应商（如霍尼韦尔、柯林斯宇航）、适航当局（FAA、EASA）以及工具供应商（如MathWorks、ANSYS）的意见。关键决策包括：
- 保持框架连续性：DO-178C保留了DO-178B的五个过程（计划、开发、综合、配置管理、质量保证）和五个软件等级（A-E）的基本框架，以降低行业迁移成本。
- 引入技术补充文件：DO-178C不再将模型化开发、形式化方法、工具鉴定和面向对象技术的内容直接写入主标准，而是通过四个技术补充文件（Technical Supplements）分别阐述，即DO-331（模型化开发）、DO-332（面向对象技术）、DO-333（形式化方法）和DO-330（工具鉴定）。
- 强化目标的可判定性：DO-178C对每个目标（Objective）都给出了更明确的"输出产物"（Output）和"符合性证据"（Compliance Evidence）要求，减少了审查中的主观判断空间。
- 引入"数据项"（Data Item）概念：DO-178C将DO-178B中的"软件生命周期数据"（Software Life Cycle Data）细化为具体的数据项，如"软件需求数据"（Software Requirements Data）和"软件设计数据"（Software Design Data），使数据间的追溯关系更加清晰。
4.1.3 案例拆解：某飞控系统从DO-178B迁移到DO-178C的决策过程
某航空电子系统供应商在2013年启动了一个新型飞控计算机项目，目标适航等级为A级。项目初期，团队计划沿用DO-178B流程，但在与FAA审查代表进行预审会议时，审查代表建议采用DO-178C，理由如下：
- 项目计划使用Simulink进行模型化开发，并自动生成C代码，DO-178C的DO-331补充文件提供了明确的模型开发目标和验证方法，而DO-178B对此无明确指导。
- 项目计划使用形式化方法验证部分安全关键算法（如飞行包线保护逻辑），DO-178C的DO-333补充文件认可了形式化方法的符合性证据。
- 项目计划使用MathWorks的Embedded Coder进行自动代码生成，DO-178C的DO-330工具鉴定框架提供了更清晰的工具鉴定等级（TQL）划分。
经过评估，项目组决定采用DO-178C，并制定了详细的迁移计划。迁移过程中，团队发现DO-178C对"模型验证"（Model Verification）的目标要求比DO-178B对"手工代码验证"的要求更为严格，例如需要额外进行模型覆盖率分析（Model Coverage Analysis）。为此，项目组增加了模型测试用例的投入，最终在审查中顺利通过。这一案例表明，DO-178C的采用不仅是标准版本的升级，更是对开发流程和验证策略的重新设计。
4.1.4 常见误区与总结复盘
常见误区一：认为DO-178C只是DO-178B的"修订版"，只需在原有流程上增加少量文档即可。实际上，DO-178C对目标的可判定性、数据项的完整性、以及工具鉴定的严格性都有显著提升，需要重新审视整个开发流程。
常见误区二：认为DO-178C只适用于使用模型化开发或形式化方法的项目。实际上，即使采用传统的手工编码方式，DO-178C的目标体系也适用于所有项目，只是符合性方法的选择有所不同。
常见误区三：忽视DO-330工具鉴定的影响。DO-178C将工具鉴定独立为一份标准，意味着所有用于开发或验证的工具都需要按照DO-330进行评估，这可能导致工具鉴定成本显著增加。
经验提醒：在项目启动初期，应尽早确定采用DO-178C还是DO-178B，并完成差距分析（Gap Analysis）。差距分析应覆盖过程、工具、人员技能和文档模板四个方面，确保团队对标准变化有充分准备。
4.2 DO-178C与DO-178B的差异分析
4.2.1 核心原理：差异的本质
DO-178C与DO-178B的差异并非简单的条款增删，而是对"如何证明软件满足适航要求"这一核心问题的重新定义。DO-178B侧重于"过程保证"（Process Assurance），即通过遵循规定的开发流程来间接保证软件质量；而DO-178C在保留过程保证的基础上，更强调"目标保证"（Objective Assurance），即通过明确每个目标的输出产物和符合性证据，使软件质量的证明更加直接和可审计。
| 对比维度 | DO-178B（1992） | DO-178C（2011） | 关键影响 |
|---|---|---|---|
| 目标数量与独立性 | 66个目标，独立性要求相对模糊 | 71个目标，独立性要求按等级明确划分 | A级项目需额外满足5个独立目标 |
| 模型化开发 | 无明确指导 | DO-331补充文件，定义模型开发与验证目标 | 模型可作为需求或设计数据 |
| 形式化方法 | 仅提及"形式化方法可用于验证" | DO-333补充文件，定义形式化方法的适用场景和证据 | 形式化方法可作为分析证据 |
| 工具鉴定 | 工具鉴定准则分散在正文中 | DO-330独立标准，定义TQL1-5级 | 工具鉴定成本和时间显著增加 |
| 面向对象技术 | 无明确指导 | DO-332补充文件，定义OOT的适用性和验证方法 | 支持C++、Ada等OOP语言 |
| 数据项定义 | 统称为"软件生命周期数据" | 细化为具体数据项，如"软件需求数据"、"软件设计数据" | 数据追溯关系更清晰 |
| 参数数据项（PDI） | 未明确 | 引入参数数据项概念，区分代码与数据 | 便于管理配置数据 |
4.2.2 判断方法：如何选择DO-178C还是DO-178B
对于新启动的项目，FAA和EASA已明确要求采用DO-178C。但对于已处于开发中期的项目，是否迁移需要谨慎评估。判断方法如下：
- 项目阶段评估：如果项目已完成需求阶段，且需求文档基于DO-178B格式，迁移成本较高，可考虑继续使用DO-178B（需获得审查方同意）。
- 技术栈评估：如果项目计划使用模型化开发、自动代码生成或形式化方法，强烈建议采用DO-178C，否则审查风险极高。
- 工具链评估：检查现有工具链是否支持DO-178C的符合性证据生成。例如，Simulink的Embedded Coder在DO-178C下需要按照DO-330进行TQL鉴定。
- 审查方沟通：在项目启动前，与适航当局或DER进行正式沟通，确认采用的标准版本和审查预期。
4.2.3 案例拆解：DO-178C目标独立性要求的实际影响
某飞控系统项目在DO-178B下已完成了A级软件的开发，但在迁移到DO-178C时，发现新增的5个独立目标（如"验证过程独立性"、"配置管理过程独立性"等）要求验证团队和开发团队在组织上完全独立。项目组原先的验证工程师隶属于同一部门，无法满足独立性要求。为此，项目组进行了组织架构调整，将验证团队独立为质量部门下属的二级部门，并重新定义了汇报关系。这一调整虽然增加了管理成本，但显著提升了验证过程的客观性。在后续的审查中，审查代表对验证独立性给予了高度评价。
4.2.4 常见误区与总结复盘
关键认知：DO-178C的差异不仅仅是技术层面的，更是管理层面的。组织架构、人员职责、工具链配置都需要重新审视。建议在项目启动时进行一次全面的"DO-178C就绪度评估"，涵盖过程、工具、人员、组织四个维度。
4.3 DO-178C标准结构解析
4.3.1 核心原理：标准的分层架构
DO-178C标准本身分为正文（Main Body）和四个技术补充文件（Technical Supplements）。正文部分定义了适用于所有软件开发的通用目标、过程和符合性方法；技术补充文件则针对特定技术提供额外的目标和指导。这种分层架构的设计初衷是：保持正文的稳定性，同时允许技术补充文件随着技术发展而独立更新。
正文部分共分为六个章节：第1章（引言）、第2章（软件生命周期过程）、第3章（软件计划过程）、第4章（软件开发过程）、第5章（软件综合过程）、第6章（软件生命周期数据）。此外，附录A提供了目标（Objectives）的完整列表，附录B提供了各数据项的说明，附录C提供了工具鉴定相关指导（现已由DO-330替代）。
4.3.2 判断方法：如何阅读和运用标准结构
在实际项目中，建议采用"目标驱动"的阅读方法：首先查阅附录A的目标列表，确定项目软件等级对应的目标集合；然后针对每个目标，回溯到正文相关章节，理解其过程要求；最后，根据项目使用的技术（如模型化开发），查阅对应的技术补充文件。这种方法可以避免在标准正文中迷失方向，提高效率。
4.3.3 案例拆解：某项目使用DO-331补充文件的结构化流程
某飞控系统项目计划使用Simulink进行模型化开发。项目组在制定PSAC（软件适航计划）时，按照DO-331的要求，将模型分为"系统模型"（System Model）和"软件模型"（Software Model）两类。系统模型用于描述系统行为，不直接用于软件生成；软件模型则细分为"需求模型"（Requirements Model）和"设计模型"（Design Model）。项目组为每个模型类型定义了开发目标和验证目标，并建立了模型与源代码之间的追溯关系。在验证阶段，项目组使用Simulink Verification and Validation工具进行模型覆盖率分析，并将覆盖率报告作为符合性证据。这一流程完全遵循DO-331的结构化指导，使审查过程顺畅高效。
4.3.4 常见误区与总结复盘
常见误区：将DO-331、DO-332、DO-333视为独立的标准，而忽略了它们与DO-178C正文的依赖关系。实际上，技术补充文件必须与正文配合使用，正文中的目标仍然适用，补充文件只是增加了额外的目标或修改了部分目标的符合性方法。
4.4 目标（Objectives）与符合性方法
4.4.1 核心原理：目标体系的逻辑
DO-178C共定义了71个目标，按软件等级（A/B/C/D）分配不同的独立性要求。目标分为三类：开发过程目标（Development Process Objectives）、综合过程目标（Integral Process Objectives）和计划过程目标（Planning Process Objectives）。每个目标都对应一个或多个"输出产物"（Output）和"符合性证据"（Compliance Evidence）。例如，目标"高层需求是正确且完整的"（High-Level Requirements are correct and complete）对应的输出是"软件需求数据"（Software Requirements Data），符合性证据是"需求评审记录"和"需求追溯矩阵"。
符合性方法（Means of Compliance）是指为满足目标而采用的技术手段。DO-178C认可的符合性方法包括：评审（Review）、分析（Analysis）、测试（Test）、形式化方法（Formal Methods）和工具鉴定（Tool Qualification）。不同的目标适用于不同的符合性方法，且同一目标可以采用多种方法组合。
4.4.2 判断方法：如何选择符合性方法
选择符合性方法时，需考虑以下因素：
- 目标类型：如"需求可验证性"目标通常采用评审和分析方法；"源代码与低层需求一致性"目标通常采用测试和评审方法。
- 软件等级：A级软件要求更严格的符合性方法，如结构覆盖率分析（MC/DC）是强制要求。
- 技术栈：使用模型化开发时，模型测试和模型覆盖率分析是重要的符合性方法。
- 工具能力：如果使用自动代码生成工具，需按照DO-330进行工具鉴定，工具鉴定本身也是一种符合性方法。
4.4.3 案例拆解：A级飞控软件的目标符合性矩阵
某A级飞控软件项目制定了详细的目标符合性矩阵（Objectives Compliance Matrix），部分示例如下：
| 目标编号 | 目标描述 | 输出产物 | 符合性方法 | 独立性要求 |
|---|---|---|---|---|
| O1.1 | 高层需求正确且完整 | 软件需求数据 | 评审 + 分析 | 独立 |
| O2.2 | 低层需求正确且完整 | 软件设计数据 | 评审 + 分析 | 独立 |
| O3.3 | 源代码与低层需求一致 | 源代码 + 追溯数据 | 测试 + 评审 | 独立 |
| O4.4 | 源代码可验证 | 源代码 + 测试用例 | 测试 + 分析 | 独立 |
| O5.5 | 结构覆盖率满足MC/DC | 覆盖率报告 | 测试 + 分析 | 独立 |
项目组在制定PSAC时，将上述矩阵作为核心附件，并在每个阶段结束时更新符合性状态。审查代表通过检查矩阵，可以快速了解项目的符合性进展，显著提高了审查效率。
4.4.4 常见误区与总结复盘
经验提醒：目标符合性矩阵是项目适航审查的核心文档，建议从项目启动时就建立并持续维护。矩阵应包含目标编号、目标描述、输出产物、符合性方法、独立性要求、当前状态（未开始/进行中/已完成）、证据文件链接等字段。
常见误区：认为"测试"是唯一的符合性方法，忽视了评审和分析的重要性。实际上，对于某些目标（如"需求可验证性"），评审和分析是更有效的符合性方法。过度依赖测试可能导致成本增加且无法覆盖所有目标。