自動駕駛安全實踐挑戰及思考

上海盤石是一家專業從事汽車功能安全、預期功能安全、信息安全相關的培訓、流程咨詢、產品咨詢、工程服務的專業公司。

上海盤石信息技術有限公司創始人邊軍以“自動駕駛安全實踐的挑戰與思考”為主題，圍繞如何設計可靠冗余、如何讓Linux滿足功能安全、如何覆蓋感知系統的各種故障模式、如何正確判斷自動駕駛設計的ODD、如何定義自動駕駛的安全驗收標準、如何解決自動駕駛仿真環境與現實世界的差異等問題展開。以下是發言摘要:

上海盤石信息技術有限公司創始人邊軍。

如何設計可靠的冗余

首先，我簡單介紹一下自己。我從2009年開始接觸功能安全。當時常用的標準是IEC 61508，應用于工業領域。到現在為止，我從事安全相關的開發和審計已經十幾年了。首先說一下成立上海盤石信息技術公司的初心。經過十幾年的工作，我看到國內的安防領域和國外還是有一定差距的，主要表現在自動駕駛領域，芯片和軟件質量，尤其是自動駕駛領域。安全是從L2到L3演進過程中最關鍵、最基本的一點，這個環節的完成將影響整個自動駕駛產業在中國的落地。

自動駕駛的安全需要聚集國家和社會的財力和知識資源，建立產業連接，才能真正解決其在安全方面的共性問題，最終幫助中國落地自動駕駛。我今天帶來的內容主要分為六個方面，主要是我在整個自動駕駛發展過程中遇到的問題和挑戰，需要大家共同探討和完成。

第一，如何設計一個可靠的冗余系統，自動駕駛會從L1進化到L4，安全冗余設置會越來越多。從L3-TJP交通擁堵輔助和L3-HWP高速公路誘導的功能出發，在轉向、機動和定位方面會有冗余要求。L3以上，安全冗余會有全方位的要求，涉及感知、域控、電控等基本操作層面。

從2018年到現在，中國已經形成了自己的系統解決方案，但是有些解決方案并不代表這個領域已經真正實現量產，還有很多技術問題沒有解決。首先，系統需要有有效及時的故障檢測機制。“有效”強調安全冗余機制的性能。國內的安全冗余設計往往是多種安全機制的相互制衡。如果一個安全機制失效了，還要注意另一個安全機制的性能是否能滿足要求。例如，鄭路匹配和絕對定位一起構成了道路級定位的冗余設計。一旦絕對定位失敗，鄭路匹配方案是否足夠精確支持車輛運行是需要考慮的問題。

“及時”強調冗余機制的切換時間，要求系統在短時間內檢測出故障點，并迅速切換到備用機制，保證系統的正常運行。例如，如果將攝像頭和激光雷達結合起來作為車道線識別的冗余設計，一旦激光雷達出現故障，實際車道線將逐漸偏離攝像頭車道線，這就需要激光雷達本身的安全機制及時檢測到故障，然后系統將及時切換到基于攝像頭輸出的側向控制。如果不能及時發現故障，實際行駛車道線與攝像頭車道線偏差過大，系統無法確認故障點，必須采取緊急制動。

第二個難點是復雜的系統設計增加了冗余設計獨立的難度。工作人員需要考慮各種共因故障和級聯故障，尤其是傳感器融合中使用的一些設計，需要考慮傳感器的時間戳、自運動狀態等共因。除了電子和電氣……ical故障、外部環境因素也會導致冗余設計的失敗。例如，降雨可能會導致相機和激光雷達的性能下降。

做冗余設計時，要考慮五個方面。首先要做充分的安全性分析，比如FTA，考慮冗余機制由于性能限制的失效概率。第二，在開發初期做DFA分析，避免潛在的公共失敗和級聯失敗。第三，要有時間規劃，要縮短自我診斷和相互驗證的時間。第四，加大對系統工程的投入。第五，冗余設計不僅要實現ASIL層次分解，還要考慮失效操作。為了順利減少故障，傳感系統需要至少三個獨立的功能/機制，并通過“三取二”的策略快速識別故障。

如何讓Linux滿足功能安全

