2. 航空软件与系统级验证需求
在航空机载软件研制中，DO-178C 并不只是一份“软件编码规范”，它真正约束的是从系统需求到软件实现、再到验证证据的完整闭环。很多团队在 HIL 系统级验证阶段遇到困难，根源往往不在测试执行本身，而在于系统级需求没有正确分解到软件层级，或者软件层级与系统层级之间的接口定义不完整，导致验证证据无法回溯到最初的安全目标。本节围绕四个关键问题展开：DO-178C 对系统级验证提出了什么要求、软件层级与系统层级如何接口、需求如何分解与追溯、验证证据链如何构建。
一、DO-178C 对系统级验证的要求
DO-178C 将软件生命周期过程分为软件计划、软件开发、软件验证和软件构型管理等过程，并按照 A 到 E 五个软件等级（DAL）规定不同的目标强度。需要特别注意的是：DO-178C 本身不直接规定系统级验证方法，但它要求软件需求必须可追溯到系统需求，且软件验证必须覆盖系统分配给软件的功能与安全目标。系统级验证（如 HIL 台架试验、铁鸟试验、机上地面试验）承担的是“系统需求是否被满足”的确认，而软件层级验证承担的是“软件是否按软件需求正确实现”。两者通过需求追溯关系连接。
以 DAL A 软件为例，DO-178C 表 A-1 至 A-7 中与验证直接相关的目标包括：软件需求可追溯至系统需求、软件架构可追溯至软件需求、源代码可追溯至软件架构、验证结果可追溯至验证目标。这意味着在 HIL 系统级验证中，每一个测试用例都应当能够回答三个问题：它验证的是哪一条系统需求？该需求分配给了哪个软件配置项？测试结果如何证明该需求被满足？
二、软件层级与系统层级的接口
软件层级与系统层级的接口通常体现在三个层面：功能接口、数据接口和时序接口。功能接口描述系统功能如何分配给软件，例如飞行控制律计算、大气数据解算、告警逻辑判断；数据接口描述软件与传感器、作动器、总线之间的数据流，例如 ARINC 429 标签、AFDX 虚拟链路、离散量输入输出；时序接口描述软件周期、采样率、延迟和抖动约束，例如控制律周期 20 ms、传感器采样 50 Hz、端到端延迟不超过 100 ms。
在 HIL 系统级验证中，这些接口通过实时仿真模型和 I/O 板卡被“真实化”。例如，将大气数据计算机的 ARINC 429 输出接入 HIL 仿真机，仿真机按真实标签格式发送高度、空速、迎角等参数，被测软件接收后计算控制指令，再通过模拟量或总线输出到作动器模型。此时，系统级验证观察的是“传感器输入—软件计算—作动器输出”的完整链路，而软件层级验证观察的是软件内部函数、模块和状态机是否正确。
三、需求分解与追溯
需求分解的核心原则是：系统需求不能直接“跳”到源代码，必须经过软件高层需求和软件低层需求两级分解。系统需求描述的是飞机级或系统级功能，例如“当迎角超过失速迎角时，飞行控制计算机应在 100 ms 内输出失速告警并限制俯仰指令”。这条需求分配给软件后，软件高层需求将其分解为“迎角有效性判断”“失速阈值比较”“告警输出逻辑”“俯仰指令限幅”等功能；软件低层需求再进一步分解为具体模块、函数和状态机，例如“迎角有效性判断函数应在 10 ms 内完成，输入范围 -10° 到 +30°，无效时置默认值”。
追溯关系必须是双向的。向上追溯确保每条软件需求都有系统需求来源，不会出现“无源需求”；向下追溯确保每条系统需求都有软件实现和验证证据，不会出现“需求遗漏”。在 HIL 系统级验证中，追溯关系通常以需求追溯矩阵（RTM）的形式维护。一个简化的追溯矩阵示例如下：
| 系统需求编号 | 软件高层需求编号 | 软件低层需求编号 | HIL 测试用例编号 | 验证状态 |
|---|---|---|---|---|
| SYS-FCS-012 | HLR-FCS-045 | LLR-FCS-101 / 102 | HIL-TC-023 | 通过 |
| SYS-FCS-013 | HLR-FCS-046 | LLR-FCS-103 | HIL-TC-024 | 通过 |
| SYS-ALERT-007 | HLR-ALERT-021 | LLR-ALERT-055 | HIL-TC-031 | 待复测 |
表中“待复测”状态说明该需求尚未形成完整证据链，不能计入验证完成。在 DO-178C 审查中，审查员会随机抽取系统需求，沿追溯链向下检查软件需求、源代码、测试用例和测试结果，确认每一环都存在且一致。
四、验证证据链的构建
验证证据链不是单一文档，而是由需求评审记录、测试用例与规程、测试结果数据、覆盖率分析报告和评审签署记录共同构成的证据集合。在 HIL 系统级验证中，证据链的构建需要注意以下几点：
- 测试用例必须可追溯到需求：每个 HIL 测试用例应明确标注其验证的系统需求编号和软件需求编号，避免“为测而测”。
- 测试结果必须可复现：记录 HIL 台架的配置版本、仿真模型版本、被测软件版本、I/O 板卡配置和激励数据，确保任何人在相同配置下能复现结果。
- 覆盖率分析必须覆盖需求：除了结构覆盖率（语句、分支、MC/DC），还要分析需求覆盖率，确认每条需求至少被一个测试用例验证。
- 异常结果必须闭环：测试中发现的偏差、失败或未覆盖项，必须记录为问题报告，跟踪至关闭，并在证据链中保留处理记录。
总结来看，DO-178C 对系统级验证的要求可以归纳为：需求可追溯、接口可验证、证据可闭环。在 HIL 系统级验证中，工程师需要同时关注系统层级的功能与安全目标、软件层级的实现细节，以及两者之间的接口一致性。只有把需求分解、追溯关系和证据链三者打通，才能形成经得起审查的验证结论。