从入职现在的工作到今天，一年零三个月的时间。期间公众号放在这里，都长草了 :D。看着大牛们每天工作还日更不辍，特别特别佩服，牛人都不知道哪里能找到辣么多的时间。。。虽然如此，臣妾还是做不到日更啊啊啊。想着，以后把觉得有些条理的学习笔记和想法发到公众号上来，今天，不定期更新，第一篇。

对于功能安全，从听说它的存在开始，就觉得是好东西，就是一直没有机会好好看看。这次十一假期，终于有机会。下面的内容，有总结也有摘录。不合适的地方，欢迎探讨。

ISO26262是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的，主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件。

ISO26262从2005年11月起正式开始制定，经历了大约6年左右的时间，已于2011年11月正式颁布，成为国际标准。国标修改采用了该标准，编纂初版了我国的道路车辆功能安全国标《GB∕T 34590-2017 道路车辆 功能安全》。2018年12月，ISO26262更新到第二版，国标没有那么快，2017版是基于ISO 26262 的2011版的。

1、概述

道路车辆功能安全标准分为10个部分：术语、功能安全管理、概念阶段、产品开发-系统层、产品开发-硬件层、产品开发-软件层、生产和操作、支持过程、汽车安全完整性等级导向和安全导向分析、指南。这十个个章节的特点概述如下。

第1部分：术语，以名词解释的方式，表明在功能安全体系中各个词语的特别含义，我们确实不能望文生义，由于是翻译词汇，什么走查、检查，什么评审、评估，还有各种失效率，确实需要抠字眼。

第2部分：功能安全管理，综合阐述该系列标准是基于产品全生命周期的开发、管理、实施的标准，界定不同生命阶段所需要的功能安全概念和管理措施；

第3部分：概念阶段，对应到产品定义立项阶段，需要对产品功能安全作出整体规划。具体操作就是针对产品的各种功能在不同场景下可能产生的安全问题进行危害分析和风险评估，明确各个功能的安全目标，从安全目标推导至安全需求，进而拆解到产品的系统设计上，落实到对硬件、软件的技术安全需求。

第4部分：产品开发：系统层面，包括基于系统层面的从功能安全目标到技术安全需求的拆解过程；并考虑技术安全需求的落实、集成测试、安全确认、功能安全评估以及生产发布的整个过程；

第5部分：产品开发：硬件层面，从系统级别的功能安全目标，拆解到各级硬件上的功能安全目标，转化成功能安全需求，进而通过技术安全需求，选择实现功能安全目标的具体技术手段，并考虑硬件涉及的测试和功能安全相关评估活动；

第6部分：产品开发：软件层面，与前面硬件类似的过程，也是从功能安全目标到具体技术方案设计实现及测试验证系列活动；

第7部分：生产和运行，主要考虑产品生命周期中涉及的生产、运行、售后、报废几个生命阶段中，与功能安全相关的部分；

第8部分：支持过程，是对产品生命周期中关于分布式开发接口（也就是整车行业当前最主要的供应商提供一级部件的开发形式）、设计变更、开发工具的评审及其他与功能安全的评审认可相关的必要活动的解释说明；

第9部分：以汽车安全完整性等级为导向和以安全为导向的分析，是强调站在功能安全的角度梳理产品全生命周期内几项关键工作的执行方式；

第10部分：指南，是前面9个部分的补充说明和阅读指南，通过增补一些实际案例，解说之前的概念在具体应用过程中的实现方式和注意事项。

2、实施

在产品开发阶段，ISO26262按汽车工业中常用的V型开发流程定义相关安全活动：V型的左侧是技术安全需求（功能安全概念的技术实现途径）的制定、系统/软件/硬件设计；V型的右侧是软硬件测试、系统集成测试。

2.1 功能安全危害分析与风险评估

提出了确定功能安全等级(ASIL)的方法，安全等级范围是A、B、C、D，其中ASIL A安全等级最低，ASILD安全等级最高。在整车和系统电子设计时，需要确定所设计项目的范围。基于项目定义，确定项目的安全目标，避免不合理的风险。ASIL使用3个参数进行评估，分别是：危险对驾驶员或其他交通参与人员造成伤害的严重程度S，危险所在工况的发生概率E，危险涉及的驾驶员和其他交通参与人员及时采取控制行动避免特定伤害的能力C。S分为0～3级，如表1所示，S0代表无伤害，S3代表危及生命的重伤或致命伤；E分为0～4级，如表2所示，E0代表工况不可能发生，E4代表工况是常见的；C分为0～3级，如表3所示，C0代表完全可控，C3代表非常难于控制。对于每一个识别到的危险，按表4评估风险等级（即汽车安全完整性等级），其中QM表示与安全无关。

以上评估是在同一个层面上进行的，而在从系统到子系统，或者高的功能安全目标实施过程中，发现单一的技术安全需求太高，需要通过多个技术手段去实现一个功能安全需求，这里就用到了功能安全等级的分解。ASILB、ASILC、ASILD、有着明确的分解方案。

