謝邀。
太長不看，一句話版本：路測覆蓋度遠遠不夠，必須與仿真結合，才能解決自動駕駛的功能測試，以及自動駕駛的ODD邊界測試問題；
圖文解釋版本：
要透過仿真技術賴測試自動駕駛系統，需要的是整套的端到端硬件在環測試環境。
不是那種只能測PnC的軟件在環，是傳感器和執行器都能模擬的真·HIL。
包含：
車輛模型，駕駛員模型，傳感器模型，道路模型，環境模型（其他交通參與者），碰撞檢測模組，仿真處理器，硬件板卡，等等，
被測物：自動駕駛系統；
這樣一套系統，需要支持故障註入，自動測試，報告生成，後續還需要支持測試用例的泛化；
關於HIL是什麽，可以先看這篇。
HIL在自動駕駛領域能做什麽：
1.針對設計執行域（ODD）內的功能測試。
1）基本功能的測試
比如一個新的軟件版本能否正常編譯，刷寫，能否進入預定的工作狀態等；
2）故障註入
自動駕駛系統的傳感器、執行器數量多，結構復雜，因此對於故障診斷的測試壓力非常大。
透過HIL，可以模擬傳感器、執行器的故障，測試對故障的診斷，以及響應策略。
2）針對Planning的功能測試
我沒有寫所有的planning功能，因為目前的窮舉和泛化還不夠成熟。但是可以透過構建虛擬的case，把路測中遇到的問題收集起來在HIL裏面，進行集中測試，作為每個版本部署前必要的環節。隨著測試經驗積累，收集到的corner case會越來越多；
2.針對能力邊界（ODD邊界）的測試；
其實很多時候，我們並不知道系統能夠辨識什麽，而不能辨識什麽。所以我們只能盡量多的生成測試用力，探索系統的底線。在底線內，也就是ODD之內，超出了底線的，要麽最佳化軟件，讓系統能夠解決，要麽就把這種情況排除在ODD之外。
要盡可能多的生成測試用力，一個主流思路是泛化測試：
比如千奇百怪的異形目標，我們沒法透過實際路測來覆蓋，那麽一個思路就是透過軟件去泛化這個目標的形狀、大小，來解決路測局限性的問題。
不僅可以改變目標，還可以改變環境，比如光照；
這塊還不夠成熟，但是一定會成為趨勢。
另外，之後還有更多的關於交通的仿真，來測試自動駕駛系統的高階規劃能力；
先說這麽多，想到再補充。
------------------------------------------------------------------------------------------------
