導讀

地平線在智東西公開課開設「地平線AI芯片技術專場」。第三期課程中，地平線系統(tǒng)及人工智能安全總監(jiān)楊虎以《如何翻越自動駕駛AI系統(tǒng)安全高峰》這一主題進行了直播講解。

如果說自動駕駛處理器是人工智能產(chǎn)業(yè)的珠穆朗瑪，那么，攀登人工智能的珠峰，務必要翻越“系統(tǒng)安全”的崇山峻嶺。

楊虎老師從自動駕駛所帶來的安全挑戰(zhàn)、自動駕駛AI系統(tǒng)安全的內涵、 AI 芯片的安全量產(chǎn)實踐和AI算法安全的可衡量性四方面進行了全方位解讀。

大家好，很高興和大家交流如何翻越自動駕駛AI系統(tǒng)安全高峰。我叫楊虎，地平線系統(tǒng)及人工智能安全總監(jiān)，曾在多家行業(yè)主流Tier 1和OEM公司擔任系統(tǒng)安全相關職位，負責ADAS系統(tǒng)的功能安全工作，實現(xiàn)了功能安全團隊及流程從0到1的搭建。我也是ISO 26262功能安全及ISO 21448預期功能安全國際標準制定小組成員，參與了IEEE P2846、IEEE P2851和IEEE P3130自動駕駛國際安全標準制定工作。

以下是本次課程講解的主要內容，大概分為4個部分:1、自動駕駛所帶來的安全挑戰(zhàn)2、自動駕駛系統(tǒng)安全的內涵3、AI芯片的安全量產(chǎn)實踐4、AI算法安全的可衡量性

01 自動駕駛所帶來的安全挑戰(zhàn)

大家對ISO 26262和FUSA可能比較熟悉，在神經(jīng)網(wǎng)絡算法里，業(yè)內做過一些故障注入實驗。如上圖上半部分所示，如果改變原始圖像中的一個像素點，在交通標志燈的分類結果中，綠燈的分類結果可能會變成紅燈。在高等級自動駕駛系統(tǒng)中，如果把交通標志燈的分類結果引入到控制環(huán)中，由單一像素引起的錯誤可能會導致交通事故的發(fā)生，這顯然不是做安全工作的人期望看到的。
同時，地平線內部也做過一些類似的故障注入實驗。如上圖左下角所示，在神經(jīng)網(wǎng)絡不同層注入單一像素錯誤，注入錯誤后目標數(shù)少于1個占比達到3.4%，目標數(shù)多1個或2個分別占比為3%和0.2%，目標數(shù)不變的占比大概是93.4%。同樣，如果在不同層注入一個像素錯誤，可能會導致物體的位置或大小發(fā)生變化，變化比例約在20%~25%左右，這對目標檢測、距離判斷等有非常大的影響，也會帶來一些安全方面的問題。 單一像素的錯誤有可能來自于硬件故障，像RAM的某一個bit錯誤了，或里面的某個加法器、乘法器邏輯有問題，最終導致的結果都是很可怕的。
2018年，Uber在進行自動駕駛汽車測試時，撞死了一名橫穿馬路行人。這起事故在世界范圍內引起了很大的輿論，也引發(fā)了人們對自動駕駛行業(yè)發(fā)展的安全擔憂。還有之前特斯拉撞上一輛橫穿馬路的白色大貨車，車輛以為檢測到的是云朵，然后沒有來得及識別，發(fā)生了致命的事故。
在Uber這起事故發(fā)生過程中，美國 NTSB發(fā)布了一個調查報告，報告中詳細給出了碰撞前的時間線，比如在碰撞前2.7~3.8秒時，系統(tǒng)對該行人的識別結果在“車輛”和“其他”之間搖擺不定；距離碰撞還有2.6秒時，系統(tǒng)將該行人和她的自行車識別為“自行車”；然后在距離碰撞1.5秒時，該行人又被系統(tǒng)識別是“未知”；在碰撞前的1.2秒識別結果又變成了自行車。結果來回翻轉、不停切換，最終導致了這起事故的發(fā)生。 與上面提到由單一像素錯誤導致的交通事故不同，在這起事故中可以明顯看到，在這個過程中沒有錯誤、硬件失效和軟件故障，唯一的問題是整個自動駕駛系統(tǒng)沒有充分考慮對場景的應對，這也是ISO 26262 功能安全方法論的局限性，即無法覆蓋人為誤用、功能不足和性能局限，這就需要從ISO 21448預期功能安全的角度來考慮問題并給出解決方案。
另外，隨著高等級自動駕駛系統(tǒng)的不斷演進和行業(yè)不斷發(fā)展，傳統(tǒng)的基于規(guī)則的編程方法，像畫狀態(tài)流程圖、寫軟件需求、設計軟件架構、單元設計、測試驗證等傳統(tǒng)的V模型開發(fā)模式，即軟件1.0的開發(fā)模式，逐漸被軟件2.0的開發(fā)模式取代。軟件2.0的開發(fā)模式需要先定義問題，把問題定義清楚之后，做一個網(wǎng)絡架構，然后不斷的收集數(shù)據(jù)，再不斷的訓練和迭代優(yōu)化整個網(wǎng)絡結構，最后達到一定的性能表現(xiàn)時，把產(chǎn)品投放到市場上，這也是特斯拉的開發(fā)模式對傳統(tǒng)V模型開發(fā)模式的迭代更新。既然開發(fā)模式變了，那應對新開發(fā)模式的Safety和Security問題，所采取的手段與方法也應不同。

