MUNIK解读ISO26262：什么是ASIL分解

—原创文章，文章内所有内容文字资料，版权均属本公众号所有，任何媒体、网站、公众号或个人未经本公众号授权不得转载、转贴、引用或以其他方式复制发布 、发表。已经本公众号授权的媒体、网站、公众号、个人，在下载使用时必须注明来源，违者本公众号将依法追究相关责任.

 

回到本文的源头文章“ISO26262标准解读”，请点击链接：ISO26262 Functional Safety of Automotive汽车功能安全服务

回到Munik知识普及课堂，请点击链接：MUNIK中国-技术分享

 

对于功能安全产品的开发而言，当整车层级通过Item Definition, HARA将安全目标（SG）推导出来以后，想将其实现最直接的方式就是内部所有的组件都按照安全目标的等级进行开发，换言之就是SG是ASIL D, 下游的系统，硬件，软件组件被分配的TSR,HSR,SSR都是ASIL D。但实际上由于高等级的安全要求在有些时候想直接实现难度确实相当大，但又不能因此阻碍功能安全的开发工作，所以标准引入了ASIL 分解的概念。

 

1. 什么是ASIL分解？

 

ASIL分解是降低功能安全开发要求的一种方法，它的主要特点就是将一条高标准的安全要求分解成两个独立且易于实现的要求，并将分解后的这两个要求分配到互相独立的要素上, 同时独立要素合力实现的功能要满足初始安全要求。标准对于ASIL分解有专门的表示方法，如ASIL X(Y)，这里的Y表示分解前的原始ASIL等级，X表示分解后的ASIL等级，例如一个ASILD的安全要求分解成一个ASILC和一个ASIL A,则应标注成“ASIL C(D)”和“ASIL A(D)”。而在ISO 26262, part9第5章对于ASIL分解有专门的分解规则（见下图），

 

 

这里大家理解的时候可以类比QM=0，ASIL A=1，ASIL B=2，ASIL C=3，ASIL D=4。值得注意的一点就是，当原始需求ASIL分解预期功能和安全机制这两个方面时，安全机制宜被分配分解后的较高 ASIL等级。

注：ASIL分解的时候原始需求一次只能分配为两个新需求。

 

2. 分解后的要素独立性要得到满足

 

在上面我们提到了ASIL分解要将分解后的需求分配到相互独立的要素上，这是一个必须满足的条件，因为ASIL分解本质概念是冗余，冗余就要求组件之间不存在共因失效或者级联失效，那么怎么来证明要素之间互相冗余？标准这里就要求ASIL分解后的两个要素之间要进行相关失效分析（DFA）,用来判断要素之间是否存在共因失效或者级联失效。关于DFA的相关问题可以查阅我们之前的文章《什么是DFA》。

这里有必要说明一下，冗余并非是直接使用两个相同的组件互相备份，这种直接复制组件的方式称为同构冗余，同构冗余的两个组件是缺乏要素间的独立性的，因为同样的组件大概率是会存在相同的系统性失效，而系统性失效是我们在开发功能安全产品时是要尽可能避免的，所以一般会采用功能相同，设计存在明显区别的组件进行互相冗余。

 

3.ASIL分解为什么能降低开发难度？

 

功能安全设计本质上是为了控制和解决两种失效情况，分别是系统性失效和随机失效，我们分别从这两个方面进行了解。

 

a)系统性失效：以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。

ISO 26262对系统性失效的要求存在于相关项的各个层级，硬件元器件层(HW part level)、软件单元层(SW-Unit level)、组件层(component level)和系统层(system level)。而且从上面系统性失效的定义可以看出，ISO 26262对系统性失效的要求本质上可以理解为对设计流程和验证流程的要求。

这一点我们在建立功能安全流程体系时制定的各种指南，流程性文件来对活动进行约束，包括严格按照V模型概念实施验证活动都是为了避免发生系统性失效。

从验证工作数量上举个例子：假如某硬件组件原始被分配的安全需求为ASIL D，通过ASIL分解后为该硬件组件增加了一个ASILB（D）的安全机制，而该硬件组件按照ASIL B(D)的要求限制系统性失效就可以，降低了开发难度和成本，对应到下图中可以看到ASIL B比ASIL D要求更为宽松。

 

