1. 课程导入与工程全景

在电控软件开发中，HIL（Hardware-in-the-Loop，硬件在环）测试是把真实控制器（ECU）接入实时仿真机，用仿真模型替代真实被控对象与部分传感器/执行器，从而在实验室里安全、可重复地复现整车或台架工况。当项目从"偶尔跑一次 HIL"走向"每天都要验证"，问题就不再是"能不能测"，而是"如何让测试自动、稳定、可追溯地跑起来"。这正是本课程要解决的核心：把 dSPACE HIL 台架接入持续集成（CI）流水线，并组织成夜间回归（Nightly Regression）体系。

先明确两个关键概念。持续集成指开发人员频繁提交代码后，由自动化服务器触发构建、静态检查、单元测试与 HIL 测试，尽早暴露集成缺陷；夜间回归指在无人值守时段批量执行一组覆盖面较广的测试用例，通常耗时数小时，第二天早晨产出报告。二者结合后，HIL 台架从"工程师手动操作的设备"变成"CI 流水线中的一个可调度资源"。其价值体现在三点：一是把回归周期从"周"压缩到"天"，缺陷发现时间前移；二是测试结果与代码版本、模型版本、标定数据强绑定，可追溯；三是台架利用率提升，白天做调试、夜间做回归，资源不闲置。

一个典型的 dSPACE HIL 持续集成系统由五层组成，理解这五层的职责与数据流，是后续所有章节的基础。

图中五层并非简单串联，而是形成闭环：CI 服务器从代码与模型源拉取版本，按测试管理中的用例清单调度 HIL 台架执行，结果回写报告并反馈到代码仓库（例如失败则阻止合并）。夜间回归正是这个闭环在时间维度上的批量展开。

要让这条链路真正跑通，需要解决若干工程问题，它们构成了本课程的学习路线。第一，环境与版本一致性：ECU 代码、Simulink 模型、A2L 标定文件、HIL 配置（如 dSPACE ConfigurationDesk 工程）必须成套管理，否则"昨天通过、今天失败"往往源于版本错配。第二，自动化脚本：用 AutomationDesk 或 Python 封装台架启动、模型下载、用例执行、数据采集，把人工点击变成可重复命令。第三，台架资源调度：多台 HIL 台架如何排队、如何避免冲突、失败如何重试。第四，结果判定与报告：如何定义通过准则（如信号容差、超时阈值），如何生成趋势看板。第五，稳定性治理：处理偶发失败（flaky test）、台架掉线、实时超载等夜间常见故障。

为便于理解，这里给出一个教学示例（参数为合理假设，非实测结果）：某项目夜间回归包含 120 条用例，单条平均耗时 3 分钟，串行执行约 6 小时，符合 22:00—06:00 窗口。若将台架扩展为 2 台并行，理论耗时降至约 3 小时，但需注意模型下载与台架初始化各占约 5 分钟，实际并行效率约 85%。通过准则可设为：关键信号稳态误差 ≤ 2%、超调量 ≤ 5%、无未预期故障码。这些数字在后续章节会具体展开如何配置与判读。