Safety和Security也面臨著一些新問題，像利用激光筆做幻影攻擊。如上圖左上角所示，掉頭的標志牌用一支激光筆照射時，可能會分類成交通燈，置信度為0.45；人行道的標志牌經(jīng)過激光筆照射，可能會被分類成電影院；同樣，雙層巴士可能會被檢測成蟾蜍；停車場的標志也會被錯誤地分類成皂液瓶。如果人為地用激光筆惡意照射，可以認為是Security要應對的問題。但如果是在城區(qū)場景下，這種光影變換很常見，可能又回到了Safety應對的場景里，所以這個問題會有點混合，從源頭上來看，很難界定它是 Security還是Safety問題，但產(chǎn)品設計中一定要把這個問題解決掉才能安全應用。
同樣，上圖左下角的標志牌也類似，上面一些白色標簽、黑色標簽或人為貼的補丁也會導致識別結果錯誤。還有隨著時間的延長，標志牌可能出現(xiàn)掉漆、老化的問題，導致交通標志檢測和分類出現(xiàn)錯誤，這種情況很難將它歸類為Security還是Safety問題，但產(chǎn)品中一定要把這些問題解決掉。

綜上所述，如果只遵守ISO 26262應對自動駕駛所帶來的安全問題足夠嗎？顯然是不夠的，例如上圖左半部分人穿著雞的服裝，他的分類結果是no person，probability達到了0.99，實際上人藏在雞的服裝里，但神經(jīng)網(wǎng)絡并不能很準確的檢測出里面有人。同樣中間部分的圖像中，在馬路上畫一個小姑娘，如果神經(jīng)網(wǎng)絡設計足夠smart，有可能檢測出是一個行人。還有在逆光環(huán)境中，功能或器件并沒有失效，但在這種場景下，對于目標識別跟檢測也會有一些影響。同樣，一些穿奇裝異服的人，如果只考慮ISO 26262應對這些場景，很顯然是無法應對這個復雜而真實的世界。 那面對自動駕駛場景下帶來的諸多安全挑戰(zhàn)，該如何應對？首先要分析和界定自動駕駛系統(tǒng)安全的內涵。

02 自動駕駛系統(tǒng)安全的內涵

