0 序言

只要是汽车行业相关的工程师，基本都躲不开“功能安全”这个概念。此前陆续有几次想系统的写一下功能安全相关的内容，但结果都是从入门到放弃。鉴于功能安全这个概念过于重要，躲也躲不掉，所以还是试着来总结下。

本文并不适合需要深入了解功能安全的读者，因为本身我自己的功能安全水平也有限。本文想要达到的目的是使小白读者笼统的了解功能安全相关的基本概念，功能安全开发时具体涉及哪些阶段，每个阶段需要做哪些工作。这样子，至少在和功能安全相关同事交流时，能够搭上话。另外，当有读者真的需要做功能安全的具体工作时，也能知道自己为什么要做那些工作。至于功能安全工作具体该怎么做，本文不会过多涉及，因为我自己也讲不深。通常让软硬件工程师做功能安全开发时，会有专业的功能安全工程师进行指导。

在本文中，很多内容都是我自己的理解，大概率无法做到严谨，请十分谨慎的参考。标准中的文字倒是很严谨，但我相信摘抄出来，没几个人有耐心看。

1 功能安全是什么

先来解释概念，功能安全简单来解释就是功能要安全，这好像是句废话。国标GB/T 34590（可以认为是国标版的ISO26262，后文不会专门区分二者，说功能安全标准可能指的是二者的任意一个）对功能安全的定义是“不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险”。对这么一句简单的话，做一些拆解。

（1）功能安全讨论的对象是电子电气系统，因此机械/液压等设计都不在功能安全的研究范围。换句话说，一个产品按照功能安全流程开发，并不代表其就是安全的。功能安全只是产品安全的一部分。所以机械行业的读者们学习功能安全的必要性就不是那么高，但如果有学习行业内相关知识的热情，是更好的。

（2）现实生活中的危害有很多类，比如人身伤害或财产损失。功能安全关注的危害仅仅是指电子电气系统故障对驾驶员或者车辆周边人员的人身伤害。说白了，一切目的都是保护人。至于车门设计不合理，很容易被撬，钱容易丢，功能安全管不了那么多。

（3）世上没有100%安全的系统，即使能够无限逼近100%安全，那成本也是极高，那些产品是无法量产上市的。所以功能安全的定义里提到的是“不合理”的风险。判断风险是否可以接受，可以从两个维度去考虑，即危害的严重性和危害发生的频率。虽然飞机失事后几乎都是无人生还，但由于其发生概率低，因此也不能说飞机这个产品设计是不合理的。

既然功能安全的研究对象是电子电气系统，那么相关行业，比如航空电子、汽车、铁路和医疗设备行业都会涉及到功能安全概念。功能安全最通用的标准是IEC 61508,它起源于工业产品市场，涵盖了许多行业的“一般功能安全”。基于IEC 61508，发展出了大名鼎鼎的ISO 26262标准，该标准特别适用于汽车乘用车电气和电子系统。GB/T 34950《道路车辆功能安全》可以认为是国标版本的ISO26262。如果不想看英文标准，看GB/T 34950也是一样的。

2 功能安全解决什么问题

功能安全的开发遵循ISO26262，中国的国标是GB/T 34590，所以功能安全解决什么问题等同于这两个标准要解决什么问题。不想去摘网络上的标准话术，来说点大白话。随着汽车朝着电动化的方向一路狂奔，汽车上EE系统越来越复杂，那么功能安全相关的问题就越来越多。在ECU还不复杂的时候，对于产品的一些安全问题，还可以要求工程师在那些地方多注意一下。其实，在大公司里，为了保证开发的质量和效率都有一些方法论，比如代码应该按照什么样的规范编写，电路设计完后按照一个已有的Checklist去检查。但这些都是个别公司自己的行为规范。汽车是个很复杂的系统，整个产业上下游需要一个形成共识的方法论来指导生产经营活动。对于整车厂而言，知道供应商遵循的标准与自己的一致，心里才更安心；对于供应商来说，只需要遵循一套标准，就可以满足多家客户的要求。

功能安全标准不仅仅只关注开发阶段的方法论，还包括管理、生产、运行、服务等等，GB/T 34590的内容如下。

所以，功能安全标准实际上是提供了产品整个生命周期的方法论。比如标准要求要在公司建设功能安全文化、配置功能安全团队、对这些团队人员进行管理等等。对于研发人员，看这些就觉得很虚，但功能安全本身就是一个方法论，其相当于给你指了个大方向，你按照指导能走到目的地，但很具体的细节怎么落地，需要从事功能安全相关的人员有自己的理解。

本文主要关注开发阶段，功能安全在开发阶段的任务，不严谨的讲就是识别危害和风险；针对这些危害和风险实施一些安全措施；通过测试、分析、仿真等手段来验证措施是否有效，能否保证安全。

标准将开发阶段分为概念阶段、系统阶段、软硬件阶段，下面分别来看。

3 概念阶段

概念阶段又被分为三个部分，即相关项定义，危害分析和风险评估，功能安全概念，下面来一个个看吧。

3.1 相关项定义

相关项的英文是Item，也可以翻译成项目或者条款。但说白了，其实就是确定功能安全的研究对象。相关项包括产品的功能、接口、环境条件、法规要求等。功能安全研究的是如何让功能变得安全，那第一步当然是要先知道产品的功能，这个比较好理解。

假设我们要研究的对象是eBooster，eBooster作为取代传统真空助力器的电控系统，其工作原理可简要概括为：当驾驶员踩下制动踏板时，推动输入推杆产生位移，踏板行程传感器记录输入推杆位移，将其发送至eBooster ECU，ECU根据位移计算并控制助力电机产生力矩推动制动主缸推杆，使得主缸释放液压到轮缸以实现液压制动。工作过程可以缩略为：踩制动踏板→产生位移信号→电机转动提供助力→实现制动。我之前的文章有写过线控制动，如果有兴趣，可以查看之前的文章。

自动驾驶的必要条件--线控底盘（1）

目前市场上主流的eBooster产品是博世的i-Booster，如下图所示。

eBooster的功能简单概括为：

（1）驾驶员制动时提供制动助力

（2）制动过程中点制动灯

（3）反馈eBooster状态信息给HMI系统

另外，根据欧洲经济委员会标准ECE-R13H和国标GB13594的要求，乘用车在电子助力失效的情况下，机械部件仍然要保证驾驶员在用500Nm踩制动踏板时能产生 2.44 m/s² 的减速度。所以eBooster的机械设计也应满足这一法规要求。上面这些说明，就可以说是一个相关项定义。

