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