為了不斷給自動駕駛汽車提供海量數據和極端場景以滿足安全測試的需要，仿真技術在近年來備受關注，眾多仿真平臺也應運而生。

　　在這種大背景下，英偉達將自己在圖形計算時代所積累的優勢復制到自動駕駛技術上，并且于 2019 年正式向客戶開放 DRIVE Constellation 自動駕駛仿真模擬器。

　　那么，當下無人駕駛在預期功能安全方面的進展如何?英偉達在仿真驗證方面有什么獨特的見解?

　　雷鋒網新智駕邀請了英偉達無人駕駛開發架構師楊健來進行業內分享。以下為楊健的演講內容，雷鋒網新智駕進行了不改變原意的整理：

　　大家好!我是英偉達無人駕駛解決方案架構師楊建，感謝新智駕提供的平臺，讓我們可以交流關于無人駕駛仿真方面的話題。

　　今天分享的主題為《英偉達仿真模擬方法論助力無人駕駛算法開發》，主要分為以下三個方面：

　　無人駕駛與預期功能安全;

　　英偉達仿真驗證方法論;

　　解決問題需要的規模和計算量。

　　一、無人駕駛和預期功能安全

　　首先給大家解釋一下 verification(驗證)和 validation(確認)的區別。

　　Verification，主要是驗證結果是否與預期設計相一致，即“把事情做對”;validation，則是結果在與預期設計相一致的同時，確認預期設計是否有問題，是否能夠滿足客戶的其他需求，即“做對的事情”。

　　目前，工業界有兩種驗證自動駕駛車輛安全的方法論。

　　一種是大家比較熟悉的 ISO26262 功能安全(FuSa)，這種方法論旨在預防由汽車電子電氣系統產生故障導致的意外風險隱患。

　　另一種是 ISO21448 預期功能安全(SOTIF)，這種方法論旨在解決自動駕駛系統本身由于算法或者傳感器(攝像頭、激光雷達等)本身缺陷導致致命傷害事故的問題。這也是今天分享的重點。

　　從開發流程上來說，無論是 FuSa 還是 SOTIF，都要經歷從需求定義到軟硬件開發再到系統驗證的過程，但相對來說，SOTIF 需要解決的問題難度更大。

　　就像長尾理論一樣，容易造成事故的場景基本上出現在長尾的尾部，因此，我們很難預測這些問題將會在什么時候發生，而 SOTIF 就旨在去發現這些罕見的場景。

　　也就是說，SOTIF 可以發揮指導性的意義，把這種潛在的風險進行量化評估，從而評估車輛抵御風險的能力。

　　我們可以看一下這張圖：

　　我們將所有場景分為 4 個區域，包括已知的安全場景、已知的不安全場景、未知的不安全場景以及未知的安全場景。

　　前面兩個場景相對好理解，已知的不安全場景可以通過對 ODD 進行分析來解決相關的風險。由于最后一個場景的安全的場景，因此我們對它的關注度也不是很大。

　　最需要關注的是區域3，即未知的不安全場景，由于該場景中存在著巨大的風險，如果我們對其一直處于無法悉知的狀態，我們就無法評估其中的風險會對無人駕駛帶來多大的影響。

　　所以，在 SOTIF 的開發流程中，針對已知的安全場景，我們可以通過概念定義階段來對這些場景進行足夠多的分析;針對已知的不安全場景，我們在驗證階段會去構建一些不安全的場景，然后對這些場景進行驗證，確保無人駕駛算法可以安全地解決這些問題;對于為安全的未知安全場景，我們需要一些輔助的手段來幫助我們發現場景，了解場景。

　　也就是說，我們的最終目標就是把未知的不安全場景逐漸轉化成已知的不安全場景，甚至是轉化成已知的安全場景。

　　不過，從客觀上來講，未知的不安全場景肯定不會完全消失，但它最終會小到我們足以保證無人駕駛算法出現安全事故的概率會比真人駕駛要更小，也就是說，我們可以證明無人駕駛比真人駕駛要更安全。

　　二、英偉達的驗證方法論

　　剛剛跟大家分享了英偉達對于 SOTIF 的理解，接下來給大家解釋一下，我們針對上述一些問題的方法和方法論。

　　首先，我們把整個驗證的測試過程分為幾個步驟：

