原文：ASIL Decomposition: The Good, the Bad, and the Ugly

作者：Agish George, Jody Nelson

翻譯：郭金、徐銥銥

譯文審核：湯黎超

ASIL分解是ISO 26262標(biāo)準(zhǔn)中描述的一種將ASIL分解給冗余需求的方法。雖然ASIL分解似乎與IEC 61508-2的硬件容錯概念有類似的意圖，但ASIL分解的目的不是為了減少ASIL分配至硬件元素的隨機(jī)硬件故障，而是專注于系統(tǒng)性失效情況下的功能和需求。根據(jù)我們參與標(biāo)準(zhǔn)制定的情況，該方法在實(shí)踐中被以不同的方式應(yīng)用，并非所有的方法都與標(biāo)準(zhǔn)的意圖完全一致。兩個潛在可能導(dǎo)致使用 "修改過的 "ASIL等級”的原因包括：OEM廠商需要對系統(tǒng)進(jìn)行分割并向供應(yīng)商指定子系統(tǒng)需求，以及設(shè)計者需要自下而上的構(gòu)建系統(tǒng)。自下而上構(gòu)建系統(tǒng)的目標(biāo)是，從已有的一些ASIL概念組件元素中實(shí)現(xiàn)目標(biāo)系統(tǒng)級的ASIL。在本文中，我們研究了ASIL分解在ISO 26262標(biāo)準(zhǔn)中的起源和該方法潛在的好處和局限性，以及通過查閱關(guān)于這個主題的論文，去探究它目前是如何被應(yīng)用于工業(yè)項(xiàng)目中。

01、引言

分解和分配需求的任務(wù)是系統(tǒng)工程眾所周知的一部分。一個系統(tǒng)級的需求要么被直接分配給系統(tǒng)的一個組件，要么被分解（分割）成子需求，這些子需求被分配給不同的組件。在后一種情況下，每個子需求都支持系統(tǒng)需求的部分實(shí)現(xiàn)，當(dāng)每個組件實(shí)現(xiàn)其子需求時，我們期待系統(tǒng)級需求也得到滿足。

一般來說，當(dāng)開發(fā)系統(tǒng)級和子系統(tǒng)級需求時，最好是避免產(chǎn)生多余的需求，因?yàn)閺男枨蠊芾淼慕嵌葋砜?，重?fù)的需求會產(chǎn)生維護(hù)問題。如果一個冗余的需求被修改，那么所有其他的需求也必須被修改，否則需求將不一致。然而，當(dāng)開發(fā)高集成度的系統(tǒng)時，冗余需求可以提高系統(tǒng)的完整性。在這種情況下，一個系統(tǒng)級的需求被分解成冗余的子需求，其中每個單獨(dú)的子需求都直接支持實(shí)現(xiàn)系統(tǒng)需求。如果冗余需求被分配給不同的組件，那么如果其中一個組件不能滿足其需求，其他組件仍然可以滿足，從而提高系統(tǒng)的完整性。

出現(xiàn)的一個問題是如何評估冗余需求所提供的完整性水平。從安全或評估案例的角度來看，一個有多種方式實(shí)現(xiàn)要求的系統(tǒng)似乎比一個只提供一種方式實(shí)現(xiàn)要求的系統(tǒng)更有可能滿足要求，因此，安全分析人員希望給有冗余要求的系統(tǒng)指定一個更高的完整性等級。需要考慮共同原因故障的概念，為了使冗余要求提供比單一要求更高的完整性，必須有一些手段來保證冗余要求的實(shí)施的獨(dú)立性。

為了評估冗余需求的價值，必須建立一個故障模型。一般來說，故障可以分為兩類：隨機(jī)硬件故障和系統(tǒng)故障，其中系統(tǒng)故障可能與系統(tǒng)的硬件和軟件都有關(guān)。為了評估有冗余需求的設(shè)計對隨機(jī)硬件故障的完整性水平，可以進(jìn)行故障樹分析。冗余實(shí)現(xiàn)的要求將導(dǎo)致故障樹有多個輸入與門。然而，對于系統(tǒng)性故障，可以定義和應(yīng)用一個實(shí)現(xiàn)整體完整性與冗余需求完整性之間關(guān)系規(guī)則的定性代數(shù)方程。對于這樣的方法，可以定義一組完整性等級（例如，A、B、C和D），代數(shù)規(guī)則涉及到冗余需求的完整性如何被組合以產(chǎn)生更高的完整性等級（例如，A + A = B）。

