2. 仿真基础概念

在开始使用 CarMaker 搭建整车仿真环境之前，必须先建立一套清晰的“概念坐标系”。很多初学者一上来就操作软件界面，却对“仿真到底在仿什么”“HIL 和 SIL 的区别是什么”“虚拟测试的结果能不能信”等问题缺乏系统认知，导致后续搭建模型时频繁返工、调试时无从下手。本章将围绕车辆动力学仿真、虚拟测试、SIL（软件在环）、HIL（硬件在环）四个核心术语展开，厘清它们之间的层级关系、适用场景与工程边界，为后续章节的实操打下坚实的理论基础。

2.1 车辆动力学仿真：仿真的“物理内核”

核心原理

车辆动力学仿真是一切整车仿真工作的物理基础。它通过数学模型描述车辆在路面行驶时的受力与运动关系，核心包括纵向动力学（加速、制动）、横向动力学（转向、侧偏）和垂向动力学（悬架振动、载荷转移）。在 CarMaker 中，车辆模型被拆分为车身、悬架、转向、轮胎、动力总成、制动系统等子系统，每个子系统都有可配置的参数化模型。轮胎模型是其中最关键的部分，常用的有 Pacejka 魔术公式、FTire、CDTire 等，它们决定了车辆在极限工况下的仿真精度。

CarMaker 的车辆动力学模型采用多体动力学与经验公式混合的建模策略。对于悬架运动学（K&C 特性），使用查表或多项式拟合；对于轮胎力，使用半经验公式；对于车身刚体运动，使用牛顿-欧拉方程。这种混合策略在保证实时性的同时，尽可能逼近真实物理特性。

判断方法：如何评估一个车辆动力学模型是否“够用”

在实际项目中，我们不需要一味追求最高精度的模型，而是根据测试目的选择合适保真度。判断标准如下：

• 开环控制开发（如 ACC 纵向控制）：关注纵向加速度响应，可使用简化单轨模型，精度要求中等。
• 底盘调校（如 ESP/ABS 标定）：必须包含悬架 K&C 特性和轮胎非线性区，需要高保真模型。
• 自动驾驶感知算法测试：更关注传感器仿真与场景逻辑，车辆模型可适当简化，但需保证基本运动学一致。
• 实时性验证：HIL 环境要求模型在 1ms 步长内完成计算，模型复杂度受限于实时机算力。

案例拆解：从“跑不动”到“跑得准”——一次悬架参数修正

某项目组在搭建 CarMaker 仿真环境时，发现车辆在高速变道工况下横摆角速度响应比实车测试数据快了约 15%。初始现象是仿真车辆“过于灵活”，转向过度趋势明显。团队首先检查了轮胎模型参数，发现前轴轮胎侧偏刚度使用了默认值，未按实际轮胎型号替换。进一步排查后，确认后悬架侧倾中心高度参数与实车不一致，导致载荷转移计算偏差。

关键输入数据：实车 K&C 试验台测得的前悬架侧倾刚度 1200 N·m/deg，后悬架 950 N·m/deg；轮胎侧偏刚度前轴 78000 N/rad，后轴 72000 N/rad。修正步骤：① 在 CarMaker 的 Vehicle Data 面板中更新前后悬架 K&C 特性曲线；② 将轮胎文件替换为实际型号的 Pacejka 参数；③ 运行稳态回转仿真，对比横摆角速度增益；④ 迭代调整后悬架侧倾中心高度从 80mm 降至 55mm。结果：横摆角速度响应误差从 15% 降至 3% 以内。复盘经验：车辆动力学参数必须来源于实车测量或厂商数据，不能依赖默认值；每次修改参数后应运行标准验证工况（正弦扫频、阶跃转向）确认全局一致性。

2.2 虚拟测试：从“单点仿真”到“场景化验证”

核心原理

虚拟测试是在纯软件环境中，通过构建包含道路、交通参与者、环境条件、传感器模型在内的完整测试场景，对车辆功能进行批量验证的方法论。与传统的单次仿真不同，虚拟测试强调“场景库”的概念——将真实世界中的交通情况抽象为可参数化的场景描述，然后通过自动化手段批量执行。CarMaker 提供了 Scenario Editor 和 TestAutomation 接口，支持从 OpenSCENARIO 格式导入场景，也支持通过 Python/MATLAB 脚本批量修改场景参数。

