GB/T 46958-2025Road vehicles - Test scenarios for automated driving systems - Scenario based safety evaluation framework (English PDF)

4.1 Application of this process in the overall development process

4.1.1 Purpose

The purpose of 4.1 is to achieve the following objectives.

The system-based approach (Task 1.2) starts with the system itself. This document focuses on the scenario-based approach (Task 1.1), which starts with the scenario space related to system functionality, identifying risk factors by analyzing the relevant scenario space. This document only considers general physical limitations of the system, such as the sensing range of sensors based on the physical characteristics of the sensing system. This document does not address specific system implementation issues, such as machine learning algorithms failing to correctly classify sensed objects or sensor failures due to random hardware malfunctions. A system-based approach can better analyze these system execution problems.

The advantage of a scenario-based approach is that it has minimal dependency on the system's implementation details (e.g., in regulatory applications). As long as the relevant scenario space is the same, the analysis results can be reused across different systems. However, in certain specific scenarios, the system configuration (e.g., the exact number and location of sensors) can still affect the maximum value of scenario risk factors.

Note 1.Knowledge gained during the implementation of one method (e.g., a system-based approach) can be used for analysis using another method (e.g., a scenario-based approach).

Note 2.System-based security analysis results can also serve as test scenarios to be implemented.

This document does not cover all tasks of ADS security evaluation, but primarily focuses on the following aspects.

- Task 1.1.1.Identify and assess potential hazardous scenarios by analyzing the relevant scenario space (see 4.3);

- Task 1.1.2.Explore unknown hazardous scenarios by deriving a set of typical test scenarios (see Appendix J), to demonstrate the adequacy of the relevant scenario space coverage.

Guidelines for the execution of other security tasks can be found in other documents, such as.

- Task 2.GB/T 43267-2023;

- Task 3.ISO/SAE 21434;

- Tasks 1.2 and 1.3.GB/T 43267-2023, ISO 26262 (all parts).

Note 3.Some security issues can be assigned to multiple tasks.

Example. Adversarial attacks, also known as "physical unauthorized intrusions", such as stickers on traffic signs to deceive sensors, can be assigned to both Task 3 and Task 1.In Task

3, the relevant attack scenarios are identified; in Tasks 1.1 and 1.2, the robustness of the system evaluation process in this document;

- The second column from the left is the preparation phase prior to identifying critical scenarios, which defines the safety testing objectives;

- The third column from the left provides the relevant scenario space norms and identifies the risk factors and critical scenarios for safety evaluation based on the safety evaluation framework;

- The fourth column from the left illustrates the connection between the scenario- based safety testing and evaluation process in the safety analysis phase and the remaining product development phases;

- The fifth column from the left illustrates how the outputs of the scenario-based safety evaluation framework adapt to the whole-vehicle safety verification process, including other safety confirmation steps;

- The lines represent iterative cycles and conditions of action, which can contain new findings and trigger necessary adjustments, such as functional modifications required for safety reasons.

Chapter 4 provides guidance on addressing the following issues to refine the overall scenario-based safety evaluation process.

- 4.1 Applying this process throughout the overall development process. How this framework can be integrated into existing product development processes;

- 4.2 Safety testing objectives. How to define the safety testing objectives the system needs to achieve;

- 4.3 Relevant scenario space norms. How to define the relevant scenario space;

- 4.4 Derivation of critical scenarios based on risk factors. How to define a set of critical scenarios and derive a test scenario set from them;

- 4.5 Derivation of test scenarios based on objectives covering the relevant scenario space. Identifying potential critical test scenarios;

- 4.6 Derivation and allocation of specific test scenarios. How to generate test scenarios and allocate them to different test platforms;

- 4.7 Test execution. Requirements that need to be met when running test scenarios;

- 4.8 Safety evaluation. How to evaluate test results to obtain overall results.

Clause 4.3 identifies reasonably foreseeable risk factors that can lead to hazardous scenarios, which is a supplement and expansion of Chapter 7 of GB/T 43267-2023.

Critical scenarios are generated by structuring risk factors; a scenario catalog is created for testing. Therefore, the method of identifying and structuring risk factors in this document helps to maximize the coverage of known hazardous scenarios in SOTIF.

Clause 4.5 determines the specific scenarios to be tested and their corresponding platforms, which is an important step in defining the verification and validation strategy in Chapter 9 of GB/T 43267-2023.

Clauses 4.3 ~ 4.8 correspond to Chapters 10 and 11 of GB/T 43267-2023, using known hazardous scenarios as additional inputs to the safety evaluation process. By changing some attributes or characteristics of these scenarios, unknown hazardous scenarios can be explored, thereby reducing the space and number of unknown scenarios.

Note. The scenario-based safety evaluation process, or some of its activities, can be applied not only to the whole vehicle level but also to the system, subsystem, or component level. This process is adapted accordingly for testing different ADSs.

4.1.3 Requirements and recommendations

This document shall be applied in conjunction with GB/T 43267-2023.

4.1.4 Compliance requirements

All requirements of this document shall be met. If any non-compliance exists, reasonable justification must be provided to demonstrate that the scenario-based security evaluation still achieves the corresponding objectives.

4.2 Safety testing objectives

4.2.1 Purpose

The purpose of 4.2 is to determine the safety testing objectives for ADS safety evaluations.

4.2.2 Overview

Safety testing objectives are derived from general risk acceptance criteria [e.g., Lowest

Reasonable Feasible Risk Level (ALARP), Minimum Endogenous Mortality Rate (MEM), Positive Risk Balance (PRB), and other applicable criteria] or from external inputs (e.g., GB/T 43267-2023 and related documents). Safety testing objectives are typically represented using one of two methods.

a) Within the operational scope, during operation of the ADS (or a portion thereof), the acceptable and verifiable occurrence boundary values (upper or lower limit,

......