3.2 危害分析与风险评估

危害分析与风险评估（Hazard analysis and risk assessment）即读者们看到的HARA。危害分析和风险评估基于相关项定义的功能和接口展开，通过识别出相关项的功能失效可能导致的危害和风险，并对风险进行ASIL等级评估从而得到相关项的安全目标。

个人理解，这一步就是要看看产品的每一个功能有哪些失效形式，失效后的风险有哪些，严重程度如何。对于不同严重程度的风险，在后面的设计中，就要区别对待。举个不恰当的例子，豆角炒不熟，可能会引起食物中毒，拉拉肚子什么的。但要是河豚处理不好，食客可能就有生命危险。所以，虽然在处理这两种食物的时候，都需要小心谨慎，但处理河豚时明显要更专注点才行。

关于危害分析和风险评估有几点注意事项：

（1）应以能在整车层面观察到的条件或行为来定位危害。比如你可以定义模块A某功能故障影响了模块B的使用。这也是一种危害，但这不是对整车的危害。正确的应该是比如eBooster的助力功能异常，导致车异常加速，这就是对整车层面的影响。为什么一定强调是对整车的危害？因为功能安全本质上是为了避免对人的伤害，产品对整车的危害，才能直接体现对人的危害。我们来评判某种危害的严重程度，评判的也是其对人的危害。

既然是以整车层面观察到的行为来定义危害，那么从整车动力学的角度，汽车的运动轨迹可以被下图的运动坐标系完全包含。

而在坐标系上，因为控制不当而可能产生的所有整车表现也能被界定。

（2）在HARA过程中，不应该考虑将要实施或者已经实施的安全机制。比如你想说，你在eBooster系统中加了一套完全的冗余系统，可以避免异常加速的问题，所以你就认为没有这个危害。这不是这个阶段需要考虑的事情，这个阶段只是发现危害与风险。至于安全机制的实施，是后面的事，不要杂糅在这个阶段。

（3）通常，每一个危害有多种与相关项的功能实现相关的潜在原因。比如eBooster的助力异常有可能是硬件问题造成的，也可能是软件bug造成的。这个阶段也不考虑。

那如何枚举一个产品或者功能的危害呢？ISO 26262中推荐了一种系统性地分析相关项的危害的方法——HAZOP(危害和可操作性分析，Hazard and Operability Analysis)。HAZOP给开发人员提供了一种可借鉴的思维方式，可操作性强，因此被车企广泛地运用到了功能安全开发中。简单来说，HAZOP从以下几个方面来全面地考虑功能的可能失效模式，从而识别出功能所有可能产生的危害。

现在来思考下，是不是只要产品的功能出问题了，就会产生危害？比如eBooster的非预期制动，如果是在高速上，那就会造成后车追尾。但是如果是在地下车库里慢速行进，突然刹车，好像只是体验不好，而不会对人产生伤害。于是，产品功能失效是否会产生危害，还需要结合场景来看。车辆的运行场景可以理解为是下图各个因素的排列组合。

危害事件定义好了之后，还需要对危害事件进行评价，主要有三个维度，即S（severity严重度）、E（Exposure曝光度）和C（controllability可控度）。

基于这三个维度的评分，确定汽车安全完整性等级，automotive safety integrity level，也就是我们常说的ASIL等级。ASIL一共分为四个等级，D代表最高严格等级，即风险最高。A代表最低严格等级，即风险最低。当某项功能被定义为ASIL D，意味着设计时需要花费更大的代价去避免其失效，因为其失效后的风险真的很大。需要说明的是，下表中还有一个QM等级，这表示只要按照企业流程开发就可以满足要求。

可以看到，ASIL等级的确定由S、E、C三个参数决定的，而这三个参数的确定又有很多的主观性。比如车异常加速，有的人能在瞬间踩刹车，有的人则要反应2S，那你说车异常加速的可控程度是怎么样的？车瞬间加速到100Km/h和缓慢加速到30km/h，这可控度又不一样了。

对于S值来说，SAE J2980标准基于ISO26262的既有定义，在评分方面做了更详细的说明，以期提供给车企企业做参考。车企也可以根据已有的事故数据，结合整车仿真模拟和试车测试来细化自己的评判标准。总之一句话，没有统一的标准。

对于C值来说，车企则会定义一系列的Controllability study测试。针对识别出来的可能存在风险的场景，设计故障注入测试，并尽量随机选择驾驶员进行实际道路实验。最终综合驾驶员主观评价和整车动态表现的客观参数来评定出安全边界，为后续功能设计提供边界参考，保证功能失效后仍在大多数驾驶员的可控范围内。值得一提的是，这种Controllability study成本非常高，且从测试用例设计到测试结果评价都处处体现了企业的know-how，属于企业的核心机密。

对S值和C值的评定，不同企业可以根据已有的事故数据达成基本的共识，如果出现分歧，也基本上可以通过仿真和实车测试的结果来验证以消除。但是对场景暴露度E值的评估则不同，因为定性分析的成分很大，且不同国家的驾驶场景有区别，面对分歧双方又很难提供有说服力的数据，所以，相比S值和C值，E值的评定往往争议性比较大，各个车企之间分歧比较多。

有一个例子最能说明E值评定的难度。德国汽车工业协会（German Association of the Automotive Industry ，VDA）曾经把德国车企巨头召集起来，试图对E值的评定形成一个行业统一的指导标准，虽然最后释放了一版标准VDA 702，但是就连这些参与制定的车企最后都没有完全遵守，更别说其他国家的车企使用了，因此这份标准至今仍然只有德文版。

当ASIL等级评估完毕，我们就可以初步定义安全目标了。比如eBooster故障使得车辆制动力过小这个危害，我们做了如下图的分析。

于是，我们就可以定义出一条Safety Goal：整车应避免制动力过低->ASIL D。可以看到从一个功能的失效到分析出一个安全目标这整个过程中，都有很多主观性的东西，比如S、E、C值的判断，运行场景的选择等。到这里，HRAR分析其实还没有结束，因为上面的安全目标并不完整。一条安全目标的属性不仅仅包括ASIL等级。

接着上面这个例子，我们要问几个问题。

1.减速度低于多少值算是“过低”？

2.减速度过低一定会导致危害？

3.减速度过低导致的危害都是ASIL D？

所以在标准中，对于安全目标有如下的定义。每条安全目标并不一定包含以下a-e的所有内容，但a-c是基础内容，通常都会有。

