ChinaAutoRegs｜GB/T 34590.4-2022英文版翻译English 道路车辆功能安全第4部分：产品开发：系统层面（英语版）
Road Vehicles—Functional Safety—Part 4: Product Development at The System Level
CONTENTS
Foreword
Introduction
1 Scope
2 Normative References
3 Terms and Definitions
4 Requirements
5 General topics for the product development at the system level
6 Technical safety concept
7 System and item integration and testing
8 Safety validation
Annex A (Informative) Overview of and workflow of product development at the system level
Annex B (Informative) Example contents of hardware-software interface (HSI)
Bibliography
1 范围
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.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) 按照 GB/T 34590.2 的要求，安全活动的剪裁已经实施并表明这些要求不适用；或
b) 不满足要求的理由存在且是可接受的，并且按照 GB/T 34590.2 的要求对该理由进行了 评估。
标有“注”或“示例”的信息仅用于辅助理解或阐明相关要求，不应作为要求本身且不具备完备性。 将安全活动的结果作为工作成果。应具备上一阶段工作成果作为“前提条件”的信息。如果章条的
某些要求是依照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 系统层面产品开发的概述
目的
本章的目的是提供系统层面产品开发的概览。
总 则
图2给出了系统开发过程中的必要活动。技术安全概念在迭代过程中被开发出来，其包括技术安全 要求和系统架构设计。系统架构建立后，将技术安全要求分配给系统的各要素，如果适用，也可分配给 其他技术。此外，技术安全要求需要被细化，增加来自系统架构的包括软硬件接口（HSI）在内的要求。 同时，基于架构的复杂程度，子系统的要求可通过迭代得到。
完成相关开发后，集成硬件和软件要素并测试以形成一个相关项，然后，将该相关项集成在整车上。 一旦在整车层面完成了集成，进行安全确认以提供与安全目标和接受准则相关的功能安全证据。
本部分适用于系统开发。GB/T 34590.5 和 GB/T 34590.6分别提出了针对硬件和软件开发的要求。 图3 具有多层集成的系统示例，阐明了如何应用本部分及GB/T 34590.5和GB/T 34590.6。
注1：表A.1提供了对系统层面产品开发中特定子阶段的目标、前提条件和工作成果的概览。
6 技术安全概念
目的
本章目的为：
a) 为实现系统要素和接口的功能、相关性、约束和属性，制定所需的技术安全要求； b) 为系统要素和接口中将要实施的安全机制，制定技术安全要求；
c) 制定在生产、运行、服务和报废过程中系统及其要素功能安全的相关要求； d) 验证技术安全要求在系统层面是否符合功能安全要求并与功能安全要求一致；
e) 制定满足安全要求且不与非安全相关要求冲突的系统架构设计和技术安全概念；
f) 分析系统架构设计，以防止故障发生，并导出针对生产和服务必要的安全相关的特殊特性；及 g) 验证系统架构设计和技术安全概念是否满足相应 ASIL 等级的安全要求。
总则
技术安全概念是技术安全要求及其对应的系统架构设计的集合，提供了系统架构设计适合于满足
GB/T 34590.3（包括考虑非安全要求）中所述活动产生的安全要求和设计约束的依据。
技术安全要求规定了功能安全要求在其各自层级上的技术实现；要同时考虑相关项定义和系统架 构设计，并述及潜伏失效的探测、故障避免、安全完整性以及运行和服务方面的问题。
系统构架设计是由技术系统实现的所选系统层面解决方案。系统构架设计旨在同时满足所分配的 技术安全要求和非安全要求。
系统开发可以迭代执行。
本章的输入
6.3.1 前提条件
应具备下列信息：
——功能安全概念，按照 GB/T 34590.3,7.5.1;
——系统架构设计（来自外部，见 GB/T 34590.3,7.3.1）；及
——其他涉及安全的相关项对此相关项的要求（如果适用）。 示例：泊车辅助系统对制动系统的要求。 注：在分布式开发中，一个技术安全概念可基于由子系统实现的另一个技术安全概念。
6.3.2 支持信息
可考虑下列信息：
——危害分析和风险评估报告（见 GB/T 34590.3，6.5.1）；及
——相关项定义(见 GB/T 34590.3,5.5.1)。
要求和建议
6.4.1 技术安全要求的定义
6.4.1.1 技术安全要求应按照功能安全概念、相关项的系统架构设计来定义，考虑如下： a) 相关项、系统及其要素安全相关的关联性及约束条件；
b) 系统的外部接口，如果适用；及 c) 系统可配置性。
注1：设计约束可能来自于：环境条件、安装空间、实施本身（例如可用性能、热容量、热扩散）以及其他功能或非 功能性要求（例如安全性、所用技术的物理限制）。
注2：系统的可配置性由系统要素中的变量、配置数据或标定数据来确定，通常作为将现有系统复用于不同应用的策 略的一部分。
6.4.1.2 技术安全要求应定义影响安全要求实现的系统应激响应。 这包括相关激励和失效与每种相 关运行模式和定义的系统状态的组合。
示例：如果收到的 ACC 指令信息未通过错误检测代码检查，则制动系统电控单元（ECU）将禁用自适应巡航控制（ACC） 制动。
6.4.1.3 除技术安全要求已定义的那些功能外，如果其他功能或要求也由该系统或其要素实现，则应 定义这些功能或要求，或者参考其规范。
示例：其他要求可能来自联合国欧洲经济委员会（UN/ECE）法规、美国汽车安全技术法规（FMVSS）、公司平台战略、 功能概念或其他概念，例如信息安全概念。
6.4.1.4 技术安全要求和非安全要求不应矛盾。
6.4.2 安全机制
6.4.2.1 技术安全要求应定义安全机制，用于探测故障并防止或减轻出现在系统输出端的违反功能安 全要求（见 GB/T 34590.3,第 7 章）的失效，包括：
a) 与系统自身故障的探测、指示和控制相关的安全机制； 注1：包括用于探测随机硬件故障及探测系统性故障（如果适用）的系统自身监控。 注2：包括对通讯通道失效（例如：数据接口、通讯总线、无线射频链接）的探测和控制的安全机制。 注3：可以在系统架构适当的层级定义安全机制。
b) 涉及探测、指示和控制与本系统有相互影响的其他外部要素中所发生故障的安全机制；
示例：外部设备包括其他的电控单元、电源或者通讯设备。
c) 使系统实现或者维持在相关项的安全状态的安全机制；
注4：包括来自安全机制的多个控制请求的仲裁。
d) 定义和执行报警和降级策略的安全机制；及
e) 防止故障变为潜伏故障的安全机制。
注5：如同a)到d)，这些安全机制通常与上电过程（运行前检查）、运行中、下电过程（运行后检查）及维护过程中 发生的自检相关。
6.4.2.2 对于每个使相关项实现安全状态或维持安全状态的安全机制，应定义下列内容： a) 状态间的转换；
注1：包括控制执行器的要求。
b) 与从适当的架构层级分配得到的时间要求相关的故障处理时间间隔；及
注2：该子要求的目的是在针对每个安全目标定义的故障处理时间间隔的范围内，实现时间一致。
c) 不能在 FTTI 内进入相关项安全状态时的紧急运行容错时间间隔（见 GB/T 34590.1， 3.45）。
注3：整车测试和试验能够用于确定紧急运行容错时间间隔。 示例1：安全状态之前的降级运行持续时间。
示例2：一个依赖于电源的线控制动应用的安全机制，可以包括定义备用电源或储能设备(容量、启动和运行时间等)。
6.4.2.3 本要求适用于 ASIL(A)、(B)、C 和 D 等级：如果适用，应定义安全机制，以防止故障变为潜 伏故障。
注1：仅随机硬件故障的多点故障有可能成为潜伏故障。 示例：自检可作为检测多点故障的安全机制。用于验证组件在不同运行模式（例如上电、下电、运行或额外的自检
模式）下的状态。阀、继电器或灯在常规上电时进行的功能检测就是自检的例子。
注2：识别是否需要防止故障成为潜伏故障的安全机制的评估标准来源于良好的工程实践。GB/T 34590.5第8
章给出的潜伏故障度量提供了评估标准。
6.4.2.4 此要求适用于 ASIL(A)、(B)、C 和 D 等级：为了避免多点失效，应为每个探测多点故障的安 全机制定义诊断测试策略，包括：
a) 硬件组件的可靠性要求，并考虑其在架构中的角色及其对多点失效的贡献；
b) 定义的量化目标值， 表征由于随机硬件失效而违背各安全目标的最大可能性 ( 见 GB/T 34590.5,第 9 章)；
c) 已分配的 ASIL 等级，从相关安全目标、功能安全要求或更高层面的技术安全要求中导出；及
d) 多点故障探测时间间隔。
注1：诊断测试策略可以是时间驱动（例如使用诊断测试时间间隔）或者事件驱动（例如启动测试）。
注2：二阶多点失效包含以多点故障检测时间间隔分隔的两个故障。
注3：下列措施的使用取决于时间约束：
——系统或要素在运行过程中的周期性测试；
——要素在上下电时的自检；及
——系统或要素在维护时的测试。
6.4.2.5 本要求适用于 ASIL(A)、(B)、C 和 D 等级。仅为了防止双点故障变成潜伏故障而实施的安全 机制的开发应至少符合：
a) ASIL B 等级（对于分配为 ASIL D 等级的技术安全要求）；
b) ASIL A 等级（对于分配为 ASIL B 等级和 ASIL C 等级的技术安全要求）；及 c) QM 等级（对于分配为 ASIL A 等级的技术安全要求）。 注：如果安全要求运用了ASIL等级分解，那么本章的要求亦适用于分解后的要求。
示例：某内存存储采用奇偶校验作为安全机制，其安全要求被评为 ASIL B 等级。针对用于测试该奇偶校验机制在 探测和指示内存故障的能力的自检测试，其要求可被评为 ASIL A 等级。
6.4.3 系统架构设计规范和技术安全概念
6.4.3.1 技术安全概念和该子阶段的系统架构设计应基于相关项定义，功能安全概念和先前的系统架 构设计。
6.4.3.2 应检查 GB/T 34590.3,7.3.1 中的系统架构设计和本子阶段中的系统架构设计的一致性。 如果发现差异，则可能有必要对 GB/T 34590.3 描述的活动进行迭代。
6.4.3.3 系统架构设计应实现技术安全要求。
6.4.3.4 关于技术安全要求的实现，系统架构设计应考虑：
a) 验证系统架构设计的能力；
b) 与实现功能安全相关的预期软硬件要素的技术能力；及
c) 在系统集成过程中执行测试的能力；
6.4.3.5 应定义安全相关要素的内部和外部接口，其他要素不应对安全相关要素产生不利的安全相关 影响。
6.4.3.6 如果在系统架构设计期间对安全要求进行 ASIL 等级分解，应按照 GB/T 34590.9，第 5
章进行。
6.4.4 安全分析及避免系统性失效
6.4.4.1 应按照表 1 和 GB/T 34590.9 第 8 章进行系统架构设计的安全分析，其目的在于：
——为系统设计的适合性提供证据，以证明其适合提供与 ASIL 等级相适应的特定安全功能和特 性；
——识别失效原因和故障影响；
——识别或确认安全相关系统要素和接口；及
——支持设计规范，并基于已识别的故障原因和失效影响验证安全机制的有效性。
6.4.4.2 为符合安全目标或要求，应消除已识别出的引起失效的内部原因，或在必要时减轻它们的影 响。
6.4.4.3 为符合安全目标或要求，应消除已识别出的引起失效的外部原因，或在必要时减轻它们的影 响。
6.4.4.4 为了减少系统性失效的可能性，宜在适用处应用值得信赖的系统设计原则。这些原则可能包 括：
a) 值得信赖的技术安全概念的复用；
b) 值得信赖的要素设计的复用，包括硬件和软件组件； c) 值得信赖的探测和控制失效的机制的复用；
d) 值得信赖的或标准化接口的复用。
6.4.4.5 应对值得信赖的设计原则的适用性进行分析并形成文档，以确保其和最终产品应用的一致性 和适用性。
6.4.4.6 为了避免系统性故障，系统架构设计应具有以下特征： a) 模块化；
b) 适当的颗粒度水平；及
c) 简单。
注：可以通过使用诸如分层的设计，精确的接口定义，避免组件和接口不必要的复杂性，可维护性和可验证性之类 的设计原则实现上述特征。
6.4.4.7 在安全分析或系统架构设计过程中新识别的尚未被安全目标涵盖的危害，应更新到按照 GB/T
34590.3 定义的危害分析和风险评估（HARA）中。
注：安全目标尚未涵盖的危害可能是非功能性危害。非功能性危害不在GB/T 34590的范围内，但可在危害分析和风 险评估中增加注释；例如，通过增加“此危害中未指定ASIL等级，因为它不在GB/T 34590的范围内”的注释进行 说明。
6.4.5 运行过程中随机硬件失效的控制措施
6.4.5.1 应按照 6.4.3 中的系统架构设计，定义探测、控制或减轻随机硬件失效的措施。
示例1：这些措施可能是硬件的诊断特性，通过软件对其的使用来探测随机硬件失效。 示例2：随机硬件失效发生时，不需要探测即可进入安全状态的硬件设计（即，失效-安全的硬件设计）。 注：6.4.4.1中归纳和演绎分析的量化估计有助于确定是否需要采取进一步的安全措施。可按照GB/T 34590.5
进行硬件分析，并做出决定。
6.4.5.2 本要求适用于等级为 ASIL(B)、C 和 D 的安全目标。应选择可替代流程中的一个，用于评估随 机硬件失效导致的对安全目标的违背 (见 GB/T 34590.5，第 9 章)，并应定义目标值以用于相关 项层面的最终评估。
6.4.5.3 本要求适用于等级为 ASIL(B)、C 和 D 的安全目标。适当的失效率和诊断覆盖率的目标值宜在 要素层面进行定义，以符合：
a) GB/T 34590.5,第 8 章中度量的目标值；及 b) GB/T 34590.5,第 9 章中的流程。
6.4.5.4 本要求适用于 ASIL(B)、C 和 D 等级。对于分布式开发（见 GB/T 34590.8,第 5 章）， 推导出的目标值应通报给每个相关团队。
注1：GB/T34590.5，第8章和第9章中描述的架构约束，不一定适用于商业现成产品的元器件和组件。这是因为 供应商通常不能预测终端相关项中如何使用他们的产品以及潜在的安全影响。在这种情况下，供应商会提供基 本的数据，例如失效率、失效模式、每种失效模式的失效率分布、内置的诊断等，以便允许在整体硬件架构层 面上预估架构约束。
6.4.6 分配到硬件和软件
6.4.6.1 技术安全要求应分配给以系统、硬件或软件作为实施技术的系统架构设计要素。
注：如果将技术安全要求分配给作为实施技术的系统中，则再次按照GB/T 34590.4进一步开发这些要求，直到能将 他们分配给硬件和软件为止。
6.4.6.2 分配和分区决策应符合系统架构设计。
注：为了实现独立性和避免失效传播，系统架构设计可以采用功能分区和组件分区。
6.4.6.3 每个系统架构设计要素都应继承其实现的技术安全要求的最高的 ASIL 等级。
6.4.6.4 如果系统架构设计要素由指定为不同 ASIL 等级的子要素组成,或由安全相关和非安全相关的 子要素组成，那么每个子要素都应按照最高 ASIL 等级进行处理，除非满足共存标准（按照 GB/T 34590.9- XXXX，第 6 章）。
6.4.6.5 如果技术安全要求分配到具备可编程功能的定制化硬件要素（比如：专用集成芯片（ASICs）、 可编程门阵列（FPGA）或是其他形式的数字化硬件），宜结合 GB/T 34590.5 和 GB/T 34590.6 的要求来 定义和实施适当的开发流程。
注1：如果满足GB/T 34590.8第13章的应用准则，则可以按照该章的评估方法提供证据证明上述硬件要素中的 一些要素满足所分配的安全要求。
注2：GB/T 34590.11 提供了相应指导。
6.4.7 软硬件接口(HSI)规范
6.4.7.1 HSI 规范应定义硬件和软件的交互，并保持与技术安全概念一致。HSI 规范应包括组件中由软 件控制的硬件元器件以及支持软件运行的硬件资源。
注：软硬件接口（HSI）中详细描述的方面和特性见附录B。
6.4.7.2 软硬件接口（HSI）规范应包含下列特性： a) 硬件设备的相关运行模式和相关配置参数；
示例1：硬件设备的运行模式，例如：默认模式、初始化模式、测试模式或者高级模式。 示例2：配置参数，例如：增益控制、带通频率或时钟分频。
b) 确保要素间独立性或支持软件分区的硬件特征； c) 硬件资源的共用和专用； 示例3：内存映射、寄存器分配、计时器、中断、I/O 端口。 d) 硬件设备的访问机制；及 示例4：串、并、从、主/从。
e) 由技术安全概念得出的时间约束。
6.4.7.3 硬件的相关诊断能力和软件对其的使用应在软硬件接口（HSI）规范中定义： a) 应定义硬件的诊断特性；及
示例：过流、短路或过温的探测。
b) 应定义需要在软件中实现的对硬件的诊断特性。
6.4.7.4 应在系统架构设计过程中对软硬件接口（HSI）进行定义。
注：在硬件开发（见GB/T 34590.5第6章）和软件开发（见GB/T 34590.6第6章）过程中对软硬件接口（HSI） 进行细化。
6.4.8 生产、运行、服务和报废
6.4.8.1 应定义在系统架构设计过程中识别出的 GB/T 34590.7 中对生产、运行、服务和报废的 要求。这些包括：
a) 在生产、服务或报废期间达到、保持或修复相关项及其要素的安全相关功能和特性所需的措施； b) 安全相关的特殊特性；
c) 确保正确识别系统或要素的要求； d) 生产的验证措施；
e) 包含诊断数据及服务记录的服务要求；及 f) 报废措施。
示例：组装或拆卸指南、服务记录、关于系统要素允许维修的指南、报废指南、要素标签。 注：确保生产、运行、服务和报废期间的功能安全主要包含两方面。第一个方面涉及那些在开发阶段中确保充分的
系统架构设计和对合适的安全相关的特殊特性的定义而开展的活动，这些活动在要求6.4.8.1中给出，第二方 面涉及确保在生产和运行阶段实现或维持功能安全的活动（例如：基于特定的与安全相关的特殊特性），这些 活动在GB/T 34590.7中进行了阐述。
6.4.8.2 在考虑了安全分析的结果和所实施的安全机制的情况下，应定义需具备的诊断特性，以提供 按照 GB/T 34590.2,第 7 章对相关项或其要素进行现场监控所需的数据。
6.4.8.3 为了修复或保持功能安全，应定义诊断特性以便服务时能够识别故障并对维护或修复的有效 性进行检查。
6.4.9 验证
6.4.9.1 应按照 GB/T 34590.8，第 6 章和第 9 章对技术安全要求进行验证，以提供其在给定系 统边界条件下的正确性、完整性和一致性的证据。
6.4.9.2 应使用表 2 所列的验证方法对系统架构设计，软硬件接口（HSI）规范以及生产、运行、服务 和报废的要求规范以及技术安全概念进行验证，以提供证据表明实现以下目标：
a) 它们适合并足以达到按照相关 ASIL 等级所要求的功能安全水平； b) 系统架构设计与技术安全概念的一致性；及
c) 先前开发步骤中系统架构设计的有效性和符合性。
注：识别出的安全异常和不完备性将按照GB/T 34590.2,5.4.3进行报告。
工作成果
6.5.1 技术安全需求规范，由 6.4.1 和 6.4.2 的要求得出。
6.5.2 技术安全概念，由 6.4.3～6.4.6 的要求得出。
6.5.3 系统架构设计规范，由 6.4.3～6.4.6 的要求得出。
6.5.4 软硬件接口(HSI)规范，由 6.4.7 的要求得出。
6.5.5 生产、运行、服务和报废需求规范，由 6.4.8 的要求得出。
6.5.6 针对系统架构设计、软硬件接口（HSI）规范、生产、运行、服务和报废需求规范及技术安全概
念的验证报告，由 6.4.9 的要求得出。
6.5.7 安全分析报告，由 6.4.4 的要求得出。
7 系统及相关项的集成和测试
目的
集成和测试阶段包括三个子阶段和三个目标，如下所述。第一个子阶段是各要素硬件和软件的集成； 第二个子阶段是组成一个系统的要素的集成，以形成一个完整的相关项；第三个子阶段是相关项与车辆 内其他系统的集成。本章的目的是：
a) 定义集成步骤并集成系统要素，直到系统完全集成；
b) 验证由系统架构层级安全分析定义的安全措施是否得到正确实施；及 c) 提供证据表明所集成的系统要素满足按照系统架构设计的安全要求。
总则
相关项要素的集成按照系统化的方法进行，从软硬件集成和验证开始，经过系统集成和验证，到整 车集成和验证。在每个集成阶段要进行特定的集成测试，以提供证据证明所集成的要素之间正确地交互。
在按照GB/T 34590.5和GB/T 34590.6对硬件和软件进行充分开发后，可按照本章启动系统集成。
本章的输入
7.3.1 前提条件
应具备下列信息:
——危害分析和风险评估报告中得出的安全目标和接受准则，按照 GB/T 34590.3,6.5.1;
——功能安全概念，按照 GB/T 34590.3，8,7.5.1;
——技术安全概念，按照 6.5.2;
——架构设计规范，按照 6.5.3;及
——软硬件接口（HSI）规范，按照 6.5.4、GB/T 34590.5,6.5.2 和 GB/T 34590.6- XXXX,6.5.2。
7.3.2 支持信息
可考虑下列信息:
——整车架构(来自外部);
——整车其他系统的技术安全概念(来自外部);及
——安全分析报告(见 6.5.7)。
要求和建议
7.4.1 集成和测试策略规范
7.4.1.1 为了提供证据证明系统架构设计符合功能安全和技术安全要求，应按照 GB/T34590.8，
第 9 章进行集成测试活动，以检查:
a) 功能安全及技术安全要求的正确实施;
b) 安全机制正确的功能性能、准确性和时序; c) 接口的一致性和正确实施；及
d) 足够的鲁棒性。
7.4.1.2 应考虑系统架构设计规范、功能安全概念和技术安全概念，定义集成和测试策略，其应该述 及：
a) 适合提供功能安全证据的测试目标；及
b) 相关项及该相关项中有助于安全概念的要素的集成和测试；
注：这包括有助于安全概念的其他技术要素。
7.4.1.3 为使相关项集成子阶段能够进行，应根据集成和测试策略执行以下内容： a) 应为软硬件集成和测试定义相关项集成和测试策略；
b) 相关项集成和测试策略的定义应包括系统和整车层面的集成测试规范。应确保来自于软硬件 验证的未解决问题得到处理；
c) 相关项集成和测试策略应考虑车辆系统（相关项内部和外部）与环境之间的接口；及
d) 相关项集成和测试策略应考虑被集成的系统或要素是否是作为独立于环境的安全要素（SEooC） 进行开发，以及开发期间所做的假设是否需要验证。
注：在软硬件集成层面和相关项层面进行集成与验证的规范，要考虑软硬件之间的接口及其交互。
7.4.1.4 如果系统是可配置的（如通过要素的变量或标定数据），在系统或整车层面的验证应提供证 据证明用于量产实施层面的配置符合安全要求
注：测试一个合适的配置子集可能是足够的。
7.4.1.5 在整个集成子阶段，对每个功能安全和技术安全要求是否得到了满足，应至少进行一次验证
（如果适用，通过测试来验证）。
注1：一个常规的做法是在更高一级的集成层面上对已定义的安全要求进行验证。 注2：当一个SEooC集成到一个安全相关系统中，其开发中使用的假设的有效性需要进行验证。 注3：集成测试期间识别出的安全异常要按照GB/T34590.2,5.4.3的要求进行报告。
7.4.1.6 为了恰当的定义集成测试的测试用例，应考虑集成的层面，使用表 3 中所列的恰当的方法组 合导出测试用例。
现成译文，到款即发。
任取样页验证译文质量。
提供正规增值税电子发票。
请联系手机/微信: 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.