與其他系統相比，Linux有很多優點。一方面是免費開源，軟件庫豐富，開發成本低。另一方面綜合性能強，響應時間和速度更快，能更有效地運行軟件任務，支持多核運行，適用于不同硬件。同時，Linux也有一些缺點，例如，整個開發過程無法滿足與功能安全相關的標準。下面總結了Linux在功能安全性方面遇到的幾個主要挑戰:

首先是缺少文檔，開發過程無法追溯。有鑒于此，可以使用軟件FMEA分析對軟件模塊進行白盒化，識別故障模式和影響，也可以使用ASIL安全等級分解從不同層次對軟件模塊進行監控，但如果采用軟件監控，則需要另外考慮其獨立性。

其次，難以保證硬實時性。鑒于此，常見的策略是添加實時內核，用雙內核運行，但這種方案也存在很多問題，比如實時內核無法具備Linux內核的優點，Linux內核無法滿足安全性。為了保證硬實時，采用雙內核可能會導致代碼移植的問題。

第三，代碼和單元測試的工作量是巨大的，為了安全，需要對不符合ISO26262編碼規范的代碼進行裁剪和重新編譯。第四，安全改造后，Linux的優勢消失。業內有一種假設，未來可能不會出現收縮包裝的Linux軟件包，可以應用于安全性要求高的應用，但硬件的通用性可能會打折扣。

從行業進展來看，目前國內外的組織都在致力于提高Linux系統的安全性。所以從長遠來看，Linux可能是一個更加開放的平臺，未來在安全產品中使用還是有相當大的概率的。

如何覆蓋感知系統的各種失效模式

目前整個自動駕駛的難點其實是感知。例如，L1和L2自動駕駛的主要目標是防止意想不到的AEB與后車相撞。過渡到L3后，會增加很多額外的安全目標，比如正確識別道路邊緣信息；正確識別前方障礙物，防止錯前追尾；正確識別代表ODD的信息，防止系統進入未知的危險狀態。

目前，感知的安全目標主要是為L1和L2級別定義的。一旦應用于L3級系統，如何考慮這些偏差將成為行業難點。想象一下早高峰由陰轉雨的場景。你正在一個十字路口開車，突然攝像頭失靈了。然后你會看到以下場景:行地址失敗，列地址失敗，控制寄存器失敗，像素數據流水線失敗，內存/寄存器尋址失敗，圖像數據流水線失敗。

圖片來源:上海盤石信息科技有限公司。

在L3自動駕駛儀中，既要保證目標的正確識別，又要保證ODD的正確識別，同時還要考慮各種故障對它的影響，這實際上工作量非常大。之前見過一些國外的芯片。他們做這個分析的時候，可能會列出上千個場景，考慮每個場景的影響，以及如何解決。

鑒于上述困難，業界也提出了幾種攝像機的安全機制。一種是像素級模擬測試，主要針對像素點。常見的方法如模擬信號范圍篩選、ADC測試方案、行/列存儲數據路徑測試方案，最后是冗余。像素模擬測試可以解決像素顏色、強度、對比度的問題，也可以發現大于某個閾值的噪聲，但是沒有辦法解決像素的時空表達，也沒有辦法解決圖像傳輸中的問題。

對于圖像測試，這也是目前業內普遍采用的方式。典型的做法是給出一個參考圖像，然后從參考圖像中知道應該輸出什么目標。這種方法的優點是可以測試像素的時間和空間表達，但也有一些缺點，其診斷覆蓋率難以滿足一定的要求，難以遍歷數量巨大的故障模式。

三是測試成分，內容涵蓋像素的顏色、強度、對比度；像素的時間和空間表達；圖像傳輸；也可以發現大于閾值的噪聲，相當于白芯測試，采用關鍵數據寫保護；CRC寄存器；溫度和電壓檢測；時鐘檢查等等。

圖片來源:上海盤石信息科技有限公司。

我覺得這些方法以后肯定會結合起來，但是如何設計出一個診斷覆蓋率高，可以適用于不同安全目標的方案，是所有相機廠商和后端芯片廠商的難題。

如何正確判斷自動駕駛設計的奇數操作設計域

