鉴源论坛丨汽车电子ISO 26262：2018标准概述（一）

作者 | 郭建 上海控安可信软件创新研究院特聘专家

版块 | 鉴源论坛 · 观模

摘要：安全在汽车研发中是关键要素之一，辅助驾驶、车辆的动态控制等功能的研发和集成都需要加强安全系统研发，同时，需要为满足所有预期的安全目标提供证据。随着系统复杂性的提高，软件和机电设备的应用，来自系统失效和随机硬件失效的风险也日益增加。ISO 26262标准使得人们对安全相关功能有一个更好的理解，并尽可能明确地对它们进行解释，同时为避免这些风险提供了可行性的要求和流程。

我们将通过2次推文介绍ISO 26262：2018的国际标准。

ISO 26262是从电子、电气及可编程器件功能安全基本标准IEC 61508派生出来的，主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件，旨在提高汽车电子、电气产品功能安全的国际标准。

ISO 26262从2005年11月起正式开始制定，经历了大约6年左右的时间，已于2011年11月正式颁布，成为国际标准。中国也于2017年颁布了相应的标准。在2018年，新的ISO 26262：2018国际标准颁布，增加了半导体和摩托车的规范标准。

ISO 26262为汽车安全提供了一个生命周期（管理、开发、生产、经营、服务、报废）理念，并在这些生命周期阶段中提供必要的支持。该标准涵盖功能性安全方面的整体开发过程（包括需求规划、设计、实施、集成、验证、确认和配置）。

ISO 26262：2018国际标准共分为12部分，它们是：

第一部分：术语

第二部分：功能安全管理

第三部分：概念阶段

第四部分：产品开发：系统层面

第五部分：产品开发：硬件层面

第六部分：产品开发：软件层面

第七部分：生产、运营、服务和报废

第八部分：支持过程

第九部分：以汽车安全完整性等级为导向和以安全为导向的分析

第十部分：ISO 26262的指南

第十一部分：ISO 26262对半导体应用的指南

第十二部分：ISO 26262对摩托车的适应性

ISO 26262：2018国际标准的架构如图1所示：

 图1 ISO 26262总体架构图

在本次推文中，针对ISO 26262：2018国际标准的第一部分到第五部分做简要的介绍。

Part 1

术语

在Part1给出了185个术语的解释，比2011版的增加了43个术语，并对相关术语的解释更加准确、清晰和易懂，由于技术的发展，又增加了一些新的术语的解释。并给出了关于缩写的解释107个，比2011版的增加了56个，使得2018版更具有完整性。

Part 2

功能安全管理

Part2对功能安全管理总署、功能安全的审核流程和要求做了详细的介绍，确保参与安全生命周期建立并保持一种安全文化，以支持和鼓励有效的成就，促进与其他相关学科对功能安全的有效沟通；为功能安全制定并维护适当的组织规则和流程；制定和维护流程，以确保已识别的安全异常得到充分解决；建立并维护能力管理体系，以确保相关人员与其职责相称；建立和维护质量管理体系，以支持功能安全。

在功能安全管理中，包括依赖项目的安全管理和生产、运营、服务和报废的安全管理。对于依赖项目的安全管理要确保参与概念阶段或开发阶段的组织在系统、硬件或软件层面要求定义和分配有关安全活动的角色和责任；对相关项进行影响分析，以识别相关项是新相关项、是对现有相关项修改、还是修改环境的现有相关项。在一个或多个修改需要的情况下，分析修改对功能安全的影响；对元素级别进行影响分析，元素若被重新使用，需要评估重新使用的元素是否能够遵守分配给该元素的安全要求，同时需要考虑元素被重新使用的操作环境；对于量身定制的安全活动，要提供相应的理由，并审查所提供的理由；需要规划安全活动；协调和跟踪安全活动的进展以符合安全计划；需要计划分布式开发；确保安全活动在整个安全生命周期中能够正确进行；可以创建一个可理解的安全案例，为实现功能安全提供论据；判断设计是否实现了功能安全（即功能安全评估），或判断对实现某一要素是否实现了功能安全或判断工作产品的功能安全；在开发结束时，根据支持对所实现的功能安全提供证据，决定相关项或元素是否可以发布用于生产。

