在本次技術沙龍中，來自Apollo團隊計算平臺的資深研發工程師-羅琦老師帶了關于Apollo3.0 PnC更新以及車輛開放平臺的講解。

這里，我們將整理后的視頻資料及內容分享給大家，沒能到達現場的開發者可以通過視頻和PPT資料來詳細了解課程內容。

演講概要：

安全是自動駕駛前行的保障，尤其是對于 L4 級別的自動駕駛系統，功能安全更是一個全新的領域與挑戰。本演講將分享 Apollo 在功能安全方面的探索。

Apollo3.0 PnC更新以及車輛開放平臺介紹

1Apollo Roadmap

這里分享一下Apollo在3.0里面的相關更新，以及車輛開放平臺的一些介紹。

首先為大家介紹下Apollo的Roadmap。今年7月份，Apollo發布了3.0版本，并升級發布了ASU、Hardware Flexibility、Labelled Obstacles。其中在感知模塊我們也部署了新的檢測方案；而新增加的Guardian-Safety Module是Apollo平臺關于功能安全新的嘗試；在Monitor也更新了對硬件的檢測、軟件的功能檢測，為了和Guardian系統一起形成一個完整的Functional Safety的嘗試；在3.0版本中，我們又接入了新的Sensors——毫米波雷達，以及升級版的Hardware Development Platform。

2Apollo Open Software Platform 更新Guardian &Monitor

首先是 Guardian和Monitor模塊。Monitor是狀態監控模塊，Guardian是在3.0版本中新加入的一個功能模塊。這兩個模塊是開放平臺對于Functional Safety和Fault Handling的嘗試。

Monitor主要實時監控硬件和軟件各個模塊的健康狀態，比如功能模塊——Perception、Prediction、Planning、Control、Roadmap、Localization，同時監測一些信號是否延時，以及是否有收到一些重要的信號?；诖?，如果發現一些非正常行為、系統模塊報錯，就會通知Guardian模塊進入安全模式，同時會在Dreamview上通過不同的聲音和畫面方式提醒駕駛員在10秒鐘內需要接管。

之前的Control直接跟CAN Bus模塊進行通訊。現在由于接入了 Guardian，在 Guardian下存在兩個工作模式。在正常的模式下，Guardian會直接轉發Control的Signal到CAN Bus，如果當超聲波傳感器正常工作并且前方沒有檢測到障礙物的前提下，嘗試在10s內緩緩停車。如果超聲波傳感器在監測的整個過程中信號沒有輸出、輸出不符合預期或者是Ultrasonic Sensors檢測到障礙物，我們會采取緊急措施來防止碰撞。

Relative Map

Relative Map最初是在 Apollo2.5 中發布的，其目的是在一些相對簡單的路況上，降低對于高精地圖的依賴。在 Apollo 2.0 以及之前的開放版本中，高精地圖主要用于3D雷達的監測、2D相機紅綠燈監測以及定位模塊的多傳感器融合和DreamView的顯示。這些功能都對高精地圖有很強的依賴。在Apollo 2.5中，我們主要依賴攝像頭來作為進行障礙物和車道線的監測，同時定位模塊主要依賴相對車道線或者GPS定位， 使得我們有機會嘗試解耦對于高精地圖的高度依賴。

Relative Map是根據周圍的環境實時建立的，同時以10hz的頻率向外發布，以供預測、規劃以及Dreamview使用。有三個不同的工作方式。

一是直接由實時的感知模塊監測到的道路邊界，以10hz的頻率生成。好處是完全脫離對高精地圖和高精定位的依賴，部署成本較低，壞處是這種工況對于車道線本身的Lane Marker標注是否清晰依賴度較高，同時在這種工況下只能進行簡單的ACC和Lane keeping。

第二種是指引線加上相對地圖，這樣的方式對于定位有較強依賴，而對車道線本身標注的清晰程度依賴較低，同時，不基于高清地圖，仍然保持較為靈活的部署方式。

最后一種方案是基于指引線+高精地圖模式，這是最精確的解決方案，這樣的優點是可以得到最全面和精確的地圖定位信息，缺點是部署成本較高。

上面是歸納高精地圖在三種模式下的車道應用說明。

Lattice Planner

Lattice Planner一開始在Apollo 2.5時入庫，但那時候并沒有完全Functional ready，簡單來說，Lattice Planner是一種Sample Based Planning的算法，具體的算法為：

1. 橫向和縱向分別撒點， 根據實時的決策目標，比如跟車或者停止，在車輛的狀態空間內取不同的終點。用高階曲線鏈接起點和不同狀態的終點。

2. 同時根據體感，是否達到終點狀態等，對于橫向和縱向的曲線Assign不同的Cost。

3. 之后，將橫縱向的曲線bundle起來形成最終的曲線，根據曲線Bundle后的Cost，從小到大排序，再檢查Bundle后的曲線是否符合Gometry Constraint，Comfort Constraint和通過Collision Check。

4. 最終輸出滿足條件的最優的解。

