4. 仿真测试基础

在自动驾驶系统开发中，测试验证贯穿从需求分析到最终量产的全生命周期。由于实车测试存在成本高、周期长、场景覆盖有限且部分危险场景不可复现等瓶颈，基于模型的仿真测试成为核心手段。按照被测对象（Model/Software/Hardware/Driver）与仿真环境耦合程度的不同，业界通常将仿真测试划分为MIL（Model-in-the-Loop，模型在环）、SIL（Software-in-the-Loop，软件在环）、HIL（Hardware-in-the-Loop，硬件在环）和DIL（Driver-in-the-Loop，驾驶员在环）四种类型。这四种类型并非相互替代，而是形成了一条从算法验证到系统集成验证再到人机共驾验证的递进式测试链条。理解各自的技术本质、适用边界与数据流特征，是构建高效测试策略的前提。

4.1 MIL（模型在环）：算法逻辑的快速验证

核心原理：MIL是仿真测试链条的起点，其核心思想是将自动驾驶控制算法（如感知融合、路径规划、决策控制）以图形化模型（Simulink/Stateflow）的形式，与车辆动力学模型、传感器模型在同一仿真环境中闭环运行。此时，被测对象是纯数学模型，不涉及任何代码编译或硬件执行。仿真步长通常为1~10ms，采用变步长或定步长求解器，在虚拟时间轴上快速推进。

判断方法与操作流程：MIL测试的典型流程包括：①搭建被测算法模型（如ACC跟车模型）；②配置车辆动力学模型（如CarSim或Simulink自带Vehicle Dynamics Blockset）；③设计测试场景（如目标车切入、前车急刹）；④设置仿真参数（求解器类型、步长、停止时间）；⑤批量运行并采集数据；⑥通过覆盖率分析（语句覆盖、分支覆盖、MC/DC覆盖）评估测试充分性。MIL测试的核心指标是模型覆盖率和需求追溯率，即每条需求是否至少被一个场景验证。

4.2 SIL（软件在环）：代码级验证与回归测试

核心原理：SIL将MIL中的算法模型通过自动代码生成（Embedded Coder）转换为C/C++代码，并在PC或服务器上编译运行。此时被测对象是软件代码，但运行环境仍是虚拟的（无真实硬件）。SIL的核心价值在于验证模型-代码一致性，即自动生成代码是否忠实实现了模型逻辑。同时，SIL支持在x86架构上运行，执行速度远快于实时，适合大规模回归测试。

判断方法与操作流程：SIL测试的关键步骤：①模型配置（设置代码生成目标为SIL模式）；②生成代码并编译为可执行文件；③将SIL模块替换原模型中的算法模块；④运行相同的测试用例集；⑤对比MIL与SIL的输出差异（通常要求最大误差<1e-6）；⑥若存在差异，检查代码生成配置或模型中的数据类型转换问题。SIL测试的典型指标是数值一致性和执行时间。

// SIL测试中常见的数据类型不匹配问题示例
// 模型中使用double，但代码生成配置为single
float32_t speed = 10.5f;  // 精度损失
if (speed > 10.0f) {      // 边界条件可能改变
    // 触发AEB
}
// 建议：在模型中使用显式数据类型转换模块

案例拆解：某Tier 1供应商在开发泊车辅助系统时，MIL阶段测试全部通过，但SIL阶段发现APA（自动泊车辅助）在特定车位（宽度2.3m）下路径规划失败。通过对比MIL/SIL输出，定位到代码生成时atan2函数的实现差异——模型库使用双精度，而嵌入式代码生成使用了单精度近似。修复方法：在模型中将atan2替换为查表法，并增加误差补偿项。此问题若未在SIL阶段发现，将直接导致HIL测试中断。

4.3 HIL（硬件在环）：实时系统集成验证

