你真的做對ASIL分解了嗎？

駕駛哥

2021年6月16日 09:33

瀏覽：3153 評論：1

出品 | 焉知

知圈 | 進“電子電氣群”請加微13636581676,備注架構

本文要點

稍微了解功能安全的朋友絕對都聽過ASIL分解。畢竟作為ISO 26262官方推薦的降低功能安全開發要求的手段，必然是要被工程師們好好地加以利用的。但是 ASIL分解雖好，卻不是簡單的加減運算式的“ASIL D 可以分為兩個ASIL B或一個ASIL A和一個ASIL C”那么簡單，如果在進行分解時忽略了它的前提和規則，將可能造成系統的功能安全漏洞。

基于此背景，本文旨在梳理ASIL分解的理論以及易被忽略的規則，以期為讀者提供一些有價值的參考。

1. 什么是ASIL分解？

設想一個場景：養豬場有兩個豬圈，一個里面有一頭豬X，另一個里面有兩頭豬Y和Z。如果它們的目標都是用力量沖破豬圈的木柵欄獲得自由。顯而易見，對X的力量要求比一起合作的Y和Z都高。

ASIL分解的背后也是相同的道理。作為降低對功能安全需求的ASIL等級的裁剪方法，這一方法的核心點是通過將一條功能安全需求分解成兩條相互獨立的需求并分配到兩個及兩個以上相互獨立的要素（如軟件模塊、硬件模塊、輸入信號等）上，正是由于這些參與分解的獨立的要素之間構成了互為冗余關系，從整個系統的角度看，只有當這些元素同時發生失效時才會違背安全目標，這樣一來對每個參與分解的相關元素的功能安全要求可以降低。

ISO 26262, part9第5章中定義了ASIL分解的特定的標記方式：

應通過在括號中給出安全目標的ASIL等級，對每個分解后的ASIL等級做標注。each decomposed ASIL shall be marked by giving the ASIL of the safety goal in parenthesis.

例如，如果一個ASILD的要求分解成一個ASILC的要求和一個ASIL A 的要求,則應標注成“ASIL C(D)”和“ASIL A(D)”。如果ASIL C(D)的要求進一步分解成一個ASILB的要求和一個ASILA的要求,則應使用安全目標的ASIL等級將其標注為“ASIL B(D)”和“ASIL A(D)”。

你真的做對ASIL分解了嗎？的圖1

ASIL分解標記示例

在ISO 26262, part9第5章中也對ASIL分解原則給出了說明，總結如下表所示。其中QM即Quality Management，表示只要按照企業質量管理流程開發就可以滿足ISO 26262要求，沒有其他特殊功能安全要求。

你真的做對ASIL分解了嗎？的圖2

表格給人的第一印象是ASIL分解和加減運算有些類似，但是要正確地進行ASIL分解實際上并沒有這么簡單，還存在著不少容易被忽略的規則。接下來以案例的形式對這些規則以及開發過程中可能遇到的典型問題進行匯總。

2. ASIL分解規則

2.1. 案例

假設現在有一個舒適性功能，正常情況下駕駛員在車輛靜止狀態下通過按鈕激活，但是如果該功能在車速超過15kph時激活將會造成ASIL C的風險。由此對該功能提出如下需求：

#R0：The function shall be deactivated for vehicle speed greater than 15km/h

為實現該需求所設計的功能架構如下圖所示，關鍵點為：

前端的Controller在接收到駕駛員的按鈕請求后會判斷當前的車速，當車速小于15kph時允許發出激活請求
后端的Actuator在收到來自Controller的激活請求時會進一步判斷車速，當車速小于15kph時控制actuator動作

你真的做對ASIL分解了嗎？的圖3 功能架構圖（示例）

由此引申出兩條需求：

#R1：Controller shall not send an activation command for vehicle speeds greater than 15km/h
#R2：Actuator switch shall open when vehicle speed is greater than 15km/h

回到案例上，理論上如果對#R1和#R2進行ASIL分解，有如下選擇：

#R1	#R2
ASIL C(C)	QM
ASIL B(C)	ASIL A(C)
ASIL A(C)	ASIL B(C)
QM	ASIL C(C)

但是這兩條需求背后的safety machanism都是車速監控，因此車速的計算邏輯是分解成立與否的關鍵。接下來就接著這個例子進行發散。

2.2. 參與ASIL分解的要素間是否充分獨立？

問：假設#R1和#R2對應的車速監控使用的是同一個輪速傳感器計算得到的車速信號，分解是否成立？

答：不成立。

ASIL分解本質概念是冗余，冗余就要求不存在共因失效或者級聯失效導致互為冗余的元素同時失效。

①. 共因失效Common Cause Failure (CCF)

一個相關項中，由一個單一特定事件或根本原因引起的兩個或多個要素的失效。Failure of two or more elements of an item resulting directly from a single specific event or root cause which is either internal or external to all of these elements.

你真的做對ASIL分解了嗎？的圖4

共因失效圖示，截圖來自ISO 26262, 2018, part1

②. 級聯失效 cascading failure

