上周來自百度Apollo的資深架構師——毛繼明，為我們帶來《適用于無人駕駛的分布式仿真平臺》的社群分享，錯過社群直播的開發者可以通過此篇內容了解干貨！

本次分享主要為以下五個方面的內容：

一、仿真產品的業務價值

二、如何達到真實性

三、如何完成更全面異常檢測

四、智能輔助駕駛和全自動無人駕駛的區別

五、全面的無人車能力判定

{ 一 }

仿真產品的業務價值

仿真器，顧名思義，就是用軟件模擬真實。但在 Apollo 中，對仿真平臺的定位是不僅僅是真實，而是要能夠進一步：能夠發現無人車算法中的問題。因為在整個算法迭代閉環中，光有擬真是不夠的，還需要能夠發掘問題，發現了問題后才能去 fix 問題，也就是回到了開發過程。

如此這樣，從開發到仿真再回到開發，仿真平臺同我們的開發過程串聯成一個閉環。只有閉環的東西才能構成持續迭代和持續優化狀態。所以仿真平臺在整個無人車算法迭代中的地位非常重要。

如上所述，仿真平臺的功能。

發現問題，進行功能拆解的話，可以拆成有因果關系的兩部分：

先要能夠真實，接下來要能夠進行全面的異常檢測。真實性，就是說要能夠對世界進行數學建模；全面的異常檢測，其中最難的是“全面”二字，這要看我們對“全面的異常”的定義。

{ 二 }

真實→客觀世界的數學建模

客觀世界的真實性表達依賴于三部分：靜態環境的真實性、動態環境的真實性、車輛行為（也就是主車）真實性。

準確來說，對于靜態環境的真實建模本身并不難，比如游戲畫面中，我們能經常看到“照片畫質”的渲染，看著都很真。最難的是“成本”兩個字，這個成本指的是：單位公里上全部環境建模的時間成本。無人車的場景重建跟游戲中不一樣。游戲中是藝術家造出的場景，它不考慮真實。而真實仿真器中的場景是要跟真實世界做 diff 的，需要做到毫厘不差。

1靜態環境的真實性

靜態環境是相對于動態障礙物而言的，比如道路（包括各種地面元素）、柵欄、紅綠燈、路旁的路燈和綠植兩側的高樓。對于自動駕駛來說，它們屬于背景元素。當然大家能夠理解這跟行人、車輛等動態障礙物的不同。

大家都有過這樣的經驗，我們自己得到一個結果，這很簡單，但若要讓自己得到一個跟別人一模一樣的結果，這個成本就大太多了。百度內部有成熟的百度高精地圖制作流水線，在厘米級精度的世界刻畫能力的基礎上，成本做到非常低。

那么大家會問，講了這么多地圖生成的事，這跟仿真有什么關系？其實，Apollo 仿真器的靜態世界的表達，正是直接使用了 Apollo 高精地圖數據。所以它是真實的，且是具有足夠低成本的。

2標題內容

然后是動態環境，也就是各種障礙物的行為真實性了。動態障礙物引入了人的因素，相對靜態場景重建更難，因為人的行為“難以捉摸”。對于 Apollo 而言，最快和直接的做法，不是擬真，而是直接“真”。

用實際路上采集回的海量真實數據，經過 Apollo 感知算法，做動態場景重建。一方面，我們通過 Apollo 數據生態，會得到更多的數據用來補充場景，另一方面我們利用自身持續迭代的感知算法可以更精準的還原世界。從量和質上都得到持續的提升。

3車輛行為的真實性

主要分傳感器模擬和車輛動力學模擬。由于傳統的商業仿真軟件在這兩個領域已經進行了數十年的研發，成果已經被各大車廠所認可。Apollo 倡導開放能力、合作共贏，所以這兩塊功能 Apollo 仿真平臺是以直接 involve 商業仿真軟件的方式實現這兩塊 feature。后面在講開放性的時候會提到。

{ 三 }

全面的異常檢測

在滿足了真實性后，我們來看看如何完成下一個需求：更全面異常檢測。

其實大家都知道，尤其是搞 IT 的同學可能會更清楚。所謂異常檢測，就是先給一個條件，再給一個預期輸出。就是大家寫的 UnitTest 的常用版型。方法論上都是一樣的。那么對于無人車的異常檢測，什么是條件呢？就是車輛運行的場景。什么是預期輸出？就是要有一整套判定準則或者說判定算法。