核心原理：HIL将真实的ECU（电子控制单元）或域控制器接入仿真回路，通过实时机（如dSPACE SCALEXIO、NI PXI）运行车辆动力学模型和传感器模型，并通过IO板卡（CAN、LIN、FlexRay、以太网）与ECU进行真实信号交互。HIL测试的关键特征是实时性——仿真步长必须严格匹配硬件执行周期（通常1ms），且IO延迟需控制在微秒级。HIL验证的是硬件接口、底层驱动、通信协议和实时调度的正确性。

判断方法与操作流程：HIL测试环境搭建流程：①需求分析（确定被测ECU的IO接口、通信矩阵）；②实时机配置（安装IO板卡、配置FPGA模型）；③传感器信号模拟（通过可编程电阻、电压源模拟温度/压力传感器）；④故障注入单元（FIUs）设计（模拟短路、断路、对电源/地短路）；⑤测试用例开发（基于场景库生成CAN报文序列）；⑥执行测试并监控（记录ECU响应时间、总线负载率）。HIL测试的核心指标是实时性（任务超时率<0.1%）和信号精度（模拟量误差<±5mV）。

实战场景：某OEM在VCU（整车控制器）HIL测试中，发现当CAN总线负载率超过60%时，VCU的报文接收超时率从0.01%升至2.3%，导致扭矩指令中断。通过HIL的CANoe监控，定位到VCU的接收缓冲区配置过小（仅10帧），而实际应用需要缓存至少20帧。修复后重新测试，超时率降至0.02%。此问题在SIL阶段无法发现，因为SIL不涉及真实CAN控制器。

4.4 DIL（驾驶员在环）：人机共驾与接管体验验证

核心原理：DIL将真实驾驶员接入仿真回路，通过驾驶模拟器（如动态驾驶模拟器、固定基座模拟器）提供视觉、听觉、触觉反馈。被测对象是人-车-环境闭环系统，重点评估L2+级自动驾驶的人机交互（HMI）设计、接管请求（TOR）的合理性和驾驶员状态监测。DIL测试的核心是人因工程，而非单纯的算法或硬件验证。

判断方法与操作流程：DIL测试设计要点：①明确测试目标（如评估TOR提前量对接管质量的影响）；②招募驾驶员样本（建议至少15人，覆盖不同年龄/驾龄）；③设计实验场景（如高速公路施工绕行、系统失效）；④配置模拟器（方向盘力反馈、座椅振动）；⑤采集多模态数据（眼动仪、方向盘转角、制动踏板位移、心率）；⑥统计分析（接管时间、碰撞率、主观问卷）。DIL测试的关键指标是接管时间（从TOR发出到驾驶员有效操作的时间）和接管质量（如最大横向偏差）。

常见误区：DIL测试中，模拟器的运动延迟（通常>50ms）会显著影响驾驶员的感知和操作。若模拟器延迟过大，测得的接管时间会偏长，导致对系统性能的误判。建议使用运动延迟<30ms的高性能模拟器，并在实验前进行延迟标定。另外，DIL测试样本量过小（<10人）无法获得统计学意义，建议至少15人并采用拉丁方设计消除顺序效应。

4.5 四种仿真类型的协同策略与选型决策

核心原理：MIL/SIL/HIL/DIL并非孤立使用，而是形成“V模型”左侧的验证链条。在项目实践中，应遵循“左移测试”原则——尽可能在早期阶段（MIL/SIL）发现缺陷，因为缺陷发现越晚，修复成本呈指数级增长（MIL阶段修复成本为1，SIL为5，HIL为20，实车为100）。

选型决策流程：①若目标是验证算法逻辑和需求覆盖，选择MIL；②若目标是验证代码实现和回归测试，选择SIL；③若目标是验证硬件接口、实时性和通信协议，选择HIL；④若目标是验证人机交互和接管体验，选择DIL。实际项目中，通常采用“MIL+SIL+HIL”组合，DIL仅在HMI重大变更或法规认证（如UN R157）时使用。