智能駕駛真能替代“老司機”嗎？
        研究數據表明，近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的危險不是由故障引起的，而是由于來自外部的觸發條件會觸發系統的局限性或弱點（都不是故障）。SOTIFHARA可以與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+成功案例，積累了豐富的經驗。

        本次介紹到這里就結束啦，更多精彩內容詳見11月24&25日“ 2020經緯恒潤&ANSYS數字化安全技術大會”！國內外專家講師齊聚直播間，為您帶來技術剖析+前沿探討+案例分享，本次會議免費，點擊“閱讀原文”，歡迎報名參會！