01本文概述

隨著汽車行業電氣化智能化的快速發展，功能安全標準ISO 26262逐漸被各大汽車制造企業及零部件供應商重視。近期，《智能網聯汽車生產企業及產品準入指南》明確將功能安全和預期功能安全作為汽車制造和生產的準入要求，體現了國家對于汽車安全的重視，功能安全的實施與否已經成為了衡量汽車制造企業及零部件供應商造車能力的關鍵性指標。

然而，功能安全標準的發布和實施歷史并不悠久。根據筆者觀察，尤其國內大部分汽車制造和零部件供應商企業，基本從2014年起才開始關注功能安全設計。因此功能安全在國內的發展其實還遠未達到成熟期，可以說目前依然處于概念建立期或者快速發展期。

因此，面對日新月異的汽車電子電氣系統的發展，如何正確地理解或者考慮該產品的安全設計給很多同行帶來了困惑。對于一個系統，架構設計通常決定了該系統的整體性能表現，而功能安全標準對架構設計的要求及安全分析方法論引用比較復雜，如何在系統設計之初，合理并充分的考慮其安全設計成為了當前很多同行在做安全設計的一個難點。

內容框架：

安全架構設計必須了解的術語及安全方法說明

E-GAS三層架構的理解及使用約束

ADAS系統安全架構設計及安全等級的分解

02安全架構設計必須了解的術語及安全方法說明

在ISO 26262的第三部分，第四部分及第九部分，提到了很多關于系統或者相關項的安全術語，包括故障類型判斷，安全分解策略，故障控制/避免措施，等。如何正確地理解并應用這些術語及背后的方法論，對于安全架構設計尤為重要。本文主要針對涉及到系統安全架構設計的必要術語進行一些系統性闡述，幫助大家理解其中關系。

故障控制措施（Fault control）和故障避免措施（Fault avoidance）

在功能安全標準或者一些教學中，經常會提到系統性失效和隨機硬件失效兩個概念作為電子電氣系統的兩大失效來源。在安全設計時，我們應當理解，并非所有的失效都能夠通過安全機制來診斷或者控制，例如，基于系統層面FMEA或者FTA分析，導出可能違背安全目標的可能失效來源后，需要基于具體的失效原因制定對應的安全措施。

對于某個器件的隨機硬件失效或者某個功能的系統性失效，如果可以通過特定安全機制進行診斷或者控制達到安全狀態的，我們把這一類安全措施歸納為故障控制措施。(本文提到的故障控制措施包含故障診斷以及容錯（fault tolerance）)

對于某個算法或者安全控制邏輯設計如果沒有可以采用的安全機制能夠對它合理性進行診斷及控制，那么就應該功能實現本身設計為對應的安全等級以對該功能的系統性失效進行覆蓋，我們把它歸納為故障避免措施。

需要注意的是，從安全分解的角度，對于故障控制措施的安全需求，我們通常無需考慮進一步分解，對該功能直接進行對應安全級別的設計即可；對于故障避免措施的安全需求，如果有必要，我們才需要考慮進行進一步ASIL分解，進行冗余設計。（本文提到的故障避免措施，僅指代在功能設計時應當考慮的通過符合該功能安全設計流程和方法用于降低故障發生概率，其廣泛含義還包含各階段的安全分析，確認等標準要求的安全活動。）

安全分解（Decomposition）和分配（Allocation）

對于安全分解和分配，通常在上游安全需求往下游設計細化時考慮。其中，安全分解并非是必須的，而安全分配則是必須的。在考慮安全分解或者分配時，需要有一定程度細化的系統初始架構，包括物理和邏輯架構。結合系統安全分析FTA, FMEA識別的故障控制措施或者故障避免措施，將安全相關的診斷或者控制需求分配到架構元素中去。

進行安全分配和分解考慮時需要注意：

分配最簡原則：如果對于某個安全目標或者故障控制措施，能夠由系統架構中的一個單獨元素完成。則將該安全功能完全分配到該元素中去，并保持該功能元素與其他非安全功能之間的獨立性。