在本文中，我們研究了上述問題如何被ISO 26262標(biāo)準(zhǔn)[1]解決。ISO 26262定義了汽車安全完整性等級（ASILs）和安全要求分解的代數(shù)方法（ASIL分解）。本文的動機(jī)是作者觀察到ASIL分解的做法目前在汽車行業(yè)內(nèi)并不一致。為了幫助解決這個問題，我們調(diào)查并評論了關(guān)于這個問題的幾個出版物。本文的結(jié)構(gòu)如下：首先，我們提供一個關(guān)于ISO 26262 ASIL分解的介紹，接下來通過回顧幾個相關(guān)的出版物，確定其所描述的方法，并提供評論和總結(jié)性的例子，最后列出發(fā)現(xiàn)的總結(jié)。

02、ISO26262中的ASIL分解

ASIL分解是ISO26262第9部分第5條中定義的方法（關(guān)于ASIL定制的要求分解），將一個給定的安全要求分解成一組冗余的安全要求，根據(jù) "父級 "要求的ASIL定制一個ASIL。一般來說，ASIL被分配給一個安全目標(biāo)，所有從該目標(biāo)衍生出來的安全要求都繼承相同的ASIL。如果需求被分配給足夠獨(dú)立的元素（建筑、硬件或軟件），那么ASIL分解方法可用于在這些獨(dú)立的元素上冗余地實(shí)現(xiàn)分解的安全需求，這可能導(dǎo)致降低分解需求的ASIL。請注意，降低分解需求的ASIL并不意味著 "父 "需求的ASIL已經(jīng)降低，而是所有分解需求的ASIL降低后，一起達(dá)到 "父 "需求的ASIL。

在使用ASIL分解時，我們需要注意以下幾點(diǎn)。

• ASIL分解可用于功能，技術(shù)，硬件和軟件需求 

• 如果元素的獨(dú)立性不成立，那么分解的需求將繼承其 "父 "需求的ASIL。

• 如果使用同質(zhì)冗余（硬件/軟件的純粹重復(fù)），則需要依賴性故障分析[9]來證明獨(dú)立性。

ASIL分解可以在設(shè)計過程的任何階段應(yīng)用于任何需求，并且可以多次應(yīng)用。這與IEC 61508-2的硬件容錯概念不同，后者只允許分解一次。在系統(tǒng)、硬件和軟件層面上分配給分解需求的元素的開發(fā)，至少要在分解的ASIL進(jìn)行。然而，由于隨機(jī)硬件故障（ISO 26262，第5部分）導(dǎo)致的上級安全目標(biāo)的硬件架構(gòu)指標(biāo)的評估需要在分解前在ASIL進(jìn)行。因此，每個具有分解ASIL的需求應(yīng)在括號中包含其安全目標(biāo)的ASIL，作為跟蹤原始ASIL的一種方式。如果ASIL分解是在軟件層面上進(jìn)行的，實(shí)現(xiàn)分解需求的元素將需要在系統(tǒng)、硬件和軟件層面上檢查獨(dú)立性（包括保證獨(dú)立性的措施）。

表1中描述了ASIL分解的規(guī)則，當(dāng)執(zhí)行ASIL分解時：

• 任何確認(rèn)措施（ISO 26262，第2部分）將在分解前的ASIL下應(yīng)用 

• 將提供元素獨(dú)立性的證明（ISO 26262，第9部分）

• 任何集成活動（ISO 26262，第4部分）將在分解前的ASIL下進(jìn)行

我們注意到，如果ASIL分解將需求分配為功能和其安全機(jī)制，則安全機(jī)制將被分配分解的ASIL中最高者。

如果分解規(guī)則是ASIL X到ASIL X(X)和QM(X)的一個，那么顯然質(zhì)量管理的要求足夠開發(fā)功能分配的要素。

