自動(dòng)駕駛SOTIF落地的思考與展望

引言

自動(dòng)駕駛SOTIF落地的思考與展望

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

01

小科普（老手略過）

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

02

標(biāo)準(zhǔn)適用范圍 （老手略過）

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

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

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

03

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

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

先看一看SOTIF的SEOOC可行嗎？

關(guān)于SOTIF的發(fā)展，個(gè)人預(yù)測(cè)它不會(huì)像功能安全一樣多點(diǎn)開花，受以下因素制約：

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

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

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

其四、ODC不同，導(dǎo)致整車層級(jí)安全策略、駕駛策略、MRM策略，人機(jī)交互策略不盡相同。

以上原因?qū)е抡噷蛹?jí)，系統(tǒng)層級(jí)，部件層級(jí)的SOTIF需求差異化嚴(yán)重，供應(yīng)商的同一款產(chǎn)品搭載到不同公司、不同平臺(tái)車型的SOTIF需求短時(shí)間無法統(tǒng)一。

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

04

工程落地的思考

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

初學(xué)乍練

“二八原則”是關(guān)鍵

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

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

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

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

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

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

進(jìn)入佳境

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

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

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

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

感知、預(yù)測(cè)、決策、規(guī)劃 、控制模塊SOTIF需求的導(dǎo)出

SOTIF的頂層目標(biāo)是接受準(zhǔn)則，接受準(zhǔn)則是量化指標(biāo)，那么它必定會(huì)和感知、預(yù)測(cè)、決策、規(guī)劃 、控制模塊從量化需求上產(chǎn)生某種函數(shù)關(guān)系，對(duì)于ADS子模塊的量化指標(biāo)，本質(zhì)上就是SOTIF需求，這是正向?qū)С鲂枨蟮拇篌w思路。

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

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

從定性角度論證接受準(zhǔn)則的達(dá)成，筆者認(rèn)為這將是一件眾口難調(diào)的事情，尤其是L3及以上最好不要這么搞。

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

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

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

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

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

登堂入室

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

先看一下數(shù)據(jù)驅(qū)動(dòng)的流程圖：

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

那么對(duì)于SOTIF而言數(shù)據(jù)驅(qū)動(dòng)更關(guān)心什么？應(yīng)該干點(diǎn)啥？怎么干？

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

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

BEV技術(shù)不強(qiáng)依賴目標(biāo)特征，或許是解決方案之一吧。

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

05

建立用戶對(duì)“自動(dòng)駕駛”的漸進(jìn)式成長(zhǎng)的認(rèn)知

想一想還是應(yīng)該補(bǔ)充這一段內(nèi)容。

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

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

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

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

06

Tier1該干點(diǎn)啥呢？

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

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

躺平也不行，干點(diǎn)啥？

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

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

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

如果現(xiàn)階段無法從正向?qū)С隽炕枨?，逆向操作是否可行?/p>

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

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

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

審核編輯 ：李倩