自动驾驶概念兴起，工程师眼中的汽车功能安全、ISO26262与ASIL评级

在这篇文章中我会简要谈谈以下内容：

1. 什么是功能安全

2. 什么是ISO26262

3.什么是ASIL，如何进行需求的ASIL评级

4.在获得ASIL评级以后，如何确保功能安全

------------ ------------ -------迷之分割线------------ ------------ ------------

随着消费者对汽车质量和安全性要求的日益提升，以及近年来辅助驾驶/自动驾驶概念的兴起，功能安全（Functional Safety) 在汽车研发中占据的地位变得越来越重要。无论是控制工程师、机械工程师还是像我一样的软件狗(误？？），能对功能安全的基本概念有所了解，也逐渐成为了skill set中的重要一环。

但是在实际工作中，我发现刚入职一两年的同事们，基本上就没有接受过任何功能安全相关的培训。在开技术讨论会牵涉到相关话题时往往是一脸懵逼。所以借着在中国休假等签证的机会，我打算写这篇文章对功能安全进行一个简单介绍，同事也是回馈点了我关注的800多同学....

1. 什么是功能安全

按照比较老的ISO8402的定义，功能安全就是：

“A state in which the risk of harm (to persons) or damage is limited to an acceptable level.”

而根据ISO26262, 功能安全被定义为：

“Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.”

所以综合一下、按通俗的理解而言，功能安全就是指汽车即便出现了故障，这个故障也是可控的，不会出现“玩脱了”的情况。实现功能安全是汽车设计的主要目标，也是评价汽车设计的重要标准。

2. 什么是ISO26262

ISO26262: Road Vehicles – Functional Safety 是一个适用于汽车电子/电气系统的国际标准。这个标准对汽车的研发、生产、测试、售后等整个生命周期，在文档管理、流程规划、功能设计和任务执行等方面进行了具体的指导，并提出了一系列要求，最终使产品达到功能安全的目标。

可以说，“功能安全”好比一位童颜巨 乳、温婉善良、人人都想追的妹子，而“ISO26262”则是一本针对这个妹子的详细把妹教程。而且ISO26262比把妹教程更牛逼：没有哪本教程可以保证你把妹成功，但只要企业详细遵循了ISO26262标准，其设计出的产品就一定能满足功能安全的目标。只要了解了ISO26262，可以说就了解了功能安全的绝大部分内容。

ISO26262内容非常丰富，但对于非安全工程师而言，我认为了解到ISO26262中最重要的三部分内容就可以了，它们是：1. “V”型开发流程 2. ASIL概念 3. 功能安全设计开发流程

对于“V”型开发流程（the “V” cycle）,我在另外一篇文章：写工业级别代码是怎样一种体验？ - 知乎中已经介绍过了（是的我就是顺便打个广告），在这里我想先介绍一下ASIL的概念。

3. ASIL

3.1 ASIL 的定义

ASIL（Automotive Safety Integrity Level）是用来描述一项需求(Requirement)的安全严格等级的概念。它由低到高分为A、B、C、D四个级别，除此之外还有一个非安全需求的QM（Quality Management）级。粗略而言，ASIL D级别的需求，一旦发生故障则具有相当高的安全风险，会导致严重的安全后果，往往危及人员生命安全；而对于ASIL A级别的需求，安全风险就很小了，就算出了故障也无所谓。

比如需求“顺/逆时针转动方向盘时，电子助力的力矩须与其保持同方向”是ASIL D级，因为如果驾驶员向左打方向盘而助力向右，汽车很快就会失控并撞向道路一侧，这是要出人命的；而“车窗可通过按钮控制上行/下行”就是ASIL A级——你的车窗就算坏了，除了淋点雨，并不会发生什么了不起的事情。

于是，当汽车研发人员拿到一份需求文档，首先要做的就是对其中每一项需求进行ASIL评级。

3.2 ASIL 的评级

那么一项需求的ASIL具体是怎么确定的呢？为了详细说明，还要引入几个ISO26262中定义的概念。

第一个概念：Exposure（E）。Exposures是指故障发生的时长占平均运行时长的比例，用来表征故障发生的概率大小。E值越大则故障发生的概率越大。

第二个概念：Controllability（C）。Controllability是指故障发生以后，驾驶员是否可以人为对故障状态加以控制。C值越大则越难以控制。比如前面的例子中，如果反向的转向助力非常大，以至于驾驶员靠手臂的力量无法控制方向盘，则C值也就很大。

第三个概念：Severity（S）。这个比较好理解了，就是故障的严重程度。S值越大则故障越严重。转向助力失灵是很严重的故障，而车窗失灵就不严重。S值分由轻微到严重为S0至S3共四级。

聪明的你一定已经意识到了，一项需求发生故障以后的安全风险，可以用公式

Risk = E * C * S来表示。

第四个概念：Tolerable Risk。前面我们已经得到了安全风险的量化公式，那么进行评级还需要一个对比标准，这个标准就是Tolerable Risk。

为了吹嘘我家的汽车安全，我可能会说:“我们生产的软件狗牌转向机的故障的风险，比空难的风险还低!”这里就选择了空难作为对比标准。事实上，安全工程师在制定Tolerable Risk的时候，确实类比了诸如空难、七级以上大地震、严重车祸等等事件的量化风险做标准——如果我做出来的汽车部件的安全风险，比大地震的风险还低，你作为消费者，是不是已经可以安心使用了呢？

把以上四个概念绘制在一个图表中，以S为横轴，E*C 为纵轴，就可以得到以下一张ASIL评级图：

从图中我们可以看出，左下角的安全风险最低，而右上角部分的安全风险最高，并且有Tolerable Risk线把图分为了两部分。Tolerable Risk 线以下的部分，就好比“比地震风险还低”的部分，不需要给予特别关注，可以直接评为非安全需求的QM级；而线以上的部分，就具有显著的安全风险，需要进行ASIL评级，最右上角评为D级，向左下依次评为C、B、A级。

在实际评级中，安全工程师会制定详细的E、C、S值量化评分表，于是对于任意一项需求，都可以对照评分表得出其E、C、S的值。其中，确定E值的过程叫做Risk Assessment，而确定C值和S值的过程叫做 Hazard Analysis。有了E、C、S值，再对照ASIL评级图，就可以得出这项需求的ASIL 评级了。

ISO26262中给出了一张标准的ASIL评级表，这里也贴出来（其中的C1-C3,E1-E4是各种具体分级，具体定义前面的答案已经描述过了），和我画的其实是一个意思。对于初学者而言，我觉得我画的图更容易理解（迷之自信...）。

注意: ASIL 评级过程和DFMEA中PRN值的计算以及PRN值的降低过程有些相似，却又有本质上的不同。这部分其他答案已经有所涉及，限于篇幅这里就不对比说明了。等我下次写一篇介绍DFMEA的文章时再详细说吧（希望不要又是半年以后……）

 4. ISO26262如何保证功能安全?

前面说了那么多各种概念，现在来谈一下为什么说执行ISO26262后一定能保证功能安全。

根据ISO26262，对于任何一项需求，其功能安全大致可以通过以下几个步骤来保证：

1）进行Hazard Analysis 和 Risk Assessment。前文已叙，这个步骤是为了获得需求的E、C、S值。

2）评出此需求的ASIL评级并建立Safety Goal。Safety Goal 是一个具体的、定性的安全目标，比如转向助力那个例子中，“助力方向一致”这个需求一定是ASIL D级，故障后会有相当大的安全风险。其Safety Goal就是把故障风险降低至可容忍风险以下。Safety Goal继承对应需求的ASIL评级。

3) 将Safety Goal 进一步分解为 Functional Safety Concept 和 Technical Safety Concept。还举前例，要怎样降低“助力方向一致”故障的风险呢？一个可行的办法是进行冗余计算：用两套不同的算法计算助力方向，保证结果的正确性。或者，把助力电机的力矩限制在一个较小的值也是个好办法，因为这样一来即便助力方向错误，由于助力有限，驾驶员还是可以控制汽车。