對于自動駕駛系統(tǒng)安全的內涵，首先要做安全風險的梳理。如果從產(chǎn)生原因劃分，安全風險可以來自于產(chǎn)品內部，也可以來自于產(chǎn)品外部。產(chǎn)品內部又可分為功能失效與功能不足，功能失效包括硬件隨機失效和系統(tǒng)性故障，可以采用ISO 26262和功能安全的方法論去處理；如果是功能不足，比如一開始設計時沒有考慮到陌生場景，需要用SOTIF方法論處理。

產(chǎn)品外部原因可以分為性能局限和誤用，性能局限包括逆光或者大雪場景，也是用SOTIF方法論來解決問題；誤用分為無意誤用與有意誤用，無意誤用也需要SOTIF方法論來處理問題，有意誤用，比如網(wǎng)絡攻擊，就需要ISO 21434方法論來處理。 把安全風險做系統(tǒng)化梳理后，發(fā)現(xiàn)系統(tǒng)安全由網(wǎng)絡安全、預期功能安全和功能安全三個部分組成，它們所應對的問題各不相同，但又互為補充。

在研究自動駕駛政策以及法規(guī)監(jiān)管的一些動態(tài)時，會發(fā)現(xiàn)無論是中國、美國還是歐盟，有關高等級自動駕駛的產(chǎn)業(yè)政策或行業(yè)法規(guī)，都會不約而同的涉及到功能安全、預期功能安全以及網(wǎng)絡安全。上圖右上角是去年7月，工信部出臺的有關智能網(wǎng)聯(lián)車輛準入管理意見，里面明確提到了功能安全、預期功能安全以及網(wǎng)絡安全這三個topic。歐盟在 Regulation No.157里也提到了System safety and Fail-safe Response和Cybersecurity and Software-Updates。美國也是如此，美國交通部與NHTSA、白宮的交流非常密切，每1~2年就會發(fā)布一個產(chǎn)業(yè)政策，像AV1.0、AV2.0、AV3.0、AV4.0，目前最高版本是AV4.0，這些產(chǎn)業(yè)政策對安全都很關注。
上圖右半邊是美國發(fā)布的一個自動駕駛車輛行動計劃，它把自動駕駛車輛的關鍵技術點大概分為了20條，其中第一條、第二條、第十一條是有關于ISO 21434、ISO 26262以及ISO/PAS 21448。從這些工業(yè)強國的產(chǎn)業(yè)政策包含的內容可以看出，對安全的監(jiān)管將變得越來越強。 那么系統(tǒng)安全如何實現(xiàn)落地呢？

03 AI芯片的安全量產(chǎn)實踐

首先看下地平線系統(tǒng)安全的總覽。地平線安全團隊可以劃分為三個不同部分，第一部分負責芯片安全，包括了 SoC的Safety架構跟Security架構；第二部分是系統(tǒng)及人工智能安全，這個部門負責整個公司的流程搭建、體系維護升級、整個公司的產(chǎn)品開發(fā)項目安全管理，也包括了 AI的安全研究；最后一部分是上層應用的安全，它也涵蓋了兩個方面：一個是Safety架構，另一個是Security架構.

有了這樣強大的組織之后，地平線在產(chǎn)業(yè)界的參與度也比較多，像參與了 ISO的一些標準制定，以及IEEE 2846、IEEE 2851等，還有參與CAICA SOTIF工作以及ELISA組織等。
2020年9月時，地平線的產(chǎn)品開發(fā)流程通過了 ISO 26262 ASIL D級別認證，這證明了地平線具有開發(fā)最高級別功能安全產(chǎn)品的能力。地平線根據(jù)ISO 26262功能安全流程的要求進行產(chǎn)品研發(fā)，在隨后的2021年7月，征程5 獲得了ASIL B功能安全產(chǎn)品認證。這標志著地平線征程5芯片的功能安全架構、設計實現(xiàn)均達到了全球公認的汽車功能安全標準 ISO 26262 ASIL-B級別，滿足世界一流OEM和Tier1的功能安全開發(fā)要求。征程5也是中國首顆基于ISO 26262功能安全流程開發(fā)的車規(guī)級AI芯片。
同樣地平線每年還會組織公司級的功能安全外部培訓，如果今年的培訓計劃實施完，地平線會有近100位工程師拿到第三方的功能安全資質認證。這些工程師并不專門從事系統(tǒng)安全的工作，他們分散在軟件開發(fā)、測試和項目管理等等不同的職能和業(yè)務部門里，將系統(tǒng)安全落地在自動駕駛技術研發(fā)的全流程中。