事實上，在自動駕駛早期，大家更傾向于使用靜態奇數約束和地理圍欄。到目前為止，純靜態的運行設計域約束已經不再適用，系統需要有一個有效及時的反映環境條件的動態檢測機制，以保證系統始終在可接受的風險下運行。

這里有兩個例子。左圖是單個因素影響的評估:比如陽光直射導致攝像頭反光，系統如何判斷什么程度的反光會影響駕駛員，什么時候應該退出，這是目前行業的難點。右圖是多個影響因素的耦合:霧夜，迎面遠光燈，此時系統如何評估是退出還是繼續跑？

圖片來源:上海盤石信息科技有限公司。

以下是基于傳感器原理方法的環境觸發條件識別案例:車輛行駛在金屬護欄道路邊緣，雷達反射導致虛擬場景，系統誤以為前方有車，導致誤制動。

圖片來源:上海盤石信息科技有限公司。

如何定義自動駕駛的安全驗收標準

針對如何定義自動駕駛的安全可接受性標準，首先解決兩個問題:一個已知的不安全場景如何被認為是可接受的？未知的不安全場景有什么解決方法？

針對已知的不安全場景，一方面需要量化系統安全性能要求，建立測試評估體系，同時需要解決模擬和測量中的技術難點，再現不安全場景，通過模擬測試結果判斷是否滿足安全要求。針對未知的不安全場景，也有兩個問題需要考慮:一是如何定義自動駕駛放行的安全準則，什么樣的碰撞概率是可以接受的；二是如何建立場景庫，解決算法的安全問題，而不是總是測試實車，縮短測試周期。

具體來說，對于已知的不安全場景，期望安全標準列出了傳感器、執行器、算法和集成系統的不同測試方法，但目前還沒有量化KPI的方法。對于行業實踐，很多指標需要量化定義。除了感知，實際上還有控制和決策的指標。如何分配和定義各個指標，是目前整個行業面臨的難題。

為了解決這個問題，我們可以量化感知系統的安全KPI:第一層通過RSS或者TTC來評估安全距離是否合適。第二層是通過碰撞檢查評估肇事者是否可控。緩解策略的效果如何？總體來說，通過這兩條路線來評價決策系統是否足夠安全。

圖片來源:上海盤石信息科技有限公司。

如何解決未知場景安全問題，我們需要定義車輛安全準則:汽車行駛了多久，碰撞概率有多大。這是一個相對安全的概念。這是安全性和可用性之間的平衡，因此我們必須考慮定義可接受的風險。什么是可接受的風險？目前有幾種想法。

首先，通過交通道路數據看不同場景下的風險標準。其次是參照功能安全ASIL A-D的等級標準來定義，定義了風險準則之后，還有一個問題，就是如何衡量。據估計，需要140億公里才能證明自動駕駛算法的安全性。這直接反映了自動駕駛系統測得的工作負荷。所以我覺得模擬一定是未來的主流方向。雖然現在仿真存在各種缺點，但是隨著數字軟硬件技術的發展，這些問題會逐步得到解決。

如何解決自動駕駛模擬環境與現實世界的差異

整個仿真和現實世界還是有很大差別的，首先是因為傳感器仿真模型的局限性。上海盤石是一家專業從事汽車功能安全、預期功能安全、信息安全相關的培訓、流程咨詢、產品咨詢、工程服務的專業公司。

上海盤石信息技術有限公司創始人邊軍以“自動駕駛安全實踐的挑戰與思考”為主題，圍繞如何設計可靠冗余、如何讓Linux滿足功能安全、如何覆蓋感知系統的各種故障模式、如何正確判斷自動駕駛設計的ODD、如何定義自動駕駛的安全驗收標準、如何解決自動駕駛仿真環境與現實世界的差異等問題展開。以下是發言摘要:

上海盤石信息技術有限公司創始人邊軍。

如何設計可靠的冗余

首先，我簡單介紹一下自己。我從2009年開始接觸功能安全。當時常用的標準是IEC 61508，應用于工業領域。到現在為止，我從事安全相關的開發和審計已經十幾年了。首先說一下成立上海盤石信息技術公司的初心。經過十幾年的工作，我看到國內的安防領域和國外還是有一定差距的，主要表現在自動駕駛領域，芯片和軟件質量，尤其是自動駕駛領域。安全是從L2到L3演進過程中最關鍵、最基本的一點，這個環節的完成將影響整個自動駕駛產業在中國的落地。

