功能安全学习笔记002-功能安全的定义

1，功能安全的定义

1.1 本质安全与功能安全

为了了解功能安全的概念，先得熟悉下 和“本质安全”和“功能安全”的概念。

假如以铁道的路口为例，比较一下基于两种安全概念的避免路口事故的方法。这里避免路口事故就是安全目标，为了实现这个目标，可进行如下操作：

首先，如果把铁道路口撤掉，直接改造成立交桥的形式，让火车和汽车都走各自的路，这样就不会发生人或者车辆横穿铁道口的事故了。像这样，根据系统的特性把危险源直接除掉的方法是「本质安全」。

                                                                           

其次，假如我们在铁道路口设置信号灯和道口自动栏杆，当火车来临时前闪红灯，同时将栏杆放下，避免行人或者车辆通过。像这样通过栏杆的拦截功能及预警灯来抑制事故风险的技术叫做「功能安全」。在这里信号灯和自动栏杆一种安全机制（Safety Mechanism）。理想的情况是不管什么场合都采用 「本质安全」，但事实上，在很多场合里，由于系统自身的原因，不可能把危险源除掉。特别是像车载电控系统这样非常复杂的电子化系统，以上所述的本质安全很难被实现和应用。因此我们只能采用功能安全，它的目的就是在本质安全无法达到时，尽可能的通过增加安全机制去提高安全等级，实现安全目标。

1.2 电子控制器的功能安全

对于汽车而言，可将汽车看成一个“机器人”，驾驶员给这个“机器人”发送信号，比如踩踏板加油，汽车收到命令然后执行：电喷系统增加喷油，发动机输出扭矩增加，实现车辆加速。

对于传统汽车而言，它的结构简单，且大多数命令都是通过机械方式来实现的，如老式汽车的机械式节气门等，其失效的可预见性大；而现在汽车，其电子电气化增强，驾驶员的指令会先转换成相关信号，然后这些信号传递给控制器的处理芯片，然后最终驱动相关的执行器来执行，其失效的可预见性大大降低。

   

正因为现代汽车随着电子电气化的程度越来越高，其整车的安全性很大程度就取决于电子控制器的安全性，比如发动机控制器ECU，变速箱控制器TCU，车辆稳定性控制器ESP等等。而且电子控制器失效的可预见性非常低，比如芯片／电路受外界干扰等，这很难预料什么情况会出问题。  因此必须考虑电子控制器失效了会怎么办的问题。

1.3 功能安全考虑的角度

针对电子控制器失效了怎么办这个问题，首先得确定一个角度。比如极端高温情况下的ECU自燃，爆炸等这种系统本身带来的风险，这种风险不在功能安全的考虑范围内。

从产品安全的角度来说，可将其安全分为传统安全以及由电子/电气功能安全，传统安全包括：与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由电子电气安全相关系统的故障行为而引起的。传统安全不在功能安全的考虑范围之内。

  

根据国际上知名的安全协会的定义，比如英国的MISARA（The Motor Industry Software Reliability Association 汽车工业软件可靠性协会），比如德国的德国VDA协会（VDA（Verband der Automobilindutrie）德国汽车工业协会）他们是从车辆可控性的角度对功能安全提出要求。而IEC-61508强调从人身安全（还可以考虑设备安全）角度提出需求。

因此从车辆可控性和人身安全两个层面上考虑功能安全就有了着陆点。比如考虑是不是有非驾驶员期望的加速等，而非驾驶员期望的减速其实是降低了安全边界，但车辆扔被驾驶员控制着。这就是为什么ECU不对相关控制器的减扭做监控的原因。

1.4 ISO26262中对功能安全的定义

ISO 26262是专门用作提升汽车电子电气产品功能安全的国际标准，它派生于电子、电气及可编程器件功能安全基本标准IEC61508。那26262是如下定义功能安全这个概念的：

English definition:absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems；

没有由电子、电气系统故障行为导致的危险所引起的不合理风险。

我们来分解下这段话：

A.没有风险：absence of risk

B.没有不合理风险 unreasonable

C.没有由电子、电气系统故障行为导致的危险所引起的不合理风险

其中的关键词是不合理风险，什么是不合理风险呢，比如车辆行驶时安全气囊蹦出来了，这是不合理风险，这是功能安全需要避免的问题。

                                                

总体来说，功能安全是指避免由系统功能性故障导致的不可接受的风险。它关注的是系统发生故障之后的行为，而不是系统的原有功能或性能。因此功能安全的目的就是当系统发生故障后，将系统进入安全的可控模式，避免对人身、财产造成伤害。

2，ASIL汽车安全完整性等级

2.1 危险事件的确定

对电子控制器ECU来说，引起失效主要是两个方面：软件和硬件。

软件失效：比如没有考虑分母可能为0；变量公式定义错误，导致精度丢失；

硬件失效：如下图所示可以分为传感器失效；ECU硬件失效（比如CPU或者RAM/ROM失效）；执行器失效；

        

依据ISO 26262标准进行功能安全设计时，首先识别系统的功能，并分析其所有可能的功能故障（Malfunction）或失效，可采用的分析方法有HAZOP，FMEA、头脑风暴等。

功能故障在特定的驾驶场景下才会造成伤亡事件，比如近光灯系统，其中一个功能故障就是灯非预期熄灭，如果在漆黑的夜晚行驶在山路上，驾驶员看不清道路状况，可能会掉入悬崖，造成车毁人亡；如果此功能故障发生在白天就不会产生任何的影响。

