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标准的架构如图1所示：

图1 ISO 26262总体架构图

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

Part6

产品开发：软件层面

软件开发过程要确保一个合适且一致的软件开发过程或开发方法，以确保合适的软件开发环境。软件开发的参考阶段模型如图2所示。

图2软件层产品开发的参考阶段模型

例如，敏捷软件开发的开发方法也适用于安全相关软件的开发，但如果安全活动被剪裁，则应考虑ISO 26262-2:2018 6.4.5。然而，敏捷开发方法不能省略安全措施或忽视实现功能安全所需的基本文件、过程或安全完整性。

再如，基于测试的开发方法也可用于改善提高需求质量，并提高可测性。

在安全需求规范子阶段，要求规定或完善源自技术安全概念和系统架构设计规范的软件安全需求；定义实施所需软件的安全相关功能和属性；完善ISO 26262-4:2018第6条中提出的软硬件接口要求；验证软件安全要求和软硬件接口要求是否适合软件开发，是否符合技术安全概念和系统架构设计规范。

在软件架构设计子阶段，需要开发满足软件安全需求和其他软件需求的软件架构设计；验证软件体系结构设计是否适合满足所需具有ASIL的软件安全需求；以便支持软件的实施和验证。

在软件的单元设计与实现子阶段，需要根据软件体系结构设计、设计标准和相关软件需求开发软件单元设计，以支持软件单元的实现和验证；按照规范实现软件单元。

在软件单元验证子阶段，提供证据证明软件单元设计满足所分配的软件需求；验证在安全分析阶段所确定的安全措施是否得到了正确实现；提供证据证明所实现的软件单元符合单元设计并满足所分配的ASIL等级的软件需求；提供充分证据证明软件单元既不包含不需要的功能，也不包含关于功能安全的不需要的属性。

在软件集成和验证子阶段，需要定义集成步骤并集成软件元素，直到嵌入式软件被完全集成；验证由软件体系结构级别的安全分析产生定义的安全措施是否得到了正确实现；提供证据证明集成的软件单元和软件组件符合软件体系结构设计的需求；提供充分证据证明集成软件既不包含不需要的功能，也不包含关于功能安全的不需要的属性。

在嵌入式软件测试子阶段，需要提供证据证明嵌入式软件在目标环境中执行满足软件安全需求；既不包含不需要的功能，也不包含关于功能安全的不需要的属性。

在软件配置子阶段，以实现针对不同应用的软件行为的受控改变；提供配置数据和校准数据满足所需ASIL等级要求的证据；提供特定应用程序的嵌入式软件及其校准数据适合发布、用于生产的证据。

Part7

生产、运营、服务和报废

在生产、运营、服务和报废需要制定和维护拟安装在道路车辆上的安全相关的元件或相关项的生产流程；可以根据组织在安全供应链中的地位和生产的安全相关要素的复杂性，通过组织遵守IATF 16949或同等标准来实现。开发有关运营、服务（维护和维修）和报废的必要信息，以确保在车辆的整个生命周期中都能满足功能安全。

在生产子阶段，需要确保相关制造商或负责相关项和元件生产过程的人员或组织（车辆制造商、供应商、次级供应商等）在生产阶段（或生产后）满足功能安全。

在运营、服务和报废子阶段，需要确保在车辆生命周期的各个子阶段运营、服务（维护和维修）和报废期间满足功能安全。

Part8

支持过程

支持过程阶段包括分布式开发的接口、安全需求的规范及管理、配置管理、更改管理、验证、文档管理、软件工具使用的置信度、软件组件的鉴定、硬件元素的评估、在用证明、超出ISO 26262范围的连接的应用程序、未根据ISO 26262开发的安全相关系统的集成。

分布式开发的接口需要为开发活动定义客户和供应商之间的交互和依赖关系；并描述职责分工；识别相关项和要素进行分布式开发的流程及相关责任的分配。

安全需求的规范及管理要确保安全需求在其属性和特性方面的正确规范；以及确保在整个安全生命周期中对安全需求的一致管理。

