【智慧駕駛安全專題】功能安全與SOTIF如何融合實施？

智慧駕駛真能替代“老司機”嗎？
研究資料表明，近94%的致命車禍與駕駛員直接相關，例如疲勞、超速或其他違法行為，智慧駕駛被視為可以顯著降低事故率。

隨著系統複雜性的不斷提升，新技術將會引入新的安全風險，Uber自動駕駛汽車2018年3月在美國意外撞擊致死一名行人，2016-2020四年間特斯拉三次因攝像頭識別侷限性撞向白色卡車，2020年3月沃爾沃向全球市場發出大規模召回通告，數量達70萬輛，涉及9款在售車型，召回的原因是此前沃爾沃在丹麥進行的一項關於XC60的安全測試中，發現自動緊急制動系統（Autonomous Emergency Braking, AEB）沒有按預期在發生碰撞時及時剎停車輛。無論是關於消費者購買自動駕駛車輛的決定因素調查，還是各國發布的自動駕駛車輛標準，“安全”始終是最受關注的焦點。

智慧駕駛帶來的安全問題越來越多，不管是交通事故還是召回事件，究其原因也不全是由於E/E系統故障失效而導致的；在自動駕駛系統中即使系統不發生故障，也可能因為複雜智慧演算法的不確定性導致功能的偏離、感測器或系統效能限制、駕駛員對車輛功能的誤用，造成交通傷害。智慧駕駛事故頻發，公眾的信心下降，對於智慧駕駛的未來我們不禁會有這樣的疑問：我還有機會嗎？

智慧駕駛的“安全帶”—SOTIF我們知道ISO26262 功能安全旨在避免由E/E系統功能失效導致的不可接受的風險，主要是針對系統性失效/隨機硬體失效導致的風險的進行分析和控制，然而感測器和感知演算法(e.g. machine learning, neural networks)，在沒有出現電子電器系統失效時，由於設計的侷限性也會導致風險，但此部分並不屬於ISO 26262的範疇。為了彌補ISO 26262的侷限，預期功能安全（Safety of the intended functionality，SOTIF）應運而生。

2019年1月，ISO/PAS 21448:2019 Road vehicles — Safety of the intended functionality釋出，同年5月ISO 21448工作組草案（WD）中已將該國際標準的範圍擴充至L1-L5自動駕駛車輛系統。

SOTIF定義為不存在不可接受的由功能設計不足或者可預見的駕駛員誤操作風險，主要為了消除以下兩類風險：
? Performance limitation 例如：惡劣環境條件下，感測器無法探測到物體
? Misuse 例如：人機介面設計差，導致駕駛員誤用自動駕駛功能
智慧網聯車輛對於不同的危害事件原因，會有相應標準覆蓋。

SOTIF從已知性和安全性兩個維度將場景分為4類：

SOTIF的目的就是評估Area 2和Area 3，通過一系列技術措施將兩區域減小，並同時提供證據證明這兩個域已經足夠小，剩餘的殘餘危害是可接受的。在此過程中Area 1通常是增加的。

ISO 26262與ISO 21448 核心環節對比
儘管ISO 26262和ISO 21448處理的是安全的不同方面，但這兩個過程都需要用於實現預期功能的可靠安全性論證。兩個標準之間活動的一致性有助於在系統設計的早期發現問題並進行修改，同時各活動之間是互動進行的，產品開發階段通常需要多次迭代，以生成最終的功能和系統規範。

? Part5 系統規範和設計與 Item Definition 並行
? Part6 危害識別和風險評估與 HARA 並行
? Part7 觸發條件識別和評估與 FSC/TSC 並行
? 驗證和確認與 ISO 26262的 V模型右半邊並行
? SOTIF的釋出與功能安全評估並行

功能安全與SOTIF融合實施
ISO 21448中定義了SOTIF的工作流，下面融合ISO 26262開發過程，針對Part5-Part8詳細描述個階段工作內容。

? Part5 功能規範與系統設計方案功能規範 Functional description整車層面的描述，包括預期功能和子功能目的、需要達到的效能指標、預期功能的啟動，退出條件（執行設計域operational design domain, ODD描述）、車輛自動化的Level等級等。

方案設計 system design and architecture方案設計中搭建系統架構，明確各子系統間的依賴互動關係，定義系統功能和相關故障。

