ISO26262 是 IEC61508 对 E/E 系统在道路车辆方面的功能安全要求的具体应用。

——提供了汽车生命周期（管理，研发，生产，运行，服务，拆解）和生命周期中必要的改装活动。

——提供了决定风险等级的具体风险评估方法（汽车安全综合等级，ASILs）。

——使用 ASILs方法来确定获得可接受的残余风险的必要安全要求。

——提供了确保获得足够的和可接受的安全等级的有效性和确定性措施。

主要用于安装在最大毛重不超过 3.5 吨的乘用车上的一个或多个 E/E 系统的安全相关系统。不包括电击，火灾，热，辐射，有毒物质，可燃物质，反应物质，腐蚀性物质，能量释放及类似的危险，除非这些危险是由于 E/E 安全相关系统故障导致的。

ISO26262 主要包括以下几个部分：

Part 1：定义

Part 2：功能安全管理

Part 3：概念阶段

Part 4：产品研发：系统级

Part 5：产品研发：硬件级

Part 6：产品研发：软件级

Part 7：生产和操作

Part 8：支持过程

Part 9：基于 ASIL 和安全的分析

Part 10：ISO26262 导则

ISO26262 系列标准分为 10 本，从 ISO26262-1 到 ISO26262-10，分别从功能安全管理，概念，系统级研发，软硬件的研发，生产和操作等方面对产品的整个生命周期进行了规范和要求。从而使得产品在各个生命周期都比较完善的考虑了其安全功能。

ISO26262 给出了一套这样的管理方法、流程、技术手段和验证方法，称之为安全管理生命周期，框架如下:

那么各部分又有什么具体含义和措施呢？下面就来分别说明：

1、 项目定义：

项目定义，是对所研发项目的一个描述，是安全生命周期的初始化任务，其包括了项目的功能，接口，环境条件，法规要求，危险等内容，也包括项目的其他相关功能，系统和组件决定的接口和边界条件等。

2、 安全生命周期的初始化

基于项目定义，安全生命周期要对项目进行区分，确定是新产品研发，还是既有产品更改。如果是既有产品更改，影响分析的结果可以用来进行安全生命周期的拼接。

3、 危险分析和风险评估

安全生命周期初始化之后，就要按照 ISO26262-3 的第七条款来进行危险分析和风险评估，危险分析和风险评估的流程要考虑暴露的可能性，可控性和严重性，以便确定项目的 ASIL 等级。接下来就是为每一个风险设立安全目标，并确定合适的 ASIL 等级。

4、 功能安全概念

基于安全目标，功能安全概念就要考虑具体的基本架构。功能安全概念就是对定位到每个项目元素中的功能安全要求的具体化和细化。超出边界条件的系统和其他技术可以作为功能安全概念的一部分来考虑。对其他技术的应用和外部措施的要求不在 ISO26262 考虑的范围之内。

5、 系统级产品研发

有了具体的功能安全概念之后，接下来就是按照 ISO26262-4 的系统级研发了。系统级研发的过程基于技术安全要求规范的 V 模型。左边的分支都是系统设计和测试，右边的分支是集成，验证，确认和功能安全评估。

6、 硬件级产品研发

基于系统的设计规范，硬件级的产品研发要遵循 ISO26262-5 的要求。硬件研发流程应符合 V 模型概念左侧分支的硬件设计和硬件要求。硬件的集成和验证在右侧分支。

7、 软件级产品研发

基于系统的设计规范，软件级的产品研发应遵循 ISO26262-6 的要求。软件研发流程应符合 V 模型概念中左侧分支的软件需求规范和软件设计架构设计的要求。软件安全需求中的软件集成和验证在右侧分支中。

8、 生产计划和操作计划

其包括：生产和操作计划，相关的需求规范，系统级产品研发的开始等。ISO26262-7 的第 5 条款和第 6 条款给出了生产和操作的具体要求。

9、 产品发布

产品发布是产品研发的最后一个子阶段，该项目也将完成，具体要求在ISO26262-4 的第 11 条款中。

10、 产品的操作、服务和拆解

产品的操作、服务和拆解应符合 ISO26262-7 的第 5 条款和第 6 条款中，对产品的生产、操作、服务和拆解的相关要求。

11、 可控性

在危险分析和风险评估中，要考虑司机和处于危险中的其他人可以采取措施来控制危险情况的能力。如何提供对可控性的有效性证明不在 ISO26262 的范围之内。

