GB/T 34590.5-2022Road vehicles - Functional safety - Part 5: Product development at the hardware 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.5-2017 "Road vehicles - Functional safety - Part 5.

Product development at the hardware level". Compared with GB/T 34590.5-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 Clause 1 of this Edition, Clause

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 title of Clause 5 (see Clause 5 of this Edition, Clause 5 of Edition 2017);

- Change the description about the purpose (see 5.1 of this Edition, 5.1 of Edition 2017);

- Change Figure 2 (see 5.2 of this Edition, 5.2 of Edition 2017);

- Delete the content in 5.3, 5.4, and 5.5 about "inputs, requirements and suggestions, and

work products of this Clause" (see Annex D of Edition 2017);

- Delete "safety plan (refined)" (see 6.3.1 of Edition 2017);

- Add hardware specification (from outside) (see 6.3.2 of this Edition);

- Change the description about the purpose (see 7.1 of this Edition, 7.1 of Edition 2017);

- Delete the safety plan (refined) (see 7.3.1 of Edition 2017);

- Add non-safety-related hardware requirements specification (from outside) (see 7.3.2 of

this Edition);

- Change Table 1 from "modular hardware design principles" to "hardware architecture

design principles" (see 7.4.1.6 of this Edition, 7.4.1.6 of Edition 2017);

- Add requirements for noise factors (see 7.4.1.7 of this Edition);

- Add requirements for ASIL (A) (see 7.4.3.3 of this Edition);

- Add requirements for ASIL (A) (see 7.4.3.4 of this Edition);

- Add the content about "provide evidence according to the hardware design verification

methods listed in Table 3" (see 7.4.4.1 of this Edition);

- Add the requirement to verify the validity of assumptions of SEooC (see 7.4.4.3 of this

Edition);

- Add requirements for the production, operation, service and scrapping of hardware

elements generated during the hardware design process (see 7.4.5.5 of this Edition);

- Add the requirements for "additional safety mechanisms" in items a) and b) (see 8.4.4 of

this Edition);

- Add examples of formulas related to SPFM target values (see 8.4.7 of this Edition);

- Change the description of the general provisions (see 9.2 of this Edition, 9.2 of Edition

2017);

- Add the content about "ASIL application level of this requirement" (see 9.4.1.1 of this

Edition);

- Add the content of the argument "to prove that the probability of a single point of failure

of a single hardware component is sufficiently low" (see 9.4.1.2 of this Edition);

- Add the content of the argument "to prove that the probability of residual failure of a

hardware component is sufficiently low" (see 9.4.1.3 of this Edition);

- Add the requirements for multiple systems constituting related items (see 9.4.2.3 of this

Edition);

- Delete the content about "failure rate combination and scale factor conversion" (see 9.4.2.7

of Edition 2017);

- Add applicable ASIL levels (see 9.4.3.4 of this Edition);

- Delete the content of failure rate conversion (see 9.4.3.12 of Edition 2017);

- Add the requirements for acceptable conditions for double-point failures that may be

caused by double-point failures (see 9.4.3.12 of this Edition);

- Add the content about "conditions leading to possible double-point failure when the

requirements of 9.4.3.11 or 9.4.3.12 cannot be met" (see 9.4.3.13 of this Edition);

- Change the title of Clause 10 (see Clause 10 of this Edition, Clause 10 of Edition 2017);

- Delete the hardware security requirements specification and hardware design specification

(see 10.3.1 of Edition 2017);

- Delete the project plan (refinement) (see 10.3.2 of Edition 2017);

- Add examples and qualification requirements for safety-related hardware components (see

10.4.3 of this Edition);

- Change the title of Table 12 (see 10.4.6, 10.4.6 of Edition 2017);

- Add hardware integration and verification specifications (see 10.5.1 of this Edition);

- Delete the content of "starting product development at the hardware level" (see Clause 5

and Table A.1 of Edition 2017).

The revision of this document adopts ISO 26262-5.2018 "Road vehicles - Functional safety -

Part 5.Product development at the hardware level".

The technical differences between this document and ISO 26262-5.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-

5.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., CRRC Times Electric Vehicle Co., Ltd., Huawei Technologies Co., Ltd.,

Shanghai Hella Electronics Co., Ltd., Nexteer Automotive Systems (Suzhou) Co., Ltd., China

FAW Group Co., Ltd., SAIC Motor Volkswagen Automobile Co., Ltd., Pan Asia Automotive

Technology Center Co., Ltd., Valeo Automotive Internal Control (Shenzhen) Co., Ltd., Hitachi

Anstemo Automotive Electronics (Shanghai) Co., Ltd., Infineon Technologies (China) Co., Ltd.,

SAIC Maxus Automobile Co., Ltd., Shanghai Jinmai Electronic Technology Co., Ltd., BYD

Auto Industry Co., Ltd., Ningde Times New Energy Technology Co., Ltd., United Automotive

Electronics Co., Ltd., Zhixing Automotive Technology (Suzhou) Co., Ltd., Shanghai

Automotive Group Co., Ltd. Technology Center, Zhuzhou CRRC Times Electric Co., Ltd.,