同一個相關項中，一個要素的失效引起另一個或多個要素的失效。failure of an element of an item resulting from a root cause [inside or outside of the element] and then causing a failure of another element or elements of the same or different item.

你真的做對ASIL分解了嗎？的圖5

級聯失效圖示，截圖來自ISO 26262, 2018, part1

如果參與分解的要素之間存在共因失效或者級聯失效，說明要素之間相互影響而不是相互獨立，ASIL分解將不成立。

回到開頭的問題，如果兩個車速監控都使用的是同一個輪速傳感器計算，那么輪速傳感器失效將直接導致這兩個safety machanism同時失效，存在共因失效，因此分解不成立。

如何確定獨立性呢？ISO 26262要求對于使用ASIL分解的功能安全概念，必須要通過相關失效分析(DFA, Dependent Failure Analysis)證明分解后的相關元素間相互獨立，即證明系統既不存在級聯失效，也不存在共因失效。

2.3. 參與ASIL分解的要素間是否存在同構冗余？

問：假設#R1和#R2的車速監控分別使用兩個輪速傳感器，但兩個輪速傳感器是同一個廠家的同一個型號，分解是否成立？

答：不成立。

ISO 26262, part9對這種情況進行了說明：

使用同構冗余(如通過復制設備或復制軟件)的情況下，考慮到硬件和軟件的系統性失效，不能降低ASIL等級，除非相關失效的分析提供了存在充分獨立性或潛在共因指向安全狀態的證據。因此，同構冗余因缺少要素間的獨立性，通常不足以降低ASIL等級。

如何理解這句話呢？功能安全開發的目標本質上就是將系統的系統性失效和隨機硬件失效控制在合理范圍內，而ASIL分解的目的是降低對安全相關的要素的系統性失效要求，從而降低功能安全開發成本。系統性失效是以確定的方式產生的失效，造成這類失效的系統性故障是設計或生產流程、操作規程、文檔或其他相關因素導致的，一旦故障存在，則系統性失效100%會發生。比如軟件開發工程師人為誤寫的一個bug，每次程序運行bug對應的代碼100%會輸出錯誤的結果。又比如硬件開發工程師錯誤地在手冊中將“5Ω”的電阻寫成了“50Ω”，生產出的硬件也必然是錯誤的。

回到問題上，如果兩個輪速傳感器是同一個廠家的同一個型號的傳感器，也就意味著它們的開發與生產過程完全一樣，如果在這個過程中產生了系統性失效的話，兩個傳感器的系統性失效也是一模一樣的，同樣缺少要素間的獨立性，因此無法進行ASIL分解。

2.4. 如何給參與ASIL分解的要素提功能安全需求？

假設#R1的車速監控使用輪速傳感器，#R2的車速監控使用變速箱軸速傳感器，兩個傳感器滿足獨立性要求，因此采取ASIL B(C)和ASIL A(C)的分解方式。接下來要對傳感器的供應商提功能安全要求。

問題：下面兩種釋放給供應商的功能安全要求是一樣的嗎？

case1: 輪速傳感器要求ASIL B(C)，軸速傳感器要求ASIL A(C)
case2: 輪速傳感器要求ASIL B，軸速傳感器要求ASIL A

實際上這兩個case的需求是不同的，且這里直接宣布結論：case2的功能安全需求會造成對隨機硬件失效要求的遺漏，必須避免！

前文中提到，ASIL分解的目的是降低對安全相關的要素的ASIL等級要求，而關于ASIL分解對隨機硬件失效的影響，ISO 26262, part9明確指出：

The requirements on the evaluation of the hardware architectural metrics and the evaluation of safety goal violations due to random hardware failures in accordance with ISO 26262-5 shall remain unchanged by ASIL decomposition. （針對隨機硬件失效的要求，包括硬件架構度量的評估和由于隨機硬件失效導致違背安全目標的評估，在ASIL分解后仍保持不變。）

拿變速箱軸速傳感器來說，ASIL A和ASIL A(C)的區別在于：

ASIL A：系統性失效的要求和隨機硬件失效要求均為ASIL A
ASIL A(C)：系統性失效的要求為ASIL A，隨機硬件失效要求為ASIL C

根據ISO 26262對隨機硬件失效的要求，ASIL A的隨機硬件失效是沒有指標要求的，說白了就是沒有要求。也就是說，直接給變速箱軸速傳感器供應商提ASIL A要求，供應商完全可以忽略對變速箱軸速傳感器的隨機硬件失效的要求，這顯然是不合理的，只有當給供應商分配ASIL A(C)時隨機硬件失效要求才會被考慮。

在這里還有一點需要強調，由于冗余的存在，此時變速箱軸速傳感器的單點故障是整個系統的潛伏故障（輪速傳感器和變速箱軸速傳感器同時失效才會造成ASIL C的風險）。因此對于變速箱軸速傳感器供應商而言，只需要按照下表5而不是下表4來進行開發，對傳感器單點故障監控的度量只需要滿足“≥80%”的指標而不是“≥97%”的指標。

你真的做對ASIL分解了嗎？的圖6