3. 测试数据治理框架设计
HIL测试数据治理不是“把文件归档到NAS”这么简单。它要解决的核心问题是：在台架持续运行、模型频繁迭代、测量文件成批产出的环境中，如何让每一份数据都能被找到、理解、信任、复用和追溯。本节围绕目标、角色、策略层级、成熟度模型与落地原则，给出一套可直接映射到dSPACE HIL场景的治理框架。
一、治理目标：从“存得下”到“用得准”
HIL测试数据治理的目标可以归纳为五个可检验的方向：
- 可发现：给定测试用例编号或需求ID，能在分钟级定位到对应的测量文件、标定文件与报告。
- 可理解：数据自带元数据（台架配置、模型版本、传感器量程、采样率、单位），无需询问原作者即可判读。
- 可信赖：数据来源、采集时间、操作人、软件版本可追溯，异常数据有明确标记。
- 可复用：同一工况的历史数据可被回归测试、模型标定、故障复现直接引用。
- 可合规：满足内部审计与行业标准对测试记录留存、变更追溯的要求。
这五个目标不是并列口号，而是有依赖关系的：没有元数据就谈不上可理解，没有可追溯就谈不上可信赖。因此治理框架必须按层级推进，而不是一次性铺开。
二、组织角色：谁对数据负责
在典型的HIL测试团队中，建议明确四类角色，避免“数据没人管、出事一起扛”的局面：
| 角色 | 核心职责 | 在HIL场景中的具体动作 |
|---|---|---|
| 数据所有者（Owner） | 对数据资产整体质量与策略负责 | 审批命名规范、保留周期、访问权限变更 |
| 数据管理员（Steward） | 执行日常治理规则 | 维护元数据模板、检查入库完整性、处理异常标记 |
| 测试工程师 | 数据生产者与第一责任人 | 按规范命名测量文件、填写测试配置、上传原始数据 |
| 数据消费者 | 复用数据并反馈问题 | 标定工程师、算法工程师按需求检索数据，反馈缺失字段 |
关键原则是：生产者负责元数据，管理员负责规则执行，所有者负责策略裁决。不要让测试工程师既写用例又当数据管理员，否则治理规则会在赶进度时被跳过。
三、策略层级：从命名到生命周期
治理策略应分为三层，逐层细化：
第一层：标识与命名策略。这是最基础也最容易被忽视的一层。建议HIL测量文件采用结构化命名，例如：
TC_ABS_0123_Run03_20240612_1430.mf4
│ │ │ │ │ │
│ │ │ │ │ └─ 采集时刻
│ │ │ │ └─ 采集日期
│ │ │ └─ 重复运行序号
│ │ └─ 测试用例编号
│ └─ 功能域
└─ 测试类型前缀命名规则必须与测试管理系统中的用例ID一致，否则检索链路会在第一步断裂。
第二层：元数据与存储策略。每个测量文件应附带一份元数据记录，至少包含：台架编号、dSPACE硬件配置（如DS1006/DS5203板卡组合）、模型版本号、标定文件版本、采样率、关键信号清单及单位、测试目的、预期结果。存储上建议采用“原始数据只读、处理数据可派生”的分层结构，原始测量文件一旦入库不允许覆盖，处理结果另存并记录派生关系。
第三层：生命周期与保留策略。按测试类型区分保留周期：功能验证数据保留至项目结束+2年，法规相关数据按标准要求延长，调试过程中的临时数据可设置30天自动清理。清理前必须确认无未关闭的缺陷关联。
四、成熟度模型：判断当前处在哪一级
治理不是一步到位，可以用五级成熟度模型定位现状并规划下一步：
- L1 无序：数据散落在个人电脑和共享盘，命名随意，无元数据。
- L2 规范：有统一命名和目录结构，但依赖人工执行，元数据不完整。
- L3 受控：元数据模板强制填写，入库有校验，权限按角色分配。
- L4 可追溯：数据与需求、用例、缺陷、模型版本自动关联，变更可审计。
- L5 优化：基于数据使用情况自动优化保留策略，支持跨项目复用与智能检索。
多数HIL团队处于L2到L3之间。从L2迈向L3的关键动作不是买工具，而是把元数据填写变成入库的强制门槛——不填元数据，数据进不了库。
五、在HIL测试场景中的落地原则
框架要落地，必须适配HIL测试的实际节奏。以下五条原则来自工程实践中的常见教训：
原则一：治理动作嵌入现有工具链，不另建流程。测试工程师已经在用ControlDesk采集、用AutomationDesk编排用例，元数据填写应嵌入这些工具的导出环节，而不是要求他们再登录一个治理平台手工录入。例如在AutomationDesk的测试序列末尾增加一个“元数据填写”步骤，导出测量文件时自动生成同名.json元数据文件。
原则二：最小必要元数据集先行。不要一开始就设计50个字段的元数据模板，那会导致填写疲劳和造假。先强制6～8个字段：用例ID、台架编号、模型版本、标定版本、采集日期、操作人、测试结论、关联缺陷ID。其余字段按需扩展。
原则三：原始数据不可变，处理可追溯。HIL测量文件一旦入库即设为只读。后续的滤波、重采样、特征提取等处理，生成新的派生文件并记录“父文件ID+处理脚本版本+处理时间”。这样当标定工程师质疑某个数据点时，可以一路回溯到原始采集。
原则四：按测试类型差异化保留。不是所有数据都值得长期保存。功能验证数据保留至项目SOP后2年；法规认证相关数据按法规要求延长；每日冒烟测试数据保留30天即可。差异化策略能显著降低存储成本和管理负担。
原则五：用一次真实检索验证治理效果。治理框架上线后，找一个未参与设计的工程师，给他一个需求ID，看他能否在10分钟内找到对应的测量文件、元数据和测试报告。如果找不到，说明命名或元数据关联仍有断点。这个“10分钟检索测试”比任何成熟度评分都直接。
总结来看，HIL测试数据治理框架的核心逻辑是：目标定义方向，角色划分责任，策略分层执行，成熟度定位现状，落地原则保证适配。五者缺一不可，但推进时不必齐头并进——先把命名和最小元数据集做扎实，再逐步向可追溯和优化演进，是风险最低、见效最快的路径。