GB/T 34590.6-2022Road vehicles - Functional safety - Part 6: Product development at the software level (English PDF)

Foreword

This document was issued on 30 December 2022 by the State Administration for Market Regulation; Standardization Administration of the PRC and takes effect on 1 July 2023.

It is a GB/T standard: recommended rather than compulsory, but it is the text a Chinese reviewer applies when assessing a submission.

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.

- GB/T 34590.6-2017 that was issued in 2017 of the first time.

- This is the first revision.

1 Scope

GB/T 34590.6-2022 is the software part of the road vehicle functional safety framework. Software fails differently from hardware: it does not wear out and has no random failure rate, so the probabilistic argument used for hardware is unavailable and the entire case rests on the rigour of the development process. That is why this part reads as a set of obligations on how work is done rather than on what is built — architectural design that keeps safety-related software separable from the rest, coding rules that exclude constructs whose behaviour is not fully determined, unit design and verification, and testing whose adequacy is demonstrated by coverage criteria that get stricter as the integrity level rises. It is also the part that governs software developed elsewhere, which now includes the operating systems, communication stacks and machine learning components that no vehicle manufacturer writes itself. This part specifies the requirements for product development at the software level for automotive applications. Under CCS T35, it is written for automotive software suppliers and vehicle manufacturers' software organisations, for tool vendors whose tools must themselves be qualified, and for functional safety assessors. It is the companion to Part 5 on hardware.

This document specifies the requirements for product development at the software level for

automotive applications, including the following.

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.

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

Tables are normative or informative depending on their context. The different methods listed in

a table contribute to the level of confidence in achieving compliance with the corresponding

requirement. Each method in a table is either.

5 General topics for the product development at the software level

The reference phase model for the development of software is given in Figure 2.Details

concerning the treatment of configurable software are provided in Annex C.

6 Specification of software safety requirements

The hardware-software interface specification initiated in GB/T 34590.4-2022, Clause 6,

shall be refined sufficiently to allow for the correct control and usage of the hardware by the

software, and shall describe each safety-related dependency between hardware and software.

7 Software architectural design

The software architectural design represents the software architectural elements and their

interactions in a hierarchical structure. Static aspects, such as interfaces between the software

components, as well as dynamic aspects, such as process sequences and timing behaviour, are

described.

8 Software unit design and implementation

Based on the software architectural design, the detailed design of the software units is

developed. The detailed design can be represented in the form of a model.

9 Software unit verification

The software unit design and the implemented software units are verified by using an

appropriate combination of verification measures such as reviews, analyses and testing.

In order to verify a single software unit design, both software safety requirements and all non-

safety related requirements are considered. Hence in this sub-phase safety-related and non-

safety-related requirements are handled within one development process.

......