引言

自動駕駛SOTIF落地的思考與展望

隨著汽車“新四化”的演進，上半場“電動化”已經初具格局，下半場“智能化”正火熱進行，智能汽車的安全嫣然成為智能化的核心競爭力之一，隨著《關于開展智能網聯汽車準入和上路通行試點工作的通知(征求意見稿)》的發布，對L3&L4的安全要求提出了框架指示，未來、誰能掌握安全的制高點，那么誰在智能化競爭中勝算就會更大，而耳熟能詳的ISO 26262已經無法覆蓋EE系統安全問題，隨著ISO 21448的發布，貌似給自動駕駛企業帶來一絲絲曙光，那么21448在企業如何落地呢？筆者聊聊個人淺見。

01

小科普（老手略過）

ISO 26262是為了解決電子電氣系統失效導致的不合理的風險，且假定預期功能是安全的（預期功能不安全屬于SOTIF范疇）。功能安全是對EE失效的研究，確切的說是對“EE白盒失效”的分析然后對失效進行避免或者控制，將風險降低到合理可接受程度，而隨著技術發展，自動駕駛涉及的各個要素的失效原因，甚至失效模式不再是“白盒”，傳統的功能安全已經不能cover相關安全風險，EE系統在沒有故障的情況下，由于功能不足（規范不足和性能不足）、人員誤用仍會導致風險，基于此背景ISO 21448標準立項成立，正式版標準于2022年6月發布。

02

標準適用范圍 （老手略過）

車型：乘用車、商用車（含低速物流小車）

功能：適用于依靠復雜傳感器和處理算法進行態勢感知且感知的正確性會對安全產生重要影響的預期功能，特別是駕駛自動化等級為 L0～L5級的相關功能。

補充幾句：SOTIF同樣適用于非ADAS的EE功能，如：假設電動車窗防夾力設計200N，當車窗開關被兒童誤觸發（直接誤用）導致夾傷肢體，防夾參數本身的不安全，屬于SOTIF范圍的“規范的不足”。

03

SOTIF開發模式的思考

先回顧一下功能安全，功能安全的現狀是OEM提出功能安全需求，由Tier1承接并轉化為技術安全需求，最后把需求傳遞給Tier2，細化成軟硬件安全需求（當然，由于產業鏈重塑，出現了T0.5/T1.5/全棧自研等角色，但是FUSA需求傳遞理念是不變的），由于功能安全算是一個歷史悠久的標準，且整車安全目標已經趨于統一，供應商早已基于行業經驗或者SEOOC開發一個帶有ASIL屬性的產品（傳感器、控制器、執行器、操作系統、芯片等）。

先看一看SOTIF的SEOOC可行嗎？

關于SOTIF的發展，個人預測它不會像功能安全一樣多點開花，受以下因素制約：

其一、整車車型不同，車身軸距、重量不同（影響DDT參數標定）

其二、硬件方案不同，如傳感器的數量、冗余類型，安裝位置有差異；

其三、軟件算法不同，感知融合算法類型/參數不同、規控算法差異；

其四、ODC不同，導致整車層級安全策略、駕駛策略、MRM策略，人機交互策略不盡相同。

以上原因導致整車層級，系統層級，部件層級的SOTIF需求差異化嚴重，供應商的同一款產品搭載到不同公司、不同平臺車型的SOTIF需求短時間無法統一。

面對以上眾多“車端”SOTIF需求的不確定性，導致SEOOC的逆向開發模式異常困難，基于此現狀筆者認為SOTIF的開發將以OEM（或者系統供應商）為主導地位。

04

工程落地的思考

結合對自動駕駛發展趨勢的判斷及個人一些淺見，筆者認為SOTIF的落地大致會經歷三個階段：初學乍練，漸入佳境，登堂入室（這要是放在古代，筆者還真是文人墨客，遷客騷人）

初學乍練

“二八原則”是關鍵

為什么說“二八原則”，什么是SOTIF的“二八原則”？

回答這個問題前，我想還是從功能不足和觸發條件的識別說起吧，不論是FUSA還是SOTIF，其本質都在降低風險到一個可接受的程度（這是一種“想對安全”的理念，還不是“本質安全”），識別故障和不足是前置條件，對于26262而言，通過安全分析FMEA、FTA等方法識別故障，然后設計安全機制，但是SOTIF面對的是人-車-環境交互的復雜體，其“系統”已經不局限于車，隨機性的場景對智能駕駛的潛在影響也不是一兩句話能解釋清楚，傳統的安全分析用在SOTIF上明顯乏力，安全分析的“完整性”一詞也不再適用于SOTIF。

