文章作者：莫璐怡 Pony.ai

編輯整理：Hoh Xil

內容來源：Pony.ai & DataFun AI Talk

出品社群：DataFun

注：歡迎轉載，轉載請在留言區留言。

導讀：本次分享的主題為打造最可靠的自動駕駛基礎架構。主要內容包括如何做 Pony.ai 自動駕駛系統的基礎架構，涉及到的技術困難，以及我們是如何克服的。

首先先了解下傳統網際網路公司的基礎架構：

資料基礎設施，會包括大規模的資料庫、分散式的檔案系統；

計算平臺，可能會需要大量的伺服器、大資料平臺、容器的管理機制；

Web 服務管理，同時還會有各種各樣的 Web Service，不停的迭代來滿足新的業務發展。

這是傳統網際網路公司要做的事情，但是對於自動駕駛公司和 Pony.ai，在這樣的架構基礎上我們還會做哪些事情？

這是 Pony.ai 的基礎架構，包含了所有傳統網際網路公司要做的事情，除此之外，還需要做如下事情：

自動駕駛車載系統，如何支援各種各樣的AI技術、演算法，如何控制車輛，這都依賴於自動駕駛車載系統來完成。

大規模模擬平臺，Pony.ai 每天至少會跑 30W 公里的模擬測試（很多自動駕駛公司一年跑的里程可能只有百萬級別），這點對於自動駕駛測試來說非常重要。

車隊運營基礎平臺，Pony.ai 要打造自己的移動出行服務，需要基礎平臺來支援 Robotaxi 的運營。

視覺化平臺與人機介面，視覺化平臺是幫助我們瞭解系統到底是如何思考、運作的，或者當測試工程師做各種測試的時候都依賴於視覺化平臺；人機介面，自動駕駛車輛最終是要提供出行服務，是有乘客在裡面，這時會有一個視覺化的介面，來告訴乘客車所感知的周圍環境，以及接下來的駕駛操作等等資訊，同時還會提供人機互動的功能，讓乘客也能控制車輛，比如輸入目的地，或者需要停車等等。

Pony.ai 的目標是打造自動駕駛移動出行平臺，我們希望可以在不同的城市，可以提供大規模自動駕駛車輛的運營，那麼我們的基礎架構會面臨以下挑戰：

車輛數量的增加，目前廣州已經有幾十輛車在進行測試，同時還在不停的增長著；

運營區域的擴大，剛開始只是在很小的區域進行測試，目前已經在幾百平方公里的區域進行測試；

資料量的增長，我們有很多的感測器，以及車輛和運營區域的增加，都使得資料量的增長非常非常非常大；

工程師數量的增長，目前 Pony.ai 有廣深、北京、美國四個 office，工程師的數量每週都在增長，所以導致模組數量和內部程式碼的數量也在增長。

所有的這些增長都要求我們的技術棧是具有可擴充套件性的，來滿足快速增長所帶來的挑戰。

剛剛講了整個基礎架構，其中重要的一點就是車載系統，在講車載系統之前，先簡單介紹下自動駕駛系統：

感測器及其他硬體：鐳射雷達、高解析度攝像頭、毫米波雷達、GNSS/IMU、運算平臺，我們可看到圖中標了不同的顏色，目前這些感測器是通過 Supplier Partner 來得到的，我們自己不做感測器，我們需要去購買他們的產品，但是購買之後需要做資料進一步的分析和整合，然後做後面的處理，然後對於運算平臺除了 supplier 的一些應用外，我們自己也會做一些優化。感測器主要要做的事情就是接收真實世界的資料，然後傳遞給 Pony.ai 自動駕駛系統中。

自動駕駛系統：首先，要做感測器融合，進行時間同步，將多感測器的資料融合在一起；然後是感知模組，用來感知周圍的環境有什麼樣的障礙物和物體；接下來會進行行為預測，預測這樣的障礙物或物體之後的行為會是什麼樣的；然後才到我們的決策規劃模組，按照之前的預測來決定之後車輛的動作，如急剎車、讓路、超車等動作；最後，就是我們的控制模組，他會按照決策規劃模組，告知我們的系統要怎麼做，然後決定怎麼踩剎車、油門，怎麼打方向盤。

車輛，我們本身是不造車的，所以車輛是由 OEM 提供的，但是整個控制的演算法，是我們自研去做的。

除此之外，還有高精地圖與定位模組，以及資料與系統架構（資料的處理，以及控制資料在不同模組的流動）。

這裡介紹的是各個模組，但最後把他們串聯起來，靠的是我們的自動駕駛軟體系統，這就是自動駕駛的車載系統。很多自動駕駛企業使用的是 ROS 的一套工業系統，而 Pony.ai 是從第一行程式碼開始，寫了一套 PonyBrain，自研的多層次自動駕駛車載系統，最主要的做的事情有：