运行模式：安全目标所对应的系统运行模式，在上面这个例子中，运行模式就是“整车应避免制动力过低->ASIL D”

故障容错时间：fault tolerant time interval，即FTTI。FTTI指的是在没有安全机制的情况下，从相关项出现故障到危害时间发生的最小时间间隔。很明显这个时间越长，危害越低。因为只要在这个时间内，驾驶员进行相关操作，就有可能避免危害。

安全状态：没有不合理风险的相关项的运行模式。讨论安全状态的时候，我们要把安全措施考虑在内。即虽然发生了危害，但是我们的设计上有安全措施，使得车辆进入了安全状态。安全状态就是使得人安全的状态，这个安全状态可以根据产品的不同自行来定义。比如对于高阶自动驾驶而言，一套系统坏了，还可以切换到另一套系统，而不必提醒驾驶员接管。对于低阶的自动驾驶系统，当功能发生了某种故障，导致系统无法完成自动驾驶任务，那么系统可以提醒驾驶员接管，当驾驶员接管进行手动操作且驾驶员可以掌控车辆，那么就可以认为进入了安全状态。

运行模式和安全状态都比较好定义，比较难的是FTTI。FTTI的定义通常是通过故障注入的方式进行实车测试或者模型仿真。整车测试的优势体现在真实性上，但是成本高昂，且容易收到不必要因素的干扰，尤其是对于多车参与的场景。仿真在人力成本和时间成本上的优势明显，且对场景的复现性强，更有利于排除不必要因素的干扰。因此，除了对整车动力学模型精准度要求极高的场景（比如车辆失稳）需要在实车上验证外，对于其他场景仿真模型基本能满足精度要求。

接着上面的例子讲，来看下如何通过仿真获得FTTI参数。整车应避免制动力过低->ASIL D，这个安全目标的场景是两车运行在同一车道且车速相近，后车制动力过小，与前车发生追尾。为创造出这一场景，搭建的整车模型至少需要包含如下关键参数。

根据仿真结果，可以得到不同减速度和不同初始速度参数设置下辆车是否会发生碰撞，且发生碰撞时刻辆车的相对速度。不同的碰撞速度将影响不同的S值评分。

另外，可以根据初始速度对场景的E值进行适当的划分，比如：

E4：初始速度≤120

E3：120≤初始速度≤160

E2：160≤初始速度≤200

E1：初始速度≥200

如果发生故障，但到碰撞前的时间比较长，在这段时间内后车驾驶员虽然无法控制制动力，但是仍然有可能在足够的时间内通过转向避免和前车相撞，因此C值可以如下设置。

碰撞发生前持续时间＞6s，C2；碰撞发生前持续时间≤6s，C3。

综合上述的S/E/C评分标准和仿真结果，我们可以大致得出下面这样的表格。

通过上面的表格，可以看到危害的等级和故障持续时间和后车减速度有关。我们可以得出这样的结论：

ASIL A：减速度大于-6m/s²，FTTI:600ms。这里其实严苛了些，比如当减速度为-6m/s²，故障持续时间要到2.2S，才会导致ASIL A等级的危害。只有在减速度为0m/s²时，在600ms时间内才会导致ASIL A等级的危害。这里是结合减速度和故障持续时间，取了个严格的标准。下面是同样的道理。

ASIL B：减速度大于-4m/s²，FTTI:800ms。

ASIL C：减速度大于-3m/s²，FTTI:1000ms。

ASIL D：减速度大于-1m/s²，FTTI:1200ms。

根据上面讲的，按道理，不同的FTTI数值下，会得到不同的ASIL等级，也就是说会生成不同的安全目标。实际操作中，只按照其最高要求进行设计，即选取最高的ASIL等级、FTTI，如此就得到了一条简化的安全目标。

整车应避免制动减速度过低

ASIL:D

FTTI:600ms

Safety amplitude:减速度＞-6m/s²

Safety state:eBooster关闭并警示驾驶员

3.3 功能安全概念

再看下这个图，在HARA分析后，就到了功能安全概念。

危害分析和风险评估这个过程里，得到了安全目标（Safety Goal），即整车应避免减速度过低->ASIL D（还是使用上面的例子，FTTI等参数略）。

当所研究的对象（即相关项）有造成某条安全目标所对应的危害事件的可能时，相关项就要考虑这一条安全目标。如eBooster系统有导致整车非预期减速的接口时，eBooster就继承了这一条安全目标，这个安全目标就成为了eBooster系统最高层级的功能安全要求（Functional Safety Requirement，FSR），即eBooster有这样的功能安全要求：eBooster应避免减速度过低->ASIL D（这里省略了FTTI等属性）。如果有其他的ECU也有可能造成整车非预期减速，那么它们也将有相同的功能安全要求。

4 系统层面-技术安全概念

概念阶段完成之后，就进入了系统层面。在概念阶段，通常只有初步的架构。所谓初步的架构，就是指我们此时只知道整车有什么ECU，至于ECU的具体设计就不知道了。如果OEM不自研ECU，那么在概念阶段，OEM做功能安全要求拆解，并给到具体供应商。从下图可以看到，开发模型是一个V字模型。本节只说左边的技术安全概念，安全确认和集成测试需要在软硬件开发后讲。

供应商接收到功能安全要求后，需要拆分到技术安全要求。这里要说下功能安全要求和技术安全要求的区别。功能安全更像是甲方对乙方说，我要你这个ECU做到什么样的安全性能，但其不知道这个ECU的具体设计。而技术安全要求则是乙方根据甲方的需求，拆解自己ECU的系统设计，对各个模块提出要求。比如功能安全要求是xxECU不应导致非预期减速 ASIL D，xxECU的供应商收到了这个要求，然后拆解了下提出了如下要求：MCU应由两路独立的电源共同供电，形成冗余-> ASIL D；传感部分应该用两路完全冗余的传感器->ASIL D。拆解出来的技术安全要求可能有很多，上面只是简单说两个。

由功能安全要求拆解到技术安全要求，具体是要怎么做呢？这里也要讲究方法论，就要谈到一些安全分析方法，在ISO26262中主要推荐了两种方法，即FEMA和FTA，下面来介绍FEMA。