　　構建一個模擬器來運行可控的環境和場景;

　　軟件在環仿真，對軟件算法模塊進行單元測試;

　　硬件在環仿真，把若干模塊和模組整合進行系統測試;

　　之后在可控的封閉道路上做整體測試。

　　所以，我們可以把上述步驟分為兩大類，即真實世界的測試里程，以及仿真環境里加速測試里程。這里的“加速”不僅是指時間上的加速，還包括了場景構建，或是其他變化的加速，從而獲得更高質量的驗證里程數。

　　從另一個維度來劃分就是軟件在環和硬件在環。一般來看，軟件在環方面，無人駕駛算法開發都在 X86 平臺上運行，因此模擬器也在相同的平臺運行。硬件在環方面，英偉達與傳統的主機廠有些不同。

　　傳統上的硬件在環一般指的是 ECU -in-the-loop，相當于只有計算單元是真實的硬件。事實上，我們所說的硬件在環還包括了其他模擬出來的傳感器和車輛控制器。

　　由于，測試對象運行在目標平臺上，計算單元的算法需要驗證的里程數巨大。所以，一套硬件并不能夠滿足需求，而是需要利用到 IT 行業已經非常成熟的并行化計算和集群化計算來提高仿真訓練效率。

　　因此，這種仿真的硬件在環平臺要能夠部署到數據中心，然后構建成集群，然后使用集群調度管理工具來進行集群化并行化運行，這種測試的場景才有可能在有效的時間內完成海量的驗證里程。

　　如此一來，硬件在環就可以做到比特級的準確，但它有一個缺點就是實時屬性太強。

　　對此，英偉達推出了 drive constellation 解決方案，這是一個虛擬的 AV 仿真硬件在環模擬器。

　　從整個仿真的結構來看，英偉達會把更多精力放在軟件在環仿真上，通過單個軟件模塊或者多個模塊進行驗證;軟件在環仿真驗證之后就是硬件在環仿真，然后這一部分的仿真工作量相對減少;通過了硬件在環仿真驗證，最后才會進入到路測階段。

　　就工作量而言，我們認為 SIL 一般占到 60-70%，HIL 在 20% 左右，剩下的為路測。

　　關于“加速”，我還想進一步解釋一下。

　　如圖，在場景 A 當中，假設綠車是我們無人駕駛算法控制的車，然后有一輛汽車想要變道超車，一次性只變一個車道，這樣的場景發生的概率很高，基本上每 10 公里就會發生一次;場景 B 中，這輛汽車在超車時跨越了兩個車道，這種場景發生的概率相比前者低，大概每 30 公里發生一次。

　　將上述兩個常見的場景參數進行一定的隨機調整，就能衍生出變種的場景。比如場景 Ax 和場景 Bx，這兩種場景都十分罕見， 1 萬公里可能才會發生一次，這也意味著這些場景更加危險，因為無人駕駛開發公司在路測時，不一定能收集到這樣的場景。

　　通過這種隨機參數化的方式來衍生出常規場景的變種場景，擴大測試的場景范圍，才有可能進一步覆蓋我們從未遇到過的風險。同時，我們可以在多個機器上一起并行測試，大大提升驗證的效率。

　　那么，我們怎么樣去應對諸如此類的場景變化?

　　正如上述提到的增加隨機參數的方式，我們推出了一種類似 Python 腳本的高級場景定義語言 HSDL。通過這種語言我們可以定義一些簡單的行為，然后通過組合方式，將它們結合成復雜的場景。目前，這種語言也在積極地為 ASAM OpenScenario 2.0 做貢獻。

　　下圖是我們基于一個場景，通過 HSDL 語言對該場景進行多次隨機化變化生成的多個場景。在多次執行中，汽車的位置、所處的地形、面臨的天氣情況都不相同，許多的變化是我們在最開始編寫場景時沒有預料過的。

　　通過這種方式來不斷地改進算法，提升無人駕駛算法的可靠性，最終形成開發流程的閉環。

　　三、計算規模的問題

　　涉及到隨機的參數變化，我們就需要思考計算規模的問題。

　　從我們的經驗來看，每個場景都需要經歷多次隨機變化才能保證覆蓋，衍生出來的場景數量基本上是在 10 的二次方級別，當然也有可能更高。