分配最后原則：如果對于某個安全目標或者故障控制措施，能夠由一條安全關鍵路徑的最后一個元素來實施，那么可以將該安全功能分配到該路徑的最后一個元素中去。需要保證該元素對安全需求的實現不受前級輸入影響。

分解最大可用性原則：充分利用初始架構中已經存在的冗余元素進行安全需求的分解，而不是去新增新的冗余元素。這里的冗余元素不局限于相同的傳感器或者控制器執行機構等，只要兩者之間有固定的算法或者合理性關系皆可以考慮構成分解。

分解最簡原則：考慮安全分解時，如果實現安全目標或者故障避免措施的診斷或者實施過程比較復雜，那么采用分解策略時，應當采取更為簡單有效的安全設計對預期的功能進行分解，并給其分配更高的安全等級，通常推薦QM(X)+X(X)方式進行分解。

冗余（Redundant）和獨立性(Independent) 設計

基于標準描述，進行安全分解后，需要保證分解后的兩個功能具備對上級安全需求的實現的冗余并且完全獨立。

冗余理解為：分解后的兩個或者多個功能能夠分別獨立地完成上游安全需求。注意，通常預期功能和其安全機制不能直接構成冗余，除非該安全機制能夠完全執行預期功能的安全要求并能獨立的控制系統進入安全狀態。

例如，MCU的功能控制與外部看門狗不能構成安全分解的關系，因為外部看門狗并不能取代MCU單獨的完成所有安全診斷和控制任務；而對于CAN通訊的E2E安全機制可以與CAN總線協議的診斷功能構成安全分解，因為E2E機制可以通過CRC和Rolling Counter覆蓋信號傳輸過程中的信號安全診斷要求，并且獨立于CAN總線協議使系統進入安全狀態。（E2E診斷要求可以作為安全控制措施成為FSR，而對通訊整體不提安全要求，這種情況下則無需考慮分解，將該控制措施直接按照對應的安全級別實施即可。）

獨立性理解為：分解后的兩個或者多個功能之間不存在共同的導致初始安全需求被違背的失效來源或者該類型的失效能夠被合理的安全機制覆蓋；

注意，標準不僅要求對分解后的安全功能之間做共因失效分析，用于評估安全機制的有效性也需要做分析（預期功能與安全機制之間的獨立性）。

要素共存的需要，如果在系統或者軟件層面存在不同安全級別或非安全的功能運行在同一塊資源區間，則需要保證低安全等級的功能失效不會導致高安全等級的功能失效，或者該失效類型能夠被合理的安全機制覆蓋。

以上獨立性的要求，可以被概括為避免共因失效（Common Cause Failure）和避免級聯失效（Cascading Failure）,這兩類失效通常由FTA及FFI分析后識別，通過DFA分析才能確認分解后的元素完全獨立。

失效安全（Fail safe）

失效靜默（Fail silent）

失效運行（Fail operational）

及緊急運行（Emergency operation）

在考慮不同產品的功能失效時，需要基于產品功能的可用性要求，在行業內，經常會有如下幾個關于安全架構概念階段的名詞，用于定義產品架構級別的失效屬性，從而判斷該采取哪一種設計作為安全狀態。

失效安全（Fail safe）：是指一個系統失效后特定功能關閉能夠讓系統維持在安全狀態。例如，對于發動機管理系統的避免非預期扭矩輸出這個安全目標，可以考慮采用關閉發動機扭矩輸出作為安全狀態。或者對于L2及以下的自動駕駛系統功能，也通常考慮采用關閉該特定功能作為安全狀態。

失效靜默（Fail silent）：失效靜默類似于失效安全，但是通常理解為系統失效后的一種狀態屬性，失效靜默表示系統失效后對外表現為靜默狀態，不對其他的功能和輸出產生干擾。該詞匯用于描述功能失效后的影響，不常用于安全狀態定義。