对于一个ECU来说，其有一个上游传递来的功能安全要求。假如按照功能来分，这个ECU可以分为很多个功能模块，比如供电、通信、AD采样、传感器等等。我们可以分别去分析各个模块可能的失效模式，并分析其对顶层的功能安全要求的影响程度，如果一个模块的失效违背了功能安全要求，那么就要对这个模块分配相应的设计要求，这个设计要求就是技术安全要求。比如我们分析到MCU的供电失效会违背顶层的功能安全要求：xxECU不应导致整车非预期减速，那么我们就要对供电提出技术安全要求：MCU需要由两路完全独立的电源供电->ASIL D。

这样子从底层模块分析其对顶层模块的影响，是一种归纳的方法，而FMEA就是这样一种方法。FMEA的全称是Failure Mode and Effects Analysis，即失效模式和影响分析，其流程如下。如果将FMEA用于生产环节中，那么可称其为Process FMEA，即PFMEA。如果FMEA用于产品开发环节，那么称其为Design FMEA，即DFMEA。

第一步和最后一步是是文档类的工作，我们不看，只看中间五步。

4.1 结构分析

这里说的结构指的是系统结构，参考文章里以车窗升降系统举例，其拆解的情况如下。结构分析的目的就是清晰、完整地描述产品的组成部分，包括系统的边界。DFMEA通常用树状图的形式描述了整个系统中的结构依赖性，即各个要素间的关系。

4.2 功能分析

对于要分析的产品，有基于产品设计需求定义出来的产品功能；而对每一个系统要素，也都各自对应一个或多个功能。功能分析的目的是保证产品功能被适当地分配给了相应的要素，从而将产品功能和要素功能关联起来形成功能网络。

4.3 失效分析

失效分析的目的是正确地识别出失效原因（failure cause）、失效模式（failure mode）和失效影响（failure effect）,从而基于功能网确定失效网。

对失效的定义来源于功能定义，当功能不能被实现时即为失效。功能的失效模式可以从以下几个方面定义：

4.4 风险分析

风险分析的目的是通过评估风险的严重度（Severity）、频度（Occurrence）和探测度（Detection）来确定需要采取优化措施的优先级。Severity值指的是最顶层（整车层）的failure effect所造成的严重程度。对S值的评级见下表。简单来说，10表示最严重，0表示最不严重。

Occurrence值反映的是在为避免failure cause发生所采取的预防措施的作用下failure cause发生的可能性。对O值的评级见下表。简单来说，10表示发生的可能性最大，0表示可能性最小。

Detection值则反映了在产品量产释放之前采取的探测failure cause的措施的有效性。对D值的评级见下表。简单来说，10表示探测的有效性最差，0表示有效性最好。

在确定了失效网的S/O/D值后，就可以进行风险分析，确定需要采取优化措施的失效的优先级。对于风险评估的标准每个公司都可能有自己的标准，有些公司用RPN值，RPN=O*D*S，根据RPN的结果大小来确定优先级。有些公司采用S*O值的结果来进行确定。不管采取哪一种评价标准，核心的目的是识别出系统中最需要优化的点。

4.5 优化

优化的目的是对需要采取进一步措施的failure cause定义新的预防措施和探测措施，以降低O/D值从而将风险降低到可接受的范围。

是否需要采取优化措施，采取什么样的优化措施，这是FMEA团队的共同决定。当优化措施被定义以后，应相应地定义负责人和完成时间，以便对优化措施的状态进行跟踪。另外需要指出，优化是一个迭代的过程，对于同一个failure cause，可能要定义不止一轮优化措施。

4.6 FMEA总结

本节结合技术安全要求拆解，讲了一种归纳分析方法FMEA，其实FMEA可以用于各个层级的安全分析。比如从安全目标拆解到功能安全要求，也可以用FMEA，所以FMEA并不局限在哪个阶段用。

以功能安全要求拆解到技术安全要求为例，通过FMEA分析得到了若干技术安全要求，某个模块被分到了技术要求要求就意味着该模块失效会违背功能安全要求。所以可以说FMEA一方面拆解了技术安全要求，另一方面识别到了可能失效的模块。

功能安全主要关注两种失效，系统性失效和随机硬件失效。

随机硬件失效：在硬件要素的生命周期中，非预期发生并服从概率分布的失效。

关于随机硬件失效有几点需要说明

（1）只有硬件会发生随机失效，软件不会

（2）尽管硬件的设计是完全正确的，元器件也是符合质量标准的，但是却无法预知故障在哪里发生，以怎样的形式发生。

（3）虽然失效的发生是非预期的，但是失效率可以在合理的精度范围内进行预测，也就是说硬件随机失效是可以进行定量评估的。

系统性失效：以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。

关于系统性失效有几点需要说明：

（1）不同于随机硬件失效的不可预知性，系统失效的形式是确定的，只要满足相应条件就一定会发生。从另一个角度来说，系统性失效是可以复现的。此外，硬件和软件都会产生系统性失效。

（2）当找到造成失效的确定方式后，可以采取对应的措施（如修复软件bug,更改不正确的电路设计等）有效避免系统性失效。

对于FMEA来说，其分析出的失效是系统性失效。虽然在FEMA分析过程中，对每种失效进行风险分析时，给出了S、O、D三个评价值，但这三个值是主观给出的，所以FMEA只能算是定性分析，而不是定量分析。

当FMEA分析出了系统性失效后，该怎么优化呢？可以参考FMEA风险分析的评价指标，即频度和探测度。比如我们组织对原理图的评审，可以检查出设计错误并且我们可以要求测试的时候覆盖率必须达到什么样的水平，这就是从提升探测度来说的。FMEA的优化措施并不固定，每家公司可以形成自己方法。还是那句话，功能安全是方法论，通过分析发现了系统性失效的风险，那就需要有优化这个动作。至于具体怎么优化，需要自行定义。

5 硬件层面

接下来进入硬件开发层面，对于一个硬件工程师来说，技术安全要求还不够具体，需要拆解到更细致的硬件安全要求。比如我们上面说到的例子,MCU需要两路完全独立的电源供电，这是技术安全要求。那这个电源的欠压值是多少？过压值是多少？当产生过压了，要执行的安全机制是什么，比如强制MCU复位，发出示警信息？这些就是硬件安全要求。

每个硬件安全要求也有ASIL等级，一个板子上有不同的模块电路，因此就会有多个功能安全等级。按照最高的功能安全等级对整个板子进行开发。对于不同等级的硬件架构设计，有不同的原则。这个设计原则其实有点虚，好的硬件设计，不管是否要实现高等级的ASIL，是个硬件工程师都想实现板子的可维护性、可测试性等等。需要说明的是，对于表格里的技术或方法，一个+号表示建议实施，两个+号表示强烈建议实施。