12、 外部措施

参考项目以外的，在项目定义中被描述的措施（参加 ISO26262-3 的第 5 条款），以便减小项目的危险结果。外部危险降低措施不但可以包括附加的车载设备，如：动态稳定控制器防爆轮胎等，也可以包括非车载装置，如：护栏，隧道消防系统等。这些外部措施在进行危险分析和风险评估的时候应该被考虑到，但如何为这些外部措施的有效性提供证明不在 ISO26262 的范围之内，除非是 E/E设备。但要注意的是，没有明确安全例证的外部措施是不完整的。

13、 其他技术

其他技术是指那些不在 ISO26262 范围之内的，不同于 E/E 技术的设备。如：机械和液压技术。这些都要在功能安全概念的规范中加以考虑或者在制定安全要求时加以考虑。

通过以上这些具体的生命周期的各个阶段和标准中对每个阶段所必须考虑的措施、方法和具体技术的要求，将各个阶段的要求和如何满足要求的措施都进行逐一落实，这样才能设计出、制造出满足功能安全要求的安全产品。

1，功能安全的定义

1.1 本质安全与功能安全

为了了解功能安全的概念，先得熟悉下 和“本质安全”和“功能安全”的概念。

假如以铁道的路口为例，比较一下基于两种安全概念的避免路口事故的方法。这里避免路口事故就是安全目标，为了实现这个目标，可进行如下操作：

首先，如果把铁道路口撤掉，直接改造成立交桥的形式，让火车和汽车都走各自的路，这样就不会发生人或者车辆横穿铁道口的事故了。像这样，根据系统的特性把危险源直接除掉的方法是「本质安全」。

其次，假如我们在铁道路口设置信号灯和道口自动栏杆，当火车来临时前闪红灯，同时将栏杆放下，避免行人或者车辆通过。像这样通过栏杆的拦截功能及预警灯来抑制事故风险的技术叫做「功能安全」。在这里信号灯和自动栏杆一种安全机制（Safety Mechanism）。理想的情况是不管什么场合都采用 「本质安全」，但事实上，在很多场合里，由于系统自身的原因，不可能把危险源除掉。特别是像车载电控系统这样非常复杂的电子化系统，以上所述的本质安全很难被实现和应用。因此我们只能采用功能安全，它的目的就是在本质安全无法达到时，尽可能的通过增加安全机制去提高安全等级，实现安全目标。

1.2 电子控制器的功能安全

对于汽车而言，可将汽车看成一个“机器人”，驾驶员给这个“机器人”发送信号，比如踩踏板加油，汽车收到命令然后执行：电喷系统增加喷油，发动机输出扭矩增加，实现车辆加速。

对于传统汽车而言，它的结构简单，且大多数命令都是通过机械方式来实现的，如老式汽车的机械式节气门等，其失效的可预见性大；而现在汽车，其电子电气化增强，驾驶员的指令会先转换成相关信号，然后这些信号传递给控制器的处理芯片，然后最终驱动相关的执行器来执行，其失效的可预见性大大降低。

正因为现代汽车随着电子电气化的程度越来越高，其整车的安全性很大程度就取决于电子控制器的安全性，比如发动机控制器ECU，变速箱控制器TCU，车辆稳定性控制器ESP等等。而且电子控制器失效的可预见性非常低，比如芯片／电路受外界干扰等，这很难预料什么情况会出问题。 因此必须考虑电子控制器失效了会怎么办的问题。

1.3 功能安全考虑的角度

针对电子控制器失效了怎么办这个问题，首先得确定一个角度。比如极端高温情况下的ECU自燃，爆炸等这种系统本身带来的风险，这种风险不在功能安全的考虑范围内。

从产品安全的角度来说，可将其安全分为传统安全以及由电子/电气功能安全，传统安全包括：与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由电子电气安全相关系统的故障行为而引起的。传统安全不在功能安全的考虑范围之内。

根据国际上知名的安全协会的定义，比如英国的MISARA（The Motor Industry Software Reliability Association 汽车工业软件可靠性协会），比如德国的德国VDA协会（VDA（Verband der Automobilindutrie）德国汽车工业协会）他们是从车辆可控性的角度对功能安全提出要求。而IEC-61508强调从人身安全（还可以考虑设备安全）角度提出需求。

