一、功能安全标准

ISO 26262《道路车辆功能安全》脱胎于IEC 61508《电气/电子/可编程电子安全系统的功能安全》，主要定位在汽车行业（包含乘用车、商用车、卡车、特殊车辆、摩托车等）中特定的电子器件、电子设备等专门用于汽车领域的部件，目的是提高汽车电子电气产品的安全性。

ISO 26262从2005年起正式开始制定，历约6年于2011年正式颁布第一版，成为国际标准。第二版也于2018年正式发布。相应的国标版功能安全标准也于2017年正式发布——GB/T 34590。同时，第二版的GB/T 34690也在制定中，相信不久就会正式颁布。

二、功能安全等级定义

ASIL (Automotive Safety Integrity Level) 是指汽车安全完整性等级。它是由ISO 26262 标准定义的道路车辆功能安全的风险分类系统。在ISO 26262中，功能安全定义为：不存在由于电子/电气系统的功能异常表现引起的危险而导致的不合理风险（ Absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems）。

ISO 26262定义了四种功能安全等级——ASIL A, ASIL B, ASIL C和ASIL D。其中ASIL A代表最低程度，ASIL D代表最高程度的汽车危险。

ASIL的定义通常通过如下来获得:

• 通常在项目早期阶段进行，通过对系统/功能进行危害分析和风险评估（HARA）获得
• 每一个危险事件都被分配了一个ASIL等级 （从ASIL-A 到 ASIL-D，或QM）
• QM不是一个功能安全等级，它意味着没有特殊性的安全要求，满足质量管理流程即可
• ASIL的选择基于可控性（C）、严重程度（S）和暴露时间（E）。

例如：安全气囊、防抱死制动器和动力转向等系统需要ASIL-D等级（适用于安全保证的最高等级，因为与此类故障相关的风险最高）；尾灯等组件通常只需要ASIL-A等级，前灯和刹车灯通常为ASIL-B，雨刷控制通常为ASIL-A；而巡航控制通常为ASIL-C。

三、危险事件的确定

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

（1）软件失效：比如没有考虑分母可能为0、变量公式定义错误、导致精度丢失。
（2）硬件失效：如下图所示可以分为传感器失效、ECU硬件失效（比如CPU或者RAM/ROM失效）、执行器失效。
依据ISO26262标准进行功能安全设计时，首先识别系统的功能，并分析其所有可能的功能故障（Malfunction）或失效，可采用的分析方法有HAZOP、FMEA、头脑风暴等。

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

所以进行功能故障分析后，要进行情景分析，识别与此故障相关的驾驶情景，比如：高速公路超车、车库停车等。分析驾驶情景建议从公路类型（国道，高速），路面情况，（湿滑、冰雪）；车辆状态（转向、

超车、制动、加速等），环境条件（风雪雨尘、夜晚、隧道灯），人员情况（乘客、路人）等几个方面去考虑。功能故障和驾驶场景的组合叫做危害事件（hazard event）。

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

四、ASIL安全等级

ASIL等级，Automotive Safety Integration Level，汽车安全完整性等级，描述系统能够实现指定安全目标的概率高低。每个安全功能要求都包括两部分内容，安全性目标和ASIL安全等级。
对一个指定系统应用安全功能要求。

ASIL安全等级划分包括如下步骤：
1）根据预想架构、功能概念、操作模式和系统状态等确定安全事件；
2）危险分析和风险评估，初步确定ASIL安全等级；
3）逐级分解安全要求和安全等级，ASIL安全级别划分和ASIL安全级别逐层分解两个过程交替进行，直至抵达无法进一步分解 零件或者子系统；
4）最后用几个原则去检查等级分配的合理性，包括因素共存原则、相关失效分析和安全分析。

五、危险分析和风险评定

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

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

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

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

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

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

• 基本可控C0的组合不考虑；
• 无伤害S0的组合不考虑；
• 其余组合相加等于7分为ASIL A，等于8分为ASIL B，等于9分为ASIL C，等于10分为最高等级ASIL
• ASIL A、B、C、D都是与功能安全相关的
• 其余的得分安全评定为QM，代表与安全无关的功能

六、功能安全目标的分解

通过上危害分析和风险评估，我们得出系统或功能的安全目标和相应的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）分解和应用