下文的表中，一些方法的推荐等级说明：
“++”表示对于指定的ASIL等级，高度推荐该方法；
“+” 表示对于指定的ASIL等级，推荐该方法；
“o” 表示对于指定的ASIL等级，不推荐该方法。

1 安全生命周期

安全生命周期包含了在概念阶段、产品开发、生产、运行、维护和报废期间的主要安全活动，而计划、协调和记录安全生命周期所有阶段的安全活动是关键的管理任务。允许根据实际项目需求对安全生命周期进行裁剪。
这里有个相关项（item）的概念，这里可以理解为一个功能单元，比如电驱系统。

功能安全管理分为几个阶段：概念阶段、产品开发阶段、生产发布之后的阶段。

1.1 概念阶段

在概念阶段，要完成这几件事：
（1）定义相关项item
安全生命周期的初始任务是对相关项(item)的功能、接口、环境条件、法规要求、已知危害等进行描述，以确定它的边界、接口，以及与其它相关项、要素、系统和部件相关的条件。
（2）安全生命周期启动
在完成相关项定义的基础上，通过确定所开发的相关项是一个全新的开发，还是对现有相关项的修改，来启动安全生命周期。
如果是对现有相关项的修改，可以根据（1）得到的影响分析的结果用于对安全生命周期进行裁剪。
（3）危害分析和风险评估（hazard analysis and risk assessment） – HaRa
在本阶段，进行以下操作。
首先，通过危害分析和风险评估来预测，与该相关项相关的危害事件所处工况的暴露概率、危害事件的可控性和严重度，这些参数共同决定了危害事件的汽车安全完整性等级。
然后，通过危害分析和风险评估来确定相关项的安全目标。安全目标（safety goal）是相关项的最高层面的安全要求，将所确定的危害事件（hazardous event）的ASIL等级分配给相应的安全目标。后续阶段和子阶段中详细的安全要求就是来自于安全目标，这些安全要求会继承相应安全目标的ASIL等级。
（4）功能安全概念（functional safety concept） – FSC
功能安全概念是通过分配给相关项（item）要素（element）的功能安全要求（functional safety requirement）来定义的。如果能够对涉及的其它技术或与外部措施接口的期望行为进行确认，功能安全概念可包括其它技术或与外部措施的接口

1.2 产品开发阶段

在产品开发阶段，要做这几件事：
（1）产品开发
（2）安全确认
（3）功能安全评估
（4）生产发布

产品开发包括系统/硬件/软件几个方面的开发，这几个方面的流程都要遵循V模型的概念。

1. 系统层面：
   系统开发流程的V模型，左侧包含技术安全要求的定义、系统架构、系统设计和实现，右侧包含集成、验证、确认和功能安全评估。 软硬件接口要在该阶段定义清楚，形成HSI文档。
   从系统层面来说，包括了对其它几个阶段发生活动的确认。
   (1) 确认功能安全概念FSC的技术实现。
   (2) 确认外部措施的有效性，以及能达到的性能。比如，附加的车载装置如动态稳定控制器或防爆轮胎，以及道路防护置如防撞栏或隧道消防系统等，不在本标准使用范围，因此可作为外部措施加以考虑。
   (3) 确认人员的反应，这里可以指驾驶员，包括可控性和操作任务。可控性指HaRa分析中，驾驶员或其他涉险人员控制危害情况能力的可信度。

2. 硬件层面：
   基于系统设计规范，从硬件层面进行开发。硬件开发流程基于一个V模型概念，V模型左侧包含硬件要求定义、硬件设计和实现，V模型右侧包含硬件集成和测试。

3. 软件层面：
   基于系统设计规范，从软件层面进行相关项的开发。软件开发流程基于一个V模型概念，V模型左侧包含软件要求定义、软件架构设计和实现，V模型右侧包含软件集成、测试和软件要求验证。

4. 生产发布：
   生产发布是产品开发流程的最后阶段，为量产发布提供必要交付物。

1.3 生产发布后续阶段

在生产发布之后的后续阶段，要做这几件事：
（1）生产活动
生产计划、运行计划，以及相关要求的定义，要在产品开发的系统层面启动。
（2）运行、维护、报废
与安全相关的特性，以及对相关项的维护、修理、报废的指导说明的开发和管理，用以确保相关项在生产发布后的功能安全。

2 安全管理的角色和职责

在相关项开发的启动阶段应指定一名项目经理，应赋予项目经理责任和权限，项目经理应确认组织提供了功能安全活动所需的资源
项目经理应确保已指定了安全经理。
在开发阶段，安全经理应负责计划和协调功能安全活动。包括将任务分配给具体人员，在其它交付物中进一步细化安全活动，以及按照相关项是否为一个全新开发或一个对既有相关项的修改，来为相应的安全活动制定计划。安全经理要负责维护安全计划，并监督安全活动的进度是否按照安全计划进行。
安全计划指集成和测试计划，包括：确认计划、软件验证计划、功能安全评估计划。各计划责任人应负责维护各自的安全计划，并监督安全活动的进度是否按照各自的安全计划进行。

3 安全活动的裁剪

如果对安全活动进行裁剪，那么应在安全计划中定义该裁剪，并且要给出理由，来说明为什么本次裁剪对于功能安全来说是恰当且充分的。
注1：裁剪理由应考虑ASIL等级。
注2：安全计划中要包含裁剪的理由，并且在认可评审或功能安全评估过程中对其进行评审。

独立于相关项的要素的开发应基于一个需求规范，该需求规范来自对预期用途和应用环境的假设，包括其外部接口，且应确认独立于相关项而开发的要素的预期用途和应用环境的假设的有效性。本标准不能应用于独立于相关项的要素开发，因为功能安全不是一个要素的属性（然而一个相关项中的某一个要素可以认为是与安全相关的）。功能安全是一个可以用功能安全评估方法来评价的相关项的属性。
比如：以电驱控制系统使用的微控制器MCU的开发为例。上面这段话翻译过来就是，针对该MCU这个要素的功能安全评估不在本次安全活动范围内，又因为MCU与安全相关，所以要由相应的供应商提供必要的认证或者证据。

4 安全活动的评审

当相关项安全目标的最高ASIL等级是ASIL（B）、C或D时，要求进行相关项的功能安全审核，应委派一名或多名人员开展一次或多次功能安全审核，所委派的人员应提供包含对功能安全所要求的过程实施情况的评估报告。
如果由SPICE（Software Process Improvement and Capability Determination软件过程改进和能力测试）评估人员开展功能安全审核，那么可以和功能安全审核同时开展。SPICE评估人员可以向功能安全审核人员提供反馈。但是，SPICE评估不足以对功能安全进行评估，仅能同步检查某些支持过程。
组织的流程定义可以同时符合多种标准，比如GB/T和SPICE的配置管理流程要求。这种流程的协调有助于避免重复工作，以及流程的不一致。对于协调后的流程，可提供组织对GB/T的要求和对SPICE的交叉引用的专门的流程。

5 安全活动的评估

功能安全评估范围应包括：安全计划要求的工作成果、功能安全要求的流程，以及流程的评估可基于功能安全审核的结果。对在相关项开发过程中已实施的且可评估的安全措施进行适宜性和有效性评审，对于在产品生产子阶段实施的但不能在相关项开发过程中进行评估的安全措施，可与生产过程能力结合在一起进行评估。

功能安全评估应考虑：
a) 其它认可措施的计划
b) 认可评审和功能安全审核的结果
c) 功能安全评估的建议

6 交付物

安全计划
项目计划（细化的）
功能安全评估计划
认可措施报告