功能安全開發的案例
經緯恒潤SOA功能安全開發方案, 助力車企軟件定義汽車
作為功能安全國家標準委員會成員，參與了GB/T34590第一版、第二版起草工作及修訂工作；作為芯片創新聯盟核心成員，參與了車規級自主芯片功能安全標準制定。結合20余年汽車電子產品研發實踐，功能安全咨詢團隊提供面向量產車型開發從概念設計到正式投產的全棧功能安全咨詢服務。
目前，經緯恒潤已經為戴姆勒、現代、菲亞特克萊斯勒、一汽紅旗、一汽解放、東風、長安、上汽、吉利、長城、蔚來汽車、華人運通、合眾汽車、嵐圖汽車、博格華納、華域麥格納等國內外主流客戶提供了功能安全開發服務并得到客戶廣泛認可。未來，經緯恒潤將緊跟軟件定義汽車大勢，堅持自主創新，為智能汽車安全發展保駕護航！
展開 EPB系統功能安全筆記 (19)： 功能安全的認可措施（Confirmation Measures）理解與辨析
本文要點
：ISO 26262將功能安全開發融入了廣為熟知的“V模型”開發流程中。根據系統/軟件/硬件三個層級的劃分，ISO 26262的功能安全開發活動被融入了三個“V模型”之中，如下圖所示。在前面的系列文章中已經對這三個“V模型”中包含的功能安全開發要點進行了說明。
“V模型”中的功能安全開發，截圖來自ISO 26262
做工程項目的朋友都知道，對于一款量產產品，除了完成開發工作以外，還需要對開發產物進行審核，審核通過后方能釋放產品。功能安全開發也是如此。“ISO 26262，part2，功能安全管理”中詳細介紹了功能安全的審核流程和要求，對應的術語為“認可措施，Confirmation measures”。
安全管理流程圖，截圖來自ISO 26262-2018, part2
一個現實的情況是，當讀者實際上去讀ISO 26262中“認可措施，Confirmation measures”相關的解釋和要求時，很容易就被其中包含的三個維度的措施給繞暈了，尤其是結合中文國標GB/T 34590對這三個維度的翻譯更加混淆，如下所示：
Confirmation review (認可評審)
Functional safety audit (功能安全審核)
Functional safety assessment (功能安全評估)
基于此，本文將試圖對“認可措施，Confirmation measures”以及其中包含的三個維度的措施進行辨析，旨在為讀者提供有價值的參考。
Note:
1. 考慮到中文翻譯的混淆性，除非有必要，本文接下來將使用英文概念進行描述。
2.
展開 汽車功能安全工程師入行指南
在所有層面（管理/開發/驗證/審核）執行是否有明確的、可追蹤的和受控的流程？
安全文化舉例 （截圖來自GB/T 34590）
從這些方面可以看出，安全文化并不只是空虛的口號，而是實實在在地體現在公司的開發流程中的。優秀的安全文化一定意味著企業有非常完善的開發流程。否則功能安全只是空中樓閣，落地無從談起。于此同時，完善的流程也意味著要增加相應的崗位和工程師們的工作量，甚至是升級開發工具，開發成本也隨之上升。
2.2. 人員配置
針對這一點，不同的企業也有一些出入，但是，功能安全開發比較成熟的企業間至少有一點是能達成一致的，那就是不可能是由一個功能安全開發工程師同時負責系統/軟件/硬件所有的功能安全開發。就算有這種萬里挑一的全才，也得考慮如此龐大的工作量會不會把人才趕跑了。
一個完善的功能安全開發團隊通常定義三個角色：
系統功能安全工程師
軟件功能安全工程師
硬件功能安全工程師
每個角色負責下圖中的一個V模型開發活動。
功能安全開發中的三個V模型 （截圖來自GB/T 34590）
對于后兩個角色，如果是開發一個全新的產品，由于工作量大，人員配置比較充足的企業會獨立于軟/硬件開發工程師之外再指派兩個工程師擔任；如果是基于企業已經量產的產品，根據不同客戶的需求做修改，由于工作量相對減少很多，那么軟/硬件功能安全工程師通常由軟/硬件開發工程師兼任。但是不論是開發全新產品還是基于已有產品修改，系統功能安全工程師一般是專門的崗位。在很多企業系統功能安全工程師也稱為功能安全經理，負責統籌協調整個產品的功能安全開發工作。
展開 功能安全管理（四）：功能安全審核及功能安全評估
作者 | HYZY
出品 | 焉知
知圈 | 進“芯片社群”請加微信13636581676，備注芯片
功能安全開發流程的終點應該是對相關項的安全認可，以確認其達到了生產發布的安全條件。
一、認可措施的關系
ISO 26262標準中定義的認可措施包括認可評審、功能安全審核和功能安全評估三種類型，ISO 26262標準中允許將認可評審和功能安全審核與功能安全評估合并、聯合，以支持相關項類似變型的處理。
下圖1展示了三種認可措施及驗證評審之間的關系，可以看出：
認可評審/驗證評審與功能安全審核相對獨立，分別是針對工作成果及功能安全開發流程；
功能安全評估的范圍最廣，除涵蓋了認可評審、驗證評審和功能安全審核外，還包括安全措施的適宜性和有效性、功能安全實現的論證、安全檔案提供的論證、安全異常原因已按規定關閉等其它內容。
圖 1 認可措施及驗證評審范圍
二、功能安全審核
1、功能安全審核內涵
功能安全審核可類比ASPICE過程能力審核與TS 16949體系審核，可由公司的體系審核員或第三方機構審核員按照ISO 26262標準中對于過程的要求，審核項目開發中的安全流程實施情況。
功能安全審核可與ASPICE過程能力評估一同進行（特別是對于支持過程的審核），但ASPICE過程能力評估不能代替功能安全審核。
展開 
智能網聯汽車功能安全開發解決方案
概述
“安全”被普遍認為是智能駕駛汽車被用戶接受或者得到商業應用較大的問題，傳統汽車電子按照功能安全（ISO 26262，避免系統性故障及隨機硬件失效）標準進行安全設計，而智能駕駛汽車安全要求超越了功能安全范疇，尤其是L4及以上智能駕駛車輛中駕駛員將不再接管對車輛的控制權，功能安全要求演化為失效可工作（Fail-operational），產品設計需要兼顧預期功能安全（ISO/PAS 21448，解決產品性能受限及駕乘人員誤操作）、信息安全（ISO/SAE 21434，防御網絡攻擊）等多重安全需求。
經緯恒潤結合自身汽車電子產品研發實踐，功能安全咨詢團隊在智駕域提供覆蓋安全流程、產品開發認證及工具平臺的綜合解決方案。
智能駕駛功能安全流程搭建
智能駕駛安全產品開發及認證
通過功能安全模板、開發實例及定制的Workshop給客戶提供專業的咨詢服務。
智能駕駛功能安全開發平臺
結合客戶工程需求，恒潤會協助構建適配智能駕駛的高可靠、高自動化功能安全平臺，以基于模型的安全分析為重要手段驅動智能駕駛產品架構及設計不斷持續改進。
依托Medini平臺及豐富的API接口可以構建完整的基于模型開發的功能安全平臺，所有的系統功能和系統架構基于SysML模型描述，基于這些系統設計，可以直接一鍵生成FMEA表格，以及快速的構建故障樹，進行FTA。在集成化的平臺里，可以管理安全目標、安全需求，并把安全需求分配給對應的系統和組件。進而，安全需求、系統設計、安全分析三者可以統一平臺中進行連接、交互和管理。
展開 經緯恒潤預期功能安全（SOTIF）解決方案為自動駕駛安全保駕護航
· 產品上：一方面，經緯恒潤基于駕駛數據、場景提取算法、聯合分布統計等數據驅動方法，結合安全分析構建關鍵臨界風險場景并進行解算，在整車開發早期提出量化需求指標和測試驗證準則，以便在車輛后期測試階段有較為明確的輸入，避免因定義模糊造成大量重復且無意義的測試驗證工作。另一方面，基于在高級自動駕駛領取多年深耕的經驗，經緯恒潤總結關鍵技術，通過預期功能安全模板、開發實例及定制Workshop給客戶提供專業的咨詢服務。可以更好地助力企業高級別自動駕駛功能“安全”落地。
自動駕駛安全組件是經緯恒潤獨立研發的一種解決方案，通過使用經緯恒潤的自動駕駛安全組件，企業可以節省大量的時間和精力，因為組件已經經過獨立研發和測試，具備符合功能安全和預期功能安全的能力。企業無需從零開始開發安全組件，而是可以直接使用經過驗證的解決方案，從而加快自動駕駛功能的開發進程。此外，自動駕駛安全組件還具備適配結構化和非結構化場景的能力。這意味著無論是在道路上的結構化環境還是復雜的非結構化環境中，組件都能夠提供可靠的安全性支持，確保自動駕駛系統在各種場景下的穩定運行。
經緯恒潤功能安全團隊成立于2008年，系國內較早從事功能安全技術研究的團隊。作為功能安全、預期功能安全國家標準委員會成員，參與GB/T 34590第一版、第二版起草及修訂工作。經緯恒潤在汽車電子產品研發實踐中全面導入功能安全方法論，目前研發流程、生產流程已通過ISO26262的功能安全開發過程認證，功能安全開發過程已達到ASIL-D級別。智能駕駛產品開發內部按照SOTIF流程開發，并通過了ISO21448的預期功能安全開發過程評估。
展開 功能更新 | 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
展開 EPB功能安全筆記(20) 尾聲：ISO26262的總結和展望
知圈 | 進“汽車智能交互社群”請加微信13636581676，備注交互
抱著“為ISO 26262及功能安全的初學者提供有價值參考”的初衷，《EPB系統功能安全筆記》系列文章來到了尾聲。
受限于筆者的個人水平，初衷達到幾何尚未可知，但是可以肯定兩點：一是在更新這個系列文章的過程中，筆者在系統梳理對功能安全理解的同時也獲得了不少新的認知；二是雖然在更新過程中盡可能嚴謹，但文章中不可避免地有值得討論甚至是錯誤之處，還請有經驗的讀者諒解并甄別。
作為《EPB系統功能安全筆記》的收官，本文的目標是站在ISO 26262的全局視角對功能安全開發過程中的關鍵點做出串聯和總結；與此同時，在智能駕駛迅猛發展、E/E系統架構快速迭代的今天，本文站在安全的角度指出ISO 26262在這一潮流中的局限并做出展望。
需要提前指出，功能安全開發活動是貫穿整個產品安全生命周期的（管理、開發、生產、運行、服務、報廢），重點包括開發過程(包括需求規范、設計、實現、集成、驗證、確認和配置)、生產過程、服務過程和管理過程的，而
系列文章只聚焦于開發過程
，因為本文的梳理也僅圍繞開發過程展開。
Part 1: ISO 26262總結
1.1.功能安全的目標
ISO 26262中對“Functional Safety, 功能安全”的定義如下。
absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.
展開 BMS功能安全開發流程詳解
在ISO26262-9中定義了ASIL分解，為了降低安全目標實施成本，可以將一個高ASIL安全目標分解成兩個相互獨立的低一級安全目標。拿文中的SG1-預防過放作為一個例子，在這里我們假設負載只有驅動電機，可以通過將SG1分解成兩個獨立的FSR。FSR1.2a:在x ms內斷開高壓回路，FSR1.2a：通過CAN報文請求負載將需求功率降低為0。
三、技術安全要求導出
在第三部分中介紹了功能安全概念的目的是從安全目標（SR）中得出功能安全要求（FSR），并將其分配給相關項的初步架構要素或外部措施。
技術安全要求導出
圖1說明了通過分層的方法，從危害分析和風險評估得出安全目標，再由安全目標得出功能安全要求。
下圖給出了ISO26262相應部分中的安全要求的結構和分布的說明。將功能安全要求分配給初步架構要素。
技術安全要求（TSR）是對功能安全要求（FSR）提煉，細化了功能安全的概念，同時考慮功能性的概念和初步的體系架構。通過分析技術安全需要來驗證符合功能安全需求。在整個開發生命周期，技術安全需求是要落實功能安全概念的技術要求，其用意是從細節的單級功能安全要求到系統級的安全技術要求。
技術安全要求應根據功能安全概念、相關項的初步架構設想和如下系統特性來定義：
a.外部接口，如通訊和用戶接口，如果適用；
b.限制條件，例如環境條件或者功能限制；以及
c.系統配置要求。
展開 EPB功能安全筆記(16):ASIL分解及其關鍵點
本文要點：在上一期（EPB功能安全筆記(15)：什么是DFA(Dependent Failure Analysis)）中介紹了相關失效分析(DFA, Dependent Failure Analysis)的目的和實踐。相關失效分析的目的可以簡單概括為：證明系統既不存在級聯失效，也不存在共因失效。進一步地，ISO 26262指出，當級聯失效和共因失效都不存在時，可以認為實現了獨立性(independence)。
共因失效(左)；級聯失效(右)
提到獨立性，讀者比較熟知的是ASIL分解，ISO 26262中要求ASIL分解的前提是：ASIL分解需要安全要求具有冗余性，且分配給充分獨立的架構要素。
本文將對ASIL分解展開說明，在介紹分解原則的同時指出其中的關鍵點，拋磚引玉，希望能給讀者帶來一些參考。
1.什么是ASIL分解？
下面的案例在功能安全開發過程中非常常見：
對信號的功能安全需求的ASIL等級為ASIL D或者ASIL C，而信號只能達到ASIL A或者ASIL B
對于這種偏差，ISO 26262開了個“后門”來合理地避免這類偏差影響功能安全開發，這個“后門”就是ASIL分解。ASIL分解是降低對功能安全需求的ASIL等級的裁剪方法，這一方法的核心點是通過將一條功能安全需求分解成兩條相互獨立的需求并分配到兩個及兩個以上相互獨立的元素（如軟件模塊、硬件模塊、輸入信號等）上。
正是由于這些參與分解的獨立的元素之間構成了互為冗余關系，從整個系統的角度看，只有當這些元素同時發生失效時才會違背安全目標，這樣一來對每個參與分解的相關元素的功能安全要求可以降低。
展開 4月16日在線研討會預熱 | medini analyze — 符合ISO 26262的功能安全平臺
? Mobileye——自動駕駛安全策略的分析
Mobileye將medini analyze作為其自動駕駛安全策略開發的核心工具，將自動駕駛安全目標拆分為功能安全ISO26262安全目標及預期功能安全SOTIF安全目標，系統性解耦了功能安全與預期功能安全之間的關聯關系，不但實現了產品的功能安全開發，并且利用medini analyze積極探索了SOTIF的落地過程。
經緯恒潤
北京市海淀區知春路7號致真大廈D座6層
郵箱：market_dept@hirain.com
網址：www.hirain.com
展開 
Ansys medini 功能安全技術交流會（兩天線上培訓）
隨著汽車智能化和網聯化的發展，安全也成為至關重要的一部分。Ansys medini analyze是一款專業的系統安全開發平臺工具，可用于安全關鍵電氣電子 (E/E) 和軟件控制系統的開發，符合汽車、軌道交通、航空航天及工業設備等領域的安全開發流程，支持一致、高效地執行適用安全標準所要求的安全相關活動。
Ansys medini analyze根據 ISO 26262、ISO21448、ISO21434、IEC 61508 以及 ARP4761 等安全標準進行專門定制，應用范圍廣泛，包括產品早期概念設計階段、產品研發以及半導體級的詳細分析。4月1日，Ansys中國將舉辦一場 “Ansys medini 功能安全技術交流會” 。
本次活動將通過對一個項目進行完整的功能安全分析，詳細介紹如何在medini中實現全生命周期的功能安全分析工作，同時展示medini在預期功能安全分析以及信息安全分析的解決方案。
活動主題：Ansys medini analyze功能安全技術
會議日程：
費用：收費，199/人
主講講師簡介
韓慶洋
Ansys SBU應用工程師，擁有自動駕駛領域功能安全以及預期功能的功能安全開發經驗，曾參與L3級別自動駕駛功能的功能安全開發工作，熟悉ISO26262以及SOTIF標準，目前負責Ansys medini工具的支持與咨詢工作，對于自動駕駛安全分析有著深入見解。
點擊圖片或點擊報名鏈接報名：http://event.31huiyi.com/1835708191/index?c=jishulink
展開 Ansys medini 功能安全技術交流會（兩天線上培訓）
隨著汽車智能化和網聯化的發展，安全也成為至關重要的一部分。Ansys medini analyze是一款專業的系統安全開發平臺工具，可用于安全關鍵電氣電子 (E/E) 和軟件控制系統的開發，符合汽車、軌道交通、航空航天及工業設備等領域的安全開發流程，支持一致、高效地執行適用安全標準所要求的安全相關活動。
Ansys medini analyze根據 ISO 26262、ISO21448、ISO21434、IEC 61508 以及 ARP4761 等安全標準進行專門定制，應用范圍廣泛，包括產品早期概念設計階段、產品研發以及半導體級的詳細分析。4月1日，Ansys中國將舉辦一場 “Ansys medini 功能安全技術交流會” 。
本次活動將通過對一個項目進行完整的功能安全分析，詳細介紹如何在medini中實現全生命周期的功能安全分析工作，同時展示medini在預期功能安全分析以及信息安全分析的解決方案。
活動主題：Ansys medini analyze功能安全技術
會議日程：
費用：收費，199/人
主講講師簡介
韓慶洋
Ansys SBU應用工程師，擁有自動駕駛領域功能安全以及預期功能的功能安全開發經驗，曾參與L3級別自動駕駛功能的功能安全開發工作，熟悉ISO26262以及SOTIF標準，目前負責Ansys medini工具的支持與咨詢工作，對于自動駕駛安全分析有著深入見解。
點擊圖片或點擊報名鏈接報名：http://event.31huiyi.com/1835708191/index?c=jishulink
展開 自動駕駛預期功能安全要素及準入難點解讀
也即對于企業能力的要求，如某企業的預期功能安全管理流程，企業的安全文化，以及在各個環節中的文檔設計工作，以及對整個產品全生命周期的監控。
其二是對產品的要求。即參考國際、國內標準的開發流程，在產品開發環節做必要的SOTIF分析，并通過仿真、實車測試手段對產品的SOTIF能力進行驗證，最終在產品使用中仍繼續對SOTIF能力進行迭代。
基于《準入》對預期功能安全在整個自動駕駛設計中的要求，提升企業的SOTIF能力勢在必行。如下表示了企業的SOTIF開發、驗證和運維流程示意圖。
如下我們將分別就上面的預期功能安全準入需求進行解讀和對策分析：
一（五）企業應滿足預期功能安全開發接口管理要求，符合預期功能安全管理職責和角色定義、供應商計劃管理等規定。
二（四）應定義駕駛自動化系統預期功能安全相關零部件的接口要求，確保零部件符合對應的預期功能安全設計開發、驗證、確認等規定。
為了確保企業滿足預期功能安全開發接口管理要求，可通過如下的管理和定義實現相關功能。
1. 企業可以建立并維持良好的安全文化，鼓勵企業內部各部門就預期功能安全問題展開溝通和研究，特別是系統設計、軟件開發及功能安全分析三大部分是其預期功能安全分析的核心部門；
2. 企業針對自身特點，建立合理的安全異常解決機制；
3. 企業制定安全管理流程，并完善管理機制，主要涉及：
提供質量管理體系的證明材料；
對安全管理人員提出合理的的能力考核辦法，以確保勝任相關工作；
對安全計劃、安全測試案例和安全確認機制等文件中所涉及的內容詳細記錄在案；
4.
展開 詳解功能安全概念階段
功能塊圖展示了子系統之間的關系和接口，同時也指示了系統所必須提供的功能。下圖給出了系統的功能塊圖的例子：
對于功能塊圖中的任一功能，對其進行危害分析時，需要明確該功能的輸入信號，運行環境，配置信息及期望的和錯誤的輸出。把這些信息整合，可以如下圖所示的參數圖（Parameter Diagram）：
通過對這些參數的分析，可以得出導致某個功能出現故障的基本原因。在后續的分析過程中，針對故障原因，設計合理的檢測和消除機制，可以有效的提升系統的安全性。
3 總結
本文從ISO 26262:2018，Part 3中的基本概念出發，介紹了該部分涉及到重要概念及開發過程中需要用到的基本技術。在ISO 26262流程中，概念階段（包括功能安全概念和技術安全概念）是最重要的階段，這個階段出現的任何紕漏，都會影響后續的功能安全開發活動。由于ISO 26262采用的是V模型，概念階段變更引起的工作量會十分巨大。本文希望通過一些重要概念的解釋和實用技術的說明，理清功能安全概念的過程，幫助功能安全開發人員，實現正確的功能安全概念。
版權聲明：本文為CSDN博主「coroutines」的原創文章，遵循CC 4.0 BY-SA版權協議，獲作者轉載權限。
展開 