旗开得胜 Q1
1. 功能安全这个概念的形成与发展？对中国汽车行业和企业而言，重要性何在？
功能安全概念的形成起源于上个世纪。19世纪70年代到80年代，在世界范围内，尤其是石油化工领域中一些大型项目的生产过程中，多次发生爆炸事故或者严重的污染物泄漏事情。当时业内专家通过系列而系统的分析手段，明确了事故发生的主要原因是因为相关安全控制系统安全功能失效导致的，而造成这些失效的直接原因中，由于电子、电气、可编程逻辑控制器产品自身安全功能不完善导致系统失效的比重是非常大的。
为了提高电子、电气、可编程逻辑控制器产品的安全性能，从19年开始，世界范围内的业内专家，对产品安全性设计技术非常重视，并且计划将电子、电气及可编程电子安全控制系统相关的技术发展为一套成熟的安全设计技术标准。1993年，在包含TÜV SÜD技术专家的专家技术团队的不断努力下，诞生了DIN V VDE 0801标准。之后随着更多业内专家的参与和积极努力，国际电工委员会终于在1998年的时候，正式颁布了IEC61508(功能安全基础标准)标准的第一版，并在2010年正式颁布了该标准的第二版。
到目前为止，除功能安全的基础标准IEC61508之外，其他相关领域的功能安全系列标准也已经颁布并得到大量的应用。如专门针对过程控制行业的IEC61511标准，专门针对工厂自动化领域的IEC62061和ISO13849-1标准，专门针对铁路信号控制领域的EN5012X系列标准，专门针对核电领域的IEC61513标准…当然，这其中也包含针对道路车辆功能安全领域的专用标准ISO26262。
ISO26262是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的，ISO26262标准主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车控制领域的
1
读万卷书 行万里路
旗开得胜 部件和系统，它旨在提高汽车电子、电气产品功能安全性能。另外此前路人皆知的“踏板门”、“刹车门”等事件，其实和功能安全都有很大的关联度。
ISO26226标准的核心价值在于，它可以通过系统的功能安全研发管理流程，以及针对汽车电子控制系统硬件和软件的系统化验证和确认方法，保证电子系统的安全功能在面对各种严酷条件时不失效，从而保证驾乘人员以及路人的安全。对于汽车厂商而言，贯彻执行ISO26262标准不仅可以提高安全性能，提升产品内在价值，也可以最大程度的控制因为电子部件可靠性问题导致的整车召回风险，避免品牌形象受损，避免蒙受较大的经济损失。
ISO26262标准在今年刚刚正式颁布，虽然世界范围内，暂时没有出现官方层面的强制执行要求，但该标准的执行，将减少因为电子器件失效造成的交通事故和降低潜在召回风险，所以目前国际大型车企非常重视ISO26262标准的应用和推广。
2. ISO26262对中国汽车行业和企业而言，提出了什么新要求？
ISO26262标准主要强调汽车电子电气部件的可靠性和功能安全要求，同时也给国内企业提出了新的挑战，主要集中在专业研发团队建设和系统化的功能安全设计方法。
人员方面，因为ISO26262标准对相关的硬件、软件、质量管理人员等工作提出了新的系统化、规范化的设计要求，不同的技术团队需要协调一致才能保证整体系统的可靠性。所以我们认为经过系统培训的研发团队，才能保证标准符合度。在此基础之上，通过系统化的功能安全管理方法，才能保证满足标准的全部要求。
Q2
1
读万卷书 行万里路
旗开得胜 s:zhihu/question/27719391
ISO26262 中 ASIL 与 DFMEA 有什么区别？
1. 首先，ISO26262的ASIL与DFMEA的打分对象不同
二者具有相同点，都研究失效(failure)。那么，我们举一个具体的例子来对比： “整车控制器（VCU）上的某个器件发生失效后，导致VCU发出错误的扭矩命令，从而使动力总成输出过大扭矩，车辆发生了非预期加速。而前方恰好有车，非预期加速导致了追尾碰撞，驾驶员受到不同程度的伤害”。
以下图表示此事件，发生在element level的fault向上级系统层层传递，导致了vehicle level的failure(也可以叫做malfunction或malfunction hazard)。Vehicle level的failure在一定的情景下会危害到人的安全，发生危害事件(Hazard event).
DFMEA的打分对象是element 或component或system或vehicle，在企业中，不同系统级别的DFMEA一般是在不同级别部门里进行，某一系统级别的failure mode是上级系统的fault。DFMEA打分的3个维度Severity/Occurrence/Detective都是针对器件或系统的：
•
Severity严重度：某个器件或系统失效后有多严重？ Occurrence频度：某个器件或系统失效有多频繁？
Detective探测度：发现失效的难度程度（可能性）有多高？
•
•
ISO26262的打分对象是Hazard event，打分的3个维度Severity / exposure/ controllability都是针对可能危害到人身安全的危害事件的(若只损害汽车而不危害到人身安全，则为S0，不需要打分)：
1
读万卷书 行万里路
旗开得胜 • Severity严重度：危害事件会对人造成多大危害？（无大碍、轻伤、致残、致死）
• Exposure暴露度：此危害事件的情景(Scenario)发生的频繁程度？（注意，与系统无关，情景的频繁程度）
• Controllability可控度：驾驶员通过观察系统警示信息或快速反应，以避免危害事件发生的难易程度。（注意，不是系统主动避免危害事件）。
综上，二者的打分对象是完全不同的。DFMEA关注的是系统或器件，而ISO26262关注的则是抽象概念的危害事件（所谓抽象，是指ISO26262时在打分的时候是不关注系统的，可适用于不同车辆。）。
2. 然后，二者的思维方法是完全不同的(对应于题主所说的“控制方法”)。
DFMEA是典型的归纳式(inductive)方法，从单个fault出发，去思考可能引发的后果(failure或hazard)。
与DFMEA相对应的是故障树方法(FTA: fault tree analysis)，从hazard去分析可能的原因，是一种演绎式(deductive)方法。
ISO26262 的功能安全是一整套体系与流程，不能笼统地说是归纳式的还是演绎式的。但从上面的图可以看出，ISO26262的分析起点是Hazard event，从最终的后果去定ASIL等级，再通过一定的方法将ASIL等级分配给系统、子系统、部件、器件。从宏观的思路上来看，这与FTA类似而与 FMEA相反，是一种演绎的思维方法。
1
读万卷书 行万里路
旗开得胜 3. 最后，二者的概念级别是不同的。
DFMEA与FTA可以是同一级别的概念，是分析失效的两种不同思维方法。 而ISO26262是一整套流程，大体上可以分为几大阶段：
•
概念阶段Concept Phase
系统开发阶段System Design (V型开发) 硬件开发阶段Hardware Design 软件开发阶段Software Design
•
•
•
每一阶段，均会使用到FMEA方法与FTA方法(有可能只做部分工作，而不是完整的FMEA或FTA)。ISO26262将FMEA与FTA当作是整套流程的一种工具。 %%%%% 答主知识水平自评 %%%%%%
•
ISO26262：接触3个半月，即将入门。 FMEA：6年前上过几节课，学了点皮毛。
•
因此，答主水平也是相当一般的，因此答的内容不要全信。高人如指出错误，答主在确认之后会第一时间更正。 %%%%题外话%%%%%
二者还有不少相同之处。由于题目问的是不同之处，因此不就赘述了。
1
读万卷书 行万里路
旗开得胜 跟题主讨论下问题中的某一句，“ ASIL中安全完整性等级考虑功能失效的严重性、暴露率和可控性 ”，ASIL中的暴露率指的是事件场景的暴露率，而不是功能失效本身的暴露率。
今天看《电动汽车动力电池系统-安全分析与设计》（王芳夏军）中提到，其中ISO26262中ASIL等级里面的 Exposure ，指的是场景的暴露率，而不是故障的暴露率。举例，比如说分析过充起火和慢充这个事件，评估的是慢充充电这件事（电动车几乎每天都会充电）的暴露率，而不是慢充起火这件事的暴露率。
人气浅谈一下汽车研发领域的功能安全（Functional Safety）和ISO26262。至于FMEA的部分，希望以后慢慢补上。
在这篇文章中我会简要谈谈以下内容： 1. 什么是功能安全 2. 什么是ISO26262
3.什么是ASIL，如何进行需求的ASIL评级 4.在获得ASIL评级以后，如何确保功能安全
1
读万卷书 行万里路
旗开得胜 ------------ ------------ -------迷之分割线------------ ------------ ------------ 随着消费者对汽车质量和安全性要求的日益提升，以及近年来辅助驾驶/自动驾驶概念的兴起，功能安全（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.”
1
读万卷书 行万里路
旗开得胜 所以综合一下、按通俗的理解而言，功能安全就是指汽车即便出现了故障，这个故障也是可控的，不会出现“玩脱了”的情况。实现功能安全是汽车设计的主要目标，也是评价汽车设计的重要标准。
2. 什么是ISO26262
ISO26262: Road Vehicles – Functional Safety 是一个适用于汽车电子/电气系统的国际标准。这个标准对汽车的研发、生产、测试、售后等整个生命周期，在文档管理、流程规划、功能设计和任务执行等方面进行了具体的指导，并提出了一系列要求，最终使产品达到功能安全的目标。
可以说，“功能安全”好比一位童颜、温婉善良、人人都想追的妹子，而“ISO26262”则是一本针对这个妹子的详细把妹教程。而且ISO26262比把妹教程更牛逼：没有哪本教程可以保证你把妹成功，但只要企业详细遵循了ISO26262标准，其设计出的产品就一定能满足功能安全的目标。只要了解了ISO26262，可以说就了解了功能安全的绝大部分内容。
ISO26262内容非常丰富，但对于非安全工程师而言，我认为了解到ISO26262中最重要的三部分内容就可以了，它们是：1. “V”型开发流程 2. ASIL概念 3. 功能安全设计开发流程
1
读万卷书 行万里路
旗开得胜 对于“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级——你的车窗就算坏了，除了淋点雨，并不会发生什么了不起的事情。
1
读万卷书 行万里路
旗开得胜 于是，当汽车研发人员拿到一份需求文档，首先要做的就是对其中每一项需求进行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
1
读万卷书 行万里路
旗开得胜 来表示。
第四个概念：Tolerable Risk。前面我们已经得到了安全风险的量化公式，那么进行评级还需要一个对比标准，这个标准就是Tolerable Risk。
为了吹嘘我家的汽车安全，我可能会说:“我们生产的软件狗牌转向机的故障的风险，比的风险还低!”这里就选择了作为对比标准。事实上，安全工程师在制定Tolerable Risk的时候，确实类比了诸如、七级以上大地震、严重车祸等等事件的量化风险做标准——如果我做出来的汽车部件的安全风险，比大地震的风险还低，你作为消费者，是不是已经可以安心使用了呢？
把以上四个概念绘制在一个图表中，以S为横轴，E*C 为纵轴，就可以得到以下一张ASIL评级图：
从图中我们可以看出，左下角的安全风险最低，而右上角部分的安全风险最高，并且有Tolerable Risk线把图分为了两部分。Tolerable Risk 线以下的部分，就好比“比地震风险还低”的部分，不需要给予特别关注，可以直接评为非安全需求的QM级；而线以上的部分，就具有显著的安全风险，需要进行ASIL评级，最右上角评为D级，向左下依次评为C、B、A级。
1
读万卷书 行万里路
旗开得胜
在实际评级中，安全工程师会制定详细的E、C、S值量化评分表，于是对于任意一项需求，都可以对照评分表得出其E、C、S的值。其中，确定E值的过程叫做Risk Assessment，而确定C值和S值的过程叫做 Hazard Analysis。有了E、C、S值，再对照ASIL评级图，就可以得出这项需求的ASIL 评级了。
ISO26262中给出了一张标准的ASIL评级表，这里也贴出来（其中的C1-C3,E1-E4是各种具体分级，具体定义前面的答案已经描述过了），和我画的其实是一个意思。对于初学者而言，我觉得我画的图更容易理解（迷之自信...）。
1
读万卷书 行万里路
旗开得胜 注意: 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。还举前例，要怎样降低“助力方向一致”故障的风险呢？一个可行的办法是进行冗余计算：用两套不同的算法计算助力方向，保证结果的正确
1
读万卷书 行万里路
旗开得胜 性。或者，把助力电机的力矩在一个较小的值也是个好办法，因为这样一来即便助力方向错误，由于助力有限，驾驶员还是可以控制汽车。
这些解决方法就是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 对系统设计进行分析和评价。可以说，全套流程结束以后，功能安全能够得到有效的保障。
1
读万卷书 行万里路
旗开得胜
5. 最后再说一些
其实吧，要说透功能安全流程的实施，一定要配合着V型开发流程讲。但是这样讲起来再画五张图、再写一千字也未必讲得清楚，这里就作罢了。ISO26262还有一个 Safety Life Cycle 的概念，我个人认为对普通工程师没有那么重要，限于篇幅也就不涉及了。
我在美国工作了五年，也去欧洲开会交流，感觉现在整个欧美汽车行业，除了几家主要OEM，大部分企业对功能安全可以说既不重视，理解也不到位。每家企业对于ISO26262都有自己的理解，甚至有时彼此间的理解差异还很大。在这里我尽量写出了自己的理解，希望能抛砖引玉，和大家探讨。
1
读万卷书 行万里路
旗开得胜
1
读万卷书 行万里路
