ISO26262 Part 9 之 ASIL分解的意义

1.标准要求

5.4.11 The development of the decomposed elements at the system level and at the software level shall be performed, as a minimum, in accordance with the ASIL requirements (after decomposition) of ISO 26262-4 and ISO 26262-6. The development of the decomposed elements at the hardware level shall be performed, as a minimum, in accordance with the ASIL requirements (after decomposition) of ISO 26262-5, except for the evaluation of the hardware architectural metrics and the evaluation of safety goal violations due to random hardware failures (see 5.4.5).

5.4.11 应至少按照GB/T34590.4—2022和GB/T34590.6—2022中(分解后的)ASIL等级要求,在系统层面和软件层面开发分解后的要素。应至少按照GB/T34590.5—2022中(分解后的)ASIL等级要求,在硬件层面开发分解后的要素,但硬件架构度量的评估和因随机硬件失效导致违背安全目标的评估除外(见5.4.5)。

5.4.5 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.
5.4.5 按照GB/T34590.5—2022,对硬件架构度量的评估要求和对由于随机****硬件失效导致违背安全目标的评估要求应在ASIL等级分解后保持不变。

在Part 4中关于安全机制的安全等级，有过说明，

6.4.2.5 本要求适用于ASIL(A)、(B)、C和D等级。仅为了防止双点故障处于潜伏状态而实施的安全
机制的开发应至少符合:
a) ASILB等级(对于分配为ASILD等级的技术安全要求);
b) ASILA 等级(对于分配为ASILB等级和ASILC等级的技术安全要求);
c) QM 等级(对于分配为ASILA 等级的技术安全要求)。
注:如果安全要求运用了ASIL等级分解,那么本章的要求亦适用于分解后的要求。
示例:某内存存储采用奇偶校验作为安全机制,其安全要求被评为ASILB等级。针对用于测试该奇偶校验机制在探测和指示内存故障的能力的自检测试,其要求可被评为ASILA等级。

在Part10 Clause11中明确说明：ASIL分解只针对系统性失效；

The objective of ASIL decomposition is to comply with the safety goal by using multiple sufficiently independent elements with respect to systematic faults.

2. ASIL分解规则

2.1 案例

假设现在有一个舒适性功能，正常情况下驾驶员在车辆静止状态下通过按钮激活，但是如果该功能在车速超过15kph时激活将会造成ASIL C的风险。由此对该功能提出如下需求：

• #R0：The function shall be deactivated for vehicle speed greater than 15km/h

为实现该需求所设计的功能架构如下图所示，关键点为：

• 前端的Controller在接收到驾驶员的按钮请求后会判断当前的车速，当车速小于15kph时允许发出激活请求

• 后端的Actuator在收到来自Controller的激活请求时会进一步判断车速，当车速小于15kph时控制actuator动作
  
  由此引申出两条需求：

• #R1：Controller shall not send an activation command for vehicle speeds greater than 15km/h

• #R2：Actuator switch shall open when vehicle speed is greater than 15km/h

2.2 如何给参与ASIL分解的要素提功能安全需求？

假设#R1的车速监控使用轮速传感器，#R2的车速监控使用变速箱轴速传感器，两个传感器满足独立性要求，因此采取ASIL B©和ASIL A©的分解方式。接下来要对传感器的供应商提功能安全要求。

问题：下面两种释放给供应商的功能安全要求是一样的吗？

• case1: 轮速传感器要求ASIL B©，轴速传感器要求ASIL A©

• case2: 轮速传感器要求ASIL B，轴速传感器要求ASIL A

实际上这两个case的需求是不同的，且这里直接宣布结论：**case2的功能安全需求会造成对随机硬件失效要求的遗漏，**必须避免！

前文中提到，ASIL分解的目的是降低对安全相关的要素的ASIL等级要求，而关于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 A和ASIL A©的区别在于：

• ASIL A：系统性失效的要求和随机硬件失效要求均为ASIL A

• ASIL A©：系统性失效的要求为ASIL A，随机硬件失效要求为ASIL C

根据ISO 26262对随机硬件失效的要求，ASIL A的随机硬件失效是没有指标要求的，说白了就是没有要求。也就是说，直接给变速箱轴速传感器供应商提ASIL A要求，供应商完全可以忽略对变速箱轴速传感器的随机硬件失效的要求，这显然是不合理的，只有当给供应商分配ASIL A©时随机硬件失效要求才会被考虑。 （特别是整体的单点，但是对于分解后的为潜伏）

在这里还有一点需要强调，由于冗余的存在，此时变速箱轴速传感器的单点故障是整个系统的潜伏故障（轮速传感器和变速箱轴速传感器同时失效才会造成ASIL C的风险）。因此对于变速箱轴速传感器供应商而言，只需要按照下表5而不是下表4来进行开发，对传感器单点故障监控的度量只需要满足“≥80%”的指标而不是“≥97%”的指标。

因此从这个角度我们可以说：ASIL分解不会降低对整个系统的随机硬件失效要求，但是可能会降低对组成系统的要素的随机硬件失效要求。

3. ASIL分级如何降低了功能安全开发难度？

本质上每条功能安全需求的ASIL等级属性的背后是对系统性失效和随机硬件失效的要求。

• 随机硬件失效(random hardware failure)：在硬件要素的生命周期中，非预期发生并服从概率分布的失效。
• 系统性失效（systematic failure）：以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。
  -

3.1 对系统性失效的要求

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更加宽松了。

3.2 对随机硬件失效的要求

对随机硬件失效而言， 我们知道ISO 26262要求从以下三个方面的指标衡量随机硬件失效：

• 单点故障度量（single-point fault metric, SPFM）

• 潜伏故障度量(Latent fault metric, LFM）

• 随机硬件失效概率度量(Probabilistic Metric for random Hardware Failures，PMHF)

参考 2.2

对于PMHF的影响：

4. 总结

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

参考：
ref：

https://mp.weixin.qq.com/s/XlY8TJOdQaIQmCyo1biMaw

https://mp.weixin.qq.com/s/wWMlTa3ajvCUS7qqNvR1hw

PMHF 参考：https://ifusa-oss-bucket.oss-cn-shanghai.aliyuncs.com/upload/file/20200706/15b2627f88e876e8038349f69350d79b.pdf