　　那假如我們有 100 個基本測試場景，那么，總的需要測試的場景(加上衍生場景)大概有 100 萬個。假如每個場景每次測試 15 秒，那么，總的測試時間大概在 40 萬個小時左右。如果有 400 套像 Constellation 這樣的設備，那么，就可以在 1000 個小時之內完成所有的驗證任務。

　　如此大的計算規模需要在產品中加入數據中心的工作流程，幫助用戶來解決大規模集群的調度工作，以及仿真驗證任務的分發工作。

　　目前，英偉達已經研發了 drive constellation cloud 集群化管理工具，用戶首先可以提交任務，隨后，系統會自動將這些任務切分，分發到集群中數百臺機器上，同時進行運行。任務運行完以后，所有數據自動收集起來，然后存放到分布式存儲中進行統一匯總，方便開發工程師取用。

　　最后我們來討論一個問題。

　　目前，我們認為有兩種主要的辦法來對感知進行驗證，一種是 Replay，即在路面采集的數據記錄下來，然后在最終驗證時進行回放;另一種是 Simulation。

　　前一種辦法的優勢就在于，這些收集到的數據都是來自真實世界里傳感器的數據，時間準確度也比較好。但同樣是因為這一點，我們沒有辦法控制輸出的信號。也就是說，這種辦法只能進行開環驗證，基本上不能做閉環驗證，而且成本也很高。

　　盡管 Simulation 在對真實世界的感知上不如 Replay，但它在很大程度上彌補了 Replay 的上述短板。為了讓 Simulation 變得真實，英偉達已經開發了效果更佳的渲染引擎。

　　好，我今天給大家分享的內容就是這些，感謝大家。

　　接下來是 Q&A 環節：

　　1. 激光雷達的反射值是怎么模擬的?

　　我們在構建靜態場景的時候就會賦予物體一些材質屬性，使得光線追蹤算法可以模擬激光的物理反射。經過對物體材質屬性的計算，最終我們可以得到一個相對準確的反射值，甚至可以模擬出同一個激光雷達的多次反射和接收。

　　2. 傳感器仿真的真實度如何評估?

　　我們會進行對比測試。通過神經網絡模型直接來評估仿真圖像的真實度，基本上是難以量化的。但我們可以通過神經網絡模型或是其他算法，來間接評判我們仿真的真實度。如果仿真模型的特性與真實采集到的數據基本一致，那么傳感器仿真的真實度就比較高。

　　3. 仿真的數據庫場景從哪里來?

　　英偉達內部使用的數據場景庫，一方面是基于我們對 ODD 的解析，比如在做無人駕駛的時候，針對定義的需求來構建場景;另一方面是來自一些公開的場景庫，使用 HSDL 語言將不同的場景隨機組合起來，生成更多的場景。

　　4. 如何保證交通流模擬，車輛軌跡和行為的仿真性?

　　簡單來說也是通過 HSDL 語言來實現。但是由于每輛車的行為都是隨機發生的，如果要確保這些行為的合理性，我們就要對隨機變量的范圍進行控制和調整。在一開始的時候，這個范圍可能會過大或者過小，從而影響仿真的場景的真實性，所以，我們需要逐步優化這個過程，對隨機參數進行手動的推理和調整。

　　5. 仿真場景中，哪些在 SIL 中測，哪些在 HIL 中測?

　　我們的基本邏輯是，盡量在 SIL 中測，因為 SIL 跑得比較快，剩下一小部分有代表性的在 HIL 中測。所以，剛剛提到的通過 HSDL 語言合成的場景主要也是以 SIL 測試為主。 HSDL 的發布時間在很大程度上取決于今年下半年 ASAM OpenScenario 2.0 的推進情況。

　　6. 高精地圖導入時怎么解決偏轉的問題?

　　其實我們在推進項目的過程中確實遇到了偏轉的問題，但由于英偉達是外資公司，很難拿到中國的無偏高清地圖。所以，我們干脆不假設自己可以拿到無偏高精地圖，我們會將中國特有的場景，以及一些影響駕駛的交通元素合成一個地圖。盡管這個地圖在真實世界不存在，但與駕駛相關的元素，比如說紅綠燈，交通信號牌或車道線，都符合真實世界的法律法規，所以我們的項目得以正常推進。
　　（邯鄲做小程序）