本文要點：在上一期（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%”。
下期預告
先前提到，相關失效分析(DFA, Dependent Failure Analysis)主要确認在功能安全設計中充分實作了所需的獨立性(independence)或不受幹擾的能力(freedom from interference)。本文介紹了ASIL分解的基本原理以及關鍵點，下期将對“不受幹擾的能力”展開說明。