Great Wall Motor Co., Ltd., Yutong Bus Co., Ltd., Schaeffler (China) Co., Ltd., Daimler Greater

China Investment Co., Ltd., BAIC Motor Co., Ltd., Beijing New Energy Automobile Co., Ltd.,

Xingkedi Technology (Taizhou) Co., Ltd., Huizhou Yineng Electronics Co., Ltd., Beijing Huate

Times Electric Vehicle Technology Co., Ltd., Hefei Juyi Power System Co., Ltd., Honeycomb

Energy Technology Co., Ltd., Bosch Auto Parts (Suzhou) Co., Ltd., Beijing Baowo Automobile

Co., Ltd., Beijing Baidu Zhixing Technology Co., Ltd., Lego (Shandong) New Energy

Technology Co., Ltd., Huating (Hefei) Power Technology Co., Ltd., Aiways Automobile

(Shanghai) Co., Ltd., Beijing Jingwei Hengrun Technology Co., Ltd., Vitesco Technology

Investment (China) Co., Ltd., Nanjing Xinchi Semiconductor Technology Co., Ltd., Geely

Automobile Research Institute (Ningbo) Co., Ltd., Suzhou Inovance United Power System Co.,

Ltd., Weichai Power Co., Ltd.

The main drafters of this document. Li Bo, Li Yong, Wei Fang, Luo Yan, Liu Hang, Fu Yue, Yu

Jianye, Shao Haihe, Li Jun, Zhang Lemin, Shang Shiliang, Li Zhenzhen, Yang Hequan, Xu

Huizhong, Li Gang, Zhang Xiang, Mao Xiangyang, Zhou Dongdong, Xiong Zaihui, Zhao

Tianli, Wang Chao, Zhang Chan, Song Weijin, Li Hongbo, Chen Lei, Liu Qinghe, Li Yurui,

Jiang Zhaojuan, Lu Ming, Guo Feifei, Li Dangqing, Qian Qiuhua, Fan Yaoguo, Zhuang Ping,

Zhang Ci, Wang Zhipeng, Li Zhewei, Wang Yali, Bao Wei, Luo Huan, Zhang Aiqin, Wang Yu,

Wang Bin, Huang Yi, Tong Ziqian, Chen Xiaohu, Chen Jiao, Liu Chang, Sun Bo.

Versions of standard substituted by this document are.

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

- This is the first revision.

1 Scope

GB/T 34590.5-2022 is the hardware part of the Chinese adoption of the road vehicle functional safety standard, the framework better known internationally as ISO 26262. Its subject is what happens when electronics that control braking, steering or propulsion fail — not whether they might, but the acceptance that they will, and the requirement to show that failures are detected and handled before they reach the driver. That turns hardware design into an evidential exercise: every component's failure modes are enumerated, the effect of each is traced to whether it can violate a safety goal, and the design must demonstrate quantitatively that dangerous undetected failures are rare enough for the integrity level claimed. The metrics this part defines — single point fault metric, latent fault metric, the probabilistic measure of random hardware failure — are what a certification body actually examines. This part specifies the requirements for product development at the hardware level for automotive applications. Under CCS T35, it is written for automotive electronics suppliers and semiconductor makers, for vehicle manufacturers' safety engineering functions, and for the assessors who audit their work. It is the companion to Part 6 on software.

This document specifies the requirements for product development at the hardware 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

If an ASIL is given in parentheses in GB/T 34590, the corresponding sub-clause shall be

considered as a recommendation rather than a requirement for this ASIL. This has no link with

the parenthesis notation related to ASIL decomposition.

For items or elements of motorcycles for which requirements of GB/T 34590.12-2022 are

applicable, the requirements of GB/T 34590.12-2022 supersede the corresponding requirements

in this document and GB/T 34590.12-2022.

5 General topics for the product development at the hardware level

In contrast to the software development sub-phases, this document contains two clauses

describing quantitative evaluations of the overall hardware architecture of the item.

Clause 8 describes two metrics to evaluate the effectiveness of the hardware architecture of the

item and the implemented safety mechanisms to cope with random hardware failures.

6 Specification of hardware safety requirements

The technical safety requirements are allocated to hardware and software. The requirements

that are allocated to both are further partitioned to yield hardware-only safety requirements.

The hardware safety requirements are further detailed considering design constraints and the

impact of these design constraints on the hardware.

7 Hardware design

Methods 1a and 1b serve as a check of the complete and correct implementation of the

hardware safety requirements in the hardware design. If it is discovered, during hardware design,

that the implementation of any hardware safety requirement is not feasible, a request for change

shall be issued in accordance with the change management process in GB/T 34590.8-2022,

Clause 8.

8 Evaluation of the hardware architectural metrics

The random hardware failures addressed by these metrics are limited to some of the item's

safety related electrical and electronic hardware parts, namely those that can significantly

contribute to the violation or the achievement of the safety goal, and to the single-point, residual,

and latent faults of those parts.

9 Evaluation of safety goal violations due to random hardware failures

The requirements for the second method are given in 9.4.3.The "Evaluation of Each Cause of

safety goal violation" (EEC) is based on the individual evaluation of each hardware part and its

contribution to the violation of the considered safety goal with respect to residual, single-point

and plausible dual-point failures.

......