來源 | SASETECH

前言

2016年，美國佛州的一輛特斯拉Model S在Autolipot狀態下與正在轉彎的白色半掛卡車發生碰撞，鉆進了卡車貨柜下方，特斯拉駕駛員不幸身亡。

圖1：特斯拉事故

直到近幾年陸續發生的事故，都指向特斯拉由于視覺感知的缺陷，無法有效識別靜止的白色車輛。對靜態車輛的檢測，屬于當下以“攝像頭+毫米波雷達”作為主傳感器的L2級自動駕駛方案的一個世界性難題。

傳統的功能安全已經無法覆蓋此類"失效"。2018年以來預期功能安全(sotif,iso21448)持續發展，解決的正是系統性能局限以及駕駛員誤用引發的整車層面危害。

SOTIF

工作流

SOTIF主要工作內容是Clause6-Clause12，6-7進行SOTIF HARA分析，識別system limitation和triggering event，與ISO26262中Part3處于同一階段。

功能安全Part3包括相關項定義、危害分析和風險評估等活動，輸出功能安全概念。功能安全概念描述了分配給實施安全措施的架構元素。SOTIF包括功能更改，是為避免、減少或緩解導致 SOTIF風險的 system limitation而制定的措施。

ISO26262第4部分是系統級產品開發，將功能安全概念分解為技術安全概念，同時還定義確認測試策略。SOTIF V&V與Part4可在同一階段開發，包括V&V策略制定與實施。

圖2:SOTIF開發流程（融合功能安全）

可以看出SOTIF內容覆蓋面同樣很廣，本文主要就validation target如何制定，給出對于標準的解讀和自己的思考。

Validation Target

初步探索

Validation是解決L2+以上智駕的重要一環，是證明智駕產品安全可靠的關鍵指標，同時也各家主機廠比較頭疼的問題，究竟validation target 該如何定義，比如：

• 如何證明經過validation之后風險降低到可接受水平？
• 需要驗證多少里程，多長時間？
• 選擇哪些場景路試？
• 仿真和實車的時長如何分配

本文將對前兩個topic進行初步探索：

先聊聊路試時長的定義，標準里給出這樣一個公式：

STEP1

識別事故導致傷害H的原因，比如非期望制動導致后碰的風險。這里比較關鍵，涉及到step2事故接受指標的定義，因為橫向控制導致出車道的風險與縱向控制導致的追尾或后碰指標是不一樣的。

STEP2

識別step1中發生事故的可接受準則AH，需要查詢事故數據庫，比如德國GIDAS數據庫，經歷較多年的發展已經較為完善，國內CIDAS數據庫統計正在建立過程中，目前數據還不全。典型的指標如（有些是里程指標/km，有些是時間指標/h，可以結合車速進行換算）：

圖3：AH示例

STEP3

識別危害行為可能發生的潛在危險場景（比如高速行駛后方有近距離車輛跟隨），假設危害行為發生在該場景下的條件概率為PE|HB。這里引入了ISO26262里的exposure概念，同樣frequency&duration的理論也適用，在最新一版的ISO21448中增加了此參數，之前標準中未考慮exposure。為什么在定義validation target要引入此概念，而在SOTIF HARA分析時只考慮了S，C，各位可以深入思考下。 

STEP4

識別危害行為在危險場景不可控的概率PC|E，假設暴露在該場景下。

STEP5

從危害事件中識別嚴重度的分布，假設駕駛員不可控，這個分布描述發生事故中各嚴重程度的概率PS|C。比如X%交通參與者發生嚴重的傷害，或至少X%交通參與者發生輕微傷害。按標準的意思，筆者認為這里也存在條件概率，即C3的情況下對應各s等級的分布。

在ISO26262中S與C耦合較深，E相對獨立，而在SOTIF中是否同樣適用？標準中沒有給出答案，個人理解SOTIF中E S C三者是深度融合的， 而不僅僅是S與C關聯，此處后續可以展開聊聊。