在本節(jié)的最后，我們提供一個從[8]中抽象出來的ASIL分解的例子。[8]中的第11.3條描述了一個舒適的功能，駕駛員可以在零速行駛時通過按下一個開關(guān)來啟動它。如果車速超過15公里/小時，啟動可能會導(dǎo)致危險情況。正如[8]中的情況一樣，該功能、其要求和它們的ASILs是為了說明問題，并不反映任何現(xiàn)實(shí)生活中的功能及其要求。讓我們假設(shè)分解前的要求是。

需求：當(dāng)車輛速度大于15km/h時，該特征應(yīng)被停用。

而上述要求是一個ASIL C要求。考慮到圖1中描述的結(jié)構(gòu)，可以將上述要求分解為以下兩個冗余的要求。

需求1. 控制器不得對車速大于15km/h的車輛發(fā)送激活指令

需求2. 當(dāng)車輛速度大于15km/h時，執(zhí)行器開關(guān)應(yīng)打開

很明顯，控制器和開關(guān)是獨(dú)立的元件，從獨(dú)立的來源接收車輛速度。這種元素獨(dú)立性的證明允許對需求1和2進(jìn)行ASIL分解，它們可以被分配到如表2中的ASIL分解解釋與實(shí)踐

03、ASIL分解詮釋與實(shí)踐

自2009年ISO 26262國際標(biāo)準(zhǔn)草案發(fā)布以來，許多研究人員和從業(yè)人員對ASIL分解進(jìn)行了研究、應(yīng)用和報告。除了在會議和研討會上進(jìn)行的演講和發(fā)表的論文外，許多提供功能安全領(lǐng)域咨詢的公司都提出了他們自己對ASIL分解的詮釋。我們回顧了其中的一些論文和演示，總結(jié)了以下主要的發(fā)現(xiàn)。

ASIL分解的概念和適用性

ASIL分解不是一個新的概念， IEC 61508[2]第2部分已經(jīng)有一個類似的概念，目標(biāo)是硬件冗余，并得到所有功能安全專家的認(rèn)可。然而，這個概念的應(yīng)用方式因不同的從業(yè)者對這個概念的解釋而不同。許多人都將這個概念理解為用于探索設(shè)計和機(jī)構(gòu)的選項(xiàng)之一。

在[3]中，作者明確指出ASIL分解是定性的概念，來解決系統(tǒng)問題而不是硬件失效。也就是說，[3]指出，該概念被用作架構(gòu)設(shè)計的一部分，分解需求并將它們分配給架構(gòu)元素，而不處理硬件可靠性并試圖實(shí)現(xiàn)量化目標(biāo)。[7]中是支持這樣的陳述，其中明確指出ASIL分解處理系統(tǒng)需求，硬件指標(biāo)保持在頂層安全需求的水平(ISO 26262術(shù)語中的安全目標(biāo))。

首先，關(guān)于ASIL分解在[6]中給出了一個更通用的陳述，其中作者聲稱ASIL分解可以在系統(tǒng)、硬件和軟件級別上執(zhí)行。如果系統(tǒng)、硬件和軟件級別被用來表示架構(gòu)元素，那么該聲明就違反了ISO 26262 ASIL分解的意圖。然而，[6]似乎間接遵循了對ASIL分解的[3]和[7]的解釋，因?yàn)橐⒁庥布軜?gòu)指標(biāo)不應(yīng)受ASIL分解的影響。如果架構(gòu)度量不受影響，那么就不會針對隨機(jī)硬件故障造成的硬件可靠性問題。

這里值得注意的是，[3]聲明ASIL可以降低。雖然分解需求的ASIL可以降低，但安全目標(biāo)的ASIL保持不變，因此沒有實(shí)現(xiàn)ASIL的絕對降低。另一方面，如果我們的理解是不正確的，該陳述可能與ASIL分解規(guī)則和需求不一致。

重疊需求和ASIL分解

