iso26262功能安全

一、功能安全这个概念的形成与发展?对中国汽车行业和企业而言，重要性何在?

功能安全概念的形成起源于上个世纪。19世纪70年代到80年代，在世界范围内，尤其是石油化工领域中一些大型项目的生产过程中，多次发生爆炸事故或者严重的污染物泄漏事情。当时业内专家通过系列而系统的分析手段，明确了事故发生的主要原因是因为相关安全控制系统安全功能失效导致的，而造成这些失效的直接原因中，由于电子、电气、可编程逻辑控制器产品自身安全功能不完善导致系统失效的比重是非常大的。

为了提高电子、电气、可编程逻辑控制器产品的安全性能，从1989年开始，世界范围内的业内专家，对产品安全性设计技术非常重视，并且计划将电子、电气及可编程电子安全控制系统相关的技术发展为一套成熟的安全设计技术标准。1993年，在包含TÜV SÜD技术专家的专家技术团队的不断努力下，诞生了DIN V VDE 0801标准。之后随着更多业内专家的参与和积极努力，国际电工委员会终于在1998年的时候，正式颁布了IEC61508(功能安全基础标准)标准的第一版，并在2010年正式颁布了该标准的第二版。

到目前为止，除功能安全的基础标准IEC61508之外，其他相关领域的功能安全系列标准也已经颁布并得到大量的应用。如专门针对过程控制行业的IEC61511标准，专门针对工厂自动化领域的IEC62061和ISO13849-1标准，专门针对铁路信号控制领域的EN5012X系列标准，专门针对核电领域的IEC61513标准…当然，这其中也包含针对道路车辆功能安全领域的专用标准ISO26262。

ISO26262是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的，ISO26262标准主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车控制领域的部件和系统，它旨在提高汽车电子、电气产品功能安全性能。另外此前路人皆知的“踏板门”、“刹车门”等事件，其实和功能安全都有很大的关联度。

ISO26226标准的核心价值在于，它可以通过系统的功能安全研发管理流程，以及针对汽车电子控制系统硬件和软件的系统化验证和确认方法，保证电子系统的安全功能在面对各种严酷条件时不失效，从而保证驾乘人员以及路人的安全。对于汽车厂商而言，贯彻执行ISO26262标准不仅可以提高安全性能，提升产品内在价值，也可以最大程度的控制因为电子部件可靠性问题导致的整车召回风险，避免品牌形象受损，避免蒙受较大的经济损失。

ISO26262标准在今年刚刚正式颁布，虽然世界范围内，暂时没有出现官方层面的强制执行要求，但该标准的执行，将减少因为电子器件失效造成的交通事故和降低潜在召回风险，所以目前国际大型车企非常重视ISO26262标准的应用和推广。

二、ISO26262对中国汽车行业和企业而言，提出了什么新要求?

ISO26262标准主要强调汽车电子电气部件的可靠性和功能安全要求，同时也给国内企业提出了新的挑战，主要集中在专业研发团队建设和系统化的功能安全设计方法。

人员方面，因为ISO26262标准对相关的硬件、软件、质量管理人员等工作提出了新的系统化、规范化的设计要求，不同的技术团队需要协调一致才能保证整体系统的可靠性。所以我们认为经过系统培训的研发团队，才能保证标准符合度。在此基础之上，通过系统化的功能安全管理方法，才能保证满足标准的全部要求。

三、什么是功能安全

按照比较老的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.”

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

四. 什么是ISO26262

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

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

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

1.“V”模型开发流程

2. ASIL

2.1 ASIL 的定义

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

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

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

2.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 评级了。

注意: ASIL 评级过程和DFMEA中PRN值的计算以及PRN值的降低过程有些相似，却又有本质上的不同。

3. 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 对系统设计进行分析和评价。可以说，全套流程结束以后，功能安全能够得到有效的保障。