引言

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

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

01

小科普（老手略過）

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

02

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

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

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

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

03

SOTIF開發(fā)模式的思考

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

先看一看SOTIF的SEOOC可行嗎？

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

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

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

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

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

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

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

04

工程落地的思考

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

初學乍練

“二八原則”是關鍵

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

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

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

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

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

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

進入佳境

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

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

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

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

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

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

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

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

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

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

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

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

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

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

登堂入室

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

先看一下數(shù)據(jù)驅動的流程圖：

從2021年開始，走“漸進式”路線的企業(yè)陸續(xù)實現(xiàn)L2+級別車輛規(guī)模化量產(chǎn)，數(shù)據(jù)閉環(huán)模式逐漸打通，眾包收集場景，進行數(shù)據(jù)挖掘，反復迭代優(yōu)化算法，逐級攻克L3&L4場景問題，這是業(yè)界常規(guī)做法，而SOTIF的運行階段活動核心不就是需要打造這么一個閉環(huán)流程嗎。

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

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

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

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

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

05

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

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

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

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

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

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

06

Tier1該干點啥呢？

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

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

躺平也不行，干點啥？

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

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

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

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

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

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

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

審核編輯 ：李倩