如何理解ASIL分解?

汽車電子 時間:2022-05-09來源:汽車ECU開發

編者按:接觸功能安全的讀者一定對ASIL分解不陌生,都知道ASIL B(D)意味著原本需求為ASIL D,分解成了ASIL B,從而降低功能安全開發難度。但是如果繼續追問則是一知半解,比如: ASIL分解的原則是什么? 進行ASIL分解需要滿足什么條件? ASIL分解到底如何降低了功能安全開發難度? 本文試圖對這些問題進行回答,在介紹分解原則的同時指出其中的關鍵點,拋磚引玉,希望能給讀者帶來一些參考。

作者 |小青的風箏

1、什么是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)”。

2、ASIL分解的原則?

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

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

1. ASIL D分解可選擇以下任意一種方式

2. ASIL C分解可選擇以下任意一種方式

3. ASIL B分解可選擇以下任意一種方式

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

ASIL分解原則,截圖來自ISO 26262-2018, part9

3、進行ASIL分級需要滿足什么條件?

進行ASIL分解最重要的前提是參與ASIL分解的元素間充分獨立。

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

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

比如下面的例子,如果兩個輪速傳感器WSS(Wheel Speed Sensor)是同一個供應商的同一批次的傳感器,實際上屬于同構冗余,分解不成立。

4、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要求從以下三個方面的指標衡量隨機硬件失效:

而關于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分解后仍保持不變。)

這個背后是因為ISO 26262對隨機硬件失效的要求是站在將相關項(item)作為一個整體的角度來評估的,通過計算系統整體的隨機硬件失效指標(SPFM、LFM、PMHF)來確定系統的Safety Goal是否滿足要求。

同時這也意味著不論是哪一個層級,對隨機硬件失效要求的ASIL等級都應該是分解前的值。

舉個例子,駕駛員在車輛靜止時可以通過按鈕激活某舒適性功能,但是如果在車速大于10kph時錯誤激活,有造成ASIL D危害的風險。該功能由ECU A實現,需要在激活該功能前正確判斷車速,當車速高于10kph時禁止激活。

ECU A的系統架構如下:

safety concept分析如下圖所示。車速計算依賴互為冗余且充分獨立的輪速傳感器和變速箱軸速傳感器。

無論對輪速和變速箱軸速的需求是下列哪一種分配:

對于ECU A這個整體而言,隨機硬件失效要求都要符合ISO 26262, part5中對下面三個指標的ASIL D的要求。

上面的例子驗證了:

無論在哪一個層級,對隨機硬件失效要求的ASIL等級都應該是分解前的值。

但是,不同的層級ASIL等級都繼承分解前的ASIL等級,那么ASIL等級背后的要求也一樣一樣嗎?

答案是否定的。

如果我們站在組成系統的部件的角度,拿上面的輪速傳感器舉例,對輪速傳感器的需求是ASIL B(D),那么對輪速傳感器的單點故障度量SPFM滿足分解前的ASIL D的要求。

但是,站在系統層的角度,只有當輪速傳感器和變速箱軸傳感器同時發生故障時,才會導致功能產生ASIL D的危害。也就是說,輪速傳感器的單點故障是系統層的潛伏故障。此時,對輪速傳感器的單點故障度量SPFM的要求不是表1而是表2,要求從≥99%降低到了≥90%。

綜上,我們可以做出如下總結:

ASIL分解可以降低系統中不同層級的元素(如軟件、硬件等)的系統性失效要求ASIL分解無法降低相關項(item)作為一個整體的隨機硬件失效要求,即分解前后對相關項的SPFM、LFM和PMHF要求都不變ASIL分解可以降低相關項的某個component的隨機硬件失效要求,準確地說是降低了對部件的SPMF和LFM的要求 (注:對PMHF是item level相關項層級的要求,在component層面不做考慮)

關鍵詞: ASIL

加入微信
獲取電子行業最新資訊
搜索微信公眾號:電子產品世界

或用微信掃描左側二維碼

相關文章


用戶評論

請文明上網,做現代文明人
驗證碼:
查看電腦版
97超碰中文字幕久久精品_美女国产诱a惑v在线观看_四虎免费在线观看_中文字幕亚洲第一页乱码