GB/T 34590.6-2022英文版翻译English 道路车辆功能安全第6部分:产品开发:软件层面

ChinaAutoRegs|GB/T 34590.6-2022英文版翻译English 道路车辆功能安全第6部分:产品开发:软件层面(英语版)
Road Vehicles—Functional Safety—Part 6: Product development at the software level

GB/T 34590.6-2022英文版翻译English 道路车辆功能安全第6部分:产品开发:软件层面

CONTENTS

Foreword
Introduction
1 Scope
2 Normative References
3 Terms and Definitions
4 Requirements
5 General topics for the product development at the software level
6 Specification of software safety requirements
7 Software architectural design
8 Software unit design and implementation
9 Software unit verification
10 Software integration and verification
11 Testing of the embedded software
Annex A (Informative) Overview of and workflow of management of product development at the software level
Annex B (Informative) Model-based development approaches
Annex C (Normative) Software configuration
Annex D (Informative) Freedom from interference between software elements
Annex E (Informative) Application of safety analyses and analyses of dependent failures at the software architectural level
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.4 , 道 路 车 辆 功 能 安 全 第 4 部 分 : 产 品 开 发 : 系 统 层 面 (ISO 26262-4:2018,MOD)
GB/T 34590.5 , 道 路 车 辆 功 能 安 全 第 5 部 分 : 产 品 开 发 : 硬 件 层 面 (ISO 26262-5: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 要求
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 XXXXX.12的要求替代本 文件和GB/T XXXXX.2的相应要求。
4.6 卡车、客车、挂车和半挂车的适用性
对卡车、客车、挂车和半挂车的特殊规定以(T&B)来表示。

5 软件层面产品开发概述
5.1 目的
本章的目的是:
a) 确保合适且一致的软件开发流程;及
b) 确保合适的软件开发环境。
5.2 总则
图2给出了软件开发阶段的参考模型。附录C中提供了可配置软件处理的详细信息。
注:图中 GB/T 34590 每部分的特定章用以下方式标示:“m-n”,“m”代表部分号,“n”代表章 号,例如,“4-7”代表 GB/T 34590.4 的第 7 章。
图 2 软件层面产品开发阶段参考模型
注1:敏捷软件开发的方式和方法也可以适用于安全相关软件的开发,但是如果安全活动按照该方式 剪裁,应该考虑GB/T 34590.2,6.4.5。然而,敏捷方式和方法的使用不能省略安全措施 或忽略实现功能安全所必需的基本文档、流程或严格的产品安全完整性要求。
示例1:由测试驱动的开发可用于提高要求的质量和可测试性。 示例2:基于自动化构建系统的持续集成可以支持各个子阶段的一致性并促进回归测试。这种构建系
统通常执行代码生成、编译和链接、静态代码分析、文档生成、测试和打包。根据工具链和 工具配置,该系统允许重复生成以及在变更后生成可比较的软件、文档和测试结果。
注2:开发特定相关项的嵌入式软件时,也可以考虑信息安全,见GB/T 34590.2,5.4.2.3。为 了能够开发软件,本章中讨论了关于要使用的建模、设计和/或编程语言以及指南和工具应用的 特定主题。
注3:用于软件开发的工具,包括软件工具以外的工具。 示例3:测试阶段使用的工具。
5.3 本章的输入
5.3.1 前提条件
无。
5.3.2 支持信息
可考虑下列信息:
——经鉴定合格的软件工具(见 GB/T 34590.8,第 11 章);
——用于建模、设计和编程语言的设计和编码指南(来自外部);
——方法应用的指南(来自外部);及
——工具应用的指南(来自外部)。 5.4 要求和建议
5.4.1 在开发相关项的软件时,使用的软件开发过程和软件开发环境应:
a) 适用于开发安全相关的嵌入式软件,包括方法、指南、语言和工具;
b) 支持软件开发生命周期中的各跨子阶段和各自工作成果的一致性;及
c) 与系统和硬件开发阶段在所需的交互和信息交换的一致性方面兼容。
注1:相关项软件开发的阶段、任务和活动的排序,包括迭代步骤,目的是为了确保相应的工作成果 与硬件层面的产品开发(本文件GB/T 34590.5)和系统层面的产品开发(本文件GB/T 34590.4) 保持一致。
注2:软件工具准则评估报告(本文件GB/T 34590.8,11.5.1)或软件工具的鉴定报告(本文件 GB/T 34590.8,11.5.2)可以为工具的使用提供输入。
5.4.2 当选择一种设计语言、建模语言或编程语言时,应考虑准则:
a) 明确易理解的定义; 示例:语法和语义的明确定义或对开发环境配置的限制。
b) 如果建模用于需求工程和管理,定义和管理安全要求(按照 GB/T 34590.2 第 8 章)的适用性;
c) 支持模块化、抽象化和封装化的实现;及
d) 支持结构化构造的使用。
注:汇编语言能用于那些不适合使用高级编程语言的软件部分,如与硬件接口的底层软件、中断处理 程序、或对时间敏感的算法。然而,使用汇编语言可能需要对所有软件开发阶段进行适当的应用 或剪裁(例如,第 8 章的要求)。
5.4.3 考虑到表 1 中列出的主题,相应的指南或者开发环境应涵盖适合于建模、设计或者 编程语言(见 5.4.2)的准则,并且这些准则并不完全由语言自身决定。
示例 1:MISRA C(见参考文献[3])是编程 C 语言的编码指南,并包括自动生成代码的指南。
示例 2:在具有自动代码生成功能的基于模型的开发中,可以在模型层面以及代码层面中应用该准则。 可以考虑适当的建模风格指南,包括 MISRA AC 系列。商业工具的风格指南也可作为可能的 指南。
注:可以为特定的相关项开发修改现有的编码指南和建模指南。
5.5 工作成果
5.5.1 软件开发环境文档,由 5.4.1~5.4.3 和 C.4.1~C.4.11 的要求得出。
6 软件安全要求的定义
6.1 目的
该子阶段的目的是:
a) 定义或细化由技术安全概念和系统架构设计规范导出的软件安全要求; b) 定义软件实现所需的安全相关功能和特性;
c) 细化在 GB/T 34590.4 第 6 章最初定义的软硬件接口要求;及
d) 验证软件安全要求和软硬件接口要求是否适用于软件开发,及验证它们与技术安全 概念和系统架构设计规范的一致性。
6.2 总则
在GB/T 34590.4,第6章定义的系统架构设计阶段中,技术安全要求被细化并分配 给硬件和软件。软件安全要求的定义特别考虑硬件约束及其对软件的影响。该子阶段包括软 件安全要求的定义,以支持后续设计阶段。
6.3 本章的输入
6.3.1 前提条件
应具备下列信息:
——技术安全要求规范,按照 GB/T 34590.4,6.5.1;
——技术安全概念,按照 GB/T 34590.4,6.5.2;
——系统架构设计规范,按照 GB/T 34590.4,6.5.3;
——软硬件接口规范,按照 GB/T 34590.4,6.5.4;及
——软件开发环境文档,按照 5.5.1。
6.3.2 支持信息
可考虑下列信息:
——硬件设计规范(见 GB/T 34590.5,7.5.1);及
——软件非安全相关功能和特性的定义(来自外部)。
6.4 要求和建议
6.4.1 软件安全要求得出时,应考虑所需的安全相关的软件功能和特性,其失效可能违背 分配给软件的技术安全要求。
注 1:软件安全要求或者直接来源于分配给软件的技术安全要求,或者是对软件功能和特性的要求(这 些要求如果不满足可能违背分配给软件的技术安全要求)。
示例 1:软件安全相关功能可以是:
——使标称功能可以安全执行的功能;
——使系统达到或维持安全状态或降级状态的功能;
——与安全相关硬件要素故障探测、指示和减轻相关的功能;
——与操作系统、基础软件或应用软件本身失效探测、指示和减轻有关的自检或监控功能;
——在生产、运行、服务和报废过程中与车载测试和非车载测试相关的功能;
——允许在生产和服务过程中对软件进行修改的功能;或
——与性能或对时间敏感的操作相关的功能。
示例 2:安全相关的特殊特性包括对错误输入的鲁棒性、不同功能之间的独立性或免于干扰、或软件 的容错能力。
注 2:安全导向分析(本文件 7.4.10 或 7.4.11)可用于识别额外的软件安全要求或为其实现提供证据。
6.4.2 软件安全要求的定义应按照 GB/T 34590.4,6.4.1 和 6.4.3 的技术安全要求、 技术安全概念和系统架构设计得出,并应考虑如下内容:
a) 安全要求的定义和管理,按照 GB/T 34590.8,第 6 章;
b) 已定义的系统和硬件的配置;
示例 1:配置参数可包括增益控制、带通频率和时钟分频。
c) 软硬件接口规范;
d) 硬件设计规范的相关要求;
e) 时间约束;
f) 示例 2:由系统层面要求的响应时间得出执行或反应时间。
g) 外部接口;及
示例 3:通讯和用户接口。
h) 对软件有影响的车辆、系统或者硬件的每个运行模式以及运行模式之间的转换。
示例 4:运行模式包括下电或休眠、初始化、正常运行、降级和用于测试或刷新的其他高级模式。
6.4.3 如果对软件安全要求进行了 ASIL 等级分解,应满足 GB/T 34590.9,第 5 章的 要求。
6.4.4 在 GB/T 34590.4 第 6 章初步定义的软硬件接口规范,应细化到可以通过软件 正确控制和使用硬件的程度,并应描述硬件和软件间每个与安全相关的依赖性。
6.4.5 如果嵌入式软件除了执行 6.4.1 定义的安全要求的功能外,还执行了其他功能,则 应按照所应用的质量管理体系的要求提供这些功能及其特性的规范。
6.4.6 应由负责系统开发、硬件开发和软件开发的人员共同验证细化后的软硬件接口规范。
6.4.7 应按照 GB/T 34590.8 第 6 章和第 9 章的要求,对软件安全要求和细化后的软 硬件接口规范进行验证,以提供证据证明:
a) 软件开发的适用性;
b) 与技术安全要求的符合性和一致性;
c) 与系统设计的符合性;及
d) 与软硬件接口的一致性。
6.5 工作成果
6.5.1 软件安全需求规范,由 6.4.1~6.4.3 和 6.4.5 的要求得出。
6.5.2 软硬件接口规范(细化的),由 6.4.4 的要求得出。
注:该工作成果参照 GB/T 34590.5,6.5.2 相同的工作成果。
6.5.3 软件验证报告,由 6.4.6 和 6.4.7 的要求得出。
7 软件架构设计
7.1 目的
该子阶段的目的是:
a) 开发满足软件安全要求和其他软件要求的软件架构设计;
b) 验证软件架构设计适合满足所要求 ASIL 等级的软件安全要求;及
c) 支持软件的实现与验证。
7.2 总则
软件架构设计以层次结构的形式表示软件架构要素以及他们的交互方式。描述了静态方 面,如软件组件之间的接口、和动态方面,如进程序列和时序行为。
注:软件架构设计并不一定局限于某个微控制器或 ECU。每个微控制器的软件架构也在此子条中论述。
软件架构设计既能满足软件安全要求,又能满足其他软件要求。因此,在该子阶段中, 与安全相关和非安全相关的软件要求在同一个开发过程中处理。
软件架构设计提供了实现软件要求和 ASIL 等级所需的软件安全要求的方法,也提供了 管理软件详细设计和实现复杂度的方法。
7.3 本章输入
7.3.1 前提条件
应具备下列信息:
——软件开发环境文档,按照 5.5.1;
——软硬件接口规范(细化的),按照 6.5.2;及
——软件安全需求规范,按照 6.5.1。
7.3.2 支持信息
可考虑下列信息:
——技术安全概念(见 GB/T 34590.4,6.5.2);
——系统架构设计规范(见 GB/T 34590.4,6.5.3);
——可用的经鉴定合格的软件组件(见 GB/T 34590.8,第 12 章);及
——软件非安全相关功能和特性的定义以及其他软件要求的定义,按照 6.4.5(来自外 部)。
7.4 要求和建议
7.4.1 为避免软件架构设计和后续开发活动中的系统性故障,软件架构设计的描述应满足
表 2 中列出的软件架构设计标记法所支持的特征:
a) 可理解性;
b) 一致性;
c) 简单性;
d) 可验证性;
e) 模块化;
f) 抽象性;
注:抽象性可以通过使用层次化结构、分组方案或视图来支持,以涵盖架构设计的静态、动态或 部署方面。
g) 封装性;及
h) 可维护性。


现成译文,到款即发。
任取样页验证译文质量。
提供正规增值税电子发票。
请联系手机/微信: 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.

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注