失效運行（Fail operational）：如果一個安全狀態無法通過功能關閉來實現，而是要保證系統的可用性，那么就需要選擇失效運行作為其安全狀態。例如對于L4及以上的自動駕駛系統，如果設計要求系統失效后車輛依然可以按照既定的操作進行自動駕駛，則需要設計一套冗余的控制系統，在主控制系統失效后，Fallback系統能夠及時接管車輛在既定的ODD運行。類似失效運行的概念，還有失效降級（fail degraded, fail partial）,通常對于有失效后可用性要求，又不需要完整的冗余接管的系統，例如，對于車輛燈光控制系統的防止近光燈非預期的完全關閉，這個安全目標需要考慮通過雙電源和日間行車燈對近光燈的冗余，保證失效后至少有一個近光燈或者日間行車燈對路面進行照明。

緊急運行（Emergency operation）：這個術語不等同于失效運行。緊急運行是指如果安全狀態無法在可接受的時間內實現，則需要定義一個緊急操作，讓系統在FTTI時間之內能夠順利的過渡到安全狀態。這里的安全狀態可能是指fail silent或者fail operational。例如，對于L3級別的自動駕駛系統，如果MRC作為系統的安全狀態（fail silent）,那么fallback系統的MRM功能則可以定義為緊急運行。

限于篇幅，對于概念和系統階段其他的術語筆者不作展開，主要闡述在安全架構設計時應當考慮的幾個基本點，即：

如何分配安全需求；

如何考慮安全分解；

如何考慮安全狀態設計。

在開展具體的安全架構設計時，還需要充分地參考安全標準具體要求。

03E-GAS三層架構的理解及使用約束

早期從事功能安全的同行對汽油發動機管理系統的E-GAS三層安全架構應該都有了解。雖然該架構并非為實現功能安全而專門設計，但是該架構提供了一個很好的應用安全分解的解決方案。基于目前市場上的類似電控系統設計，該架構基于Lockstep Core設計可以支持到最高ASIL D級別的設計要求。

圖3.1-E-GAS三層安全架構帶LC示意圖

對于三層架構，如果運用安全分解策略，我們應該要注意：

L2層級的安全控制功能的輸入需要獨立于L1層級，以保證兩者的獨立性

L2可以對L1層級的輸出信號進行診斷，診斷輸出控制應該獨立于L1的輸出控制，能夠直接對系統進行關斷控制，以保證安全狀態控制的獨立性

L2 也可以通過輸入信號進行獨立的功能診斷，診斷輸出控制應該獨立于L1的輸出控制，能夠直接對系統進行關斷控制，以保證安全狀態控制的獨立性

外部監控設備需要能夠獨立的對系統進行關斷控制而不必依賴于L1或者L2的控制指令，用于避免L1和L2的相關性失效。

在考慮應用E-GAS架構時，對其安全分解策略并無固定要求，但是通常推薦采用QM(X) + X(X)的分解策略。主要考慮：

如果系統功能設計已經比較成熟，而引入功能安全后，對該系統進行功能重構復雜程度高。因此采用QM(X) + X(X)的分解能夠讓系統設計本身保持QM的等級，而只是對安全要求進行冗余的設計，這樣能夠最小化的影響功能的穩定性。

系統功能安全需求數量不多，并且該系統能夠采用相對簡單的策略對故障避免措施進行額外的冗余設計。這樣能夠最小化地增加開發成本。

L2 也可以通過輸入信號進行獨立的功能診斷，診斷輸出控制應該獨立于L1的輸出控制，能夠直接對系統進行關斷控制，以保證安全狀態控制的獨立性

例如，傳統的三電系統，發動機管理系統，變速箱控制系統及車身控制系統皆可以采用上述架構。通過E-GAS三層架構，對安全的功能和系統控制功能進行合理的分解，再配合目前主流的英飛凌AURIX（帶Lockstep）+SBC(ASIL D)硬件解決方案，能夠高效快速的實現高等級的功能安全設計。除此之外，對于VCU, MCU等新能源汽車上的一些控制器，通過E-GAS三層架構來實現ASIL D等級的設計也是很多主機廠和供應商的優先選擇。

