什么是 DO-178C？
DO-178C 是由美国航空无线电技术委员会（RTCA）发布的国际标准，全称为《机载系统与设备合格审定中的软件考虑》。它为航空机载软件的开发、验证和审定提供了一套系统化的指导框架，是全球民用航空领域最权威的软件适航标准。
该标准被美国联邦航空管理局（FAA）、欧洲航空安全局（EASA）以及中国民用航空局（CAAC）等全球主要适航当局所采纳，作为航空软件适航审查的核心依据。任何安装在民用飞机上的软件——从飞行控制计算机到座舱娱乐系统——都需要依据 DO-178C 进行开发和认证。
DO-178C 的核心理念
- 基于目标（Objective-based）而非规定性方法
- 软件严格度与系统安全性影响挂钩
- 强调过程的可追溯性与可重复性
- 独立验证与确认（IV&V）的分离原则
- 全生命周期质量保证与配置管理
- 通过软件计划确保合规可预期
发展历程
DO-178 初版发布
随着数字航空电子系统的兴起，业界首次意识到需要专门的软件适航标准。RTCA 发布了 DO-178 的最初版本。
DO-178A 发布
第一次重大修订，引入了更结构化的软件开发和验证过程。
DO-178B 发布
里程碑式版本。引入五级软件保证等级（DAL A-E）和基于目标的合规方法，成为此后近 20 年全球航空软件认证的事实标准。
启动 DO-178C 修订
RTCA SC-205 和 EUROCAE WG-71 联合启动修订工作，旨在应对模型驱动开发、面向对象技术和形式化方法等新技术挑战。
DO-178C 正式发布
连同四份技术补充文件一并发布，标志着航空软件标准进入新时代。
软件设计保证等级（DAL）
DO-178C 的核心概念之一是设计保证等级（Design Assurance Level, DAL）。软件的 DAL 由系统安全性评估（SSA）过程确定，取决于该软件失效对飞机和乘客可能造成的最严重后果。DAL 越高，要求完成的目标越多、验证越严格。
| 等级 | 失效影响 | 失效概率要求 | 目标数 | 独立性要求 | 典型应用 |
|---|---|---|---|---|---|
| Level A | 灾难性（Catastrophic） | ≤ 10⁻⁹ / 飞行小时 | 71 | 最高独立性 | 飞行控制、自动驾驶、发动机控制 FADEC |
| Level B | 危险/严重（Hazardous） | ≤ 10⁻⁷ / 飞行小时 | 69 | 高独立性 | GPS导航、电气管理 |
| Level C | 重大（Major） | ≤ 10⁻⁵ / 飞行小时 | 62 | 中等独立性 | 通信系统、气象雷达 |
| Level D | 轻微（Minor） | ≤ 10⁻³ / 飞行小时 | 26 | 基本独立性 | 乘客广播、舱内照明控制 |
| Level E | 无影响（No Effect） | 无要求 | 0 | 无要求 | 座舱娱乐（IFE）、部分维护辅助工具 |
软件生命周期过程
DO-178C 定义了三类过程共同构成完整的软件生命周期：开发过程（产出软件产品）、整体过程（贯穿全生命周期的支撑活动）和验证过程（确认正确性）。
系统需求
来自系统级分配
(ARP 4754A)
软件需求
高层需求
HLR
软件设计
低层需求
LLR + 架构
编码
源代码
实现
集成
软件构建
与集成
验证
评审、分析
与测试
认证联络
SOI 审查
合规证明
核心过程详解
软件计划过程
制定五份关键计划文档（PSAC、SDP、SVP、SCMP、SQAP），定义项目的开发策略、工具、标准和合规路径。这是认证联络的起点。
软件需求过程
将系统需求分配转化为高层需求（HLR），确保需求准确、一致、可验证、可追溯。需求是一切后续活动的基础。
软件设计过程
将 HLR 细化为低层需求（LLR）和软件架构，描述数据流、控制流和组件接口。设计必须满足所有高层需求。
编码过程
依据 LLR 和编码标准编写源代码。需遵循编码规则，确保代码可读、可维护，并且与低层需求一致。
集成过程
将编译后的对象代码加载到目标硬件上，完成软件-硬件集成，并确认可执行目标代码与开发环境中的一致性。
验证过程
通过评审、分析和测试三种手段验证每一级产物。包括需求验证、设计验证、代码验证和集成测试，覆盖结构覆盖率分析。
配置管理过程
对所有软件生命周期数据进行标识、基线化、变更控制和状态记录。确保任何已批准的配置项都可追溯和复现。
质量保证过程
独立于开发团队，对过程合规性和产物符合性进行持续监控审计，发现问题并跟踪至关闭。
认证联络过程
与适航当局（DER/ODA/EASA）保持沟通，提交 PSAC，参加阶段审查（SOI），最终提交软件完成摘要（SAS）和 SCI。
关键目标（Objectives）示例
DO-178C 采用基于目标的合规框架。标准中 Annex A 的表格列出了所有目标，并按 DAL 标注适用性和独立性要求。以下列举部分核心目标：
A-1
软件需求与系统需求的一致性与可追溯性
A-2
高层需求的准确性与一致性已得到验证
A-3
HLR 符合软件需求标准
A-4
HLR 可追溯到系统需求
A-5
算法的准确性和行为已验证
A-6
低层需求与高层需求的一致性
A-7
源代码符合 LLR 和架构
Table A-6
基于需求的测试覆盖已完成
Table A-7
结构覆盖率（SC/DC/MC/DC）达标
结构覆盖率等级对照
- Level A — MC/DC（修改条件/判定覆盖）
- Level B — DC（判定覆盖）
- Level C — SC（语句覆盖）
- Level D — 无结构覆盖要求
四大技术补充文件
DO-178C 的重要创新之一是引入了四份独立的技术补充文件，用于指导特定技术领域的软件开发与验证。当项目采用了相关技术时，应在 PSAC 中声明适用的补充文件。
定义了开发和验证工具的鉴定准则和等级（TQL 1-5），确保工具不会在开发过程中引入未检测到的错误。
为 Model-Based Development & Verification（MB-D&V）提供指南，涵盖模型的开发标准、仿真验证和模型到代码的可追溯性。
针对 OOT（面向对象技术）的特有风险（如继承、多态、动态分派）提供额外的验证目标和指南。
允许使用形式化规格和形式化证明作为验证手段的替代或补充，在某些场景下可替代部分测试活动。
DO-178C vs DO-178B
DO-178C 并非对 DO-178B 的颠覆，而是一次务实的演进。核心框架和 DAL 体系保持不变，但在关键领域做出了重要改进。
DO-178B (1992)
- 无工具鉴定的独立标准
- 不覆盖模型驱动开发
- 未考虑面向对象技术
- 不支持形式化方法作为替代验证
- 参数数据项（PDI）处理不明确
- "活动"（Activities）导向的描述风格
- 工具鉴定仅在附录中简要提及
DO-178C (2011)
- DO-330 专门处理工具鉴定
- DO-331 提供 MBD&V 完整指南
- DO-332 覆盖 OOT 特有挑战
- DO-333 允许形式化方法替代测试
- 明确 PDI 处理要求
- "目标"（Objectives）导向的表述风格
- 更灵活、可扩展的技术补充机制
认证联络与审查阶段
DO-178C 的合规不是自我声明，而需通过与适航当局的正式认证联络过程来证明。这一过程通常围绕四个软件审查节点（SOI）展开：
SOI #1
计划审查
审查 PSAC、SDP、SVP、SCMP、SQAP 等计划文件的完整性和合理性。
SOI #2
开发审查
审查需求、设计和编码过程产物，确认过程执行与计划一致。
SOI #3
验证审查
审查测试用例、测试结果、覆盖率分析和问题报告。
SOI #4
最终审查
审查 SAS（软件完成摘要）、SCI（软件配置索引）和 SECI，确认所有目标已满足。
关键交付物清单
- PSAC — 软件合格审定计划
- SDP — 软件开发计划
- SVP — 软件验证计划
- SCMP — 软件配置管理计划
- SQAP — 软件质量保证计划
- SRS — 软件需求规格
- SDD — 软件设计描述
- SAS — 软件完成摘要
- SCI — 软件配置索引
- SECI — 软件生命周期环境配置索引
- PR / SCR — 问题报告 / 软件变更请求
常见问题
DO-178C 是法律法规吗？
不是。DO-178C 本身是一份行业指南文件（Guidance），但被 FAA（通过 AC 20-115D）和 EASA（通过 AMC 20-115D）等适航当局作为可接受的符合性方法（Acceptable Means of Compliance）引用，因此在实际认证中具有准强制性。
DAL 等级由谁决定？
DAL 由系统安全性评估过程（参照 ARP 4754A / ARP 4761）确定，并分配给相应的软件功能。系统工程师和安全工程师通过功能危险评估（FHA）和故障树分析（FTA）等方法确定每个功能的失效影响等级。
Level E 的软件需要做什么？
DO-178C 对 Level E 软件不设任何目标。但开发者仍需在 PSAC 中声明该软件为 Level E，并通过配置管理标识它。适航当局可能会审查 Level E 的判定是否合理。
什么是 MC/DC？
MC/DC（Modified Condition / Decision Coverage，修改条件/判定覆盖）是 DO-178C 对 Level A 软件要求的最严格结构覆盖准则。它要求证明每个条件都能独立影响判定结果，是航空软件测试中最具挑战性的覆盖指标之一。
开源软件可以用在机载系统中吗？
理论上可以，但必须满足 DO-178C 对"先前开发的软件"（Previously Developed Software）的所有要求，包括完整的需求追溯、代码审查、覆盖率分析等。这通常意味着需要投入与重新开发相当甚至更多的验证工作。