這種方法對比現在的EM Planner來說，優點是在調試性和可理解性上都要容易很多。缺點的話，是跟現有的EM Planner相比，因為軌跡之間是用高階曲線進行連接，Lattice Planner在特別復雜的條件下表達能力有所欠缺。因此Lattice Planner適合相對比較容易的高速場景以及末端物流場景和園區場景中運行。

這是兩種不同的Applications，一種是Relative Map + Lattice Planner在高速場景中的應用，另外一種主要解決方案是HD Map+Lattice Planner在低速物流場景的應用。在Apollo 2.5中Relative Map剛開始發布時主要支持單車道的簡單ACC與Lane Keeping，在隨后的Apollo 3.0以及以后再次升級了相對地圖，以及在此基礎上的決策規劃與控制的能力，同時提供在Relative Map下的多車道的復雜動作，比如超車與換道。

Fleet Mangement

Fleet Management在第三方平臺和云服務平臺的之間定義了車輛接口、合作方接口、園區接口、以及起始終點接口。同時，在百度云端服務和車端自動駕駛系統之間，定義了起始點，以及車輛調度指令下發接口和狀態收集接口，與量產接口一致，保證了和partner是一套調度接口，方便開發者在此基礎上進行開發。

3Open Vehicle Certificate Platform

Open Vehicle Certificate Platform在1.0版本的時候只有一種車型，對于開發者來說選擇相對較少。因此在Apollo 3.0當中開放了Open Vehicle Certificate Platform，同時發布了Open Vehicle Certificate Standard，比如把整個的標準跟流程進行發布，更方便不同的開發者快速的把他們相關的能力加入我們的平臺中。

Apollo開放認證平臺，對于自動駕駛開發者來說更方便、更安全以及更低成本，只需要一套代碼就可以支持多種車型，直接進行切換。對于車企和車營商來說，好處在于車輛可以和Apollo平臺無縫對接，同時可以接入自動駕駛的開發者，這里我們也希望能夠和更多車型、車輛的供應商一起攜手建立一套行業標準。

Apollo開放車輛的接口標準主要分為兩大部分。首先對于線控系統來說，線控系統會對于功能指標、性能指標、安全指標進行一系列的約定與標準的提出。其次是對于車輛本身的車輛系統，為了支持自動駕駛，我們也對它的功能、性能、安全以及能耗指標制定了一系列約定。

具體來說最常見的剎車和油門，對于它們來說，控制精度、控制力度及這些系統的周期時間、響應時間都有著嚴格的規定。對于線控系統的安全指標來講，其中包括指令越界保護和控制的處理，都有著明確約定以及標準化的要求。

對于車輛系統本身，首先希望有相對穩定的CAN通信接口，同時對于這輛車的電源，具體包括電壓、功率、最大波動、輸出誤差都有一系列的規定，能夠保證在整個自動駕駛過程中電源輸出穩定。

在車輛系統中，我們希望partners能夠給我們一些動力學模型，具體來說包括加速動力曲線、剎車動力曲線、以及轉向動力曲線。同時，接入的車輛要滿足一系列的安全指標，比如車輛碰撞及一些推薦能耗指標，比如車輛排放標準、油耗標準和續航里程標準。

在Apollo 3.0中，我們開放了相關開放車輛的一些工具和文檔，這些工具文檔包括但并不限于我們的DBC file轉化工具，校驗工具，以及車輛安全測試工具。同時我們也開放了相關的文檔，比如接口需求文檔、操作文檔，及認證車輛類表。接下來介紹一下整個的車輛操作指南，同時在這個過程中帶領大家熟悉一下在Apollo的代碼中，我們的接口需求、文檔以及各個工具具體的位置以及使用方式。

在一個完整的Open Vehicle Certificate Program的流程里，第一步是Apollo Publish Interface and requirements，這里面包括Interface Documents，也包括我們的Compatible Vehicles，Certification Services以及Apollo Open Source Code，這些都是開始之前預先要做的準備。

第二步是Partners Initiate Process，能夠根據接口要求進行自檢，并進行一系列的測試，同時我們會相應的提供一些文檔和工具的支持。

第三步是一些Process Requirements，以及更多的Tehnical Check和Business Development Process。

第四步是Apollo and Partner Real Vehicle Test。Apollo平臺也盡可能提供不同的接口幫助大家完成開發以及對接。首先對于一輛新的vehicle，希望大家在Apollo Github上找到documents，根據流程和文檔，和我們開源的demo code和標準，開發者們可以從一個新的車廠DBC file，生成一整系列的code，通過改變很小的一部分code就可以無縫接入我們的Open Vehicle Certificate Program的流程。

期待我們的partner在Open Loop的時候使用一些Verification工具，保證向下的命令可以符合預期。最后開發者應該可以以Apollo 1.0循跡的方式，用新加入的車輛進行Waypoint Following的測試，通過我們在Apollo平臺上提供的相關測試標準。

接下來是最后的步驟，首先是Legal Check，將車輛通信協議代碼添加到Github上，同時將車輛添加到Apollo車輛平臺兼容列表里，就可以完成整個認證流程。