作者 / 浪跡天涯
出品 / 焉知

站在2020年年尾回看智能駕駛，這一年黑科技層出不窮，無疑是一片琳瑯滿目的壯觀景象：超大的顯示屏娛樂功能強大、智能座艙高度數字化、OTA遠程升級幾乎是新車型標配、ADAS輔助駕駛功能也越來越豐富和實用......至于智能駕駛的終極目標——無人駕駛，在市場的狂熱逐漸退燒后，各大廠家重新制定了自動駕駛計劃。智能汽車正在朝著便利和解放駕駛員的方向上狂奔。

但是，除了給駕駛員帶來便利以外，智能汽車更核心的愿景是減少交通事故，為人類創造更美好的生活。如果解放了駕駛員的同時卻不能保證駕駛員的安全，個人認為智能汽車上的黑科技更多的是錦上添花，而沒有大規模推廣的意義。

支撐所有智能駕駛技術的是全新的電子電器系統，而電子電器系統的基本組成是軟件和硬件。從這個角度，智能駕駛的安全就是軟件和硬件的安全。為了讓軟件和硬件足夠安全，無數的汽車工程師正在行動，并在探索與合作的過程中逐步達成了共識，至少要從三個方面去保證安全：

功能安全 （Functional Safety）
預期功能安全（Safety of the Intended Functionality）
信息安全 （Cyber Security）

未來的智能汽車在安全上的突破，就是找到這三個方向在汽車上落地量產的可行性方案。而這三個方向的落地之難，從某種程度上也折射出智能駕駛距離終極目標的距離還很遠。本文將對這三個方向的內容以及發展現狀做簡單介紹，嘗試回答落地難在何處，希望給讀者們帶來一些有價值的參考。

1. 功能安全 （Functional Safety）

1.1. 什么是功能安全？

ISO 26262中對功能安全的定義為：

ISO 26262：absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.（不存在由電子電氣系統的功能異常表現引起的危害而導致不合理的風險）

簡而言之，功能安全聚焦系統故障后怎么做。危害有很多類型，如人身傷害或者財產損失等等。功能安全所關注的危害指對駕駛員或者路人或周邊車輛內人員（注意：不僅僅是駕駛員）造成的健康傷害。換句話說，功能安全開發目的是避免傷人。

功能安全的定義中有一個關鍵詞“unreasonable”，即“不可被接受的”。就像世界上沒有永動機一樣，世界上也沒有100%安全的系統，因此功能安全追求的是將危害控制在可被接受的范圍。而是否可被接受，需要從兩個維度去衡量：危害的嚴重性和危害發生的頻率。舉例來說，飛機失事幾乎無人生還，但是正因為飛機失事的概率非常低，所以不影響它成為最重要的交通工具之一；電動車窗發生卡滯故障的頻率比較高，但是故障不會讓人受傷，因此很多司機甚至只有等到下個月去4S店時才想起來維修它。但是，如果你的車突然在高速上自動加速，估計你馬上停在緊急帶，驚魂未定便馬上打電話給4S店喊著要退車了，因為這種原本可以通過設計規避的故障是不可接受的。這也正是功能安全開發期望避免的故障。

1.2. 功能安全的發展現狀

相對于預期功能安全和信息安全，功能安全的發展是最成熟的。自2011年功能安全標準ISO 26262正式發布以來，已經過去了快10年。這這段時間里，在汽車智能化高速發展的驅動下，功能安全越來越被汽車行業接受，國內外各大主流汽車企業陸陸續續將ISO 26262的需求融入自己的研發體系和流程中，以保證安全能跟上電子電器系統快速變革的步伐，保證輔助駕駛功能不僅好用而且安全。借著這股東風，ISO 26262一路“平步青云”，功能安全儼然成為了汽車研發的新興熱門話題。

但是，隨著更高階的自動駕駛的開發思路越來越清晰，功能安全也漸露窘色。

相比較輔助駕駛，自動駕駛最大的難點在于系統在出現故障之后，需要系統來自己操作避免事故（自動駕駛等級越高，駕駛員可以越晚介入接管甚至是完全不用接管），出了事故是廠家的責任而不是駕駛員的責任。

這正是為什么之前特斯拉被告虛假宣傳，從而不得不將其宣稱的“自動駕駛”改成“增強版輔助駕駛”的原因。因為特斯拉的Autopilot功能正常工作的時候，表現得確實是無人駕駛，而一旦出現異常，卻是由駕駛員來擔責。