对于生产、运营、服务和报废的安全管理的目标是需要定义负责实现和维护生产、运营、服务和报废的功能安全的组织和人员的责任。

图2说明了与安全生命周期相关的管理活动。

图2 与安全生命周期有关的管理活动

在图2中，ISO 26262：2018各部分的具体条款如下所示：“m-n”，其中“m”表示该部分的编号，“n”表示该条款的编号，例如“3-6”表示ISO 26262-3：2018第6条。

Part 3

概念阶段

在概念阶段给出了相关项的定义、危害分析和风险评估，以及功能安全概念。

在相关项的定义中，定义和描述相关项、相关项的功能、相关项对驾驶员的依赖程度以及与驾驶员、环境和车辆级别的其他相关项的交互；支持对相关项的准确理解，以便执行后续阶段的活动能够执行。

在危害分析和风险评估时，能够识别并分类由相关项故障行为引起的危险事件；制定与预防或缓解危害事件相关的安全目标及其相应的ASIL等级，以避免不合理的风险。

对于危害分析和风险评估，可以用函数（F）描述，该函数有三个参数：危害事件的发生频率（ f ）、可控性（C），即通过相关人员的及时反应避免特定危害或损害的能力，以及由此造成的危害或损害的潜在严重程度（S）：

发生频率 f 又受到两个因素的影响，处于危害事件可能发生的频率和持续时间。在ISO 26262中，被简化为可能发生危害事件的概率（暴露，E）。另一个因素是相关项中故障的发生率，在危害分析和风险评估过程中不考虑这一因素。因此，在危害分析和风险评估中，E、S、C的分类会形成ASIL（automotive safety integrity level，汽车安全完整性等级）确定相关项的最低要求集，以控制或降低随机硬件故障的概率，并避免系统故障。相关项的故障率并不能认为是可以推理演绎的,因为可通过实现所得出的安全要求来避免不合理的残余风险。

危害分析和风险评估子阶段包括三个步骤：

第一步：场景分析和危害识别：场景分析和危险识别的目标是识别可能导致危害事件的相关项的潜在非预期行为。场景分析和危害识别活动需要对相关项、及其功能和边界进行清晰的定义。它是基于相关项的行为；因此，相关项的详细设计并不一定需要知道。

第二步：危害事件的分类：危害分类方案包括确定相关项危害事件的严重程度、暴露概率和可控性。严重程度表示对特定驾驶情况下潜在危害的估计，暴露概率由相应的情况决定，可控性衡量了驾驶员或其他道路交通参与者在所考虑到的运行场景中避免所考虑到的事故的难易程度。对于每种危害，根据相关危害事件的数量，分类将产生一个或多个严重性、暴露概率和可控性的组合。

第三步：ASIL确定：确定所需的汽车安全完整性等级。

功能安全概念根据其安全目标规定相关项的功能或降解功能的行为；根据其安全目标，规定有关检测，控制相关故障的约束条件；规定相关项级别的策略或措施，以获得所需的故障容错，或通过相关项自身、驾驶员或外部措施充分减轻相关故障的影响；将功能安全要求分配给系统体系结构设计或外部判定；验证功能安全概念并规定安全验证标准。

Part 4

产品开发：系统层面

系统开发过程包括技术安全概念、硬件层面的产品开发、软件层面的产品开发、系统与相关项的集成和测试、安全确认等必要活动，如图3所示。在迭代过程中，开发了技术安全概念，并将技术安全需求和系统架构设计结合起来。建立了系统体系结构，将技术安全需求分配到系统的元素，如果适用，还会分配其他技术到系统上。此外，还细化了技术安全需求，增加了系统架构产生的需求，包括软硬件接口（HSI）。根据体系结构的复杂性，可以迭代地导出子系统的需求。

