2. 航电计算平台测试标准与适航要求

航电计算平台的自动化测试不是“把手工测试脚本化”这么简单。它必须回答一个更根本的问题:测试活动本身如何被适航审定方接受为符合性证据。这就把测试从工程活动提升为“符合性验证活动”,其依据来自一组相互衔接的标准体系。理解这些标准对测试的要求,是设计自动化测试框架、组织测试证据链的前提。

一、四类标准各自约束什么

DO-178C 与 DO-254 是“过程标准”,分别针对机载软件和复杂电子硬件(如 FPGA、ASIC)。它们不规定具体测试用例,而是规定生命周期过程、目标(Objective)、活动与证据。DO-178C 按软件等级 A~E 划分,等级越高,目标越多、独立性要求越强。以等级 A 为例,它要求语句覆盖(SC)、判定覆盖(DC)和修正条件/判定覆盖(MC/DC),并要求验证过程与开发过程相互独立。DO-254 对硬件的对应要求体现在需求捕获、概念设计、详细设计、实现与验证各阶段,验证方法包括仿真、形式化分析和基于需求的测试。

ARINC 653 是“接口与分区标准”,它规定航空电子分区操作系统(APEX)的接口服务:分区管理、进程管理、时间管理、分区内通信(缓冲、黑板、信号量、事件)和分区之间通信(采样、队列端口)。对测试而言,它带来两个硬性要求:一是分区隔离性验证——一个分区的故障不得影响其他分区;二是时间确定性验证——分区调度必须按主时间框架(Major Time Frame)严格轮转,抖动必须在允许范围内。

ARINC 664(AFDX)是“网络标准”,它基于以太网但引入虚拟链路(VL)、带宽分配间隔(BAG)、最大帧长(Lmax)和完整性检查(Integrity Checking)来保证确定性。测试必须覆盖 VL 的带宽约束、冗余网络(A/B 网)的完整性检查与去重、以及网络在故障注入下的降级行为。

四类标准的关系可以这样理解:DO-178C/DO-254 管“你怎么做、拿什么证明”,ARINC 653/664 管“被测对象必须满足什么行为”。自动化测试既要产出过程证据,也要产出行为证据。

二、适航审查中的测试证据链

审定方关注的不是单个测试是否通过,而是从需求到结果的可追溯闭环。一条完整的证据链通常包含:高层需求 → 低层需求 → 测试用例 → 测试规程 → 测试结果 → 覆盖分析报告 → 问题报告与关闭记录。每一环都必须可双向追溯:正向证明每条需求都被测试覆盖,反向证明每个测试用例都对应至少一条需求,没有“无源之水”的测试。

在 DO-178C 的框架下,证据链还要满足“独立性”要求:等级 A/B 的验证活动应由独立于开发的人员执行,或至少由独立的过程完成。自动化测试在这里的价值是双重的——它既提高执行一致性,又通过工具鉴定(Tool Qualification,DO-330)把“工具可信度”本身纳入证据体系。如果自动化测试工具的输出被直接用于替代或减少某项目标活动,该工具通常需要按 DO-330 进行鉴定;若仅作为辅助手段、结果仍由人工复核,则鉴定要求可降低。

三、自动化测试如何满足符合性验证

把标准要求落到自动化测试上,核心是让测试框架具备“证据生成能力”,而不仅是“执行能力”。具体来说,测试用例应携带需求标识(如 REQ-FCS-0123),执行时自动记录时间戳、输入激励、被测输出、判定结果和覆盖信息,并输出为可追溯的格式。下面是一个测试用例元数据的示例结构:

case_id: TC_PARTITION_ISOLATION_007
requirement: REQ-653-ISO-004
objective: 验证分区A写越界不影响分区B输出
setup: 分区A注入非法写地址0x8000_0000
stimulus: 分区B周期任务输出计数器
expected: 分区B计数器连续递增,无丢帧
coverage: 分区隔离目标 ISO-1
evidence: log_007.json + trace_007.csv

对于 ARINC 653 的时间确定性测试,自动化框架需要能够精确测量分区切换时刻。一种可行做法是利用被测平台的健康监控(HM)钩子或专用测试端口,在每个主时间框架边界打时间戳,统计实际切换点与理论调度点的偏差。示例判据可设为:在 1000 个主时间框架内,分区切换抖动不超过 ±50 μs,且无分区超时。这类参数属于示例性合理假设,实际阈值应依据平台设计保证值和适航审定基础确定。

对于 ARINC 664 网络测试,自动化框架通常需要构造符合 VL 配置的激励流量,并注入异常帧(超长帧、错误 BAG、冗余网不一致)来验证完整性检查与去重逻辑。测试结果不仅要看“是否通过”,还要记录网络在异常下的恢复时间,作为确定性行为的证据。

四、标准要求到测试活动的映射

下面这张图把四类标准的关键要求与自动化测试需要产出的证据对应起来,帮助在设计测试框架时明确“每个测试动作服务于哪条符合性目标”。

标准要求 → 自动化测试活动 → 符合性证据 DO-178C 软件生命周期目标 MC/DC、独立性 DO-254 硬件设计保证 需求追溯、验证方法 ARINC 653 分区隔离、时间确定性 APEX 服务接口 ARINC 664 VL/BAG、冗余去重 完整性检查 需求追溯与覆盖分析 用例绑定需求ID,自动统计SC/DC/MC/DC 输出覆盖报告与未覆盖项清单 硬件在环与仿真验证 FPGA 激励注入、时序比对 设计需求与实现一致性检查 分区隔离与调度测试 故障注入、越界访问、时间戳采集 抖动统计与超时判定 网络确定性与故障注入 VL 流量构造、异常帧注入 冗余网切换与恢复时间测量 覆盖分析报告 需求-用例追溯矩阵 未覆盖项及理由说明 验证结果记录 激励-响应日志 时序比对报告 隔离与时间证据 分区切换时间戳序列 抖动统计与判定结论 网络行为证据 VL 带宽与 BAG 符合性 冗余切换恢复时间记录 证据链闭环:需求 → 用例 → 执行记录 → 覆盖分析 → 问题关闭,全程可双向追溯

五、自动化测试框架需要具备的证据能力

基于上述映射,一个面向适航的自动化测试框架至少应具备以下能力,这些能力直接决定证据链是否成立:

  • 需求绑定与追溯:每个测试用例在定义时就绑定需求标识,执行后自动生成追溯矩阵,避免人工整理带来的遗漏和错误。
  • 确定性执行与时间戳:测试激励的施加时刻、被测响应的采集时刻必须可记录、可复现,尤其对 ARINC 653 的时间确定性测试,时间戳精度直接影响结论可信度。
  • 覆盖度量自动化:对 DO-178C 的 SC/DC/MC/DC,需要工具链支持自动插桩与覆盖统计,并区分“已覆盖”与“已证明不可达”两类情况。
  • 故障注入与异常路径:分区越界、网络异常帧、冗余网断链等场景必须能由框架自动注入并记录系统响应,作为鲁棒性证据。
  • 工具鉴定考量:若框架输出直接用于符合性判定,需评估是否按 DO-330 进行工具鉴定;若仅辅助人工复核,应在测试计划中明确说明工具角色与限制。
常见误区:把“测试全部通过”当作符合性结论。适航审查关注的是证据链是否完整、可追溯、可复现,以及测试是否覆盖了标准要求的目标。缺少需求追溯或覆盖分析的测试结果,即使全部通过,也不能单独构成符合性证据。