ASIL等级确定与分解
1. 引⾔
汽车上电⼦/电⽓系统（E/E）数量不断的增加，⼀些⾼端豪华轿车上有多达70多个ECU（Electronic Control Unit电⼦控制单元），其中安全⽓囊系统、制动系统、底盘控制系统、发动机控制系统以及线控系统等都是安全相关系统。当系统出现故障的时候，系统必须转⼊安全状态或者转换到降级模式，避免系统功能失效⽽导致⼈员伤亡。失效可能是由于规范错误(⽐如安全需求不完整)、⼈为原因的错误(⽐如：软件bug)、环境的影响( ⽐如：电磁⼲扰)等等原因引起的。为了实现汽车上电⼦/电⽓系统的功能安全设计，道路车辆功能安全标准 ISO 26262[1]于2011年正式发布，为开发汽车安全相关系统提供了指南，该标准的基础是适⽤于任何⾏业的电⼦/电⽓/可编程电⼦系统的功能安全标准IEC 61508[2]。
ISO 26262标准中对系统做功能安全设计时，前期重要的⼀个步骤是对系统进⾏危害分析和风险评估，识别出系统的危害并且对危害的风险等级——ASIL等级（Automotive Safety Integration Level，汽车安全完整性等级）进⾏评估。ASIL有四个等级，分别
为A，B，C，D，其中A是最低的等级，D是最⾼的等级。然后，针对每种危害确定⾄少⼀个安全⽬标，安全⽬标是系统⾼级别的安全需求，由安全⽬标导出系统级别的安全需求，再将安全需求分配到硬件和软件。ASIL等级决定了对系统安全性的要求，ASIL等级越⾼，对系统的安全性要求越⾼，为实现安全付
出的代价越⾼，意味着硬件的诊断覆盖率越⾼，开发流程越严格，相应的开发成本增加、开发周期延长，技术要求严格。ISO 26262中提出了在满⾜安全⽬标的前提下降低ASIL等级的⽅法——ASIL分解，这样可以解决上述开发中的难点。
本⽂⾸先介绍了ISO 26262标准中的危害分析和风险评估阶段中的ASIL等级确定⽅法，然后介绍了ASIL分解的原则，并辅以实例进⾏说明。
2. 危害分析和风险评估
依据ISO 26262标准进⾏功能安全设计时，⾸先识别系统的功能，并分析其所有可能的功能故障（Malfunction），可采⽤的分析⽅法有HAZOP，FMEA、头脑风暴等。如果在系统开发的各个阶段发现在本阶段没有识别出来的故障，都要回到这个阶段，进⾏更新。功能故障在特定的驾驶场景下，才会造成伤亡事件，⽐如近光灯系统，其中⼀个功能故障就是灯⾮预期熄灭，如果在漆⿊的夜晚⾏驶在⼭路上，驾驶员看不清道路状况，可能会掉⼊悬崖，造成车毁⼈亡；如果此功能故障发⽣在⽩天就不会产⽣任何的影响。所以进⾏功能故障分析后，要进⾏情景分析，识别与此故障相关的驾驶情景，⽐如：⾼速公路超车、车库停车等。分析驾驶情景建议从公路类型：⽐如国道、城市道路、乡村道路等；路⾯情况：⽐如湿滑路⾯、冰雪路⾯、⼲燥路⾯；车辆状态：⽐如转向、超车、制动、加速等；环境条件：⽐如：风雪交加、夜晚、隧道灯；交通状况：拥堵、顺畅、红绿灯等；⼈员情况：不如乘客、路⼈等⼏个
⽅⾯去考虑。功能故障和驾驶场景的组合叫做危害事件（hazard event），危害事件确定后，根据三个因⼦——严重度（Severity）、暴露率（Exposure）和可控性（Controllability）评估危害事件的风险级别——ASIL等级。其中严重度是指对驾驶员、乘员、或者⾏⼈等涉险⼈员的伤害程度；暴露率是指⼈员暴露在系统的失效能够造成危害的场景中的概率；可控性是指驾驶员或其他涉险⼈员能够避免事故或伤害的可能性。这三个因⼦的分类在表1中给出。
表1 严重度、暴露率、可控性分类
ASIL等级的确定基于这三个影响因⼦，表2中给出了ASIL的确定⽅法，其中D代表最⾼等级， A代表最低等级，QM表⽰质量管理（Quality Management），表⽰按照质量管理体系开发系统或功能就⾜够了，不⽤考虑任何安全相关的设计。确定了危害的ASIL等级后，为每个危害确定⾄少⼀个安全⽬标，作为功能和技术安全需求的基础。
表2 ASIL等级确定
下⾯以EPB（Electrical Park Brake）系统为例介绍如何进⾏危害分析和风险评估。
EPB较传统的驻车制动器，除了驻车功能，还有动态起步辅助功能、紧急制动功能以及⾃动驻车功能等。这⾥我们以驻车功能为例，当驻车时，驾驶员通过按钮或其它⽅式发出制动请求，EPB系统在汽车的后轮上施加制动⼒，以防⽌车⾮预期滑⾏。该系统的危害有：⾮预期制动失效、⾮预期制动启动。相同的危害在不同的场景下的风险是不⼀样的，所以我们要对不同的驾驶场景进⾏分析。为了简化问题，这⾥我们仅对”⾮预期制动失效”这种功能故障进⾏风险评估。表3给出了EPB风险评估表，在该表中我们考虑的驾驶场景是车停在斜坡上，驾驶员不在车上。如果驾驶员在车上的话，驾驶员可通过踩刹车控制汽车滑⾏，可控性增加，那么所评估的ASIL等级会⽐表中的ASIL
D低，但是对于同⼀个安全⽬标，如果评估的ASIL等级不同的话，要选择ASIL等级⾼的那个。
表3 EPB风险评估
通过以上分析，得出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的情况。
图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开发的功能逻辑简单，使得开发变得简单，整体成本也得以降低。
4. 结论
本⽂以EPB为例介绍了ISO 26262标准中安全⽬标及其ASIL等级确定的⽅法，安全⽬标的ASIL等级被开发阶段安全需求继承，如果安全需求的ASIL等级⾼，那么需要进⾏ASIL分解以降低ASIL等级，本⽂以实例介绍了ASIL分解的原则和步骤。ASIL分解并没有在ISO 26262中被强制要求执⾏，但是我们可以通
过对系统进⾏分析、进⽽对系统架构进⾏调整，实现ASIL分解，可以解决因ASIL等级⾼⽽带来的开发成本、开发周期和技术要求等⽅⾯的问题。