虚拟测试的核心价值在于“左移”——在实车测试之前，通过仿真发现功能缺陷，从而缩短开发周期、降低测试成本。根据 IPG 的统计数据，虚拟测试可以覆盖约 80% 的常规场景和 60% 的边界场景，而成本仅为实车测试的 5%-10%。

操作流程：构建一个可执行的虚拟测试用例

1. 场景定义：明确测试目的（如 AEB 行人横穿），确定道路几何（直道/弯道）、初始车速、目标物类型与运动轨迹。
2. 参数化：将关键变量（如自车速度、行人速度、碰撞角度）设为可扫描参数，定义取值范围与步长。
3. 仿真执行：使用 CarMaker 的 Batch 模式或 TestManager 批量运行，每次仿真自动生成结果文件（包括车辆轨迹、速度曲线、碰撞标志位）。
4. 结果判定：通过后处理脚本自动检查是否满足通过准则（如最小距离 > 0.5m、碰撞速度 < 2km/h）。
5. 报告生成：汇总所有场景的通过/失败状态，生成矩阵报告。

案例拆解：AEB 系统虚拟测试矩阵

某 OEM 需要对 AEB 系统进行 Euro NCAP 2023 规程验证。初始目标：覆盖 5 大测试场景（CCRs、CCRm、CCRb、Pedestrian Farside、Pedestrian Nearside），每个场景 3 种车速（30/45/60 km/h），共 15 个测试用例。团队在 CarMaker 中搭建了测试矩阵，使用 Python 脚本自动修改场景文件中的初始车速和目标物位置。关键输入数据：自车减速能力（最大减速度 -8m/s²）、传感器探测距离（前向雷达 120m，摄像头 80m）、系统响应延迟（0.3s）。执行过程中发现 CCRb 场景（目标车静止）在 60km/h 下碰撞速度超标，分析日志发现是传感器融合模块在远距离目标检测时置信度不足，导致制动介入延迟。通过调整传感器模型中的探测概率参数，并增加融合逻辑的虚拟验证，最终所有用例通过。该案例表明，虚拟测试不仅能验证功能，还能暴露传感器模型与算法之间的交互问题。

2.3 SIL（软件在环）：让真实代码跑在虚拟世界里

核心原理

SIL 是指将实际编译后的 ECU 控制软件（通常是 C 代码或 Simulink 生成的嵌入式代码）运行在通用处理器（PC 或服务器）上，与虚拟车辆模型和环境模型构成闭环仿真。与 MIL（模型在环）不同，SIL 使用的是产品级代码，而非开发阶段的 Simulink 模型，因此可以验证代码实现层面的缺陷，如定点溢出、数据精度、任务调度时序等。

在 CarMaker 中，SIL 通常通过 FMU（Functional Mock-up Unit）接口或自定义 C 接口实现。控制软件被编译为动态链接库（.dll/.so），由 CarMaker 的仿真主程序在每一个步长调用。SIL 的实时性要求较低，允许使用非实时操作系统（如 Windows/Linux），仿真速度可以比真实时间快 10-100 倍，适合大规模回归测试。

判断方法：什么场景必须用 SIL 而不是 MIL

• 代码覆盖率分析：需要统计产品代码的分支覆盖、MC/DC 覆盖时，必须使用 SIL。
• 编译器差异验证：不同编译器（GCC/ARMCC/GreenHills）可能产生不同行为，SIL 可以提前暴露。
• 定点/浮点转换验证：控制算法从浮点模型转为定点代码后，精度损失是否在可接受范围。
• 多核任务调度验证：当控制软件包含多个周期任务时，SIL 可以模拟任务抢占和延迟。

实战场景：SIL 在 BMS 控制策略验证中的应用

某电池管理系统（BMS）开发项目，需要在硬件交付前验证 SOC 估算算法在极端温度下的鲁棒性。团队将 BMS 的 C 代码编译为 Linux 下的 .so 文件，通过 CarMaker 的 FMU 接口接入仿真环境。仿真中设置电池温度从 -20°C 到 50°C 连续变化，同时叠加充放电工况。初始现象：在 -10°C 以下，SOC 估算误差超过 8%，超出设计指标（<5%）。分析日志发现，代码中的开路电压查表函数在低温区间使用了线性插值，而实际电池 OCV-SOC 曲线在低温下呈强非线性。修复方案：将查表数据从 5°C 间隔加密到 2°C 间隔，并改用三次样条插值。修复后 SOC 误差降至 3% 以内。该案例说明 SIL 能够在不依赖硬件的情况下，快速定位算法实现层面的缺陷。

