本文将由亚远景iso26262为大家带来ISO26262中的ASIL等级确定与分解(三)。
ASIL分解原则
通过上节介绍的危害分析和风险评估,我们得出系统的安全目标和相应的ASIL等级,从安全目标可以推导出开发阶段的安全需求,安全需求继承安全目标的ASIL等级。如果一个安全需求分解为两个冗余的安全需求,那么原来的安全需求的ASIL等级可以分解到两个冗余的安全需求上。因为只有当两个安全需求同时不满足时,才导致系统的失效,所以冗余安全需求的ASIL等级可以比原始的安全需求的ASIL等级低。ISO 26262标准的第 9 章给出了ASIL分解的原则,如图 1 所示。
分解后的ASIL等级后面括号里是指明原始需求的ASIL等级,比如ASIL D等级分解为ASIL C(D)和ASILA(D)等,因为集成和需求的验证仍然依据其原始的ASIL等级。
ASIL 分解可以在安全生命周期的多个阶段进行,比如功能安全概念、系统设计、硬件设计、软件设计阶段。而且ASIL等级可以分多次进行,比如ASIL D等级分为ASIL C(D)和ASILA(D),ASIL C(D)还可以继续分解为 ASIL B(D)和ASIL A(D )。
但是ASIL 分解的一个最重要的要求就是独立性,如果不能满足独立性要求的话,冗余单元要按照原来的ASIL等级开发。所谓的独立性就冗余单元之间不应发生从属失效(Dependent Failure),从属失效分为共因失效(Common Cause Failure)和级联失效(Cascading Failure) 两种。共因失效是指两个单元因为共同的原因失效,比如软件复制冗余,冗余单元会因为同一个软件bug导致两者都失效,为了避免该共因失效,我们采用多种软件设计方法。级联失效是指一个单元失效导致另一个单元的失效,比如一个软件组件的功能出现故障,写入另一个软件组件RAM中,导致另一个软件组件的功能失效,为了控制该级联失效,我们采用内存管理单元,可以探测到非法写入RAM的情况。
图 1 ASIL分解原理图
下面以一个例子介绍ASIL 分解的过程。
假设功能F,其输入信号为S1,S2,S3,这三个信号分别测量不同的物理量,是相互独立的,经过ECU内部的逻辑运算后,发送触发信息给执行器Actuator,功能F的架构示意图如图 2 所示。假设经过危害分析和风险评估后,功能 F 的ASIL等级为ASIL D,安全目标为避免非预期触发执行器。那么功能 F 的各个部分继承ASIL等级,即传感器、ECU、执行器都需要按照ASIL D 等级开发,如图3所示。
图 2 功能F架构示意图
图 3 ASIL等级在功能F架构上的分配图
经过进一步的分析发现,当速度V>阈值时,非预期触发执行器,才能造成危险。那么我们在功能 F 的架构中,加入一个安全机制,安全机制的功能是当检测到速度V大于阈值时,不允许触发执行器。那么功能F的架构变为如图 4 所示。
图 4 加入安全机制后的架构
功能 F 和安全机制是冗余安全需求,同时来满足安全目标,因此可以将功能 F 原来的ASIL等级在这两个需求上进行分解,分解为ASIL D(D)和QM(D),分解后的 ASIL等级如图5所示。
图 5 ASIL分解后架构示意图
原来的传感器S1、S2、S3按照QM开发,速度传感器按照ASIL D开发,ECU里面的软件,原来的逻辑按QM开发,安全机制的逻辑按照ASIL D开发,不同ASIL等级的软件存在于一个ECU内,为了保证软件之间的独立性,保证两者之间不相互影响,需要考虑内存保护机制,合适的调度属性来保证存储空间和CPU时间的独立性,这样会增加软件开发的很多成本。那么我们进一步采取硬件上的分离来保证独立性,我们选择一个成本很低的简单的芯片(比如PGA, Programmable Gate Array)来运行安全机制中的软件(如图 6 所示)。需要注意的是PGA要使用独立的电源和时钟。
图 6 改进的ASIL分解后架构示意图
经过分解后,按照ASIL D开发的功能逻辑简单,使得开发变得简单,整体成本也得以降低。
结论
本文以EPB为例介绍了ISO 26262标准中安全目标及其ASIL等级确定的方法,安全目标的ASIL等级被开发阶段安全需求继承,如果安全需求的ASIL等级高,那么需要进行ASIL分解以降低ASIL等级,本文以实例介绍了ASIL分解的原则和步骤。ASIL分解并没有在ISO 26262中被强制要求执行,但是我们可以通过对系统进行分析、进而对系统架构进行调整,实现ASIL分解,可以解决因ASIL等级高而带来的开发成本、开发周期和技术要求等方面的问题。
以上就是本文将由亚远景iso26262为大家带来的ISO26262中的ASIL等级确定与分解(三)。