配置管理需要确保工作产品、相关项、要素及其生产的原理和一般条件能够在任何时候以受控的方式进行唯一识别和复制；并能确保可以追溯早期版本和当前版本之间的关系和差异。

更改管理是在整个安全生命周期内分析和控制安全相关的工作产品、相关项和要素的变更。

验证需要确保工作产品符合其需求。

文档管理需要制定整个安全生命周期内的文件管理策略，以促进有效和可重复的文件管理过程。

软件工具使用的置信度需要提供标准，以确定软件工具在应用时中所需的置信水平；在应用软件工具时，为软件工具的资格鉴定提供手段，以创建证据，证明软件工具适合用于支持ISO 26262系列标准所要求的活动或任务。即，用户可以依靠软件工具的正确功能来完成ISO 26262标准系列所要求的那些活动或任务。

软件组件鉴定是为其在符合ISO 26262系列标准开发的相关项可重复使用提供证据。

硬件元素的评估确保功能行为足以满足分配的安全需求，因此，由于硬件元件的系统故障而违反安全目标或安全需求的风险应该足够低。基于随机故障管理的使用适合性是由被评估硬件元件的集成在设计集成的下一个最高级别确定的。术语“硬件元件”指的是COTS硬件组件或部件，或者是定制硬件组件或部件，这些组件或部件最初不是根据ISO 26262系列标准开发或设计的，并且在符合ISO 26262标准的相关项或元件的上下文中被认为是安全相关的，它们将会被集成在其中。更确切地说，硬件元件的评估是符合ISO 26262-5的一种替代方法。符合评估条件的硬件元素可以是特定应用程序，也可以是标准元素。这些元件通常被开发用于许多行业，汽车或非汽车行业。

在用证明是为经验证的使用论证提供指导。经验证的使用论证是一种符合ISO 26262系列标准的替代方法，当现场数据可用时，可在重复使用现有相关项或元素的情况下使用。

超出ISO 26262范围的应用程序要确保超出ISO 26262范围的应用，不会违反根据ISO 26262系列标准开发的基本车辆或相关项的安全目标。

未根据ISO 26262开发的安全相关系统的集成要确保未按照ISO 26262开发的系统或组件满足集成到根据ISO 26262研发的相关项中所需的功能安全水平。

Part9

以汽车安全完整性等级（ASIL）为导向

和以安全为导向的分析

以汽车安全完整性等级（ASIL）为导向和以安全为导向的分析包括ASIL等级剪裁的需求分解、元素共存标准、相关故障分析、安全分析。

ASIL等级剪裁的需求分解确保在分解的下一个细节层次上将安全需求的分解是冗余安全需求，并将这些需求分配给足够独立的设计元素；以及按照允许的ASIL分解模式应用ASIL分解。

元素共存标准包括与安全相关的子元素与非安全相关的子元素；分配了不同ASIL等级的安全相关子元素。

相关故障分析通过分析其潜在原因或引发因素，确认在设计中充分实现了所需的独立性或不受干扰的自由度；如有必要，确定安全措施以缓解可能的相关故障。

安全分析确保由于系统故障或随机硬件故障导致的违反安全目标的风险足够低。根据应用情况，可以通过以下方式实现：

✔ 识别在危险分析和风险评估过程中未识别的新危险；

✔ 分别识别可能导致违反安全目标或安全需求的故障；

✔确定其潜在原因；

✔分别支持故障预防或故障控制安全措施的定义；

✔为安全概念的适用性提供证据；

✔支持安全概念、安全要求的验证，以及设计要求和测试要求的识别。

Part10

ISO 26262的指南

该文档给出在运用ISO 26262开发时的一些指南，包括在相关项及定义、ISO 26262的关键概念、关于安全管理方面的、概念阶段和系统开发阶段、安全过程的需求架构、硬件开发阶段、超出ISO 26262的安全元素、在用元素验证、关于ASIL等级分解、具有安全相关可用性需求的系统开发指南、关于“使用软件工具的信心”的备注、安全相关特殊特性等方面的指南。