所以在设计时，有什么正向指导呢？我觉得要先理解硬件设计下面的硬件架构度量的评估和随机硬件失效导致违背安全目标的评估，这二者说白了就是对硬件设计质量的一种评价。知道这二者的评价标准，并在正向设计时时刻关注什么样的设计有利于上述两种评估方法的结果。

在展开上述两种评估方法之前，需要先介绍下硬件要素的故障类型。

5.1 随机硬件故障类型

A.单点故障

（1）可直接导致违背安全目标

（2）对于该硬件要素，没有任何安全机制预防其某些故障违背安全目标。比如一个未被监控的电阻，该电阻至少有一种失效模式有违背安全目标的潜在可能。

B.残余故障

（1）可直接导致违背安全目标

（2）对于该硬件要素，有至少一个安全机制预防其某些违背安全目标的故障。比如有安全机制检查一个芯片的通信接口，这个安全机制可以探测到信号电平的异常，数据速率的异常，但无法检查出报文的错误。也就是说我们虽然有安全机制去监测这个芯片，但是无法诊断其所有的问题。

C.可探测的双点故障

（1）仅与另一个(双点故障有关的)独立硬件故障联合才能导致安全目标的违背

（2）被防止其潜伏的安全机制所探测。

比如电阻1和电阻2同时短路才会导致安全目标被违背，但有安全机制可以检查出电阻1的短路，那么就可以称其为可探测的双点故障。

D.可感知的双点故障

（1）仅与另一个(双点故障有关的)独立硬件故障联合才能导致安全目标的违背

（2）在规定的时间内被驾驶员所感知（有或无安全机制探测）。

比如一个电阻断路了，车灯没那么亮了，驾驶员可以明显感知到，那么可以称其为可感知的双点故障。

E.潜伏的双点故障

（1）仅与另一个(双点故障有关的)独立硬件故障联合才能导致安全目标的违背

（2）不被安全机制所探测也不被驾驶员感知。直到第二个独立故障发生前，系统始终可以运行且驾驶员也不知道发生了故障。

比如有个电阻1短路了，没有安全机制检查这种问题，等到电阻2短路了，二者结合导致违背了安全目标。

F.安全故障

（1）与安全目标违背无关的故障，比如某个去耦电容断路了，对功能没有影响。

（2）n>2的全部n点故障，比如三个电阻并联，只有三个电阻都断路的情况下，才会违背安全目标，即n=3。这个很好理解，三个及三个以上的故障同时发生的概率非常低，如果对其设计安全机制的话，就太复杂了，整个设计会非常臃肿。

各种故障的关系如下图所示，下图中的MPF指的是双点故障。

综上，其实我们关心的主要有三类故障类型，即单点故障、残余故障和潜伏双点故障，因为这三类是不被安全机制探测或覆盖的。

5.2 硬件架构度量的评估

硬件架构度量用于评估相关项的架构应对随机硬件失效的有效性。硬件架构的度量旨在实现以下目标：

（1）显示用于防止硬件架构中单点或残余故障风险的安全机制的覆盖率是否足够(单点故障度量)。

（2）显示用于防止硬件架构中潜伏故障风险的安全机制的覆盖率是否足够(潜伏故障度量)。

上面的定义不太清楚没关系，下面看公式就知道怎么回事了。

假设所有的硬件失效都是相互独立的，那么每个安全相关的硬件要素的失效率总和λ都可以按照下面的公式来表示：

λ = λ _SPF + λ _RF + λ _MPF + λ _S

其中，

安全相关故障失效率总和：λ

单点故障失效率总和：λ _SPF

残余故障失效率总和：λ _RF

多点故障失效率总和：λ _MPF

安全故障（即没有安全影响的故障）失效率总和：λ _S

而对于多点故障，可以进一步拆分：

λ _MPF = λ _MPF_D + λ _ MPF_P + λ _MPF_L

多点故障失效率总和：λ _MPF

可探测的多点故障失效率总和：λ _MP_D

可感知的多点故障失效率总和：λ _MPF_P

潜伏故障失效率总和：λ _MPF_L

5.2.1 单点故障度量

单点故障度量反映了相关项通过安全机制覆盖或通过设计手段 实现的对单点故障和残余故障的鲁棒性。高的单点故障度量值意味着相关项硬件的单点故障和残余故障所占的比例低，系统可靠性更高。

ISO26262中对单点故障度量的要求如下，对ASIL A的安全目标没有要求，对ASIL B的安全目标没有强制要求，对ASIL C和ASIL D的安全目标有强制要求。

5.2.2 潜伏故障度量

潜伏故障度量反映了相关项通过安全机制覆盖、通过驾驶员在安全目标违背之前识别或通过设计手段(主要为安全故障)实现的对潜伏故障的鲁棒性。高的潜伏故障度量值意味着硬件的潜伏故障所占的比例低，系统可靠性更高。

潜伏故障度量的计算公式如下。

ISO26262中对潜伏故障度量的要求如下，对ASIL A的安全目标没有要求，对ASIL B的安全目标没有强制要求，对ASIL C和ASIL D的安全目标有强制要求。

5.3 随机硬件失效导致违背安全目标的评估

随机硬件失效导致违背安全目标的评估（下面简称随机硬件失效评估）是用来确定违背安全目标的残余风险已经足够低。

单点故障、残余故障和潜伏故障会违背安全目标，因此硬件架构度量对这三种故障率都提出了相应的标准。随机硬件失效评估也要给出一个评判标准，与硬件架构度量不一样，随机硬件失效评估是给一个综合的评判标准。举个例子，考研通常考四门，录取时，学校或者国家会划分单科的分数线，同时学校还会划一个总分的分数线。不仅总分要过线，单科也要过线。随机硬件失效评估相当于对总分的要求，硬件架构评估相当于对单科分数的要求。

对于随机硬件失效评估，ISO26262给出了一个度量方法，随机硬件失效概率度量（Probabilistic Metric for random Hardware Failure，PHMF）。PMHF表示在汽车运行周期中每小时平均失效概率，ISO26262中对PMHF的目标值要求如下。

PMHF的计算公式如下：

式中

单点故障失效率：λ _SPF

残余故障失效率：λ _RF

潜伏双点失效率：λDEF_det/λDEF_latent，比如A和B是双点失效的两个事件，则其失效率分别为λDEF_det（det表示已探知）/λDEF_latent（latent表示潜伏）

