一、路测基础认知：什么是实车路测？路测在ADAS开发中的核心地位
1.1 实车路测到底是什么？
实车路测，说白了就是把装了ADAS系统的车开到真实道路上去跑。
不是实验室，不是仿真环境，是真实的马路、真实的交通流、真实的天气和光照。我经常跟团队里新来的工程师说：仿真能帮你发现80%的问题，但剩下的20%，只有上路才能揪出来。
我个人习惯把路测分成三个层次：
- 功能验证路测——测这个功能“能不能用”。比如AEB能不能在目标车静止时刹停。
- 性能标定路测——测这个功能“好不好用”。比如ACC的跟车平顺性、加减速的舒适度。
- 鲁棒性路测——测这个功能“在各种场景下是否稳定”。比如雨夜、隧道出入口、强光逆光等。
核心观点：实车路测是ADAS系统从“实验室原型”走向“量产产品”的唯一验证手段。仿真可以覆盖场景，但无法替代真实传感器噪声、真实机械响应、真实驾驶员的心理预期。
1.2 为什么路测在ADAS开发中处于核心地位？
这个问题，我换个角度回答你——如果没有路测，ADAS开发会怎样？
我在2018年参与过一个项目，团队在仿真里跑了上万公里的AEB场景，所有指标都过了。结果第一次实车路测，第一脚刹车就把测试工程师吓出一身冷汗——系统在目标车距离30米时才开始制动，而仿真里设定的是40米。后来排查发现，雷达的延迟特性在仿真里被简化了。
你看，这就是路测不可替代的原因。
具体来说，路测的核心地位体现在以下四个方面：
| 维度 | 仿真/台架 | 实车路测 | 为什么路测不可替代 |
|---|---|---|---|
| 传感器感知 | 理想化模型 | 真实噪声、遮挡、多径 | 雷达/摄像头/激光雷达的真实物理特性无法完美建模 |
| 车辆动力学 | 简化模型 | 真实轮胎、悬挂、制动响应 | 轮胎非线性、制动热衰退等只能在实车中体现 |
| 环境交互 | 预设场景 | 随机交通流、行人意图 | 真实交通参与者的不可预测性无法仿真 |
| 人机交互 | 模拟操作 | 真实驾驶员接管/干预 | 驾驶员对系统行为的信任度、反应时间只能在实车中评估 |
⚠️ 避坑提醒：我曾经见过一个团队，在仿真里把AEB的触发逻辑调得特别激进，仿真成绩很漂亮。结果实车路测时，系统在高速上对路边的金属护栏产生了误触发，差点造成追尾。记住：仿真通过不等于路测通过。
1.3 路测在ADAS开发流程中的位置
ADAS开发通常遵循V模型。路测处于V模型的右侧——验证与确认阶段。
但我想强调一点：路测不是最后才做的事。我个人的做法是，在算法开发的中期就开始做“快速路测验证”，哪怕只是验证一个单一场景。这样可以尽早暴露问题，避免后期大规模返工。
下面这张图展示了路测在整个ADAS开发流程中的核心位置：
1.4 路测的核心目标：发现问题，而不是证明没问题
这是我想特别强调的一点。很多刚入行的工程师，路测时总想着“千万别出问题”。
错了。
路测的核心目标就是发现问题。 你想想看，如果在路测阶段没有发现问题，那这些问题就会在用户手里暴露出来——那才是真正的灾难。
我个人的经验是，每次路测前都会和团队说一句话：“今天如果能找到一个严重问题，这趟路测就值了。”
💡 实战技巧：路测时不要只盯着“功能是否通过”。要学会看“系统行为是否合理”。比如AEB虽然成功刹停了，但制动过程是否让驾驶员感到恐慌？ACC虽然跟住了车，但跟车距离是否让旁车道车辆觉得可以加塞？这些“软指标”往往决定了用户最终是否愿意使用这个功能。
1.5 路测的典型工作流程
一个标准的路测流程，我习惯把它分成六个步骤：
- 场景定义——明确要测什么场景（直道前车静止、弯道切入、行人横穿等）
- 测试用例设计——细化场景参数（车速、目标车距离、光照条件等）
- 路测准备——车辆检查、设备安装、数据采集系统就绪
- 执行路测——按用例驾驶，同时监控系统状态和日志
- 数据回灌与分析——把路测数据灌回仿真环境复现问题
- 问题定位与修复——找到根因，推动算法/软件修改
这里面，数据回灌与分析是我认为最关键的环节。很多问题在路测现场只能看到表象，真正的根因需要回到办公室，把传感器原始数据、CAN信号、算法中间结果逐帧分析才能找到。
⚠️ 常见误区：有些团队路测时只录了视频和CAN日志，忽略了摄像头原始图像和雷达点云数据。等到问题复现时才发现数据不全，无法定位。我曾经吃过这个亏，后来定了一条铁律：路测数据必须包含所有传感器的原始数据，一个都不能少。
1.6 本章小结
实车路测不是ADAS开发的“最后一步”，而是贯穿整个开发周期的核心验证手段。它解决的是仿真和台架无法覆盖的真实世界问题——传感器噪声、车辆动力学非线性、随机交通交互、人机信任度。
记住三个关键词：真实、随机、不可预测。这就是路测存在的意义。