道路车辆功能安全
第2 部分：功能安全管理
1 范围
GB/T 34590的本部分规定了应用于汽车领域的功能安全管理的要求，包括：
——独立于项目的关于所涉及组织的要求（整体安全管理）；及
——项目特定的在安全生命周期内关于管理活动的要求，例如在概念阶段、产品开发阶段（系统
层面、硬件层面、软件层面）以及生产、运行、服务和报废的管理。
本文件适用于安装在除轻便摩托车外的量产道路车辆上的包含一个或多个电气/电子系统的与安全
相关的系统。
本文件不适用于特殊用途车辆上特定的电气/电子系统，例如，为残疾驾驶者设计的车辆。
注：其他专用的安全标准可作为本文件的补充，反之亦然。
已经完成生产发布的系统及其组件或在本文件发布日期前正在开发的系统及其组件不适用于本文
件。对于在本文件发布前完成生产发布的系统及其组件进行变更时，本文件基于这些变更对安全生命周
期的活动进行剪裁。未按照本文件开发的系统与按照本文件开发的系统进行集成时，需要按照本文件进
行安全生命周期的剪裁。
本文件针对由安全相关的电气/电子系统的功能异常表现而引起的可能的危害，包括这些系统相互
作用而引起的可能的危害。本文件不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐
蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由安全相关的电气/电子系统的功能异常
表现表现而引起的。
本文件提出了安全相关的电气/电子系统进行功能安全开发的框架，该框架旨在将功能安全活动整
合到企业特定的开发框架中。本文件规定了为实现产品功能安全的技术开发要求，也规定了组织应具备
相应功能安全能力的开发流程要求。
本文件不针对电气/电子系统的标称性能。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，
仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本
文件。
GB/T 34590.1-XXXX 道路车辆功能安全第1部分：术语(ISO 26262-1:2018,MOD)
GB/T 34590.3-XXXX 道路车辆功能安全第3部分：概念阶段(ISO 26262-3:2018,MOD)
GB/T 34590.4-XXXX 道路车辆功能安全第4部分：产品开发：系统层面(ISO 26262-4:2018,MOD)
GB/T 34590.5-XXXX 道路车辆功能安全第5部分：产品开发：硬件层面(ISO 26262-5:2018,MOD)
GB/T 34590.6-XXXX 道路车辆功能安全第6部分：产品开发：软件层面(ISO 26262-6:2018,MOD)
GB/T 34590.7-XXXX 道路车辆功能安全第7部分：生产、运行、服务和报废(ISO 26262-7:2018,MOD)
GB/T 34590.8-XXXX 道路车辆功能安全第8部分：支持过程(ISO 26262-8:2018,MOD)
GB/T 34590.9-XXXX 道路车辆功能安全第9部分：以汽车安全完整性等级为导向和以安全为导向
的分析(ISO 26262-9:2018,MOD)

3 术语、定义和缩略语
GB/T 34590.1-XXXX界定的术语、定义和缩略语适用于本文件。
4 要求
目的
本章规定了：
a) 如何符合GB/T 34590-XXXX；
b) 如何解释GB/T 34590-XXXX 中所使用的表格；及
c) 如何解释各章条基于不同的ASIL 等级的适用性。
一般要求
如声明满足GB/T 34590-XXXX的要求时，应满足每一个要求，除非有下列情况之一：
a) 按照本文件的要求，安全活动的剪裁已经实施并表明这些要求不适用；或
b) 不满足要求的理由存在且是可接受的，并且按照本文件的要求对该理由进行了评估。
标有“注”或“示例”的信息仅用于辅助理解或阐明相关要求，不应作为要求本身且不具备完备性。
将安全活动的结果作为工作成果。应具备上一阶段工作成果作为“前提条件”的信息。如果章条的
某些要求是依照ASIL定义的或可剪裁的，某些工作成果可不作为前提条件。
“支持信息”是可供参考的信息，但在某些情况下，GB/T 34590不要求其作为上一阶段的工作成果，
并且可以是由不同于负责功能安全活动的人员或组织等外部资源提供的信息。
表的诠释
本文件中的表是规范性或资料性取决于上下文。在满足相关要求时，表中列出的不同方法有助于置
信度水平。表中的每个方法是：
a) 一个连续的条目（在最左侧列以顺序号标明，如1、2、3）；或
b) 一个选择的条目（在最左侧列以数字后加字母标明，如2a、2b、2c）。
对于连续的条目，高度推荐和推荐的方法按照ASIL等级推荐予以使用。高度推荐或推荐的方法允许
用未列入表中的其它方法替代,此种情况下，应给出满足相关要求的理由。如果可以给出不选择所有条
目也能符合相应要求的理由，则不需要对缺省方法做进一步解释。
对于选择性的条目，应按照指定的ASIL等级对这些方法进行适当的组合，而与这些方法在表中是否
列出无关。如果所列出的方法对于一个ASIL等级来说具有不同的推荐等级，宜采用具有较高推荐等级的
方法。应给出选择组合方法或选择单一方法满足相应要求的理由。
注：在表中所列出方法的理由是充分的。但是，这并不意味着有倾向性或对未列到表中的方法表示反对。
对于每种方法，应用相关方法的推荐等级取决于ASIL等级，分类如下：
——“++”表示对于指定的ASIL 等级，高度推荐该方法；
——“+”表示对于指定的ASIL 等级，推荐该方法；
——“o”表示对于指定的ASIL 等级，不推荐也不反对该方法。
基于ASIL 等级的要求和建议

