采編 | 一驥絕塵
本文要點
ASIL等級是功能安全需求的核心屬性之一，也是我們在進行功能安全開發過程中被提及最頻繁的詞之一。在功能安全的討論中經常充斥著諸如 “這款ECU最高支持什么ASIL等級？” 、“XX信號能否滿足ASIL D？”之類的問題。但是，當反問一句“ASIL D到底意味著什么需求？”時，提問者未必能夠給出很好的答案。
“ASIL D到底意味著什么需求？”這是一個非常好的問題，既是一個功能安全剛入門的工程師會暗自發問的一個問題，同時也可以檢驗一個工程師對于功能安全的基本理解是否到位。本文將試圖對這個問題給出答案。受限于筆者水平和文章篇幅，這個答案不會是全面而深入的，但是應該至少可以給功能安全剛入行的工程師一些參考。
1. ASIL等級從何而來？
ISO 26262中對 “Functional Safety 功能安全” 的定義如下：
absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.（不存在由電子電氣系統的功能異常表現引起的危害而導致不合理的風險）
從中可以看出，功能安全追求的是將風險控制在合理的范圍內。這意味著必須首先確定哪些風險是合理的，那些風險是不合理的。ISO 26262將這一活動定義為“危害分析與風險評估。”
step1: 確定相關項所有功能異常所有行為可能導致的整車危害。
在這一過程中需要注意：應以能在整車層面觀察到的條件或行為來定義危害。那么既然是以整車層面觀察到的行為來定義危害，首先需要了解車輛所有可能的運動行為。從整車動力學的角度，汽車所有的運動行為可以通過下圖中的運動坐標系來準確描述。
而在每一個坐標系上，因為控制不當而可能產生的所有的整車表現也能被界定。思路如下圖所示。
step2: 結合危害和場危害發生時刻車輛運行的場景來分析風險。
這一步驟對應“危害事件分類（Classification of hazardous events）”
舉例來說，和制動控制相關的ESC系統（電子穩定性系統，Electric Stability Controller）存在一個危害：ESC錯誤建立輪缸壓力導致車輛產生非預期的制動。如果這個危害發生在高速公路上時，很可能造成人員傷亡；但是如果危害僅僅發生在車速低于10kph的停車場，則不會有造成人員傷亡的風險。
從這個角度，功能安全需要結合危害和危害發生時刻車輛運行的場景來綜合分析危害所導致的風險是否在可接受的范圍內。車輛的運行場景，可以理解為是下圖各個因素的排列組合。簡單來說，運行場景 = 道路場景 + 駕駛場景，比如“高速公路+直行加速”或者“高速公路+直線制動”等。
當列出了相關項的所有場景與危害的組合后，接下來就是對其進行分類和篩選，確定哪些風險是可接受的，哪些是不可接受的。ISO 26262從三個維度來進行分類和篩選：
1. S（severity 嚴重度）：
危害發生對駕駛員或乘客或路人或周邊車輛中人員會造成的傷害等級。
2. E（Exposure 曝光度）：
運行場景在日常駕駛過程中發生的概率。
3. C（controllability 可控度）：
駕駛員或其他涉險人員控制危害以避免傷害的概率。
通過這三個維度的綜合評分確定汽車安全完整性等級（ ASIL, automotive safety integrity level），如下圖所示。ASIL D代表最高嚴格等級，ASIL A 代表最低嚴格等級。QM（quality management）則意味著只要按照企業流程開發就可以滿足ISO 26262要求，無其他特殊要求。
總結
ASIL等級通過危害分析與風險評估這一功能安全活動而來。通過對危害事件進行S/E/C三個維度的評估從而確定風險的ASIL等級
對每個具有ASIL等級的危害事件都導出一條Safety Goal，ASIL等級是Safety Goal的基本屬性
ASIL等級越高，危害事件造成的不合理的風險越大，因此功能安全開發要求也會越高
2. ASIL D到底在要求什么？
當確定了一條完整的Safety Goal，同時Safety Goal對應的safety criteria確定以后，接下來將基于系統架構識別出可能違背Safety Goal的系統要素（軟件或硬件），從而對相應的要素分配功能安全需求，（在無法進行分解的情況下）這些功能安全需求都將繼承Safety Goal的ASIL等級。ASIL等級越高，意味著功能安全開發的要求越嚴苛。
那么將引出本文開頭的問題，當一條功能安全需求定義為ASIL D時，到底在要求什么？相比ASIL A或ASIL B，ASIL D的需求“嚴苛”體現在哪里？
要回答這個問題，還需要回到ISO 26262中對 “Functional Safety, 功能安全”的定義中。
absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.（不存在由電子電氣系統的功能異常表現引起的危害而導致不合理的風險）
這次我們將目光聚焦在“功能異常表現”上。ASIL D意味著功能異常表現能導致的風險最高，那么反過來對功能開發的要求最嚴苛以避免異常表現。
2.1. 功能異常是如何發生的？
在確定如何避免功能異常表現之前，需要先搞清楚功能異常是如何發生的。
如果借助ISO 26262第10部分的說明圖，我們很容易得出以下結論：
故障導致失效的示例，截圖來自GB/T 34590, 第10部分
系統要素（軟件或硬件）的三類故障最終可能引起系統的失效從而引起功能異常而導致風險：
對于前兩類統稱為系統性故障，由它們導致的失效則稱為“系統性失效”。后者則導致“隨機硬件失效”。下面就這兩類失效展開說明。
系統性失效（systematic failure）：以確定的方式與某個原因相關的失效，只有對設計或生產流程、操作規程、文檔或其他相關因素進行變更后才可能排除這種失效。
1) 確定的方式：不同于隨機硬件失效的不可預知性，系統失效的形式是確定的，只要滿足相應條件就一定會發生。從另一個角度，系統性失效是可以復現的。
2) 排除：當找到造成失效的確定方式后，可以采取對應的措施（如修復軟件bug，完善軟件開發流程等）有效避免系統性失效。
隨機硬件失效(random hardware failure)：在硬件要素的生命周期中，非預期發生并服從概率分布的失效。
1) 硬件要素：只有硬件才會產生這類失效，軟件不會。
2) 非預期：盡管硬件的設計完全正確的，元器件也是符合質量標準的。但是卻無法預知的故障，無法預知在哪里發生，以怎樣的形式發生。
3) 服從概率分布：雖然失效的發生是非預期的，但是失效率可以在合理的精度范圍內進行預測。也就是說硬件隨機失效是可以進行定量評估的。
2.2. 如何將功能異常控制在可接受的范圍內？
實際上需要先澄清，世界上沒有100%安全的產品，功能異常不可能100%避免。功能安全追求的是將功能異常的可能性控制在可接受的范圍內。
而通過上節我們可以得出結論：將功能異常控制在可接受的范圍內，本質上就是將系統性失效和隨機硬件失效控制在可接受的范圍內。
2.2.1. 控制系統性失效
對于系統性失效而言，如果結合“V模型”開發來看，控制系統性失效主要就是兩點：
在“V模型”左邊設計階段考慮盡可能周到
在“V模型”右邊驗證階段驗證盡可能完善
進一步地，保證“左邊設計階段考慮盡可能周到”，既體現在對開發者的要求上，也體現在對審核過程的要求上。
拿ISO 26262中對軟件開發中的軟件架構設計原則的要求舉例，這些方法使用越多，軟件架構設計出現的系統性失效必然越低。“++”表示強烈推薦， ASIL等級越高對這些方法的推薦度也越高。
同樣地，在審核軟件架構設計的過程中，采用“對設計中的動態部分進行仿真”顯然比“設計走查”更能避免系統性失效。相比其他ASIL等級，ASIL D對以下方式的推薦度最高。
為保證“右邊驗證階段驗證盡可能完善”，拿軟件集成測試舉例，顯然下表中的方法貫徹地越多，對避免軟件集成的系統性失效效果越好。相比其他ASIL等級，ASIL D對以下方式都強烈推薦。
2.2.2. 控制隨機硬件失效
ISO 26262中從兩個方面對隨機硬件失效提出了要求：
1. 硬件架構度量的評估(Evaluation of the hardware architectural metrics)
2. 隨機硬件失效導致違背安全目標的評估(Evaluation of safety goal violations due to random hardware failures)
簡單來說，硬件架構度量用來評估相關項的架構應對隨機硬件失效時的有效性。這些度量所針對的隨機硬件失效僅限于相關項中某些安全相關電子和電氣硬件元器件，即那些能對安全目標的違背或實現有顯著影響的元器件，并限于這些元器件的單點故障、殘余故障和潛伏故障。
單點故障度量（single-point fault metric）
單點故障度量反映了相關項通過安全機制覆蓋或通過設計手段(主要為安全故障) 實現的對單點故障和殘余故障的魯棒性。高的單點故障度量值意味著相關項硬件的單點故障和殘余故障所占的比例低，系統可靠性更高。
單點故障度量的計算
式中分母即安全相關的失效率總和。單點故障度量公式圖示如下。
ISO 26262對單點故障度量的要求
ISO 26262中對單點故障度量的要求如下，對ASIL A的安全目標沒有要求，對ASIL B的安全目標沒有強制要求，對ASIL C和ASIL D的安全目標有強制要求。
潛伏故障度量
潛伏故障度量反映了相關項通過安全機制覆蓋、通過駕駛員在安全目標違背之前識別或通過設計手段(主要為安全故障)實現的對潛伏故障的魯棒性。高的潛伏故障度量值意味著硬件的潛伏故障所占的比例低，系統可靠性更高。
潛伏故障度量的計算
式中分母即安全相關的失效率總和。潛伏故障度量公式圖示如下。
ISO 26262對潛伏故障度量的要求
ISO 26262中對潛伏故障度量的要求如下，對ASIL A的安全目標沒有要求，對ASIL B的安全目標沒有強制要求，對ASIL C和ASIL D的安全目標有強制要求。
隨機硬件失效導致違背安全目標的評估
簡單來說，對隨機硬件失效導致違背安全目標的評估是用來確定違背安全目標的殘余風險已經足夠低。ISO 26262對這一評估推薦了兩個方法：
第一個方法包括使用概率的度量,即“隨機硬件失效概率度量”( Probabilistic Metric for random Hardware Failures，PMHF)，通過使用例如定量故障樹分析(FTA)及將此計算結果與目標值相比較的方法，評估是否違背所考慮的安全目標。
第二個方法包括獨立的評估每個殘余和單點故障，及每個雙點失效是否導致違背所考慮的安全目標。
因為在實際開發中所有的公司幾乎都使用PMHF，所以本文只對PMHF展開說明，感興趣的朋友可以參考ISO 26262，part5了解第二種方法。
PMHF表示在汽車運行周期中每小時平均失效概率。ISO 26262對PMHF的要求如下，從表格中可以看出兩點：
2. PMHF對ASIL C和ASIL B的要求一樣，同時與ASIL D的要求差一個數量級。