多模組的排程執行，所有模組的排程執行都是 Pony.ai 自己去做的。

模組間的訊息通訊，如何把資料從鐳射雷達傳遞到感測器融合的模組，再把融合的結果放到感知模組中，然後感知的資料怎麼告訴行為預測、決策規劃等等模組，以及如何拿到高精地圖與定位的資訊。

車載計算資源的分配與管理，對於自動駕駛來說反應速度是非常重要的，這就需要我們對記憶體、CPU、GPU 等有足夠的優化，做到定製化的車載計算資源分配與管理。

日誌記錄，同時我們需要完善的日誌記錄，我們所有的測試資料回來都需要一整套的 Pipeline 去做自動化的分析，然後幫我們評判出有意義的資料，給到測試工程師或者研發工程師，進行進一步的分析去使用，然後進一步提升我們的模型。

監控與報警，保證了我們自動駕駛的安全性。

車載系統的挑戰：

① 可靠性：車載系統必須足夠的可靠，不能有任何的記憶體洩露、程式碼邏輯的錯位，這種都是零容忍的，一旦發生了這樣的事情，對整個自動駕駛系統來說是非常嚴重的事故，是有可能影響到安全性的，對於 Pony.ai 自動駕駛系統技術的發展來說，安全永遠是我們的第一位，所以所有影響安全性的事情，我們都是零容忍的，同時他也會影響車隊運營的效率；所以我們還需要系統監控與異常報警，一旦系統出現任何問題，我們需要及時提醒安全員，做出車輛接管的操作。

② 高效能：滿足模組間通訊的海量資料壓力，同時實現低延遲。

③ 靈活性：支援多種不同型別的計算資源的接入，以及不同型別模組的接入，需要有靈活的系統來支援計算資源的高速迭代。

車載系統的實踐：

可靠性：

① 程式碼質量要求高：對於可靠性來說我們有非常嚴格的 code review 和 unit test，相信這是在國內網際網路公司不太容易見到的一件事情，雖然會非常耗時，但是對可靠性的提升是有非常大的幫助的。

② 合理使用工具幫助發現問題：同時我們也會使用非常多的工具，如靜態分析、ASAN 等等，來做離線的分析，來保證系統的可靠性。

③ 多重系統可靠性檢查：包括系統啟動前校驗，系統執行時實時監控，系統執行後資料分析等。

④ 這是我們的持續整合與釋出的平臺：對於每一次程式碼的修改，我們都會進行模擬測試；然後對於研發的迭代，我們每週會有 Release 版本的更新，保障版本的穩定性，同時，剛剛我們整個測試包括封閉，半封閉，高峰期的測試，整個測試流程怎麼持續整合與釋出，也是保證系統可靠性的一種方法。

高效能：

① 合理的架構避免大資料拷貝等嚴重影響效能的邏輯。

② 依據模組邏輯分配合適的計算資源，如記憶體、CPU、GPU 等。

③ 定期對整個系統 Profile 分析系統的效能瓶頸。

靈活性：

① 定義足夠通用的模組公共介面。

② 定義足夠通用的訊息通訊介面。

為什麼需要模擬系統？因為模擬系統可以使得我們車還沒有上路的時候，就已經做了大規模的自動駕駛測試，無需路測和人力接入就可以評價系統的效能變化；由於沒有進行路測，不會引起路面事故；同時，模擬系統還提供了基於資料驅動快速迭代演算法的可行性，新的演算法可以先在模擬平臺上做驗證，一些具體的指標和測試的資訊都會在模擬平臺上有所體現。

模擬系統資料的倆個不同來源：

① 支援真實路測收集的場景，我們的路測資料非常的多，資料回來之後，通過 Data Pipeline 自動更新這些有意義和有意思的場景，我們會根據當時的場景改動相應的模組，然後會在模擬系統重跑當時的場景，來判斷新的方法是否 work；

② 支援人工和隨機生成的場景，這樣的一些模擬的場景，也是非常的重要的，因為雖然我們在做大規模的路測，但是不代表可以遇到所有的場景，很多場景無法在路測中收集到，這就需要我們通過人工去創造這樣的場景出來，給我們的系統一些樣本，來學習如何處理這樣的場景，保證我們新的 feature 在這樣的場景不會出現問題。

模擬平臺的挑戰與實踐：

① 模擬結果的可靠性：首先模擬的結果必須是可靠的，如果不可靠，用它檢測出來的結果是沒有任何的意義的。整個模擬是在服務端模擬車載環境跑的，同時在服務端構建車輛動力學模型，保證測試的資料足夠可靠。