若无其它说明，对于ASIL A、B、C和D等级，应满足每一章条的要求或建议。这些要求和建议参
照安全目标的ASIL等级。如果在项目开发的早期对ASIL等级完成了分解，按照GB/T 34590.9第5章的要
求，应遵循分解后的ASIL等级。
如果GB/T 34590中ASIL等级在括号中给出，则对于该ASIL等级，相应的章条应被认为是推荐而非要
求。这里的括号与ASIL等级分解无关。
摩托车的适用性
对于适用于GB/T 34590.12要求的摩托车的相关项或要素，GB/T 34590.12的要求替代本文件和GB/T
34590.2的相应要求。
卡车、客车、挂车和半挂车的适用性
对卡车、客车、挂车和半挂车的特殊规定以（T&B）来表示。
5 整体安全管理
目的
本章旨在确保参与安全生命周期执行的组织，即负责安全生命周期或在安全生命周期内执行安全活
动的组织，实现以下目标：
a) 建立并维护能够用于支持和鼓励功能安全有效实现，并能够促进与功能安全相关的其他领域
有效沟通的安全文化；
b) 建立并维护充分的组织的专门的功能安全规章和流程；
c) 建立并维护可确保能充分解决识别出的安全异常的流程；
建立并维护可确保参与人员的能力与其职责相匹配的能力管理体系；及
建立并维护用以支持功能安全的质量管理体系。
本章是GB/T 34590 安全生命周期内所有活动的前提条件。
总则
5.2.1 安全生命周期概述
GB/T 34590参考安全生命周期包含了在概念阶段、产品开发、生产、运行、服务和报废期间的主要
安全活动。计划、协调和监控安全活动的进度，以及确保认可措施得到执行，是关键的管理任务，并且
贯穿整个生命周期。安全生命周期可以被剪裁（本文件第6章）。
注1：GB/T 34590.3-XXXX、GB/T 34590.4-XXXX、GB/T 34590.5-XXXX、GB/T 34590.6-XXXX 和GB/T 34590.7-XXX
分别详细描述了在概念阶段、产品开发、生产、运行、服务和报废期间的安全活动。
注2：表A.1 概括了功能安全管理的目的、前提条件和工作成果。
图2说明了与安全生命周期相关的管理活动。
注3：在图中，GB/T 34590-XXXX 各部分中的具体条款用以下方式表示：“m-n”,其中m 代表部分的数值，n 代表章
的数值。例如：3-6 代表GB/T 34590.3-XXXX 的第6 章。
注4：1)系统层面产品开发的子阶段如GB/T 34590.4-XXXX 图2 所示。
注5：2)硬件层面产品开发的子阶段如GB/T 34590.5-XXXX 图2 所示。
注6：3)软件层面产品开发的子阶段如GB/T 34590.6-XXXX 图2 所示。