許多功能安全專家同意ASIL分解應(yīng)用于需求，而不是構(gòu)建架構(gòu)的元素。盡管[3]聲明ASIL分解通過架構(gòu)設(shè)計元素引入了功能性或異構(gòu)冗余，我們相信[3]的作者正在討論分配到不同架構(gòu)元素的需求的冗余。[6]和[7]中也有類似的表述。在[6]和[7]中，作者討論了將安全要求適當(dāng)?shù)貏澐譃槿哂喟踩罂梢杂糜讵?dú)立元素的組合。這里的關(guān)鍵是這些要素必須是獨(dú)立的，這就需要進(jìn)行某種類型的分析，以證明其中一個要素的失效不會孤立地導(dǎo)致安全目標(biāo)的違反。此外，分解后的需求必須符合“父”需求，即這些需求都是相同的。

[4]中提出了一種有趣的需求分解方法，其中使用了類似于故障樹分析(FTA)的方法。在分解需求時，系統(tǒng)/子系統(tǒng)的獨(dú)立性通過AND門來證明，并應(yīng)用表1的規(guī)則。盡管[4]給出了系統(tǒng)及其構(gòu)建子系統(tǒng)的故障樹表示，并描述了相應(yīng)的ASIL分解，但我們的理解是，分解的ASIL被分配給這些系統(tǒng)的需求，而不是系統(tǒng)和子系統(tǒng)本身。如果這種理解是不正確的，那么所提出的方法可能是有問題的，并且實(shí)際上違反了ISO 26262 ASIL分解的意圖。如果所提議的方法的意圖是從需求分解中獲益，那么這樣的方法可能是有效的。

需求分解的好處

由于ASIL分解處理的是需求分解，這樣的分解可用于降低分配給特定元素的安全需求的ASIL，這得益于體系結(jié)構(gòu)中已添加的冗余元素，這些冗余元素有助于滿足硬件體系結(jié)構(gòu)指標(biāo)。具體來說，在許多系統(tǒng)中，針對隨機(jī)硬件故障實(shí)施安全機(jī)制(在一個元素中按照ISO 26262開發(fā))將足以滿足該標(biāo)準(zhǔn)對設(shè)計的幾個元素的要求。在前面已經(jīng)討論過，這種技術(shù)是對ASIL X到ASIL X(X)和QM(X)的分解規(guī)律的一種解釋。

ASIL分解作為自上向下和自下向上方法

ASIL分解很容易被解釋為一種自上向下的方法。安全目標(biāo)被分解為需求和子需求。在冗余元素獨(dú)立且互不干擾的情況下，這些需求被分配為較低的ASILs。像ASIL Decomposition這樣的FTA的[4]中的描述支持這個論點(diǎn)，即根據(jù)故障樹的分支將需求分解到不同的組件。我們的理解是，組件或架構(gòu)元素的獨(dú)立性可以通過使用的門的類型來證明或證明:即，AND門的使用是值分支是獨(dú)立的，因此組件或架構(gòu)元素確實(shí)是獨(dú)立的，這驗(yàn)證了ASIL分解的正確性。在[5]中介紹了ASIL分解的另一個自上向下的應(yīng)用，其中作者討論了一個線控制動系統(tǒng)的示例，并介紹了從車輛到系統(tǒng)和子系統(tǒng)級別的安全需求，以及系統(tǒng)和子系統(tǒng)級別需求的ASIL分解。