从故障A发生到故障B发生之前车辆运行时间：TLifetime

5.4 随机硬件失效分析方法

上面一直在说各种失效率，那么失效率的定义是什么呢？失效率λ表示产品单位时间内发生失效的次数，所以其单位是/h。在半导体行业因为电子元器件失效率非常低，因此常用FIT (failures in time) 来表示，1 FIT表示为每十亿小时（10^9 h）失效1次。

那什么是随机硬件失效率呢？电子元器件的失效率分为三个阶段。即早期失效期、偶然失效期和耗损失效期。

早期失效期（Infant Mortality）表现为产品在开始使用时失效率很高，但随着产品工作时间的增加，失效率迅速降低，这一阶段失效的原因大多是由于设计、原材料和制造过程中的缺陷造成的，往往发生在产品正式递交到客户或者市场之前，通过完善的测试和开发流程来剔除掉不合格品。这一阶段的失效率可以理解为系统故障导致的，不是随机失效。

耗损失效期(Wear-out)是由于磨损、疲劳、老化和耗损等原因使得失效率随时间的延长而急速增加，这是产品的固有生命属性，这也是产品会设置“保修期”的原因。对于汽车同样如此，ECU上的电子元器件达到损耗失效期的时间比厂家质保时间长，且通常也意味着车辆到了该报废的时候了。

第二阶段（Useful life）持续时间长，失效率低且较稳定；另外，这一阶段的失效是随机发生的，再好的设计也无法消除，我们又称其为随机失效阶段。这个阶段的失效率通常是常数，就是随机失效率。随机失效率正是我们关心的。

知道了什么是随机硬件失效率后，问题来了，从哪获得这些数据？通常来说，电子元器件的失效率可以通过以下三种方式获得：

（1）历史数据

如果设计一款和已有的产品相似的产品，那么原产品收集的历史数据可以用来评估新产品的失效率，只要数据收集合理，可信度非常高。但是对于全新的产品而言则没有历史数据可以参考。

（2）测试

测试自然是最真实和最准确的数据来源。但是对电子元器件而言，普遍失效率的数量级很低，导致测试周期长，成本太高，不适用于大规模运用。

（3）行业公认的标准

就汽车ECU而言，电子元器件的失效率都是厂商基于SN 29500和MIL HDBK 217等行业公认的标准和指南中提供的可靠性预估算法计算而来。这种经济成本低且能够被普遍接受，缺点就是计算的失效率相对真实值要保守很多。不过换个角度想，使用偏保守的数据来满足ISO 26262的随机硬件失效要求，证明系统更加“可靠”。

举个例子，SN 29500对连接器（contactors）所提供的参考随机硬件失效率如下：

不同的产品可以综合考虑实际运行环境对参考随机硬件失效率进行修正，如下图所示，公式中的每个参数如何确定SN 29500都有详细说明。

通过上面的方法，我们可以确定电子元器件总的失效率。但是，这显然还不够。电子元器件的失效模式不止一种，且不同的失效模式所造成的影响也不同，不加筛选地使用总失效率依然会导致结果失真。所以还需要知道各个失效模式下对应的失效率，而各个失效模式对应的失效率等于元器件总失效率乘以该失效模式的占比。失效模式与占比也可以通过查询行业公认的指南得到，如下图所示。所有失效模式的占比之和等于1。行业公认的指南通常有IEC/TR 62380、IEC61709以及EN62601等。

现在我们知道了一个器件的总的失效率和各种失效模式的占比，随便举个例子，一个电阻的失效率为XX，其中短路占30%，断路占70%。理论上，一个板子上所有电子器件的随机失效率和失效模式我们都可以通过SN 29500等标准查到（实际上，这个过程非常繁琐，并且有的器件没有提供相关的失效率数据），但需要注意的是，并不是所有器件的失效都会违背安全目标，并不是一个器件的所有失效模式都会违背安全目标。比如这个板子上有十个电阻，可能只有一个电阻的失效会违背安全目标，且可能只有这个电阻在短路时，会违背安全目标。所以我们在分析的时候，需要对所有电子器件的失效模式进行分析和筛选，将于安全相关的失效模式识别出来，并确定其失效率。比如电阻R1的短路会引起单点失效，那么这个单点失效率就是R1的总失效率乘以其短路在电阻总失效率中的占比。完成这一工作的常用方法就是FMEDA（Failure Modes,Effects and Diagnostic Coverage Analysis）

FMEDA的输入除了失效率、失效模式占比，还需要一个故障诊断率。故障诊断率是什么？还记得上面讲残余故障的时候吗，我们提到安全机制可能无法完全诊断出所有的失效的。比如一个电阻的总失效率是40fit，其中短路占20%，如果短路可以违背安全目标，且短路没有安全机制监测，那么这个电阻短路的失效就是单点故障，单点故障失效率就是40*0.2=8fit。如果电阻短路有安全机制监测，诊断覆盖率为99%，那么有1%的概率我们监测不到其失效，我们称其为残余故障，残余故障失效率就是40*0.2*0.01=0.08fit。如果该电阻短路不足以违背安全目标，但是当另一个器件失效时，二者的失效组合起来会违背安全目标，那我们说该电阻短路是多点故障，假如有安全机制且诊断覆盖率是99%，那么可探测的多点故障失效率就是40*0.2*0.99=7.92fit，潜伏故障失效率就是40*0.2*0.01=0.08fit。

综上，我们要获得硬件架构度量和随机硬件失效对违背安全评估的结果，诊断覆盖率是必须的输入。那么诊断覆盖率怎么定义？ISO26262:2011中提供了诊断覆盖率的典型估计值，其分低中高三档位，分别为60%、90%、99%，如下图所示。

但是在2018版本的标准中已经删掉了，变成了Low，Medium和High，具体的值可以自行定义。

自行定义就比较困难了，需要进行大量的测试，总之你把诊断覆盖率定义成某个值总得有根有据。

标准（我这里截的是国标34590的图）的第五部分的附录D，定义了多种安全机制，并且对这些安全机制定义了诊断覆盖率。看到网上有的文章说，如果用的是标准中定义的安全机制，比如下图中的比较器，其诊断覆盖率为高，那么可以将其映射到ISO26262:2011中定义的值，即99%。

对于安全机制的定义，标准的附录D也有说明，比如说明了什么是比较器安全机制。这样子，工程师就可以对照着标准来看自己的安全机制所以哪一个，然后便可以查到该机制的诊断覆盖率是多少。