咱們繼續往下，假設一個危險行為不總是導致傷害發生，可接受準則可以分解為：

危害行為Rhb是可以被容忍的比率，作為一段時間內危害行為發生的概率。危害行為直接由trigger event結合功能缺陷導致，因此可以被當作validation target。

在風險識別和評估中，假設傷害H識別后，對應的可接受準則為AH=10^-8/h,從實際數據中得知危害行為導致不可控的百分比為PC|E=10%。達到可接受標準的嚴重度對應的為PS|C=10%。駕駛員在該場景下（危害行為導致傷害）暴露概率預估為PE|HB=5% driving time。因此可以計算target value如下：

因為滿足泊松分布，如果5000h測試周期內沒有發生危害行為即有63%置信度認為風險可控。不同的功能以及危害行為需要取不同的置信度。

這里標準只給出簡單的示例，仍然有很多問題值得探索：

1.SOTIF中S E C是如何關聯？條件概率如何計算? 標準未給出答案。

2.S如何評估，根據碰撞前后的速度？ΔV>50KPH一定會達到S3等級么？

3.為什么定義validation target時可以引入暴露度的概念，和之前的標準是否沖突？

4.為什么滿足泊松分布，以及如何結合不同的危害行為定義不同泊松分布置信度？

5.測試時長確定后，如何合理分配仿真測試時長，實車道路測試時長？

6.如何結合功能選擇哪些場景validation？

……

筆者也是初識SOTIF，可能有些觀點有失偏頗。這里只是拋磚引玉，可能以上的問題各位心中已有答案。

SOFIT

分解

最后介紹下如果計算出來validation target時間很長，是否可以通過類似ASIL分解的方法對路試時長進行裁剪。舉個例子，假設我們通過上述公式整個系統的Rhb=10^-9,同時系統內有兩條獨立的路徑實現同一個功能（如前視攝像頭，環視攝像頭均可檢測車道線），我們是否可以對兩條路徑單獨驗證，這樣每條路徑的驗證時長可以縮短（可能縮短至10^-3 OR 10^ 4），因為任一通道的潛在功能缺陷可以被視為“多點功能缺陷”。如下圖所示，假設channel fusion模塊沒有功能缺陷,且能夠比較來自兩個通道的信息,若發現不一致，則輸出不一致信息。

圖4：Two channel system architecture

如果上述“SOTIF分解”可行，則如何進行指標分解？

這是個挺有意思的話題,比如“多點功能缺陷”是否可以類比ISO26262中“多點故障”，進而參考Part10中的多點故障計算公式進行推導？留給各位思考。

還有問題沒有解決,如何保證兩個通道的獨立性呢？標準給出了幾種量化的指導意見↓

1.分析

a.關聯失效分析

b.各通道采用不同傳感器組

c.各通道采用不同傳感器算法

2.專用測試與確認

a.測試表明系統能夠應對假設的共因或關聯失效

b.系統性設計確認測試,充分測試已知或假設的傳感器、組件和通道缺陷

3.專用措施

a.措施可以覆蓋由理論分析(如DFA)出的共因失效或觀測到的關聯失效

b.使用類似傳感器或功能對其他系統中觀察到的功能不足進行分析

c.對開發過程中觀察到的單通道功能不足進行分析或通過現場監測,提供證據證明其他通道不受此問題影響。

圖5：System behaviour modelling

總結

本文先簡要分析特斯拉事故原因—即視覺缺陷,引入SOTIF流程介紹,重點描述了SOTF工作流與FUSA相似點,之后就SOTIF validation target如何導入給出公式詳解。最后對如何減少路試時長進行了初步的探索(“SOTIF分解”)。同時留下了很多問題,一些觀點帶有主觀的想法,僅作為各位理解標準過程中的參考。

智駕安全道阻且長，未完待續……