2. dSPACE HIL测试数据生态解析

在 dSPACE HIL 测试环境中，数据从来不是由单一工具产生的。ControlDesk 负责试验操作与在线观测，AutomationDesk 负责自动化测试序列，MotionDesk 负责三维场景与视觉激励，RTI 负责模型到实时硬件的接口代码生成，XIL API 则负责跨工具、跨平台的标准化访问。理解这些工具各自“产出什么数据、以什么形态存在、通过什么通道流转”，是后续做数据治理、归档和报告工程的前提。

一、五类工具的数据产出定位

ControlDesk 是试验台的操作入口。它产生的数据主要有三类：一是测量数据，来自实时系统通过 XIL API 或 dSPACE 内部通道回传的变量采样，通常以 .mf4（MDF4）或 .dat 形式落盘；二是标定与参数数据，即用户在标定窗口中修改的变量值，往往以 .sdf、.par 或 .a2l 描述的变量集合为参照；三是布局与工程配置数据，如 .cdx 布局文件、.cdp 工程文件，它们记录的是“怎么测”，而不是“测到了什么”。

AutomationDesk 是自动化测试序列的执行者。它本身不直接产生物理量，而是产生测试逻辑与结果：测试用例定义（.adx 或 .aut 序列文件）、测试步骤执行日志、断言结果、参数化数据表（如 CSV 或 Excel 驱动的输入向量），以及最终生成的测试报告（HTML/XML/PDF）。AutomationDesk 的测量数据通常仍由 ControlDesk 或底层记录模块产生，但测试结论由 AutomationDesk 给出。

MotionDesk 是视觉与场景激励工具。它产生的是三维场景描述、相机轨迹、动画时间线以及场景中对象的状态数据。这些数据一部分作为实时激励注入模型（如摄像头图像、雷达目标列表），一部分作为可视化记录用于回放。其数据形态偏向场景配置（.mds 场景文件）和图像/视频流，与物理量测量数据在格式上差异明显。

RTI（Real-Time Interface）是 Simulink 模型到 dSPACE 实时硬件的桥梁。它不产生运行数据，而是产生“可运行代码”和“接口描述”：通过 RTI 生成的 .c/.h 代码、.rti 配置文件、.trc 跟踪文件，以及描述变量、任务、I/O 映射的 .a2l 文件。RTI 的数据形态是“静态的、结构化的接口定义”，它决定了后续测量系统能访问哪些变量、以什么地址和类型访问。

XIL API 是标准化访问层。它不直接产生文件，而是提供一套跨工具、跨厂商的 API（如 ASAM XIL API），让 ControlDesk、AutomationDesk 或第三方测试工具能够以统一方式读写变量、触发记录、控制仿真。XIL API 的“数据”是运行时的调用参数与返回值，其价值在于把不同工具的数据流统一到同一套语义上。

二、数据流转关系与格式对照

从数据流角度看，RTI 处于最上游：它把模型接口固化为 .a2l 和可执行代码，决定了“哪些变量可被观测”。ControlDesk 和 AutomationDesk 处于中游：ControlDesk 通过 XIL API 或 dSPACE 内部通道读取实时变量并记录为 .mf4；AutomationDesk 则调用 ControlDesk 或 XIL API 完成测量，同时把测试步骤、断言和结果写入自己的日志与报告。MotionDesk 处于激励侧：它把场景数据注入模型，同时接收模型状态用于可视化，形成一条“场景→模型→实时系统→测量”的闭环。XIL API 贯穿中游，是工具之间互操作的粘合剂。

下面这张图把五类工具的数据形态、格式与流转关系放在同一张拓扑中，便于对照理解。

三、格式差异带来的治理难点

从图中可以清楚看到，五类工具的数据格式并不统一：RTI 产出的是代码与接口描述，ControlDesk 产出的是二进制测量文件与标定文件，AutomationDesk 产出的是测试序列与报告，MotionDesk 产出的是场景与媒体流，XIL API 则只存在于运行时。这种“多源异构”是 HIL 数据治理的第一个难点。

第二个难点是时间基准不一致。测量数据带有实时系统的时间戳，测试序列带有 AutomationDesk 的执行时间，场景动画带有 MotionDesk 的帧时间。若不做时间对齐，后续做“某个测试步骤对应哪段测量曲线”的追溯就会非常困难。实践中通常以实时系统时间戳为基准，把 AutomationDesk 的步骤起止时间映射到测量文件的时间轴上。

第三个难点是变量命名与语义映射。RTI 生成的 .a2l 中变量名是模型侧的，ControlDesk 记录时可能使用别名，AutomationDesk 断言时又可能引用另一套路径。XIL API 虽然提供了统一访问方式，但变量映射仍需人工或工具维护。治理时建议建立一张“变量映射表”，至少包含模型变量名、A2L 名称、ControlDesk 显示名、AutomationDesk 引用路径和物理单位。

四、一个可参考的变量映射表示例

下面给出一个简化的变量映射表结构，用于把 RTI 的 A2L 变量、ControlDesk 记录通道和 AutomationDesk 断言路径对应起来。表中数据为示例，实际项目应按模型和测试规范填写。

模型变量名	A2L 名称	ControlDesk 通道	AutomationDesk 引用	单位	数据类型
VehicleSpeed	Model/VehicleSpeed	Speed_kmh	Root.Speed_kmh	km/h	float32
BrakePressure	Model/BrakePressure	Brake_bar	Root.Brake_bar	bar	float32
EngineTorque	Model/EngineTorque	Torque_Nm	Root.Torque_Nm	N·m	float32
GearPosition	Model/GearPosition	Gear	Root.Gear	—	uint8

有了这张表，当 AutomationDesk 报告某条断言失败时，就可以快速定位到 ControlDesk 中对应的测量通道，再回到 .mf4 中查看该变量的时间曲线，形成“测试结论→测量数据→模型变量”的追溯链。这正是数据治理在 HIL 测试中的核心价值：不是简单地把文件存起来，而是让不同工具产生的数据能够互相解释、互相印证。

五、流转关系对报告工程的影响

报告工程需要的数据通常来自两个方向：一是测量数据（.mf4 中的曲线、统计值），二是测试结论（AutomationDesk 的通过/失败、断言详情）。如果两者没有通过统一标识关联，报告就只能分别罗列，无法回答“这个失败对应哪段曲线”。因此，在数据流转设计中，应让 AutomationDesk 在生成报告时携带测量文件的引用（如文件名、时间范围、变量列表），并让 ControlDesk 的记录配置中包含测试用例标识。这样，报告生成工具才能把结论和证据拼在一起。

MotionDesk 的场景数据在报告中的角色相对特殊：它通常作为视觉证据（截图或视频片段）附加在报告中，用于说明测试时的环境条件。治理时应把场景文件版本、相机参数和对应的时间段一并记录，避免出现“有视频但不知道对应哪次测量”的情况。

综上，dSPACE HIL 测试数据生态的关键不在于记住每个工具的文件扩展名，而在于理解它们各自在数据链中的位置：RTI 定义接口，XIL API 统一访问，ControlDesk 记录测量，AutomationDesk 给出结论，MotionDesk 提供激励与视觉证据。只有把这条链上的数据形态、格式和流转关系梳理清楚，后续的归档、索引、追溯和报告生成才有稳定的基础。