② 模擬資料的選擇與管理：當然我們會選擇合適的路測資料來幫助演算法的迭代（這裡的選擇不是人工的選擇，是全自動化的選擇，幫我們在茫茫資料中挑選出有意義的資料）；另外，我們還會規範的依據類別管理大規模的模擬資料，比如感知模組的一些改動，到底需要測試哪些資料，才會更加的體現這個改動帶來多少影響，這裡我們會有內部的一個分類，我們不會對所有的資料進行無差別的模擬（這樣做意義不大）。

③ 模擬系統的效能：我們將整個模擬系統並行部署在分散式計算平臺中，這才可能滿足我們單天 30W 公里以上的模擬測試，並且這個資料還在不斷增長。

資料基礎架構：

資料是自動駕駛技術進步的核心驅動力，沒有資料，我們就看不到現在如此多的測試車輛在進行路測，資料本身有幾個重要的點：

① 如何儲存海量的資料，如何支援快速的訪問。

② 如何進行資料處理。

③ 如何進行資料同步，如何把不同區域、路測資料、車載資料同步到資料集中，如何讓不同辦公區的工程師都可以使用這些資料，對資料同步來說是一個很大的挑戰。

核心挑戰：

① 資料量大：我們有 PB 級別的資料，這裡只是以攝像頭為例，還包括其他感測器資料，以及系統運作的中間資料等等。

② 資料屬性不同於網際網路資料：我們的資料由客戶端產生，有大量的感測器資料、大量的模組執行日誌，這與網際網路資料有本質的區別，所以對整個資料架構的要求也是不一樣的。

資料儲存的挑戰：

① 依據特定的使用場景設計合理的儲存格式的設計：以便於車載系統記錄、大規模資料分析（資料回來之後，需要有方法進行分析，找出有意義的資料）、部分資料訪問、檔案系統儲存（如何高效的利用檔案系統）等。

② 選擇合適的儲存系統：

針對冷/熱資料選擇不同方案

選擇高可用的儲存系統

選擇易於水平擴充套件，因為車輛規模是不停的在變大的，運營時間越來越長，資料的增長速度是遠超想象的，所以需要易於水平擴充套件的儲存系統。

控制成本，不能用過於昂貴的裝置。

資料處理可以幫助收集效能指標，有 MPI（平均每次接管所需里程）、模組執行效率、乘客舒適度體驗等，還有就是路測有趣場景的挖掘，如接管、急剎、感知演算法識別、不合理的變道策略等用於模型訓練和模擬。

資料處理的挑戰：

① 減小資料採集到處理的全流程時間：如何以最快的速度把資料從車傳到中間處理系統，Data Pipeline 執行完之後，上傳到資料中心，這裡面我們做了非常多的工作。

② 依據不同型別資料處理任務選擇合適的處理系統：計算量要求比較高的我們選擇 CPU 密集型系統來處理；更多的會是車載的資料，我們會選擇 IO 密集型系統進行處理。

③ 通用的任務定義以支援靈活的新增新任務：幫我們檢測出來更多有意義的資料。

車隊運營基礎平臺：

我們有一個 Pony Pilot 專案，在我們廣州所有的內部員工都可以使用，同時在北京和美國加州，也有同樣的服務已經上線，那麼支援這樣的服務，我們需要做哪些事情：

Fleet Control Center，車隊控制中心

Pony Pilot APP

Onboard system

各種各樣的 webapp，幫助我們觀察整個車隊的運營情況，幫助管理測試的車輛和人員。

車隊運營基礎平臺的挑戰：

需要支援複雜需求變化的 web 框架，同時我們有大量的 web service 的部署與管理，這都需要我們去完善 web 服務通用元件，例如部署工具、日誌記錄平臺隨時排查問題、監控平臺保證所有 service 平臺的高可容性。

容器與服務排程平臺：

通過 Kubernetes 來幫我們做各種各樣的服務排程和叢集支援。

視覺化平臺：

① 目標：方便人類理解無人車系統看到的世界

② 挑戰：首先，需要足夠的靈活，易於適配不同需求的工具；其次，需要有高效能的現實，如 3D 實時渲染的高效實現；最後，支援跨平臺的視覺化框架，如桌面系統、移動系統、Web 等多平臺。

人機介面：

方便乘客使用的使用者介面，同時可以看到自動駕駛是如何瞭解世界，如何做決策，如何規劃之後的行為等等，給乘客更多的資訊和信任。

總結：

① Pony.ai 的基礎架構工作包括：

傳統網際網路公司所需要解決的基礎架構挑戰。

自動駕駛技術特定的基礎架構挑戰。

② 在這裡工作你可以：

接觸自動駕駛系統的各個方面。

設計並實現滿足通用需求的單機和分散式系統。

系統的保障自動駕駛技術的持續進步。

這是一個非常有意思的 team，裡面有很多有意思的工作，非常歡迎大家與我們一起來工作，推動整個自動駕駛的發展，謝謝大家！

歡迎關注DataFunTalk同名公眾號，收看第一手原創技術文章