EPB功能安全笔记(16):ASIL分解及其关键点

本文要点：在上一期（EPB功能安全笔记(15)：什么是DFA(Dependent Failure Analysis)）中介绍了相关失效分析(DFA, Dependent Failure Analysis)的目的和实践。相关失效分析的目的可以简单概括为：证明系统既不存在级联失效，也不存在共因失效。进一步地，ISO 26262指出，当级联失效和共因失效都不存在时，可以认为实现了独立性(independence)。

共因失效(左)；级联失效(右)

提到独立性，读者比较熟知的是ASIL分解，ISO 26262中要求ASIL分解的前提是：ASIL分解需要安全要求具有冗余性，且分配给充分独立的架构要素。

本文将对ASIL分解展开说明，在介绍分解原则的同时指出其中的关键点，抛砖引玉，希望能给读者带来一些参考。

1.什么是ASIL分解？

下面的案例在功能安全开发过程中非常常见：

• 对信号的功能安全需求的ASIL等级为ASIL D或者ASIL C，而信号只能达到ASIL A或者ASIL B

对于这种偏差，ISO 26262开了个“后门”来合理地避免这类偏差影响功能安全开发，这个“后门”就是ASIL分解。ASIL分解是降低对功能安全需求的ASIL等级的裁剪方法，这一方法的核心点是通过将一条功能安全需求分解成两条相互独立的需求并分配到两个及两个以上相互独立的元素（如软件模块、硬件模块、输入信号等）上。

正是由于这些参与分解的独立的元素之间构成了互为冗余关系，从整个系统的角度看，只有当这些元素同时发生失效时才会违背安全目标，这样一来对每个参与分解的相关元素的功能安全要求可以降低。

ISO 26262, part9第5章中定义了ASIL分解的特定的标记方式：

应通过在括号中给出安全目标的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分解标记示例

在ISO 26262, part9第5章中也对ASIL分解原则给出了说明，总结如下。

ASIL D分解

以下三种分解方式均可：

• 一个ASIL C(D)的要求和一个ASIL A(D)的要求；或
• 一个ASILB(D)的要求和一个ASIL B(D)的要求；或
• 一个ASIL D(D)的要求和一个QM(D)的要求。

QM即Quality Management，表示只要按照企业质量管理流程开发就可以满足ISO 26262要求，没有其他特殊功能安全要求。下同。

ASIL C分解

以下两种种分解方式均可：

• 一个ASIL B(C)的要求和一个ASIL A(C)的要求;或
• 一个ASILC(C)的要求和一个QM(C)的要求。

ASIL B分解

以下两种种分解方式均可：

• 一个ASIL A(B)的要求和一个ASIL A(B)的要求;或
• 一个ASILB(B)的要求和一个QM(B)的要求。

ASIL A分解

一个ASIL A 的要求不应被进一步分解,除非需要分解成一个ASIL A(A)的要求和一个QM(A)的要求。

2.ASIL分解的关键点

功能按照发展有些年头了，和E/E系统打交道的开发人员经过耳濡目染几乎都对ASIL分解略知一二，但是可能存在一些理解上的偏差。基于此，接下来对2个最容易被忽略的关键点展开说明。

2.1. ASIL分解要求元素间充分独立

ASIL分解本质概念是冗余，冗余就要求不存在共因失效或者级联失效导致互为冗余的元素同时失效。因此ISO 26262要求，对于使用ASIL分解的功能安全概念，必须要通过DFA证明分解后的相关元素间相互独立。

ISO 26262, part9对冗余进行了说明：

使用同构冗余(如通过复制设备或复制软件)的情况下,考虑到硬件和软件的系统性失效，不能降低ASIL等级，除非相关失效的分析提供了存在充分独立性或潜在共因指向安全状态的证据。因此，同构冗余因缺少要素间的独立性，通常不足以降低ASIL等级。

比如对于EPB系统来说，如果在车辆高速运行时错误拉起（一边）卡钳，那么最严重的情况会造成车辆失稳。因此EPB系统需要满足如下安全目标：

SG: EPB应避免在车速V>10kph时错误拉起卡钳，ASIL D

为实现这一安全目标，对正确判断车速有ASIL D的要求。假设车速计算依赖于轮速传感器输入，因此safety concept设计如下。

这个分解成立的前提是两个轮速信号充分独立，如果两个轮速传感器是同一个供应商的同一批次的传感器，实际上属于同构冗余，以上分解不成立。

2.2. ASIL分解是如何降低功能安全开发要求的？

前面提到，ASIL分解的目的是降低对安全相关的元素的ASIL等级要求，从而降低功能安全开发成本。而ASIL等级背后的要求包括对系统性失效和随机硬件失效的要求。那么ASIL分解以后对系统性失效和随机硬件失效的具体影响是什么呢？要回答这个问题，需要先回顾ISO 26262对这两类失效的要求。

ISO 26262对系统性失效的要求存在于各个层级，包括硬件元器件层(HW part level)、软件单元层(SW-Unit level)、组件层(compenent level)、系统层(system level)和相关项层(item level)。同时对系统性失效的要求本质上就是对设计流程和验证(测试)流程的要求。

产品层级划分

为了更好地理解上面的解释，依旧以2.1中提及的EPB系统Safety Goal为例，假设为了实现这条Safety Goal，EPB系统的功能架构和safety concept设计如下，其中车速计算依赖互为冗余且充分独立的轮速传感器和变速箱轴速传感器，各自分配ASIL B(D)的要求。

对于系统性失效而言，有如下功能要求：

1.车速计算模块需要满足ASIL D的软件开发流程；

2.EPB系统的集成测试需要满足ASIL D的测试要求；

3.轮速传感器和电机转速传感器的开发流程需要满足ASIL B的开发流程要求和测试要求。

而对随机硬件失效而言， 我们知道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分解后仍保持不变。）

这意味着不论是哪一个层级，对随机硬件失效要求的ASIL等级都应该是分解前的值。

但是，同样的ASIL等级，其背后对应的要求在不同层级是不一样的。我们接着上面的案例进一步分析。

站在将EPB系统看作一个整体的角度，系统的随机硬件失效指标应满足如下要求：

1.SPFM≥99%

2.LFM≥90%

3.PMHF＜10 FIT

注：此处PMHF的要求的前提是EPB系统是全新开发的系统，没有上一代产品的PMHF值作为对比，具体原因见第14期​​EPB功能安全笔记(14)：FTA定量分析之ISO26262对随机硬件失效的要求​​）

其中，PMHF是一个item level的指标，只有将EPB系统作为一个整体才能分析，但是，对于两外两个指标SPFM和LFM而言，即使ASIL等级不变，对部件的随机硬件失效要求实际上被降低了。

比如对上图中的电机转速传感器来说，虽然对电机传感器的随机硬件失效仍然要满足继承于Safety Goal的ASIL D的要求，但是电机传感器故障不会直接造成EPB系统直接违背安全目标，换句话说，对EPB系统而言，电机传感器的单点故障是系统的潜伏故障。因此，对电机传感器的SPFM要求应该根据系统层对潜伏故障度量的ASIL D的要求来定义，而不是系统层的对单点故障度量的ASIL D的要求来定义，这样一来要求从“不低于99%”降低为“不低于90%”。

下期预告

先前提到，相关失效分析(DFA, Dependent Failure Analysis)主要确认在功能安全设计中充分实现了所需的独立性(independence)或不受干扰的能力(freedom from interference)。本文介绍了ASIL分解的基本原理以及关键点，下期将对“不受干扰的能力”展开说明。

本文转载自：焉知智能汽车