5.1目的

全面安全管理的目的是确保参与执行安全生命周期的组织，i.e.那些负责安全生命周期或在安全生命周期中执行安全活动的人，实现以下目标：

a. 建立和保持一种支持和鼓励有效实现功能安全的安全文化，并促进与其他与功能安全的有效沟通；

b. 建立和保持适当的组织特定的规章和流程，以实现功能安全；

c. 建立和维护流程，以确保适当解决已确定的安全异常；

d. 建立和维持能力管理制度，以确保有关人员的能力与其职责相称；以及

e. 建立和维护质量管理体系，以支持功能安全。

全面安全管理作为ISO26262安全生命周期中活动的前提条件。

5.2.概述

5.2.1安全生命周期概述

ISO26262参考安全生命周期包括概念阶段、产品开发、生产、运行、服务和报废期间的主要安全活动。策划，协调和监控安全活动的进展，以及确保认可措施得到执行的责任，是关键的管理任务，并在整个生命周期内执行，安全生命周期可以定制（见第6条）。

注1：在概念阶段、产品开发、生产、运行、服务和报废期间的安全活动详见ISO26262-3、ISO26262-4、ISO26262-5、ISO26262-6和ISO26262-7。

注2：表A.概述功能安全管理的目标、前提条件和工作成果。

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

注3：在图中，ISO26262的每个部分的具体条款以以下方式表示：“m-n”，其中“m”表示部分的数量，“n”表示条款的数量，例如。“3-6”代表ISO26262-3：2018，第6条。

注4：1)系统级产品开发的子阶段如ISO26262-4：2018所示，图2。

注5：2)硬件层面产品开发的分阶段见ISO26262-5：2018，图2.

注6：3)软件层面的产品开发的子阶段如ISO26262-6：2018所示，图2。

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

5.2.2关于安全生命周期的解释性说明

5.2.2.1概述

ISO26262系列标准规定了有关安全生命周期的特定阶段和子阶段的要求，但也包括适用于安全生命周期的几个或全部阶段的要求，例如功能安全管理的要求。

重点安全管理任务是对功能安全相关活动进行策划，协调和跟踪。这些管理任务适用于安全生命周期的所有阶段。本部分给出了功能安全管理的要求，区别：

Ø 全面安全管理（见第5条）；

Ø 相关项依赖的安全管理，关于概念阶段和产品开发阶段的系统，硬件和软件层面（见第6条）；及

Ø 有关生产、运营、服务和报废的安全管理（见第7条）。

有关开发的安全活动的计划是在概念阶段开始的，并在必要时通过产品开发阶段（系统、硬件和软件）加以完善，直到决定为生产发布该相关项或要素。在系统层面的产品开发期间，启动了生产、运营、服务和报废活动的计划。

5.2.2.2解释了安全生命周期的不同阶段和分阶段的定义。在安全生命周期中需要考虑的其他关键概念在第5.2.2.3款中作了说明。

5.2.2.2安全生命周期的阶段和子阶段

a. 相关项定义（概念阶段的一个子阶段）：

安全生命周期的启动任务是开发相关项的功能、接口、环境条件、法律要求、已知危害等描述。确定相关项及其接口的边界，以及关于其他相关项、要素或外部措施的假设(见ISO26262-3：2018，第5条)。

b. 危险分析和风险评估（概念阶段的一个子阶段）：

危险分析和风险评估按ISO26262-3：2018第6条的规定进行首先，危害分析和风险评估估计了该相关项的暴露概率、可控性和危险事件的严重程度。这些参数共同决定了危险事件的ASILs。随后，危害分析和风险评估确定了该相关项的安全目标，安全目标是该相关项的最高安全要求。为危险事件确定的ASIL被分配到相应的安全目标。对危害分析和风险评估中关于人类行为的假设，包括可控性和人类反应、功能安全概念和技术安全概念以及与ASIL分类有关的技术假设进行了验证(见ISO26262-3：2018，第6条，ISO26262-3：2018，第7条和ISO26262-4：2018，第8条)。

在随后的阶段和子阶段，详细的安全要求是从安全目标中得出的。安全要求继承相应安全目标的ASIL，或在应用ASIL裁剪的情况下，在分解后接收ASIL(见ISO26262-9：2018，第5条)。

c. 功能安全概念（概念阶段的一个子阶段）：

基于安全目标，考虑到初步的架构假设，开发了一个功能安全概念(见ISO26262-3：2018，第7条)。功能安全概念是通过从安全目标中导出功能安全要求并将这些功能安全要求分配给相关项的要素来开发的。功能安全概念还可以包括其他技术或依赖外部措施(见ISO26262-3：2018，第7条)。在这些情况下，相应的假设或预期行为得到验证(见ISO26262-4：2018，第8条)。其他技术的实施不在ISO26262系列标准范围内，外部措施的实施不在相关项开发范围内。

