译文 | ASIL分解：好的，坏的和丑陋的

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

作者：Agish George, Jody Nelson

翻译：郭金、徐铱铱

译文审核：汤黎超

ASIL分解是ISO 26262标准中描述的一种将ASIL分解给冗余需求的方法。虽然ASIL分解似乎与IEC 61508-2的硬件容错概念有类似的意图，但ASIL分解的目的不是为了减少ASIL分配至硬件元素的随机硬件故障，而是专注于系统性失效情况下的功能和需求。根据我们参与标准制定的情况，该方法在实践中被以不同的方式应用，并非所有的方法都与标准的意图完全一致。两个潜在可能导致使用 "修改过的 "ASIL等级”的原因包括：OEM厂商需要对系统进行分割并向供应商指定子系统需求，以及设计者需要自下而上的构建系统。自下而上构建系统的目标是，从已有的一些ASIL概念组件元素中实现目标系统级的ASIL。在本文中，我们研究了ASIL分解在ISO 26262标准中的起源和该方法潜在的好处和局限性，以及通过查阅关于这个主题的论文，去探究它目前是如何被应用于工业项目中。

01、引言

分解和分配需求的任务是系统工程众所周知的一部分。一个系统级的需求要么被直接分配给系统的一个组件，要么被分解（分割）成子需求，这些子需求被分配给不同的组件。在后一种情况下，每个子需求都支持系统需求的部分实现，当每个组件实现其子需求时，我们期待系统级需求也得到满足。

一般来说，当开发系统级和子系统级需求时，最好是避免产生多余的需求，因为从需求管理的角度来看，重复的需求会产生维护问题。如果一个冗余的需求被修改，那么所有其他的需求也必须被修改，否则需求将不一致。然而，当开发高集成度的系统时，冗余需求可以提高系统的完整性。在这种情况下，一个系统级的需求被分解成冗余的子需求，其中每个单独的子需求都直接支持实现系统需求。如果冗余需求被分配给不同的组件，那么如果其中一个组件不能满足其需求，其他组件仍然可以满足，从而提高系统的完整性。

出现的一个问题是如何评估冗余需求所提供的完整性水平。从安全或评估案例的角度来看，一个有多种方式实现要求的系统似乎比一个只提供一种方式实现要求的系统更有可能满足要求，因此，安全分析人员希望给有冗余要求的系统指定一个更高的完整性等级。需要考虑共同原因故障的概念，为了使冗余要求提供比单一要求更高的完整性，必须有一些手段来保证冗余要求的实施的独立性。

为了评估冗余需求的价值，必须建立一个故障模型。一般来说，故障可以分为两类：随机硬件故障和系统故障，其中系统故障可能与系统的硬件和软件都有关。为了评估有冗余需求的设计对随机硬件故障的完整性水平，可以进行故障树分析。冗余实现的要求将导致故障树有多个输入与门。然而，对于系统性故障，可以定义和应用一个实现整体完整性与冗余需求完整性之间关系规则的定性代数方程。对于这样的方法，可以定义一组完整性等级（例如，A、B、C和D），代数规则涉及到冗余需求的完整性如何被组合以产生更高的完整性等级（例如，A + A = B）。

在本文中，我们研究了上述问题如何被ISO 26262标准[1]解决。ISO 26262定义了汽车安全完整性等级（ASILs）和安全要求分解的代数方法（ASIL分解）。本文的动机是作者观察到ASIL分解的做法目前在汽车行业内并不一致。为了帮助解决这个问题，我们调查并评论了关于这个问题的几个出版物。本文的结构如下：首先，我们提供一个关于ISO 26262 ASIL分解的介绍，接下来通过回顾几个相关的出版物，确定其所描述的方法，并提供评论和总结性的例子，最后列出发现的总结。

02、ISO26262中的ASIL分解

ASIL分解是ISO26262第9部分第5条中定义的方法（关于ASIL定制的要求分解），将一个给定的安全要求分解成一组冗余的安全要求，根据 "父级 "要求的ASIL定制一个ASIL。一般来说，ASIL被分配给一个安全目标，所有从该目标衍生出来的安全要求都继承相同的ASIL。如果需求被分配给足够独立的元素（建筑、硬件或软件），那么ASIL分解方法可用于在这些独立的元素上冗余地实现分解的安全需求，这可能导致降低分解需求的ASIL。请注意，降低分解需求的ASIL并不意味着 "父 "需求的ASIL已经降低，而是所有分解需求的ASIL降低后，一起达到 "父 "需求的ASIL。

