最近我們的自動駕駛首發刷屏，ADS終于不是什么神秘組織了。從幾年前不太拿得出手的demo，到今天的成熟度還可以的產品，毫不夸張的說，每一個領域，從理念到設計，都經歷過不止一次的翻天覆地的沖擊和重構。今天回頭看，這是錘煉一個創新產品的及其痛苦但又必須經歷的過程。

安全領域也不例外。

這個過程，迫使我們拋開所有的標準、規范，拷問自己：本質上，自動駕駛的安全風險來自于哪里?

我想，這個圖大致表達了我們的認識：

這個圖直觀的表達了安全風險的來源：用戶預期和系統能力的偏差。

低階傳統ADAS，大家上手一用，就知道它只能用來偶爾松松腳，不會有任何誤解，以為它有更多的高階功能。系統能力low，用戶期望low，安全反倒沒毛病。毛病是產品沒啥用。

高階到無人駕駛，系統能力high，用戶期望high，安全也沒毛病，毛病是這樣的產品還不存在。

麻煩的是從最低點走到最高點的過程。市面上所有的自動駕駛系統，都在這個階段，都在爭取更連續的用戶體驗，都在試圖拔高用戶預期。系統的風險也累積在在這個爬坡的過程中。

用戶是很容易被系統的單點和短期能力取悅的。當系統成功閃開一個小電驢，用戶會默認系統無所不能。當系統一個星期都沒讓人接管，司機信任會急劇增長，然后開始看手機打瞌睡。用戶的預期一定會比系統能力增長快的多。

我們的考量，出發點都在彌合這個gap。

首先，傳統的功能安全設計必不可少

本質上，傳統的功能安全設計，保證了系統能力以外的風險(灰色區域)，能夠被人cover。

具體來說，它在保證兩件事情：第一，司機能夠在任何時候接管。第二，避免對公共安全造成無法避開的傷害。所有人都對交通行為有預期，當自車行為在很短時間內，極大的破壞了這個預期，人是很難及時反應和規避的。

雖然目的一樣，對于高階自動駕駛，這部分設計和傳統ADAS也有很大的不同。但無非也只是功能安全理念在ADS這個新物種上的應用，我相信會是業界研究逐漸趨于成熟的一塊，就不展開多講了。

第二，恰到好處的核心冗余

業界常提的fail-operation，出處是為應對L3的定義：系統故障時，需要給司機預留足夠的時間來接管(通常是10s)。關于這個定義的悖論，業界已經討論的足夠多，也不是這里要討論的重點。重點是，由于SAE對L3的嚴苛定義，導致fail-operation幾乎等同于全冗余，把冗余設計的方向全部帶偏了。

有趣的是，我前兩天參加一個自動駕駛的討論會，看到業界主流顯而易見的共識：沒有人再爭論L2/L3/L4，一致把目標對準了城區、泛化場景和用戶體驗。那么，這是否意味著冗余設計可以徹底不考慮了呢?

問題仍然出在系統能力和用戶預期的gap。當用戶足夠信任系統，他就難以在瞬間接管系統。這是系統冗余要求的根源。

但另一方面，冗余是一把雙刃劍。冗余意味著成本升高、架構復雜、切換過程的無數深坑。用下面這個圖，大家可以圍觀一下某大廠OEM針對自動駕駛系統的冗余架構。不知道這個架構是否已經落地了，我的判斷，這個架構必然是失敗和沒有競爭力的。

第三，重新定義“系統交付”

傳統產品開發過程，是要保證“SOP”那一刻，系統能力、可靠性、安全性達到一個很高的成熟度。但自動駕駛的特點，“SOP”絕不意味著產品開發的結束。系統能力不斷爬坡的過程，甚至很大程度發生在SOP之后。這對于傳統安全設計的“系統思維”，是一個顛覆性的沖擊。這意味著按照傳統的方法，列出所有的需求，在SOP前按V模型開發交付落地，既不現實，也無必要。

“數據驅動改進“的提法在自動駕駛領域很流行，也是領域主流玩家一致認可的系統進化方向。對于安全設計來說，要應對這個趨勢，一是能夠在每個階段，識別出關鍵的交付目標。同時，數據閉環的及時性相當重要，這也是我們“Data Driven Improvement”方案要解決的問題。還有一點決不可忽視，在系統爬坡的過程中，需要使用合理的人機交互設計，控制整體系統的風險。

這也引出了最后一點，也是我認為最難的一點：通過人機交互設計，讓用戶預期和系統能力盡可能趨于一致。

這個難點在于“用戶體驗”和“用戶預期”之間的平衡。從用戶體驗角度，希望用戶盡可能不受干擾，徹底解放。從產品安全的角度，又需要用戶隨時應對系統能力邊界，做好接管的準備。這兩個方面的訴求，對人機交互設計提出了非常高的要求：非必要的時候，盡可能不干擾用戶;提醒盡可能精準和直觀;基于系統能力演進，不斷調整和進化人機交互。。?？赡艽蠹覜]有意識到，這個領域的設計難度和工作量，一點不比算法開發容易。

最后，這幾年總是聽到大家在吐槽，傳統的功能安全方法不能有效應對新技術的發展。希望能夠拋磚引玉，給大家提供一些新的思路，來解這個問題。畢竟，產品的用戶體驗是自動駕駛賽道的關鍵核心競爭力，安全性同樣是這個馬拉松賽道上，笑到最后的保證。