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