在使用ASIL分解时，我们需要注意以下几点。

• ASIL分解可用于功能，技术，硬件和软件需求 

• 如果元素的独立性不成立，那么分解的需求将继承其 "父 "需求的ASIL。

• 如果使用同质冗余（硬件/软件的纯粹重复），则需要依赖性故障分析[9]来证明独立性。

ASIL分解可以在设计过程的任何阶段应用于任何需求，并且可以多次应用。这与IEC 61508-2的硬件容错概念不同，后者只允许分解一次。在系统、硬件和软件层面上分配给分解需求的元素的开发，至少要在分解的ASIL进行。然而，由于随机硬件故障（ISO 26262，第5部分）导致的上级安全目标的硬件架构指标的评估需要在分解前在ASIL进行。因此，每个具有分解ASIL的需求应在括号中包含其安全目标的ASIL，作为跟踪原始ASIL的一种方式。如果ASIL分解是在软件层面上进行的，实现分解需求的元素将需要在系统、硬件和软件层面上检查独立性（包括保证独立性的措施）。

表1中描述了ASIL分解的规则，当执行ASIL分解时：

• 任何确认措施（ISO 26262，第2部分）将在分解前的ASIL下应用 

• 将提供元素独立性的证明（ISO 26262，第9部分）

• 任何集成活动（ISO 26262，第4部分）将在分解前的ASIL下进行

我们注意到，如果ASIL分解将需求分配为功能和其安全机制，则安全机制将被分配分解的ASIL中最高者。

如果分解规则是ASIL X到ASIL X(X)和QM(X)的一个，那么显然质量管理的要求足够开发功能分配的要素。

在本节的最后，我们提供一个从[8]中抽象出来的ASIL分解的例子。[8]中的第11.3条描述了一个舒适的功能，驾驶员可以在零速行驶时通过按下一个开关来启动它。如果车速超过15公里/小时，启动可能会导致危险情况。正如[8]中的情况一样，该功能、其要求和它们的ASILs是为了说明问题，并不反映任何现实生活中的功能及其要求。让我们假设分解前的要求是。

需求：当车辆速度大于15km/h时，该特征应被停用。

而上述要求是一个ASIL C要求。考虑到图1中描述的结构，可以将上述要求分解为以下两个冗余的要求。

需求1. 控制器不得对车速大于15km/h的车辆发送激活指令

需求2. 当车辆速度大于15km/h时，执行器开关应打开

很明显，控制器和开关是独立的元件，从独立的来源接收车辆速度。这种元素独立性的证明允许对需求1和2进行ASIL分解，它们可以被分配到如表2中的ASIL分解解释与实践

03、ASIL分解诠释与实践

自2009年ISO 26262国际标准草案发布以来，许多研究人员和从业人员对ASIL分解进行了研究、应用和报告。除了在会议和研讨会上进行的演讲和发表的论文外，许多提供功能安全领域咨询的公司都提出了他们自己对ASIL分解的诠释。我们回顾了其中的一些论文和演示，总结了以下主要的发现。

ASIL分解的概念和适用性

ASIL分解不是一个新的概念， IEC 61508[2]第2部分已经有一个类似的概念，目标是硬件冗余，并得到所有功能安全专家的认可。然而，这个概念的应用方式因不同的从业者对这个概念的解释而不同。许多人都将这个概念理解为用于探索设计和机构的选项之一。

在[3]中，作者明确指出ASIL分解是定性的概念，来解决系统问题而不是硬件失效。也就是说，[3]指出，该概念被用作架构设计的一部分，分解需求并将它们分配给架构元素，而不处理硬件可靠性并试图实现量化目标。[7]中是支持这样的陈述，其中明确指出ASIL分解处理系统需求，硬件指标保持在顶层安全需求的水平(ISO 26262术语中的安全目标)。

首先，关于ASIL分解在[6]中给出了一个更通用的陈述，其中作者声称ASIL分解可以在系统、硬件和软件级别上执行。如果系统、硬件和软件级别被用来表示架构元素，那么该声明就违反了ISO 26262 ASIL分解的意图。然而，[6]似乎间接遵循了对ASIL分解的[3]和[7]的解释，因为要注意硬件架构指标不应受ASIL分解的影响。如果架构度量不受影响，那么就不会针对随机硬件故障造成的硬件可靠性问题。

这里值得注意的是，[3]声明ASIL可以降低。虽然分解需求的ASIL可以降低，但安全目标的ASIL保持不变，因此没有实现ASIL的绝对降低。另一方面，如果我们的理解是不正确的，该陈述可能与ASIL分解规则和需求不一致。