故障發生后，系統從報警變成了繼續進行安全控制，可以預見，功能安全的開發難度以及功能安全對系統架構的要求都產生了質的改變。汽車實現自動駕駛實際上和已經實現了自動駕駛的飛機的設計思路類似。飛機的自動駕駛是怎么保證的呢？除了盡可能保證零部件可靠性之外，飛機會有兩個發動機，保證在一個發動機故障以后另一個仍能保證安全飛行。這就是“冗余設計”的概念。冗余設計在飛機上到處可見，比如兩個獨立運行的計算機系統，兩套獨立的供電系統等等。

回到汽車自動駕駛上，同樣對關鍵部件采用冗余設計，保證當故障發生后備份系統仍能保證車輛正常運行。可以預見的是，自動駕駛的大腦控制系統、制動系統、轉向系統、供電系統等都需要冗余。

但是，冗余一方面意味著部件數量增加，成本上升；另一方面，功能安全中會對系統故障可能導致的危害事件進行分級，簡單來說從ASIL A到ASIL D危害程度逐漸升高。那么開發要求也逐漸升高。比如單就硬件開發而言，ASIL D對單點故障度量（SPFM, signal point fault metrics）、潛在故障度量(LFM, Latent fault metrics)等的指標要求近乎苛刻。

而對于需要冗余的制動系統、轉向系統、大腦控制系統等而言，它們的失效都會引起一些ASIL D的危害事件，換句話說，這些系統的開發需求中至少有一部分是有最嚴苛的ASIL D要求的。如今兩套冗余都需要滿足這些要求，無疑增加了開發難度和開發成本。

但是汽車開發又不得不面對這樣的現實：和飛機不同，汽車的利潤比飛機的利潤低得多，全靠走量，如果不計成本，那么即使實現了安全系數很高的自動駕駛系統，也會因為價格過高而不被市場認可。如何在功能和安全之間找到平衡，是功能安全在自動駕駛汽車上面臨的挑戰之一，也是未來在智能駕駛汽車上真正落地功能安全的關鍵。

2. 預期功能安全 （SOTIF, Safety of the Intended Functionality）

2.1. 什么是SOTIF?

在回答這個問題之前，先問一個問題：就算不計成本地保證了智能駕駛系統的功能安全，這個系統是否就足夠安全了呢？

我們不妨先來看一個召回的案例。

2020年3月19日，由于自動緊急制動系統（Autonomous Emergency Braking, AEB）存在故障，沃爾沃汽車宣布在全球范圍內召回汽車近74萬輛，共涉及9款在售車型。此次召回的原因，是因為一些場景下無法有效識別物體，導致AEB在該工作的時候不工作。一般AEB探測物體依賴傳感器毫米波雷達和攝像頭兩個關鍵傳感器的信息融合。因為多普勒效應，毫米波雷達不擅長識別靜態物體；而攝像頭在霧天或者光線不足等情況下探測度都會降低，這些因素都會導致在一些場景下無法正確識別物體從而激活AEB。

因此，這次召回不是因為系統故障導致的，而是傳感器本身的功能局限導致的。ISO 26262功能安全旨在避免電子電氣系統故障導致功能異常而引起的不合理的危害，功能受限ISO 26262的范疇。為彌補功能安全的局限，預期功能安全SOTIF (Safety of the Intended Functionality)以及標準ISO 21448便誕生了。

簡單來說，SOTIF強調的是避免因為預期的功能表現局限而導致不合理的風險。

因為SOTIF誕生的背景是智能駕駛的發展，所以如果按照智能駕駛的功能鏈：感知——決策——執行來歸類，“功能表現局限”體現在3個方面：
（1）傳感器感知局限導致場景識別錯誤
（2）深度學習不夠導致決策算法判斷場景錯誤
（3）執行器功能局限導致與理想目標偏差

而從另一個維度，“功能表現”可以概括為4類：
（1）在危險場景介入 （正常工作）
（2）在非危險場景介入 （誤觸發）
（3）在危險場景不介入 （漏觸發）
（4）在非危險場景不介入（正常關閉）

