第二章 测试环境搭建基础：MATLAB/Simulink环境配置、CarMaker/TruckMaker基础、NI/ETAS硬件平台选型
好，咱们直接进入正题。测试环境搭建，说白了就是给咱们的MIL和HIL测试找个“家”。这个家搭得稳不稳，直接决定了后面所有工作的效率和质量。我见过太多项目，前期环境没弄好，后面调试改代码改到崩溃。所以，这一章咱们把基础打牢。
2.1 MATLAB/Simulink环境配置——你的“算法实验室”
MATLAB/Simulink，做MIL测试的核心工具。很多人觉得装个软件就行了，其实不然。配置不对，模型跑起来要么慢得像蜗牛，要么直接报错。
2.1.1 版本兼容性——血的教训
我个人习惯，先确认版本。MATLAB版本和操作系统、编译器、甚至和CarMaker的接口版本，都有严格的对应关系。我曾经在一个项目里，用了MATLAB 2020b和CarMaker 7.0，结果死活连不上。查了两天，才发现官方文档里写着“推荐使用2021a及以上版本”。
2.1.2 必备工具箱安装
做MIL测试，下面这几个工具箱是标配。少了哪个，你的模型可能就跑不起来，或者跑起来没法分析。
- Simulink：基础中的基础，不用多说。
- Simulink Test：管理测试用例、生成测试报告。我建议你从一开始就用它，别手动管理Excel。
- Simulink Design Verifier：做形式化验证，检查模型有没有死逻辑、除零错误。嗯，这个工具能帮你省下不少Debug的时间。
- Embedded Coder：如果你后续要做代码生成，这个必须装。它能把模型转成高效的C代码。
- Vehicle Dynamics Blockset：做车辆动力学仿真时，这个工具箱提供了现成的轮胎、悬架、转向模型，省得你自己从头搭。
2.1.3 环境变量与路径设置
安装完工具箱，别忘了设置路径。把你们项目的工作目录、公共库文件夹都加到MATLAB的搜索路径里。否则，每次运行模型都要手动cd，烦不烦？
% 添加路径示例
addpath(genpath('C:\MyProject\SharedLibraries'));
savepath; % 保存，下次启动自动加载这里有个小技巧：用genpath可以递归添加子文件夹。但注意，别把整个C盘都加进去，否则启动会慢到让你怀疑人生。
2.2 CarMaker/TruckMaker基础——你的“虚拟车辆”
CarMaker和TruckMaker，是IPG公司的拳头产品。它们提供了高精度的车辆动力学模型、道路场景、传感器模型。说白了，就是给你一个“虚拟车辆”，让你在电脑上就能跑各种工况。
2.2.1 模型架构概览
CarMaker的模型分三层：
- 车辆模型：包含车身、底盘、动力总成、制动系统等。你可以调整参数，比如整车质量、轮胎刚度、发动机扭矩曲线。
- 环境模型：道路、交通参与者、天气、光照。我做过一个测试，专门验证自动紧急制动（AEB）在雨天和夜间的表现，就是靠调整环境模型实现的。
- 传感器模型：摄像头、雷达、激光雷达。这些模型会输出带噪声的信号，用来测试你的感知算法。
2.2.2 与Simulink的联合仿真
这是MIL测试的核心。CarMaker作为被控对象（Plant），Simulink作为控制器（Controller）。两者通过TCP/IP或者共享内存通信。
配置步骤大致如下：
- 在CarMaker中，选择“Simulink Co-Simulation”模式。
- 设置通信步长。通常和Simulink模型的固定步长一致，比如10ms。
- 在Simulink模型中，添加“CarMaker Interface”模块。
- 映射信号：把CarMaker输出的车速、横摆角速度等信号，连到你的控制器输入；把控制器的输出（比如目标扭矩、目标制动压力）连回CarMaker。
2.2.3 场景编辑——避坑指南
CarMaker自带一个场景编辑器，可以画道路、放障碍物。我曾经犯过一个错误：在场景里放了一个静止的障碍物，但忘了设置它的“碰撞属性”。结果我的AEB算法明明检测到了它，但就是不触发制动。查了半天，发现障碍物在CarMaker里被当成了“装饰物”，不是“可碰撞物体”。
2.3 NI/ETAS硬件平台选型——你的“真实世界接口”
到了HIL测试阶段，你需要把虚拟的控制器换成真实的ECU。这时候，就需要硬件平台来模拟传感器信号、采集执行器响应。NI和ETAS是两大主流选择。
2.3.1 NI平台——灵活、开源、生态好
NI（National Instruments）的核心是PXI机箱和VeriStand软件。它的优势在于：
- 模块化：你可以根据信号类型（模拟量、数字量、CAN、LIN、FlexRay）选择不同的板卡。比如，需要模拟4个轮速传感器，就插4块模拟输出板卡。
- 开放性：VeriStand支持自定义设备驱动。如果你有特殊的传感器，可以自己写驱动集成进去。
- 与Simulink无缝集成：你可以把Simulink模型编译成DLL，直接加载到VeriStand里运行。这样，MIL测试的模型可以直接复用到HIL测试。
我个人的经验是：NI平台适合项目需求变化多、需要快速迭代的团队。因为它的硬件和软件都很灵活，改起来方便。
2.3.2 ETAS平台——稳定、高效、汽车级
ETAS（博世子公司）的核心是LABCAR系统。它的特点：
- 高度集成：LABCAR提供了从信号调理、故障注入到总线仿真的一整套方案。你不需要自己拼凑板卡。
- 实时性极强：LABCAR的实时内核非常稳定，微秒级的任务调度抖动很小。对于发动机控制、底盘控制这类对实时性要求极高的测试，ETAS是首选。
- 与Vector工具链配合好：如果你用Vector的CANoe做总线仿真，LABCAR可以无缝对接。
2.3.3 选型对比表
| 维度 | NI (PXI + VeriStand) | ETAS (LABCAR) |
|---|---|---|
| 硬件模块化 | 高，板卡种类丰富 | 中，以集成模块为主 |
| 实时性 | 好（μs级抖动） | 极好（亚μs级抖动） |
| 软件开放性 | 高，支持自定义驱动 | 中，以配置为主 |
| 与Simulink集成 | 原生支持（DLL加载） | 支持（需通过FMU或接口） |
| 典型应用场景 | ADAS、域控制器、快速原型 | 动力总成、底盘、量产ECU |
| 成本 | 中等（按需配置） | 较高（整体方案） |
2.3.4 硬件选型避坑指南
最后，分享几个我踩过的坑：
- 信号类型别搞错：模拟量输入输出，要分清是电压型还是电流型。我曾经把0-5V的传感器接到0-20mA的板卡上，结果读数全是乱的。
- 通道数留余量：选型时，按实际需求算一遍通道数，然后乘以1.5。因为项目后期往往会增加测试项，比如多测一个轮速传感器、多模拟一路CAN信号。
- 故障注入模块别省：HIL测试的一个重要功能是模拟传感器短路、断路、对电源短路等故障。NI和ETAS都有专门的故障注入板卡，别为了省钱用继电器自己搭，不稳定。
好了，环境搭建的基础就聊这么多。下一章，咱们开始动手搭建第一个MIL测试模型。记住，基础打牢了，后面才能跑得快。