顯然，要做到全面的異常檢測，這里重點或者說難點，肯定不在后四個字，而在于前面兩個字“全面”。場景，要是全面的場景；判定，要是全面的判定。

全面的場景。全面這兩個字很虛，而且“100% 全面”在理論上也無法達到。所以，唯一可行的做法是：在受限場景下逼近 100%。這個“受限場景”，換種說法，就是我們無人車算法的問題域定義，也就是說這個算法要解決哪一種受限場景。不同的應用場景，仿真器的設計可能會大有不同。目前以我的理解，能夠對仿真器設計產生革命性變化的，只有一種問題域的劃分方式，就是智能駕駛 vs 無人駕駛。具體怎么個革命性變化，后面會講。

全面的判定。這個取決于算法能力域的設計。什么叫算法能力域？就是指算法能達到的上限，也就是說，是 just work，還是 work well。對于判定算法而言，如果僅僅是做“just work”級別的判斷其實并不難，難在對“work well”做判斷。所以這里，也有一個對仿真器算法產生重大影響的能力域的劃分方式，就是： “機器人型駕駛”（just work）的判定，以及“擬人型駕駛”（work well）的判定。

{ 四 }

智能駕駛 vs. 無人駕駛

準確來講，無人駕駛屬于智能駕駛的一個分支，這么寫可能不太確切。但是，我想強調的是，這其中有一個非常大的差異，無人駕駛和自動駕駛之間的，就是：是否有人。

“是否有人”這個事情，對整個智能駕駛無論是算法、還是硬件設計、還是仿真器的設計，都產生了極大的影響。“沒有人來保底”決定了算法需要應對的占比從 80% 到 99.9999%。大家都了解二八法則。從 80% 到 99.9999%，無論是算法、還是硬件、還是仿真，需要解決的問題或者說面臨的困難要提高幾個數量級。

{ 五 }

復雜城市道路 +99.9999%

99.9999% 是無人駕駛特有的要求。而 99.9999% 需要的是算法“見多識廣”。要解決長尾問題，也就是要應對全自動無人駕駛的 99.9999% 的場景 handle 能力，必須要累計起【海量場景】。

也許大家對海量場景這個事情并沒有太多感覺。在實際的生產領域，擁有海量場景其實不是難事，難就難在海量場景的使用效率。前面講到了，算法需要高速迭代，我們的用戶需求是：30 分鐘，仿真平臺能告訴我們什么。30 分鐘，可以算算，平均時速 30km/h，只能跑 15 公里，如果是這種能力的話，其實不用談海量場景。

所以從百度內部最開始進行無人車項目時，就已著手考慮仿真平臺的運行效率。Apollo 仿真平臺通過 2 個不同層次的實現方式來進行大幅度優化。從宏觀角度出發，通過大規模分布式化來進行；所以Apollo 仿真從最開始，就是以分布式仿真作為方向的。從微觀角度出發，通過動態變速仿真來進行。

{ 六 }

大規模分布式的架構設計思考

這個是分布式仿真框架的簡圖。了解分布式計算框架的同學應該比較熟悉。整體上看，分布式仿真架構按層次和功能，可以按照如下幾部分進行說明：

由于分布式仿真平臺的計算模型很像傳統的 MapReduce。所以整個分布式調度 follow 傳統的 MR 架構。

下層是 Hardware Resource Scheduler。由于仿真節點的運行會用到 GPU+CPU/only CPU/CPU+FPGA 多種硬件組合，又由于仿真的運行是一種彈性的資源使用。所以我們單獨的剝離出來一層 Hardware Resource Scheduler。這層 Scheduler 是支持更換的。比如在百度內部，我們使用了百度內部已有的資源調度器 Matrix，如果是在開源系統里，我們支持使用 K8S，再比如我們跟 Microsoft azure 合作的 Apollo Simulation Global 中，我們使用了 MS 的 cosmos。未來如果做大客戶定制化，我們也可以支持大客戶內部專門的 Resource Scheduler。