2.4 HIL（硬件在环）：把真实 ECU 接入仿真回路

核心原理

HIL 是将真实的电子控制单元（ECU）连接到实时仿真系统上，仿真系统实时运行车辆动力学模型和环境模型，并通过 I/O 接口（CAN、LIN、FlexRay、模拟量、数字量）与 ECU 进行信号交互。HIL 的核心价值在于：ECU 运行的是最终量产软件，且所有传感器/执行器信号都是真实的电气信号，因此可以验证 ECU 的硬件接口、底层驱动、通信协议和故障诊断功能。

CarMaker 在 HIL 场景中通常作为实时仿真模型运行在 IPG 的实时机（如 Kinion）或第三方实时机（如 dSPACE SCALEXIO、NI PXI）上。仿真模型通过实时机的 I/O 板卡输出车速、轮速、横摆角速度等信号给 ECU，同时接收 ECU 发出的制动压力、转向角、扭矩请求等控制信号。整个闭环在 1ms 或更小的步长内完成。

操作流程：搭建一个 HIL 测试台架

1. 需求分析：确定被测 ECU 的 I/O 清单（CAN 报文、硬线信号、PWM 输出等）。
2. 实时模型配置：在 CarMaker 中配置车辆模型、道路场景，并映射 I/O 信号到实时机的物理通道。
3. 故障注入设计：在信号路径上设计断路、短路、信号偏移等故障注入点。
4. 标定与验证：使用标定工具（如 CANape）连接 ECU，验证信号正确性。
5. 自动化测试：编写测试脚本，批量执行测试用例并记录结果。

案例拆解：ESP 系统 HIL 测试中的信号延迟问题

某底盘电子项目在 HIL 测试中发现，ESP 系统在低附着路面（μ=0.2）的介入时机比预期晚了约 40ms。初始现象：仿真车辆在冰面上紧急制动时，横摆角速度偏差超过阈值后 ESP 才激活。团队通过 CAN 总线日志分析，发现轮速信号从仿真模型输出到 ECU 接收到之间存在约 25ms 的延迟，而 ECU 内部滤波算法又增加了 15ms 的相位延迟。关键输入数据：CAN 报文周期 10ms，仿真步长 1ms，轮速信号经过实时机 D/A 转换和 ECU 的 A/D 采样。分析判断：延迟主要来自 CAN 报文打包和 ECU 的软件滤波。实际操作：① 将轮速信号从 CAN 传输改为硬线 PWM 信号，减少协议栈延迟；② 在 ECU 软件中调整滤波系数，减少相位滞后；③ 在仿真模型中增加轮速传感器的惯性环节，模拟真实传感器响应。结果：ESP 介入延迟从 40ms 降至 12ms，满足设计指标。复盘经验：HIL 测试中信号延迟是常见问题，需要从仿真模型输出、实时机 I/O、通信协议、ECU 软件四个层面逐一排查。

2.5 四种仿真层级的协同与选择策略

核心原理

MIL、SIL、HIL 和虚拟测试并非相互替代，而是构成一个从“算法验证”到“系统集成验证”的完整测试链条。在 V 模型开发流程中，MIL 对应早期算法验证，SIL 对应代码级验证，HIL 对应 ECU 集成验证，虚拟测试则贯穿始终，提供场景库和自动化执行框架。CarMaker 的优势在于：同一套车辆模型和场景可以在不同层级间复用，只需切换控制器的接入方式（模型/代码/硬件），从而保证测试结果的可追溯性。

选择策略：如何决定当前项目用哪种仿真

常见误区与总结复盘

• 误区一：HIL 可以完全替代实车测试。实际上，HIL 无法模拟真实的电磁干扰、机械磨损、温度漂移等物理效应，实车测试仍是最终验收手段。
• 误区二：SIL 和 MIL 差不多。SIL 使用的是产品代码，能发现编译器、定点化、任务调度等问题，而 MIL 只能验证算法逻辑。
• 误区三：虚拟测试场景越多越好。无目的的海量场景会消耗大量计算资源，且结果难以分析。建议基于功能安全分析和实车数据提取关键场景。
• 误区四：车辆动力学模型精度越高越好。在 HIL 中，模型复杂度受实时性约束；在虚拟测试中，模型复杂度影响批量执行速度。应根据测试目的选择合适保真度。