📚 课程目录第4章 HIL测试数据管理标准与规范

4. HIL测试数据管理标准与规范

在航空航天HIL（硬件在环）测试中，数据管理并不是“把波形存下来”这么简单。DO-178C、DO-254、ARP4754A这三份文件分别从机载软件、复杂电子硬件、系统研制流程三个层面，对“记录什么、记录到什么程度、如何证明数据与需求之间的追溯关系”提出了要求。理解它们的差异与交集，是设计HIL测试数据管理方案的前提。

三份标准各自管什么

ARP4754A面向飞机与系统研制，关注的是系统需求如何向下分配到软硬件、如何通过验证与确认证明分配正确。它要求形成从飞机级需求到系统级需求、再到软硬件需求的双向追溯链，HIL测试数据正是这条链上“验证证据”的载体。DO-178C面向机载软件，按A至E五个软件等级规定目标，其中A级要求最严，强调需求覆盖、结构覆盖（语句、判定、MC/DC）以及测试结果的可重复性。DO-254面向复杂电子硬件（如FPGA、ASIC），其数据要求与DO-178C思路相近，但对象是硬件设计需求与实现验证。

三者的共同点是：任何一条验证结论都必须能回溯到具体需求，任何一份测试数据都必须能证明其来源、版本与完整性。区别在于追溯的起点和粒度不同——ARP4754A追到系统功能与安全性目标，DO-178C追到软件需求与代码结构，DO-254追到硬件需求与逻辑实现。

数据记录：从“存波形”到“存证据”

在HIL环境中，一次测试运行会产生大量信号：总线报文、模拟量、离散量、故障注入状态、模型内部变量。标准并不要求把所有信号都永久保存，但要求与验证目标相关的数据必须完整、可复现、可追溯。实际操作中，建议按以下粒度组织记录：

原始数据层：按固定采样率记录关键信号，保留时间戳与触发条件。例如某飞控HIL台架以1 kHz记录舵面指令与反馈，以100 Hz记录总线周期报文。
测试用例层：每个用例对应一个需求ID，记录激励序列、预期结果、实际结果、判定结论。这是追溯链的最小单元。
构型层：记录被测软件版本、FPGA逻辑版本、HIL模型版本、台架接线与标定文件版本。缺少构型信息的数据在适航审查中不具备证据效力。

以DO-178C A级软件为例，若某条需求要求“迎角超限时10 ms内输出失速警告”，HIL测试数据中必须能同时看到迎角激励信号、警告输出信号、两者时间差，以及该用例对应的需求ID和软件版本。审查员关注的不是波形好不好看，而是这条数据能否独立证明该需求被满足。

追溯性：双向链路的建立方法

ARP4754A强调双向追溯：从需求向下能找到验证证据，从验证证据向上能找到需求。在HIL数据管理中，这通常通过需求管理工具与测试管理工具的接口实现。一个可落地的做法是：在测试用例中嵌入需求ID字段，HIL自动化测试脚本执行时自动将该ID写入数据文件头或元数据表。

用例元数据示例（JSON片段）：
{
  "case_id": "TC-FCS-0127",
  "req_id": "SYS-REQ-0456",
  "sw_version": "FCS_SW_v2.3.1",
  "hw_version": "FPGA_ACT_v1.7",
  "hil_model": "Aircraft_Model_v5.2",
  "rig_config": "RIG-A-2024-03",
  "pass_criteria": "stall_warn_delay <= 10 ms",
  "result": "PASS",
  "measured_delay_ms": 7.4
}

这样，当需求发生变更时，可以通过req_id快速检索出所有受影响的测试用例与历史数据，评估是否需要重新测试。DO-254对硬件验证数据同样要求这种关联，尤其是FPGA逻辑变更后，必须能定位到哪些HIL测试数据是基于旧逻辑版本产生的，并标记为失效。

数据完整性与可重复性要求

DO-178C和DO-254都要求测试结果可重复。这意味着HIL数据管理不能只保存结果，还要保存复现条件：激励数据文件、模型参数、台架标定值、环境温度补偿系数（如涉及）。如果同一用例在不同时间运行得到不同结果，必须能通过记录判断差异来源。

常见误区：只保存通过用例的数据，删除失败或异常数据。适航审查中，失败用例及其处理记录同样是验证活动的一部分。DO-178C要求对未通过项进行记录、分析和关闭，删除数据会直接破坏追溯链。

面向审查的数据组织建议

综合三份标准，HIL测试数据管理可按“需求—用例—运行—数据文件”四级组织。每一级都携带版本与审批状态。数据文件命名建议包含日期、台架编号、用例编号和版本，例如20240315_RIG-A_TC-FCS-0127_v2.3.1.dat。元数据与原始数据分离存储，元数据入库便于检索，原始数据按批次归档并计算校验和，防止篡改。

对于同时涉及软件和硬件的系统级验证，ARP4754A要求系统验证证据能覆盖软硬件接口。HIL台架恰好是观察这些接口的理想位置，因此数据记录中应明确标注哪些信号属于软件输出、哪些属于硬件响应、哪些是模型内部量，避免审查时混淆证据归属。

实践提示：在HIL测试项目启动阶段就定义数据字典，明确每个记录信号的名称、单位、采样率、所属需求ID和判据。数据字典本身也应纳入构型管理，随需求变更同步更新。这样后期生成追溯矩阵时，可以直接从数据字典和用例元数据自动导出，减少人工整理错误。

总结来看，DO-178C、DO-254、ARP4754A对HIL数据管理的共同要求可以归纳为：数据必须绑定需求、携带构型、支持双向追溯、保持完整并可重复。区别只在于追溯的层级和审查的侧重点。把这些要求落实到数据字典、用例元数据和归档规范中，才能让HIL测试数据真正成为适航审查中可用的验证证据，而不是一堆无法说明来源的波形文件。