谢邀。
太长不看，一句话版本：路测覆盖度远远不够，必须与仿真结合，才能解决自动驾驶的功能测试，以及自动驾驶的ODD边界测试问题；
图文解释版本：
要通过仿真技术赖测试自动驾驶系统，需要的是整套的端到端硬件在环测试环境。
不是那种只能测PnC的软件在环，是传感器和执行器都能模拟的真·HIL。
包含：
车辆模型，驾驶员模型，传感器模型，道路模型，环境模型（其他交通参与者），碰撞检测模块，仿真处理器，硬件板卡，等等，
被测物：自动驾驶系统；
这样一套系统，需要支持故障注入，自动测试，报告生成，后续还需要支持测试用例的泛化；
关于HIL是什么，可以先看这篇。
HIL在自动驾驶领域能做什么：
1.针对设计运行域（ODD）内的功能测试。
1）基本功能的测试
比如一个新的软件版本能否正常编译，刷写，能否进入预定的工作状态等；
2）故障注入
自动驾驶系统的传感器、执行器数量多，结构复杂，因此对于故障诊断的测试压力非常大。
通过HIL，可以模拟传感器、执行器的故障，测试对故障的诊断，以及响应策略。
2）针对Planning的功能测试
我没有写所有的planning功能，因为目前的穷举和泛化还不够成熟。但是可以通过构建虚拟的case，把路测中遇到的问题收集起来在HIL里面，进行集中测试，作为每个版本部署前必要的环节。随着测试经验积累，收集到的corner case会越来越多；
2.针对能力边界（ODD边界）的测试；
其实很多时候，我们并不知道系统能够识别什么，而不能识别什么。所以我们只能尽量多的生成测试用力，探索系统的底线。在底线内，也就是ODD之内，超出了底线的，要么优化软件，让系统能够解决，要么就把这种情况排除在ODD之外。
要尽可能多的生成测试用力，一个主流思路是泛化测试：
比如千奇百怪的异形目标，我们没法通过实际路测来覆盖，那么一个思路就是通过软件去泛化这个目标的形状、大小，来解决路测局限性的问题。
不仅可以改变目标，还可以改变环境，比如光照；
这块还不够成熟，但是一定会成为趋势。
另外，之后还有更多的关于交通的仿真，来测试自动驾驶系统的高阶规划能力；
先说这么多，想到再补充。
------------------------------------------------------------------------------------------------