因此从车辆可控性和人身安全两个层面上考虑功能安全就有了着陆点。比如考虑是不是有非驾驶员期望的加速等，而非驾驶员期望的减速其实是降低了安全边界，但车辆扔被驾驶员控制着。这就是为什么ECU不对相关控制器的减扭做监控的原因。

1.4 ISO26262中对功能安全的定义

ISO 26262是专门用作提升汽车电子电气产品功能安全的国际标准，它派生于电子、电气及可编程器件功能安全基本标准IEC61508。那26262是如下定义功能安全这个概念的：

English definition:absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems；

没有由电子、电气系统故障行为导致的危险所引起的不合理风险。

我们来分解下这段话：

A.没有风险：absence of risk

B.没有不合理风险 unreasonable

C.没有由电子、电气系统故障行为导致的危险所引起的不合理风险

其中的关键词是不合理风险，什么是不合理风险呢，比如车辆行驶时安全气囊蹦出来了，这是不合理风险，这是功能安全需要避免的问题。

总体来说，功能安全是指避免由系统功能性故障导致的不可接受的风险。它关注的是系统发生故障之后的行为，而不是系统的原有功能或性能。因此功能安全的目的就是当系统发生故障后，将系统进入安全的可控模式，避免对人身、财产造成伤害。

2，ASIL汽车安全完整性等级

2.1 危险事件的确定

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

软件失效：比如没有考虑分母可能为0；变量公式定义错误，导致精度丢失；

硬件失效：如下图所示可以分为传感器失效；ECU硬件失效（比如CPU或者RAM/ROM失效）；执行器失效；

依据ISO 26262标准进行功能安全设计时，首先识别系统的功能，并分析其所有可能的功能故障（Malfunction）或失效，可采用的分析方法有HAZOP，FMEA、头脑风暴等。

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

所以进行功能故障分析后，要进行情景分析，识别与此故障相关的驾驶情景，比如：高速公路超车、车库停车等。分析驾驶情景建议从公路类型（国道，高速），路面情况，（湿滑、冰雪）；车辆状态（转向、 超车、制动、加速等），环境条件（风雪雨尘、夜晚、隧道灯），人员情况（乘客、路人）等几个方面去考虑。功能故障和驾驶场景的组合叫做危害事件（hazard event）。

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

2.2 ASIL等级

ASIL等级的定义是为了对失效后带来的风险进行评估和量化以达到安全目标，其全称是Automotive Safety Integration Level--汽车安全完整性等级。这个概念来源于IEC61508，其通过失效概率的方式定义了安全完整性等级（SIL）。但是在汽车界只有硬件随机失效可以通过统计数字评估失效概率，软件失效却难以量化，因此26262根据汽车的特点定义了ASIL。

如上节所述ASIL的评定，一般是在产品概念设计阶段对系统进行危害分析和风险评估，识别出系统的危害，如果系统的安全风险越大，对应的安全要求级别就越高，其具有的ASIL的等级也越高。ASIL分为QM，A、B、C、D五个等级，ASIL D是最高的汽车安全完整性等级，对功能安全的要求最高。

2.3 危险分析和风险评定

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

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

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

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

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

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

A. 基本可控C0的组合不考虑；

B. 无伤害S0的组合不考虑；

C. 其余组合相加等于7分为ASIL A，等于8分为ASIL B，等于9分为ASIL C，等于10分为最高等级ASIL D；ASIL A、B、C、D都是与功能安全相关的（Safety Relevant Function）

D. 其余的得分安全评定为QM，代表与安全无关的功能（Non Safety Relevant Function）

下面举几个例子进行说明：

1，EPB（Electrical Park Brake）电子手刹

以电子手刹的驻车功能为例，当驻车时，驾驶员通过按钮或者其他方式触发制动请求，EPB在汽车的后轮上施加制动力，以防止车非期望的滑行。该系统的危害有非期望的制动失效，非期望的制动启动。相同的危害在不同场景下风险也是不一样的，因此也要对不同场景进行分析。分析如下表所示：

得出了EPB系统的安全目标为：防止非期望的制动，ASIL等级为D

根据上面的分析，不难得出其它例子的ASIL 等级，比如：

2.4 功能安全目标的分解

通过上危害分析和风险评估，我们得出系统或功能的安全目标和相应的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等级分解可如下图所示：

参考原文：blog.csdn.net/Todd_yc/a