本文要點：在上一期（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等級的裁剪方法，這一方法的核心點是通過將一條功能安全需求分解成兩條相互獨立的需求并分配到兩個及兩個以上相互獨立的元素（如軟件模塊、硬件模塊、輸入信號等）上。

正是由于這些參與分解的獨立的元素之間構成了互為冗余關系，從整個系統的角度看，只有當這些元素同時發生失效時才會違背安全目標，這樣一來對每個參與分解的相關元素的功能安全要求可以降低。

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分解標記示例

在ISO 26262, part9第5章中也對ASIL分解原則給出了說明，總結如下。

ASIL D分解

---

以下三種分解方式均可：

• 一個ASIL C(D)的要求和一個ASIL A(D)的要求；或

• 一個ASILB(D)的要求和一個ASIL B(D)的要求；或

• 一個ASIL D(D)的要求和一個QM(D)的要求。

QM即Quality Management，表示只要按照企業質量管理流程開發就可以滿足ISO 26262要求，沒有其他特殊功能安全要求。下同。

ASIL C分解

---

以下兩種種分解方式均可：

• 一個ASIL B(C)的要求和一個ASIL A(C)的要求;或

• 一個ASILC(C)的要求和一個QM(C)的要求。

ASIL B分解

---

以下兩種種分解方式均可：

• 一個ASIL A(B)的要求和一個ASIL A(B)的要求;或

• 一個ASILB(B)的要求和一個QM(B)的要求。

ASIL A分解

---

一個ASIL A 的要求不應被進一步分解,除非需要分解成一個ASIL A(A)的要求和一個QM(A)的要求。

2.ASIL分解的關鍵點

功能按照發展有些年頭了，和E/E系統打交道的開發人員經過耳濡目染幾乎都對ASIL分解略知一二，但是可能存在一些理解上的偏差。基于此，接下來對2個最容易被忽略的關鍵點展開說明。

2.1. ASIL分解要求元素間充分獨立

ASIL分解本質概念是冗余，冗余就要求不存在共因失效或者級聯失效導致互為冗余的元素同時失效。因此ISO 26262要求，對于使用ASIL分解的功能安全概念，必須要通過DFA證明分解后的相關元素間相互獨立。

ISO 26262, part9對冗余進行了說明：

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

比如對于EPB系統來說，如果在車輛高速運行時錯誤拉起（一邊）卡鉗，那么最嚴重的情況會造成車輛失穩。因此EPB系統需要滿足如下安全目標：

SG: EPB應避免在車速V>10kph時錯誤拉起卡鉗，ASIL D

為實現這一安全目標，對正確判斷車速有ASIL D的要求。假設車速計算依賴于輪速傳感器輸入，因此safety concept設計如下。

這個分解成立的前提是兩個輪速信號充分獨立，如果兩個輪速傳感器是同一個供應商的同一批次的傳感器，實際上屬于同構冗余，以上分解不成立。

2.2. ASIL分解是如何降低功能安全開發要求的？

前面提到，ASIL分解的目的是降低對安全相關的元素的ASIL等級要求，從而降低功能安全開發成本。而ASIL等級背后的要求包括對系統性失效和隨機硬件失效的要求。那么ASIL分解以后對系統性失效和隨機硬件失效的具體影響是什么呢？要回答這個問題，需要先回顧ISO 26262對這兩類失效的要求。

ISO 26262對系統性失效的要求存在于各個層級，包括硬件元器件層(HW part level)、軟件單元層(SW-Unit level)、組件層(compenent level)、系統層(system level)和相關項層(item level)。同時對系統性失效的要求本質上就是對設計流程和驗證(測試)流程的要求。

產品層級劃分

為了更好地理解上面的解釋，依舊以2.1中提及的EPB系統Safety Goal為例，假設為了實現這條Safety Goal，EPB系統的功能架構和safety concept設計如下，其中車速計算依賴互為冗余且充分獨立的輪速傳感器和變速箱軸速傳感器，各自分配ASIL B(D)的要求。

對于系統性失效而言，有如下功能要求：

1.車速計算模塊需要滿足ASIL D的軟件開發流程；

2.EPB系統的集成測試需要滿足ASIL D的測試要求；

3.輪速傳感器和電機轉速傳感器的開發流程需要滿足ASIL B的開發流程要求和測試要求。

而對隨機硬件失效而言， 我們知道ISO 26262要求從以下三個方面的指標衡量隨機硬件失效：

?單點故障度量（single-point fault metric, SPFM）

?潛伏故障度量（Latent fault metric, LFM）

?隨機硬件失效概率度量( Probabilistic Metric for random Hardware Failures，PMHF)

而關于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等級都應該是分解前的值。

但是，同樣的ASIL等級，其背后對應的要求在不同層級是不一樣的。我們接著上面的案例進一步分析。

站在將EPB系統看作一個整體的角度，系統的隨機硬件失效指標應滿足如下要求：

1.SPFM≥99%

2.LFM≥90%

3.PMHF＜10 FIT

注： 此處PMHF的要求的前提是EPB系統是全新開發的系統，沒有上一代產品的PMHF值作為對比，具體原因見第14期EPB功能安全筆記(14)：FTA定量分析之ISO26262對隨機硬件失效的要求）

其中，PMHF是一個item level的指標，只有將EPB系統作為一個整體才能分析，但是，對于兩外兩個指標SPFM和LFM而言，即使ASIL等級不變，對部件的隨機硬件失效要求實際上被降低了。

比如對上圖中的電機轉速傳感器來說，雖然對電機傳感器的隨機硬件失效仍然要滿足繼承于Safety Goal的ASIL D的要求，但是電機傳感器故障不會直接造成EPB系統直接違背安全目標，換句話說，對EPB系統而言，電機傳感器的單點故障是系統的潛伏故障。因此，對電機傳感器的SPFM要求應該根據系統層對潛伏故障度量的ASIL D的要求來定義，而不是系統層的對單點故障度量的ASIL D的要求來定義，這樣一來要求從“不低于99%”降低為“不低于90%”。