1）ASILD可以按照下面的一个方案进行分解：一个ASILC（D）和一个ASILA（D）；

或者 一个ASILB（D）和一个ASILB（D）；

或者一个ASILD（D）和一个QM（D）；

2）ASILC可以按照下面的一个方案进行分解：一个ASILB（C）和一个ASILA（C）；或者一个ASILC（C）和一个QM（C）；

3）ASILB可以按照下面的一个方案进行分解：一个ASILA（B）和一个ASILA（B）；或者一个ASILB（B）和一个QM（B）；

其中，括号里的（D）含义是该功能安全等级要求来自于一个最高的功能安全等级要求D的分解。原标准中的图示如下：

2. 2 功能安全系统设计

系统级产品功能安全设计要求包括产品开发的启动、技术安全要求中的规范、系统设计、项目集成和测试、安全验证、功能安全评估、生产发布。如图2所示。在启动产品开发和定义技术安全要求后，进行系统设计。在系统设计过程中建立系统架构，将技术安全要求分配给硬件和软件，并且，如果适用，也可应用其它技术。同时，细化技术安全要求，并添加来自系统架构的要求，包括软硬件接口的要求。根据架构的复杂性，可以逐步得出子系统的需求。开发后，集成硬件和软件要素并测试以形成一个相关项，然后，将该相关项集成在整车上。一旦在整车层面完成了系统集成，进行安全确认以提供与安全目标相关的功能安全证据。

安全相关项开发参考阶段模型

系统层面产品开发示例

2 3 功能安全软硬件设计

如图2所示，在系统功能安全设计时，需要制定软硬件接口HIS要求，根据表4分析确定的不同功能安全等级，在进行具体软件和硬件设计时也要有具体要求。总体来说，硬件功能安全设计体现了不同安全等级的定量要求，如表5和表6所示。硬件功能安全要求包括硬件产品开发的启动、硬件安全规格的要求、硬件设计、硬件架构指标、对由于硬件随机失效引起的违反安全目标进行评估、硬件集成和测试。软件功能安全等级的定性要求，如图3所示。软件功能安全要求包括软件级产品开发的启动、软件安全要求的规格、软件架构设计、软件单元设计与执行、软件单元测试、软件集成和测试、软件安全要求的验证。

硬件层面产品开发参考阶段模型

软件层面产品开发参考阶段模型

3 汽车电控系统安全等级验证评估要求

汽车电控系统功能安全等级的验证评估主要从测试验证和文档评审来确定。

3. 1 功能安全测试要求

功能安全测试分为软硬件测试、系统集成测试、整车集成测试。软硬件测试主要针对软件和硬件设计的具体单元、功能模块进行确认实施，其中硬件测试主要是失效率的验证、功能的确认、EMC等性能测试，软件测试主要是单元模块测试、不同测试方法的覆盖。

系统集成测试主要是对不同安全等级对应的安全场景、故障反应时间、故障处理措施、安全状态的确认。整车集成实施主要是在实车环境中依据危害分析和风险评估的结果进行各种故障注入测试，确认实车环境下各电控系统能够满足不同功能安全等级的要求。

3. 2 功能安全文档要求

根据功能安全标准的要求，在功能安全管理、概念阶段、产品系统设计、硬件设计、软件设计、生产发布、支持过程等环节，对应有诸多的功能安全工作成果。对于不同电控系统的设计需求，可以对这些工作成果即文档进行功能安全裁剪。按照标准要求，对这些文档进行审核确认。

3. 3 功能安全等级评估

功能安全等级评估可以分为五个阶段完成：安全理念认可、功能/基本安全试验、硬件安全完整性分析与测试、软件安全性分析与测试、功能安全等级认定。其中，安全理念认可包括安全管理计划审核、验证与确认计划审核、功能/安全需求规格说明书审核、安全相关的文档体系评估、产品生产质量管理文档评估、已采用的故障避免措施评估。功能/基本安全试验包括安全相关的EMC试验、环境试验、化学试验、故障注入测试、FMEDA分析、安全相关的功能测试等；硬件安全完整性分析与测试包括危险与风险分析、故障注入测试、系统建模与安全参数计算等。软件安全性分析与测试包括软件代码安全性分析、软件架构安全分析、软件测试工作完善性分析、HIL咨询测试、项目开发工具安全适用性分析。依据上述的评审，最终进行功能安全等级的确认。

不同功能安全等级，其要求进行认可的项目不完全相同，标准原文给出了关于实施确认措施的推荐方式。

参考文献

1、汽车电子功能安全设计与测试方法的研究_王铁

2、于ISO26262的BMS概念阶段开发概述_田星

3、基于ISO26262的动力电池系统高压功能安全概念_朱叶

4、基于ISO26262的整车电源模式管理系统功能安全概念设计_童菲

5、安全完整性等级验证计算在化工装置中的应用研究_张兆祥