开发完成后，对硬件和软件元素进行集成和测试，形成一个项目，然后将其集成到车辆中。一旦在车辆级别集成，就要进行安全确认，以提供与安全目标相关的功能安全证据。

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

在技术安全概念子阶段，需要规定有关系统元素及其实现所需接口的功能、依赖性、约束和属性的技术安全要求；规定系统元素和接口中实施的安全机制的技术安全要求；在生产、运行、服务和报废期间系统及其元素的功能安全要求；验证技术安全需求是否适合在系统级别实现功能安全，并与功能安全需求一致。开发满足安全需求且与非安全相关需求不冲突的系统架构设计和技术安全概念；分析系统架构设计，以防止故障，并得出为生产和服务所需的与安全相关的专用属性；以验证系统架构设计和技术安全概念是否满足其各自的ASIL等级的安全需求。

在系统与相关项的集成和测试阶段，需要定义集成步骤并集成系统元素，直到系统完全集成；验证由系统架构级别的安全分析得出定义的安全措施是否能够进行恰当的实现；根据系统架构设计，提供集成系统元素满足其安全要求的证据。

在安全确认阶段，需要提供证据，证明该相关项在集成到相应车辆中是实现了安全目标；并提供证据证明功能安全概念和技术安全概念适用于实现相关项的功能安全。

ISO 26262-4适用于系统的开发，ISO 26262-5和ISO 26262-6分别描述了硬件和软件的开发要求。图4是一个具有多级集成的系统示例，说明了ISO 26262-4、ISO 26262-5和ISO 26262-6标准的应用。

图4 系统级产品开发的一个示例

Part 5

产品开发：硬件层面

硬件级产品开发过程步骤，包括根据ISO 2626-4的技术安全概念得到在硬件开发层面产品开发的一般问题，然后获得硬件安全需求规范，紧接着就要硬件设计、硬件架构度量的评估、随机硬件故障导致违背安全目标的评估，以及最后的硬件集成与验证。开发过程如图5所示。

图5 硬件层产品开发的参考阶段模型

硬件层面的产品开发所需的活动和过程包括：技术安全概念的硬件实现；潜在硬件故障及其影响的分析；和与软件开发的协调。

在硬件安全需求规范子阶段规定硬件安全要求。它们来源于技术安全概念和系统架构设计规范；完善ISO 26262-4:2018，6.4.7中提出的软硬件接口（HSI）规范；以及验证硬件安全要求和软硬件接口（HSI）规范是否符合技术安全概念和系统架构设计规范。

在硬件设计阶段，创建硬件设计，支持以安全为导向的分析；以安全为导向的分析结果；以满足硬件安全要求；软硬件接口（HSI）规范；符合系统架构设计规范；及满足所需的硬件设计属性。

在该阶段规定生产、运行、服务和报废期间硬件的功能安全要求并提供相关信息。

硬件开发中及完成后，需要验证硬件设计能够满足硬件安全要求和软硬件接口（HSI）规范；用于开发集成在已开发硬件中的每个SEooC假设的有效性；安全相关特殊属性在生产和服务过程中实现的功能安全的适用性。

在硬件架构度量的评估子阶段，基于硬件体系结构度量。提供关于检测和控制安全相关随机硬件故障的相关项的硬件体系结构设计适用性的证据。

在随机硬件故障导致违背安全目标的评估子阶段，能够提供证据证明由于相关项的随机硬件故障导致的违反安全目标的残余风险足够低。

在硬件集成与验证子阶段，确保所开发的硬件符合硬件安全需求。

本文对ISO 26262：2018国际标准的第一部分到第五部分的内容做了一个简单的介绍，我们将在下一次推文中对其的后半部分做介绍。