目前的窘境是，大部分公司的SOTIF都是功能安全負責人帶頭干，初衷是好的，但是心有余而力不足，你能識別出的功能不足和觸發條件，人家系統工程，算法工程師或許早就知道，興許人家的know how比你還要多的多，你能分析到的僅僅是你能知道的，那還做什么SOTIF？直接去測試，不斷發現問題，解決問題就好了，其實這也是Waymo case by case的做法，實踐下來取得的效果也不錯，Waymo在2021年之前感知模塊問題占比較大，2021之后規控問題占比上升（并不是說規控問題發生次數多了，而是感知問題占比降低，導致規控問題占比升高）。

再回到SOTIF本身，此階段不意味著躺平，企業需要引入SOTIF理念，建立SOTIF流程，智能駕駛開發人員具備SOTIF全流程的認知，埋下SOTIF文化的種子，但不必期望SOTIF這件事情能立刻開花結果，更沒有必要急功近利的撰寫大量的“紙面無用功夫”，筆者認為20%的精力用于SOTIF V流程左側就夠了，80%精力用于V右側的測試、確認以及真實數據池的建立。

積累數據，用數據回放的形式來打磨算法也好，還是用IDM(Intelligent driver model)等手段來訓練規控也好，總之、真實數據收集是關鍵。

小結：本階段，搭建流程是基礎，用測試手段去閉環功能不足和積累觸發條件是核心，這個階段還沒有到數據驅動，仍然是靠人在驅動閉環流程。

進入佳境

隨著行業的摸索，自動駕駛的功能架構、系統架構差異化逐漸縮小，硬件方案（傳感器數量、安裝位置甚至冗余思路）趨同，差異化集中在軟件本身。

基于上述假設，從安全角度勢必會出現通用的自動駕駛的感知、預測、決策、規劃、控制模塊的“頂層安全準則”，其實這些“頂層安全準則”已經在UL 4600的第8&9章節對應的required小章節有所體現，但是采用何種技術手段去實現這些模塊的“頂層安全準則”標準并沒有提及，也不會提及，這將是每家企業的智駕產品在安全維度的核心競爭力所在。

說了這么多，讀者會問SOTIF在感知、預測、決策、規劃 、控制模塊到底要做什么？

筆者認為這個答案并不在問題本身這個層面，要跳出問題本身來思考，原因在于筆者看好AI在智能駕駛上的應用，推斷“預測”、“決策”、 “規劃”幾大模塊的算法會逐漸AI化才能真正實現自動駕駛，從安全維度刻意區分是FUSA的問題還是SOTIF的問題并沒有太大意義（不考慮幾大模塊運行載體的失效，如SOC/MCU硬件故障）。

感知、預測、決策、規劃 、控制模塊SOTIF需求的導出

SOTIF的頂層目標是接受準則，接受準則是量化指標，那么它必定會和感知、預測、決策、規劃 、控制模塊從量化需求上產生某種函數關系，對于ADS子模塊的量化指標，本質上就是SOTIF需求，這是正向導出需求的大體思路。

但是、正向操作非常困難，基于此背景，先摸底各個模塊的性能，由各個模塊負責人去論證其模塊承擔的功能的安全維度可接受性，在執行validation活動中繼續識別模塊的不足，反復優化模塊性能，直到接受準則被論證實現，最終每個模塊形成該模塊功能各個維度的量化參數，作為基線版本，這或許是現階段可落地的方案之一。至于接受準則要執行多少公里/時長，是否能執行下去，以及如何執行，另當別論。

讀者可能問“如果接受準則是定性的，怎么辦？”

從定性角度論證接受準則的達成，筆者認為這將是一件眾口難調的事情，尤其是L3及以上最好不要這么搞。

定性的接受準則需要寫一篇“議論文”，中心論點是系統在safety measures的加持下所有潛在危險場景下C=0，得到S*C=0，無SOTIF風險。

但是、這將引出若干個偽命題，如“所有潛在危險場景”的完整性、覆蓋率如何通過“紙上”論證呢？有報警但是駕駛員不接管的話，C=0？還是論證M值呢？

以上僅拋出一些開放式的問題。

另外、補充一下，SOTIF不僅關注ADS系統內的模塊的性能，還涉及諸多規范層面的不足，筆者認為在執行上述活動過程中，規范的不足的識別和修改反而是水到渠成的事情。

小結：本階段研發團隊搭建數據驅動和閉環的流程是核心，同步創建功能Use case庫、SOTIF場景庫；測試團隊拉通“多支柱法”測試和研發團隊形成良性循環，不是為了測試去測試，而是為了發現、彌補設計的不足，這“任督二脈”的打通是SOTIF成敗的關鍵。

登堂入室

軟件定義汽車時代，數據、算法和算力是自動駕駛開發的核心三要素，企業能夠持續地低成本、高效率、高效能收集和處理數據，并通過數據迭代算法，最終形成數據閉環是自動駕駛企業可持續發展的關鍵所在，那么數據到底驅動了啥？閉環了啥？和SOTIF又有啥關系？

先看一下數據驅動的流程圖：