b)随机失效：非预期发生并服从概率分布的失效，一般由器件材料老化，环境变化等原因造成。

对于随机失效，标准用三个量化指标进行衡量，分别是单点故障度量（SPFM）

 

 

潜伏故障度量（LFM）

 

随即硬件失效概率度量(PMHF) 

 

对于整个产品而言，不管是内部有没有进行ASIL分解，这三个指标的要求都不会改变。但是对于产品内部的组件而言就不太一样了，举例产品中的硬件组件X原始安全要求是ASIL D,并且其的失效会直接影响产品的安全目标，那么其对应的架构度量应该为

 

而分解后由硬件组件Y ASIL B(D)以及安全机制Z ASIL B（D）来实现，因为Y和Z是互相冗余且独立的，所以不再属于单点故障，而属于多点失效，其架构度量应属于

综上可知，ASIL 分解是可以降低功能安全开发难度甚至成本，但降低开发难度和成本仅限于这两个独立的子要素，对于整体硬件集成、验证和认可措施等活动，仍然需要按初始ASIL等级的要求来开展(比如对ASILD的硬件系统，在认可措施活动中需要有最高的独立性要求

 

4. 示例

 

现在我们通过一个简单的示例对ASIL分解进行梳理。

 

l导出SG

假设整车层面的EPB(电子驻车制动系统)功能，它的实现依赖多个传感器对不同物理量的测量，例如S1(刹车/油门踏板传感器),S2(驻车按钮),S3(姿态传感器),S4(发动机转速传感器)，S5(车速传感器)上传给ECU进行运算并发送指令给执行器A(EPB卡钳)。

 

经过HARA分析后，汽车在高速行驶过程中可能会误触驻车按钮导致非预期的刹车，从而危及人身安全，因此制定安全目标1(SG1)：“避免在车速≥80km/h时非预期触发执行器而对人员造成伤害”。ASIL等级为D,功能实现架构图及ASIL等级分布示意图如下：

 

 

l分配SG

根据SG1我们可得出以下FSR：

1) FSR1:传感器S5应提供正确的车速信息给ECU1---ASIL D;

2)FSR2:当车速≥80km/h 时，ECU1不再向EPB卡钳供电---ASIL D;

3)FSR3:EPB卡钳只有在得到ECU1供电之后才能动作，进行刹车---ASIL D;

 

l增加安全机制迭代后的功能安全要求

因为ECU1处理的信息较多，为了降低开发难度并实现安全要求，我们在架构设计中为车速信息处理增加了监测机制，原有的ECU1执行功能层面的数据处理，优化后的架构功能及ASIL等级如下：

1) FSR1:传感器S5提供正确的车速信息给ECU1和ECU2---ASIL D;

2)  FSR2-1:ECU1接受S1-S5的信息，用来判断是否发送刹车信号给ECU2---QM（D）;

3) FSR2-2:ECU2处理S5以及ECU1的信息。当S5的信息显示车速≥80km/h时，ECU2不会向卡钳供电；当S5的信息显示车速＜80km/h时，ECU有刹车请求，ECU2给卡钳供电。---ASIL D(D);

4) FSR3:EPB卡钳只有在ECU2为其供电时才工作进行刹车动作---ASIL D

 

 

注：

l当然这里仅仅是围绕着SG1展开的分解，现实中的ECU1承担的功能和安全需求不会只有一条，最终开发等级还是要按照所涉及的安全要求中最高的ASIL等级进行开发。

FSR的迭代关系如下表：

 

 

 

这样又有一个问题那就是设计中同时存在了QM和ASIL D（要素共存的问题），那么就要考虑相关失效可能会造成的影响，也就是最起码确保ECU1和ECU2相互独立，这里又回到了我们之前的文章“什么是DFA”。

以上就是一个比较简单的处理部分的ASIL分解示例，其他方面也可能会同时存在ASIL分解，比如车速传感器部分可以采用冗余设计。