2023-10-20 Share: 如何理解ASIL分解
Local Backup
- 接觸功能安全的讀者一定對ASIL分解不陌生，都知道ASIL B(D)意味著原本需求為ASIL D，分解成了ASIL B，從而降低功能安全開發難度。但如果繼續追問則是一知半解，例如：
- 1. ASIL分解的原則是什麼？
- 2. 進行ASIL分解需要滿足什麼條件？
- 3. ASIL分解到底如何降低了功能安全開發難度？
- 本文試圖對這些問題進行回答，在介紹分解原則的同時指出其中的關鍵點
一、什麼是ASIL分解？
- 軟體工程師可能經常遇到這樣一個場景：在進行功能安全開發時，Safety Goal的ASIL等級太高，輸入訊號無法滿足要求。對於這種情況，ISO 26262提供了一個特殊的裁剪方法以降低對功能安全需求的ASIL等級，即「ASIL分解」。
- 此方法的核心點是透過將一條功能安全需求分解成兩個相互獨立的需求並分配到兩個及兩個以上相互獨立的元素（如軟體模組、輸入訊號等）上。由於冗餘的存在，對每個分解後的相關元素的ASIL等級要求可以降低。
- ASIL分解有特定的標記方式。ISO 26262, part9第5章要求：
- 應透過在括號中給出安全目標的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分解的原則？
- 而對於ASIL分解原則，在ISO 26262, part9第5章中也給出了說明，現總結如下。
- 註：以下提到的QM即“Quality Management”，表示只要按照企業品質管理流程開發就可以滿足ISO 26262要求，沒有其他特殊功能安全要求。
- 1. ASIL D分解可選擇以下任一種方式
- 一個ASIL C(D)的要求和一個ASIL A(D)的要求；或
- 一個ASIL B(D)的要求和一個ASIL B(D)的要求；或
- 一個ASIL D(D)的要求和一個QM(D)的要求。
- 2. ASIL C分解可選擇以下任一種方式
- 一個ASIL B(C)的要求和一個ASIL A(C)的要求;或
- 一個ASIL C(C)的要求和一個QM(C)的要求。
- 3. ASIL B分解可選擇以下任一種方式
- 一個ASIL A(B)的要求和一個ASIL A(B)的要求;或
- 一個ASIL B(B)的要求和一個QM(B)的要求。
- 4. 一個ASIL A 的要求不應被進一步分解,除非需要分解成一個ASIL A(A)的要求和一個QM(A)的要求。
ASIL分解原則，截圖來自ISO 26262-2018, part9
三、進行ASIL分解需要滿足什麼條件？
- 進行ASIL分解最重要的前提是參與ASIL分解的元素間充分獨立。
- ASIL分解本質概念是冗餘，冗餘就要求不存在共因失效或級聯失效導致互為冗餘的元素同時失效。因此ISO 26262要求，對於使用ASIL分解的功能安全概念，必須透過相關失效分析(DFA, Dependent Failure Analysis)證明分解後的相關元素間相互獨立。
- 同時，ISO 26262也指出，使用同構冗餘(如透過複製設備或複製軟體)的情況下,考慮到硬體和軟體的系統性失效，不能降低ASIL等級，除非相關失效的分析提供了存在充分獨立性或潛在共因指向安全狀態的證據。因此，同構冗餘因缺乏要素間的獨立性，通常不足以降低ASIL等級。
- 例如下面的例子，如果兩個輪速感測器WSS(Wheel Speed Sensor)是同一個供應商的同一批次的感測器，實際上屬於同構冗餘，分解不成立。
四、ASIL分解如何降低了功能安全開發難度？
- 本質上每個功能安全需求的ASIL等級屬性的背後是對系統性失效和隨機硬體失效的要求。
- 在下文中對兩類失效進行過比較。
- 隨機硬體失效(random hardware failure)：在硬體要素的生命週期中，非預期發生並服從機率分佈的失效。
- 系統性失效（systematic failure）：以確定的方式與某個原因相關的失效，只有在設計或生產流程、操作規程、文件或其他相關因素後才可能排除此失效。
隨機失效與系統性失效- 從ISO 26262的要求來看，ISO 26262對系統性失效和隨機硬體失效的要求有明顯的差異。
對系統性失效的要求
- ISO 26262對系統性失效的要求存在於相關項目的各個層級，硬體元件層(HW part level)、軟體單元層(SW-Unit level)、元件層(component level)和系統層(system level)都有各自對應的要求。而且同時上面系統性失效的定義可以看出，ISO 26262對系統性失效的要求本質上可以理解為對設計流程和驗證流程的要求。
層級劃分圖示- 這樣一來，ASIL分解後的需求被分配到組成相關項整體中的某個（些）元素上，對於這些元素的系統性失效要求降低了。
- 舉個軟體元素的例子，如下圖所示，分解前對軟體模組A的要求為ASIL D。
- 而分解以後對軟體模組A的要求降低為ASIL B(D)。
- 在分解之前，模組A需要遵循ASIL D的要求來開發以限制系統性失效；而分解後只需要按照ASIL B的要求來限制系統性失效，從而降低了開發難度和開發成本。拿對模組A軟體單元的測試要求來說，從下圖可以看出，ASIL B的要求比ASIL D更加寬鬆了。
對隨機硬體失效的要求
- 對隨機硬體失效而言， 我們知道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 deposition。和由於隨機硬體失效導致違反安全目標的評估，在ASIL分解後仍保持不變。）
- 這個背後是因為ISO 26262對隨機硬體失效的要求是站在將相關項（item）作為一個整體的角度來評估的，透過計算系統整體的隨機硬體失效指標（SPFM、LFM、PMHF）來確定係統的Safety Goal是否符合要求。
- 同時這也意味著不論是哪一個層級，對隨機硬體失效要求的ASIL等級都應該是分解前的值。
- 舉個例子，駕駛員在車輛靜止時可以透過按鈕激活某舒適性功能，但是如果在車速大於10kph時錯誤激活，有造成ASIL D危害的風險。此功能由ECU A實現，需要在啟動該功能前正確判斷車速，當車速高於10kph時禁止啟動。
- ECU A的系統架構如下：
- safety concept分析如下圖所示。車速計算依賴互為冗餘且充分獨立的輪速感知器和變速箱軸速感知器。
- 無論對輪速和變速箱軸速的需求是下列哪一種分配：
- 輪速ASIL A(D); 變速箱軸速ASIL C(D)
- 輪速ASIL B(D); 變速箱軸速ASIL B(D)
- 輪速ASIL C(D); 變速箱軸速ASIL A(D)
- 對於ECU A這個整體而言，隨機硬體失效需求都要符合ISO 26262, part5中對下面三個指標的ASIL D的要求。
- SPFM≥99%
- LFM≥90%
- PMHF＜10 FIT
- 上面的例子驗證了：
- 無論在哪一個層級，隨機硬體失效要求的ASIL等級都應該是分解前的值。
- 但是，不同的層級ASIL等級都繼承分解前的ASIL等級，那麼ASIL等級背後的要求也一樣嗎？
- 答案是否定的。
- 如果我們站在組成系統的部件的角度，拿上面的輪速感知器舉例，對輪速感知器的需求是ASIL B(D)，那麼對輪速感知器的單點故障度量SPFM滿足分解前的ASIL D的要求。
- 但是，站在系統層的角度，只有當輪速感知器和變速箱軸感知器同時發生故障時，才會導致功能產生ASIL D的危害。也就是說，輪速感知器的單點故障是系統層的潛伏故障。此時，對輪速感知器的單點故障度量SPFM的要求不是表1而是表2，要求從≥99%降低到了≥90%。
表1
表2- 綜上，我們可以做以下總結：
- ASIL分解可以降低系統中不同層級的元素（如軟體、硬體等）的系統性破壞需求
- ASIL分解無法降低相關項（item）作為一個整體的隨機硬體失效要求，即分解前後對相關項的SPFM、LFM和PMHF要求都不變
- ASIL分解可以降低相關項的某個component的隨機硬體失效要求，準確地說是降低了對部件的SPMF和LFM的要求（註：對PMHF是item level相關項層級的要求，在component層面不做考慮）
一些評論
- 2022-04-03
- PMHF是一個獨立的item層級的指標（如ESP, EPS等），衡量的是item整體的指標，即對應你這裡提到的「分解前」的指標。FMEDA不區分層級，item或item中某個element（如EPS μC）都可以進行FMEDA，只要給到element的功能安全需求確定，需求是否已經參與分解都不影響FMEDA的開展，只有在確定FMEDA的結果的評估指標時才會考慮是否有分解
- 2021-02-20
- 輪速感知器的單點故障是系統層的潛伏故障。此時，對輪速感知器的單點故障度量SPFM的要求不是表1而是表2，要求從≥99%降低到了≥90%。—寫得很到位了。每次遇到這個問題，都想重複個人的理解。
- 分解後：
- 1）item/system level的SPFM/LFM metrics要求保持不變；
- 2）針對此ASIL D SG的PMHF,EEC metrics要求保持不變；
- 3）Verification要求保持ASIL D不變
- 即，WSS失效模式FIT值的計算在FMEDA中從against ASIL D SPF變為against ASIL D LFM，從而放寬了WSS隨機硬體失效要求的要求。
- 2021-05-14
- 隨機硬體失效要求的ASIL等級都應該是分解前的值”，其原因除了題主所說的硬體架構指標是從item整體的角度來定義的，更背後的原因是：若硬體也實作ASIL分解，雖然可以確保每個獨立的part符合架構指標，但整體的架構指標有可能會不滿足。具體見如下論文的闡述：ISO26262中硬體隨機失效度量指標(PMHF)的分解
- 2021-06-29
- 寫的挺好的，讚一個，不過最後對輪速感知器的單點故障度量要求的說法不認同，按潛伏降低到90%只是因為B（D）+B（D）的組合，恰巧跟ASIL B的SPFM對應上了，假設原始分解是A(D)+C(D)的組合且輪速感知器為A（D），輪速感知器要求單點故障90%就不合理了
- 2022-04-03
- 你選擇「A+C.也可以B+B，也可以D+QM」的依據是參與分解的component的實際ASIL能力。例如當某個感測器只有ASIL A的能力時，那麼你就必須只能選擇A+C或D+QM
- 2021-02-25
- 軟體失效或說軟體錯誤的來源有三：
- 1.需求規格錯誤。舉個例子：NASA的火星極地軌道飛行器與行星發生碰撞，原因就是子系統同時有英里和千米的單位。
- 2、軟體系統設計錯誤。主要是邏輯的正確性和完整性。
- 3.程式碼生成錯誤。例如符號遺漏、未宣告的變數、儲存單元的意外共用等。
- 軟體的共因主要有3種：
- 1.共同的需求，即多個軟體模組是基於共同的需求開發。
- 2.共同的演算法，多個硬體產品被一個包含有控制演算法的單獨或共同的軟體模組所驅動。
- 3.共同的數據，多個硬體產品由一個單獨或共同的軟體模組提供數據。
- 我個人覺得即使按照最高的等級去設計測試驗證確認，軟體的失效模式也不能說消除了，可以說降低了其發生的機率。所以軟體的共因想消除的確是個難題。
TAGS
- 145 person(s) visited this page until now.