基于ISO 26262標準的的功能安全產(chǎn)品架構(gòu)設計

01本文概述

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

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

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

內(nèi)容框架：

安全架構(gòu)設計必須了解的術(shù)語及安全方法說明

E-GAS三層架構(gòu)的理解及使用約束

ADAS系統(tǒng)安全架構(gòu)設計及安全等級的分解

02安全架構(gòu)設計必須了解的術(shù)語及安全方法說明

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

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

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

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

對于某個算法或者安全控制邏輯設計如果沒有可以采用的安全機制能夠?qū)λ侠硇赃M行診斷及控制，那么就應該功能實現(xiàn)本身設計為對應的安全等級以對該功能的系統(tǒng)性失效進行覆蓋，我們把它歸納為故障避免措施。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

失效安全（Fail safe）

失效靜默（Fail silent）

失效運行（Fail operational）

及緊急運行（Emergency operation）

在考慮不同產(chǎn)品的功能失效時，需要基于產(chǎn)品功能的可用性要求，在行業(yè)內(nèi)，經(jīng)常會有如下幾個關(guān)于安全架構(gòu)概念階段的名詞，用于定義產(chǎn)品架構(gòu)級別的失效屬性，從而判斷該采取哪一種設計作為安全狀態(tài)。

失效安全（Fail safe）：是指一個系統(tǒng)失效后特定功能關(guān)閉能夠讓系統(tǒng)維持在安全狀態(tài)。例如，對于發(fā)動機管理系統(tǒng)的避免非預期扭矩輸出這個安全目標，可以考慮采用關(guān)閉發(fā)動機扭矩輸出作為安全狀態(tài)?；蛘邔τ贚2及以下的自動駕駛系統(tǒng)功能，也通?？紤]采用關(guān)閉該特定功能作為安全狀態(tài)。

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

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

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

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

如何分配安全需求；

如何考慮安全分解；

如何考慮安全狀態(tài)設計。

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

03E-GAS三層架構(gòu)的理解及使用約束

早期從事功能安全的同行對汽油發(fā)動機管理系統(tǒng)的E-GAS三層安全架構(gòu)應該都有了解。雖然該架構(gòu)并非為實現(xiàn)功能安全而專門設計，但是該架構(gòu)提供了一個很好的應用安全分解的解決方案?；谀壳笆袌錾系念愃齐娍叵到y(tǒng)設計，該架構(gòu)基于Lockstep Core設計可以支持到最高ASIL D級別的設計要求。

圖3.1-E-GAS三層安全架構(gòu)帶LC示意圖

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

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

L2可以對L1層級的輸出信號進行診斷，診斷輸出控制應該獨立于L1的輸出控制，能夠直接對系統(tǒng)進行關(guān)斷控制，以保證安全狀態(tài)控制的獨立性

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

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

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

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

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

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

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

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

04ADAS系統(tǒng)安全架構(gòu)設計及安全等級的分解

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

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

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

而對于SAE LEVEL 3級別的ADAS功能，由于系統(tǒng)定義在發(fā)生失效后的一定時間內(nèi)（通常規(guī)定10s及以上），系統(tǒng)仍然需要正確的執(zhí)行DDT，或者進行功能降級運行狀態(tài)。因此在考慮該系統(tǒng)的安全架構(gòu)時，需要設計緊急操作或者失效運行功能（L4及以上）。當主控制器發(fā)生安全相關(guān)失效而又無法進入安全狀態(tài)時，備份系統(tǒng)至少需要在規(guī)定時間以內(nèi)保持動態(tài)駕駛?cè)蝿詹⑻崾抉{駛員接管。

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

L3及以上級別自動駕駛系統(tǒng)安全等級評估

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

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

圖4.2-L3+ADAS自動駕駛系統(tǒng)抽象架構(gòu)

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

如果定義ADAS系統(tǒng)的整體安全目標簡化為：

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

基于圖4.2，F(xiàn)allback系統(tǒng)作為Main系統(tǒng)的冗余系統(tǒng)，通過完全的冗余和獨立可以將安全指令的可用性需求分解為ASIL B（D）即：

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

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

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

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

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

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

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

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

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

2. Fallback系統(tǒng)失效后可控度與Main系統(tǒng)失效相同 （C3）；

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

表4.1-1 Fallback系統(tǒng)暴露度指標評估參考

發(fā)生永久性故障后接管系統(tǒng)的最大操作時間：假定在最壞情況下，Main控制器在其操作時間內(nèi)失效。

假定系統(tǒng)運行過程由于瞬態(tài)切換而累積的接管操作持續(xù)時間：假定主系統(tǒng)由于系統(tǒng)性原因或者SOTIF影響短暫切換到Fallback系統(tǒng)，恢復后退回Main控制器?？紤]在1000小時的ADAS操作時間內(nèi)，每小時切換3s。

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

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

基于以上兩點，可以簡單總結(jié)ADAS系統(tǒng)的安全概念：

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

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

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

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

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

05總結(jié)

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

審核編輯：郭婷