Part11

ISO 26262对半导体应用的指南

这是在ISO 26262：2018版新增加的部分。对半导体应用的指南包括半导体元件及其划分、具体的半导体技术和使用案例的指南。

在半导体元件及其划分子阶段，包括在如何考虑半导体元件、将半导体元件分成若干部分、考虑硬件的故障、错误及失效模式、在系统层面关于半导体元件的安全分析、IP、半导体的基本故障率、半导体依赖故障分析、故障注入、生产与运营、分布式开发的接口、确认措施、硬件集成和验证的确认等方面的指南。

具体的半导体技术和使用案例子阶段，包括在数字元件和存储器、模拟/混合信号元件、可编程逻辑器件、传感器及转换器等方面的指南。

Part 12

ISO 26262对摩托车的适应性

为了使摩托车上的E/E系统符合ISO 26262系列标准，应满足ISO 26262-2至ISO 26262-9的所有要求。一些需求可能需要一定程度的裁剪才能适用于摩托车。在这种情况下，这些量身定制的需求取代了ISO 26262系列标准的相应需求。

对于摩托车适用ISO 26262系列标准，需要在安全管理的安全文化、确认措施、关于生产、运营、服务和报废等方面的说明；在概念阶段的危害分析和风险评估、功能安全概念等方面的说明；在系统层的产品开发的技术安全概念、在相关项的集成与测试、安全的有效性方法的说明。

在安全管理的安全文化子阶段确保参与执行安全生命周期的组织，即负责安全生命周期或在安全生命周期中执行安全活动的组织，需要建立并保持一种安全文化，支持和鼓励有效地实现功能安全，并促进与功能安全相关的其他学科的有效沟通；为功能安全制定并维护适当的组织特定规则和流程；以确保已识别的安全异常得到充分解决；建立并保持能力管理体系，以确保相关人员的能力与其职责相称；建立和维护质量管理体系，以支持功能安全。

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

在关于生产、运营、服务和报废子阶段定义负责实现和维护生产、运营、服务和报废的功能安全的组织和人员的责任。

在概念阶段的相关项定义子阶段定义和描述相关项、其功能、对驾驶员的依赖性以及与驾驶员、环境和车辆级别的其他相关项的交互；支持对相关项的充分理解，从而可以执行后续阶段的活动。

在概念阶段的危害分析和风险评估子阶段规定进行摩托车特定危险分析和风险评估所需遵守的必要要求；识别和分类由相关项故障行为引起的危险事件；制定安全目标及其相应的ASIL等级，危险事件的预防或缓解，以避免不合理的风险。

功能安全概念子阶段根据其安全目标规定相关项的功能或退化功能行为；根据其安全目标，规定有关适当和及时检测和控制相关故障的约束条件；规定相关项级策略或措施，通过驾驶员或通过外部措施，以实现所需的容错或充分减轻相关项相关故障的影响；将功能安全需求分配给系统架构设计或外部措施；验证功能安全概念并规定安全验证标准。

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

在相关项的集成与测试子阶段定义集成步骤并集成系统元件，直到系统完全集成；验证由系统架构级别的安全分析得出的安全措施是否得到了正确实施；根据系统架构设计提供集成系统元件满足其安全需求的证据。

在安全的有效性子阶段提供证据，证明该相关项在集成到相应车辆中实现了安全目标；提供证据证明功能安全概念和技术安全概念符合实现相关项的功能安全。

小结

今天的新能源车、自动驾驶等汽车的发展方向越来越依赖于电子系统和软件。新系统的出现带来了故障模式的新风险。车企在设计中努力识别和评估风险，并采取有效措施减少或消除这种风险，尽一切努力确保其产品的安全运行或使用。ISO 26262：2018国际标准的发布能够帮助企业确保其电子电气系统的功能安全，并在产品开发过程尽早识别和分析风险，建立安全目标，通过一个全面的验证计划实现这些目标。