功能安全設計的案例
符合功能安全的Level2層VCU架構設計
來源 |
電動學堂
隨著軟件定義汽車的趨勢日益加強，道路車輛電子電器系統滿足功能安全已經成為基本要求。近期，在歐盟車輛型式批準（typeapproval依據部分UNECE法規）和我國車輛的CCC認證中，對采用電子控制的轉向、制動、動力電池管理系統等也引入了功能安全要求。高效的軟件架構設計顯然對功能安全的實施和落地起著引導性作用，所以電子電器系統滿足功能安全要求已經成為產品基本屬性。
針對軟件架構如何滿足功能安全要求，業內人士紛紛借鑒了E-Gas架構，E-Gas最先被應用于發動機控制器EMS，由Level1功能層、Level2功能監控層、Level3控制器監控層三部分組成。國內相關論文分別將E-Gas架構應用于各個控制功能中，其中專利、文獻、文獻、文獻、文獻都針對功能安全標準設計了整車控制器硬件和軟件，但并未涉及Level2軟件架構。
因此，為了彌補E-Gas架構未明確提出基于模型開發MBD的Level2軟件架構的缺陷，且架構設計要滿足高內聚低耦合、合適的分層等功能安全要求，本文針對整車控制器VCU設計了一種Level2功能監控層軟件架構，不但符合功能安全架構設計要求，而且可應用于其他ECU功能安全Level2設計中，有助于功能安全設計進一步落地，降低實施難度。
一、VCU模型整體架構
設計整車控制器VCU模型Level1、Level2架構，如圖1所示，包括時序調度、輸入信號、Level1、Level2和輸出信號模塊，需滿足功能安全可理解性、一致性、簡單性、可驗證性、模塊化、抽象化、封裝性、可維修性等架構設計原則和要求。
展開 自動駕駛預期功能安全要素及準入難點解讀
作者 | Aimee
出品 | 焉知
知圈 | 進“電子電氣群”請加微13636581676,備注架構
傳統電子電氣領域問題，可通過功能安全解決。但隨著自動駕駛技術的發展，加入了包括算法、圖像識別等內容，僅保證自身無故障已經不足以滿足自動駕駛對于安全的需求。由于自動駕駛系統本身的高度復雜性，導致了我們設計的功能本身就有局限性或缺陷，從而進一步導致安全事故的發生，預期功能安全試圖解決的就是這些問題。
行業內預期功能安全的標準為ISO21448，這份標準主要為了應對駕駛輔助/自動駕駛領域越來越復雜的系統和工況。與功能安全不同，在判斷功能失效的情況及原因時，如果功能錯誤/失效是由于相關EE架構失效或硬件失效等引起的，就是功能安全的范疇(ISO 26262)，如果是由于一些系統的設計局限，比如傳感器的誤識別或是駕駛員的誤操作等原因導致對一些場景的錯誤解讀而引起的話，就是SOTIF的范疇(ISO/PAS 21448)。
本系列文章將分別介紹預期功能（SOTIF），功能安全和網絡安全這三個可靠性域如何協同工作，以及如何將它們組合在一起以創建一個可靠的系統。
本文首先介紹每個領域，并從安全性前提下衍生出可靠的自動駕駛功能。然后，提供可以實現這些預期功能安全設計的元素。最后，通過引入通用的邏輯體系結構來組合所有元素確保預期功能安全設計的完備性。
自動駕駛汽車的法律框架
中華人民共和國工業和信息化部于2018年發布了《國家汽車工業互聯網標準體系（智能互聯汽車）建設指南》，以全面加強頂層設計，加強自動駕駛汽車的智能化及網聯化過程研發。
展開 從功能安全視角看軟件架構設計
功能安全應該如何考慮軟件架構，什么樣的架構是符合功能安全標準要求的，對于軟件架構工程師和功能安全工程師，很難在兩個方面都說得明白，本篇來從功能安全的角度談談軟件架構設計的基本要求。
首先，功能安全軟件的架構設計是基于兩個層次的：
第一：
選取和建立一個層次分明，易于理解的軟件架構；
第二：
在第一條的基礎上，符合相應功能安全等級要求的軟件設計要求。
接下來，以汽車功能安全標準ISO26262-6和軌道交通軟件功能安全標準EN50128作為基準，談談標準是如何從以上兩個層次來做出規定的。
軟件架構階段的開始
軟件架構設計是軟件生命周期的第二個階段，前面的階段是軟件需求階段（software requirements specification）,在軟件需求設計時，把整個軟件當成一個黑盒處理，來確定該軟件的所有功能、性能，與硬件的接口定義，與外部其它系統的接口定義，而在軟件架構階段，需要設計一種架構來滿足軟件需求，通過層次化結構的方式來表示軟件架構的組件構成和他們之間的交互方式。以下圖為例，虛線框之外是軟件需求，虛線框內是軟件架構。
什么是軟件組件
上面這個圖用于解釋軟件架構所做的工作，將整個軟件劃分為功能和接口清晰的組件。
展開 從功能安全視角看軟件架構設計
來源 | 薄說安全
功能安全應該如何考慮軟件架構，什么樣的架構是符合功能安全標準要求的，對于軟件架構工程師和功能安全工程師，很難在兩個方面都說得明白，本篇來從功能安全的角度談談軟件架構設計的基本要求。
首先，功能安全軟件的架構設計是基于兩個層次的：
第一：選取和建立一個層次分明，易于理解的軟件架構；
第二：在第一條的基礎上，符合相應功能安全等級要求的軟件設計要求。
接下來，以汽車功能安全標準ISO26262-6和軌道交通軟件功能安全標準EN50128作為基準，談談標準是如何從以上兩個層次來做出規定的。
軟件架構階段的開始
軟件架構設計是軟件生命周期的第二個階段，前面的階段是軟件需求階段（software requirements specification）,在軟件需求設計時，把整個軟件當成一個黑盒處理，來確定該軟件的所有功能、性能，與硬件的接口定義，與外部其它系統的接口定義，而在軟件架構階段，需要設計一種架構來滿足軟件需求，通過層次化結構的方式來表示軟件架構的組件構成和他們之間的交互方式。以下圖為例，虛線框之外是軟件需求，虛線框內是軟件架構。
什么是軟件組件
上面這個圖用于解釋軟件架構所做的工作，將整個軟件劃分為功能和接口清晰的組件。
展開 
智能駕駛車輛功能安全測試解決方案
在功能安全測試領域，經緯恒潤致力于為客戶規劃定制化的功能安全測試方案、構建功能安全測試工具鏈、提供貼身的測試服務與測試培訓，助力智能駕駛車輛功能安全設計落地。
功能安全管理（四）：功能安全審核及功能安全評估
作者 | HYZY
出品 | 焉知
知圈 | 進“芯片社群”請加微信13636581676，備注芯片
功能安全開發流程的終點應該是對相關項的安全認可，以確認其達到了生產發布的安全條件。
一、認可措施的關系
ISO 26262標準中定義的認可措施包括認可評審、功能安全審核和功能安全評估三種類型，ISO 26262標準中允許將認可評審和功能安全審核與功能安全評估合并、聯合，以支持相關項類似變型的處理。
下圖1展示了三種認可措施及驗證評審之間的關系，可以看出：
認可評審/驗證評審與功能安全審核相對獨立，分別是針對工作成果及功能安全開發流程；
功能安全評估的范圍最廣，除涵蓋了認可評審、驗證評審和功能安全審核外，還包括安全措施的適宜性和有效性、功能安全實現的論證、安全檔案提供的論證、安全異常原因已按規定關閉等其它內容。
圖 1 認可措施及驗證評審范圍
二、功能安全審核
1、功能安全審核內涵
功能安全審核可類比ASPICE過程能力審核與TS 16949體系審核，可由公司的體系審核員或第三方機構審核員按照ISO 26262標準中對于過程的要求，審核項目開發中的安全流程實施情況。
功能安全審核可與ASPICE過程能力評估一同進行（特別是對于支持過程的審核），但ASPICE過程能力評估不能代替功能安全審核。
展開 自動駕駛預期功能安全要素及準入難點解讀
這里需要說明的是對于功能不足、誤用、觸發條件原因導致的錯誤結果，可通過如下幾個方面進行改進：
1、提升系統能力，例如算力、算法效率；
2、增加多樣性冗余技術，例如感知融合、執行端多冗余、電源冗余；
3、明確說明功能條件限制，例如明確ODD范圍；
4、駕駛員接管預測、控制策略及提示策略；
5、通過用戶手冊對駕駛員進行警示，以減少對系統的誤用情況。
總結
自動駕駛準入對于企業在預期功能安全的開發和設計中提出了較高的要求，這就要求企業在設計之初需要不斷完善其安全分析能力和設計能力，確保在自動駕駛設計開發后期的測試驗證過程中能夠滿足法規和上市銷售需求。這種安全分析設計能力除開可以參照SOTIF標準外，還可以由企業結合自身能力從更加深層次的角度進行分析和設計，如完善場景庫搭建，加入安全分析流程，結合測試工具，收集市場反饋，以不斷完善自動駕駛SOTIF分析能力。
展開 控制閥聯鎖功能安全要求和設置
編 輯 | 化工活動家
來 源 | 石油化工自動化 長城能源化工
作 者 | 陳志飛
關鍵詞 | 控制閥 聯鎖 功能安全 要求
共 1456 字 | 建議閱讀時間 7 分鐘
導讀
控制閥是過程控制工業里最常用的終端控制元件，在安全儀表系統設計中除機泵等動設備外控制閥往往都是作為聯鎖動作的最終執行者，是整個控制回路的核心和失效占比較高的環節?？刂崎y除了用作正常調節外，在安全領域有時需要承擔切斷、放空等功能?？刂崎y承擔安全功能時，具有嚴格的功能要求。今天主要講解的控制閥主要指氣動調節閥和氣動開關閥。
控制閥聯鎖安全要求
控制閥除了泄漏等指標外，聯鎖動作時一般還需具備三個基本要求：故障安全位置；執行的可靠性；全行程響應時間。
01
故障安全位置
在工程實踐中，當遇到氣源、電源、信號故障時，不同的場合對閥門的狀態有不同的要求，故障位置基本類型有故障開（FO）、故障關（FC）和故障保持（FL）三種，主要基于以下三方面：
1）事故條件下，工藝裝置盡量處于安全狀態。
2）事故狀態下，減少原料或動力消耗，保證產品質量。
3）考慮介質的特性。如氣化爐燒嘴冷卻水進口切斷閥要求為FO，氣化爐鎖渣閥要求為FC等。
02
可靠性
功能安全是安全功能設計的重要內容，是評價安全功能實現的有效性和可靠性。
展開 經緯恒潤SOA功能安全開發方案, 助力車企軟件定義汽車
▎SOA架構危害分析與風險評估
危害分析與風險評估（HARA）基于相關項定義中提取的用戶實例及執行器特性等內容，從狀態機和執行器兩個維度分析功能的失效，結合咨詢團隊100+量產項目經驗所總結的場景庫組合得到危害事件。經緯恒潤安全團隊引入MBSE方法，通過量化的計算模型和仿真相結合的方式，定量計算得到危害事件的嚴重度S與可控度C值，結合場景庫中得到的暴露率E值，最終得到危害事件的ASIL等級并導出安全目標，迭代更新到功能定義文檔中。
▎SOA架構概念層級開發
功能安全概念（FSC）基于相關項定義中提取的時序圖，采用故障樹分析（FTA）的方法，分析時序圖中PC（Product Capability）的失效或PC之間交互的失效是否會違反相應的安全目標，若違反則設計對應的整車級安全策略（例如診斷并導入安全狀態、冗余設計等）。通過與E/E架構團隊的協同設計，確定功能安全設計過程中所引入的新的PC或PC之間接口的合理性及正確性，將上述功能安全策略更新到功能設計文檔的時序圖中。
▎SOA架構系統層級開發
功能安全系統階段開發主要基于E/E架構團隊的模塊設計文檔。技術安全概念（TSC）的主要分析對象是SWC的部署視圖，即不同的SWC分別部署在中央控制器、區域控制器及與區域控制器相連的ECU中。同樣通過故障樹分析的方式確定當前系統架構設計中的薄弱點，增加安全機制保證系統架構設計滿足功能安全的要求。新增的SWC及接口同樣通過和架構團隊討論后確定并更新到SWC部署視圖中。
經緯恒潤于2008年成立功能安全小組，是國內較早從事功能安全技術研究的團隊。
展開 淺談系統安全架構設計
引言
淺談系統安全架構設計
筆者從事功能安全領域工作八年有余，結合個人經驗分享一下對系統安全架構設計的理解，希望能夠解決部分同行對于安全架構設計的痛點。
注：圖片來源于網絡，如有侵權，請及時聯系作者刪除。
?本文主要內容分為6個部分（約7700字，30分鐘閱讀）
目錄
01
本文概述
02
安全架構設計必須了解的術語及安全方法說明
03
E-GAS三層架構的理解及使用約束
04
ADAS系統安全架構設計及安全等級的分解
05
總結
06
參考文獻
01
本文概述
隨著汽車行業電氣化智能化的快速發展，功能安全標準ISO 26262逐漸被各大汽車制造企業及零部件供應商重視。近期，《智能網聯汽車生產企業及產品準入指南》明確將功能安全和預期功能安全作為汽車制造和生產的準入要求，體現了國家對于汽車安全的重視，功能安全的實施與否已經成為了衡量汽車制造企業及零部件供應商造車能力的關鍵性指標。
然而，功能安全標準的發布和實施歷史并不悠久。根據筆者觀察，尤其國內大部分汽車制造和零部件供應商企業，基本從2014年起才開始關注功能安全設計。因此功能安全在國內的發展其實還遠未達到成熟期，可以說目前依然處于概念建立期或者快速發展期。
因此，面對日新月異的汽車電子電氣系統的發展，如何正確地理解或者考慮該產品的安全設計給很多同行帶來了困惑。
展開 使用FPGA實現ADAS設計的功能安全考慮
HPS采用了幾種硬件功能(例如，ECC、MMU、看門狗)，在HPS中進行故障診斷。
功能安全重要的另一面是確保減少系統性故障。這通過使用可靠的開發過程和工具來實現。ISO26262標準詳細規定了功能安全的管理要求，例如，對安全生命周期和支持過程中不同的行為進行一致性測量，類似配置和修改管理。如果所使用的工具有可能造成應用故障，那么就應該分析這些工具，進行測量以減小故障發生的概率。
ADAS是確保越來越擁擠的道路更加安全的下一波創新。這些系統的性能需求給現有以及未來的標準商用貨架(COTS)產品帶來了挑戰，而可編程FPGA在這方面有很大的優勢。實現專用診斷能夠擴大系統的診斷覆蓋。很多COTS產品在設計時并沒有體現功能安全，而通過使用具有功能安全的平臺和開發環境，與擅長功能安全的合作伙伴合作，這些都有利于系統的整體實現。(end)
展開 
使用FPGA實現ADAS設計的功能安全考慮
HPS采用了幾種硬件功能(例如，ECC、MMU、看門狗)，在HPS中進行故障診斷。
功能安全重要的另一面是確保減少系統性故障。這通過使用可靠的開發過程和工具來實現。ISO26262標準詳細規定了功能安全的管理要求，例如，對安全生命周期和支持過程中不同的行為進行一致性測量，類似配置和修改管理。如果所使用的工具有可能造成應用故障，那么就應該分析這些工具，進行測量以減小故障發生的概率。
ADAS是確保越來越擁擠的道路更加安全的下一波創新。這些系統的性能需求給現有以及未來的標準商用貨架(COTS)產品帶來了挑戰，而可編程FPGA在這方面有很大的優勢。實現專用診斷能夠擴大系統的診斷覆蓋。很多COTS產品在設計時并沒有體現功能安全，而通過使用具有功能安全的平臺和開發環境，與擅長功能安全的合作伙伴合作，這些都有利于系統的整體實現。（轉）
展開 電動汽車電機驅動控制器功能安全架構研究
0 引言
伴隨著新能源汽車產業的發展，車用電子電氣系統的功能也日趨復雜，如何確保電子電氣系統的功能安全已成為行業關注的重點和研究的熱點。國際標準化組織（ISO）于2011年正式發布了ISO26262《道路車輛功能安全》標準，其提供了一套涵蓋系統（包括硬件和軟件）及其生產制造的完整功能安全設計流程與認證制度，以確保汽車行駛的安全性，并已成為汽車行業目前普遍接受的一套完整的評估并降低風險的方法，獲得了全球主要汽車制造商以及零部件供應商的廣泛認可和采用。盡管該標準針對功能安全性給出了完整的設計流程，對功能安全理念的引入發揮了至關重要的作用，但由于其并不涉及特定產品的具體設計，同時國內外的相關文獻也鮮有介紹，因此如何正確地實現產品級的功能安全，對設計人員而言仍然具有一定的難度。
作為純電動汽車核心動力部件，電機驅動控制器其功能安全的正確實施顯得尤為重要。本文將從純電動汽車電機驅動控制器的安全目標出發，詳細闡述針對不同微處理器結構如何實現系統架構設計層面的功能安全。
1 電動汽車電機驅動控制器安全完整性等級分析
1.1 安全目標及安全完整性等級ASIL
產品安全性開發的最終目的是為了符合安全目標。安全目標是系統最高層面的安全要求，是危害分析和風險評估（HARA）的結果。基于HARA分析可以得出針對安全目標的汽車安全完整性等級（ASIL）。根據文獻可知，ASIL等級的確定需要針對危害事件綜合考慮嚴重度（S）、暴露概率（E）和可控性（C）的因素，如表1所示，其中D代表最高等級，A代表最低等級，QM表示質量管理。
對于S，E，C指標，文獻中均有明確定義，本文不再贅述。需要說明的是，一個安全目標可能與多種危害相關，而多個安全目標也可能與某種單一的危害有關。
展開 BMS功能安全開發流程詳解
在上述中，從安全目標道出了BMS的一個功能安全要求，圖3是對功能安全要求FSR1.2a導出的技術安全要求。
系統設計
基于概念階段的基本系統架構，功能安全概念，技術安全要求和非功能性要求，按照ISO26262的下一步流程就是系統設計了。在這個階段，系統及子系統需要上面所定義的貫徹技術安全要求，需要反映前面定義的安全檢測及安全機制。
技術安全要求的應分配給系統設計要素，同時系統設計應完成技術安全要求，關于技術安全要求的實現，在系統設計中應考慮如下問題：
a. 系統設計的可驗證性
b. 軟件硬件的技術實現性
c. 系統集成中的執行測試能力
系統和子系統架構應該滿足各自ASIL 等級的技術安全需求，每個元素應實現最高的ASIL技術安全需求，如果一個系統包含的子系統有不同的ASIL 等級，或者是安全相關的子系統和非安全相關的子系統，那么這些系統應該以最高的ASIL等級來處理。
在系統設計階段，為了避免系統系失效，ISO26262針對不同的ASIL等級推薦了不同的分析方法，如
FMEA,FAT等。如表1。由于內因或者外因而引起系統失效應當避免或者消除。
為減少系統性失效, 宜應用值得信賴的汽車系統設計原則. 這些原則可能包括：
a. 值得信賴的技術安全概念的再利用；
b. 值得信賴的要素設計的再利用, 包括硬件和軟件組件；
c. 值得信賴的探測和控制失效的機制的再利用, 及
d. 值得信賴的或標準化接口的再利用。
展開 客戶案例 | 通過medini工具完成FMEA/FTA定性和定量分析，并實現功能安全設計各層級的追溯
汽車的功能安全分析就成了汽車系統研發設計的關鍵要素。因此，一款用于復雜產品的系統，硬件，軟件的安全分析和可靠性計算、且滿足功能安全認證標準要求的專業軟件對汽車研發團隊就是非常必要的了。medini含有的可靠性計算模型和失效模式分布等特性，可以為安全分析提供有力的支撐，減少其中的無效步驟，提高研發效率，medini中帶有的分析安全需求的追溯鏈接設置，有助于確保各層級設計的追溯性和合理性。
客戶簡介
深圳麥格米特電氣股份有限公司是一家專注于電能的變換、控制和應用的電氣自動化公司，以電力電子及工業控制為核心技術，業務涵蓋智能家電電控、電源產品、工業自動化、新能源&軌道交通、智能裝備、精密連接六大板塊。
主營業務涵蓋智能家電電控、電源產品、工業自動化、新能源&軌道交通、智能裝備、精密連接六大領域并包括三大核心技術平臺分別是數字化電源控制技術平臺、功率變換硬件技術平臺、系統控制與通訊軟件技術平臺。
所遇工程挑戰
需要一個可靠性高的并且通過功能安全認證的軟件工具，進行包括硬件BOM的失效模式定義、失效率設置和計算等在內的功能安全的定量分析功能；
需要軟件內置多種常用知名標準的失效率數據庫，同時該工具業內知名度較高、客戶廣泛，生成的工程文件可通用；
可以在安全分析(演繹法、歸納法)和安全需求，甚至安全架構、安全機制之間形成清晰的、有邏輯的追溯關系， 因為使用傳統的Excel和手寫工具進行定量分析，效率較低，復用性差；
需要軟件含有一系列成功應用的案例和最佳實踐模版，以及有良好的售后支持，包括提供軟件的使用培訓、二次開發和持續改進的能力。
展開 