重叠需求和ASIL分解

许多功能安全专家同意ASIL分解应用于需求，而不是构建架构的元素。尽管[3]声明ASIL分解通过架构设计元素引入了功能性或异构冗余，我们相信[3]的作者正在讨论分配到不同架构元素的需求的冗余。[6]和[7]中也有类似的表述。在[6]和[7]中，作者讨论了将安全要求适当地划分为冗余安全要求可以用于独立元素的组合。这里的关键是这些要素必须是独立的，这就需要进行某种类型的分析，以证明其中一个要素的失效不会孤立地导致安全目标的违反。此外，分解后的需求必须符合“父”需求，即这些需求都是相同的。

[4]中提出了一种有趣的需求分解方法，其中使用了类似于故障树分析(FTA)的方法。在分解需求时，系统/子系统的独立性通过AND门来证明，并应用表1的规则。尽管[4]给出了系统及其构建子系统的故障树表示，并描述了相应的ASIL分解，但我们的理解是，分解的ASIL被分配给这些系统的需求，而不是系统和子系统本身。如果这种理解是不正确的，那么所提出的方法可能是有问题的，并且实际上违反了ISO 26262 ASIL分解的意图。如果所提议的方法的意图是从需求分解中获益，那么这样的方法可能是有效的。

需求分解的好处

由于ASIL分解处理的是需求分解，这样的分解可用于降低分配给特定元素的安全需求的ASIL，这得益于体系结构中已添加的冗余元素，这些冗余元素有助于满足硬件体系结构指标。具体来说，在许多系统中，针对随机硬件故障实施安全机制(在一个元素中按照ISO 26262开发)将足以满足该标准对设计的几个元素的要求。在前面已经讨论过，这种技术是对ASIL X到ASIL X(X)和QM(X)的分解规律的一种解释。

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

ASIL分解很容易被解释为一种自上向下的方法。安全目标被分解为需求和子需求。在冗余元素独立且互不干扰的情况下，这些需求被分配为较低的ASILs。像ASIL Decomposition这样的FTA的[4]中的描述支持这个论点，即根据故障树的分支将需求分解到不同的组件。我们的理解是，组件或架构元素的独立性可以通过使用的门的类型来证明或证明:即，AND门的使用是值分支是独立的，因此组件或架构元素确实是独立的，这验证了ASIL分解的正确性。在[5]中介绍了ASIL分解的另一个自上向下的应用，其中作者讨论了一个线控制动系统的示例，并介绍了从车辆到系统和子系统级别的安全需求，以及系统和子系统级别需求的ASIL分解。

一些实践者认为ASIL分解是一种自下而上的方法。然而，在我们的理解中，这并不是ISO 26262的意图，正如ISO 26262第9部分第5.4条所示。这种方法可以解释为，设计师需要从现有的设计元素自下向上构建系统。更具体地说，如果制造商为供应商提供子系统安全需求，那么供应商需要满足这些需求，从而从具有与之关联的ASIL概念的组件元素实现目标系统级别的ASIL。掌握一些关于组件元素及其相关ASIL的知识，并将其考虑到满足目标系统级别的ASIL中，真正构成了ASIL分解的自下向上方法。[6]中的作者在设计基础软件时讨论了这种方法。正如在[6]中所解释的，基础软件需要满足ASIL D是非常复杂的，它无法独立于其他机制来满足ASIL。因此，一些应用软件和安全层被开发出来，以满足ASIL D的要求，并且与QM基础软件一起，每个组件被分配到独立的架构元素，以满足ASIL D的最高要求。[3]中也展示了自下向上方法的另一个示例，尽管其方式不像[6]中那样明显。在[3]中，作者讨论了一个汽车相关的例子，其中定义了ASIL D的安全目标。系统中的所有组件都被分配到满足ASIL D完整性的要求。但是，在组件级别上执行分析，以检查这些组件中的任何故障是否会直接导致违反安全目标。如果没有违反安全目标，根据表1的规则之一，这些组件需求的ASIL将被降低。尽管继承安全目标的ASIL被认为是一种自上向下的方法，但[3]中提出真正的ASIL分解是通过自下向上的方法实现的。

脱离上下文的安全元素(SEooC)