器件失效率，失效模式占比，故障诊断率就是FMEDA的必要输入，有这三种数据就可以算出各种故障失效率，最终就可以获得硬件架构度量和随机硬件失效导致违背安全目标的评估结果。

国标34590的附录E给出了一个FMEDA例子，推荐大家去看一下。

5.5 硬件集成和验证

硬件集成和验证的目的是确保硬件的开发符合硬件安全要求，这是标准上的话。其实但凡硬件设计做完，都是要做测试的。对于功能安全中的“硬件集成和验证”这个阶段，只是多了一些与功能安全相关的要求。

对于测试用例的导出，标准中给出了一些方法。很遗憾，标准中没有对这些方法展开解读，有些方法我都不知道什么意思。一个公司的硬件功能安全开发，肯定不可能纯靠硬件工程师，通常会有专职的功能安全工程师。硬件工程师可以和功能安全工程师去讨论决定测试用例。

测试内容主要有以下几种。

验证和测试阶段还需要验证硬件在环境和运行应力因素下的耐用性和鲁棒性，内容如下，看起来有点像我们平时说的可靠性测试。

6 软件开发层面

由于我没有做过软件开发，所以本节只是简单介绍下。软件层面的开发模型如下，与系统和硬件开发一样，也是V字模型。

与硬件开发一样，从上层的技术安全要求分解到软件安全要求，可以采用FMEA的方法。其实，除了FMEA分析以外，还有一种方法，是FTA。之前没讲，是因为感觉功能安全的概念已经够多了，讲多了就乱了。

这里简单提一下，FMEA是从底层单元开始分析，分析底层单元有什么失效模式，并找出其对顶层安全要求的影响。比如ADC采样电路可能无法采到正确的值，这会使得ECU无法输出正确的控制信号，FMEA是一种归纳的方法。而FTA则是一种演绎方法，比如有个ECU有个安全目标是能够正确输出控制信号，那如果其无法输出控制信号，可能会有哪些原因呢？工程师就根据系统架构设计去一个个排查，排查出ADC电路失效、传感器电路失效等会影响顶层的安全目标，那么这两部分电路就要被分配相应的安全要求。一种是自上向下，一种是自上向下。二者都能将上层的功能安全要求拆解到各个底层模块上去，当然两种方法肯定会有差别，如有兴趣，可以自行研究。

与硬件不同，软件只有系统性失效，而没有随机硬件失效，所以就没有做FMEDA的过程。根据软件安全要求设计软件架构和软件单元后，依次对软件单元、软件架构和软件安全要求进行验证和测试。对于不同安全等级的软件开发、测试和验证，标准中提供了相关的准则或方法，可以查看标准。比如下图是标准标准中的软件架构设计原则，其他就不一一截图了。

7 系统层面-集成测试和验证/安全确认

软件开发完之后，开发阶段回到系统层面，进入系统及相关项集成和测试；安全确认。

7.1 系统及相关项集成和测试

集成测试与安全确认是两码事，集成测试是验证我们所提的各种安全需求有没有实现，比如我们要求检测eBooster故障，无法提供预期的减速度时，可以切换到ESC系统，提供期望的制动力。而安全确认是为了确认安全需求提的对不对，即安全需求都按照预期的实现后，是否能达到安全目标，比如我们有个安全目标是整车不应刹不住车。在安全确认阶段发现，只要我们实现了上述的安全需求后，就能够保证整车能够刹住车，那么说明我们提的安全需求是对的。

在系统层面上，集成和测试分三个部分，即软硬件集成测试、系统集成测试和整车集成测试，这其实就是不同层次的集成测试。比如在软硬件开发阶段，软硬件是各自开发的，并没有协同。当软硬件开发后，首先要把二者攒到一起，进行集成测试。系统中可能有多个功能模块，比如一个ECU中，有多个板子，每个板子都有相应的软硬件开发。当每个板子上的软硬件集成测试完成，就需要攒成一个系统再进行测试，这就是系统集成测试。整车可能有多个系统，比如底盘系统、动力系统、座舱系统等等，在分系统完成集成测试后，要攒成一台整车进行测试。

各个阶段的测试目标包括但不限于：

（1）功能安全要求和技术安全要求的正确实施

（2）安全机制正确的功能表现、准确性和时序

（3）接口实现的一致性与正确性

（4）安全机制的诊断或失效覆盖的有效性

（5）鲁棒性水平

上面这些说白了就是一些测试要求，相关的工程师和功能安全工程师需要一起将这些测试要求细化出来。在不同阶段，标准中都给出了推荐的测试方法，下面不一一罗列，仅截几张图示意一下，详细的需要去看标准。

7.2 安全确认

安全确认的要求和要点可以从以下几个方面概括。

7.2.1 安全确认的环境

在进行安全确认的时候，首先要看安全目标和整车环境有没有必然联系。比如车机相对独立，在进行安全确认的时候，就可以选择仿真环境，即可以不用整车进行安全确认。而对于诸如油门、制动和转向等和车的运动模型参数有必然联系的，安全确认就必须以整车为对象进行。

这其实有点像我们进行硬件测试的时候，如果某个功能与其他板子上的功能没什么耦合关系，那就一块单板搭建测试环境就好。但如果某个板子上的功能和其他板子有耦合，我们就必须用相关的几块板子搭建相对复杂的测试环境。

7.2.2 安全确认的目标

安全确认的目标指的是系统达到什么样的表现，我们可以认为安全目标被实现了？通常来说，通过评估以下几个方面来确认安全目标是否被实现。

（1）可控性

（2）用于控制随机失效和系统性失效的安全措施的有效性

（3）外部措施的有效性

（4）其他技术要素的有效性

7.2.3 安全确认的方式

安全确认的方式不仅只有测试一种，而是可以使用以下方法的适当组合：

（1）已定义了测试流程、测试案例和通过/未通过准则的可重复性测试(功能和安全要求的正向测试、黑盒测试、仿真、边界条件下的测试、故障注入、耐久测试、压力测试、高加速寿命测试、外部影响模拟)；

（2）分析;（如FMEA、FTA、ETA）

（3）长期测试,例如车辆驾驶日程安排和受控测试车队

（4）实际使用条件下的用户测试、抽测或盲测、专家小组

（5）评审

到此，功能安全中的开发相关内容就算笼统的过了一遍。

8 总结

功能安全的概念过于多了，所以有必要总结一下，以下仅是我个人理解。