一些實(shí)踐者認(rèn)為ASIL分解是一種自下而上的方法。然而，在我們的理解中，這并不是ISO 26262的意圖，正如ISO 26262第9部分第5.4條所示。這種方法可以解釋為，設(shè)計師需要從現(xiàn)有的設(shè)計元素自下向上構(gòu)建系統(tǒng)。更具體地說，如果制造商為供應(yīng)商提供子系統(tǒng)安全需求，那么供應(yīng)商需要滿足這些需求，從而從具有與之關(guān)聯(lián)的ASIL概念的組件元素實(shí)現(xiàn)目標(biāo)系統(tǒng)級別的ASIL。掌握一些關(guān)于組件元素及其相關(guān)ASIL的知識，并將其考慮到滿足目標(biāo)系統(tǒng)級別的ASIL中，真正構(gòu)成了ASIL分解的自下向上方法。[6]中的作者在設(shè)計基礎(chǔ)軟件時討論了這種方法。正如在[6]中所解釋的，基礎(chǔ)軟件需要滿足ASIL D是非常復(fù)雜的，它無法獨(dú)立于其他機(jī)制來滿足ASIL。因此，一些應(yīng)用軟件和安全層被開發(fā)出來，以滿足ASIL D的要求，并且與QM基礎(chǔ)軟件一起，每個組件被分配到獨(dú)立的架構(gòu)元素，以滿足ASIL D的最高要求。[3]中也展示了自下向上方法的另一個示例，盡管其方式不像[6]中那樣明顯。在[3]中，作者討論了一個汽車相關(guān)的例子，其中定義了ASIL D的安全目標(biāo)。系統(tǒng)中的所有組件都被分配到滿足ASIL D完整性的要求。但是，在組件級別上執(zhí)行分析，以檢查這些組件中的任何故障是否會直接導(dǎo)致違反安全目標(biāo)。如果沒有違反安全目標(biāo)，根據(jù)表1的規(guī)則之一，這些組件需求的ASIL將被降低。盡管繼承安全目標(biāo)的ASIL被認(rèn)為是一種自上向下的方法，但[3]中提出真正的ASIL分解是通過自下向上的方法實(shí)現(xiàn)的。

脫離上下文的安全元素(SEooC)

根據(jù)ISO 26262 Part 10 [8]， SEooC是與安全相關(guān)的元素，它不是為特定車輛的特定系統(tǒng)開發(fā)的。因此，在定義和分析此類元素時，無需考慮車輛級別的安全目標(biāo)(及其相應(yīng)的ASIL)。在這樣做的過程中，在組件級別進(jìn)行假設(shè)，并開發(fā)滿足給定安全完整性級別的需求。一旦這些元素需要集成到車輛中，就需要檢查所做的假設(shè)是否正確，以及考慮到SEooC的發(fā)展，車輛的安全目標(biāo)和安全要求是否確實(shí)可以滿足。即使SEooC不需要或不使用ASIL分解，在我們看來，這樣的方法可以被視為ASIL分解概念自下向上的應(yīng)用。

04、好的，壞的，丑陋的

在本節(jié)中，我們提供一個總結(jié)示例，突出本文中確定的問題。根據(jù)前面給出的例子，考慮兩種設(shè)計需求情況。

案例1(“好的”)如下

• 系統(tǒng)

• 需求:當(dāng)車速大于15km/h時，該功能不應(yīng)該激活A(yù)SIL C

• 控制器

• 需求:當(dāng)車速大于15km/h時，控制器不應(yīng)發(fā)送激活命令A(yù)SIL A(C)

• 執(zhí)行器開關(guān)

• 需求:當(dāng)車速大于15km/ h時，執(zhí)行機(jī)構(gòu)開關(guān)應(yīng)打開。ASIL B(C)

情況2(“壞的和丑陋的”)是

• 控制器ASIL A

• 執(zhí)行器開關(guān)ASIL B

案例1遵循ISO 26262 ASIL分解方法?？刂破鞯拈_發(fā)必須滿足ASIL A的要求，執(zhí)行器開關(guān)的開發(fā)必須滿足ASIL B的要求，整個系統(tǒng)的隨機(jī)硬件分析必須滿足ASIL C的安全目標(biāo)，即“當(dāng)車速超過15km/h時，該功能將被取消”。如果控制器開發(fā)被分配給一個供應(yīng)商，而執(zhí)行機(jī)構(gòu)是另一個供應(yīng)商，每個供應(yīng)商都知道其組件的適當(dāng)開發(fā)過程需求，并且雙方必須與系統(tǒng)集成商合作，以確保滿足頂層安全目標(biāo)(ASIL C)的隨機(jī)硬件分析需求。

