出品 | 焉知
稍微了解功能安全的朋友绝对都听过ASIL分解。毕竟作为ISO 26262官方推荐的降低功能安全开发要求的手段，必然是要被工程师们好好地加以利用的。但是 ASIL分解虽好，却不是简单的加减运算式的“ASIL D 可以分为两个ASIL B或一个ASIL A和一个ASIL C”那么简单，如果在进行分解时忽略了它的前提和规则，将可能造成系统的功能安全漏洞。
基于此背景，本文旨在梳理ASIL分解的理论以及易被忽略的规则，以期为读者提供一些有价值的参考。
1. 什么是ASIL分解？
设想一个场景：养猪场有两个猪圈，一个里面有一头猪X，另一个里面有两头猪Y和Z。如果它们的目标都是用力量冲破猪圈的木栅栏获得自由。显而易见，对X的力量要求比一起合作的Y和Z都高。
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)”。
在ISO 26262, part9第5章中也对ASIL分解原则给出了说明，总结如下表所示。其中QM即Quality Management，表示只要按照企业质量管理流程开发就可以满足ISO 26262要求，没有其他特殊功能安全要求。
表格给人的第一印象是ASIL分解和加减运算有些类似，但是要正确地进行ASIL分解实际上并没有这么简单，还存在着不少容易被忽略的规则。接下来以案例的形式对这些规则以及开发过程中可能遇到的典型问题进行汇总。
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
回到案例上，理论上如果对#R1和#R2进行ASIL分解，有如下选择：
| #R1 | #R2 |
|---|---|
| ASIL C(C) | QM |
| ASIL B(C) | ASIL A(C) |
| ASIL A(C) | ASIL B(C) |
| QM | ASIL C(C) |
但是这两条需求背后的safety machanism都是车速监控，因此车速的计算逻辑是分解成立与否的关键。接下来就接着这个例子进行发散。
2.2. 参与ASIL分解的要素间是否充分独立？
问：假设#R1和#R2对应的车速监控使用的是同一个轮速传感器计算得到的车速信号，分解是否成立？
答：不成立。
ASIL分解本质概念是冗余，冗余就要求不存在共因失效或者级联失效导致互为冗余的元素同时失效。
①. 共因失效Common Cause Failure (CCF)
一个相关项中，由一个单一特定事件或根本原因引起的两个或多个要素的失效。Failure of two or more elements of an item resulting directly from a single specific event or root cause which is either internal or external to all of these elements.
②. 级联失效 cascading failure
同一个相关项中，一个要素的失效引起另一个或多个要素的失效。failure of an element of an item resulting from a root cause [inside or outside of the element] and then causing a failure of another element or elements of the same or different item.
如果参与分解的要素之间存在共因失效或者级联失效，说明要素之间相互影响而不是相互独立，ASIL分解将不成立。
回到开头的问题，如果两个车速监控都使用的是同一个轮速传感器计算，那么轮速传感器失效将直接导致这两个safety machanism同时失效，存在共因失效，因此分解不成立。
如何确定独立性呢？ISO 26262要求对于使用ASIL分解的功能安全概念，必须要通过相关失效分析(DFA, Dependent Failure Analysis)证明分解后的相关元素间相互独立，即证明系统既不存在级联失效，也不存在共因失效。
2.3. 参与ASIL分解的要素间是否存在同构冗余？
问：假设#R1和#R2的车速监控分别使用两个轮速传感器，但两个轮速传感器是同一个厂家的同一个型号，分解是否成立？
答：不成立。
ISO 26262, part9对这种情况进行了说明：
使用同构冗余(如通过复制设备或复制软件)的情况下，考虑到硬件和软件的系统性失效，不能降低ASIL等级，除非相关失效的分析提供了存在充分独立性或潜在共因指向安全状态的证据。因此，同构冗余因缺少要素间的独立性，通常不足以降低ASIL等级。
如何理解这句话呢？功能安全开发的目标本质上就是将系统的系统性失效和随机硬件失效控制在合理范围内，而ASIL分解的目的是降低对安全相关的要素的系统性失效要求，从而降低功能安全开发成本。系统性失效是以确定的方式产生的失效，造成这类失效的系统性故障是设计或生产流程、操作规程、文档或其他相关因素导致的，一旦故障存在，则系统性失效100%会发生。比如软件开发工程师人为误写的一个bug，每次程序运行bug对应的代码100%会输出错误的结果。又比如硬件开发工程师错误地在手册中将“5Ω”的电阻写成了“50Ω”，生产出的硬件也必然是错误的。
回到问题上，如果两个轮速传感器是同一个厂家的同一个型号的传感器，也就意味着它们的开发与生产过程完全一样，如果在这个过程中产生了系统性失效的话，两个传感器的系统性失效也是一模一样的，同样缺少要素间的独立性，因此无法进行ASIL分解。
2.4. 如何给参与ASIL分解的要素提功能安全需求？
假设#R1的车速监控使用轮速传感器，#R2的车速监控使用变速箱轴速传感器，两个传感器满足独立性要求，因此采取ASIL B(C)和ASIL A(C)的分解方式。接下来要对传感器的供应商提功能安全要求。
问题：下面两种释放给供应商的功能安全要求是一样的吗？
- case1: 轮速传感器要求ASIL B(C)，轴速传感器要求ASIL A(C)
- 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(C)的区别在于：
- ASIL A：系统性失效的要求和随机硬件失效要求均为ASIL A
- ASIL A(C)：系统性失效的要求为ASIL A，随机硬件失效要求为ASIL C
根据ISO 26262对随机硬件失效的要求，ASIL A的随机硬件失效是没有指标要求的，说白了就是没有要求。也就是说，直接给变速箱轴速传感器供应商提ASIL A要求，供应商完全可以忽略对变速箱轴速传感器的随机硬件失效的要求，这显然是不合理的，只有当给供应商分配ASIL A(C)时随机硬件失效要求才会被考虑。
在这里还有一点需要强调，由于冗余的存在，此时变速箱轴速传感器的单点故障是整个系统的潜伏故障（轮速传感器和变速箱轴速传感器同时失效才会造成ASIL C的风险）。因此对于变速箱轴速传感器供应商而言，只需要按照下表5而不是下表4来进行开发，对传感器单点故障监控的度量只需要满足“≥80%”的指标而不是“≥97%”的指标。
因此从这个角度我们可以说：ASIL分解不会降低对整个系统的随机硬件失效要求，但是可能会降低对组成系统的要素的随机硬件失效要求。
本文转自：焉知自动驾驶，转载此文目的在于传递更多信息，版权归原作者所有。如不支持转载，请联系小编demi@eetrend.com删除。