d. 系统层面的产品开发

在功能安全概念指定后，该相关项在系统层面上开发，如ISO26262-4所示。系统开发过程是基于V模型的概念，具有技术安全要求的规范，系统架构，系统设计和实现在左侧，集成，验证和安全确认在右侧。

软硬件接口在此阶段指定。硬件和软件之间的接口在硬件和软件开发过程中进行更新。

ISO26262-4：2018，图2概述了系统开发的子阶段。

系统开发包含了在其他安全生命周期阶段发生的活动的安全确认任务，包括：

Ø 与ASIL分类相关的技术假设；

Ø 关于人类行为的假设的验证，包括可控性和人类反应；

Ø 验证由其他技术实现的功能安全概念的各个方面；以及

Ø 关于外部措施的有效性和绩效的假设的验证。

e. 硬件层面的产品开发

基于系统设计规范，开发硬件(见ISO26262-5)。硬件开发过程是基于V模型的概念，硬件需求的规格说明，硬件设计和实现在左侧，硬件集成和验证在右侧。

ISO26262-5：2018，图2概述了硬件开发的子阶段。

f. 软件层面的产品开发

基于系统设计规范，开发软件(见ISO26262-6)。软件开发过程是基于一个V模型的概念，左边是软件需求的规范和软件架构设计和实现，右边是软件集成和验证。

ISO26262-6：2018，图2概述了软件开发的子阶段。

g. 生产、运营、服务和报废

本阶段的计划(见ISO26262-7：2018，第5条【生产、运营、服务和报废计划】)和相关要求的规范，从系统层面的产品开发过程中开始(见ISO26262-4)，并与系统、硬件和软件开发并行进行。这种计划可以通过交换信息或要求来实现。安全相关的特殊特性或要求，以提高生产产品的能力。

这一阶段涉及确保相关项或要素的生产、运行、服务和报废功能安全的过程、手段和指示。与安全有关的特殊特性以及生产、运行、服务（维护和修理）和报废指示的制定和管理(见考虑ISO26262-7：2018，第6和7条)。

5.2.2.3其他关键概念

a)认可措施

认可措施（见第6条）是为了判断相关项实现的功能安全，或对实现功能安全的贡献，例如。关于要素的开发。

b)可控性

在危险分析和风险评估(见ISO26262-3：2018，第6条)中，可以为驾驶员或其他风险人员的能力(例如：行人、骑自行车者、乘客、其他车辆的驾驶员)以避免特定的伤害，可能由外部措施支持。对危害分析和风险评估中的可控性以及功能和技术安全概念的假设进行了验证(见ISO26262-3：2018，第6和第7条以及ISO26262-4：2018，第8条)。

注意，暴露和严重程度取决于场景。通过人为干预的最终可控性受到相关项设计的影响，因此在安全确认期间进行评估(见ISO26262-4：2018，第8条)。

c)外部措施

外部措施是指相关项边界以外的措施(见ISO26262-3：2018，第5条)，以减少或减轻相关项故障行为造成的潜在危险。外部措施可以包括额外的车辆内设备，如动态稳定控制器或运行平坦的轮胎，但也可以包括车辆外部的设备，如防撞屏障或隧道消防系统。

对相关项定义、危害分析和风险评估以及功能和技术安全概念中关于外部措施的假设进行了验证(见ISO26262-4：2018，第8条)。

外部措施可在危害分析和风险评估中考虑(见ISO26262-3：2018，第6条)。然而，如果在危险分析和风险评估中从外部措施中获得信贷，例如。为了减少安全目标的ASIL，不能再将外部措施视为功能安全概念中的风险降低。

外部措施可以超出ISO26262系列标准的范围(例如：如果外部措施是通过另一种技术实现的，或者是在车辆外部实施的)，或者在ISO26262系列标准的范围内(例如：如果外部度量是由与相关项不同的E/E系统实现的)。

d)相关项层面的影响分析

在相关项层面进行影响分析（见6.4.3），以确定该相关项是新开发、现有相关项的修改还是具有修改环境的现有相关项。如果有一个或多个修改，则分析修改对功能安全的影响。

e)要素层面的影响分析

当复用现有要素时，在要素层面进行影响分析（见6.4.4），以评估复用要素是否能够遵守分配给该要素的安全要求，同时考虑到该要素被复用的运行环境。

f)其他技术

其他技术(例如：机械和液压技术)是与电气和电子技术不同的技术。这些可以在安全要求的规范和分配中考虑(见ISO26262-3：2018，第7条和ISO26262-4)，或作为外部措施。换句话说，由另一种技术实现的要素可以在相关项中实现，也可以指定为外部度量。

g)生产发布

用于生产的发布（见6.4.13）将用于生产的相关项或要素发布的决定正式化，考虑安全生命周期的结果，包括适用的认可措施的结果。