根据ISO 26262 Part 10 [8]， SEooC是与安全相关的元素，它不是为特定车辆的特定系统开发的。因此，在定义和分析此类元素时，无需考虑车辆级别的安全目标(及其相应的ASIL)。在这样做的过程中，在组件级别进行假设，并开发满足给定安全完整性级别的需求。一旦这些元素需要集成到车辆中，就需要检查所做的假设是否正确，以及考虑到SEooC的发展，车辆的安全目标和安全要求是否确实可以满足。即使SEooC不需要或不使用ASIL分解，在我们看来，这样的方法可以被视为ASIL分解概念自下向上的应用。

04、好的，坏的，丑陋的

在本节中，我们提供一个总结示例，突出本文中确定的问题。根据前面给出的例子，考虑两种设计需求情况。

案例1(“好的”)如下

• 系统

• 需求:当车速大于15km/h时，该功能不应该激活ASIL C

• 控制器

• 需求:当车速大于15km/h时，控制器不应发送激活命令ASIL A(C)

• 执行器开关

• 需求:当车速大于15km/ h时，执行机构开关应打开。ASIL B(C)

情况2(“坏的和丑陋的”)是

• 控制器ASIL A

• 执行器开关ASIL B

案例1遵循ISO 26262 ASIL分解方法。控制器的开发必须满足ASIL A的要求，执行器开关的开发必须满足ASIL B的要求，整个系统的随机硬件分析必须满足ASIL C的安全目标，即“当车速超过15km/h时，该功能将被取消”。如果控制器开发被分配给一个供应商，而执行机构是另一个供应商，每个供应商都知道其组件的适当开发过程需求，并且双方必须与系统集成商合作，以确保满足顶层安全目标(ASIL C)的随机硬件分析需求。

案例2不遵循ISO 26262方法。虽然每个组件的开发通常会按照适当的要求进行(ASIL A用于控制器，ASIL B用于执行器开关)，但情况2意味着控制器没有随机的硬件目标(ASIL A没有目标)，只有执行器开关的推荐(非必需)目标。不能保证如果这些组件满足随机硬件故障的ASIL目标，那么整个系统就会满足ASIL C目标的总体安全目标。评估随机硬件目标的分析依赖于了解哪些组件故障模式是安全的，哪些是与系统的总体安全目标无关的。案例2确实提供了进行这种区分的信息。还有一种可能是，控制器和执行器开关之间的一个意想不到的依赖关系将被错过(控制器不需要分析)。

当与供应商合作时，可能确实有必要为供应商提供关于他们应该如何进行设计的具体指导，这样当他们的组件集成到整个系统中时，系统本身将达到随机硬件故障要求所需的ASIL目标。这可以通过使用系统工程预算方法来实现，分配一个ASIL来指导组件的开发(解决系统错误)，以及针对随机硬件故障的特定目标(通过在系统组件之间分配顶级故障目标来获得)。ISO 26262第4部分要求7.4.4.4解决了这种方法[1]。

当基于现有的设计元素设计一个系统时，在评估不同的设计方案时，使用类似于案例2的符号可能确实非常有用。这种自下向上的方法提供了一种简单的方法，可以考虑如何使用具有不同ASILs的元素来构建整个系统。但是，建议同时考虑一个自上向下的分析，以帮助确认自下向上分析的假设是合理的。

05、总结和建议

在本文中，我们总结了ISO 26262中定义的ASIL分解方法背后的理论，并介绍了该方法是如何被功能安全领域的从业者解释和实施的。鉴于我们回顾的为数不多的论文和报告，很明显，该方法正以不同的方式被应用。我们想挑出两个我们认为非常重要的问题:ASIL分解的适用性和自上向下与自下向上的分解应用。

• 根据ISO 26262的ASIL分解是一种方法，不是证明减少ASIL分配到硬件元素的随机硬件故障，而是专注于系统故障背景下的功能和需求。由于ASIL分解处理的是需求分解，在某些情况下，这样的分解可以由已经添加的架构中现有的冗余元素启用，以帮助满足硬件架构指标。然而，该方法本身的目的是提供将已实现的需求的完整性联系起来的规则，给定其分解的冗余需求的完整性。因此，作者建议ASIL分解只在需求被细化并分配到不同的独立组件时使用。

• 尽管基于已有设计元素的系统开发可能需要自下向上的方法，但ASIL与需求本质上是相关联的，当设计使用ASIL分解时，对最终的安全案例来说，确认自顶向下的ASIL需求分解是至关重要的。作者建议设计团队明确地考虑(预期的)自上向下的需求分解，即使系统是自下向上设计的，其中设计元素已经预先分配了ASILs。这将支持构建最终的安全案例，同时确认ASIL需求分解与设计元素相关的ASIL相匹配。