需要注意的是，對于一個復雜的新系統開發，或者系統功能安全需求數量大且不易做安全分解的，則不建議首先采用E-GAS三層架構。例如，對于自動駕駛系統的域控制器及備份控制器開發，安全需求除了MCU本身控制功能之外，對于感知，定位和規劃算法均有涉及，而SoC和MCU之間很難采取統一的安全監控架構。因此，即使采用E-GAS架構實施安全分解策略后，也需要做大量冗余功能及獨立性設計，并不能獲得很好的時間或者成本的收益。對于這樣的系統，可以考慮直接對安全的功能路徑進行對應級別的開發，并做好獨立性設計。

04ADAS系統安全架構設計及安全等級的分解

在考慮ADAS系統的安全設計時，應當首先考慮該系統的自動駕駛等級以幫助判斷該系統安全狀態，參考SAE J3016定義：

圖4.1-SAE J3016自動駕駛功能等級定義

基于定義來看，如果一個ADAS功能定義在SAE LEVEL 2及以下，則駕駛員需要時刻監督系統的運行用于保證駕駛安全。那么在定義該系統安全狀態時，可以考慮采用失效靜默架構，當系統失效時，對功能進行關閉即可滿足該要求。

而對于SAE LEVEL 3級別的ADAS功能，由于系統定義在發生失效后的一定時間內（通常規定10s及以上），系統仍然需要正確的執行DDT，或者進行功能降級運行狀態。因此在考慮該系統的安全架構時，需要設計緊急操作或者失效運行功能（L4及以上）。當主控制器發生安全相關失效而又無法進入安全狀態時，備份系統至少需要在規定時間以內保持動態駕駛任務并提示駕駛員接管。

值得注意的是，SAE 并沒有要求自動駕駛系統設計必須要做完全的失效運行，只要求接管系統在系統失效時一定時間內能夠讓車輛到達最小風險狀態。因此在考慮ADAS架構設計時，不一定需要考慮系統失效時還能執行完整DDT的能力，只需要考慮接管系統是否有能力通過功能降級及駕駛員未接管后由緊急運行使車輛最小風險狀態即可。

L3及以上級別自動駕駛系統安全等級評估

從功能安全的角度出發，由于高安全等級自動駕駛系統允許駕駛員脫眼或者脫手，在評估某系統的功能安全目標時，部分危害事件S,E,C會評定為最高分，繼而得到ASIL D級別的安全目標。而當安全目標被違背時，系統又無法通過功能靜默直接進入安全狀態，因此對于控制信號的可用性設計也會要求滿足ASIL D。

當前市場上ADAS系統的設計有很多，各家都在自研架構，但是整體的功能安全目標及最高級別通常均為ASIL D。為了實現最小成本的解決方案，我們需要從系統架構層級，在滿足安全要求的前提下盡量簡化系統的設計。因此建議在基于SAE標準下的系統架構要素，用于功能安全需求的分解。例如，將fallback系統與Main系統進行冗余，將控制指令可用性失效需求分解由fallback和Main系統實現，考慮兩者之間的獨立性設計，及可以將部分的安全指標降級。本文將引入一個抽象的ADAS系統架構，用于描述功能安全ASILD級別在架構上的分解及分配關系。假設該ADAS架構抽象為如下圖：

圖4.2-L3+ADAS自動駕駛系統抽象架構

注意：在圖4.2 架構中，為實現ADAS域控制指令的獨立性，實現安全分解，將ADAS指令仲裁功能分配給底盤動力域控制器。在實際項目中，指令仲裁功能也可能由ADAS Main控制器實現，通過一定的機制實現自動指令轉換，基于此結構，運動域控可以不需要；另外指令仲裁功能也可以集成在底盤域控系統中。對于執行器端的冗余設計，可以基于不同的ADAS功能和安全降級的要求進行必要冗余，而非橫縱向完全冗余。執行器端具體方案在本文不做詳細展開。

如果定義ADAS系統的整體安全目標簡化為：

防止非預期的不能提供控制指令，ASIL D：

基于圖4.2，Fallback系統作為Main系統的冗余系統，通過完全的冗余和獨立可以將安全指令的可用性需求分解為ASIL B（D）即：

1. Main 系統需要提供正確的橫向和縱向控制指令ASIL B（D）

2. Fallback 系統需要提供正確的橫向和縱向控制指令ASIL B（D）

3. Main 系統和Fallback系統的控制指令需要完全獨立 ASIL D（獨立性要求）