案例2不遵循ISO 26262方法。雖然每個組件的開發(fā)通常會按照適當(dāng)?shù)囊筮M(jìn)行(ASIL A用于控制器，ASIL B用于執(zhí)行器開關(guān))，但情況2意味著控制器沒有隨機(jī)的硬件目標(biāo)(ASIL A沒有目標(biāo))，只有執(zhí)行器開關(guān)的推薦(非必需)目標(biāo)。不能保證如果這些組件滿足隨機(jī)硬件故障的ASIL目標(biāo)，那么整個系統(tǒng)就會滿足ASIL C目標(biāo)的總體安全目標(biāo)。評估隨機(jī)硬件目標(biāo)的分析依賴于了解哪些組件故障模式是安全的，哪些是與系統(tǒng)的總體安全目標(biāo)無關(guān)的。案例2確實(shí)提供了進(jìn)行這種區(qū)分的信息。還有一種可能是，控制器和執(zhí)行器開關(guān)之間的一個意想不到的依賴關(guān)系將被錯過(控制器不需要分析)。

當(dāng)與供應(yīng)商合作時，可能確實(shí)有必要為供應(yīng)商提供關(guān)于他們應(yīng)該如何進(jìn)行設(shè)計的具體指導(dǎo)，這樣當(dāng)他們的組件集成到整個系統(tǒng)中時，系統(tǒng)本身將達(dá)到隨機(jī)硬件故障要求所需的ASIL目標(biāo)。這可以通過使用系統(tǒng)工程預(yù)算方法來實(shí)現(xiàn)，分配一個ASIL來指導(dǎo)組件的開發(fā)(解決系統(tǒng)錯誤)，以及針對隨機(jī)硬件故障的特定目標(biāo)(通過在系統(tǒng)組件之間分配頂級故障目標(biāo)來獲得)。ISO 26262第4部分要求7.4.4.4解決了這種方法[1]。

當(dāng)基于現(xiàn)有的設(shè)計元素設(shè)計一個系統(tǒng)時，在評估不同的設(shè)計方案時，使用類似于案例2的符號可能確實(shí)非常有用。這種自下向上的方法提供了一種簡單的方法，可以考慮如何使用具有不同ASILs的元素來構(gòu)建整個系統(tǒng)。但是，建議同時考慮一個自上向下的分析，以幫助確認(rèn)自下向上分析的假設(shè)是合理的。

05、總結(jié)和建議

在本文中，我們總結(jié)了ISO 26262中定義的ASIL分解方法背后的理論，并介紹了該方法是如何被功能安全領(lǐng)域的從業(yè)者解釋和實(shí)施的。鑒于我們回顧的為數(shù)不多的論文和報告，很明顯，該方法正以不同的方式被應(yīng)用。我們想挑出兩個我們認(rèn)為非常重要的問題:ASIL分解的適用性和自上向下與自下向上的分解應(yīng)用。

• 根據(jù)ISO 26262的ASIL分解是一種方法，不是證明減少ASIL分配到硬件元素的隨機(jī)硬件故障，而是專注于系統(tǒng)故障背景下的功能和需求。由于ASIL分解處理的是需求分解，在某些情況下，這樣的分解可以由已經(jīng)添加的架構(gòu)中現(xiàn)有的冗余元素啟用，以幫助滿足硬件架構(gòu)指標(biāo)。然而，該方法本身的目的是提供將已實(shí)現(xiàn)的需求的完整性聯(lián)系起來的規(guī)則，給定其分解的冗余需求的完整性。因此，作者建議ASIL分解只在需求被細(xì)化并分配到不同的獨(dú)立組件時使用。

• 盡管基于已有設(shè)計元素的系統(tǒng)開發(fā)可能需要自下向上的方法，但ASIL與需求本質(zhì)上是相關(guān)聯(lián)的，當(dāng)設(shè)計使用ASIL分解時，對最終的安全案例來說，確認(rèn)自頂向下的ASIL需求分解是至關(guān)重要的。作者建議設(shè)計團(tuán)隊(duì)明確地考慮(預(yù)期的)自上向下的需求分解，即使系統(tǒng)是自下向上設(shè)計的，其中設(shè)計元素已經(jīng)預(yù)先分配了ASILs。這將支持構(gòu)建最終的安全案例，同時確認(rèn)ASIL需求分解與設(shè)計元素相關(guān)的ASIL相匹配。