搜索
ISO26262中的ASIL等级确定与分解北京经纬恒润科技有限公司【摘要】根据标准ISO26262，对安全相关系统进行设计时，首先要对系统进行危害分析和风险评估，以确定安全目标和相应的汽车安全完整性等级(ASIL)，然后将ASIL等级分配到系统的组件上。由于成本、时间、技术上的限制等原因需要降低ASIL等级时，应考虑组件冗余，进行ASIL分解。本文以一些实际的例子介绍了标准ISO26262中的ASIL等级确定方法和分解原则。【关键词】ASIL等级ASIL分解ISO26262ASILLevelClassificationandDecompositioninISO26262BeijingJingweiHirainTechnologiesCo.,LtdAbstract:AccordingtoISO26262,thesafetyrelatedsystemshouldbefirstlysubjecttohazardanalysisandriskassessmentinordertodeterminethesafetygoalandthecorrespondingAutomotiveSafetyIntegrationLevel(ASIL),whichisallocatedtosystemcomponents.ItthecasethattheASILlevelshouldbeloweredduetotherestrictionofcost,developmenttimeandtechnology,etc.,theASILdecopositionappliedonthetheredundantcomponentisconsiderd.Inthispaper,theASILlevelclassificationandASILdecompositionprincipleareintroducedbasedonseveralexamples.Keywords:ASIL,ASILDecomposition,ISO262621引言汽车上电子/电气系统（E/E）数量不断的增加，一些高端豪华轿车上有多达70多个ECU（ElectronicControlUnit电子控制单元），其中安全气囊系统、制动系统、底盘控制系统、发动机控制系统以及线控系统等都是安全相关系统。当系统出现故障的时候，系统必须转入安全状态或者转换到降级模式，避免系统功能失效而导致人员伤亡。失效可能是由于规范错误(比如安全需求不完整)、人为原因的错误(比如：软件bug)、环境的影响(比如：电磁干扰)等等原因引起的。为了实现汽车上电子/电气系统的功能安全设计，道路车辆功能安全标准ISO26262[1]于2011年正式发布，为开发汽车安全相关系统提供了指南，该标准的基础是适用于任何行业的电子/电气/可编程电子系统的功能安全标准IEC61508[2]。ISO26262标准中对系统做功能安全设计时，前期重要的一个步骤是对系统进行危害分析和风险评估，识别出系统的危害并且对危害的风险等级——ASIL等级（AutomotiveSafetyIntegrationLevel，汽车安全完整性等级）进行评估。ASIL有四个等级，分别为A，B，C，D，其中A是最低的等级，D是最高的等级。然后，针对每种危害确定至少一个安全目标，安全目标是系统的最高级别的安全需求，由安全目标导出系统级别的安全需求，再将安全需求分配到硬件和软件。ASIL等级决定了对系统安全性的要求，ASIL等级越高，对系统的安全性要求越高，为实现安全付出的代价越高，意味着硬件的诊断覆盖率越高，开发流程越严格，相应的开发成本增加、开发周期延长，技术要求严格。ISO26262中提出了在满足安全目标的前提下降低ASIL等级的方法——ASIL分解，这样可以解决上述开发中的难点。本文首先介绍了ISO26262标准中的危害分析和风险评估阶段中的ASIL等级确定方法，然后介绍了ASIL分解的原则，并辅以实例进行说明。2危害分析和风险评估依据ISO26262标准进行功能安全设计时，首先对系统的功能进行逐个分析，识别系统所有的危害，然后依据三个因子——严重度（Severity）、暴露率（Exposure）和可控性（Controllability）评估危害的风险级别ASIL等级。其中严重度是指对驾驶员、乘员、或者行人等涉险人员的伤害程度；暴露率是指人员暴露在系统的失效能够造成危害的场景中的概率；可控性是指驾驶员或其他涉险人员能够避免事故或伤害的可能性。这三个因子的分类在表1中给出。表1严重度、暴露率、可控性分类严重度暴露率可控性S0无伤害E1很低的概率C0完全可控S1轻度和中度伤害E2低概率（1%）C1简单可控(99%驾驶员)S2严重伤害（有生还可能）E3中度概率（1%-10%）C2一般可控（90%驾驶员）S3致命伤害E4高概率(10%）C3很难控制（90%驾驶员）ASIL等级的确定基于这三个影响因子，表2中给出了ASIL的确定方法，其中D代表最高等级，A代表最低等级，QM表示质量管理（QualityManagement），表示按照质量管理体系开发系统或功能就足够了，不用考虑任何安全相关的设计。确定了危害的ASIL等级后，为每个危害确定至少一个安全目标，作为功能和技术安全需求的基础。表2ASIL等级确定严重度暴露率可控性C1C2C3S1E1QMQMQME2QMQMQME3QMQMAE4QMABS2E1QMQMQME2QMQMAE3QMABE4ABCS3E1QMQMAE2QMABE3ABCE4BCD下面以EPB（ElectricalParkBrake）系统为例介绍如何进行危害分析和风险评估。EPB较传统的驻车制动器，除了驻车功能，还有动态起步辅助功能、紧急制动功能以及自动驻车功能等。这里我们以驻车功能为例，当驻车时，驾驶员通过按钮或其它方式发出制动请求，EPB系统在汽车的后轮上施加制动力，以防止车非预期滑行。该系统的危害有：非预期制动失效、非预期制动启动。相同的危害在不同的场景下的风险是不一样的，所以我们要对不同的驾驶场景进行分析。为了简化问题，这里我们仅对非预期制动失效进行风险评估。表3给出了EPB风险评估表，在该表中我们考虑的驾驶场景是车停在斜坡上，驾驶员不在车上。如果驾驶员在车上的话，驾驶员可通过踩刹车控制汽车滑行，可控性增加，那么所评估的ASIL等级会比表中的ASILD低。表3EPB风险评估危害非预期制动失效驾驶场景车停在斜坡上、驾驶员不在车上可控性分类说明驾驶员不在车上，不具备可控性分类值C3严重度分类说明车突然滑行，或者偏离车道、会对行人造成严重伤害分类值S3暴露率分类说明驾驶场景“斜坡停车，且驾驶员不在车上”占车整个行驶寿命的比例10%分类值E4ASILD通过以上分析，得出EPB系统的安全目标为：防止非预期制动，ASIL等级为D。3ASIL分解原则通过上节介绍的危害分析和风险评估，我们得出系统的安全目标和相应的ASIL等级，从安全目标可以推导出开发阶段的安全需求，安全需求继承安全目标的ASIL等级。如果一个安全需求分解为两个冗余的安全需求，那么原来的安全需求的ASIL等级可以分解到两个冗余的安全需求上。因为只有当两个安全需求同时不满足时，才导致系统的失效，所以冗余安全需求的ASIL等级可以比原始的安全需求的ASIL等级低。ISO26262标准的第9章给出了ASIL分解的原则，如图1所示。图1ASIL分解原则图分解后的ASIL等级后面括号里是指明原始需求的ASIL等级，比如ASILD等级分解为ASILC(D)和ASILA(D)等，因为集成和需求的验证仍然依据其原始的ASIL等级。ASIL分解可以在安全ASIL B(D) ASIL D ASIL B(D) ASIL D(D) ASIL D QM(D) ASIL C(D) ASIL A(D) ASIL D ASIL D ASIL B(C) ASIL C ASIL A(C) ASIL C(C) ASIL C QM(C) ASIL C ASIL A(B) ASIL B ASIL A(B) ASIL B(B) ASIL B QM(B) ASIL B ASIL A(A) ASIL A QM(A) ASIL A 生命周期的多个阶段进行，比如功能安全概念、系统设计、硬件设计、软件设计阶段。而且ASIL等级可以分多次进行，比如ASILD等级分为ASILC(D)和ASILA(D)，ASILC(D)还可以继续分解为ASILB(D)和ASILA(D)。但是ASIL分解的一个最重要的要求就是独立性，如果不能满足独立性要求的话，冗余单元要按照原来的ASIL等级开发。所谓的独立性就冗余单元之间不应发生从属失效，从属失效分为共因失效和级联失效两种。共因失效是指两个单元因为共同的原因失效，比如软件复制冗余，冗余单元会因为同一个软件bug导致两者都失效，为了避免该共因失效，我们采用多种软件设计方法。级联失效是指一个单元失效导致另一个单元的失效，比如一个软件组件的功能出现故障，写入另一个软件组件RAM中，导致另一个软件组件的功能失效，为了控制该级联失效，我们采用内存管理单元，可以探测到非法写入RAM的情况。下面以一个例子介绍ASIL分解的过程。假设功能F，其输入信号为S1，S2，S3，这三个信号分别测量不同的物理量，是相互独立的，经过ECU内部的逻辑运算后，发送触发信息给执行器Actuator，功能F的架构示意图如图2所示。假设经过危害分析和风险评估后，功能F的ASIL等级为ASILD，安全目标为避免非预期触发执行器。那么功能F的各个部分继承ASIL等级，即传感器、ECU、执行器都需要按照ASILD等级开发，如图3所示。图2功能F架构示意图图3ASIL等级在功能F架构上的分配图经过进一步的分析发现，当速度V阈值时，非预期触发执行器，才能造成危险。那么我们在功能F的架构中，加入一个安全机制，安全机制的功能是当检测到速度V大于阈值时，不允许触发执行器。那么功能F的架构变为如图4所示。图4加入安全机制后的架构功能F和安全机制是冗余安全需求，同时来满足安全目标，因此可以将功能F原来的ASIL等S1 S2 S3 ECU Actuator S1 S2 S3 ECU Actuator ASIL D ASIL D ASIL D ASIL DASIL DS1 S2 S3 ECU Actuator ASIL D ASIL D ASIL D ASIL DASIL DV 级在这两个需求上进行分解，分解为ASILD(D)和QM(D)，分解后的ASIL等级如图5所示。图5ASIL分解后架构示意图原来的传感器S1、S2、S3按照QM开发，速度传感器按照ASILD开发，ECU里面的软件，原来的逻辑按QM开发，安全机制的逻辑按照ASILD开发，不同ASIL等级的软件存在于一个ECU内，为了保证软件之间的独立性，保证两者之间不相互影响，需要考虑内存保护机制，合适的调度属性来保证存储空间和CPU时间的独立性，这样会增加软件开发的很多成本。那么我们进一步采取硬件上的分离来保证独立性，我们选择一个成本很低的简单的芯片（比如PGA,ProgrammableGateArray）来运行安全机制中的软件（如图6所示）。需要注意的是PGA要使用独立的电源和时钟。图6改进的ASIL分解后架构示意图经过分解后，按照ASILD开发的功能逻辑简单，使得开发变得简单，整体成本也得以降低。4结论本文以EPB为例介绍了ISO26262标准中安全目标及其ASIL等级确定的方法，安全目标的ASIL等级被开发阶段安全需求继承，如果安全需求的ASIL等级高，那么需要进行ASIL分解以降低ASIL等级，本文以实例介绍了ASIL分解的原则和步骤。ASIL分解并没有在ISO26262中被强制要求执行，但是我们可以通过对系统进行分析、进而对系统架构进行调整，实现ASIL分解，可以解决因ASIL等级高而带来的开发成本、开发周期和技术要求等方面的问题。参考文献[1]ISO26262:2011-Roadveh