ISO 26262笔记——如何理解ASIL分解？

驾驶哥 2021年12月14日浏览：1836

作者 | 小青的风筝

来源 | 汽车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分解可选择以下任意一种方式

一个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)的要求。

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要求从以下三个方面的指标衡量随机硬件失效：

单点故障度量（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 decomposition. （针对随机硬件失效的要求，包括硬件架构度量的评估和由于随机硬件失效导致违背安全目标的评估，在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

综上，我们可以做出如下总结：

ASIL分解可以降低系统中不同层级的元素（如软件、硬件等）的系统性失效要求ASIL分解无法降低相关项（item）作为一个整体的随机硬件失效要求，即分解前后对相关项的SPFM、LFM和PMHF要求都不变ASIL分解可以降低相关项的某个component的随机硬件失效要求，准确地说是降低了对部件的SPMF和LFM的要求（注：对PMHF是item level相关项层级的要求，在component层面不做考虑）