第1種和第4種情況沒有危害，而其余兩種則有危害，也正是SOTIF關注的危害。要有效避免誤觸發和漏觸發，第一步是識別場景并進行分類，確定哪些場景下功能觸發是安全的，而哪些場景下功能不觸發是安全的。在OTIF將所有的場景劃分成下圖所示四個部分，且目標為：最大可能減小Area2 (known unsafe scenarios) 和Area3 (unknown unsafe scenarios) 的范圍。

2.2. SOTIF的發展現狀

目前SOTIF的標準ISO 21448還是draft版本，按照計劃在2022年3月正式發布。目前對于一些關鍵問題仍然存在爭議，這也是ISO 21448遲遲沒有發布的重要原因。

舉例來說，而對于Area3(unknown unsafe scenarios)，處理起來則相對棘手很多。舉個例子，這就好比我們在開發一輛將來投放在中國市場的車，需要在開發初期事先識別出一輛車在中國路況下可能會碰到的各種場景。我想即使讓全世界頂尖的安全專家坐一起產出也極其有限。

SOTIF對降低Area3，大體思路如下：

（1）提高系統和零部件功能的可信度。

Validation: set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals, and objectives

Note to entry: ......Validation activities address mainly "area 3" of figure 7 including the validation of SOTIF in unknown use cases."

（2）endurance run。

概括來說就是通過實車路試和仿真測試積累大數據。當數據積累越多，越能夠將unknown scenarios變成known scenarios。

積累實車路試和仿真測試數據是一件耗時耗力耗材的大規模工程。這無疑又給智能駕駛的安全開發增加了成本，另外，搭建可信度高的仿真測試平臺也需要巨額成本，成本因素會給SOTIF的推廣帶來比較大的挑戰。另一方面，ISO 26262從誕生到被行業普遍認可用并較為熟練運用經歷了9年，SOTI又會如何目前仍是一個問號。

3. 信息安全 （Cyber Security）

3.1. 什么是信息安全？

功能安全和SOTIF研究的對象是智能駕駛系統自身可能產生的失效，還有另一類失效也是未來智能駕駛不可忽略的——黑客攻擊。

2015年7月，兩名美國白帽黑客成功侵入一輛正在行駛的JEEP自由光SUV的CAN總線網絡系統，向發動機、變速箱、制動、轉向等系統發送錯誤指令，最終使這輛車開翻到馬路邊的斜坡下。這起案件導致吉普大規模召回。

為了應對這一種情況，已經在互聯網領域發展很成熟的信息安全正在被運用到汽車開發中。智能駕駛的智能化程度越高，可能被黑客攻擊的點就越多，對信息安全的需求量更大。

這里需要強調一點，功能安全和SOTIF以人身安全為核心，但是不是所有的信息安全問題都會導致人身安全。換句話說，信息安全除了要考慮人身安全以外，還需要考慮黑客攻擊帶來的其他風險，比如車輛被偷導致的財產損失以及隱私泄露風險。

3.2. 信息安全的發展現狀

2020年車輛信息安全標準ISO 21434，Road Vehicle - Cybersecurity Engineering標準正式發布，該標準是基于SAE J3061制定的、針對車輛整個生命周期的標準。主要涵蓋安全管理、基于項目的網絡安全管理、持續的網絡安全活動、相關風險評估方法、以及道路車輛概念驗證階段，產品開發階段和開發完成后階段的網絡安全。

對于該標準如何落地，業界尚在摸索中。于此同時，信息安全既然也包括了對人身傷害的預防，那么必然和功能安全以及SOTIF有交集，如何將三者的開發有機聯系起來目前還沒有成熟的方案，這也是亟需解決的關鍵問題。

4. 結論和展望

通過上面的介紹可以看到，要保證智能汽車的安全性任重道遠。希望大家在重視智能汽車便利性的同時，也更多的關注智能汽車的安全性。畢竟安全是智能汽車的核心。只有建立在安全的基礎上，其他的技術才可以稱之為錦上添花而不是雞肋。

當然，我們也可以看到，在經歷了初期的狂熱后，工程思維的理智慢慢將行業拉回腳踏實地的軌道。如今安全越來越受到汽車行業的重視，一大批工程師正在為智能駕駛的安全而努力，相信在未來足夠安全的智能汽車將“飛入尋常百姓家”，造福人類。

本文轉自：焉知自動駕駛，轉載此文目的在于傳遞更多信息，版權歸原作者所有。