? Part 6 識別和評估危害事件
與ISO26262不同，SOTIF的危險不是由故障引起的，而是由於來自外部的觸發條件會觸發系統的侷限性或弱點（都不是故障）。SOTIF最初的HARA可以與ISO 26262中的相同，但是會不斷演變最終會包含更多的故障，新的系統性危害以及更多情況（包括觸發條件）。

? Part 7 觸發條件的識別和評估
通過參考相同的專案或者相同領域的經驗，系統性的分析觸發條件。識別系統的缺陷或者場景主要分析內容：

已知的系統元件約束環境條件和可預見的誤操作通過這些分析可以提高對系統侷限性的理解，同時將會改善未知觸發條件的識別。基於整車級別危害可通過故障樹同時分析功能安全原因和預期功能安全原因，預期功能的故障行為下包含觸發條件和相應的弱點和限制。

針對不同模組（例如感測器）建立侷限性庫進行限制和弱點分析，將感測器/功能特徵與潛在場景的特徵/特性聯絡起來，確定的觸發條件可以儲存為情景庫，以供在新專案中進一步使用。另外附加一個SysML模型，用於描述它們隨時間的變化（活動圖）

? Part8 功能改進(Architecture)
首先從安全目標得出功能要求,然後從已識別的故障得出較低階別的功能要求。隨後在單獨的安全概念(TSC /SOTIF概念)中細化為技術要求(TSR)和效能要求(SOTIF)。新增額外SOTIF安全機制對架構進行改進，例如：提高感測器效能/精度、感測器演算法改進、選用合適的感測器技術、改變感測器位置、感測器干擾檢測，並觸發報警和降級策略、執行設計域（ODD）退出的檢測等。

? Part9-Part11為SOTIF驗證階段，需要定義驗證和確認策略，以提供實現目標的證據，並說明如何實現目標。隨著功能的改進，對系統進行分析，以確定在驗證和確認期間是否重新測試了其他功能。這些相關功能通過迴歸測試得到驗證。這確保了已知的或新的觸發事件不會在未更改的功能中導致潛在的危險行為。在驗證和確認活動中發現的觸發事件(其中存在潛在的危險行為)在每次釋出時都要重新測試。對於Area 2可以通過很明確的方法進行驗證，可參考ISO21448 Clause 10中給出了的系統和元件（感測器、演算法和執行器）和整合的推薦驗證方法。對於Area 3這類情景只能靠企業的實踐或其他方法（如設計度量、系統分析或專用實驗）進行評估。

智慧駕駛功能安全綜合方案
結合自身汽車電子產品研發實踐，經緯恆潤的功能安全團隊在智駕域提供覆蓋安全流程、產品開發認證及工具平臺的綜合解決方案。

智駕功能安全流程搭建

智駕功能安全產品開發及認證

通過功能安全模板、開發例項及定製的Workshop給客戶提供專業的諮詢服務。

智駕功能安全平臺
結合客戶工程需求，經緯恆潤會協助構建適配智慧駕駛的高可靠、高自動化功能安全平臺，以基於模型的安全分析為重要手段驅動智慧駕駛產品架構及設計不斷持續改進。

Medini為經緯恆潤長期合作的專業功能安全平臺，可以完整覆蓋ISO-26262、ISO-21448（SOTIF）行業核心過程，針對自動駕駛SOTIF領域的解決方案，可以完全覆蓋SOTIF安全分析過程（Part5-Part8），同時參與ISO 21448標準制定，隨時更新保持與標準同步。

依託Medini平臺及豐富的API介面可以構建完整的基於模型開發的功能安全平臺，所有的系統功能和系統架構基於SysML模型描述，基於這些系統設計，可以直接一鍵生成FMEA表格，以及快速的構建故障樹，進行FTA。
在整合化的平臺裡，可以管理安全目標、安全需求，並把安全需求分配給對應的系統和元件。進而，安全需求、系統設計、安全分析三者可以統一平臺中進行連線、互動和管理。

經緯恆潤從2008年開始研究及實施功能安全，並於同年組建了功能安全團隊，從消化ISO-26262標準到參與2017年GB/T 34590功能安全標準的制定；結合自身汽車電子產品研發實踐，經緯恆潤的功能安全團隊在智駕域、底盤域、動力域、車身域實施國內外100+成功案例，積累了豐富的經驗。