下面介紹下地平線的功能安全管理框架。功能安全管理目標分為三個層次：一個是總體功能安全管理，即建立和維護總體的功能安全管理流程與文化，并持續(xù)改進；第二個是產(chǎn)品開發(fā)項目的功能安全管理，即確保整個產(chǎn)品開發(fā)項目里的一些確認措施符合ASIL等級要求，包括評審，流程審核和產(chǎn)品評估；第三個是量產(chǎn)功能安全管理，當產(chǎn)品投放到市場之后，產(chǎn)品的功能安全怎樣做現(xiàn)場監(jiān)控，怎樣通過質量途徑做售后的反饋及更新。上圖右半部分解釋了地平線總體的安全管理架構，包括上面提到的三個維度。
有了安全管理的基礎之后，技術實現(xiàn)層面也需要考慮系統(tǒng)安全?？紤]一個ADAS控制器的抽象的安全架構，由于地平線是做視覺感知起家的公司，所以在視覺方面的投入會多一些，抽象架構也是以Camera Sensor為主，其他像激光雷達、毫米波雷達、超聲波雷達等劃歸為Other Sensor。

ADAS控制器主要處理器是征程系列的SoC，它里面又分為兩大部分：一部分是圖像處理，另一部分包括感知、Fusion、 Planning模塊。在圖像處理部分包括圖像接口，像MIPI、ISP、IPU、GDC以及光流等模塊。從征程5的實施經(jīng)驗來看，這些模塊可以達到ASIL B等級。圖像預處理的信號出來后，經(jīng)過AI感知做一些卷積處理，處理完在CPU里做Fusion或Planning，目前在征程5上也做到了ASIL B等級，未來產(chǎn)品可能達到ASIL D等級。同樣，外部MCU可能做一些控制車輛的功能，它的等級會高些，可以達到ASIL D。隨著集成度越來越高，外部MCU會逐漸集成到SoC內部，整個SoC的ASIL等級就會不斷提升，外部可能只需要一些簡單的器件，比如DDR、EMMC等，再加上一些 fall back機制，這就是抽象的ADAS控制器的整個安全架構。
征程5 SoC是業(yè)界最為復雜的一顆AI芯片，在征程5內部集成了很多的功能安全特性，比如用于系統(tǒng)監(jiān)控、診斷和恢復的隔離安全島；鎖步CPU/FCHM/DMA/WDT；外圍E2E保護；具有比較邏輯自檢的關鍵路徑上的延遲雙鎖步邏輯；受ECC/奇偶校驗保護的SRAM；DDR 受Inline ECC 保護；寄存器有奇偶校驗、回讀機制去做檢查；關鍵控制模塊：Triple-voted flip-flop；電壓、時鐘、溫度監(jiān)控也會有獨立的監(jiān)控在里面；上電時存儲器和邏輯 BIST；同時也支持運行時測試模式/軟件測試庫等等。征程5除了擁有特別多的safety feature之外，security方面的設計也很多。對征程5 SoC Security需求的整體來源做系統(tǒng)性梳理后，發(fā)現(xiàn)它包括了系統(tǒng)&應用層級的知識、市場趨勢&客戶需要、系統(tǒng)化的Security工程開發(fā)方法，像TARA，TCC等，以及行業(yè)標準&法規(guī)等，從而確保方案不會出現(xiàn)一些關鍵需求的遺漏。同樣，征程5上所支持的Security特性包括了安全啟動、安全刷新、安全通信、安全存儲、密鑰管理、安全配置等。征程5還有一個獨特的特性是AI模型保護，即內部提供了一種通過內存防火墻保護DDR中存儲的AI模型的方法。同樣，在安全調試上，當使用不同的系統(tǒng)資源訪問時，提供不同的調試模式。
在征程5芯片上，考慮完FUSA、Security特性之后，要想真正把一顆芯片做到量產(chǎn)，還得考慮上層算法。上層算法在做高等級自動駕駛的安全風險分析時，發(fā)現(xiàn)還需要有SOTIF方法來解決，否則如果只是把Safety和Security問題解決掉，上層算法在應對未知或已知的不安全場景時，沒有方法論可以迭代收斂上層算法，使得芯片只是一個硬件，無法真正做到量產(chǎn)上車。