所以进行功能故障分析后，要进行情景分析，识别与此故障相关的驾驶情景，比如：高速公路超车、车库停车等。分析驾驶情景建议从公路类型（国道，高速），路面情况，（湿滑、冰雪）；车辆状态（转向、 超车、制动、加速等），环境条件（风雪雨尘、夜晚、隧道灯），人员情况（乘客、路人）等几个方面去考虑。功能故障和驾驶场景的组合叫做危害事件（hazard event）。

危害事件确定后，根据三个因子——严重度（Severity）、暴露率（Exposure）和可控性（Controllability）评估危害事件的风险级别——也就是ASIL等级。

2.2 ASIL等级

ASIL等级的定义是为了对失效后带来的风险进行评估和量化以达到安全目标，其全称是Automotive Safety Integration Level--汽车安全完整性等级。这个概念来源于IEC61508，其通过失效概率的方式定义了安全完整性等级（SIL）。但是在汽车界只有硬件随机失效可以通过统计数字评估失效概率，软件失效却难以量化，因此26262根据汽车的特点定义了ASIL。

如上节所述ASIL的评定，一般是在产品概念设计阶段对系统进行危害分析和风险评估，识别出系统的危害，如果系统的安全风险越大，对应的安全要求级别就越高，其具有的ASIL的等级也越高。ASIL分为QM，A、B、C、D五个等级，ASIL D是最高的汽车安全完整性等级，对功能安全的要求最高。

2.3 危险分析和风险评定

对于汽车系统，特定危险的风险决定于以下三个因素：

A.危险事件所导致伤害或损失的潜在严重性 (Severity of failure, S) 

B.指人员暴露在系统失效能够造成危害的场景中的概率OR理解为危险事件可能发生的驾驶工况的可能性 (probability of exposure, 简称E) 

C.危险所涉及的驾驶员和其它交通人员通过及时的反应避免特定伤害或损失的能力 (controllability, 简称C)

   

然后分别将严重性S、可能性E和可控性C分成4个等级，如下表所示，其中QM代表与安全无关：

 

按照以上的划分并进行组合相加得到5个ASIL等级（QM，A，B，C，D），原则是：

A. 基本可控C0的组合不考虑；

B. 无伤害S0的组合不考虑；

C. 其余组合相加等于7分为ASIL A，等于8分为ASIL B，等于9分为ASIL C，等于10分为最高等级ASIL D；ASIL A、B、C、D都是与功能安全相关的（Safety Relevant Function）

D. 其余的得分安全评定为QM，代表与安全无关的功能（Non Safety Relevant Function）

   

下面举几个例子进行说明：

1，EPB（Electrical Park Brake）电子手刹

以电子手刹的驻车功能为例，当驻车时，驾驶员通过按钮或者其他方式触发制动请求，EPB在汽车的后轮上施加制动力，以防止车非期望的滑行。该系统的危害有非期望的制动失效，非期望的制动启动。相同的危害在不同场景下风险也是不一样的，因此也要对不同场景进行分析。分析如下表所示：

  

得出了EPB系统的安全目标为：防止非期望的制动，ASIL等级为D

根据上面的分析，不难得出其它例子的ASIL 等级，比如：

 

2.4 功能安全目标的分解

通过上危害分析和风险评估，我们得出系统或功能的安全目标和相应的ASIL等级，当ASIL等级确定之后，就需要对每个评定的风险确定安全目标，安全目标是最高级别的安全需求。安全目标确定以后就需要在系统设计，硬件，软件等方面进行设计和实施，验证。

从安全目标可以推导出开发阶段的安全需求，安全需求继承安全目标的ASIL等级。如果一个安全需求分解为两个冗余的安全需求，那么原来的安全需求的ASIL等级可以分解到两个冗余的安全需求上。因为只有当两个安全需求同时不满足时，才导致系统的失效，所以冗余安全需求的ASIL等级可以比原始的安全需求的ASIL等级低。ISO 26262标准的第9章给出了ASIL分解的原则。ISO 26262中提出了在满足安全目标的前提下降低ASIL等级的方法——ASIL分解，这样可以解决上述开发中的难点。

ASIL 分解的一个最重要的要求就是独立性，如果不能满足独立性要求的话，冗余单元要按照原来的ASIL等级开发。所谓的独立性就冗余单元之间不应发生从属失效（Dependent Failure），从属失效分为共因失效（Common Cause Failure）和级联失效(Cascading Failure) 两种。共因失效是指两个单元因为共同的原因失效，比如软件复制冗余，冗余单元会因为同一个软件bug导致两者都失效，为了避免该共因失效，我们采用多种软件设计方法。级联失效是指一个单元失效导致另一个单元的失效，比如一个软件组件的功能出现故障，写入另一个软件组件RAM中，导致另一个软件组件的功能失效。

具体降解的方法如下所示，比如应按照下列之一对一个 ASIL D 的要求进行分解： 

1)   一个ASIL C(D)的要求和一个ASIL A(D)的要求；或 

2)   一个ASIL B(D)的要求和一个ASIL B(D)的要求；或 

3)  一个ASIL D(D)的要求和一个QM(D)的要求，

     

其它ASIL等级分解可如下图所示：

      

以上简单的介绍了下功能安全的定义，以及ASIL等级的评定和分解。所学有限，如有失误，还请指正，感激不尽。