图2 与安全生命周期相关的管理活动
5.2.2 安全生命周期的解释说明
5.2.2.1 总则
GB/T 34590 不仅定义了针对安全生命周期内特定阶段和特定子阶段的要求，同时也定义了适用于
安全生命周期多个或全部阶段的要求，例如功能安全管理的要求。
关键的安全管理任务是计划、协调和追踪与功能安全相关的活动。这些管理任务适用于安全生命周
期的所有阶段。本文件给出了功能安全管理的要求，分别是：
——整体安全管理（本文件第5 章）；
——在概念阶段及在系统、硬件和软件层面产品开发阶段的项目相关的安全管理（本文件第6 章）；
及
——生产、运行、服务和报废的安全管理（本文件第7 章）。
开发相关的安全活动计划在概念阶段启动，并在产品开发阶段（系统、硬件和软件）中进行必需的
细化，直到决定对相关项或要素进行生产发布。与生产、运行、服务和报废相关的活动计划在系统层面
的产品开发期间启动。

第5.2.2.2条阐述了安全生命周期内不同阶段和子阶段的定义。第5.2.2.3条阐述了在安全生命周期
内需要考虑的其他关键概念。
5.2.2.2 安全生命周期的阶段和子阶段
a) 相关项定义（概念阶段的子阶段）：
安全生命周期的初始任务是对相关项的功能、接口、环境条件、法规要求、已知危害等进行
描述。确定相关项的边界及其接口，以及对其他相关项、要素或者外部措施的假设（见GB/T
34590.3-XXXX 第5 章）。
b) 危害分析和风险评估（概念阶段的子阶段）：
按照GB/T 34590.3-XXXX,第6 章的要求进行危害分析和风险评估。首先，通过危害分析和风
险评估预测与相关项相关的危害事件所处工况的暴露概率、危害事件的可控性和严重度。这
些参数共同决定了危害事件的ASIL 等级。然后通过危害分析和风险评估确定相关项的安全目
标，安全目标是相关项的最高层面的安全要求。将所确定的危害事件的ASIL 等级分配给相应
的安全目标。在危害分析和风险评估、功能安全概念和技术安全概念中，对人员行为的假设
（包括可控性和人员反应）以及与ASIL 分级相关的技术假设是经过确认的。（见GB/T
34590.3-XXXX 第6 章，GB/T 34590.3-XXXX 第7 章和GB/T 34590.4-XXXX 第8 章）。
后续阶段和子阶段中详细的安全要求来自安全目标。安全要求继承了相应安全目标的ASIL 等
级，或者在应用了ASIL 等级剪裁的要求进行分解的情况下，接受分解后的ASIL 等级。（见
GB/T 34590.9-XXXX 第5 章）。
c) 功能安全概念（概念阶段的子阶段）：
基于安全目标，同时考虑初步的构架设想以开发功能安全概念（见GB/T 34590.3-XXXX,第7
章）。功能安全概念是通过从安全目标中导出功能安全要求，并通过将这些功能安全要求分
配给相关项要素来开发的。功能安全概念还可以包括其他技术或依赖于外部措施（见GB/T
34590.3-XXXX,第7 章）。在这些情况下，对相应的假设或预期行为进行确认（见GB/T
34590.4-XXXX,第8 章）。其他技术的实施不在本文件系列范围内，且外部措施的实施不在相
关项开发范围内。
d) 产品开发：系统层面
在定义了功能安全概念后，应按照GB/T 34590.4-XXXX，从系统层面进行相关项的开发。系统
开发流程基于V 模型概念，V 模型左侧包含技术安全要求的定义、系统架构、系统设计和实现，
V 模型右侧包含集成、验证、安全确认。
在本阶段定义了软硬件接口。硬件和软件之间的接口在硬件和软件开发期间进行更新。
GB/T 34590.4-XXXX，图2 提供了系统开发子阶段的概览。
系统开发包括对发生在安全生命周期内其他阶段活动的安全确认任务，包括：
——与ASIL 等级分类相关的技术假设；
——对人员行为所做假设的确认，包括可控性和人员反应；
——对通过其他技术实现的功能安全概念的确认；及
——对外部措施有效性的假设的确认和对表现性能的假设的确认。
e) 产品开发:硬件层面
基于系统设计规范，开发硬件（见GB/T 34590.5-XXXX）。硬件开发流程基于V 模型概念，V
模型左侧包含硬件要求的定义、硬件设计和实现，V 模型右侧包含硬件集成和验证。
GB/T 34590.5-XXXX，图2 提供了硬件开发子阶段的概览。
f) 产品开发:软件层面
基于系统设计规范，开发软件（见GB/T 34590.6-XXXX）。软件开发流程基于V 模型概念，V
模型左侧包含软件要求的定义、软件架构设计和实现，V 模型右侧包含软件集成和验证。