自動駕駛的安全需要聚集國家和社會的財力和知識資源，建立產業連接，才能真正解決其在安全方面的共性問題，最終幫助中國落地自動駕駛。我今天帶來的內容主要分為六個方面，主要是我在整個自動駕駛發展過程中遇到的問題和挑戰，需要大家共同探討和完成。

首先，如何設計一個可靠的冗余系統……em，自動駕駛會從L1進化到L4，安全冗余設置會越來越多。從L3-TJP交通擁堵輔助和L3-HWP高速公路誘導的功能出發，在轉向、機動和定位方面會有冗余要求。L3以上，安全冗余會有全方位的要求，涉及感知、域控、電控等基本操作層面。

從2018年到現在，中國已經形成了自己的系統解決方案，但是有些解決方案并不代表這個領域已經真正實現量產，還有很多技術問題沒有解決。首先，系統需要有有效及時的故障檢測機制。“有效”強調安全冗余機制的性能。國內的安全冗余設計往往是多種安全機制的相互制衡。如果一個安全機制失效了，還要注意另一個安全機制的性能是否能滿足要求。例如，鄭路匹配和絕對定位一起構成了道路級定位的冗余設計。一旦絕對定位失敗，鄭路匹配方案是否足夠精確支持車輛運行是需要考慮的問題。

“及時”強調冗余機制的切換時間，要求系統在短時間內檢測出故障點，并迅速切換到備用機制，保證系統的正常運行。例如，如果將攝像頭和激光雷達結合起來作為車道線識別的冗余設計，一旦激光雷達出現故障，實際車道線將逐漸偏離攝像頭車道線，這就需要激光雷達本身的安全機制及時檢測到故障，然后系統將及時切換到基于攝像頭輸出的側向控制。如果不能及時發現故障，實際行駛車道線與攝像頭車道線偏差過大，系統無法確認故障點，必須采取緊急制動。

第二個難點是復雜的系統設計增加了冗余設計獨立的難度。工作人員需要考慮各種共因故障和級聯故障，尤其是傳感器融合中使用的一些設計，需要考慮傳感器的時間戳、自運動狀態等共因。除了電子和電氣故障，外部環境因素也會導致冗余設計的失敗。例如，降雨可能會導致相機和激光雷達的性能下降。

做冗余設計時，要考慮五個方面。首先要做充分的安全性分析，比如FTA，考慮冗余機制由于性能限制的失效概率。第二，在開發初期做DFA分析，避免潛在的公共失敗和級聯失敗。第三，要有時間規劃，要縮短自我診斷和相互驗證的時間。第四，加大對系統工程的投入。第五，冗余設計不僅要實現ASIL層次分解，還要考慮失效操作。為了順利減少故障，傳感系統需要至少三個獨立的功能/機制，并通過“三取二”的策略快速識別故障。

如何讓Linux滿足功能安全

與其他系統相比，Linux有很多優點。一方面是免費開源，軟件庫豐富，開發成本低。另一方面綜合性能強，響應時間和速度更快，能更有效地運行軟件任務，支持多核運行，適用于不同硬件。同時，Linux也有一些缺點，例如，整個開發過程無法滿足與功能安全相關的標準。下面總結了Linux在功能安全性方面遇到的幾個主要挑戰:

首先是缺少文檔，開發過程無法追溯。有鑒于此，可以使用軟件FMEA分析對軟件模塊進行白盒化，識別故障模式和影響，也可以使用ASIL安全等級分解從不同層次對軟件模塊進行監控，但如果采用軟件監控，則需要另外考慮其獨立性。

其次，難以保證硬實時性。鑒于此，常見的策略是添加實時內核，用雙內核運行，但這種方案也存在很多問題，比如實時內核無法具備Linux內核的優點，Linux內核無法滿足安全性。在……為了保證硬實時性，采用雙核可能會導致代碼移植的問題。

