無論是自動駕駛整車，還是解決方案，或是軟件、演算法、硬件單個模組，量產落地的速度有明顯加快的趨勢。在開發過程中，對安全的要求及管控愈加迫切，目前行業裏將自動駕駛安全分為Safety（FuSa和Sotif）和Security兩大部份，這裏分享一些思考。
回顧Uber自動駕駛事故
2018年3月，一輛Uber無人駕駛測試車在美國釀成致死事故，一度讓整個行業陷入停滯 ，事後結案報告分析了主要原因。
首先Uber對周圍環境感知的模型，假定只會出現單車、行人、車輛三類物體，且這三類物體只會沿著車道線行進。
但現實情況是行人推著單車橫穿馬路，按照模型預設，Uber在任何情況下都不會對上述場景進行分類辨識。
其次是車輛駕駛員對Uber並沒有及時接管（過於自信），在整個系統設計中沒有考慮到人為因素。
從這個事件可以看到，自動駕駛安全設計，除了去滿足已有規格書Spec的要求，更需要去驗證Spec的充分性。
自動駕駛安全的特殊挑戰
從上述案例引申出來，自動駕駛對安全提出很多挑戰。
首先，自動駕駛是以數據來驅動的，而大量數據集很難透過要求來描述；其次，AI演算法的輸出缺乏可解釋性，難以透過傳統的透過/不透過（yes/no）的方式去驗證；再次，還存在大量非技術因素，包括交通系統布局不合理、交通參與者行為不規範等；最重要的是，存在大量的隨機的且未知的長尾場景。
為了應對以上挑戰，在Safey領域主要以功能安全FuSa和預期功能安全Sotif兩大標準進行約束。
FuSa和Sotif是安全的兩大命門
功能安全（Function safety），關註E/E電子電氣架構本身的失效（Failure）；而預期功能（Sotif），解決的是自動駕駛由於效能局限、功能不足及合理可預見的人員誤用帶來的危險（Harzard）。
功能安全是假定規格書Spe是正確的前提下，去關註產品有沒有遵循或實作相關的流程和標準；而預期功能安全更多是針對產品規格書Spe不足的地方進行規範，兩者相互補充，是自動駕駛安全的兩大命門。
在這兩個安全之上，又誕生了網絡安全（Cybersecurity）的要求，三者的關系可以用以下的圖來表示。
針對於危險，如果是從本身系統而來的，需要遵循功能安全；如果是來源於系統外部，且被人故意誤用，那麽屬於網絡安全的範疇；其他層面全部劃分到預期功能安全的範疇。
FuSa和Sotif如何解決安全問題
根據安全類別以及認知程度，可以將自動駕駛場景劃分到四個區域。
區域1是已知、安全的場景（Known-Safe），區域4是未知、安全的場景（Unkown-Safe），自動駕駛汽車可以執行在這兩個場景中。
針對於區域2，已知、不安全的場景（Known-Unsafe），需要在系統設計時，提前考慮。
而針對於區域3，是未知、不安全（Unknown-Unsafe），可以理解為長尾的場景。
有兩種思路來應對區域2和區域3的安全問題，一是保守的方法，即透過限定自動駕駛執行設計域ODD，讓自動駕駛系統只能在已知和安全的場景才能執行，但這樣治標不治本，更不利於自動駕駛的規模商業化落地。
另外一種思路是努力將區域3的範圍縮小，但是，由於未知的場景是無窮無盡的，無論如何縮小，永遠都存在。
進一步來說，區域3理論上可以看作「熵增」運動，要努力減熵，需要保持開放，同時要有外力做功，減少混亂程度，脫離平衡。
對映到自動駕駛，一是讓系統本身透過數據閉環，持續地學習和升級；二是透過V2X，增加視距，增強對未知場景的認知程度。
汽車人參考小結
系統內的失效或危險，可以透過功能安全來管控，而針對於系統外的失效或危險，可以透過預期功能安全和網絡安全來管控。
但是本質上都沒有解決在長尾場景下的安全問題，透過傳統預測概率和規避的方式已不適用，透過數據閉環依然還是無法cover到100%，因為AI本身的無法解釋特性，會不會導致安全就是一個無解問題，值得行業探討。
本文為汽車人參考第370篇原創文章，如果您覺得文章不錯，「推薦和關註」是對我最大的支持，歡迎隨時和我交流。