GB/T 34590.6-XXXX，图2 提供了软件开发子阶段的概览。
g) 生产、运行、服务和报废
这一阶段的计划（见GB/T 34590.7-XXXX，第5 章），以及相关要求的规范，在系统层面的产
品开发过程中开始（见GB/T 34590.4-XXXX），并与系统、硬件和软件开发并行。这样的计划
可以通过交换信息或要求来实现，例如提高产品生产能力的安全相关的特殊特性或要求。
这一阶段描述了流程、方法和说明以确保相关项或要素的生产、运行、服务和报废中的功能
安全。安全相关的特殊特性，以及相关项或要素的生产、运行、服务（维护和维修）和报废
的指导说明的开发和管理是要被考虑的（见GB/T 34590.7-XXXX，第6 章和第7 章）。
5.2.2.3 其他关键概念
a) 认可措施
实施认可措施（本文件第6 章）以判断相关项实现了功能安全，或对实现功能安全的贡献，
例如关于要素的开发。
b) 可控性
在危害分析和风险评估（见GB/T 34590.3-XXXX，第6 章）中，驾驶员或其他涉险人员（例如，
行人、骑自行车者、乘客、其他车辆的驾驶员）避免特定伤害的能力的可信度，可能受到外
部措施的支持。需要确认在危害分析和风险评估、功能安全概念和技术安全概念中关于可控
性的假设（见GB/T 34590.3-XXXX，第6 章和第7 章，和GB/T 34590.4-XXXX，第8 章）。
注：暴露概率和严重度依赖于场景。通过人为干预的最终可控性受相关项设计的影响，因此，在安全确认过程中进
行评估（见GB/T 34590.4-XXXX，第8章）。
c) 外部措施
外部措施是指在相关项边界外（见GB/T 34590.3-XXXX，第5 章）减少或减轻相关项故障行为
造成的潜在危害的措施。外部措施可以包括额外的车载装置，如动态稳定控制器或防爆轮胎，
也可以包括车外装置，如防撞护栏或隧道消防系统。
需确认在相关项定义、危害分析和风险评估、功能安全概念和技术安全概念中关于外部措施
的假设（见GB/T 34590.4-XXXX，第8 章）。
可在危害分析和风险评估过程中考虑外部措施(见GB/T 34590.3-XXXX 中，第6 章),然而,如
果可信度来自危害分析和风险评估过程中的外部措施（如降低安全目标的ASIL 等级）,则在
功能安全概念中不能再次认为此外部措施是一个减少风险的途径。
外部措施可以在GB/T 34590 的范围之外（例如，外部措施是由另一技术实现或在车辆以外实
施），或在GBT 34590 的范围内（例如，如果外部措施由与相关项不同的电气/电子系统实现）。
d) 影响分析：相关项层面
在相关项层面执行影响分析（见6.4.3）以确定相关项是全新开发、或是对现有相关项的修改，
还是对现有相关项环境的修改，如果有一个或多个修改，则分析修改对功能安全的影响。
e) 影响分析：要素层面
当现有要素被复用（本文件6.4.4）时，在要素层面进行影响分析，以评估复用要素是否能够
符合分配给该要素的安全要求，分析时要考虑要素被复用时所在的运行环境。
f) 其他技术
其他技术（如机械和液压技术）不同于电子电气技术。这些技术可在安全要求的规范制定中
和分配中(见GB/T 34590.3-XXXX，第7 章和GB/T 34590.4-XXXX)被考虑，或作为外部措施被
考虑。换言之，由其他技术实现的要素可以在相关项内实施，或者可以定义为外部措施。
g) 生产发布
考虑安全生命周期的成果（包括适用的认可措施的成果），生产发布（本文件6.4.13）正式
决定将相关项或要素用于生产。

