1. 课程导入与验收交付全景

dSPACE HIL（Hardware-in-the-Loop，硬件在环）项目的验收与交付，不是项目末尾的一次性签字动作，而是贯穿需求冻结、台架搭建、模型集成、测试执行到成果移交的一条完整证据链。它的本质是：用可追溯的证据证明"这套 HIL 系统及其测试能力，能够按约定支撑被控对象的验证需求"，并把系统、模型、测试资产、文档与知识一并移交给接收方，使其能独立运行、维护和扩展。

理解验收与交付，先要区分两个容易混淆的概念。验收（Acceptance）回答的是"是否达标"——依据验收准则对系统功能、性能、接口、测试覆盖度做出判定，输出的是结论与偏差清单；交付（Delivery）回答的是"是否可用"——把可运行的系统、完整的资产和可维护的知识转移到接收方手中，输出的是移交物与移交确认。验收通过不等于交付完成，交付完成也不代表验收无遗留项，二者互为前提、交替推进。

参与角色与职责边界

一个典型的 dSPACE HIL 项目至少涉及五类角色。供应商侧的HIL 集成工程师负责实时系统配置、I/O 接线、模型部署与调试；测试工程师负责测试用例开发、自动化执行与报告生成；项目经理负责范围、进度与偏差管理。客户侧的验证负责人负责确认验收准则、评审证据、签署结论；最终用户（如整车或电控部门工程师）负责在移交后实际使用台架。角色之间最容易出问题的地方是职责边界：例如"模型精度由谁负责""I/O 故障注入是否属于验收范围"，必须在验收准则中写清，否则会在验收会上反复拉扯。

生命周期阶段与关键节点

HIL 项目的验收交付通常沿以下阶段推进，每个阶段都有明确的输入、输出与判定点：

• 需求与准则冻结：明确被测对象（如 VCU、BMS、电机控制器）、信号清单、测试范围与验收指标，输出《验收准则》与《交付物清单》。
• 台架搭建与集成：完成实时硬件（如 dSPACE SCALEXIO 或 MicroAutoBox）、I/O 板卡、负载仿真、故障注入单元与被测 ECU 的物理连接与信号映射。
• 模型部署与标定：将 Plant Model 编译下载至实时处理器，核对采样步长、任务优先级与信号量程。
• 测试执行与证据采集：运行自动化测试序列，采集波形、日志、覆盖率与偏差记录。
• 验收评审：对照准则逐项判定，形成通过/有条件通过/不通过结论与偏差清单。
• 移交与培训：交付系统、模型、测试资产、文档，并完成接收方操作培训与移交确认。

下图给出这一全景的结构关系：左侧是输入与角色，中部是阶段推进，右侧是输出与判定，底部是贯穿全程的风险与成功标准。

常见风险与成功标准

HIL 项目验收交付中最常见的风险集中在三处。第一是准则模糊：如果验收准则只写"系统运行稳定"，验收时双方对"稳定"的理解必然不同。可操作的写法是量化，例如"在 1 ms 步长下连续运行 8 小时无丢帧，CPU 负载不超过 70%，关键信号抖动小于 ±2%"。第二是模型精度偏差：Plant Model 与实测数据的偏差若未在准则中约定阈值，验收时容易陷入争论。建议在准则中明确"关键物理量在指定工况下与实测数据偏差不超过 ±5%"。第三是I/O 映射错误：这是最隐蔽也最致命的问题，一个通道错位可能导致整个测试结论失效，因此必须在集成阶段用已知信号逐点核对。

成功标准可以归纳为三条可检验的判据：可追溯——每条验收准则都能对应到具体的测试用例与证据；可复现——接收方按文档操作能重现相同结果；可移交——系统、模型、脚本、文档齐全，接收方经培训后能独立运行与维护。这三条既是验收的判定依据，也是交付的完成标志。

把上述内容落到操作层面，项目启动阶段就应产出一份《验收与交付基线表》，作为后续所有工作的对照基准。下表给出一个可直接参考的示例结构（字段与阈值均为示例，实际项目需按被测对象与合同约定调整）：