ChinaAutoRegs｜GB/T 34590.8-2022英文版翻译English 道路车辆功能安全第8部分：支持过程（英语版）
Road Vehicles—Functional Safety—Part 8: Supporting processes
CONTENTS
Foreword
Introduction
1 Scope
2 Normative References
3 Terms and Definitions
4 Requirements
5 Interfaces within distributed developments
6 Specification and management of safety requirements
7 Configuration management
8 Change management
9 Verification
10 Documentation management
11 Confidence in the use of software tools
12 Qualification of software components
13 Evaluation of hardware elements
14 Proven in use argument
15 Interfacing an application that is out of scope of GB/T 34590
16 Integration of safety-related systems not developed according to GB/T 34590
Annex A (Informative) Overview of and document flow of supporting processes
Annex B (informative) Development Interface Agreement (DIA) example
Bibliography
1 范围
GB/T 34590的本部分规定了对支持过程的要求，包括：
——分布式开发中的接口；
——安全要求的整体管理；
——配置管理；
——变更管理；
——验证；
——文档化管理；
——使用软件工具的置信度；
——软件组件的鉴定；
——硬件组件的鉴定；
——在用证明；
——接口超出GB/T 34590范围的应用；及
——未根据GB/T 34590开发的安全相关系统的集成。 本文件适用于安装在除轻便摩托车外的量产道路车辆上的包含一个或多个电气/电子系统的与安全
相关的系统。
本文件不适用于特殊用途车辆上特定的电气/电子系统，例如，为残疾驾驶者设计的车辆。
注：其他专用的安全标准可作为本文件的补充，反之亦然。
已经完成生产发布的系统及其组件或在本文件发布日期前正在开发的系统及其组件不适用于本文 件。对于在本文件发布前完成生产发布的系统及其组件进行变更时，本文件基于这些变更对安全生命周 期的活动进行裁剪。未按照本文件开发的系统与按照本文件开发的系统进行集成时，需要按照本文件进 行安全生命周期的裁剪。
本文件针对由安全相关的电气/电子系统的功能异常表现而引起的可能的危害，包括这些系统相互 作用而引起的可能的危害。本文件不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐 蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由安全相关的电气/电子系统的功能异常 表现表现而引起的。
本文件提出了安全相关的电气/电子系统进行功能安全开发的框架，该框架旨在将功能安全活动整 合到企业特定的开发框架中。本文件规定了为实现产品功能安全的技术开发要求，也规定了组织应具备 相应功能安全能力的开发流程要求。
本文件不针对电子电气系统的标称性能。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， 仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 文件。
GB/T 34590.1 道路车辆 功能安全 第1部分：术语(ISO 26262-1:2018,MOD)
GB/T 34590.2 道路车辆 功能安全 第2部分：功能安全管理(ISO 26262-2: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.9 道路车辆 功能安全 第9部分：以汽车安全完整性等级为导向和以安全为导向 的分析(ISO 26262-9:2018,MOD)
3 术语、定义和缩略语
GB/T XXXXX-1给出的术语、定义和缩略语适用于本文件。
4 要求
4.1 目的
本章规定了：
a) 如何符合 GB/T 34590；
b) 如何解释 GB/T 34590 中所使用的表格；及 c) 如何解释各章条基于不同的 ASIL 等级的适用性。
4.2 一般要求
如声明满足GB/T 34590的要求时，应满足每一个要求，除非有下列情况之一：
a) 按照 GB/T XXXXX.2 的要求，安全活动的剪裁已经实施并表明这些要求不适用；或
b) 不满足要求的理由存在且是可接受的，并且按照 GB/T XXXXX.2 的要求对该理由进行了评 估。
标有“注”或“示例”的信息仅用于辅助理解或阐明相关要求，不应作为要求本身且不具备完备性。 将安全活动的结果作为工作成果。应具备上一阶段工作成果作为“前提条件”的信息。如果章条的
某些要求是依照ASIL定义的或可剪裁的，某些工作成果可不作为前提条件。
“支持信息”是可供参考的信息，但在某些情况下，GB/T 34590不要求其作为上一阶段的工 作成果，并且可以是由不同于负责功能安全活动的人员或组织等外部资源提供的信息。
4.3 对表格的诠释
本文件中的表是规范性或资料性取决于上下文。在满足相关要求时，表中列出的不同方法有助于置 信度水平。表中的每个方法是：
a) 一个连续的条目（在最左侧列以顺序号标明，如 1、2、3）；或
b) 一个选择的条目（在最左侧列以数字后加字母标明，如 2a、2b、2c）。 对于连续的条目，高度推荐和推荐的方法按照ASIL等级推荐予以使用。高度推荐或推荐的方法允许
用未列入表中的其它方法替代,此种情况下，应给出满足相关要求的理由。如果可以给出不选择所有条
目也能符合相应要求的理由，则不需要对缺省方法做进一步解释。
对于选择性的条目，应按照指定的ASIL等级对这些方法进行适当的组合，而与这些方法在表中是否 列出无关。如果所列出的方法对于一个ASIL等级来说具有不同的推荐等级，宜采用具有较高推荐等级的 方法。应给出选择组合方法或选择单一方法满足相应要求的理由。
注：在表中所列出方法的理由是充分的。但是，这并不意味着有倾向性或对未列到表中的方法表示反对。
对于每种方法，应用相关方法的推荐等级取决于ASIL等级，分类如下：
——“++”表示对于指定的 ASIL 等级，高度推荐该方法；
——“+” 表示对于指定的 ASIL 等级，推荐该方法；
——“o” 表示对于指定的 ASIL 等级，不推荐也不反对该方法。
4.4 基于 ASIL 等级的要求和建议
若无其它说明，对于ASIL A、 B、 C和D等级，应满足每一章条的要求或建议。这些要求和建议参 照安全目标的ASIL等级。如果在项目开发的早期对ASIL等级完成了分解，按照GB/T XXXXX-9第5章的要 求，应遵循分解后的ASIL等级。
如果GB/T 34590中ASIL等级在括号中给出，则对于该ASIL等级，相应的章条应被认为是推荐 而非要求。这里的括号与ASIL等级分解无关。
4.5 摩托车的适用性
对于适用于GB/T XXXXX.12要求的摩托车的相关项或要素，GB/T 34590.12的要求替代本部分和GB/T 34590.2的相应要求。
4.6 卡车、客车、挂车和半挂车的适用性
对卡车、客车、挂车和半挂车的特殊规定以（T&B）来表示。
5 分布式开发的接口
5.1 目的
本章的目的是：
a) 定义客户和供应商在进行开发活动时的交互和依赖； b）描述职责的分配；及 c）识别相关项及其要素在进行分布式开发时需要交换的工作成果。
5.2 总则
相关项或要素开发的客户（如：车辆制造者）和供应商共同遵守 GB/T 34590 定义的分布式开发要 求。在安全生命周期中的概念、开发、生产、运行、服务和报废阶段，客户和供应商就责任达成一致。 分包的关系是被允许的。客户内部具有关于相关项开发的计划、执行和文档化的安全相关流程，因此， 类似的流程适用于与供应商在分布式相关项开发中的合作。这同样也适用于供应商对功能安全负有全部 责任的相关项开发。
注 1：开发接口协议（DIA）旨在描述客户和供应商之间的角色和责任。因此，客户和供应商的安全计划符合开发 接口协议。
注 2：本章不适用于未对供应商分配任何安全责任的采购，包括标准组件、元器件或委托开发。
注 3：本注释适用于 T&B：本章不适用于向基础车辆集成车辆上装设备的情况。第 15 章适用于把按照 GB/T 34590 开发的车辆上装设备集成到按照另一标准开发的基础车辆中的情况。第 16 章适用于把按照另一标准开发的车辆上装设 备集成到按照 GB/T 34590 开发的基础车辆中的情况。
5.3 本章的输入
5.3.1 前提条件
本文件安全生命周期相关阶段（该阶段计划且实施了分布式开发）中适用的前提条件。
5.3.2 支持信息
可考虑如下信息：
——安全生命周期相关阶段（该阶段计划且实施了分布式开发）中适用的支持信息；及
——基于报价需求（RFQ）的供应商投标（来自外部）。
5.4 要求和建议
5.4.1 要求的应用
5.4.1.1 应将本章的要求用于每个按照 GB/T 34590 开发的相关项和要素，但适用下述之一的商业现成 的且不是为了满足特定安全要求而定制生产的要素除外：
a) 按照基于质量标准（如：电子组件的 AEC 标准）的公认流程，鉴定商业现成的硬件要素，且按 照第 13 章进行评估；
b) 商业现成的软件组件按照第 12 章经鉴定合格的；或 c) 商业现成的硬件要素或软件组件作为 SEooC 来开发。
注 1：非定制生产的商业现成的硬件要素或软件组件可能是独立于客户的 SEooC，其项目特定的修改已被要 素规范所覆盖。
示例：通信堆栈、操作系统或软件库是商业现成的要素。
注 2：按照 GB/T 34590.2，6.4.5.7，SEooC 的假设在其目标应用中得到确认。
5.4.1.2 应将有关客户-供应商关系（接口和交互）的要求，用于客户-供应商关系的每个层面。
注 1：这包含顶层供应商采取的分包、分包商采取的分包等。
注 2：对内部供应商的管理可以采取与管理外部供应商相同的方法。
5.4.2 供应商选择准则
5.4.2.1 供应商选择准则应包含对供应商开发能力的评估，如果适用，也包含按照 GB/T 34590 对类似 复杂度和 ASIL 等级的相关项和要素的生产能力的评估。
注：供应商选择准则包含：
——供应商质量管理体系的证据；
——供应商以往的表现和质量；
——对供应商功能安全能力（作为投标的一部分）的确认；
——以往按照 GB/T 34590.2，6.4.12 进行的功能安全评估结果，或
——来自整车厂开发、生产、质量和物流部门（因其影响功能安全）的推荐。
5.4.2.2 客户给候选供应商的报价需求（RFQ）应包含： a) 符合 GB/T 34590 的正式要求；
b) 供货范围的定义；
注：供货范围规定了需要供应商提供的相关项或要素的功能、特性和边界。
c) 如果已存在，基于供应商报价对象的安全目标或相关功能安全要求（包含其分配的 ASIL 等级）； 及
注：如果在选择供应商时 ASIL 等级未知，则可以作出保守的假设。
d) 如果已存在，基于供应商报价对象的要素的失效率目标值和诊断覆盖率目标值（按照 GB/T 34590.4，6.4.5.3）
5.4.3 分布式开发的启动和计划
5.4.3.1 客户和供应商应定义开发接口协议，包含以下： a) 客户和供应商安全经理的任命；
b) 按照 GB/T 34590.2，6.4.5 进行安全活动的联合裁剪；
c) 客户需开展的安全生命周期的活动和供应商需开展的安全生命周期的活动；
注 1：活动的联合计划是需要考虑的，包含按照 GB/T 34590.2 给出的功能安全评估和功能安全审核的职责。
d) 需共享的信息和工作成果，包含分配和评审；
注 2：这包括对需提供的文档达成一致，以完成客户及供应商的安全档案； 注 3：交换的信息包含安全相关的特殊特性；
注 4：对所涉及开发方的活动所必须的工作成果相关部分，可进行识别和交换。
e) 每项活动分配给每一方的责任；
注 5：责任可以描述为“负责”、“批准”、“支持”、“通知”、“咨询”。
f) 目标值的沟通或确认（本文件 5.4.2.2d），这些目标值由系统层面的目标导出，再分配给相 关方，目的是使这些相关方满足单点故障度量及潜伏故障度量的目标值（按照 GB/T 34590.5 对硬件架构度量的评估和因随机硬件失效导致违背安全目标的评估）；
g) 在客户和供应商合作中所需要的接口相关的流程、方法及工具；
注 6：流程、工具及工具配置的版本和修订可以是相关的。
h) 哪一方（供应商或者客户）按照 GBT 34590.4 执行安全确认所达成的协议；
注 7：如果由供应商执行整车集成和确认，对供应商所需的能力和资源达成一致是重要的，因为安全确认工作 需要集成后的车辆（本文件 GB/T 34590.4）。
i) 按照 GB/T 34590.2，关于由供应商开发的要素或工作成果的功能安全评估活动；
注 8：这些由供应商开发的要素或工作成果的功能安全评估活动，可能是由供应商本身、客户、或供应商/客 户指定的组织或个人来执行。
j) 供应商关于功能安全评估报告的计划；及
注 9：开发接口协议包含报告的最低限度内容、版本和里程碑节点； 注 10：附录 B 给出了开发接口协议的一个示例。
k) 客户与供应商之间达成的允许客户指定审核人员在供应商的场所进行功能安全审核的协议。
5.4.3.2 如果供应商执行危害分析和风险评估，那么危害分析和风险评估应提供给客户进行验证和批 准。
5.4.3.3 概念阶段的责任方应按照 GB/T 34590.3 制定功能安全概念。
5.4.4 分布式开发的执行
5.4.4.1 客户应确保供应商按时收到所需的用于执行开发接口协议中安全活动的信息和数据。
5.4.4.2 供应商应向客户报告可能增加不符合开发接口协议条款的风险的问题。
5.4.4.3 供应商应向客户报告在其责任范围内和其分包商责任范围内的开发活动中发生的安全异常。
5.4.4.4 应分析已识别出的潜在影响供应商交付成果的安全异常，并采取措施予以解决。双方应就谁 来执行所需的行动达成协议。
5.4.4.5 供应商应确定客户的安全要求是否可行，以及 6.4.1 和 6.4.2 的要求是否满足。若不可行/ 不满足，则客户应重新检查安全要求并做适当的修改，以确保安全要求定义的正确性。
5.4.4.6 供应商应向客户传达其职责范围以外但供应商认为为确保实现功能安全所必要的相关项的要 素的安全要求。
5.4.4.7 在导出用于当前开发的安全要求时，按照 GB/T 34590.2，5.4.2.6，双方都应考虑从之 前相似开发中所获得的经验。
5.4.4.8 供应商应向客户报告安全计划中制定的各项任务和里程碑节点上所取得的进展。供应商和客 户应就报告的内容和提交的日期达成一致。
5.4.5 分布式开发中的功能安全评估活动
5.4.5.1 对于分配了安全要求的最高 ASIL 等级为 ASIL（B）、C 或 D 的要素，在 DIA 中应指定哪个组 织按照 GB/T 34590.2 对供应商开发的要素或工作成果执行功能安全评估活动。
注 1：这些由供应商开发的要素或工作成果的功能安全评估活动，可能由供应商本身、客户、或者客户/供应商指定 的组织或人员执行。
注 2：在 DIA 审批过程中，所有这些都需要与客户达成一致。
5.4.5.2 对于分配了安全要求的最高 ASIL 等级为 ASIL（B）、C 或 D 的要素，在 DIA 中应规定供应商
功能安全评估活动的计划。
注：计划包括报告的最低限度内容和里程碑节点。
5.4.5.3 对于分配了安全要求的最高 ASIL 等级为 ASIL（B）、C 或 D 的要素，供应商应向客户提供功 能安全评估报告，包括供应商对所开发的要素是否符合来自客户的安全要求的评估，以及所实施的流程 是否满足实现功能安全的准则。
5.4.5.4 对于分配了安全要求的最高 ASIL 等级为 ASIL（B）、C 或 D 的要素，应将供应商的功能安全 评估活动的结果提供给客户和供应商。
5.4.6 生产、运行、服务和报废的协议
5.4.6.1 供 应 商 应 向 客 户 提 供 证 据 ， 证 明 能 具 备 并 保 持 GB/T 34590.2 第 7 章 和 GB/T
34590.7 第 5 章和第 6 章所要求的生产过程能力。
注：关于半导体生产的指南，本文件 GB/T 34590.11，4.9。
5.4.6.2 客户和供应商间的供应协议应依据 GB/T 34590.2，7.4.2.1 明确功能安全责任，并应定 义各方的安全活动。
注：关于半导体分布式开发的指南，本文件 GB/T 34590.11，4.10。
5.4.6.3 供应协议应规定各方间关于安全相关特殊特性的生产监控记录和从客户退回部件的失效分析 结果的访问和交换。
注：这些事项能由质量管理协议充分覆盖。
5.4.6.4 供应协议应规定关于交换安全相关事件和所需分析的及时的沟通渠道。对于现场问题，就按 照已建立的现场监控过程对这些事件进行分析。
注：该分析包括类似相关项和潜在受类似事件影响的其他方。
5.5 工作成果
5.5.1 供应商选择报告，由 5.4.2.1 和 5.4.2.2 的要求得出。
5.5.2 开发接口协议（DIA），由 5.4.3，5.4.5.1 和 5.4.5.2 的要求得出。
5.5.3 供应商安全计划，由 5.4.3 和 5.4.4 的要求得出。
5.5.4 功能安全评估报告，由 5.4.5.3 和 5.4.5.4 的要求得出。
5.5.5 供应协议，供应协议，由 5.4.6.1～5.4.6.4 的要求得出。
6 安全要求的定义和管理
6.1 目的
本章的目的是：
a) 确保正确的定义安全要求及其属性和特性；及
b) 确保在整个安全生命周期内对安全要求的一致管理。
6.2 总则
安全要求是旨在达到并确保所需功能安全等级的要求。 在安全生命周期过程中，安全要求通过分层结构进行定义和细化。图 2 给出了 GB/T 34590
中用到的安全要求的结构和相关性。安全要求被分配给要素或在要素间分布。 安全要求的管理包括：对要求达成一致、从安全要求的执行方取得承诺和保持追溯性。 为了支持对安全要求的管理，推荐使用合适的需求管理工具。
“GB/T 34590.3、GB/T 34590.4、GB/T 34590.5”列出了有关安全要求内容在不同层面的特定要求。
6.3 本章的输入
6.3.1 前提条件
应具备如下信息:
—组织的专门的功能安全规章和流程，按照GB/T 34590.2,5.5.1；及
—安全生命周期相关阶段（该阶段定义或管理了安全要求）中适用的前提条件。
6.3.2 支持信息
本文件安全生命周期相关阶段（该阶段定义或管理了安全要求）中适用的支持信息。
6.4 要求和建议
6.4.1 安全要求的定义
为了达到 6.4.2.4 所列安全要求的特性，应使用以下恰当的组合来定义安全要求：
a) 自然语言；及
b) 表 1 所列的方法。
6.4.2 安全要求的属性和特性
6.4.2.1 安全要求应能被明确的识别为安全要求。
注：为了符合该要求，可将安全要求列在一个单独的文件中。如果在同一文件中管理安全要求和其他要求，可通过 使用 6.4.2.5 中给出的特殊属性而明确的识别出安全要求。
6.4.2.2 安全要求应继承将其导出的原安全要求的 ASIL 等级，但运用了按照 GB/T 34590.9 的 ASIL 分解除外。
注：因安全目标是顶层的安全要求，故 ASIL 等级的继承始于安全目标层。
6.4.2.3 应将安全要求分配给实施这些要求的相关项或要素。
6.4.2.4 安全要求应具有如下特性:
注 1：安全要求的特性能够使相关人员进行清晰地沟通。这些特性是向必须执行安全要求的人传达安全要求的主要 手段。下面引用的特性与 ISO/IEC/IEEE 29148(参考文献【8】）中引用的特性一致。
a) 明确的；
注 2：如果对要求的意思存在共同的理解，那么要求是明确的。
b) 可理解的；
注 3：如果要求的相关人员或要求的使用者理解要求的意思，那么要求是可理解的。
c) 不可分割的（单一的）；
注4：当一个层面的安全要求在所考虑的层面上不能被分解为至少两个独立的安全要求，那么这些要求是不可 分割的。此特性的实现可能与安全要求的其他基本特性的实现相矛盾。在这种情况下，不可分割的重要性可 以降低。
d) 内部一致的；
注 5：如果要求不包含自相矛盾的内容，则要求是内部一致的。
e) 可行和可实现的；
注 6：如果某个要求在相关项的开发限制（资源、当前技术水平等）内可被实现，则其是可行的。
注 7：一项要求在技术上可以实现，它不需要重大的技术进步，并且在可接受范围内符合相关项限制（如成本、 进度、技术、法律、法规等）”；
f) 可验证的
注 8：如果在定义要求的层面上有方法检查这些要求是否得到了满足，则要求是可验证的。
注 9：收集到有关相关项的证据表明相应的要求已得到满足。如果要求是可测量的，可验证性会更强。
g) 必要的
注 10：要求中定义了基本能力、特性、约束和/或质量因素。如果移除或删除，则将存在产品的其他能力或 流程无法满足的缺陷。
注 11：要求在当前是适用的，且没有随着时间的推移而改变。对于具有计划失效日期或适用日期的要求进行 了清晰的识别。
h) 实施自由的
注 12：要求定义的是对于相关项必要和充分的内容，避免对架构设计施加不必要的限制。该属性的目的是独 立实施要求。要求描述的是需要什么，而不是如何满足。
i) 完整的，及
注 13：所描述的要求是可测量的，并且充分描述了要求相关者所关注的能力和特性，因此要求是清晰的，不 需要进一步扩充。
j) 合规的
注 14：所述要求符合相关适用的且应满足来自政府、汽车工业及产品的标准、规范和接口要求。
6.4.2.5 安全要求应具有如下属性：
a) 在整个安全生命周期中，具有唯一识别并保持不变；
示例 1：可通过不同的方法实现对要求的唯一识别，如对每个词“应”标注下脚标，例如：“系统应 9782 检查…”； 或者对含有词“应”的每个句子进行连续的编号，例如：“9782 在…情况下，系统应检查…”。
b) 状态；及
示例 2：安全要求的状态可以是“已建议”、“已假设”、“已接受”、“已评审”、“已交付”或“已验证”。
c) ASIL 等级。
6.4.3 安全要求的管理
6.4.3.1 从一个或多个安全目标导出的相关项或要素的安全要求集应具备以下特性： a) 分层结构；
注 1：如图 2 所示，分层结构是指安全要求是由几个连续层面构建而成的。这些层面总是与相应的设计阶段 保持一致。图 2 中的任何设计阶段都可能存在多个层面的分层。
b) 按照适当分组原则建立的组织结构；
注 2：安全要求的组织意味着每个层面的安全要求被分组在一起，通常与架构相对应。
c) 完整性；
注 3：完整性表示一个层面的安全要求完全的实施了上一层面的全部安全要求。
d) 外部一致性；
注 4：不同于内部一致性，即每个单独的安全要求不包含与自身相矛盾的内容，外部一致性表示多个安全要求 不互相矛盾。
e) 分层结构中任意一层的信息不重复；及
注 5：信息不重复表示安全要求的内容不重复出现在分层结构同一层面的其他安全要求中，并且在每个分层层 面均有此要求。
f) 可维护性。
注 6：可维护性表示要求集可被修改或扩展，例如引入要求的新版本或增加/去掉要求集内的要求。 注 7：当每个要求满足 6.4.2.4 的所有要点，并且要求集满足 6.4.3.1 时，可维护性得到了提高。
6.4.3.2 安全要求应是可追溯的，与以下内容相关联：
a) 安全要求在下一个更高分层层面的每个来源；
b) 导出到下一个更低分层层面的每个安全要求，或各安全要求在设计中的实现；及
c) 按照 9.4.2 的验证规范。
注 1：可使用各种追溯记录类型，如需求管理系统、电子材料等。
注 2：可追溯性支持：
——要求、其实现及验证间的一致性；
——对特定的安全要求更改后，影响分析的有效性；及
——认可措施(如功能安全评估，以评估功能安全实现与否)的执行。
6.4.3.3 应将表 2 所列验证方法的恰当组合用于验证安全要求是否符合本章的要求，及是否符合得出 安全要求的 GB/T 34590 相关部分中关于验证安全要求的特定要求。
6.4.3.4 按照第 7 章，安全要求应置于配置管理下来维护整个安全生命周期的一致性。
示例：当较低层面的安全要求与较高层面的安全要求相符合时，配置管理可以定义一个基线作为安全生命周期后续 阶段的基础。
6.5 工作成果
无。
7 配置管理
7.1 目的
本章的目的是： a）确保工作成果、相关项、要素及其生产的原理和一般条件，在任何时间以可控的方式可被唯一
识别和重生成；及 b）确保当前版本和较早版本的关系及区别是可追溯的。
7.2 总则
配置管理是汽车工业中的成熟实践，可依据如 ISO 10007、Automotive SPICE、ISO/IEC 33000 、 ISO/IEC/IEEE 15288[4]和 ISO/IEC/IEEE 12207 进行应用。
GB/T 34590 的每个工作成果要服从于配置管理。
7.3 本章的输入
7.3.1 前提条件
应具备如下信息：
——安全计划，按照GB/T 34590.2，6.5.3；
——组织专门的功能安全规章和流程, 按照GB/T 34590.2，5.5.1；及
——安全生命周期相关阶段（该阶段对配置管理进行了计划或管理）中适用的前提条件；及
7.3.2 支持信息
无。
7.4 要求和建议
7.4.1 应计划配置管理。
注：配置管理计划可以包括职责和资源、工具和存储库、配置项的识别和命名规范、访问权限、基线计划、发布/ 批准程序。
7.4.2 配置管理过程应符合：
a) 质量管理体系标准的相关要求；及 b) 软件开发的特定要求。
注 1：软件开发的软件配置管理的特定要求，本文件 ISO/IEC/IEEE12207。
注 2：配置管理过程可以适应开发的相应阶段。
7.4.3 安全计划要求的工作成果及再次生成相关项和要素所需要的工作成果，应按照配置管理策略， 生成基线并存放。
7.4.4 在整个安全生命周期中，需要被唯一识别和重生成的工作成果、相关项和要素，在配置管理策 略中应定义其条件或目的。
示例：作为客户-供应商关系里安全活动的一部分，在其交换之前需要创建工作成果、相关项和要素的配置条件或 目的。
7.4.5 在整个安全生命周期中，应对配置管理进行维护。
7.5 工作成果
7.5.1 配置管理计划，由 7.4.1～7.4.5 的要求得出。
8 变更管理
8.1 目的
变更管理的目的是在整个安全生命周期中，分析和控制安全相关工作成果、相关项和要素的变更。
8.2 总则
变更管理确保对变更进行系统性计划、控制、监测、实施和记录，同时在整个安全生命周期内维护 工作成果、相关项和要素的相关功能和特性。
注：变更理解为因组件或元器件的异常、移除、增添、加强、报废等导致的修改。
变更管理是汽车行业中的成熟实践，可根据 ISO 10007、Automotive Spice®、ISO/IEC 33000、 ISO/IEC/IEEE 15288[4]或 ISO/IEC/IEEE 12207 等进行应用。
8.3 本章的输入
8.3.1 前提条件
应具备如下信息：
——配置管理计划，按照7.5.1；
——安全计划，按照GB/T 34590.2，6.5.3；及
——组织专门的功能安全规章和流程，按照GB/T 34590.2，5.5.1。
8.3.2 支持信息
无。
8.4 要求和建议
8.4.1 计划和启动变更管理
8.4.1.1 在对工作成果进行变更前，应计划和启动变更管理流程。
注：配置管理和变更管理是相互关联的，定义并维护两个流程间的接口，以确保变更管理的有效性。
8.4.1.2 应在变更管理计划中识别要进行变更管理的工作成果、相关项和要素，这些工作成果、相关
项和要素也要满足 7.4.3 的要求。
8.4.1.3 应为已识别出的工作成果、相关项和要素定义实施变更管理流程的日程表。
8.4.1.4 变更管理流程应包括： a) 变更需求，按照 8.4.2；
b) 变更需求分析，按照 8.4.3；
c) 变更需求的决策和依据，按照 8.4.4；
d) 已接受的变更的实施和验证，按照 8.4.5；及 e) 文档化，按照 8.4.5。
注 1：变更管理流程可适用于开发过程中的相应阶段； 注 2：可在一个变更需求中处理多个变更。
8.4.2 变更需求
8.4.2.1 应为每个变更需求分配唯一的识别码。
8.4.2.2 每个变更需求应至少包含以下信息： a) 日期；
b) 所需变更的理由；
c) 所需变更的准确描述；及 d) 所需变更基于的配置。
8.4.3 变更需求分析
8.4.3.1 对于每个变更需求,应针对以下信息,对所涉及的相关项或要素、接口及关联相关项或要素进 行影响分析：
a) 变更需求的类型；
示例：可能的变更类型有：解决错误、调整、消除、加强、预防。
b) 对需更改的工作成果、相关项和要素及受影响的工作成果、相关项和要素进行的识别； c) 在分布式开发的情况下，所涉及的相关方的识别及其责任；
d) 变更对功能安全的潜在影响；及 e) 变更的实现和验证的日程表。
8.4.3.2 对工作成果的每次变更，应重新启动安全生命周期的适用阶段。后续阶段的开展应符合 GB/T
34590。
8.4.4 变更需求评估
8.4.4.1 应使用按照 8.4.3.1 进行的影响分析的结果,对变更需求进行评估,并且应由授权人员决定是 否接受、拒绝或推迟变更。
示例：典型的授权的人员包括：
——项目经理；
——安全经理；
——负责质量保证的人员；及
——涉及的开发人员。
注：已接受的变更需求可按优先级排序，并与已接受的相关变更需求合并。
8.4.4.2 对于每个已接受的变更需求，应决定由谁来开展变更及变更的最晚时间。该决定应考虑开展 变更时所涉及到的接口。
8.4.5 变更的实施和记录
8.4.5.1 应按计划实施变更和验证变更。
8.4.5.2 如果变更影响了安全相关功能或特性，则应在发布相关项前，对按照 GB/T 34590.2 的
6.4.9 和 6.4.10 的功能安全评估和适用的确认评审进行更新。
8.4.5.3 变更的记录应包含以下信息：
a) 按照第 7 章，在合适的层面下，变更的工作成果、相关项和要素的清单，包括：配置和版本。 b) 开展的变更细节；及
c) 变更部署的计划日期。
注 1：对临时变更需求，应明确指出该变更需求的理由和变更持续的时间（如已知）。 注 2：对被拒绝的变更需求，记录变更需求和拒绝的理由。
8.5 工作成果
8.5.1 变更管理计划，由 8.4.1 的要求得出。
8.5.2 变更需求，由 8.4.2 的要求得出。
8.5.3 影响分析和变更需求计划，由 8.4.3 和 8.4.4 的要求得出。
8.5.4 变更报告，由 8.4.5 的要求得出。
9 验证
9.1 目的
验证的目的是确保工作成果符合它们相应的要求。
9.2 总则
验证适用于以下安全生命周期阶段： a）在概念阶段，验证确保了概念是正确的、完整的、并符合相关项的边界条件，同时确保了定义
的边界条件本身是正确的、完整的和一致的，以使概念可以得到实现。 b）在产品开发阶段，以不同的方式执行验证，描述如下：
——在设计阶段，验证是对工作成果的评估，例如：需求规范、架构设计、模型或软件编码， 从而确保它们与之前建立的要求在正确性、完整性和一致性方面相符合。评估可通过评审、模 拟或分析技术开展，并以系统化方式计划、定义、执行和记录。
注：设计阶段是指 GB/T 34590.4 第 6 章、GB/T 34590.5 第 7 章、GB/T 34590.6 第 7 章和 GB/T 34590.6 第 8 章。
——在测试阶段，验证是在测试环境下对工作成果、相关项和要素的评估，以确保其满足要求。 测试以系统化的方式进行计划、定义、执行、评估和记录。
c）在生产和运行阶段，验证确保了：
——生产过程中恰当地满足安全相关的特殊特性
——在用户手册、维修和维护指导中恰当地提供了安全相关的信息；及
——通过在生产流程中应用控制措施，相关项的安全相关特性得到了满足。
注：这是一般性的验证流程，GB/T 34590.3、GB/T 34590.4、GB/T 34590.5、GB/T 34590.6 和 GB/T 34590.7 中的安全生命周期的各阶段给出了示例。该流程并不针对安全确认。本文件 GB/T 34590.4 第 8 章，以 获取更多细节。
9.3 本章的输入
9.3.1 前提条件
应具备如下信息：
——组织专门的功能安全规章和流程，按照 GB/T 34590.2,5.5.1；及
——安全生命周期相关阶段（该阶段计划和执行验证）中适用的前提条件。
9.3.2 支持信息
本文件安全生命周期相关阶段（该阶段计划和执行验证）中适用的支持信息。
9.4 要求和建议
9.4.1 验证计划
9.4.1.1 对安全生命周期的每个阶段及子阶段，应制定验证计划，并应涵盖以下方面：
a）需验证的工作成果内容；
b）验证的目的；
c）用于验证的方法；
d）验证通过和不通过的准则；
e）如果适用，验证环境；
注：验证环境可以是测试环境或模拟环境。
f）如果适用，用于验证的设备；
示例：测试工具或者测量设备。
g）如果适用，用于验证的资源；
h）当探测出异常时需采取的行动；及 i）回归策略。
注：回归策略定义了在相关项或要素变更后如何重复进行验证。验证可以被全部或部分重复，并可包含其他 能影响验证结果的相关项或要素。
9.4.1.2 制定验证计划宜考虑以下方面： a）所使用验证方法的充分性；
b）需验证的工作成果的复杂性； c）与验证目标材料相关的前期经验；及
注：这包括维修历史及在用证明达到的程度。
d）所使用技术的成熟度，或使用这些技术的风险。
9.4.2 验证规范
9.4.2.1 验证规范应对用于验证的方法进行细化，并应包含：
a）评审或分析的检查清单；或
b）模拟场景；或 c）测试用例、测试数据和测试目标。
9.4.2.2 对于测试，每条测试用例的定义应包含以下内容：
a）唯一的识别； b）需验证的相关工作成果的版本的参考；
c）前提条件和配置；
注：如果对工作成果的可能配置（例如：系统变型）进行完整验证是不可行的，可选择一个合理的子集（例 如：系统的最小或最大功能性配置）。
d）如果适用，环境条件；
注：环境条件与周围物理属性（例如：温度）有关，测试在该环境进行或模拟部分测试。 e）输入数据，数据时序及其值； f）期望的表现，包括：输出数据、输出值的可接受范围、时间表现和公差表现；及
注 1：当定义期望的表现时，对初始输出数据的定义可能是必要的，以探测变化。
注 2：为避免重复定义和存储不同测试用例用到的前提条件、配置及环境条件，有必要使用明确的参考。
g）确定测试用例通过和不通过的准则。
9.4.2.3 对于测试，应按使用的测试方法对测试用例进行分组，从以下几个方面考虑： a）所需的测试设备或测试环境；
b）逻辑和时间的依赖性；及 c）资源。
示例：将测试用例分成回归测试用例和完整测试用例。
9.4.2.4 对于测试，测试用例宜由与待验证的工作成果的完成人不同的人进行评审。
9.4.3 验证的执行和评估
9.4.3.1 应按照 9.4.1 所做的计划及按照 9.4.2 所做的规范，执行验证。
9.4.3.2 验证宜由与待验证的工作成果的完成人不同的人执行。
9.4.3.3 对验证结果的评估应包含以下信息： a）所验证工作成果的唯一识别； b）验证计划和验证规范的参考；
c）如果适用，评估中用到的验证环境配置、验证工具及标定数据； d）验证结果与期望结果的一致性水平；
e）验证通过或不通过的明确的陈述，如果验证不通过，陈述应包含不通过的理由和对所验证工作 成果进行修改的建议；及
注：按照验证的完成和结束准则[本文件 9.4.1.1 d)]和预期的验证结果，对验证进行评估。
f）每个验证步骤未执行的理由。
9.4.3.4 用于验证的测试设备应能提供有效的和可重复的结果，并应按照所采用的质量管理体系进行管 控。
9.5 工作成果
9.5.1 验证计划，由 9.4.1.1 和 9.4.1.2 的要求得出。
9.5.2 验证规范，由 9.4.2.1～9.4.2.4 的要求得出。
9.5.3 验证报告， 由 9.4.3.1 ～ 9.4.3.4 的要求得出。
10 文档管理
10.1 目的
目的是开发用于整个安全生命周期的文档管理策略，以促进有效的和可重复的文档管理过程。
10.2 总则
文档管理是汽车工业中的一个成熟的实践，可依据质量管理体系（例如 IATF16949 [6]或 ISO9001[3]） 或相关标准（例如 ISO/IEC/IEEE 12207 或 ISO/IEC/IEEE 15288[4]）进行应用。
GB/T 34590 中对文档的要求主要关注内容，而非排版和外观。 信息不必一定呈现在物理文档中。文档可采取不同的形式和结构，并可使用工具自动生成文档。 示例：可能的形式有：纸张、电子媒体、数据库。
信息是否充分取决于很多因素，包括:复杂性、安全相关系统/子系统的范围和与特殊应用相关的要
求。
宜避免一个文档中信息的重复及不同文档间信息的重复，以助于可维护性。
注：在一个文档中，使用交叉引用以代替信息的重复，将读者引向信息的源文件。
10.3 本章的输入
10.3.1 前提条件
应具备如下信息：
——组织专门的功能安全规章和流程，按照GB/T 34590.2,5.5.1；及
——安全计划，按照GB/T 34590.2，6.5.3。
10.3.2 支持信息
无。
10.4 要求和建议
10.4.1 应计划文档管理过程，以获得文档：
a) 用于在整个生命周期的每个阶段中有效完成各阶段及验证活动； b) 用于功能安全的管理；及
c) 作为认可措施的输入。
10.4.2 应将对 GB/T 34590 中工作成果的识别理解为文档化要求，文档应包含相关要求的结果信息。
注：文档可以是单个文档的形式，该文档包含工作成果的完整信息；也可以是一组文档的形式，这些文档合起来包 含工作成果的完整信息。
10.4.3 文档宜是：
a) 准确的和简明的； b) 结构清晰的；
c) 目标使用者容易理解的； d) 可验证的；及
e) 可维护的。
10.4.4 整个文档的结构宜考虑内部流程和工作实践。应对文档进行组织以助于搜索相关信息。
示例：文档树。
10.4.5 每个工作成果或文档应包含下面的正式要素： a) 题目，参照内容的范围；
b) 作者和批准者；
c) 文档每个不同修订（版本）的唯一标识； d) 变更历史；及
注：变更历史包含：每次变更的作者姓名、日期和简要描述。
e) 状态。
注：“草稿”、“已发布”、“有效”、“废止”。
10.4.6 按照第 7 章，应能识别当前适用的文档修订（版本）或信息项。
10.5 工作成果
10.5.1 文档管理计划，由 10.4.1 和 10.4.2 的要求得出。
10.5.2 文档指南要求，由 10.4.3~10.4.6 的要求得出。
11 所使用软件工具的置信度
11.1 目的
本章的目的是： a）提供准则，以确定在适用时所要求的软件工具置信度水平；及
b）在适用时提供鉴定软件工具的方法，以建立证据证明软件工具适合用于支持 GB/T 34590 要求的活动或任务（即，对那些 GB/T 34590 要求的活动或任务，使用者可依靠软件工具的正确功 能）。
11.2 总则
在系统或其软件要素、硬件要素开发中使用的软件工具，可以支持 GB/T 34590 要求的活动 或任务。在这些情况下，需要具备软件工具有效达到下述目标的置信度：
a) 在开发产品中，将因软件工具功能异常导致错误输出的系统性故障的风险减小到最低；及
b) 如果 GB/T 34590 要求的活动或任务依赖于所使用软件工具的正确功能，软件工具的开发 流程充分符合 GB/T 34590。
注 1：“软件工具”，可以是独立软件包，也可以是由一套软件工具集成的工具链。 示例 1：商业工具、开源工具、免费工具、共享工具或使用者自己开发的工具。
为了制定上述条件下开发的软件工具的置信度水平要求，对以下准则进行评估：
——软件工具功能异常及其相应的错误输出，可导致或无法探测出正在开发的安全相关项或要素中 的错误的可能性；及
——防止或探测软件工具相应输出中的这些错误的置信度。 基于工具用户的要求，工具可以是已有的，也可以是按照要求开发的。 示例：软件开发工具、需求管理工具、系统设计工具、测试工具、静态分析工具等。
使用软件工具的置信度由两组活动组成，详见图 3： a) 工具使用方面
——基于工具所需功能和特性进行软件工具使用评估。相应工具置信度（TCL）的确定是基于 分析等级，包括工具影响（TI）、工具错误探测（TD）。TI和TD的确定取决于使用该工具进行 要素开发和/或验证的开发过程。
——按照评估和鉴定的结果，将软件工具集成进用户环境（见11.4.2和11.4.3）。
示例 2：工具可能需要与配置管理工具、编辑工具或编译器进行集成。
——验证该工具在用户环境下正常工作。检查预定的工具置信度水平或鉴定（11.4.2）的有效 性，如果需要，在用户环境下执行鉴定过程。
示例 3：为有代表性的使用案例测试用户环境下的工具的执行情况。 示例 4：运行工具确认测试套件。
——工具的适当使用：在用户环境下，操作工具按照定义的程序自动执行开发/验证任务。（本 文件11.4.3）。
b) 工具鉴定方面
——基于对工具使用给定的或假设的信息（例如：使用案例、用户要求、TCL、ASIL等级）进 行工具鉴定。
对工具要求的严格性，不宜因工具是已有的或者定制的而有倾向性。相反，要求取决于工具的作用、 工具失效相关的风险和相关项或要素的最高ASIL等级。
注 2：此方法的目的是避免对专门为电子电气系统开发的低影响的工具提出过度要求。另外，此方法也降低了由以 下假设所带来的倾向性：不需要对已有工具提出适当严格的要求。
现成译文，到款即发。
任取样页验证译文质量。
提供正规增值税电子发票。
请联系手机/微信: 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 before placing an order.
Please contact standardtrans@foxmail.com for the complete PDF in English.