意識到這點之后，我仿照ISO 21448方法論做了一個SOTIF工作流，它與 ISO 21448標準里的需求一一映射。如上圖所示，首先要做功能的定義與描述，接著做SOTIF Risk識別與可接受準則的確立，之后做SOTIF trigger condition的分析與梳理，這里涉及到STPA、FEMA、FTA等方法，這些SOTIF triggering會形成SOTIF的safety concept。
SOTIF safety concept可以幫助改進算法和軟件產(chǎn)品。產(chǎn)品改進完之后，根據(jù)SOTIF HARA識別出的可接受準則，制定V&V Strategy。通過V&V Strategy評估已知的不安全場景是否達到了可接受準則要求的度量，同時通過大里程的累積路試，評估產(chǎn)品應對未知不安全場景的能力，如果這些都符合產(chǎn)品釋放準則，就會把產(chǎn)品釋放到市場。釋放到市場之后，還要做好現(xiàn)場監(jiān)控。由于現(xiàn)在的生活環(huán)境與10年前的生活環(huán)境有了很大變化，同樣一輛車的生命周期如果是10年，它周圍的環(huán)境，包括道路的基礎設施及人的交通設備都與10年前不同，這10年的生命周期跨度里自動駕駛車輛所要應對的場景變化非常巨大，這時必然需要監(jiān)控整個自動駕駛車輛所要面對的環(huán)境，看它與最初設計的自動駕駛功能、數(shù)據(jù)集是否一致，如果不一致，就要做迭代、更新。

SOTIF HARA 與 FUSA HARA 類似，以危害事件的 S/E/C 值評定，但 FUSA 以 S+E+C>=7 來認定為危害事件，SOTIF 只要S>0 或 C>0 時就會被認為是危害事件。上圖的例子分析了非預期減速度的值，如果兩輛車要避免碰撞，它倆之間的間隔距離要大于等于0，由此建立一個物理模型，求解出非預期的減速度要小于等于0.2g，然后再通過可控性的分布以及場景貝葉斯條件概率等，可以算出總確認里程大概是1560000公里。但如果用條件概率做可接受準則的確認，可能會把總確認里程1560000公里會往下降一些，到156000公里。如果沒有大于0.2g的非預期減速度，就認為滿足了SOTIF的可接受準則。

156000公里是怎樣算出的呢？可以分為5步，第一是選擇接受準則，比如在ISO 21448里有三大原則：ALARP、GAMAB、MEM，地平線現(xiàn)在用的是GAMAB，即由新功能引起的危害事件概率不超過由人類駕駛員引起的等效危害事件概率；大的原則確立好之后，下一步是計算基礎的確認目標，用總里程數(shù)除以國家交通部門統(tǒng)計出來的致死交通事故數(shù)，可以算出致死兩起交通事故之間的安全行駛里程是什么量級，這個量級算出來之后，還要做一些余量修正；第三步是選擇對應的統(tǒng)計模型，考慮到交通事故數(shù)量有限，選用泊松分布來計算；之后在實際驗證中，選擇好置信度、安全裕度等，算出一個值；最后這個值再根據(jù)貝葉斯條件概率導出確認里程數(shù)156000公里。

