浅谈汽车ISO 26262安全标准架构及分解

EPB较传统的驻车制动器，除了驻车功能，还有动态起步辅助功能、紧急制动功能以及自动驻车功能等。这里我们以驻车功能为例，当驻车时，驾驶员通过按钮或其它方式发出制动请求，EPB系统在汽车的后轮上施加制动力，以防止车非预期滑行。该系统的危害有：非预期制动失效、非预期制动启动。相同的危害在不同的场景下的风险是不一样的，所以我们要对不同的驾驶场景进行分析。为了简化问题，这里我们仅对"非预期制动失效"这种功能故障进行风险评估。表3给出了EPB风险评估表，在该表中我们考虑的驾驶场景是车停在斜坡上，驾驶员不在车上。如果驾驶员在车上的话，驾驶员可通过踩刹车控制汽车滑行，可控性增加，那么所评估的ASIL等级会比表中的ASIL D低，但是对于同一个安全目标，如果评估的ASIL等级不同的话，要选择ASIL等级最高的那个。

　　通过以上分析，得出EPB系统的安全目标为：防止制动失效，ASIL等级为D。

　　3. 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的情况。

　　下面以一个例子介绍ASIL 分解的过程。

　　假设功能F，其输入信号为S1，S2，S3，这三个信号分别测量不同的物理量，是相互独立的，经过ECU内部的逻辑运算后，发送触发信息给执行器Actuator，功能F的架构示意图如图2所示。假设经过危害分析和风险评估后，功能F的ASIL等级为ASIL D，安全目标为避免非预期触发执行器。那么功能F的各个部分继承ASIL等级，即传感器、ECU、执行器都需要按照ASIL D 等级开发，如图3所示。

　　经过进一步的分析发现，当速度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开发的功能逻辑简单，使得开发变得简单，整体成本