上層是 Batch-job Scheduler。因為分布式仿真運行模式為 Batch-job，所以我們單獨剝離了一層 Batch-job Scheduler。它負責 job 的整個生命周期的運行狀態的推進，比如各種部署、啟動、運行狀態檢查、重試、優先級、彈性伸縮……等邏輯。這塊同樣的，我們單獨剝離出一層的原因在于，我們解耦了這層標準化的分布式計算模型，也允許根據用戶特別的需要進行替換。在內部我們使用了百度的 Normandy 調度框架，在外部我們支持更換成業界主流的 K8S 等。

中間這層是仿真核心。它運行在 Docker Container 中。仿真核心中運行的是客戶的算法 + 仿真邏輯：包括場景重建 + 動力學模型 + 精細化度量。由于運行模型復雜，所以我們在 Container 內抽象了上下兩層：上層，我們內部叫做 Task Engine，專門負責復雜的仿真執行流程調度。下層是 Sim-Core，用來放置用戶的自己的算法。

在外層有兩個 Storage Component：Scene Store，Result Store。圍繞著計算，統一管理了數據。Simulation-platform 主要提供了提交接口、數據分析、Dashboard 接口，串通起完整的仿真流程，供用戶使用。

{ 七 }

動態變速仿真技術

這里做一下對比，真實道路情況下，車載算法是在車載電腦上運行，實時性要求很高，所以往往需要保留較多的系統資源冗余（以應對隨時到來的系統處理顛簸的情況），萬一出現顛簸狀態，實時系統會采用丟幀的方式以保證運行時消息處理的低延遲。

在仿真系統里，這是在離線運行。如果不做任何處理，我們需要用更強力的服務器，保留更多的系統資源，或者降低運行速率，以保證不丟幀。很顯然，這種做法一方面帶來大量的運行資源的閑置，另一方面降低了我們的運行速度。所以我們引入了動態變速仿真技術。

動態變速仿真技術，本質上是對無人車復雜數據流進行流控的過程。分解來講：

1）對于處理時間較短的幀，壓縮了數據處理的間隔；

2）對于處理時間較長的幀，等待處理完成再繼續處理后續的幀。

而整個調度系統是一種根據當前處理幀的耗時做彈性變化。

通過這兩項改造，可以達到：不等待 & 不丟幀，這樣就可以充分的利用硬件資源，以最快速度運行。據實際測試，采用了動態變速仿真技術，在不影響仿真結果的前提下，單機仿真效率可以提升數倍以上。

{ 八 }

全面的無人車能力判定

從自動駕駛的能力上看，能力分成兩個層面：低端能力（能 work）以及高端能力（像人一樣 work well），所以從能力判定的算法上，會有較大的不同。后一種（高端能力級別的判定）很顯然是非常有挑戰的。

我們先看一下低端的能力判定方法，它包括了兩層判定：

Level1：模塊的運行可靠性判定。類似模塊的 coredump、非法 exit、幀率異常等。

Level2：無人車基礎能力的判定。包括：到達目的地、碰撞、違章等。

很顯然，這樣的兩層判定可以通過“通用的規則”來實現。但是此時的通用僅僅代表了無人車能力的下限已經達到。此時無人車僅僅是能夠像是機器人一樣進行駕駛。

既然有低端能力，就對應有高端能力。何為高端能力？——像自然人一樣開車，可以通過圖靈測試。它仍然包括了兩層判定：

Level3：體感判定。體感判定包括了橫擺角，頓挫感等評估體系。

Level4：心理感受。心理感受包括了心理安全感以及遲鈍感等。

高端能力的判定。可以是一種圖靈測試的驗證，是場景特化的。它代表了無人車的能力的上限。

實際上，度量算法的本質可以認為是：f(場景描述，車輛軌跡)，即某種場景和軌跡的二元函數。當我們擁有大量的正例以及負例，我們通過機器學習方法，基于大量數據，是可以得到一種具有足夠泛化能力的，并且能夠達到圖靈測試判定能力的度量能力。

事實上，百度長期的無人車路測，使仿真擁有了大量的實際的運營 / 路跑數據，我們針對性的大量采集、標注了細粒度的體感異常的 badcase 樣本，進而可以達到相當精準的異常判斷能力。我們會在 Apollo 中將這樣的能力釋放給大家。