第三，代碼和單元測試的工作量是巨大的，為了安全，需要對不符合ISO26262編碼規范的代碼進行裁剪和重新編譯。第四，安全改造后，Linux的優勢消失。業內有一種假設，未來可能不會出現收縮包裝的Linux軟件包，可以應用于安全性要求高的應用，但硬件的通用性可能會打折扣。

從行業進展來看，目前國內外的組織都在致力于提高Linux系統的安全性。所以從長遠來看，Linux可能是一個更加開放的平臺，未來在安全產品中使用還是有相當大的概率的。

如何覆蓋感知系統的各種失效模式

目前整個自動駕駛的難點其實是感知。例如，L1和L2自動駕駛的主要目標是防止意想不到的AEB與后車相撞。過渡到L3后，會增加很多額外的安全目標，比如正確識別道路邊緣信息；正確識別前方障礙物，防止錯前追尾；正確識別代表ODD的信息，防止系統進入未知的危險狀態。

目前，感知的安全目標主要是為L1和L2級別定義的。一旦應用于L3級系統，如何考慮這些偏差將成為行業難點。想象一下早高峰由陰轉雨的場景。你正在一個十字路口開車，突然攝像頭失靈了。然后你會看到以下場景:行地址失敗，列地址失敗，控制寄存器失敗，像素數據流水線失敗，內存/寄存器尋址失敗，圖像數據流水線失敗。

圖片來源:上海盤石信息科技有限公司。

在L3自動駕駛儀中，既要保證目標的正確識別，又要保證ODD的正確識別，同時還要考慮各種故障對它的影響，這實際上工作量非常大。之前見過一些國外的芯片。他們做這個分析的時候，可能會列出上千個場景，考慮每個場景的影響，以及如何解決。

鑒于上述困難，業界也提出了幾種攝像機的安全機制。一種是像素級模擬測試，主要針對像素點。常見的方法如模擬信號范圍篩選、ADC測試方案、行/列存儲數據路徑測試方案，最后是冗余。像素模擬測試可以解決像素顏色、強度、對比度的問題，也可以發現大于某個閾值的噪聲，但是沒有辦法解決像素的時空表達，也沒有辦法解決圖像傳輸中的問題。

對于圖像測試，這也是目前業內普遍采用的方式。典型的做法是給出一個參考圖像，然后從參考圖像中知道應該輸出什么目標。這種方法的優點是可以測試像素的時間和空間表達，但也有一些缺點，其診斷覆蓋率難以滿足一定的要求，難以遍歷數量巨大的故障模式。

三是測試成分，內容涵蓋像素的顏色、強度、對比度；像素的時間和空間表達；圖像傳輸；也可以發現大于閾值的噪聲，相當于白芯測試，采用關鍵數據寫保護；CRC寄存器；溫度和電壓檢測；時鐘檢查等等。

圖片來源:上海盤石信息科技有限公司。

我覺得這些方法以后肯定會結合起來，但是如何設計出一個診斷覆蓋率高，可以適用于不同安全目標的方案，是所有相機廠商和后端芯片廠商的難題。

如何正確判斷自動駕駛設計的奇數操作設計域

事實上，在自動駕駛早期，大家更傾向于使用靜態奇數約束和地理圍欄。到目前為止，純靜態的運行設計域約束已經不再適用，系統需要有一個有效及時的反映環境條件的動態檢測機制，以保證系統始終在可接受的風險下運行。

這里有兩個例子。左圖是單個因素影響的評估:比如陽光直射導致攝像頭反光，系統如何判斷什么程度的反光會影響駕駛員，什么時候應該退出，這是目前行業的難點。右圖是多個影響因素的耦合:霧夜，迎面遠光燈，此時系統如何評估是退出還是繼續跑？

圖片來源:上海盤石信息科技有限公司。

以下是基于傳感器原理方法的環境觸發條件識別案例:車輛行駛在金屬護欄道路邊緣，雷達反射導致虛擬場景，系統誤以為前方有車，導致誤制動。

圖片來源:上海盤石信息科技有限公司。

如何定義自動駕駛的安全驗收標準

針對如何定義自動駕駛的安全可接受性標準，首先解決兩個問題:一個已知的不安全場景如何被認為是可接受的？未知的不安全場景有什么解決方法？