做完SOTIF HARA以及確立可接受準則之后，還要做SOTIF觸發(fā)條件分析，當性能局限和觸發(fā)條件同時發(fā)生時，可以認為是相關項的故障行為，同時駕駛員誤用也應當把它視為觸發(fā)條件。在觸發(fā)條件分析中，采用一些結構化的推導方法去做分析，如上圖右半部分所示。比如分析 Camera感知、雷達感知和定位等的觸發(fā)條件，可以一層一層地往下細分。以Camera感知為例，又分為Sensor特性參數(shù)包括了FOV等；環(huán)境這塊包括了低照度、雨、雪天氣等等；算法里面包括了異形車、延遲等都要做一些量化分析。
分析完后，根據(jù)一些需求驅動算法的更新，更新完后根據(jù)前面設定的可接受準則做一些驗證策略。在SOTIF驗證策略中主要有兩大塊：一個是仿真，在51SIM中構建觸發(fā)條件，然后在專門的客戶端自動評估51SIM中的真值與感知結果的差異；另一個是封閉道路驗證，我們會配備裝有真值設備的車輛，通過地平線的AIDI評估平臺做數(shù)據(jù)閉環(huán)的處理。
SOTIF要應對未知的不安全區(qū)域，主要包括里程累計測試和HIL仿真。一般情況下，Bad Case應考慮危害度量，比如前面提到的模型，0.25g非預期減速度持續(xù)3s，大概率會導致碰撞事件的發(fā)生，這才是SOTIF領域需要關注的不安全行為。有了一些定量值之后，通過量化的準則，在AIDI數(shù)據(jù)集里搜集類似的場景，然后把它識別出來，不斷累積這樣的case，再通過修改軟件，達到 156000公里的目標，則可以認為這種未知不安全區(qū)域的風險，已經(jīng)滿足了設定的釋放準則。
實車數(shù)據(jù)的規(guī)劃和監(jiān)控也很重要，在一開始定義功能時，就需要考慮目標市場的真實使用環(huán)境和場景，開發(fā)用到的數(shù)據(jù)就會根據(jù)目標市場去采集。在產(chǎn)品開發(fā)過程中，收集到的數(shù)據(jù)不斷增長，數(shù)據(jù)的分布有可能會偏離預定義好的規(guī)劃。在AIDI平臺上就會有一個數(shù)據(jù)分布的監(jiān)控功能，來提升數(shù)據(jù)質量，只有收集回來的數(shù)據(jù)能夠滿足預定義好的場景分布，只有這樣才能確保開發(fā)出來的產(chǎn)品，能夠以終為始，真正應對最初定義好的場景。
講完系統(tǒng)安全在地平線的落地實現(xiàn)，那面向未來，應該如何衡量AI算法的安全呢？

04 AI算法安全的可衡量性

傳統(tǒng)汽車領域的安全關鍵電子電氣系統(tǒng)適用ISO26262等標準，采用V模型的方式從流程上進行保證。開發(fā)模式如果進化到軟件2.0模式，主要是基于數(shù)據(jù)驅動的方式，通過不斷地學習循環(huán)方式提升性能。這時可能要根據(jù)產(chǎn)品開發(fā)模式的特點，制定對應過程的保障，確保產(chǎn)品開發(fā)能夠達到安全。

在ISO 5469里有一張非常形象的流程圖如上圖所示，把軟件2.0時代的開發(fā)模式描述的很契合，像系統(tǒng)定義、風險分析、需求定義以及產(chǎn)品運行和監(jiān)控，這與原來的V模型有一一對應的關系。但到了下半部分，比如數(shù)據(jù)準備、訓練、V&V、大的回環(huán)迭代，它跟原來的V模型就有所不同，可以看出是一個不斷迭代、不斷回環(huán)的過程。

