第四章：测试环境搭建
4.1 硬件在环测试平台
硬件在环测试，简称HIL，是我个人认为最「实在」的测试手段。为什么这么说？因为它是把真实的控制器——也就是ECU——接入到仿真环境中去跑。你想想看，传感器信号、执行器响应，全都是真实的硬件在干活。
我在搭建HIL平台时，一般会关注三个核心部分：
- 实时处理器：用来跑车辆模型，比如动力学模型、发动机模型。我习惯用NI的PXI或者dSPACE的Scalexio，响应时间能控制在微秒级。
- IO接口板卡：负责把仿真信号转成真实的电压、电流、PWM波。说白了，就是让ECU以为它真的连在车上。
- 故障注入单元：这个很关键。我曾经在测试AEB功能时，故意把轮速传感器的线断开，看看系统会不会报错。没有故障注入，很多隐藏问题根本发现不了。
重要提醒：HIL平台的实时性要求很高。我见过有人用普通PC跑模型，结果仿真步长一抖，测试结果全废了。记住，实时内核是必须的。
搭建步骤其实不复杂，但细节多：
- 先把车辆模型编译好，下载到实时处理器中。
- 然后连接IO线束，注意屏蔽和接地，不然噪声会让你抓狂。
- 最后做一次开环验证——给一个固定输入，看输出对不对得上。
4.2 软件在环测试平台
软件在环，简称SIL，说白了就是纯代码跑仿真。没有硬件，只有算法模型在PC上运行。我刚开始做ADAS测试时，总觉得SIL不够「真实」，后来发现它其实是效率最高的环节。
SIL平台的核心是：
- 算法模型：比如感知、决策、控制模块，通常用Simulink或者C++实现。
- 环境仿真器：我常用CarMaker或者VTD，用来生成虚拟的交通场景。
- 数据接口：把算法和环境连起来，比如通过UDP或者共享内存通信。
嗯，这里要注意：SIL的仿真速度可以比真实时间快很多。我习惯把场景跑在10倍速下，一个小时的测试十分钟就搞定了。但有个坑——模型精度不够时，加速跑会掩盖一些时序问题。我曾经吃过这个亏，后来老老实实加了个实时同步模式。
个人技巧：SIL测试最好和HIL共用一套测试用例。这样从SIL转到HIL时，结果可以直接对比，定位问题快很多。
4.3 整车在环测试平台
整车在环，简称VIL，是把真实车辆放在转鼓或者测试场地上，但环境是虚拟的。你想想看，车在动，但看到的障碍物、行人都是仿真生成的。这个平台我用的不多，但每次用都印象深刻。
VIL平台的组成：
| 组件 | 作用 | 我常用的方案 |
|---|---|---|
| 转鼓或测试场地 | 提供真实的车辆运动 | MAHA转鼓或封闭测试场 |
| 目标物模拟器 | 生成虚拟的障碍物、行人 | 4activeSystems的软目标 |
| 数据同步系统 | 把车辆位置和虚拟场景对齐 | RTK-GPS加惯导 |
搭建VIL时，我最头疼的是同步问题。车辆的实际位置和虚拟场景必须毫秒级对齐，否则你看到障碍物在左边，车却往右边躲，那测试就废了。我建议用RTK-GPS加惯导组合，精度能到厘米级。
安全警告：VIL测试中车辆是真实运动的。我曾经见过一次测试，虚拟场景里的障碍物没生成，驾驶员差点撞上转鼓的护栏。所以，一定要有紧急制动按钮和物理围栏。
4.4 数据采集系统
数据采集，说白了就是记录测试过程中所有信号。没有数据，你拿什么分析问题？我习惯把采集系统分成三层：
- 车辆总线数据：CAN、CAN FD、以太网。记录车速、转向角、制动压力等。我用Vector的VN1640，稳定可靠。
- 传感器原始数据：摄像头图像、激光雷达点云、毫米波雷达目标列表。这个数据量很大，我一般用SSD阵列存储，一小时测试能产生几百GB。
- 环境同步数据：GPS时间戳、场景编号、测试用例ID。没有这些，你事后根本不知道这段数据对应哪个场景。
我曾经犯过一个低级错误：采集时忘了加时间同步。结果分析数据时，CAN信号和图像对不上，差了几十毫秒。后来我强制要求所有采集设备都用PTP协议同步，精度到微秒级。
关键指标：数据采集系统的延迟不能超过1毫秒，否则会影响后续的算法回放验证。我建议用专门的采集工控机，别用普通笔记本。
搭建数据采集系统的步骤：
- 先确定需要采集的信号列表，别贪多，够用就行。
- 然后配置采集设备，比如设置CAN通道的波特率、以太网的IP地址。
- 最后做一次预采集，检查数据完整性。我习惯跑一个简单的直线加速场景，看看所有信号是不是都在。
好了，这四种测试平台的搭建方法，基本覆盖了ADAS耐久性和可靠性测试的需求。我个人建议，先从SIL开始，快速验证算法逻辑；然后转到HIL，检查硬件接口；最后用VIL做整车级验证。数据采集贯穿始终，别偷懒。