功能安全的案例
功能安全管理（四）：功能安全審核及功能安全評估
作者 | HYZY
出品 | 焉知
知圈 | 進“芯片社群”請加微信13636581676，備注芯片
功能安全開發流程的終點應該是對相關項的安全認可，以確認其達到了生產發布的安全條件。
一、認可措施的關系
ISO 26262標準中定義的認可措施包括認可評審、功能安全審核和功能安全評估三種類型，ISO 26262標準中允許將認可評審和功能安全審核與功能安全評估合并、聯合，以支持相關項類似變型的處理。
下圖1展示了三種認可措施及驗證評審之間的關系，可以看出：
認可評審/驗證評審與功能安全審核相對獨立，分別是針對工作成果及功能安全開發流程；
功能安全評估的范圍最廣，除涵蓋了認可評審、驗證評審和功能安全審核外，還包括安全措施的適宜性和有效性、功能安全實現的論證、安全檔案提供的論證、安全異常原因已按規定關閉等其它內容。
圖 1 認可措施及驗證評審范圍
二、功能安全審核
1、功能安全審核內涵
功能安全審核可類比ASPICE過程能力審核與TS 16949體系審核，可由公司的體系審核員或第三方機構審核員按照ISO 26262標準中對于過程的要求，審核項目開發中的安全流程實施情況。
功能安全審核可與ASPICE過程能力評估一同進行（特別是對于支持過程的審核），但ASPICE過程能力評估不能代替功能安全審核。
展開 EPB系統功能安全筆記 (19)： 功能安全的認可措施（Confirmation Measures）理解與辨析
，是否真的能夠實現功能安全。
經緯恒潤預期功能安全（SOTIF）解決方案為自動駕駛安全保駕護航
· 產品上：一方面，經緯恒潤基于駕駛數據、場景提取算法、聯合分布統計等數據驅動方法，結合安全分析構建關鍵臨界風險場景并進行解算，在整車開發早期提出量化需求指標和測試驗證準則，以便在車輛后期測試階段有較為明確的輸入，避免因定義模糊造成大量重復且無意義的測試驗證工作。另一方面，基于在高級自動駕駛領取多年深耕的經驗，經緯恒潤總結關鍵技術，通過預期功能安全模板、開發實例及定制Workshop給客戶提供專業的咨詢服務。可以更好地助力企業高級別自動駕駛功能“安全”落地。
自動駕駛安全組件是經緯恒潤獨立研發的一種解決方案，通過使用經緯恒潤的自動駕駛安全組件，企業可以節省大量的時間和精力，因為組件已經經過獨立研發和測試，具備符合功能安全和預期功能安全的能力。企業無需從零開始開發安全組件，而是可以直接使用經過驗證的解決方案，從而加快自動駕駛功能的開發進程。此外，自動駕駛安全組件還具備適配結構化和非結構化場景的能力。這意味著無論是在道路上的結構化環境還是復雜的非結構化環境中，組件都能夠提供可靠的安全性支持，確保自動駕駛系統在各種場景下的穩定運行。
經緯恒潤功能安全團隊成立于2008年，系國內較早從事功能安全技術研究的團隊。作為功能安全、預期功能安全國家標準委員會成員，參與GB/T 34590第一版、第二版起草及修訂工作。經緯恒潤在汽車電子產品研發實踐中全面導入功能安全方法論，目前研發流程、生產流程已通過ISO26262的功能安全開發過程認證，功能安全開發過程已達到ASIL-D級別。智能駕駛產品開發內部按照SOTIF流程開發，并通過了ISO21448的預期功能安全開發過程評估。
展開 智能駕駛安全專題 | 功能安全與SOTIF如何融合實施
智駕功能安全平臺
結合客戶工程需求，經緯恒潤會協助構建適配智能駕駛的可靠、自動化功能安全平臺，以基于模型的安全分析為重要手段驅動智能駕駛產品架構及設計不斷持續改進。
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+成功案例，積累了豐富的經驗。迎合市場所需，結合量產產品功能安全落地實施的技術難點，經緯恒潤功能安全團隊以智能駕駛功能安全為主題，陸續發布解決方案系列文章。
經緯恒潤
北京市海淀區知春路7號致真大廈D座6層
郵箱：market_dept@hirain.com
網址：www.hirain.com
展開 
功能更新 | medini analyze — 符合ISO 26262的功能安全平臺工具
? Mobileye——自動駕駛安全策略的分析
Mobileye將medini analyze作為其自動駕駛安全策略開發的核心工具，將自動駕駛安全目標拆分為功能安全ISO26262安全目標及預期功能安全SOTIF安全目標，系統性解耦了功能安全與預期功能安全之間的關聯關系，不但實現了產品的功能安全開發，并且利用medini analyze積極探索了SOTIF的落地過程。
medini analyze在深耕ISO 26262功能安全的同時，也在持續開發SOTIF、cybersecurity等功能，不久將會推出支持SOTIF和cybersecurity的全新版本，敬請期待！
經緯恒潤
北京市海淀區知春路7號致真大廈D座6層
電話：010-64840808
郵箱：market_dept@hirain.com
網址：www.hirain.com
展開 功能安全--安全分析
來源 | 汽車ECU開發
在ISO26262功能安全中，有多個地方需要進行安全分析，安全分析的質量很重要的決定了功能安全項目的成敗，本文針對ISO26262中提到的各種安全分析進行匯總說明（HARA、FMEA、FTA、FMEDA、SWFMEA、DFA）。
01 HARA
在概念階段，功能安全要求進行HARA分析。
HARA（危害分析與風險評估）目的是識別項目的功能故障引起的危害，對危害事件進行分類，然后定義與之對應的安全目標，以避免不可接受的風險。
HARA分析步驟：
SEC說明：
ASIL等級說明：
QM指的是 質量管理，表示此項功能不影響安全，通過質量管理保證即可。
舉例說明：
HARA分析示例
危害事件 場景分析 S E C ASIL
EPS按照非預期的方向轉向 在城市道路，車輛正常勻速行駛（E4），車輛方向按照非預期轉向，此時駕駛員很難控制(C3)，道路兩邊人員較多，可能造成路人或者駕駛員的傷亡(S3) 3 4 3 D
02 FMEA
在系統階段，功能安全要求針對各種失效模式進行分析。
FMEA是一種自下而上的歸納分析方法，用于識別系統失效(failure)，找出失效原因(Fault)，以及分析失效影響(Effect)。
展開 汽車功能安全工程師入行指南
同時，對于主機廠或供應商各自內部的功能安全開發來說，正如前面提到，功能安全經理通常也就是系統功能安全工程師，他將作為系統層的接口協調系統與軟硬件團隊的功能安全工作，保證系統層和軟/硬件層功能安全需求的互相傳遞和執行。
功能安全開發過程交流示意圖
5
系統/軟件/硬件功能安全工程師的日常工作
不管對主機廠還是供應商，在一個客戶項目中，很少遇到要從零開始開發一個全新的產品，一般都是基于現有的產品作為base進行開發，以滿足新的項目需求，功能安全也是如此。圍繞項目需求與平臺Base不同的部分進行功能安全開發，識別不同點的活動稱作FSIA（functional safety impact analysis）。
我們前面提到，一個完善的功能安全開發團隊通常定義三個角色：
系統功能安全工程師
軟件功能安全工程師
硬件功能安全工程師
每個角色負責下圖中的一個V模型開發活動。
功能安全開發中的三個V模型 （截圖來自GB/T 34590）
當功能安全是基于base來開發時，不管是對主機廠或供應商來說，這三個角色并不需要定義三個獨立的工程師來做，這未免太奢侈，實際上也沒必要。通常軟/硬件功能安全工程師由軟/硬件工程師兼任。
對軟件功能安全開發而言，在軟件開發流程完善和開發工具滿足要求的前提下，在軟件設計和驗證過程中，功能安全需求和功能需求無需過分區別對待，有很多公司的軟件開發流程本身就能保證符合ISO 26262中ASIL D的要求。
展開 詳解功能安全概念階段
派生的過程中，功能安全需求獨立于系統的技術架構，還要給功能安全需求分配唯一的ID，當前狀態及對應ASIL等級屬性。下面是一個表格形式的功能安全需求的例子：
1.7 功能安全概念（Functional Safety Concept）
功能安全概念（Functional Safety Concept）是Part 3的最后一個活動。雖然在產品開發尚未進入系統設計階段（Part 4），但此時需要假設一個系統架構（System Architectural Design），因為功能安全概念需要在整車的架構上實現。功能安全概念階段需要描述必要的功能安全需求，并分配這些安全需求到系統的功能要素（Element）上。在ISO 26262中，功能安全概念階段要求達成以下目標：
指定與相關項安全目標相符功能行為（Functional Behavior）或者降級的功能行為（Degraded Functional Behavior）。系統功能的降級是指如果由于故障不能正確的運行，需要系統工作在一個功能或性能受限的狀態。一般系統降級要設計降級的策略，如近光燈系統，降級策略要求至少有一個燈可以工作。
根據安全目標，指定針對合適的手段及時檢測和控制相關的故障的限制條件
在相關項的層面上，設計策略或者措施用來達成要求的容錯能力，或者基于相關項本身、駕駛員或者外部措施以減輕相關故障造成的影響
分配功能安全需求到系統架構或者外部措施上
驗證功能安全概念并指定功能安全確認標準，這里的驗證是指對設計過程的驗證（Verification），主要是檢查設計過程的正確性。
2 功能安全概念階段相關技術
為保障功能安全概念階段的活動能夠正確實施，對應每個活動都有一系列的實施方法。本節對涉及到的一些重要技術手段進行介紹。
展開 詳解功能安全概念階段
派生的過程中，功能安全需求獨立于系統的技術架構，還要給功能安全需求分配唯一的ID，當前狀態及對應ASIL等級屬性。下面是一個表格形式的功能安全需求的例子：
1.7 功能安全概念（Functional Safety Concept）
功能安全概念（Functional Safety Concept）是Part 3的最后一個活動。雖然在產品開發尚未進入系統設計階段（Part 4），但此時需要假設一個系統架構（System Architectural Design），因為功能安全概念需要在整車的架構上實現。功能安全概念階段需要描述必要的功能安全需求，并分配這些安全需求到系統的功能要素（Element）上。在ISO 26262中，功能安全概念階段要求達成以下目標：
指定與相關項安全目標相符功能行為（Functional Behavior）或者降級的功能行為（Degraded Functional Behavior）。系統功能的降級是指如果由于故障不能正確的運行，需要系統工作在一個功能或性能受限的狀態。一般系統降級要設計降級的策略，如近光燈系統，降級策略要求至少有一個燈可以工作。
根據安全目標，指定針對合適的手段及時檢測和控制相關的故障的限制條件
在相關項的層面上，設計策略或者措施用來達成要求的容錯能力，或者基于相關項本身、駕駛員或者外部措施以減輕相關故障造成的影響
分配功能安全需求到系統架構或者外部措施上
驗證功能安全概念并指定功能安全確認標準，這里的驗證是指對設計過程的驗證（Verification），主要是檢查設計過程的正確性。
2 功能安全概念階段相關技術
為保障功能安全概念階段的活動能夠正確實施，對應每個活動都有一系列的實施方法。
展開 智能駕駛車輛功能安全測試解決方案
伴隨著電子電氣系統（E/E系統）復雜程度和控制權的增加，E/E 系統失效引發的安全風險日趨成為行業整車廠和供應商重視的問題。
經緯恒潤功能安全團隊致力于為國內外整車廠和零部件供應商提供優質的功能安全咨詢服務，涵蓋功能安全流程建設服務、功能安全開發咨詢服務、功能安全測試咨詢服務和工具平臺的綜合解決方案。其中，功能安全測試咨詢服務旨在滿足客戶在測試環境搭建、測試開發和測試實施等環節的全方位需求，及早發現產品潛在安全缺陷，提升整車開發效率和保障安全品質。
功能安全測試咨詢服務
經緯恒潤功能安全團隊可提供軟件開發階段、系統開發階段和整車開發階段的功能安全測試服務。
展開 如何理解預期功能安全
當前汽車行業熱度非常高的三個標準為預期功能安全ISO21448，功能安全ISO26262和網絡安全ISO21434，其中預期功能安全對于系統開發者來說比較陌生，容易將它與功能安全混為一談，預期功能安全要解決的問題是什么，為什么要在功能安全之外還要考慮預期功能安全，網上已經有很多的資料去講，本篇談談對預期功能安全概念的理解。
背景
Road vehicles - safety of the intended functionality SOTIF（道路車輛 預期功能安全）標準在2019年1月作為公開技術規范發布（ISO/PAS 21448），正式版預計將于2022年發布，目前PAS版本共有29頁+23頁附件，重點關注SAE自動化level 1和level 2駕駛輔助功能。
這個規范用于降低由于系統的預期功能不足（設計不足或性能局限）或可預見的人員誤操作導致的不可接受風險，這也是預期功能安全概念的定義，適用的電子系統為安全功能受外部環境影響的功能，來自于傳感器和處理算法，典型的有AEB自動緊急制動系統、車道保持系統等高級駕駛輔助系統。
預期功能安全概念
功能安全在于解決系統內的隨機失效和系統性失效引起的危害，造成安全事故，包括硬件故障、軟件故障，而系統功能正常時出現的危害不在功能安全考慮的范圍內，由于使用傳感器或算法的性能限制，駕駛人員對系統的誤操作，SOTIF規范的推出旨在解決這一類問題。下圖來自中國汽車標準化技術委員會在2020年發布的《預期功能安全國際標準ISO21448及中國實踐白皮書》，用于說明功能安全與預期功能安全概念的區別。
展開 
EPB功能安全筆記(20) 尾聲：ISO26262的總結和展望
沿著這個思路理解功能按照開發中的概念，可以得到如下解釋：
Safety verification：驗證功能安全需求有沒有被實現？
Safety validation: 確認功能安全需求提的對不對？即功能安全需求實現了是否確實能保證安全？
根據這樣的解釋可以發現功能安全驗證（safety verification）和功能安全確認（safety validation）屬于兩個維度。
關于系統/硬件/軟件三個層級的功能安全需求如何進行安全驗證（safety verification）分別記錄在標準中的第4/5/6部分。而安全確認的目的概括為：
提供符合安全目標的證據及功能安全概念適合相關項的功能安全的證據。
提供安全目標在整車層面上是正確的、完整的并得到完全實現的證據。
由此可以看出安全確認中的“確認”在于確認安全目標及安全目標對應的安全標準(safety criteria)是否被滿足。
在《EPB功能安全筆記(18)——功能安全驗證和確認》中對功能安全驗證和確認的關鍵點進行了詳細說明。
1.6.功能安全評估
當一切功能安全開發活動完成后，在正式量產之前，需要對開發產物進行審核，審核通過后方能釋放產品。“ISO 26262，part2，功能安全管理”中詳細介紹了功能安全的審核流程和要求，對應的術語為“認可措施，Confirmation measures”。
展開 自動駕駛預期功能安全要素及準入難點解讀
當前，自動駕駛功能的研發及量產已經進入白熱化階段，各家主機廠在該領域的投入也傾注了大量的精力和能力，對于上市也是勢在必得。但是對于法律和標準規定來說，自動駕駛上市必須拿到工信部代表交通部頒發相關的準入牌照才能受到相關社會的認可。
然而，自動駕駛準入需要充分考慮汽車研發的各個方面，最重要的是保證駕駛過程中具備足夠的安全性，這就要求在設計之初就需要充分考慮到其中的關鍵一環：功能安全及預期功能安全。由功能安全涉及的失效和故障（一般指系統級功能和功能故障的E / E故障）將導致錯誤的轉向或制動，這被認為是自動駕駛與安全性相關的最高風險（一般能達到ASIL D）。通過根據ISO PAS 21448 SOTIF方法開發的功能來定義安全功能和系統，包括第一個初步的體系結構，是朝著按照ISO 26262應用功能安全性邁出的第一步-創建項目定義。該項目定義應包括功能的定義，包括其對環境和其他項目/車輛的依賴性以及與環境和其他項目/車輛的相互作用。根據項目定義，可以進行危害分析和風險評估，以找到該功能及其相關系統的根本要求或安全目標。下一步是開發功能和技術安全概念。
自動駕駛預期功能安全分析能力
自動駕駛系統必須具有一組基本的系統屬性，此處將其指定為功能。下面將討論為了聲明整個系統是安全的應具有的功能。這些功能分為故障安全功能（FS）和故障降級功能（FD）。故障安全功能可提供并實現客戶價值。故障安全功能可以被終止，因為其不可用性的安全相關性足夠低，或被故障降級功能所覆蓋。即使在發生故障的情況下，也應該以一定的性能水平執行故障降級的功能，以在特定時間范圍內提供安全的系統，直到達到最終的最小風險條件（MRC）并允許停用為止。下表中的選擇矩陣展示了導出能力的完整性狀態，以證明對其設計原理的可追溯性。
展開 基于AP AUTOSAR實現功能安全島
其中，作者觀察到AP的一個重要使用場景為實現功能安全島。
背景
在傳統的硬件架構下，一般是一個MPU搭配一個從芯片MCU。MPU上運行需要高算力的應用，而且MCU側于車內總線(比如CAN)。功能安全的應用部署在MCU側，軟件棧比如選用CP AUTOSAR。
傳統MPU加從芯片MCU的硬件架構
在這個架構下，受MCU算力限制，CP側無法對高算力的MPU做細顆粒的監控。
目前很多量產項目用到AP AUTOSAR的主要原因是在MPU上實現功能安全島。最近有好幾個ADAS項目采用如下軟件架構：
這樣的架構主要使用在高性能ADAS控制器上。在Linux VM側，部署各種開源機器學習框架和ADAS算法。算法工程師能夠從廣大Linux軟件生態中獲益。常見的機器學習框架，算法庫等等都在Linux上有移植。
受限于Linux實現功能安全能力，所有的項目都把跟功能安全相關部分放在AUTOSAR側。AP AUTOSAR側一般實現safety應用：
系統失效后的緊急運行功能或降級功能
備份功能滿足Fail-operational的安全策略。
實現不同算法監控比對Linux VM側結果實現算法級冗余。
當然，也有RTOS廠商移植了部分框架。比如opencv等。在這種情況下，可以省去Hypervisor和Linux部分，大大降低開發集成難度。
展開 智能網聯汽車功能安全開發解決方案
概述
“安全”被普遍認為是智能駕駛汽車被用戶接受或者得到商業應用較大的問題，傳統汽車電子按照功能安全（ISO 26262，避免系統性故障及隨機硬件失效）標準進行安全設計，而智能駕駛汽車安全要求超越了功能安全范疇，尤其是L4及以上智能駕駛車輛中駕駛員將不再接管對車輛的控制權，功能安全要求演化為失效可工作（Fail-operational），產品設計需要兼顧預期功能安全（ISO/PAS 21448，解決產品性能受限及駕乘人員誤操作）、信息安全（ISO/SAE 21434，防御網絡攻擊）等多重安全需求。
經緯恒潤結合自身汽車電子產品研發實踐，功能安全咨詢團隊在智駕域提供覆蓋安全流程、產品開發認證及工具平臺的綜合解決方案。
智能駕駛功能安全流程搭建
智能駕駛安全產品開發及認證
通過功能安全模板、開發實例及定制的Workshop給客戶提供專業的咨詢服務。
智能駕駛功能安全開發平臺
結合客戶工程需求，恒潤會協助構建適配智能駕駛的高可靠、高自動化功能安全平臺，以基于模型的安全分析為重要手段驅動智能駕駛產品架構及設計不斷持續改進。
依托Medini平臺及豐富的API接口可以構建完整的基于模型開發的功能安全平臺，所有的系統功能和系統架構基于SysML模型描述，基于這些系統設計，可以直接一鍵生成FMEA表格，以及快速的構建故障樹，進行FTA。在集成化的平臺里，可以管理安全目標、安全需求，并把安全需求分配給對應的系統和組件。進而，安全需求、系統設計、安全分析三者可以統一平臺中進行連接、交互和管理。
展開 