仿真是自動駕駛領域的一項關鍵技術，能夠幫助自動駕駛汽車在模擬的極端環境中進行測試，同時，提高測試效率、降低測試成本。
然而，相對於計算機科學、晶片等其它領域，針對自動駕駛的仿真測試才剛剛起步，尚且存在著許多新問題；尤其是在實際發展過程中，整車廠、供應商以及仿真工具提供商使用的數據格式與接口沒有統一標準，導致各方之間的合作受到一定的阻礙。
近日，雷鋒網新智駕邀請了中汽數據有限公司國際標準總監周博林來進行業內分享。以下為周博林的演講內容，雷鋒網新智駕進行了不改變原意的整理：
大家好！首先我做一下自我介紹，我是中汽數據有限公司的周博林。
2017年，我加入了中汽數據，工作重心在於算法開發，包括計算機視覺算法。在此之前，我在美國和歐洲留學，也擁有一定的工作經歷。
2018年，我的工作開始從「基於數據開發算法」轉變為「從數據中去探索新的內容」。也就是說，我 2018 年更多的是在研究和處理數據之間的關係，為企業提供相應的服務。
到了 2019 年，我們逐漸發現，開發需求、企業需求以及其他需求會在一定程度上有所重疊，隨後我們聯繫到了 ASAM 組織，展開了相關的合作。
回到今天的主題上，今天主題為《ASAM OpenX 標準助力自動駕駛仿真測試落地應用》。
一、自動駕駛行業發展背景
隨著自動駕駛等級的提高，面向傳統汽車的測試工具與測試方法已不能滿足自動駕駛汽車測試的需要。比如，自動駕駛汽車無法在一些危險的場景下進行實際的測試。
因此，相比起傳統測試方式，基於場景的虛擬測試方法在測試效率、測試成本，場景覆蓋度等方面具有巨大的技術優勢，是未來自動駕駛汽車測試驗證的重要手段。而且，除了自動駕駛，計算機科學、軟體行業，以及晶片行業等領域或多或少都會通過仿真數據來進行測試，從而助力產品優化。
換句話說，仿真技術已成為當前的研究熱點。
針對自動駕駛的仿真測試是一種新的解決方案，但它與其他行業又有不同，比如晶片，晶片的輸入輸出十分穩定，每一個模塊所要解決的問題也是相對固定的。然而，自動駕駛在仿真測試中會遇到許多新問題，主要包括以下幾個方面：
缺乏有效的場景庫建設方法；缺乏自動化的生成方法和測試用例標準格式；格式轉換，動態場景、靜態地圖缺乏統一兼容格式標準；缺失統一標準接口。想要解決上面的問題，有兩種思路——立法者的思路和開發者的思路。
如果我們是立法者，我們會更加關心自上而下的體系。比如，當前這套體系是否和中國的法律法規保持一致，如何把它控制在法律法規的界限之內，如何滿足法律法規的要求。
如果我們是開發者，我們則會考慮自下而上的體系。我們需要通過大量的數據和實驗才能完善這套體系。
舉個例子，比如說我們現在立了一套法，但實際上，世界上有很多案例是在法律條款之外的。在自動駕駛裡面也有許多規則之外的未知的場景，根據這些場景來修正規則， 是自上而下的梳理。
另一方面，許多新算法和新技術的變革，其實是從下而上的變化。比如，通過一定的先驗知識去訓練模型，然後通過大量數據對模型進行優化。
上述的兩種方法，在某一時刻會打通，為了儘快實現這一目標，我們就需要一套標準化的研究體系。這也我們當前工作的關鍵點。
仿真測試的大致流程如上圖：
首先，在做測試之前，要有一個明確的測試需求。簡單來說，就是要知道測試目標以及測試內容，然後確定場景是不是符合測試需求。
第二步，把場景輸入到仿真環境中進行渲染，這一部分需要考慮的是仿真場景裡的內容和真實的場景是否保持一致，目標反射率和物理情況下的反射率是否保持一致等。
然後，確保模擬測試的輸出效果與實際情況相符合，並且達到測試的目的和預期。
這些都是我們需要攻克的難點。
具體應該怎麼操作？
首先，我們要對測試場景、駕駛動作、判斷條件進行描述，將這些信息輸入到模擬環境之中，搭建起一個仿真場景。在對仿真運行環境進行調試之後，這些信息都會傳輸到測試硬體中進行融合和處理。
在設計這樣的場景之前，除了要保證整個數據流被打通，還要在流程中的難點上得到反饋。比如記錄相應的數據，以便判斷仿真的內容是否符合測試的目的等。
其中，目前 ASAM 描述的關係就是仿真環境中的 OSC 和 XODR，一個針對地圖信息，一個針對場景信息。針對傳感器信息的為 OSI，標記數據傳感器硬體為 OpenLABEL；除此之外還有 OpenCRG等。這些內容我們之後都會詳細展開。
接下來，我們用一個具體的案例來幫助理解。
如上圖，在一個配備紅綠燈的路口，左邊有一輛自動駕駛車輛，A車，其後有一輛 B 車，A 面臨黃燈；下方是 C 車，正在等紅燈。這是一個特定的簡單的場景。
然而，如果要將這個場景搭建到仿真環境中，我們需要描述清楚這些車輛和路口的距離，要標記各種的坐標信息，還要描述車輛的速度以及其他條件信息。比如，我們需要預測結局，包括「A 車順利通過」「A 車與 B 車相撞」「A 車與 C 車相撞」。
無論是哪一種情況，我們都需要進行大量的計算，包括 A 車面臨的黃燈什麼時候切換到紅燈、A 車什麼時候能夠感知到 C 車的存在；B 車的初始速度是多少、它與 A 車的距離是多少、它對 A 車的反應如何、C 車綠燈後的反應時間是多少，它在綠燈是的行駛狀態如何；還有一些環境信息，比如天氣、道路表面、光線信息等。
除此之外，我們還需要考慮法規，比如有些國家可以闖黃燈，有些國家不可以，這些信息也需要寫進系統。
那麼，在測試流程中，如果 A 車感知到了 C 車的存在，它應該做出哪種決策？比如完全抱死，這個決策存在被 B 車追尾的風險；比如轉彎避讓 B 車或 C 車；再比如通過按喇叭的方式來讓 C 車意識到自己（A 車）的存在。
這些都是一個完整測試所需要涵蓋的參數和描述。
二、ASAM 標準助力仿真測試發展
給大家簡單介紹一下 ASAM。
1998 年，德國主要的整車廠創建了非營利性的 ASAM 組織，希望能夠打造一個工程、模擬、測試和自動化環境，在此環境中，設備和軟體應用程式可以自由互聯，數據可以無縫交換。
簡單來說就是為汽車行業制定、提高和推廣標準提供平臺。
目前的成員超過 200 個，包括 20 個整車廠。其中，主要參與者來自歐美和日本，中國 OEM 的參與者代表為上汽集團。
研究領域方面，ASAM 主要的方向有：數據管理與分析、測試自動化、軟體開發、測量與校準、診斷、ECU 網絡、仿真等。我們今天分享的重心就在於仿真方面，即描述用於駕駛和交通模擬的道路網絡、駕駛行為和測試場景的說明。
隨著駕駛和交通仿真場景測試需求的不斷增加，市場上出現了眾多來自各廠家的不同數據格式標準。
基於此，ASAM 致力於推廣 OpenX 系列格式標準，使其成為駕駛和交通仿真場景數據格式的官方標準，並承諾將其作為一項長期標準以促進未來產業發展。
ASAM 仿真格式標準整體包括以下五個方面：
OpenDRIVE 對應靜態地圖場景，負責描述地圖信息，包括高精地圖信息；OpenCRG 對應道路表面，專注於車輛動力學，以及車輛對路面信息的反饋；OpenSCENARIO 對應動態行為場景，也就是描述自動駕駛的測試場景；OSI對應仿真接口，比如傳感器仿真接口或是各種信息的仿真接口；OpenLABEL 是今年新開的一個項目，研究的是場景標籤與傳感器原始數據。
如圖所示，OpenDRIVE、OpenCRG 和 OpenSCENARIO 組成了道路及場景描述格式，OpenLABEL 負責數據方面。OpenODD 與我們之前提到的測試需求有很大的關聯，能夠幫助進一步優化決策方向。
在仿真測試的過程中，OSI 也是非常重要的一部分，這涉及到如何測試功能，以及測試的功能是否能夠達到要求。
上述這些重要的模塊組成在一起就是 OpenXOntology 以及相應領域模型。
具體來看這個體系中的內容。
OpenDRIVEOpenDRIVE 項目 2005 年由戴姆勒和 VIRES 啟動，定義了一個標準的靜態地圖格式，以實現不同仿真測試軟體的兼容性，具體是用於描述道路網絡的文件格式，涉及到駕駛模擬、交通模擬、傳感器仿真等領域。不過，OpenDRIVE 不作用於或於道路網絡交互的實體。
2019 年 1 月，OpenDRIVE 1.5 版本發布。在補充了 ASAM 標準定義及介紹、語言和語法說明、正式的數據模型之後，OpenDRIVE 1.6 版本於今年 3 月正式發布。
OpenCRGOpenCRG 於 2008 年由戴姆勒與奧迪、寶馬、保時捷和大眾共同發起，其文件格式集成在 OpneDRIVE 中，主要對路面給進行了詳細描述，以便進行輪胎模擬、振動模擬和駕駛模擬。
OpenCRG 的原始碼包括數據讀/寫和評估的 C-API，以及用於數據讀/寫、評估、生成、修改和可視化的MATLAB API。
OpenCRG 項目的啟動時間為 2019 年 8 月 28 日，到 2020 年 9 月，OpenCRG 1.2（用戶手冊和規範文件將會發布）；同時，C-和MATLAB API 1.0 也將發布。
OpenSCENARIOOpenSCENARIO（OSC）定義了一個標準的仿真測試用例格式，兼容不同的仿真測試軟體，具體用於描述駕駛模擬應用程式中動態內容的文件格式，適用場景主要包括動作、軌跡（多段線、迴旋線）、車輛（幾何、類型、軸、性能）、駕駛員（狀態）、環境等（天氣、時間、路況）。
簡單理解就是「誰在哪兒幹什麼」。
在描述的過程中還涉及非常具體的分層，比如，在一個事件板中，從活故事、動、順序、動作、事件，再到相應行動的執行。然而，隨著大數據和 AI 的發展，這種方式已經不足以覆蓋如今的測試需求。
因此，需要更高級別場景描述的指定領域語言來進行描述，即一套為自動駕駛仿真測試而生的語言。這套語言應該覆蓋開發者、認證機構、工具提供商、場景生成者等多方參與者。
那麼，這套語言就是 OSC 2.0 版本的研究重心。2020 年 3 月 16 日，OSC1.0 版本與 2.0 concept 版本相繼發布，後續版本的制定同步進行。
OSIOSI 定義了一個通用的接口，用來連接自動駕駛功能的開發和各種自動駕駛模擬框架，以實現兼容性，以期做到使任何自動駕駛功能與任何仿真工具連接，同時能夠集成各種傳感器模型。
OSI 由兩部分獨立的目標信息接口組成，即真值和傳感器數據；支持統計和物理傳感器模型兩種傳感器數據。
不過，目前 OSI 的研究內容並不能夠完全滿足自動駕駛仿真測試的需求，而是需要一個更加完整的體系，因此，OSI 將會從屋裡傳感器仿真、工具開發支撐、交通流信息、其他 Open 標準關聯進行拓展。
OpenLABELOpenLABEL 概念項目提出了一個關於標籤的標準提議，這個標準將包括標籤方法，標籤結構、文件格式等內容，旨在解決不同廠商之間數據無法互通的痛點
不過，這一項目去年年底才開始推動，目前尚處於起步階段。
三、C-ASAM和 OpenX 仿真雲工具
關於 ASAM 標準的相關工作基本上都是歐美、日本的企業在參與，作為國內的代表企業，去年 9 月 27 日，我們與 ASAM 籤訂了戰略協議，聯合成立了 C-ASAM 的工作組，為中國企業提供一個了解 ASAM 的平臺，並進行統籌管理。
目前，國內加入的企業已經將近20家，包括上汽集團、數據資源中心、騰訊、百度、華為、大疆、51VR，以及清華、北航等高校。我們也非常歡迎其他企業加入到 C-ASAM 中來。
除此之外，我們自己也開發了一套類似的工具——OpenX 仿真雲。
不同於以往的由原始場景數據通過人工方法直接轉換為測試用例，OpenX 仿真雲工具將採集到的原始場景數據通過分類標記、比對歸納、標準化基本動作整合等步驟最終形成 OSC 格式的場景文件。
中汽數據開發了用於連接現有數據與OpenX系列數據的OpenX仿真雲工具，以實現現有場景格式與OpenX格式的相互轉換和交互，優化OpenX系列數據的使用體驗，同時重點評價場景測試的覆蓋率和通過率。
OpenX 仿真雲工具四大模塊：數據檢查、場景歸納、格式轉換、雲端測試評價。
實際上，我上面說的所有內容都是幫助大家去理解，並不代表目前的體系能夠滿足所有人的需求。從某種程度上來說，把我們自己的需求在國際平臺上共享，對於標準的制定和推進會起到重要作用。
作一個測試方，我們關心的不僅僅是某一個場景下傳感器的準確度，我們更關心的是，這個場景的可遇見的，我們要解決什麼問題（感知結果融合問題）；不可遇見的場景，我們會遇到什麼樣的問題（指針問題、溢出問題、內存問題）；以及其他可能的問題。也就是說，反饋信息是我們更加關心的內容。
而且，要讓整個體系理解所遇到的問題，僅憑一兩個案例是不夠的，需要在這個環境中不斷進行迭代測試，就像硬體測試的壓力測試一樣。
以上就是我演講的全部內容，也十分歡迎大家後續跟我們進行交流，再見。
雷鋒網