在本次技術沙龍中，來自Apollo團隊計算平臺的資深研發工程師-楊凱老師帶了關于Apollo 3.0功能安全的講解。

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

演講概要：

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

Apollo 3.0 功能安全

1功能安全是什么

在2017年以前，百度在無人車領域主要考慮的是無人駕駛的主系統。主系統主要指感知、定位、規劃、控制等幾個主要方面。2017年以后，無人車進入量產，功能安全成為一個重要的課題。主要問題是如何在路上不發生碰撞，是我們在一年時間這是主要探索方向。

為什么要做功能安全？這是自動駕駛的幾次事故，其中比較嚴重的一次是2018年3月18日美國Uber碰撞事件，導致人員死亡，另外還有Google等其他無人駕駛的事故。但中國每年都有數萬人在車禍中喪生，長遠看，無人駕駛可以減少這一數字。

為什么自動駕駛系統會造成事故呢？自動駕駛系統是由軟件和硬件研發組成，硬件包括車輛、傳感器限速等等，軟件主要包括地圖、感知、規劃、定位等等。而軟件是有缺陷率的，軟件的缺陷率有兩種，一種是Bug率，一種是程序輸出的結果非預期，包括精確度、感知度和算法等，另外還有延遲，都有可能會造成事故。

硬件方面，除了有車企事故、傳感器故障，還有功能機的故障、限速的故障。車輛安全法規要求車輛上的電子電氣系統具備功能安全，對于使用了AI技術的復雜的自動駕駛系統，安全要求更為嚴格謹慎。尤其是對于無人駕駛的車輛，需要自動駕駛系統在自身或者車輛發生故障時能夠安全控制車輛。

首先，我們需要了解下功能安全是什么？無人車主要分為兩大塊，一是網絡安全，指不被黑客竊取，比如黑客竊取了駕駛軟件信息會造成危險；二是功能安全，在整個無人車生命周期內，在整個軟硬件系統中的所有零部件都系降低到風險。還有就是構建功能安全系統，預知故障，降低風險水平。

2功能安全如何做

具體來說，我們采用電子電器行業標準ISO26262。在全方面落實ISO26262搭建安全流程的同時，系統地分析解決系統風險點，把風險點解決在系統搭建的時候。此外，在局部上建立無人駕駛安全系統，召回軟硬件故障，建立安全防線。

ISO26262是國際標準化組織(ISO)2011年公告最新車電系統之功能安全國際標準。

ISO26262涵蓋車輛整個生命周期，稱為安全生命周期(Safety Lifecycle)，由管理、開發、生產、經營、維修至報廢皆有相應的要求，本標準包含十個章節，計有Part 1名詞解釋(Vocabulary)、Part 2功能安全管理(Management of Functional Safety)、Part 3概念階段(Concept Phase)、Part 4產品開發在系統層級(Product Development at the System Level)、Part 5產品開發在硬件層級(Product Development at the Hardware Level)、Part 6產品開發在軟件層級(Product Development at the Software Level)、Part 7生產與操作(Production and Operation)、Part 8支持流程(Supporting Processes)、Part 9車輛安全完整性等級導向與安全導向分析(Automotive Safety Integrity Level-oriented and Safety-oriented Analyses)、Part 10 ISO 26262指南(Guideline on ISO 26262)。

SOTIF是預期功能的安全性標準，預計2021年正式發布標準，是后續功能安全的主要標準。SOTIF和ISO26262的主要區別是什么呢？ISO26262更強調系統失效，軟件出錯，程序的故障可以被認為是系統失效。而SOTIF更加注重技術的缺陷及系統相關定義。如圖像識別的精度，雷達的抗干擾性。另外，由于功能傳感邏輯不合理，導致規劃的失敗，也屬于SOTIF的范圍。功能安全要結合ISO26262和SOTIF。

那么如何落實ISO26262呢？上圖是ISO26262的介紹，ISO26262把整個生命周期分為三個階段，黑線以上是概念階段，中間部分是產品開發階段，最后是產品交付階段。