ISO 5469把AI技術的風險等級也做了兩個維度的劃分，第一個維度從現(xiàn)有安全方法論是否能夠應對AI技術的評審和開發(fā)角度來看，把AI技術分為三個等級；另一個從使用場景上來看，如果使用AI技術能夠自動生成決策控制，它可能就是A1等級，如果AI技術用在了與安全無關的場景里，它可能被分配到D等級，介于這兩者之間的又做了一些細分，大概分為了A1、A2、B1、B2、C、D等6個等級。這6個應用等級與AI技術組合成上圖的一張表，紅色部分表示不推薦使用AI技術，黃色部分可能需要一些特定的要求，綠色部分也需要一些對應的安全風險減少的概念。ISO 5469處于一個非常前期的階段，它類似于IEC 61508，先把等級定義好之后，再針對不同的色塊提出一些具體的需求，比如針對不同的ASIL等級和不同的系統(tǒng)設計架構，包括軟件單元設計、代碼測試等這些方面衍生出一些具體的需求。
同樣，從 AI開發(fā)和部署過程上來看，大體上分為定義、specify、架構設計、設計與評估、部署和監(jiān)控幾部分。在這個過程中，軟件2.0時代的安全需保證覆蓋采、存、篩、標、訓、測、發(fā)各個階段。如果考慮AI的安全，從流程上來講，需要整體關注這些環(huán)節(jié)，然后在這些環(huán)節(jié)里添加重點的監(jiān)控和保障措施，最終在流程上形成一個 Safety Augmentation/Assurance Case，涵蓋 FUSA、SOTIF、Cyber Security三個方面的主題。通過這樣的一個完整的證據(jù)鏈，才認為流程上是可以的。
這里也做了一些舉例，比如規(guī)格不夠充分，可能會有危害場景的缺失；規(guī)格語義存在差距，使得實際的數(shù)據(jù)集與規(guī)格定義的相似性不一致；與實際要求之間存在差距，導致系統(tǒng)需求未充分傳遞，訓練集、測試集的屬性或其分布與運行域不匹配，讓系統(tǒng)的泛化和魯棒性能力不足，或部署前后參數(shù)或者硬件平臺發(fā)生變化導致不能達到性能要求等，這些都是過程上的一些控制措施。

關于行人分類規(guī)格的示例，上圖是一個參考的示例，例如行人檢測，當檢測出遮擋小于某一個閾值時，應當分類出特定像素高度和特定像素寬度的行人；同時對每幀的誤報率也有量化要求，比如對定位方面，要求垂直方向與真值偏差要小于某一個特定像素，水平方向與真值偏差要小于一個特定的像素；對于數(shù)據(jù)集，驗證數(shù)據(jù)集應當覆蓋真實環(huán)境情形中的一些特征，危害場景需要被充分的訓練和驗證，以保證已知的危害場景得到充分學習和良好的性能；技術也不應有偏見，針對不同年齡、性別、種族也要充分考慮，比如在暗光場景下，對一些膚色比較暗的人識別效果可能不太好，這時可能需要去補充一些數(shù)據(jù)做訓練，避免從技術層面產(chǎn)生倫理安全問題的風險。

由于整個自動駕駛系統(tǒng)比較龐大，在系統(tǒng)安全措施方面包括了控制器上用到的AI技術，傳統(tǒng)軟件領域中的底層驅動軟件以及OS和中間件，自動駕駛系統(tǒng)中的多傳感器冗余，以及外部的一些其他系統(tǒng)，像ESP。只有這些保護機制都失效時，才可能導致危害事件的發(fā)生。從這個角度上來看，自動駕駛解決方案或系統(tǒng)的系統(tǒng)性安全措施可以從以下方面考慮，像運行時的系統(tǒng)性策略和非運行時的系統(tǒng)性策略，及部署運行時持續(xù)的Safety Assurance。
那在AI開發(fā)過程中應從哪些方面考慮安全措施呢？首先，在算法架構或者內部產(chǎn)品設計上有多重確認策略，例如在原始圖像中檢測一輛車時，需要先檢測出它是一輛車，之后還要做車牌確認，這就是多重確認。還有一種是做ISO 26262里的ASIL 分解，即通過神經(jīng)網(wǎng)絡，做一個基于規(guī)則的監(jiān)控器，把ASIL的要求或屬性分給監(jiān)控器，然后把低等級的 ASIL屬性分給神經(jīng)網(wǎng)絡。
另外，在算法架構層級，可以有Redundancy和Ensemble等措施；在算法的功能層級，要考慮前后幀的時空一致性、對輸入數(shù)據(jù)進行預處理和規(guī)則約束；在HADS系統(tǒng)層級包括了多樣性傳感器的冗余和融合、追蹤和預測、運行模式間的轉移、實際運行范圍的約束等；在考慮System of system上，包括了人機共駕、系統(tǒng)間的協(xié)作，像fleet或眾包等；在社會包括法律法規(guī)層面也要考慮一些安全措施。
除此之外，采用高等級自動駕駛系統(tǒng)時，即使車輛的駕駛行為非常中規(guī)中矩，比如當有一輛大貨車經(jīng)過它時，人心理上對自動駕駛車輛是不信任的，你會感覺到自動駕駛汽車在向大貨車一端偏移。這又引出了人對自動駕駛汽車安全心理上的適應性，這時會涉及到人機交互，當自動駕駛汽車要過大貨車時，要提前告知車主，緩解人的恐懼，實際上也是能夠防止駕駛員誤用等方面的一些措施。

