在智慧駕駛系統的開發中，參考V模型開發流程，模擬測試通常包含多個階段：MIL（模型在環）—— 用於驗證理論模型，軟體在環（SIL）—— 測試軟體元件，硬體在環（HIL）—— 整合硬體元件進行測試，車輛在環（VIL）—— 模擬車輛與環境的互動，以及實車道路測試（包括封閉場地和開放道路）。
自動駕駛系統開發V字流程
V模型的左半邊代表開發階段，此階段模擬測試作為開發的一部分，主要用於驗證設計的可行性和效能。在這個階段，常用的模擬測試手段包括MIL和SIL，它們幫助工程師在早期發現潛在的設計問題。
V模型的右半邊代表量產測試階段。在此階段，模擬測試主要用於迴歸測試和效能評估，以確保產品在生產過程中保持質量的一致性，併為產品交付和量產做準備。在這個階段，常用的模擬測試手段包括HIL、VIL以及實車道路測試，這些測試手段能夠提供更接近實際執行條件的評估。
在整個V模型過程中，模擬測試扮演著至關重要的角色，它不僅在開發階段幫助驗證設計，而且在量產測試階段確保產品質量和效能。
1.MIL、SIL以及HIL之間的關聯
MIL、SIL和HIL屬於模擬測試的三種不同手段，用在車輛系統開發的不同階段，並且具有不同的目的。這三種測試手段相互補充，確保車輛系統的開發在各個關鍵階段都經過了嚴格的測試和驗證，進而有效地提高系統的整體質量和效能，降低開發風險，並加快產品上市的時間。
昆易電子演算法事業部總經理方誌剛講到：“從理論上來講，在早期開發階段，開發人員通常先使用Simulink等圖形化程式設計環境來設計和實現演算法模型，然後透過模擬執行這些模型，以驗證它們的行為是否符合預期，這就是所謂的MIL階段。
“一旦模型透過MIL驗證，下一步是將Simulink模型轉換成可執行的C程式碼。這個過程稱為自動程式碼生成。然後，軟體開發團隊再將生成的C程式碼編譯成適用於x86架構伺服器的可執行程式，進行SIL測試，以驗證軟體元件在X86系統環境中的功能正確性。”
與執行SIL測試的x86架構伺服器不同，汽車控制器更多的是使用ARM架構及專用的硬體加速晶片。因此，在SIL測試完成後，C程式碼需要針對目標控制器的硬體架構（如ARM）進行重新編譯和最佳化，以生成可在控制器上執行的可執行程式，才能進行HIL測試。
另外，他還指出，“如果在SIL或HIL測試中發現問題，可能需要回到Simulink模型進行修改，然後重複程式碼生成和測試過程。同時，在開發過程中需要考慮軟體在不同平臺（x86和ARM）上的相容性和效能。”
雖然MIL和SIL測試更多地關注功能的實現和驗證，但它們也都涉及到初步的效能評估。同樣，HIL測試雖然更側重於效能方面的驗證，但也必須確保硬體整合後的功能正確性。總之，所有這些測試都是為了確保最終系統在功能和效能方面都能滿足設計規範和使用者需求。
MIL/SIL/HIL三者的應用階段和目的
正常來講，對於智慧駕駛系統開發，模擬測試也需要貫穿整個V模型開發和測試的全流程。但是，當前主流的模擬技術平臺尚不能提供貫穿整個流程的全棧式模擬測試能力。因此，在智慧駕駛領域，行業內也未能夠嚴格遵循V模型的流程進行模擬測試驗證。
亦佩捷(IPG)汽車裝置(上海)有限公司總經理黃曉介紹說：“在智慧駕駛領域，多數主機廠很難做MIL和SIL，主要原因在於，對於不是全棧自研的主機廠，他們沒有供應商的Sensor模型、演算法模型，甚至是Simulink模型，因此主機廠沒有辦法做MIL。
“另外，雖然理論上做SIL（包括雲上SIL）的效率最高，但現在的客戶大部分是從HIL開始做；SIL難做的主要原因就是主機廠與供應商之間、供應商A與供應商B之間，都無法無縫提供引數、演算法和介面的開放。
“不同型別的企業以及針對不同系統層級做SIL所關注的點都不一樣。供應商自己也可以做SIL，但供應商做的SIL只能是針對其自己的產品，沒辦法做整個系統的SIL，因為主機廠的車輛動力學模型也不太可能對他們開放。比如攝像頭模組廠商針對攝像頭模組本身也可以做SIL，但他們關注點可能在攝像頭本身的效能和可靠性怎麼樣，比如識別率、影像質量以及噪聲和干擾等，而不會關注具體的智駕功能。”
NI大中華區智駕業務發展經理王帥則從另外一個維度談到：“SIL測試通常可以在本地單機或基於伺服器的雲模擬環境中進行，而HIL測試則基於真實的ECU硬體。這兩種測試方法在實時性方面存在顯著差異。HIL測試要求模擬環境必須以與實際感測器相同的幀率/速率提供輸入，例如，如果攝像頭的幀率是30fps，HIL測試中的模擬軟體也必須以30fps的幀率向控制器提供輸入，以確保測試的實時性。
“相比之下，SIL測試提供了更大的靈活性。在SIL測試中，可以進行加速或減速測試，模擬軟體可以以不同的幀率（如100fps或1fps）輸入給控制器，這在早期開發階段或演算法迭代中非常有用。
“此外，SIL測試由於其與開發端的接近性，以及與軟體迭代的緊密關聯，使得它在軟體開發的早期階段尤為重要。然而，隨著系統開發的進展，HIL測試的實時性優勢變得尤為關鍵，尤其是在整合和驗證硬體與軟體的互動環節。”
“SIL測試有助於快速迭代和早期問題發現，而HIL測試則確保了在實際硬體環境中的系統效能和安全性。目前行業上基本還是幾種模擬測試手段相互結合使用的一個狀態。”
總之，在V模型的每個開發階段都有其側重點和階段目標。模擬測試的實現需要結合階段目標來進行，每個階段的測試場景和模擬策略都會根據測試目標的需求來選擇。
2.低階智駕與高階智駕在模擬測試需求上的差異
在模擬測試中，低階智慧駕駛功能通常是基於一系列設計好的測試用例進行測試。測試用例可以簡單理解為片段式的場景，是從相關駕駛情境中提取的關鍵部分，用以測試特定功能，並且測試評價標準相對簡單。
同時，低階智慧駕駛的模擬測試主要集中在對規控演算法的驗證上。由於感知訊號經過處理後會轉換成object list，這種結構化的資料簡化了對感測器模型的模擬要求。
然而，高階智慧駕駛功能涉及車輛在複雜環境下的感知、決策和控制，比如在一個六岔路口對周邊的行人和車輛進行感知與規避。因此，主機廠在做模擬測試的時候，不僅要應對“後半段”的規控，還要對“前半段”的感知進行模擬測試。
高階智慧駕駛系統的架構複雜性，介面多樣性，以及高頻次的軟體更新迭代需求，為模擬測試系統的設計和維護帶來了一系列的挑戰。
黃曉認為，最好能有一個統一的測試平臺來管理各系統的介面，而不是使用不同的軟體來管理不同的介面。“只有統一了，在維護層面才能為企業提供更多便利性。”
“目前來看，模擬測試還主要偏向於功能測試。因為功能測試給客戶帶來的效用和幫助更直觀。他們可以快速透過模擬搭建測試場景，能夠高效、快捷驗證系統功能是否達標。”
他還提到，如果主機廠想驗收供應商的交付質量，除了功能測試，還需要考察效能是否達標。“但是對於效能測試，則需要花更多的力氣去搭建高精度的模型，我覺得目前在高精度的場景建模和感測器建模上都還存在挑戰。”
在系統的開發過程中，蘇州智行眾維（IAE）研發副總高彪表示，“高階智駕與低階智駕在模擬測試的需求上確實存在顯著的區別，這些區別主要體現在測試場景範圍以及測試評價上。”
-
低階功能的模擬測試重點在於車輛在特定條件下的響應，如檢測車道線、前車距離變化等。測試場景所需要覆蓋的路況和工況相對較為簡單，測試評價多依賴於成熟的測試標準。
-
而高階功能的測試場景需要根據智駕功能ODD覆蓋不同的路況、天氣環境和邊緣情況，測試場景里程及場景多樣性和覆蓋度至關重要。尤其是當智慧駕駛功能突破L2跨越到L3以後，“安全責任人”的角色也將發生轉變，測試評價將會更關注累計安全行駛里程。
低階智駕功能模擬測試VS高階智駕功能模擬測試
總體而言，低階智慧駕駛功能的開發和測試主要依賴於基於測試用例的測試方法。這種方法側重於驗證特定功能在預定義條件下的行為和效能。相比之下，高階智慧駕駛功能的開發和測試則趨向於採用基於場景的測試方法，這種方法更加關注在複雜多變的交通環境中系統的整體表現。
3.高階智駕模擬測試方案：純視覺VS多感測器融合
目前，依據感知感測器配置的不同，高階智駕方案大致可以劃分為兩大類：純視覺方案和多感測器融合方案；而國內主流車企的高階智慧駕駛方案多傾向於採用多感測器融合方案，具體的融合級別可能因企業的技術路線和產品需求而有所不同。
隨著深度學習技術在智慧駕駛領域的發展和應用，BEV+ Transformer方案已經成為當下高階智駕感知方案的主流選擇。BEV+Transformer 最開始是在特斯拉的純視覺方案上率先應用。緊接著，國內的企業又在此基礎上做了一些調整和適配，應用在了多感測器融合方案上。
BEV+Transformer 技術的核心優勢在於其能夠在 BEV 空間中進行有效的多模態資料融合和處理，提高感知效能。它可以根據不同的需求和場景與前融合、中融合或後融合方案結合使用，並不是嚴格限定於特定的融合方案。但目前，BEV+Transformer 技術更常見於前融合和中融合方案中。
BEV+Transformer 架構應用在不同融合方案
與純視覺方案相比，多感測器融合方案由於配置了更多種類和數量的感測器，因此在進行HIL模擬測試時，對計算能力的需求顯著增加。此外，不同感測器的資料幀率可能存在差異，這要求模擬系統中的多種感測器模型和模擬器必須實現精確的資料同步，增加了模擬過程的複雜性。
黃曉表示， 在高階智駕方案中，通常會採用前融合方案，在控制器內對感測器傳輸過來的原始資料進行融合。
在純視覺智慧駕駛方案中，攝像頭的配置數量通常在7到11個左右，解析度在2MP~8MP。由於攝像頭捕獲的原始資料是高解析度影片流，因此在模擬環境中對算力的需求尤為突出。為了處理這些大量的影像資料，通常需要部署多個配備高效能顯示卡的伺服器，以提供必要的計算能力支撐。
另外，他還指出，“在進行多感測器融合方案的模擬測試時，確保不同感測器之間的資料同步是一個複雜的問題。從軟體的角度來看，需要實現精確的時鐘同步和資料融合演算法；從硬體的角度來看，可能需要特定的硬體支援和介面來實現感測器之間的同步。此外，為了滿足實時性要求，整個模擬系統的效率也是一個重要考慮因素，包括資料傳輸速度、處理速度和計算資源的最佳化。因此，設計一個能夠滿足這些要求的模擬測試系統面臨著技術和工程上的多重挑戰。"
在多感測器融合方案中，確保資料傳輸的同步確實是一個不小的挑戰。方誌剛解釋說“首先，模擬軟體生成的各個感測器訊號在時間上可能存在差異，這可能是由於模擬模型的計算延遲或資料處理方法的不同造成的。其次，不同感測器的資料傳輸速度也有所不同。例如，毫米波雷達的資料量相對較小，可能很快就能傳輸完成；而鐳射雷達和攝像頭由於資料量大，傳輸時間可能需要幾毫秒甚至幾十毫秒。
“此外，各個感測器處理的幀率/頻率也各不相同。例如，鐳射雷達可能是10Hz，攝像頭可能是30Hz，毫米波雷達可能是13Hz。這些不同的幀率/頻率進一步增加了資料同步的複雜性。
“因此，解決多感測器資料傳輸同步的問題需要綜合考慮感測器的特性、資料傳輸速度、處理幀率以及同步機制的設計。這可能涉及到演算法最佳化、硬體升級、通訊協議改進等多個方面。”
另外，在高階智駕多感測器融合方案的模擬測試中，確保融合效果的準確性也是一個關鍵挑戰。王帥指出，為了提高融合效果，必須提供高質量的感測器模擬資料。這意味著模擬的資料不僅要真實反映感測器的特性，還要具有高度的同步性。在當前主流的BEV感知架構方案中，這一點尤為重要。例如，不同攝像頭提供的資料之間的時間差通常應控制在1毫秒以內，以確保資料的實時性和一致性。只有當後端處理模組接收到這樣高質量且高度同步的資料時，融合的結果才能更加精確，從而提高智慧駕駛系統的感知能力和決策質量。
除此之外，高彪還提到了一點：相對感測器的場景可靠性，即場景模型構建的其中一項準則是保證感測器資料的準確性，針對多種感測器的情況下，在場景構建時也需要考慮不同型別的感測器特性。
因為每種感測器都有其獨特的特性，如攝像頭提供的是影像資訊，毫米波雷達提供的主要是距離和速度資訊，鐳射雷達主要提供點雲資訊。
並且，不同型別感測器需要考慮的失效模式也有很大的不同，需要場景模型中考慮去包含冗餘和容錯機制，以確保系統的魯棒性。
另外，不同感測器對環境條件的適應性不同。例如，攝像頭受到光照變化的影響比較大，而鐳射雷達受到雨霧的干擾比較大，場景模型需要考慮這些環境因素對每類感測器的影響。
總之，相比於純視覺方案，多感測器融合方案因為涉及的感測器種類和數量較多，隨之涉及到的感測器協議型別越多，感測器之間的同步機制和校驗機制要求也越高。
4.高階智駕在模擬測試上存在的挑戰
1）場景覆蓋度和模擬置信度問題
高階智駕模擬測試對於場景庫和測試用例需求，主要體現在以下幾個方面：
高覆蓋度：強調場景庫儘可能覆蓋ODD內的駕駛場景，確保測試框架從基本功能驗證擴充套件至高階複雜挑戰的全面審視，包括但不限於常見駕駛情境、極端氣候條件、低頻出現的邊緣情況，形成一套由淺入深、循序漸進的測試體系，以驗證系統在各類工況下的穩定性和可靠性。
高真實性：在構建測試用例時，要求模擬環節總的交通參與者（包括行人、其他車輛等）不僅在物理行為上遵循真實世界的規律，還需在運動軌跡、互動邏輯上體現自然性和多樣性，確保測試資料與實際情況高度吻合。
高複雜性：在設計測試用例時，同時併發多個交通參與者的動態行為，包括但不限於隨機路徑選擇、非線性速度變化、緊急避險動作等，旨在創造高度複雜且難以預測的互動場景。
可重複性：要求測試用例能在一致的測試條件下被重複執行，確保每個測試用例均可進行迴歸測試。
黃曉認為當前高階智駕模擬測試所面臨最主要的兩個問題是場景覆蓋度和模擬置信度的問題。對於場景覆蓋度，主要是指Corner cases覆蓋度的問題，這些場景在我們日常駕駛中很少被碰到。雖然透過模擬手段可以非常快速地獲取或製作一些Corner cases 場景，可以去復現，並不斷的迭代。但模擬和測試之間還存在一個巨大的鴻溝，那就是模擬置信度的問題。
那麼，模擬置信度不高又是哪些原因造成的呢？黃曉表示，模擬置信度問題主要來自兩個方面：首先，模擬軟體本身建模的問題。傳統動力學模型置信度還可以，但是物理感測器模型、環境模型、天氣模型、道路模型、交通流模型置信度如何，以及整個綜合起來形成一個鏈條後，他們的加權置信度又會是多少？目前行業裡還沒有太多的驗證案例。
其次，使用者應用模擬測試的經驗和能力問題。比如一家整車廠在做車輛動力學模型的時候，願意花多少時間，願意投入多少人，用哪個部門來做，不同部門的之間的溝通效率如何，都會影響到車輛動力學模型最終的置信度。
最後，他建議到：“業界應合力搭建模擬場景平臺，並且全行業努力提升並驗證模擬的置信度，這對於行業的長遠發展將會是很大的助力。”
2）路採資料的通用性問題
某工具鏈公司的模擬負責人曾經提到，在用真實道路資料做模擬的情況下，一旦感測器的位置或者型號有變更，這一組資料的價值就會降低，甚至“作廢”。也可以用神經網路對真實道路資料做調參，這種調參的智慧化程度會更高一些，但可控性會比較弱。
當前，由於真實世界資料的複雜性和多樣性，合成資料只能在部分情況下替代真實資料，高階智駕模擬測試對路採的真實資料的依懶性還非常大。因此，路採資料通用性的問題，勢必會給高階智駕模擬測試的向前推進帶來比較大的阻礙。
高彪解釋說 ：“路採資料的通用效能力的強弱直接取決於測試中資料的使用策略。目前大部分企業在使用真實路採資料時，只是將路採資料按照域控制器的資料介面要求處理後進行資料回灌。這種使用方法確實對感測器安裝位置、安裝角度、型號，甚至車輛尺寸存在嚴格的一致性要求，一旦某個要素出現變更，測試資料就不再滿足測試要求。
“為了進一步挖掘真實道路資料的應用，將路採資料重構為模擬測試場景，結合模擬工具，透過模擬建模調整感測器引數配置、安裝位置、車輛型號等，實現路採資料的高通用性。”
3）法規和標準方面的問題
有業內人士提到，高階智駕准入仍存在巨大法規空白，短期內尚不能實現大規模的公開道路測試，絕大多數的測試將會在模擬環境中完成。然而，智慧駕駛模擬測試在法規與標準上仍存在缺失，尤其是針對高階智慧駕駛的模擬測試，缺乏統一的測試標準和評價體系。
高階智駕技術的複雜性和安全性要求遠高於傳統的駕駛輔助系統，因此需要大量且深入的測試來確保其在公共道路上的安全性和可靠性。目前的公開道路測試受到區域性、成本、時間週期等方面的限制，這促使行業尋求並依賴模擬測試手段，同時也將推動模擬測試成為確保智駕系統安全准入和量產的關鍵環節。
在高階智駕准入的問題上，高彪認為，車企在完善開發和測試流程的過程中，需要考慮與模擬更加緊密的結合，在不同的開發階段更多地運用模擬進行V&V驗證，從而縮短整體的開發驗證週期並降低測試成本。
另外，他還提到：“在法規制定和政府監管方面，也可以合理運用模擬測評手段，以提升安全監管目標。對於模擬工具及場景庫來講，合理提升模擬的真實性以覆蓋更廣的測試需求，同時擴充套件有效場景資料實現更高的場景覆蓋度是一直以來我們的目標。”
5.高階智駕出海與模擬測試
據中汽協公佈的汽車出口資料顯示，2023年，我國全年累計汽車出口491萬輛，其中傳統燃油汽車出口370.7萬輛，佔比為75.5%。同時，大多數車輛所搭載的智慧駕駛功能依然還是傳統的低階ADAS功能。
隨著國內汽車需求的逐漸趨向於飽和，以及價格戰的加劇，國內汽車行業紛紛將目光轉向海外，將“內卷”逐漸化為“外卷”。對於中國車企而言，在向海外推廣產品的時候，智慧化是其主打的“標籤”之一。因此，車企必然也希望能夠將高階智駕功能向海外推廣。
對模擬測試行業而言，針對海外當地的模擬測試市場的需求將會大大增加。高彪提議，國內車企需要進行大量的具有海外當地特色的模擬測試以確保其智慧駕駛系統在不同國家和地區的交通環境和法規要求下的安全性和可靠性，對應模擬測試場景就要相應適配海外當地的交通標誌、道路規格、駕駛習慣和相關法規等。他們作為模擬測試企業，會提供定製化的測試方案，以幫助車企實現產品的快速本土化。
“除了需求增加，模擬測試行業也面臨著不同國家資料合規的政策問題，同時模擬測試企業可能會與國際同行進行更多的合作和競爭，參與或推動相關測試標準和協議的制定，以實現國際市場的互操作性和統一標準，推動行業整體水平的提升。”他補充說到。
總之，高階智駕功能的出海為模擬測試行業既帶來了機遇，也帶來了挑戰。國內模擬測試行業需要不斷創新和進步，以適應和滿足全球化市場的需求，進而幫助中國車企將高階智駕技術更快地推向海外市場。
原文連結：https://mp.weixin.qq.com/s/1_9X26yAB_9kouh1Gbe8hg