需要注意的是，Fallback和Main控制器需要”熱冗余”。熱冗余是指在Main運行過程中，Fallback也應當同時運行，主要用于減少主控制器失效時指令切換的時間。同時，從安全角度，兩者對自身失效進行診斷以防止非預期的失效導致自身控制指令不可用，無論哪個控制器診斷出自身失效，ADAS系統需要在一次駕駛循環內進行MRM或者不允許ADAS功能下次激活

防止非預期的發出錯誤控制指令，ASIL D

基于圖4.2，由于ADAS系統運行時主要由Main系統進行仲裁及整車控制，因此對于Main系統，其安全診斷級別應當做到ASIL D。

由于 Fallback的整車接管控制在Main失效后才會啟動。因此，在考慮Fallback系統安全級別時，可以從如下角度考慮適度降低：

例如，如果我們定義SAE ADAS L4系統,在主系統失效后，Fallback系統接管后最大有效運行時間為1小時, 對Fallback接管功能做HARA分析：

1.Fallback系統的失效造成嚴重度與Main系統失效相同 （S3）;

2. Fallback系統失效后可控度與Main系統失效相同 （C3）；

3. 在評估暴露度時，基于Fallback功能控車總共時長不超過1小時，相比較Main系統失效場景暴露度E，可以降低其指標，分析過程如下表：

表4.1-1 Fallback系統暴露度指標評估參考

發生永久性故障后接管系統的最大操作時間：假定在最壞情況下，Main控制器在其操作時間內失效。

假定系統運行過程由于瞬態切換而累積的接管操作持續時間：假定主系統由于系統性原因或者SOTIF影響短暫切換到Fallback系統，恢復后退回Main控制器。考慮在1000小時的ADAS操作時間內，每小時切換3s。

基于以上分析，我們可以看到，對于fallback系統，其實際的operation time只占ADAS系統operation time不到1%， 因此，可以將其E值由E4降為E2。繼而，對Fallback系統發出錯誤的控制指令ASIL級別由ASIL D降為 ASIL B。

備注：1. 以上分析假定的前提為Main控制器與Fallback控制器完全獨立，其指令仲裁在底盤系統中實施；2. HARA分析中對暴露度E值的評估方法與本文提及的降低策略有偏差，從本文的角度，實際上基于產品Operation time定義來降解，更多的是從降低隨機硬件失效概率。對于Fallback控制器系統性失效，很多同行會認為需要按照原始等級（ASIL D）來實施。該分析僅做參考。

基于以上兩點，可以簡單總結ADAS系統的安全概念：

FSR-1:在ADAS系統運行過程中，如果Fallback控制器診斷出自身失效，導致無法發出控制指令，Main控制器應當基于Fallback狀態，控制系統運行一段時間或者進入MRC*。ASIL B(D)（FSR a，可用性設計，*這里也可以考慮在一個駕駛循環內持續進行DDT）;

FSR-2:在ADAS系統運行過程中，如果Main控制器診斷出自身失效，導致無法發出控制指令，Fallback控制器應當基于當前失效狀態，控制系統運行或者降級一段時間或者緊急操作進入MRC。ASIL B(D)（FSR a，可用性設計）;

FSR-3:Main控制器應當監控并正確的發出橫縱向控制指令，如果Main控制器失效導致無法發出正確的控制指令，Main控制器應當關閉控制輸出。ASIL D（FSR b, 防止提供錯誤的控制指令)；

FSR-4:Fallback系統在進行緊急操作或者接管系統駕駛任務過程中，如果Fallback系統監測到自身失效，導致無法發出正確的控制指令，則應當停止發送控制指令 ASIL B(FSR b， 防止提供錯誤的控制指令)

由于目前行業內ADAS系統設計，國內外還沒有一個權威且受認可的方案，因此以上分析及見解僅作為參考。

05總結

本文基于ISO 26262標準的定義，并結合當前部分汽車零部件供應商或者主機廠對于產品的功能安全架構設計實踐以及個人經驗，嘗試對功能安全產品架構設計進行了一些淺薄的描述。

審核編輯：郭婷