4. 平台总体架构设计
自动化回归测试平台不是把若干脚本堆在一起，而是一套需要长期演进、多人协作、跨工具链运行的工程系统。总体架构设计要回答四个问题：系统分成哪几层、每层由哪些模块构成、模块之间用什么接口通信、这些模块最终部署在哪些机器上。本节以 dSPACE 硬件在环（HIL）测试为背景，给出一套可直接落地的分层架构方案。
一、分层架构：从用例到硬件的五层切分
平台按职责纵向切分为五层，每层只依赖其下一层，禁止跨层反向调用。这样做的直接收益是：更换被测控制器或更换测试管理工具时，只需替换对应层，其余层保持稳定。
- 用例层：以自然语言与参数表描述测试意图，例如“车速 60 km/h 时触发 AEB，期望制动减速度 ≥ 6 m/s²”。该层不出现任何 dSPACE API。
- 编排层：负责用例调度、参数化展开、前置条件准备、失败重试与结果汇总，是回归批次的“指挥中心”。
- 抽象层：把“设置车速”“读取 CAN 信号”“注入故障”等操作抽象为与硬件无关的接口，屏蔽具体工具差异。
- 适配层：将抽象层调用翻译为 dSPACE 具体实现，如 AutomationDesk 的库函数、ControlDesk 的变量访问、XIL API 的调用。
- 资源层：真实硬件与仿真资源，包括实时处理器（DS1006/DS6001）、I/O 板卡（DS2211）、总线接口（DS4302 CAN）、被测 ECU 与负载箱。
分层的关键约束是“接口向下定义、实现向上替换”。抽象层接口一旦冻结，适配层可以并行开发多个后端（真实 HIL、纯仿真、回放台架），用例层完全无感。
二、模块划分与职责边界
在五层之内进一步划分模块，每个模块应有单一职责和明确的输入输出。核心模块包括：
| 模块 | 所属层 | 核心职责 | 关键输出 |
|---|---|---|---|
| 用例解析器 | 用例层 | 解析 YAML/Excel 用例，校验参数合法性 | 标准化用例对象 |
| 调度引擎 | 编排层 | 批次编排、并发控制、超时与重试 | 执行任务队列 |
| 测试服务接口 | 抽象层 | 定义信号读写、故障注入、测量采集契约 | 接口定义（IDL） |
| dSPACE 适配器 | 适配层 | 调用 AutomationDesk/XIL API 完成实际操作 | 原始测量数据 |
| 结果判定器 | 编排层 | 按判据比较实测值与期望值 | 通过/失败结论 |
| 报告生成器 | 编排层 | 汇总日志、曲线、截图，生成 HTML/PDF 报告 | 回归报告 |
| 资源管理器 | 资源层 | 台架占用、锁释放、模型加载与复位 | 可用台架句柄 |
模块边界要防止两类常见错误：一是把判定逻辑写进适配器，导致换台架就要改判据；二是让调度引擎直接操作硬件变量，绕过抽象层。前者破坏可移植性，后者破坏可测试性。
三、接口定义：三类契约
平台内部存在三类接口，必须显式定义并版本化管理。
第一类是用例接口，即用例文件的结构约定。建议固定字段：case_id、precondition、stimulus、expected、tolerance、timeout_ms。其中 tolerance 用于浮点比较，例如减速度判据写为 expected: 6.0, tolerance: 0.3，避免因仿真步长导致误判。
第二类是服务接口，即抽象层暴露给编排层的方法。典型签名如下：
interface TestService {
setSignal(name: string, value: number): void;
getSignal(name: string): number;
injectFault(component: string, mode: string): void;
startMeasurement(signals: string[], rate_hz: number): MeasurementHandle;
stopMeasurement(handle: MeasurementHandle): MeasurementResult;
}
第三类是数据接口，即测量结果的落盘格式。推荐统一为列式结构：时间戳、信号名、值、单位、质量码。质量码用于标记信号是否有效，例如 CAN 超时置为 0x02，判定器遇到无效质量码应直接判失败而非比较数值。
四、数据流：一次回归执行的完整链路
下面这张图给出从用例加载到报告产出的数据流与部署拓扑。图中同时标出了各模块所在的物理节点，便于后续部署规划。
数据流的关键点在于：控制流自左向右下发，测量流自右向左回传，两者在抽象层交汇。判定器只消费抽象层返回的 MeasurementResult，不直接读取硬件，因此同一套判据既可用于 HIL，也可用于纯仿真回放。
五、部署拓扑与资源约束
部署上建议采用“一管理多台架”的拓扑：测试管理服务器一台，负责用例仓库、调度、判定与报告；HIL 台架若干，每台运行一个 dSPACE 适配器实例。服务器与台架之间通过以太网通信，适配器以服务方式常驻，避免每次执行都重新加载模型。
资源约束需要显式建模。每台 HIL 台架同一时刻只能被一个批次独占，因此调度引擎必须实现台架锁：申请锁时记录 bench_id 与 batch_id，执行结束或超时后释放。若某批次申请锁超过 lock_timeout_ms（示例取 30000 ms），应转入等待队列而非直接失败，并在报告中标注“资源等待”而非“用例失败”，避免误判。
六、一个可执行的部署检查清单
架构落地前，可用下面这份清单逐项确认，避免上线后才发现接口或资源问题：
- 抽象层接口是否已冻结并打上版本号，是否有对应的接口文档与示例调用。
- 每个适配器是否实现了全部接口方法，未实现的方法是否显式抛出“不支持”而非静默返回 0。
- 测量数据的质量码是否已定义，判定器是否在比较前检查质量码。
- 台架锁是否具备超时释放与异常释放机制，服务器重启后锁状态能否恢复。
- 报告是否包含批次号、台架号、接口版本、用例版本，便于失败回溯。
- 结果数据库是否按批次分区，单批次数据量是否评估过（示例：500 用例 × 20 信号 × 10 s × 100 Hz ≈ 1000 万点）。