1. 航空航天嵌入式软件验证导论

航空航天嵌入式软件与普通消费电子软件最大的区别，不在于代码规模，而在于它一旦失效，后果可能是机毁人亡。因此，这类软件的“验证”不是开发完成后的可选动作，而是贯穿需求、设计、编码、集成、测试全过程的强制性工程活动。本章先厘清验证的定义与目标，再说明 DO-178C 与 ECSS 两大标准体系对验证的要求，最后给出全流程验证的总体框架与关键活动。

1.1 验证的定义与目标

在航空航天语境下，验证（Verification）回答的是“我们是否正确地构建了产品”，即确认各层级实现是否满足其上层输入要求；而确认（Validation）回答的是“我们是否构建了正确的产品”，即最终系统是否满足用户与适航方的真实需求。两者常被合称 V&V，但目标不同，不能互相替代。

验证的核心目标可归纳为三点：一致性——需求、设计、代码、测试用例之间可双向追溯，无遗漏、无多余；正确性——在规定的运行环境与边界条件下，软件行为符合预期；可接受性——有客观证据表明软件满足适航或任务安全等级要求，能够被审定方接受。

以某型飞控软件的高度保持功能为例，其顶层需求为“在 500～12000 m 高度范围内，高度偏差超过 ±30 m 时，应在 2 s 内输出修正指令”。验证工作就要把这条需求逐层分解：设计层对应控制律与状态机，代码层对应具体函数与变量，测试层对应激励输入、预期输出与容差判据。只有每一层都能追溯到这条需求，且测试结果落在容差内，验证才算闭环。

1.2 适航标准对验证的要求

DO-178C 是机载软件适航审定的核心标准，它按软件等级（A～E）规定目标数量。以最高等级 A（灾难性失效）为例，共 71 个目标，其中与验证直接相关的包括：需求可追溯性、代码符合设计、测试覆盖结构、独立验证等。DO-178C 强调“目标导向”，不规定具体方法，但要求提供生命周期数据作为符合性证据。

ECSS（欧洲空间标准化合作组织）标准体系中的 ECSS-E-ST-40C 与 ECSS-Q-ST-80C 则面向航天器软件，按关键类别（A～D）划分验证严格度。与 DO-178C 相比，ECSS 更强调验证阶段与评审节点的绑定，例如在 PDR、CDR、QR 等节点必须提交相应验证证据。

两者共同点在于：验证不是一次性活动，而是与开发过程并行、可追溯、可审计的系统工程。

1.3 全流程验证总体框架与关键活动

全流程验证可理解为一条从需求到证据的“验证链”。左侧是输入（需求、设计、代码），右侧是输出（测试结果、覆盖报告、符合性证据），中间是各阶段验证活动。关键活动包括：需求验证、设计验证、代码验证、单元与集成测试、系统测试、覆盖分析、独立验证与确认。

以某型无人机飞控软件为例，其验证链可具体化为：需求评审确认高度保持需求无歧义；设计评审确认控制律与状态机可覆盖所有高度区间；代码走查确认无未初始化变量；单元测试对高度偏差计算函数注入边界值（±29 m、±30 m、±31 m）；集成测试验证传感器输入到舵机输出的完整链路；系统测试在半物理仿真环境中模拟 500 m 与 12000 m 两个边界高度，记录修正指令输出时间；最后进行结构覆盖分析，确认语句、分支、MC/DC 覆盖率达到等级要求。

需要强调的是，验证活动不是线性串行，而是与开发迭代并行。例如代码验证发现问题后，可能回退到设计验证甚至需求验证。因此，验证计划必须定义清晰的进入条件、退出条件与问题处理流程。

1.4 关键活动落地要点

在实际项目中，验证活动能否落地，取决于三个要素：可追溯性、独立性、客观证据。可追溯性要求每条需求都有唯一标识，并与设计、代码、测试用例建立双向链接；独立性要求验证人员不隶属于开发团队，尤其对等级 A～C 软件；客观证据要求测试结果可复现，包括输入数据、环境配置、预期输出与实际输出。

以高度保持功能为例，其验证用例可设计为：输入高度偏差 +31 m，预期在 2 s 内输出修正指令，实际输出时间记录为 1.6 s，则判定通过；若输出时间为 2.3 s，则判定失败，需回溯控制律参数或状态机逻辑。这种“输入—预期—实际—判定”的闭环，正是验证证据的基本单元。

综上，航空航天嵌入式软件验证是一项以标准为依据、以追溯为纽带、以证据为输出的系统工程。理解验证的定义与目标，掌握 DO-178C 与 ECSS 的核心要求，建立全流程验证框架，是后续各章节展开具体验证技术的基础。