12
本章的输入
5.3.1 前提条件
无。
5.3.2 支持信息
可考虑如下信息：
符合质量管理标准的证据。
示例1：IATF 16949 与ISO 9001 中关于安全生命周期各个阶段的质量管理。
示例2：ISO/IEC 33000 标准系列，能力成熟度模型集成(CMMI®)或是汽车软件过程改进及能力评定(Automotive
SPICE®)1)标准系列中关于产品开发的部分。
要求和建议
5.4.1 总则
执行安全生命周期活动的组织应该满足第5.4.2～5.4.6条。
5.4.2 安全文化
5.4.2.1 组织应创造、培育并保持一种安全文化，以支持并鼓励有效地实现功能安全。
注：附件B提供了构建安全文化的更多细节。
5.4.2.2 组织应建立、执行并维护组织的专门的规章和流程，以实现且维护功能安全并符合GB/T 34590
的要求。
注：组织的专门的规章和流程可包括创建并维护通用的计划（例如：通用安全计划）或通用的流程描述。
5.4.2.3 组织应建立并维护功能安全、预期功能安全、信息安全及与实现功能安全相关的其他领域之
间的有效沟通渠道。
示例1：建立功能安全与预期功能安全之间的沟通渠道，以便于两者交互相关信息（例如，在产品开发过程中，功
能安全活动和预期功能安全活动是并行开展的，需要针对可能的相互影响进行评估）。
示例2：建立功能安全与信息安全之间的沟通渠道，以便于两者交互相关信息（例如，在识别到信息安全问题可能
违背安全目标或安全要求的情况下，或在信息安全要求可能与功能安全要求冲突的情况下）。
示例3：建立功能安全和非电气/电子系统相关安全（如机械安全）之间的沟通渠道。
示例4：建立功能安全和质量之间的沟通渠道。
注：关于功能安全与信息安全潜在交互的指导见附录E。
5.4.2.4 在安全生命周期执行期间,组织应执行要求的安全活动,包括文档的创建和管理(按照
GB/34590.8—XXXX，第10 章的说明)。
5.4.2.5 组织应为功能安全的实现提供所需的资源。
注：资源包括人力资源、工具、数据库、指南和工作说明。
5.4.2.6 基于以下几点，组织应建立、执行并维护持续改进的流程：

——从其他相关项安全生命周期的执行过程中学习经验，包括现场经验；及
——将获得的改进应用于后续相关项。
5.4.2.7 组织应确保给予负责实现或维护功能安全、执行或支持安全活动的人员以足够的权限来履行
他们的职责。
5.4.3 关于功能安全的安全异常管理
5.4.3.1 组织应建立、执行并维护流程，以确保将识别出的安全异常明确传达给负责在安全生命周期
内实现或维护功能安全的人员。
注：根据安全异常情况，责任人可包括客户安全经理、供应商安全经理、与相关项开发相关的安全经理，或在生产、
运行、服务和报废期间实现和维护功能安全的人员。
5.4.3.2 组织应建立、执行和维护安全异常解决流程，以确保及时、有效地分析、评估、解决和管理
已识别的安全异常，直至关闭。
注：安全异常的解决流程可包括根本原因分析，由该根本原因分析得出对以后的修正行动。
注：如果安全异常的解决导致变更，则按照GB/T 34590.8-XXXX中，第8章，将该变更纳入变更管理流程。
注：安全经理可以提名负责解决安全异常的人员。
注：安全异常解决流程可以整合进质量管理体系的异常解决流程中（见5.4.5）。
5.4.3.3 只有达成以下条件，安全异常才应认为被关闭：
a) 基于某一依据，实施了充分的安全措施以解决安全异常，且安全措施的有效性得到了验证；
或
注1：在设计变更解决了安全异常的情况下，按照ISO 26262-8：2018第8章进行的相应的影响分析可提供依据。
注2：安全异常可以通过其他技术实施的措施或外部措施（例如ISO 26262 范围之外的措施）解决。
b) 基于某一依据，将安全异常评估为不构成不合理风险并将其关闭。
注3：如果没有合理依据，则无法关闭安全异常。
5.4.3.4 应对5.4.3.3 规定的关闭安全异常的依据进行记录；并应进行评审。
示例：对关闭安全异常的依据的评审可以作为功能安全评估的一部分（见6.4.12）。
5.4.3.5 未完成关闭的安全异常应上报给负责功能安全的人员，比如将涉及产品开发的安全异常上报
给项目经理。
注：如果在开发过程中识别到安全异常，但未完成关闭，而此时进行功能安全评估，则负责功能安全评估的人员是
需被明确传达安全异常的人员之一。
5.4.4 能力管理
5.4.4.1 组织应确保执行安全生命周期活动的人员具有与其职责相匹配的技能水平、能力和资质。
注1：在开发过程中，达到足够的技能水平和能力的方法之一是考虑以下知识领域的培训和资质培养：
——常规的安全实践、概念和设计；
——GB/T 34590-XXXX 标准和其他适用的安全标准；
——用于功能安全组织的专门规则；
——用于与功能安全交互专业的组织的专门规则；及
——组织所建立的功能安全流程。