針對已知的不安全場景，一方面需要量化系統安全性能要求，建立測試評估體系，同時需要解決模擬和測量中的技術難點，再現不安全場景，通過模擬測試結果判斷是否滿足安全要求。針對未知的不安全場景，也有兩個問題需要考慮:一是如何定義自動駕駛放行的安全準則，什么樣的碰撞概率是可以接受的；二是如何建立場景庫，解決算法的安全問題，而不是總是測試實車，縮短測試周期。

具體來說，對于已知的不安全場景，期望安全標準列出了傳感器、執行器、算法和集成系統的不同測試方法，但目前還沒有量化KPI的方法。對于行業實踐，很多指標需要量化定義。除了感知，實際上還有控制和決策的指標。如何分配和定義各個指標，是目前整個行業面臨的難題。

為了解決這個問題，我們可以量化感知系統的安全KPI:第一層通過RSS或者TTC來評估安全距離是否合適。第二層是通過碰撞檢查評估肇事者是否可控。緩解策略的效果如何？總體來說，通過這兩條路線來評價決策系統是否足夠安全。

圖片來源:上海盤石信息科技有限公司。

如何解決未知場景安全問題，我們需要定義車輛安全準則:汽車行駛了多久，碰撞概率有多大。這是一個相對安全的概念。這是安全性和可用性之間的平衡，因此我們必須考慮定義可接受的風險。什么是可接受的風險？目前有幾種想法。

首先，通過交通道路數據看不同場景下的風險標準。其次是參照功能安全ASIL A-D的等級標準來定義，定義了風險準則之后，還有一個問題，就是如何衡量。據估計，需要140億公里才能證明自動駕駛算法的安全性。這直接反映了自動駕駛系統測得的工作負荷。所以我覺得模擬一定是未來的主流方向。雖然現在仿真存在各種缺點，但是隨著數字軟硬件技術的發展，這些問題會逐步得到解決。

如何解決自動駕駛模擬環境與現實世界的差異

整個仿真和現實世界還是有很大差別的，首先是因為傳感器仿真模型的局限性。目前常用的仿真軟件可以模擬大部分傳感器。但是對于污漬和強光的場景，在仿真中很難做出定量的判斷，只能定性的處理，所以很難通過仿真發現算法的邊界問題。

更大的困難是建立一個與真實世界相似的場景模型。場景仿真的計算量很大，如何支持其物理仿真工作。目前可以把它拆解成幾個與功能安全相關的小場景模塊，這是未來一個可能的發展方向。

一般來說，為了解決自動駕駛仿真環境與現實世界的差異，可以采用場景庫的模式:對于決策系統，通過模擬與現實世界足夠接近的場景庫，來識別決策算法的缺陷。也可以采用隨機交通流的方法:由具有自主駕駛能力的智能體或智能體集群組成的動態背景車輛與測試對象交互生成場景，在隨機交通流中進行決策模擬。

(以上內容來自于2022年8月26日由Gaspar主辦的2022中國汽車信息安全與功能安全大會上，上海盤石信息技術有限公司創始人邊軍發表的《自動駕駛安全的現實挑戰與思考》主題演講。)目前常用的仿真軟件可以模擬大部分傳感器。但是對于污漬和強光的場景，在仿真中很難做出定量的判斷，只能定性的處理，所以很難通過仿真發現算法的邊界問題。

更大的困難是建立一個與真實世界相似的場景模型。場景仿真的計算量很大，如何支持其物理仿真工作。目前可以把它拆解成幾個與功能安全相關的小場景模塊，這是未來一個可能的發展方向。

一般來說，為了解決自動駕駛模擬環境與現實世界之間的差異，我們可以ado……場景庫的模式:對于決策系統，我們可以通過模擬足夠接近真實世界的場景庫來識別決策算法的缺陷。也可以采用隨機交通流的方法:由具有自主駕駛能力的智能體或智能體集群組成的動態背景車輛與測試對象交互生成場景，在隨機交通流中進行決策模擬。

(以上內容來自于2022年8月26日由Gaspar主辦的2022中國汽車信息安全與功能安全大會上，上海盤石信息技術有限公司創始人邊軍發表的《自動駕駛安全的現實挑戰與思考》主題演講。)

標簽：優越發現

汽車資訊熱門資訊