DO-178 将软件适航要求抽象为三大核心元素：适航目标（Objectives）、完成这些目标所需的活动（Activities）、用于证明目标达成的数据（Software Life Cycle Data）。这三者共同构成了软件
一、适航目标（Objectives）：体系的"指南针"
适航目标是软件必须达成的最终状态或结果，是整个体系的起点和核心。其本质是"基于风险的安全性要求"，具体特征包括：
-
分级性：目标的数量和严格程度与软件等级（A-E）强绑定。例如：
- A级软件需达成71项目标（如"需求100%可验证""测试覆盖MC/DC""无未修复关键缺陷"）；
- E级仅需达成16项基础目标（如"需求文档完整""代码通过基本功能测试"）。
-
跨阶段覆盖：目标贯穿需求、设计、编码、测试、集成等全生命周期，而非单一阶段。例如"需求可追溯性"目标，要求从系统级需求到软件低级需求、再到代码和测试用例，形成双向追溯链。
-
安全性导向：所有目标的核心是"防止软件失效导致航空事故"。例如A级软件的"容错性"目标，要求即使出现单点故障，软件仍能维持安全状态。
二、活动（Activities）：达成目标的"执行路径"
活动是为实现适航目标而开展的具体过程和操作，是连接目标与结果的桥梁。其特点是"针对性"和"可操作性"：
-
与目标一一对应：每个目标都有明确的活动支撑。例如，为达成"需求无歧义"目标，活动包括"需求评审（需系统工程师、软件工程师、审定代表参与）""需求原型验证""自然语言需求转化为形式化描述（A级）"。
-
覆盖全生命周期：活动从"计划阶段"（制定软件审定计划）开始，到"维护阶段"（变更影响分析）结束。例如：
- 设计阶段活动："架构分层设计""模块接口定义与评审""设计与需求的一致性检查"；
- 测试阶段活动："测试用例设计（基于需求和代码结构）""测试环境校准""回归测试（每次代码修改后）"。
-
强度随等级递增：高等级软件（A/B）的活动更严格。例如，A级软件的测试活动需包含"语句覆盖、分支覆盖、MC/DC覆盖的自动化分析""故障注入测试（模拟硬件失效对软件的影响）"，而D/E级仅需"功能黑盒测试"。
三、软件生命周期数据（SLCD）：证明目标达成的"证据链"
SLCD是活动执行的可追溯记录，是向适航当局证明"目标已达成"的唯一依据。其核心作用是"可验证性"和"可重现性"：
-
数据类型全覆盖：SLCD包括22类关键文档和记录，例如：
- 计划类：《软件审定计划（PSAC）》《软件验证计划（SVP）》；
- 需求类：《软件需求规格说明（SRS）》《需求追溯矩阵（RTM）》；
- 测试类：《测试用例集》《测试报告（含覆盖度分析）》《缺陷追踪记录》；
- 配置类：《配置项清单》《变更申请与审批记录》。
-
数据需满足"审定可接受性"：SLCD不仅要"存在"，更要"可信"。例如，测试报告需包含"测试环境参数（如硬件版本、操作系统）""测试人员资质""测试用例与需求的映射关系"，确保审定人员可复现测试过程。
-
与活动同步生成：数据不是"事后补录"，而是活动的自然产物。例如，代码评审活动需同步生成《评审记录》（含评审人员、发现的问题、整改结果），若缺失该记录，即使实际开展了评审，也视为活动未有效执行。
三者的闭环关系：目标→活动→数据→目标验证
- 目标驱动活动：先明确"要达成什么"（目标），再规划"怎么做"（活动）；
- 活动产生数据：活动的每一步都留下记录（SLCD），证明"做了什么"；
- 数据验证目标：通过审查SLCD，确认活动是否按要求执行、是否达成目标，最终形成"目标是否满足"的结论。
这种闭环确保了软件适航认证的"可追溯性"和"客观性"------避免"凭经验判断"，而是通过"目标-活动-数据"的刚性逻辑，让软件安全性"有证可查、有据可依"。
DO-178B/C的演进（如C版本对模型驱动开发、形式化方法的支持），本质上是对"活动"和"SLCD"的扩展（例如新增模型验证活动、模型与代码一致性数据），但"目标-活动-数据"的核心框架始终未变，这正是标准的稳定性与适应性的体现。