GB/T 34590.6-2022 PDF in English
GB/T 34590.6-2022 (GB/T34590.6-2022, GBT 34590.6-2022, GBT34590.6-2022)
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| GB/T 34590.6-2022 | English | 695 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Road vehicles -- Functional safety -- Part 6: Product development at the software level
| Valid |
| GB/T 34590.6-2017 | English | 345 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Road vehicles -- Functional safety -- Part 6: Product development at the software level
| Obsolete |
Standards related to (historical): GB/T 34590.6-2022
PDF Preview
GB/T 34590.6-2022: PDF in English (GBT 34590.6-2022) GB/T 34590.6-2022
GB
NATIONAL STANDARD OF THE
PEOPLE’S REPUBLIC OF CHINA
ICS 43.040
CCS T 35
Replacing GB/T 34590.6-2017
Road Vehicles - Functional Safety - Part 6: Product
development at the software level
(ISO 26262-6:2018, MOD)
ISSUED ON: DECEMBER 30, 2022
IMPLEMENTED ON: JULY 1, 2023
Issued by: State Administration for Market Regulation;
Standardization Administration of the People’s Republic of China.
Table of Contents
Foreword ... 4
Introduction ... 9
1 Scope ... 13
2 Normative references ... 14
3 Terms and definitions ... 15
4 Requirements for compliance ... 15
4.1 Purpose... 15
4.2 General requirements ... 15
4.3 Interpretations of tables ... 16
4.4 ASIL-dependent requirements and recommendations ... 17
4.5 Adaptation for motorcycles ... 17
4.6 Adaptation for cargo trucks, buses, special vehicles, trailers ... 17
5 General topics for the product development at the software level ... 17
5.1 Objectives ... 17
5.2 General ... 18
5.3 Inputs to this clause ... 19
5.4 Requirements and recommendations ... 19
5.5 Work products ... 21
6 Specification of software safety requirements ... 21
6.1 Objectives ... 21
6.2 General ... 22
6.3 Inputs to this clause ... 22
6.4 Requirements and recommendations ... 22
6.5 Work products ... 24
7 Software architectural design ... 25
7.1 Objectives ... 25
7.2 General ... 25
7.3 Inputs to this clause ... 25
7.4 Requirements and recommendations ... 26
7.5 Work products ... 33
8 Software unit design and implementation ... 33
8.1 Objectives ... 33
8.2 General ... 33
8.3 Inputs to this clause ... 34
8.4 Requirements and recommendations ... 34
8.5 Work products ... 36
9 Software unit verification ... 37
9.1 Objectives ... 37
9.2 General ... 37
9.3 Inputs to this clause ... 37
9.4 Requirements and recommendations ... 38
9.5 Work products ... 41
10 Software integration and verification ... 41
10.1 Objectives ... 41
10.2 General ... 42
10.3 Inputs to this clause ... 42
10.4 Requirements and recommendations ... 43
10.5 Work products ... 46
11 Testing of the embedded software ... 46
11.1 Objective ... 46
11.2 General ... 46
11.3 Inputs to this clause ... 47
11.4 Requirements and recommendations ... 47
11.5 Work products ... 49
Annex A (informative) Overview of and workflow of management of product ... 50
development at the software level ... 50
Annex B (informative) Model-based development approaches ... 53
Annex C (normative) Software configuration ... 59
Annex D (informative) Freedom from interference between software elements ... 65
Annex E (informative) Application of safety analyses and analyses of dependent failures
at the software architectural level ... 68
Bibliography ... 78
Foreword
This document was drafted in accordance with the rules provided in GB/T 1.1-2020 Directives
for Standardization - Part 1: Rules for the Structure and Drafting of Standardizing Documents.
This document is Part 5 of GB/T 34590 Road Vehicles - Functional Safety. GB/T 34590 has
issued the following parts:
-- Part 1: Vocabulary;
-- Part 2: Management of Functional Safety;
-- Part 3: Concept Phase;
-- Part 4: Product Development at the System Level;
-- Part 5: Product Development at the Hardware Level;
-- Part 6: Product Development at the Software Level;
-- Part 7: Production, Operation, Service and Decommissioning;
-- Part 8: Supporting Processes;
-- Part 9: Automotive Safety Integrity Level (ASIL)-oriented and Safety-oriented Analyses;
-- Part 10: Guideline;
-- Part 11: Guidelines on Applications to Semiconductors;
-- Part 12: Adaptation for Motorcycles.
This document replaces GB/T 34590.6-2017 "Road vehicles - Functional safety - Part 6:
Product development at the software level". Compared with GB/T 34590.6-2017, the main
technical changes in this document are as follows:
- Change the scope of application of the standard from "mass-produced passenger cars" to
"mass-produced road vehicles other than mopeds" (see Chapter 1 of this Edition, Chapter
1 of Edition 2017);
- Add the suitability requirements for motorcycles (see 4.5 of this Edition);
- Add the applicability requirements for cargo trucks, buses, special vehicles and trailers (see
4.6 of this Edition);
- Change the description of the software development process and development environment
requirements (see 5.4.1 of this Edition, 5.4.1 of Edition 2017);
- Change the relevant requirements for design language, modeling language or programming
language (see 5.4.2 and 5.4.3 of this Edition, 5.4.6 and 5.4.7 of Edition 2017);
- Change the work product (see 5.5 of this Edition, 5.5 of Edition 2017);
- Change the description of software safety requirements (see 6.4 of this Edition, 6.4 of
Edition 2017);
- Change the work product (see 6.5 of this Edition, 6.5 of Edition 2017);
- Change the description requirements for software architecture design, including software
architecture design notation requirements (see 7.4.1 and 7.4.2 of this Edition, 7.4.1 and
7.4.2 of Edition 2017);
- Change the requirements for software architecture characteristics, including software
architecture principles (see 7.4.3 of this Edition, 7.4.3 of Edition 2017);
- Change the description of software static and dynamic design requirements (see 7.4.5 of
this Edition, 7.4.5 of Edition 2017);
- Delete the software component classification and development requirements (see 7.4.6 and
7.4.7 of Edition 2017);
- Change the description of software safety analysis requirements (see 7.4.6 and 7.4.7 of this
Edition, 7.4.8 and 7.4.9 of Edition 2017);
- Change the description of the software architecture design verification method (see 7.4.14
of this Edition, 7.4.18 of Edition 2017);
- Change the work product (see 7.5 of this Edition, 7.5 of Edition 2017);
- Add the requirements for software unit design characteristic (see 8.4.3 of this Edition);
- Change the requirements for software unit design notation (see 8.4.3 of this Edition, 8.4.2
of Edition 2017);
- Change the design principles for software unit design and implementation (see 8.4.4 and
8.4.5 of this Edition, 8.4.3 and 8.4.4 of Edition 2017);
- Delete the requirements and verification methods for software unit design and
implementation verification (see 8.4.5 of Edition 2017);
- Change the work product (see 8.5 of this Edition, 8.5 of Edition 2017);
- Delete the requirements for software unit test plan (see 2017 edition 9.4.2);
- Change the software unit verification requirements, including software unit verification
methods (see 9.4.4 of this Edition, 9.4.5 of Edition 2017);
- Change the work product (see 9.5 of this Edition, 9.5 of Edition 2017);
- Delete the requirements for software integration test plan (see 10.4.2 of Edition 2017);
- Change the requirements for software integration verification, including software
integration verification methods (see 10.4.2 of this Edition, 10.4.3 of Edition 2017);
- Change the description of software integration verification coverage requirements (see
10.4.4 and 10.4.5 of this Edition, 10.4.5 and 10.4.6 of Edition 2017);
- Change the work product (see 10.5 of this Edition, 10.5 of Edition 2017);
- Delete the requirements for software security requirements verification plan (see 11.4.1 of
Edition 2017);
- Change the test environment requirements for software testing (see 11.4.1 of this Edition,
11.4.2 and 11.4.3 of Edition 2017);
- Add the requirements for embedded software testing methods (see 11.4.2 of this Edition);
- Add the method requirements for deriving embedded software test cases (see 11.4.3 of this
Edition);
- Change the work product (see 11.5 of this Edition, 11.5 of Edition 2017);
- Add introduction, general applicability of model-based development methods and potential
impact on software life cycle (see B.2.1, B.2.2, B.2.3 of this Edition);
- Add special considerations for sample software development use cases (see B.3 of this
Edition);
- Change the description of the requirements for software configuration (see Annex C of this
Edition, Annex C of Edition 2017);
- Change the description of requirements to avoid interference between software elements
(see Annex D of this Edition, Annex D of Edition 2017).
The revision of this document adopts ISO 26262-6:2018 "Road vehicles - Functional safety -
Part 6: Product development at the software level".
The technical differences between this document and ISO 26262-6:2018 and their reasons are
as follows:
- Change the description of T&B vehicles from "trucks, buses, trailers and semi-trailers" to
"cargo trucks, buses, special vehicles, trailers" (see 4.6 of this Edition, 4.6 of ISO 26262-
6:2018), to be consistent with the vehicle types specified in GB/T 3730.1-2022 "Terms
and definitions of motor vehicles, trailers and combination vehicle -- Part 1: Types".
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. The issuing authority shall not be held responsible for identifying any
or all such patent rights.
This document was proposed by the Ministry of Industry and Information Technology of the
People's Republic of China.
This document shall be under the jurisdiction of National Technical Committee 114 on Auto of
Standardization Administration of China (SAC/TC 114).
The drafting organizations of this document: China Automotive Technology and Research
Center Co., Ltd., United Automotive Electronics Co., Ltd., Neusoft Reach Automotive
Technology (Shenyang) Co., Ltd., Weilai Automobile (Anhui) Co., Ltd., Huawei Technologies
Co., Ltd., Neusoft Group (Dalian) Co., Ltd., Valeo Automotive Internal Control (Shenzhen) Co.,
Ltd., Bosch Automotive Parts (Suzhou) Co., Ltd., Shanghai Hella Electronics Co., Ltd., Hitachi
Anstemo Automotive Electronics (Shanghai) Co., Ltd., Xingkedi Technology (Taizhou) Co.,
Ltd., Beijing Hua Tedaidai Electric Vehicle Technology Co., Ltd., Suzhou Inovance United
Power System Co., Ltd., Ningde Times New Energy Technology Co., Ltd., SAIC Maxus
Automobile Co., Ltd., Huating (Hefei) Power Technology Co., Ltd., Daimler Greater China
Investment Co., Ltd. Company, Beijing Baowo Automobile Co., Ltd., Hefei Juyi Power System
Co., Ltd., Beijing Baidu Zhixing Technology Co., Ltd., Schaeffler (China) Co., Ltd., BYD Auto
Industry Co., Ltd., SAIC Volkswagen Co., Ltd., Yutong Bus Co., Ltd. Company, Beijing New
Energy Automobile Co., Ltd., Weichai Power Co., Ltd., Nexteer Automotive Systems (Suzhou)
Co., Ltd., Midea Group (Shanghai) Co., Ltd., Beijing Automobile Co., Ltd., Shanghai Weilai
Automobile Co., Ltd., Ai Chi Automobile (Shanghai) Co., Ltd., Zhixing Automotive
Technology (Suzhou) Co., Ltd., Shanghai Jinmai Electronic Technology Co., Ltd., CRRC
Times Electric Vehicle Co., Ltd., ZF Automotive Technology (Shanghai) Co., Ltd., SAIC Motor
Corporation Limited Company Technology Center, Ligao (Shandong) New Energy Technology
Co., Ltd., Honeycomb Energy Technology Co., Ltd., Beijing Horizon Robot Technology
Research and Development Co., Ltd., Youmuyu Information Technology (Shanghai) Co., Ltd.,
China FAW Group Co., Ltd., Great Wall Motors Co., Ltd., Pan Asia Automotive Technology
Center Co., Ltd., Dongfeng Motor Co., Ltd. Dongfeng Nissan Passenger Vehicle Company,
Huizhou Yineng Electronics Co., Ltd., Vitesco Technology Investment (China) Co., Ltd.,
Beijing Jingwei Hengrun Technology Co., Ltd., Geely Automobile Research Institute (Ningbo)
Co., Ltd.
The main drafters of this document: Li Bo, Wang Wenliang, Guo Xiaodong, Ouyang Chaohui,
Fu Yue, Chen Wei, Wei Fang, Gao Jianyong, Liu Xiangchao, Qu Yuanning, Yu Jianye, Xu
Huizhong, Qian Qiuhua, Zhuang Ping, Liu Chang, Han Biao, Shi Ting, Luo Huan , Lu Ming,
Zhao Tianli, Zhang Ci, Huang Jin, Xue Jianbo, Zhang Li, Zhang Lemin, Chen Xin, He
Zhongwei, Wang Jinping, Shao Haihe, Wang Shuangquan, Guo Feifei, Shen Xiaoyong, Zhang
Chan, Zhang Aiqin, Song Weijin, Zhou Dongdong, Li Yong, Li Xinran, Li Hongbo, Bao Wei,
Wang Zhipeng, Yang Hu, Wang Yiqun, Li Haixia, Yan Gang, Shang Shiliang, Wu Yang, Wang
Bin, Fan Yaoguo, Chen Xiaohu, Chen Wei, Li Gang.
Versions of standard substituted by this document are:
Road vehicles - Functional safety - Part 6: Product
development at the software level
1 Scope
This document specifies the requirements for product development at the software level for
automotive applications, including the following:
- general topics for product development at the software level;
- specification of the software safety requirements;
- software architectural design;
- software unit design and implementation;
- software unit verification;
- software integration and verification; and
- testing of the embedded software.
This document specifies the requirements for the use of configurable software.
This document is intended to be applied to safety-related systems that include one or more
electrical and/or electronic (E/E) systems and that are installed in series production road
vehicles, excluding mopeds.
This document does not address unique E/E systems in special vehicles such as E/E systems
designed for drivers with disabilities.
NOTE Other specific safety standards can be used as a supplement to this document, and vice versa.
Systems and their components that have been released for production, or that are in
development as of the publication date of this document, do not apply to this document. When
changes are made to the system and its components that have completed production release
before the release of this document, this document tailors the activities of the safety life cycle
based on these changes. When a system not developed in accordance with this document is
integrated with a system developed in accordance with this document, the safety life cycle needs
to be tailored according to this document.
This document addresses possible hazards caused by malfunctioning behaviour of safety-
related E/E systems, including interaction of these systems. It does not address hazards related
to electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion,
release of energy and similar hazards, unless directly caused by malfunctioning behaviour of
safety-related E/E systems.
This document describes a framework for functional safety to assist the development of safety
related E/E systems. This framework is intended to be used to integrate functional safety
activities into a company-specific development framework. Some requirements have a clear
technical focus to implement functional safety into a product; others address the development
process and can therefore be seen as process requirements in order to demonstrate the capability
of an organization with respect to functional safety.
This document does not address the nominal performance of E/E systems.
Annex A provides an overview on objectives, prerequisites and work products of this document.
2 Normative references
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.
GB/T 34590.1-2022, Road vehicles - Functional safety - Part 1: Vocabulary (ISO 26262-
1:2018, MOD)
NOTE: There is no technical difference between the referenced content of GB/T 34590.1-2022 and
the referenced content of ISO 26262-1:2018.
GB/T 34590.2-2022, Road vehicles - Functional safety - Part 2: Management of functional
safety (ISO 26262-2:2018, MOD)
NOTE: There is no technical difference between the referenced content of GB/T 34590.2-2022 and
the referenced content of ISO 26262-2:2018.
GB/T 34590.3-2022, Road vehicles - Functional safety - Part 3: Concept phase (ISO 26262-
3:2018, MOD)
NOTE: There is no technical difference between the referenced content of GB/T 34590.3-2022 and
the referenced content of ISO 26262-3:2018.
GB/T 34590.4-2022, Road vehicles - Functional safety - Part 4: Product development at the
system level (ISO 26262-4:2018, MOD)
NOTE: There is no technical difference between the referenced content of GB/T 34590.4-2022 and
the referenced content of ISO 26262-4:2018.
GB/T 34590.5-2022, Road vehicles - Functional safety - Part 5: Product development at the
hardware level (ISO 26262-5:2018, MOD)
NOTE: There is no technical difference between the referenced content of GB/T 34590.5-2022 and
the referenced content of ISO 26262-5:2018.
GB/T 34590.7-2022, Road vehicles - Functional safety - Part 7: Production, operation,
service and decommissioning (ISO 26262-7:2018, MOD)
NOTE: There is no technical difference between the referenced content of GB/T 34590.7-2022 and
the referenced content of ISO 26262-7:2018.
GB/T 34590.8-2022, Road vehicles - Functional safety - Part 8: Supporting processes (ISO
26262-8:2018, MOD)
NOTE: There is no technical difference between the referenced content of GB/T 34590.8-2022 and
the referenced content of ISO 26262-8:2018.
GB/T 34590.9-2022, Road vehicles - Functional safety - Part 9: Automotive safety integrity
level (ASIL)-oriented and safety-oriented analyses (ISO 26262-9:2018, MOD)
NOTE: There is no technical difference between the referenced content of GB/T 34590.9-2022 and
the referenced content of ISO 26262-9:2018.
3 Terms and definitions
For the purposes of this document, the terms and definitions defined in GB/T 34590.1-2022
apply.
4 Requirements for compliance
4.1 Purpose
This clause describes how:
a) to achieve compliance with GB/T 34590;
b) to interpret the tables used in GB/T 34590; and
c) to interpret the applicability of each clause, depending on the relevant ASIL(s).
4.2 General requirements
When claiming compliance with GB/T 34590, each requirement shall be met, unless one of the
following applies:
a) tailoring of the safety activities in accordance with GB/T 34590.2-2022 has been
performed that shows that the requirement does not apply; or
functions and properties as required by the respective ASIL;
NOTE 1 Safety-related properties include independence and freedom from interference requirements.
- identify or confirm the safety-related parts of the software; and
- support the specification and verify the effectiveness of the safety measures.
NOTE 2 Safety measures include safety mechanisms that have been derived from safety-oriented
analyses and can cover issues associated with random hardware failures as well as software faults.
NOTE 3 See Annex E for additional information about the application of safety-oriented analysis at
the software architectural level and the selection of appropriate safety measures.
7.4.11 If the implementation of software safety requirements relies on freedom from
interference or sufficient independence between software components, dependent failures and
their effects shall be analysed in accordance with GB/T 34590.9-2022, Clause 7.
NOTE See Annex E and GB/T 34590.9-2022, Annex C for additional information about the application
of analyses of dependent failures at the software architectural level.
7.4.12 Depending on the results of the safety-oriented analyses at the software architectural
level (in accordance with 7.4.10 or 7.4.11), safety mechanisms for error detection and error
handling shall be applied.
NOTE 1 Annex E provides guidance for deciding if safety mechanisms are required for a failure mode.
NOTE 2 Safety mechanisms for error detection can include:
- Range checks of input and output data;
- Plausibility check (e.g. using a reference model of the desired behaviour, assertion checks, or
comparing signals from different sources);
- Detection of data errors (e.g., error detecting codes and multiple data storage);
- Monitoring of program execution by an external element such as an ASIC or another software
element performing a watchdog function. Monitoring can be logical or temporal monitoring or
both;
- Temporal monitoring of program execution;
- Diverse redundancy in the design; or
- Access violation control mechanisms implemented in software or hardware concerned with granting
or denying access to safety-related shared resources.
NOTE 3 Safety mechanisms for error handling can include:
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|