從2021年開始，走“漸進式”路線的企業陸續實現L2+級別車輛規?；慨a，數據閉環模式逐漸打通，眾包收集場景，進行數據挖掘，反復迭代優化算法，逐級攻克L3&L4場景問題，這是業界常規做法，而SOTIF的運行階段活動核心不就是需要打造這么一個閉環流程嗎。

那么對于SOTIF而言數據驅動更關心什么？應該干點啥？怎么干？

筆者認為最重要的是建立獲取邊界數據的有效觸發機制，獲取更多邊界數據，數據閉環的觸發機制包含功能觸發、功能誤觸發/漏觸發、駕駛員行為觸發等，而SOTIF恰好可以利用這些觸發機制提取“危險行為”，完善上文所說的SOTIF場景庫，然后對數據泛化加工、測試和更新軟件，得到特定場景的DDT安全策略也不是不可能，形成感知、預測、決策、規劃 、控制模塊的最佳安全模型也不是不可能，關鍵在于SOTIF如何和數據驅動有機結合！

但是問題來了，眾包采集的原始車輛的傳感器配置可能較低，會漏掉一些目標特征信息，這對于SOTIF是否有影響？影響有多大？如何減小影響？行業內是否有相關技術能攻克這一難題？

BEV技術不強依賴目標特征，或許是解決方案之一吧。

小結：筆者認為SOTIF的終極形態是沒有專門的SOTIF工作，而是將其融入現有自動駕駛開發流程，由各模塊負責人去兼容，這是最靠譜的模式。世上本來不存在SOTIF，標準成立了，也就有SOTIF了。你品，你細品！

05

建立用戶對“自動駕駛”的漸進式成長的認知

想一想還是應該補充這一段內容。

市場上L2+產品事故已發生多起，從SOTIF角度分析，大部分事故原因是人員誤用（分心）+功能不足導致（感知的漏檢居多），人員誤用屬于駕駛員的責任，功能不足屬于車企的責任。

“用戶教育”對于SOTIF要求的避免合理可預見的人員誤用大有裨益。（至于為什么不解決車端的功能不足，而去約束駕駛員的誤用，相信不需要解釋了）

不論是L2.5還是L2.9，都是L2，OEDR主體仍是駕駛員，企業應建立用戶告知機制，確保用戶充分掌握智能網聯汽車與傳統汽車在操作、 使用等方面的差異，告知自動駕駛功能產品功能及性能限制、 車內安全員職責、 人機交互設備指示信息、 系統操作說明、 功能激活及退出條件和方法、 最小風險策略、系統潛在風險說明、人工接管預留時間、不可避免碰撞的響應策略等信息。告知信息應明確寫入產品使用說明書。（摘自：關于開展智能網聯汽車準入和上路通行試點工作的通知(征求意見稿)）

其次、在上述要求基礎上，增加“用戶培訓”機制，如：電子考試，考試通過后方可開啟智駕功能，這也是不錯的防誤用手段。

06

Tier1該干點啥呢？

前段時間和某Lidar公司同仁聊天，談到Lidar如何做SOTIF的話題，有幾點體會和大家分享一下，尤其對于傳感器而言，如lidar這種精密器件，它的失效原因可以識別、但是失效模式、失效影響可能都很難評估，比如盲線和瞎線對整個lidar輸出到底有多大影響，目前還是說不清楚的，產品還不能按照最差失效模式、失效影響處理，這樣會導致產品性能的提升和成本的投入不成正比。

上文中，筆者陳述了SOTIF將是以OEM（或者系統供應商）開發為主導，原因不再贅述，面對SOTIF，筆者認為傳感器供應商當前能做的工作不多，能了解SOTIF概念，能和OEM在SOTIF話題上有共同語言就行了。

躺平也不行，干點啥？

Tier1應該清晰的知悉自身產品性能邊界，比如對某傳感器而言，其準確率和召回率是SOTIF強相關的，做到100%肯定不可能，那么做到XX%才算符合OEM的需求呢，多說幾句，這里會引出兩大類問題：

第一、從整車級如何導出對融合算法的量化需求？以及融合算法連續幾幀錯誤輸出才會產生危險行為？

第二、從融合算法又如何向輸入端（傳感器）導出量化需求？

如果現階段無法從正向導出量化需求，逆向操作是否可行？

先依據已知的感知性能參數，通過實車validation，符合了確認目標，論證接受準則被實現是否可行呢？進而確定某傳感器的準確率和召回率分別是XX%，在基于某傳感器架構方案下，某融合算法方案前提下，才符合了SOTIF要求，筆者認為迫于現狀，大概率先這樣做。

在不同架構、不同融合算法下，同一個傳感器發揮的能力是不同的，其單一傳感器的weakness對感知融合的輸出影響也不同，傳感器自身性能提升的可能性不大，還是在ADS感知融合模塊做文章，更大程度上容忍單一傳感器的信息偏差，劇情大致是這么一個走向。

限于公司要求及作者能力，本文還有很多“坑”沒有填，許多開放式的問題需行業同仁共同努力…

審核編輯 ：李倩