2. 测试环境搭建：硬件在环（HIL）测试平台、软件在环（SIL）测试平台、真实路测环境搭建、数据采集设备选型与配置
做导航系统测试，最头疼的问题是什么？
我个人的体会是——你永远不知道真实场景里会遇到什么鬼情况。卫星信号被高楼遮挡、多径效应导致定位漂移、IMU 温漂累积……这些问题在仿真环境里很难完全复现。
所以，测试环境搭建这件事，说白了就是给导航系统安排一场「模拟考试」。考得好不好，直接决定了它上路后会不会掉链子。
这一章，我就把三种主流测试平台——HIL、SIL 和真实路测——的搭建方法掰开揉碎讲清楚。嗯，还会聊聊数据采集设备怎么选，毕竟「巧妇难为无米之炊」嘛。
核心观点：测试环境不是越贵越好，关键是「匹配你的测试目标」。HIL 适合验证硬件接口，SIL 适合算法快速迭代，真实路测则是最终验收。三者缺一不可。
2.1 硬件在环（HIL）测试平台搭建
HIL 测试，说白了就是把真实的硬件控制器（比如你的导航板卡）接入一个仿真环境里。你想想看，卫星信号、IMU 数据、轮速脉冲……这些传感器信号都由仿真机模拟生成，然后通过物理接口送给被测设备。
我在项目中遇到过最典型的情况：某款导航板卡在实验室跑得好好的，一上车就出问题。后来查出来是 CAN 总线上的终端电阻匹配不对，导致信号反射。这种问题，在纯软件仿真里根本发现不了。
HIL 平台的核心组件
- 实时仿真机：比如 dSPACE、NI PXI、Speedgoat。我个人习惯用 NI PXI，主要是生态成熟，LabVIEW 写测试脚本很方便。
- 信号调理板卡：把仿真机输出的弱信号转换成真实的传感器电平。比如 GPS 模拟器输出的射频信号，需要经过衰减器、功分器再送到接收机。
- 故障注入单元：模拟短路、断路、信号跳变等异常。嗯，这个很重要——导航系统最怕的不是正常工况，而是异常工况。
- 负载模拟器：模拟真实的电气负载，比如电机、电磁阀等。
我的经验：搭建 HIL 平台时，接地问题一定要处理好。我曾经因为仿真机和被测设备共地不良，导致 CAN 通信间歇性丢帧，排查了整整两天。后来在信号调理板上加了隔离模块，问题才解决。
HIL 测试的典型流程
- 搭建仿真模型（车辆动力学、传感器模型、环境模型）
- 配置 I/O 接口映射（哪些信号走 CAN，哪些走模拟量）
- 编写测试用例（正常工况、边界工况、故障注入）
- 执行自动化测试（通常跑 24 小时以上）
- 分析结果，生成报告
2.2 软件在环（SIL）测试平台搭建
SIL 测试，就是把整个导航算法放在 PC 上跑，不涉及真实硬件。你想想看，这样做的好处是什么？快！ 改一行代码，编译、运行、看结果，几分钟搞定。HIL 的话，光烧录固件就得半分钟。
我建议把 SIL 作为算法开发阶段的主力测试手段。比如你写了一个新的多路径抑制算法，先在 SIL 里用录制的真实数据跑一遍，看看效果。没问题了，再烧到硬件上做 HIL 验证。
SIL 平台的搭建要点
- 仿真环境：MATLAB/Simulink、Carla、Gazebo 都行。我个人偏爱 Simulink，主要是和模型开发无缝衔接。
- 传感器模型：GPS 模拟器（比如 Spirent GSS7000 的软件版本）、IMU 模型（考虑温漂、噪声）、视觉模型（考虑光照变化）。
- 场景编辑器：定义车辆轨迹、障碍物、天气条件等。
- 数据回放工具：把真实路测采集的数据灌进去，做「开环测试」。
注意：SIL 测试不能完全替代 HIL。为什么？因为 SIL 里没有考虑硬件延迟、中断优先级、资源竞争这些实时性问题。我曾经在 SIL 里跑得好好的算法，移植到嵌入式平台后，因为浮点运算太慢导致超时，定位结果直接崩了。
2.3 真实路测环境搭建
真实路测，是检验导航系统的最终考场。不管你在仿真里跑得多漂亮，最终都要上路见真章。
搭建路测环境，我总结了三个关键点：
2.3.1 测试车辆改装
- 供电系统：加装逆变器和稳压电源，给测试设备供电。注意不要和车辆原车电路混在一起，防止干扰。
- 设备安装：GPS 天线放在车顶中央，IMU 固定在车辆质心附近。嗯，这个位置很关键——离质心越远，角速度测量误差越大。
- 数据记录：用工业级工控机（比如 Advantech 的）做数据采集，SSD 硬盘，至少 1TB 容量。
2.3.2 参考系统配置
路测必须有一个高精度参考系统，用来评价被测系统的性能。我常用的配置：
| 设备 | 精度 | 用途 |
|---|---|---|
| NovAtel PwrPak7 | RTK 模式下 2cm | 位置真值 |
| iXblue ATLANS-C | 航向 0.1° | 姿态真值 |
| OXTS RT3000 | 速度 0.05 km/h | 速度真值 |
避坑指南：我曾经在一条高架桥下做路测，参考系统的 RTK 信号频繁失锁，导致真值数据断断续续。后来学乖了——路测前一定要先踩点，避开高架、隧道、密集建筑区。如果必须经过这些区域，那就多准备几套参考系统做冗余。
2.3.3 测试场景设计
不要只跑「好路」。我建议至少覆盖以下场景：
- 城市峡谷：高楼遮挡，多径效应严重
- 隧道：完全无 GNSS 信号，考验惯导推算能力
- 林荫道：树叶遮挡，信号衰减
- 高架桥下：部分遮挡，信号跳变
- 急转弯/急加速：考验 IMU 的动态响应
2.4 数据采集设备选型与配置
数据采集设备，说白了就是导航系统的「黑匣子」。选得好，事半功倍；选不好，数据丢了或者质量差，整个测试白做。
2.4.1 核心采集设备
- GNSS 接收机：至少支持双频（L1/L2），最好支持多星座（GPS+北斗+GLONASS）。采样率 10Hz 以上。
- IMU：战术级或导航级，陀螺零偏稳定性 < 1°/h，加速度计零偏 < 1 mg。
- 数据记录仪：支持多路 CAN、串口、以太网同步采集。时间戳精度 < 1ms。
- 时间同步模块：用 GPS 秒脉冲（PPS）做全局时间同步。嗯，这个很重要——不同传感器的时间不同步，融合算法会出大问题。
2.4.2 选型建议
| 设备类型 | 推荐型号 | 关键指标 |
|---|---|---|
| GNSS 接收机 | u-blox F9P | 双频、RTK、100Hz 原始观测量 |
| IMU | ADI ADIS16470 | 战术级、SPI 接口、温补 |
| 数据记录仪 | Vector VN1630 | 4路CAN、2路LIN、1ms 精度 |
| 时间同步 | Trimble BD982 | PPS 精度 20ns |
重要提醒：数据采集设备的时间同步是重中之重。我见过一个项目，因为 IMU 和 GNSS 的时间戳差了 50ms，导致组合导航算法发散，定位误差从 2 米漂到了 50 米。后来加了 PPS 同步，问题才解决。
2.4.3 数据采集配置示例
下面是我常用的一个数据采集配置脚本（Python 伪代码）：
# 数据采集配置示例
config = {
'gnss': {
'port': '/dev/ttyUSB0',
'baudrate': 115200,
'rate': 10, # Hz
'messages': ['GGA', 'RMC', 'RAWX']
},
'imu': {
'port': '/dev/ttyUSB1',
'baudrate': 921600,
'rate': 200, # Hz
'output': 'quaternion + acceleration'
},
'can': {
'interface': 'can0',
'bitrate': 500000,
'ids': [0x100, 0x200, 0x300]
},
'sync': {
'source': 'pps',
'tolerance': 0.001 # 1ms
}
}嗯，到这里，测试环境搭建的核心内容就讲完了。你可能会问：这三种平台到底怎么选？我的建议是——按阶段来：算法开发阶段用 SIL，硬件集成阶段用 HIL，最终验收用真实路测。三者配合，才能把导航系统的性能测透。