这些解决方法就是Functional Safety Concept。把Functional Safety Concept进一步在技术上具体化，就是Technical Safety Concept。它们将继承步骤2）评出的ASIL等级。不同的ASIL等级对Functional Safety Concept 和 Technical Safety Concept有不同的要求。

4）由Technical Safety Concept 形成Software Safety Requirements 和 Hardware Safety Requirements。这些就是非常具体的安全需求了，可以直接作为软/硬件设计的依据。这些需求也继承了相同的ASIL等级。

5）根据4）步得到的安全需求，结合其ASIL 等级制定测试与验证方案。对于不同等级的安全需求，ISO26262对测试方案有着硬性的要求。比如ASIL D级需求除了进行MISRA、PolySpace等测试外，还要进行完备的功能测试和覆盖率100%的MCDC测试，并对Traceability （可溯性？）也有相应要求。

功能安全设计开发流程

在进行这套流程的同时，还需配合FMEA 和 DRBFM 对系统设计进行分析和评价。可以说，全套流程结束以后，功能安全能够得到有效的保障。

5. 最后再说一些

其实吧，要说透功能安全流程的实施，一定要配合着V型开发流程讲。但是这样讲起来再画五张图、再写一千字也未必讲得清楚，这里就作罢了。ISO26262还有一个 Safety Life Cycle 的概念，我个人认为对普通工程师没有那么重要，限于篇幅也就不涉及了。

我在美国工作了五年，也去欧洲开会交流，感觉现在整个欧美汽车行业，除了几家主要OEM，大部分企业对功能安全可以说既不重视，理解也不到位。每家企业对于ISO26262都有自己的理解，甚至有时彼此间的理解差异还很大。在这里我尽量写出了自己的理解，希望能抛砖引玉，和大家探讨。