ChinaAutoRegs｜GB/T 34590.2-2022英文版翻译English 道路车辆 功能安全 第2部分：功能安全管理（英语版）
Road Vehicles—Functional Safety—Part 2: Management of Functional Safety
CONTENTS
Foreword
Introduction
1 Scope
2 Normative References
3 Terms and Definitions
4 Requirements
5 Overall safety management
6 Project dependent safety management
7 Safety management regarding production, operation, service and decommissioning
Annex A (Informative) Overview of and workflow of functional safety management
Annex B (Informative) Safety culture
Annex C (Informative) Guidance on potential interaction of functional safety with cybersecurity
Annex D (Informative) Guidance for the confirmation measures
Annex E (Informative) Example of a functional safety assessment agenda (for items that have an ASIL D safety goal)
Bibliography
1 范围
GB/T 34590的本部分规定了应用于汽车领域的功能安全管理的要求，包括：
——独立于项目的关于所涉及组织的要求（整体安全管理）；及
——项目特定的在安全生命周期内关于管理活动的要求，例如在概念阶段、产品开发阶段（系统 层面、硬件层面、软件层面）以及生产、运行、服务和报废的管理。
本文件适用于安装在除轻便摩托车外的量产道路车辆上的包含一个或多个电气/电子系统的与安全 相关的系统。
本文件不适用于特殊用途车辆上特定的电气/电子系统，例如，为残疾驾驶者设计的车辆。 注：其他专用的安全标准可作为本文件的补充，反之亦然。 已经完成生产发布的系统及其组件或在本文件发布日期前正在开发的系统及其组件不适用于本文
件。对于在本文件发布前完成生产发布的系统及其组件进行变更时，本文件基于这些变更对安全生命周 期的活动进行剪裁。未按照本文件开发的系统与按照本文件开发的系统进行集成时，需要按照本文件进 行安全生命周期的剪裁。
本文件针对由安全相关的电气/电子系统的功能异常表现而引起的可能的危害，包括这些系统相互 作用而引起的可能的危害。本文件不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐 蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由安全相关的电气/电子系统的功能异常 表现表现而引起的。
本文件提出了安全相关的电气/电子系统进行功能安全开发的框架，该框架旨在将功能安全活动整 合到企业特定的开发框架中。本文件规定了为实现产品功能安全的技术开发要求，也规定了组织应具备 相应功能安全能力的开发流程要求。
本文件不针对电气/电子系统的标称性能。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， 仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 文件。
GB/T 34590.1 道路车辆 功能安全 第1部分：术语(ISO 26262-1:2018,MOD)
GB/T 34590.3 道路车辆 功能安全 第3部分：概念阶段(ISO 26262-3:2018,MOD)
GB/T 34590.4 道路车辆 功能安全 第4部分：产品开发：系统层面(ISO 26262-4:2018,MOD) GB/T 34590.5 道路车辆 功能安全 第5部分：产品开发：硬件层面(ISO 26262-5:2018,MOD) GB/T 34590.6 道路车辆 功能安全 第6部分：产品开发：软件层面(ISO 26262-6:2018,MOD) GB/T 34590.7 道路车辆 功能安全 第7部分：生产、运行、服务和报废(ISO 26262-7:2018,MOD) GB/T 34590.8 道路车辆 功能安全 第8部分：支持过程(ISO 26262-8:2018,MOD)
GB/T 34590.9 道路车辆 功能安全 第9部分：以汽车安全完整性等级为导向和以安全为导向 的分析(ISO 26262-9:2018,MOD)
3 术语、定义和缩略语
GB/T 34590.1界定的术语、定义和缩略语适用于本文件。
4 要求
目的
本章规定了：
a) 如何符合 GB/T 34590；
b) 如何解释 GB/T 34590 中所使用的表格；及
c) 如何解释各章条基于不同的 ASIL 等级的适用性。
一般要求
如声明满足GB/T 34590的要求时，应满足每一个要求，除非有下列情况之一：
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、GB/T 34590.4、GB/T 34590.5、GB/T 34590.6 和 GB/T 34590.7-XXX
分别详细描述了在概念阶段、产品开发、生产、运行、服务和报废期间的安全活动。 注 2：表 A.1 概括了功能安全管理的目的、前提条件和工作成果。 图2说明了与安全生命周期相关的管理活动。
注 3：在图中，GB/T 34590 各部分中的具体条款用以下方式表示：“m-n”,其中 m 代表部分的数值，n 代表章 的数值。例如：3-6 代表 GB/T 34590.3 的第 6 章。
注 4：1)系统层面产品开发的子阶段如 GB/T 34590.4 图 2 所示。 注 5：2)硬件层面产品开发的子阶段如 GB/T 34590.5 图 2 所示。 注 6：3)软件层面产品开发的子阶段如 GB/T 34590.6 图 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 第 5 章）。
b) 危害分析和风险评估（概念阶段的子阶段）：
按照 GB/T 34590.3,第 6 章的要求进行危害分析和风险评估。首先，通过危害分析和风 险评估预测与相关项相关的危害事件所处工况的暴露概率、危害事件的可控性和严重度。这 些参数共同决定了危害事件的 ASIL 等级。然后通过危害分析和风险评估确定相关项的安全目 标，安全目标是相关项的最高层面的安全要求。将所确定的危害事件的 ASIL 等级分配给相应 的安全目标。在危害分析和风险评估、功能安全概念和技术安全概念中，对人员行为的假设
（ 包括可控性和人员反应） 以及与 ASIL 分级相关的技术假设是经过确认的。（ 见 GB/T 34590.3 第 6 章，GB/T 34590.3 第 7 章和 GB/T 34590.4 第 8 章）。
后续阶段和子阶段中详细的安全要求来自安全目标。安全要求继承了相应安全目标的 ASIL 等 级，或者在应用了 ASIL 等级剪裁的要求进行分解的情况下，接受分解后的 ASIL 等级。（见 GB/T 34590.9 第 5 章）。
c) 功能安全概念（概念阶段的子阶段）： 基于安全目标，同时考虑初步的构架设想以开发功能安全概念（见 GB/T 34590.3,第 7 章）。功能安全概念是通过从安全目标中导出功能安全要求，并通过将这些功能安全要求分 配给相关项要素来开发的。功能安全概念还可以包括其他技术或依赖于外部措施（见 GB/T 34590.3, 第 7 章）。 在这些情况下， 对相应的假设或预期行为进行确认（ 见 GB/T
34590.4,第 8 章）。其他技术的实施不在本文件系列范围内，且外部措施的实施不在相 关项开发范围内。
d) 产品开发：系统层面
在定义了功能安全概念后，应按照 GB/T 34590.4，从系统层面进行相关项的开发。系统 开发流程基于 V 模型概念，V 模型左侧包含技术安全要求的定义、系统架构、系统设计和实现， V 模型右侧包含集成、验证、安全确认。 在本阶段定义了软硬件接口。硬件和软件之间的接口在硬件和软件开发期间进行更新。
GB/T 34590.4，图 2 提供了系统开发子阶段的概览。 系统开发包括对发生在安全生命周期内其他阶段活动的安全确认任务，包括：
——与 ASIL 等级分类相关的技术假设；
——对人员行为所做假设的确认，包括可控性和人员反应；
——对通过其他技术实现的功能安全概念的确认；及
——对外部措施有效性的假设的确认和对表现性能的假设的确认。 e) 产品开发:硬件层面
基于系统设计规范，开发硬件（见 GB/T 34590.5）。硬件开发流程基于 V 模型概念，V 模型左侧包含硬件要求的定义、硬件设计和实现，V 模型右侧包含硬件集成和验证。
GB/T 34590.5，图 2 提供了硬件开发子阶段的概览。 f) 产品开发:软件层面
基于系统设计规范，开发软件（见 GB/T 34590.6）。软件开发流程基于 V 模型概念，V 模型左侧包含软件要求的定义、软件架构设计和实现，V 模型右侧包含软件集成和验证。
GB/T 34590.6，图 2 提供了软件开发子阶段的概览。 g) 生产、运行、服务和报废
这一阶段的计划（见 GB/T 34590.7，第 5 章），以及相关要求的规范，在系统层面的产 品开发过程中开始（见 GB/T 34590.4），并与系统、硬件和软件开发并行。这样的计划 可以通过交换信息或要求来实现，例如提高产品生产能力的安全相关的特殊特性或要求。 这一阶段描述了流程、方法和说明以确保相关项或要素的生产、运行、服务和报废中的功能 安全。安全相关的特殊特性，以及相关项或要素的生产、运行、服务（维护和维修）和报废 的指导说明的开发和管理是要被考虑的（见 GB/T 34590.7，第 6 章和第 7 章）。
5.2.2.3 其他关键概念
a) 认可措施
实施认可措施（本文件第 6 章）以判断相关项实现了功能安全，或对实现功能安全的贡献， 例如关于要素的开发。
b) 可控性
在危害分析和风险评估（见 GB/T 34590.3，第 6 章）中，驾驶员或其他涉险人员（例如， 行人、骑自行车者、乘客、其他车辆的驾驶员）避免特定伤害的能力的可信度，可能受到外 部措施的支持。需要确认在危害分析和风险评估、功能安全概念和技术安全概念中关于可控 性的假设（见 GB/T 34590.3，第 6 章和第 7 章，和 GB/T 34590.4，第 8 章）。
注：暴露概率和严重度依赖于场景。通过人为干预的最终可控性受相关项设计的影响，因此，在安全确认过程中进 行评估（见GB/T 34590.4，第8章）。
c) 外部措施
外部措施是指在相关项边界外（见 GB/T 34590.3，第 5 章）减少或减轻相关项故障行为 造成的潜在危害的措施。外部措施可以包括额外的车载装置，如动态稳定控制器或防爆轮胎， 也可以包括车外装置，如防撞护栏或隧道消防系统。 需确认在相关项定义、危害分析和风险评估、功能安全概念和技术安全概念中关于外部措施 的假设（见 GB/T 34590.4，第 8 章）。
可在危害分析和风险评估过程中考虑外部措施 (见 GB/T 34590.3 中，第 6 章),然而,如 果可信度来自危害分析和风险评估过程中的外部措施（如降低安全目标的 ASIL 等级）,则在 功能安全概念中不能再次认为此外部措施是一个减少风险的途径。
外部措施可以在 GB/T 34590 的范围之外（例如，外部措施是由另一技术实现或在车辆以外实 施），或在 GBT 34590 的范围内（例如，如果外部措施由与相关项不同的电气/电子系统实现）。
d) 影响分析：相关项层面
在相关项层面执行影响分析（见 6.4.3）以确定相关项是全新开发、或是对现有相关项的修改， 还是对现有相关项环境的修改，如果有一个或多个修改，则分析修改对功能安全的影响。
e) 影响分析：要素层面
当现有要素被复用（本文件 6.4.4）时，在要素层面进行影响分析，以评估复用要素是否能够 符合分配给该要素的安全要求，分析时要考虑要素被复用时所在的运行环境。
f) 其他技术
其他技术（如机械和液压技术）不同于电子电气技术。这些技术可在安全要求的规范制定中 和分配中(见 GB/T 34590.3，第 7 章和 GB/T 34590.4)被考虑，或作为外部措施被 考虑。换言之，由其他技术实现的要素可以在相关项内实施，或者可以定义为外部措施。
g) 生产发布
考虑安全生命周期的成果（包括适用的认可措施的成果），生产发布（本文件 6.4.13）正式 决定将相关项或要素用于生产。
本章的输入
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 基于以下几点，组织应建立、执行并维护持续改进的流程：
1) CMMI®和 Automotive SPICE®是适用的商业产品示例。这些信息是为了方便本文件的用户而提供的，并不代表本文件对这些产品的推荐。
——从其他相关项安全生命周期的执行过程中学习经验，包括现场经验；及
——将获得的改进应用于后续相关项。
5.4.2.7 组织应确保给予负责实现或维护功能安全、执行或支持安全活动的人员以足够的权限来履行 他们的职责。
5.4.3 关于功能安全的安全异常管理
5.4.3.1 组织应建立、执行并维护流程，以确保将识别出的安全异常明确传达给负责在安全生命周期 内实现或维护功能安全的人员。
注：根据安全异常情况，责任人可包括客户安全经理、供应商安全经理、与相关项开发相关的安全经理，或在生产、 运行、服务和报废期间实现和维护功能安全的人员。
5.4.3.2 组织应建立、执行和维护安全异常解决流程，以确保及时、有效地分析、评估、解决和管理 已识别的安全异常，直至关闭。
注：安全异常的解决流程可包括根本原因分析，由该根本原因分析得出对以后的修正行动。 注：如果安全异常的解决导致变更，则按照GB/T 34590.8中，第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 标准和其他适用的安全标准；
——用于功能安全组织的专门规则；
——用于与功能安全交互专业的组织的专门规则；及
——组织所建立的功能安全流程。
注 2：为了评估执行满足 GB/T 34590 的活动所需的技能、能力和资质，可以考量以往的专业活动经验，如：
——相关项专业领域的知识；
——相关项环境方面的专业知识；
——管理经验；及
——生产、运行、服务和报废方面的专业知识。
注 3：组织可以定义技能、能力和资质的充分性的标准。 示例：英国健康与安全执行局在“安全相关系统管理能力”中给出的准则。
5.4.5 质量管理体系
5.4.5.1 组织应具有支持实现功能安全并满足质量管理标准如 IATF 16949，ISO 9001 或等同标准的质 量管理体系。
5.4.6 独立于项目的安全生命周期剪裁
5.4.6.1 组织可剪裁安全生命周期，应用于各相关项或要素，即独立于项目的剪裁，仅限于以下情况 ：
a) 合并或分解子阶段、活动或任务；
注：如果所用的方法难以清晰地区分单独的子阶段，那么这些子阶段可以合并。例如，计算机辅助开发工具能在一 个步骤中支持多个子阶段的活动。
b) 在不同的阶段或子阶段中执行同一活动或任务； c) 在新增的阶段或子阶段中执行同一活动或任务； d) 反复进行某个阶段或子阶段；
e) 若符合 6.4.7.1，执行与其他阶段或子阶段的安全活动同时进行的安全活动；或
f) 根据某个理由，省略不适用于组织的阶段或子阶段。
工作成果
5.5.1 组织的专门的功能安全规章和流程，由 5.4.2 到 5.4.6 得出。
5.5.2 能力管理证据，由 5.4.4 得出。
5.5.3 质量管理体系证据，由 5.4.5 和 5.4.6 得出。
5.5.4 已识别的安全异常报告（如果适用），由 5.4.3 得出。
6 项目相关的安全管理
目的
本章的目的是，确保参与概念阶段或系统、硬件、软件层面开发阶段的组织实现以下目标：
a) 定义与分配安全活动相关的角色和责任；
b) 在相关项层面执行影响分析，以识别相关项是全新的，或是对现有相关项修改，还是对现有相 关项的使用环境进行修改；并在有一项或多项修改时，分析所识别出的修改对功能安全的影响；
c) 在现有要素复用的情况下，在要素层面执行影响分析，评估复用的要素是否可以满足分配给它 的安全要求，并考虑该要素复用的运行环境；
注：在相关项或要素层面的影响分析能支持安全活动的计划（见6.4.6.7）。
d) 定义所剪裁的安全活动，提供相应的剪裁理由，并评审所提供的理由；
e) 计划安全活动；
f) 按照安全计划协调并追踪安全活动的进度；
g) 规划分布式开发(见 GB/T 34590.8，第 5 章)；
h) 在整个安全生命周期内，确保安全活动的正确进程；
i) 创建可理解的安全档案，以提供实现了功能安全的证据；
j) 判断相关项是否实现了功能安全（即功能安全评估），或者判断某一要素（即供应商进行的功 能安全评估活动）或工作成果（例如认可评审）对于实现功能安全的贡献；及
k) 在开发结束时，基于支持有信心实现功能安全的证据，决定相关项或要素是否能够生产发布。
总则
在项目中，定义和分配与安全活动相关的角色和职责。 在相关项层面进行影响分析，以识别相关项是全新的，或是对现有相关项修改，还是对现有相关项
的使用环境进行修改；并在有一项或多项修改时，分析所识别出的修改对功能安全的影响。 在现有要素复用的情况下，在要素层面进行影响分析，并考虑该要素复用的运行环境。 安全管理包括计划和协调安全活动、根据相应的计划跟踪活动进度的责任，以及对被剪裁的安全活
动进行描述和理由说明的责任。 将安全计划文档化，并参考开发接口协议（见GB/34590.8—XXXX，第5章），该协议定义了在分布
式开发中与其他方的安全计划的接口。 安全管理也有责任确保执行认可措施。根据适用的ASIL等级，认可措施的执行要求在资源、管理和
发布权限上的充分独立性。 认可措施包括认可评审、功能安全审核和功能安全评估：
——认可评审的目的是评判关键工作成果（见表 1）是否提供了充分和令人信服的证据，证明其对 实现功能安全的贡献；
——如果适用，功能安全审核的目的是评估安全活动所要求的流程的执行情况；
——如果适用，功能安全评估的目的是判断相关项是否实现了功能安全，或判断对功能安全实现 的贡献（例如要素的开发）。
表1列出了认可措施。
除了认可措施外，还需进行验证活动。按照GB/T 34590其他部分的要求，这些验证活动用于 验证相关工作成果是否满足项目要求以及技术要求，尤其是与应用案例和失效模式相关的技术要求。
最后，相关项或相关项中各要素的发布责任人，基于支持有信心实现功能安全的证据，判断相关项 或要素是否已做好了批量生产和运行的准备。
本章的输入
6.3.1 前提条件
应具备如下信息： 组织的专门的功能安全规章和流程，按照5.5.1； 能力管理证据，按照5.5.2；及 质量管理体系证据，按照5.5.3。
6.3.2 支持信息
如果有，可以考虑如下信息：
——项目计划 (来自外部)；
——其他活动，包括其他安全活动；及
——其他用于进行影响分析的现有信息（见 6.4.3 和 6.4.4）。
示例：产品概念、修改请求、实施计划或在用证明。
要求和建议
6.4.1 总则
第6.4.2～6.4.13条适用于参与相关项或相关项的一个或多个要素的概念阶段或产品开发阶段（系 统、硬件或软件）的组织。
示例：供应商开发了一个要由客户集成的要素（见 GB/T 34590.8:XXXX，第 5 章），该要素根据 4.4 的要求，实施 一个或多个 ASIL 等级为 A、B、C 或 D 的安全要求。
6.4.2 安全管理的角色和职责
6.4.2.1 在相关项产品开发的启动阶段应指定一名项目经理。
注：在分布式开发的情况下（见GB/T 34590.8:XXXX，第5章），客户和开发一个或多个将被集成的要素的供应商， 均需任命项目经理。
6.4.2.2 应按照 5.4.2.7 的要求赋予项目经理责任和权限，以确保： a) 执行实现功能安全所需的安全活动；及
b) 满足 GB/T 34590 的要求。
6.4.2.3 项目经理应确认组织提供了符合 5.4.2.5 要求的功能安全活动所需的资源。
注：在计划阶段预估、确定并分配足够的资源。
6.4.2.4 项目经理应确保已指定了符合 5.4.4 要求的安全经理。
注1：安全经理的角色可以由项目经理承担。
注2：因术语“安全经理”被定义为角色（见GB/T 34590.1），其任务可以根据组织的形式分配给不同的人。
注3：在分布式开发的情况下（见GB/T 34590.8，第5章），在客户处和开发一个或多个要集成的要素的供应 商处任命安全经理。
6.4.3 相关项层面的影响分析
6.4.3.1 在安全生命周期开始时，应进行相关项层面的影响分析，以确定相关项是全新开发，或是对 现有相关项修改，还是对现有相关项的使用环境进行修改。
注：在用证在用证明可适用于修改的情况（见GB/T 34590.8，第14章）。
6.4.3.2 在对相关项或其环境修改的情况下，按照 6.4.3.1 执行的相关项层面的影响分析应识别并描 述应用于相关项的修改，包括：
注 1：本章考虑的影响分析关注计划阶段相关项的修改。在开发执行过程中的设计修改是通过变更管理流程实现的 (见 GB/T 34590.8，第 8 章)。
a) 设计的修改；
注 2：设计的修改可来自需求的修改。
注 3：设计的修改可以影响相关项的行为。 示例 1：设计的修改可来自标定数据的修改。
示例 2：设计的修改可来自相关项运行模式的更改。
a) 实现方式的修改；及
注 4：实现方式的修改不影响相关项的规格或性能。
注 5：对于相关项实现方式的修改，可能会影响相关项的行为。 注 6：实现方式的修改可来自软件的修正。
b) 与环境相关的修改。
示例 3：温度、海拔、湿度、振动、电磁干扰（EMI）和燃料类型。 注 7：修改包括：
——将相关项安装于新的目标环境（如车辆变型）；
——运行场景的变更；及
——-相关项在车内的不同位置。
6.4.3.3 按照 6.4.3.2，相关项层面的影响分析应： a) 评估修改对功能安全的影响；及
b) 基于修改的影响，识别并描述要开展的安全活动。
6.4.4 现有要素的复用
在复用现有要素的情况下，应执行要素层面的影响分析，包括： a) 识别运行环境的修改，包括其导致的对要素的修改；
b) 无论复用的要素是否进行修改，都需要评估其能否符合分配给其的安全要求，这些安全要求 来自集成该要素的相关项或要素；
注1：无论是否计划对现有要素进行修改，它都可以被复用。例如，可以计划对要素进行修改，以实现现有要素的 集成。
c) 基于修改影响（包括先前假设有效性的影响）进行评估，识别要执行的安全活动; 及
d) 评估与复用要素有关的现有安全相关文档，并判断其是否支持将要素集成到相关项，或将要 素集成到另一个要素。
注2：本章中考虑的影响分析涉及在计划阶段考虑的要素运行环境的修改。开发过程中考虑的设计修改通过变更管 理流程执行。（见GB/T 34590.8，第8章）。
注3：现有要素的复用需：
a) 基于硬件要素的评估（见 GB/T 34590.8，第 13 章）； b) 基于软件组件的鉴定（见 GB/T 34590.8，第 12 章）； c) 基于在用证明（见 GB/T 34590.8，第 14 章）；或
d) 作为独立于环境的安全要素（见 GB/T 34590.10）。
6.4.5 安全活动的剪裁
6.4.5.1 可以对特定相关项开发的安全活动进行剪裁，即省略或以不同于 GB/T 34590 所参考的生命周 期中规定的方式执行。如果安全活动被剪裁，那么
a) 应在安全计划中定义该剪裁（见 6.4.6.5，b）；及
b) 应给出理由说明为什么剪裁对于实现功能安全来说是恰当且充分的。
注 1：该理由应考虑相关要求的 ASIL 等级。
注 2：剪裁的理由包含在安全计划中且在安全计划的认可评审（见 6.4.9）或功能安全评估（见 6.4.12）过程中进 行评审。
注 3：本要求适用于特定相关项的安全活动的剪裁。关于组织层面相关项开发的安全生命周期的剪裁，仅 5.4.6 适 用。
6.4.5.2 如果是按照影响分析结果（按照 6.4.3 或 6.4.4）对某一安全活动按照 6.4.5.1 进行剪裁，
则应满足 6.4.6.7 的要求。
6.4.5.3 如果由于在用证明结果而按照 6.4.5.1 对某一安全活动进行剪裁， 则剪裁应满足 GB/T
34590.8，第 14 章的要求。
6.4.5.4 如果由于硬件要素评估而按照 6.4.5.1 对某一安全活动进行剪裁， 则剪裁应满足 GB/T
34590.8，第 13 章的要求。
6.4.5.5 如果是由于软件组件鉴定而按照 6.4.5.1 对某一安全活动进行剪裁，则剪裁应满足 GB/T
34590.8，第 12 章的要求。
6.4.5.6 如果基于考虑所使用软件工具的置信度的依据而按照 6.4.5.1 对某一安全活动进行剪裁，则 应满足 GB/T 34590.8，第 11 章的要求。
6.4.5.7 如果由于要素被开发为独立于环境的安全要素（“SEooC”）而按照 6.4.5.1 对某一安全活动 进行剪裁，那么
a) 独立于环境的安全要素的开发应基于一个需求规范，该需求规范来自对预期用途和环境的假设， 包括其外部接口；及
b) 当安全要素被集成到其目标应用中时，应验证对独立于环境的安全要素的预期用途和应用环境 的假设。
注 1：本文件作为一个整体不能应用于独立于环境的安全要素的开发，因为功能安全不是一个要素属性（然而一个
相关项中的某一个要素可以认为是与安全相关的）。功能安全是一个可以通过功能安全评估方法来评价的相 关项的属性。
示例：微控制器作为独立于环境的安全要素开发。
注 2：了解更多独立于环境的安全要素的开发见 GB/T 34590.10。
6.4.5.8 本要求适用于 T&B 的相关项的开发：如果某个应用超出了 GB/T 34590 的范围，且该应用正在 与已根据这些标准开发的基础车辆或相关项进行对接, 则应按照 GB/T 34590.8，第 15 章的要求 对相应的安全活动进行剪裁。
6.4.5.9 本要求适用于 T&B 的相关项的开发：如果开展安全活动，以确保未按照 GB/T 34590 开发的系 统或组件，满足集成到按照这些标准开发的相关项中所需的功能安全水平，则应按照 GB/T 34590.8， 第 16 章的要求对这类安全活动进行剪裁。
6.4.6 安全活动的计划和协调
6.4.6.1 按照 5.4.2.7 的要求，安全经理应负责计划和协调组织所参与的功能安全活动。
注 1：安全经理可将任务分配给具有所需技术、能力和资质的人员 （见 5.4.4)。
注 2：根据相关项是全新开发、对现有相关项的修改或是对现有相关项环境的修改（见 6.4.3），又或者要素是全 新的还是复用的（见 6.4.4），安全活动范围可以不同，并据此计划相应的安全活动。
6.4.6.2 安全经理应负责维护安全计划并监控安全活动的进度是否按照安全计划进行。
6.4.6.3 在组织内部应按照 5.4.2.7 和 5.4.4 的要求,分配并沟通关于执行安全活动的责任。
注：安全经理负责计划和协调安全活动。其他人员可以负责细化计划（见6.4.6.8）或执行安全活动（例如，计划 或执行集成和验证活动以及配置管理）。
6.4.6.4 安全计划应：
a) 在项目计划中被引用；或
b) 包含在项目计划中，并使安全活动是可区分的。
注：在配置管理下，安全计划可交叉引用其他信息（见GB/T 34590.8，第7章）。交叉引用通常优于在不同工 作成果或在配置管理下的其他文档里对活动的重复描述。
6.4.6.5 安全计划应规定实现功能安全的活动计划和流程计划，包括：
a) 将独立于项目的安全活动应用到项目特定的安全管理中，按照第 5 章； b) 如果适用，所剪裁的安全活动的定义，按照 6.4.5；
注 1：例如，依据相关项层面（见 6.4.3）或要素层面（见 6.4.4）的影响分析结果进行剪裁。另参考 6.4.6.7。
c) 安全活动的计划需要满足 GB/T 34590.3，GB/T 34590.4，GB/T 34590.5，GB/T 34590.6 的要求；
d) 按照 GB/T 34590.8，在适用的情况下，支持过程的计划，包括按照 GB/T 34590.8， 第 5 章，对定义与分布式开发中其他方的安全计划接口的开发接口协议（“DIA”）的引用；
e) 集成和验证活动计划，按照 GB/T 34590.3、GB/T 34590.4、GB/T 34590.5、
GB/T 34590.6 和 GB/T 34590.8，第 9 章；安全确认活动计划，按照 GB/T 34590.4， 第 8 章；
注 2：作为工作成果，安全计划包括详细的集成，验证和安全确认计划，然而这些计划也可包含在其他文档中（见 GB/T 34590.8，第 10 章）。
f) 按照第 6.4.9～6.4.12 条的认可评审、功能安全审核和功能安全评估的日程安排；
注 3：6.4.9 给出的执行认可措施的人员的独立性水平在安全计划中定义。
注 4：安全经理负责认可措施的日程安排。详细的认可措施计划由相应认可措施的负责人制定。
g) 相关失效分析的计划， 如果适用， 按照 GB/T 34590.3， GB/T 34590.4， GB/T 34590.5，GB/T 34590.6，GB/T 34590.9，第 7 章，GB/T 34590.9，第
8 章；
注 5：安全分析的目标和范围是在其计划中定义的，且取决于相应的子阶段和应用环境。
h) 如果适用，提供候选项的在用证明，按照 GB/T 34590.8，第 14 章；及 i) 如果适用，提供软件工具置信度，按照 GB/T 34590.8，第 11 章。
6.4.6.6 安全活动的计划应包括： a) 目标；
b) 对其他活动或信息的依赖性；
c) 负责执行活动的人员；
d) 执行活动所需的资源；
e) 起始时间、结束时间和持续时间；及 f) 相应工作成果的识别。
6.4.6.7 当修改相关项和现有相关项环境时，按照 6.4.3，或当复用要素时，按照 6.4.4：
a) GB/T 34590 标准的参考安全生命周期应根据相应影响分析的结果进行剪裁；
注 1：在安全计划中定义了剪裁后的安全活动，该过程考虑了适用的生命周期阶段和子阶段（见 6.4.5）。
b) 应相应地识别、描述和返工需要创建或更新的受影响的工作成果；及
注 2：受影响的工作成果包括安全确认规范（见 GB/T 34590.4，第 8 章）。
c) 如果安全文档不符合 GB/T 34590 ，则应确定必要的活动以符合标准中的相应要求。 示例 1：按照不同于 GB/T 34590 的安全标准开发的要素，相应的安全文档不完全符合 GB/T 34590。 示例 2：缺少安全文档或安全文档不完全符合 GB/T 34590 的现有要素。
6.4.6.8 安全计划应逐步更新，至少在每个阶段开始时更新。
注：至少在每个阶段的开始，安全计划都需更新，目的是细化该阶段的安全活动计划。安全计划可以在子阶段中进 一步细化。
6.4.6.9 安全计划要求的工作成果应在开发阶段保持最新状态，目的是在生产发布前和发布时保持对 相关项或要素具有足够的代表性。
6.4.6.10 如果是分布式开发，则客户和供应商均应针对各自的安全活动制定安全计划。
注：定义相应的开发接口协议，按照GB/T 34590.2，第5章。
6.4.7 安全生命周期进程
6.4.7.1 如果缺乏来自相关先前子阶段的信息，只有在即使缺乏信息也不会导致功能安全方面的不合 理风险的情况下，才能开始后续子阶段。
注：对于缺乏信息可能危及项目的情况，需进行问题升级。
6.4.7.2 按照 GB/T 34590.8，第 7、8 和 10 章的要求，每一项安全计划所要求的工作成果应分 别服从配置管理、变更管理以及文档管理，且纳入管理的时间不迟于“产品开发:系统层面”阶段的启 动时间（见 GB/T 34590.4）。
6.4.8 安全档案
6.4.8.1 应按照安全计划建立安全档案，为实现功能安全提供论据。
6.4.8.2 安全档案宜逐步收录安全生命周期内的工作成果，以支持安全论证。
注 1：在分布式开发的情况下，相关项的安全档案可以是客户和供应商的安全档案的结合，这些档案参考了相关方 生成的工作成果的证据。然后相关项的整体论据由各方的论据支持。客户和供应商之间的接口在开发接口协 议中定义（见 GB/T 34590.8，第 5 章）。
注 2：按照 6.4.6，为了支持安全计划，可在工作成果可用之前确定预期的安全论证。为了支持按照 6.4.12.3 进行 的逐步的功能安全评估，随着工作成果的产生，安全档案可以逐步发布，为安全论证提供证据。
6.4.9 认可措施
6.4.9.1 相关项及其要素的功能安全应被认可，基于：
a) 按照表 1 和 6.4.10 的要求，认可评审判断关键工作成果，即表 1 所列工作成果，能否提供充 足并令人信服的证据，证明其对实现功能安全的贡献，此过程应考虑 GB/T 34590 相应的目标 和要求。
注 1：对表 1 中规定的和安全计划中要求的工作成果进行认可评审。
b) 按照表 1 和 6.4.11，功能安全审核判断功能安全所需的流程的实施情况；及
注 2：GB/T 34590 中定义了功能安全所需的参考流程。与相关项或要素有关的流程通过安全计划中引用或规定的活 动来定义。
c) 按照表 1 和 6.4.12，功能安全评估判断相关项实现的功能安全，或所开发的要素对实现功能
安全的贡献。
注 3：表 1 中定义的独立性的目的是确保客观、公正的观点，避免利益冲突。本文中所用的“独立性”一词指的是组 织独立性。
注 4：认可措施指南见附录 C。
注 5：认可措施的结果报告包括所分析的工作成果或流程文档的名称和版本号（见 GB/T 34590.8，第 10 章）。
注 6：如果在认可措施完成后，相关项发生变更，则需要重新进行或补充相关的认可措施（见 GB/T 34590.8， 8.4.5.2）。
注 7：认可措施，如认可评审和功能安全审核，可以与功能安全评估合并、联合，以支持相关项类似变型的处理。
现成译文，到款即发。
任取样页验证译文质量。
提供正规增值税电子发票。
请联系手机/微信: 133-0649-6964/Email: standardtrans@foxmail.com 购买完整译文。
专业源于专注|ChinaAutoRegs 始终专注于汽车标准翻译领域！迄今为止已翻译上千个国内外汽车标准法规！独家打造千万级汽车专业术语库和记忆库。
Note:
This document in English is readily available, and delivered immediately upon payment.
You may request for sample pages to your preference to verify the quality of translation.
Please contact standardtrans@foxmail.com for the complete PDF in English.