除了前面提到 AI開發(fā)流程方面的一些保障措施，以及AI算法系統(tǒng)架構方面的安全措施之外，那怎樣才算安全呢？像ISO 26262里，它的硬件部分有一個量化評估的值，比如對不同的ASIL等級，有不同的量化要求。那對于AI部分，是否有一些量化方面的分析與評價呢？從社會角度看，如何讓社會大眾認可它是一個可以信賴的系統(tǒng)呢？從自動駕駛系統(tǒng)的角度看，結合SOTIF可接受準則，使用AI發(fā)生的事故率，應該以什么樣的準則才能認為 AI系統(tǒng)是足夠安全的呢？從這些動因上考慮，我認為量化評價一個AI系統(tǒng)的安全裕度是非常有必要的，這也能夠有效解決整個行業(yè)痛點：“究竟多安全才算安全”。 目前有一些初步的想法。類似于前面的可接受準則推導，假設自車軌跡碰撞的可接受風險概率為p，逐漸往下去分解時，比如行為和軌跡的Safety Boundary，它包括了不確定要求、多少米之內應該檢測到前方行人位置精度、斜方差應該是多少等。 從現(xiàn)在的自動駕駛控制器總體產(chǎn)品架構上來看，現(xiàn)在的自動駕駛控制器的底層硬件和一些輔助器件，實際上還是傳統(tǒng)的硬件，可以用以前的方法去處理。在此之上，涉及到的一些驅動、OS以及中間件等，實際上還是一個傳統(tǒng)的軟件開發(fā)模式，可以用ISO 26262的方法論來約束它。 怎樣實現(xiàn)AI算法的量化呢？例如分類出特定像素高度且特定像素寬度的行人，可以給它分配一個風險量化值，像誤差應小于多少，斜方差應該小于多少，標準差等。這樣整個系統(tǒng)邏輯關系建立之后，就能量化出頂層可接受風險p值，如果p值與大原則相比，在可接受范圍之內，基本上能夠從形式化上證明產(chǎn)品，或 AI系統(tǒng)符合了當前可接受的安全水準。同時，從產(chǎn)品正向設計的方向去看，也建立了產(chǎn)品釋放的安全信心。 最后做下總結，ISO 26262是汽車行業(yè)成熟的關于產(chǎn)品安全開發(fā)的經(jīng)驗總結，還會在硬件以及軟件部分繼續(xù)發(fā)揮一些基礎性的作用。ISO 21448以及ISO 21434的作用會越來越重要，在執(zhí)行過程中需要將這些方法融匯到產(chǎn)品開發(fā)中。除此之外，AI安全將面臨新的問題，可能需要新的方法和流程來應對。同時，自動駕駛系統(tǒng)安全的難點是需要系統(tǒng)性的工程化考慮三大安全主題，并不僅僅是個“證”的問題，要開放地看待這件事情