功能安全是覆盖产品整个生命周期的方法论，其指导一个公司该怎么样去保证产品不会因为EE系统的故障而产生对人的不合理危害。

本文关注的是开发阶段的相关内容，开发阶段又可以分为三个小阶段，即概念阶段、系统阶段和软硬件开发阶段。

A.概念阶段

所谓概念阶段，说白了就基本还没有详细设计。比如我们想造一台车，我们只知道这个车上会有什么ECU，比如制动、执行、电子后视镜、HUD等等，但每个ECU的具体设计，基本不知道。在这个阶段的任务之一是定义相关项，所谓相关项就是定义一个产品或系统有什么样的功能及这个功能的边界（比如可以在什么样的环境里用，法规规定其能怎么用等等）。

在定义完相关项后，要对相关项进行危害分析和风险评估，即Hara分析。由于车辆在不同环境和场景下，产品产生的危害和风险是不一样的，所以HARA分析需要结合具体的环境和场景，比如在高速公路上，两车在同一个车道上行驶，前车的制动系统故障如果发生非预期加速，则会产生追尾。通过分析，从一个产品的危害和分析推导出对整车的危害，并且定义不同危害的等级。危害的对立面就是产品的安全目标，危害的等级，就是安全目标的等级。比如整车不应产生非预期减速，这个等级非常高，我们将其定义为D级。这个D级就要求我们在对整车的开发过程中，遇到失效后会产生非预期减速的功能，都要提高设计标准。

安全目标是对整车的要求，比如整车不应发生非预期减速。如果要避免这个事情，我们就要想车上哪些系统会导致非预期减速，比如制动系统，轮毂电机（车轮不转了，当然也算非预期减速）等，那么就要把安全目标传递给它们。这个就是“功能安全概念”做的事。于是制动系统中的eBooster就有一个功能安全要求：eBooster不应产生非预期制动。这个阶段，eBooster的详细设计还不知道，所以功能安全要求是一个比较宽泛的要求。

如何将上层的安全目标分解到下层的功能安全目标，这需要一些安全分析方法。ISO26262中主要推荐了两种方法，即FMEA和FTA。两种方法具体是什么样的不展开了，理论上你用头脑风暴这种方式能达到目的也行，不是非要用两种方法，但ISO26262毕竟是标准，它提供的是大家都认可的行之有效的办法。另外，车辆系统非常复杂，如果你是主机厂，当然希望大家都是按照一样的标准来进行安全分析的。

B.系统阶段

到了系统阶段，一个系统或者干脆说一个ECU吧，接收到了整车层面给过来的一个功能安全要求。这个时候这个ECU的系统工程师要设计系统架构了，这个系统架构里可以体现出若干的功能模块，比如采样模块、传感器模块等等，在这个阶段，还没有设计详细的硬件原理图或者软件代码。

为了实现ECU整体的功能安全要求，ECU的功能模块就要被分配到一定的安全目标，这就是技术安全概念要干的事。比如采样模块要达到什么样的技术安全目标。这个阶段还是用FMEA或者FTA，这两种方法不局限在某一个开发阶段，各个开发阶段都可以用。

“功能安全目标”和“技术安全目标”是不同设计阶段的叫法，很容易让人搞混，标准里这么叫主要是为了区分开发阶段。功能安全目标是在概念阶段提出的，技术安全目标是在系统阶段提出的。

C.软硬件开发阶段

到了软硬件开发阶段，工程师们要设计详细的电路图或者软件代码了。那么就需要将技术功能安全再细化。细化后的叫做硬件安全要求和软件安全要求。比如采样模块包括多个ADC，温敏电阻等等，为了达到技术安全目标要落实到具体的要求，比如软件中ADC的采样率设置为多少，硬件在选型时，ADC的位数要达到多少等等。分配到了具体的软硬件安全等级后，标准中给出了不同安全等级下的设计原则，这些原则不是可量化的，而是类似于流程规范的东西。

不管是软件还是硬件，开发过程总结起来就是需求->设计->测试。测试当然可以验证我们的设计不合理，但是在设计阶段，其实也要进行一些分析。这就像我们选择一个功率器件，电路板设计好做热测试，当然可以验证选型是否合理，但是在原理图设计阶段，我们就会通过一些理论参数计算，去看其在使用过程中能否扛得住温升。在功能安全开发过程中也有这样的分析过程。

功能安全分析的目的是减少失效，而失效主要分三种，即软件系统性失效、硬件系统性失效和硬件随机失效。所谓系统性失效，就是可复现的，可以通过调整设计方法、流程控制等进行改善的。例如代码bug，器件选型错误就是系统性失效。硬件随机失效就是即使你的原理图设计都正确，但是电子器件本身可能哪天随机就失效了，不可复现，也无法通过流程控制等改善，那是电子器件本身的特性。

系统性失效如何分析呢？例如在系统阶段，通过FMEA分析，得到了系统中的若干个模块的失效原因、模式和失效影响。这些模块的失效原因要么是系统性的，要么是硬件随机失效。那么就要针对这些模块进行优化，FEMA中给出了S、O、D等评价标准，一种失效的S值无法改变的，那就只能改变O和D值。O指的是失效的发生频次，如何降低失效的发生频次，可以增加安全机制或者提高安全机制的诊断覆盖率，只要这种失效能被安全机制检测到，并转入到安全状态，那么这种失效就相当于被抹掉了，被优化掉了，也就是发生频次降低了。D值如何降低呢？D值是对失效的探测度，有人说安全机制不也有监测吗？这里的探测度与安全机制的监测不一样，通常指审核和测试。比如原理图review、代码review，为了降低D值，对于设计产物的审核要严格，测试的覆盖率要满足要求。

随机硬件失效如何分析？随机硬件失效有量化的手段，即可以收集器件的失效率，失效模式占比和安全机制的诊断覆盖率等数据进行计算，得到具体量化值，比如单点故障度量、潜伏故障度量、PMHF。不同安全等级下，对这些量化值都有详细的要求。那么如何对随机硬件失效进行优化，那就是想办法降低单点故障度量、潜伏故障度量、PMHF，可以采用增加安全机制、提高安全机制诊断覆盖率、更换失效率更低的器件等等。

在设计完成之后，软硬件、系统和整车层面都要开展相应的测试验证，用于确认各级安全要求是否被满足。各级测试完成后，还要进行安全确认，这一步是为了确认，在各个设计阶段提出的安全要求都被满足后，最终的整车安全目标是否实现了。