ISO26262的第一章主要介紹基本概念，第二章介紹功能安全管理，第三章介紹概念管理，第四章介紹產品開發，第五章介紹硬件開發，第六章介紹軟件。ISO26262主要基于項目定義，然后在HARA基礎上做危險分析和做風險評估，再做安全目標，然后產生功能安全需求和技術安全需求。舉個例子，比如現在場景是車輛啟動，車輛啟動的時候需要分析啟動時的碰撞風險，提出HARA啟動風險，Safety goals是系統風險，FSR是功能安全需求的盲區，避免加速。然后提出TSR，比如硬件傳感去覆蓋區域，再到軟件區域，前方的感知要覆蓋到前方安全區域。

針對ISO26262，Apollo對整個系統流程進行了分工和重新定義。首先是產品經理對整個系統進行全新定義，接著安全架構師進行系統分析和風險評估，然后系統架構師設計搭建軟件系統和硬件系統，最后進入研發階段。目前我們的流程已經通過了ISO26262的認證。

介紹一下Waymo的方案， Elektrobit，NVIDIA的安全方案，可以看出，主要是通過冗余來提升系統的安全性。

冗余的方案在ISO26262中里面也有支持，ISO26262會將所有的安全等級分為ASILA、B、C、D等級。

ASIL可作為產品開發之安全目標。ASIL由嚴重度(Severity)、暴露機率(Probability of Exposure)與可控度(Controllability)決定，等級分為QM(Quality Management)與ASIL A至D五種，QM等級無須適用ISO 26262。

這里我們要講到冗余的一個反例，共因失效。冗余系統（或容錯系統）優點是當一個模塊發生失效時，由于容錯系統同時配有兩個以上相同的模塊，所以可以避免系統發生失效。但是，共因失效的出現抵消了冗余系統的優點，當一個單獨的應力導致兩個以上相同的模塊同時發生故障，那么冗余系統也會發生故障來提高強度。設計特點都會增加強度。元器件失效率低的系統，共因失效率也低。

多樣性強調兩個算法，比如業界比較流行的算法是CNN，機器學習。但是機器學習算法有個缺陷，沒有學習過的東西識別不出來，所以會造成一個問題——它進行學習的大部分都是路上經常遇到的物體，比如人、車的交通案例，但是對于一些類似小石坑的識別不處理。但是可以用MST算法多樣性布線，避免發生交規，用強化設計和測試去避免存在問題。

3功能安全子系統

這是功能安全的主系統思路。把系統比成一個人，感知是大腦，控制是手和腳。它的心臟有反應，就無法駕駛車輛，有安全風險。反應慢，也有可能造成安全風險。假如現在這個人是健康的，但也有可能錯誤決定造成安全隱患，比如突然右轉。處理方法就是做故障檢測，故障檢測之后會進行故障處理，分等級處理，第一個等級警告。然后，就是減速，系統延遲比較大時，只能降速行使，因為高速會發生危險。之后是停車，比如傳感器失效，緊急停車。否能夠靠邊停車是由發生的故障決定，比如感知系統失效就不能前后靠邊停車。

還有主系統壞了后有一個備用系統進行巡視。根據故障可以進行分類，分成人的故障和車的行為故障。如果車軟硬件發生故障，相當于車的健康率發生故障，就不能行使。另外，根據故障分成幾類，有碰撞風險是急剎，導盲故障。還有是碰撞檢測，這種可以根據障礙物進行緩剎和非急剎的策略。還有一種是無碰撞風險障礙。

4熔斷機制 & 碰撞檢測

在沒有功能安全系統時，功能安全的熔斷機制是把感知發給規劃，規劃再發給行動，行動再控制車。增加了安全后，進行了熔斷，是把主系統的控制權給安全系統進行接管。

右面是碰撞檢測，綠色區域是規劃距離，正常的車在規劃過程中會與行車保持安全距離，這個距離要遠于功能安全的檢測距離來看。紅色區域是安全的檢測碰撞區域，比如安全下面的公式，參考Mobileye RSS。另外還有多樣性感知算法，比如說CNN感知算法。

Apollo在搭建功能安全子系統時有這樣一個思考，安全子系統，必然會帶來系統復雜度的上升，但是為了安全性犧牲復雜度現在看起來也是有必要的。

另外，準確率與召回率，是功能安全的兩個核心指標。為了好的乘車體驗，要做到高準確性，為了安全又要做到高召回率。