Automatic Generation System for Autonomous Driving Simulation Scenarios Based on PreScan

Abstract

The advancement of autonomous driving technology has urgently necessitated enhanced safety testing measures. Traditional road testing methods face significant challenges due to their high costs and prolonged durations. In response to the inefficiencies of manual scenario construction and the difficulties in selecting effective scenarios using common scenario generation methods in autonomous driving safety testing, this study proposes an innovative automatic SG system based on PreScan2021.1.0. The SG process is significantly simplified by this system’s capability to swiftly and accurately generate a vast array of specific scenarios through the input of scene parameters. The results indicate that this system achieves SG at a rate 2.5-fold faster than manual methods, alongside substantial improvements in accuracy. This system introduces a novel approach to virtual simulation, which is vital for the progress of autonomous driving safety. It offers a new paradigm for quickly and precisely generating test scenarios for autonomous driving.

1. Introduction

The emergence of Autonomous Vehicles (AVs) is rapidly advancing, driven by breakthroughs in sensors, artificial intelligence, communications, and positioning technologies. Paramount among the challenges in this domain is the assurance of safety in autonomous driving [1]. Conducting exhaustive tests using comprehensive road scenarios is crucial for ensuring the anticipated safety standards. Traditional road scenario testing involves assessing vehicle functions in simulated real-world scenarios or under specific working conditions. However, the traditional approach is marred by high testing costs, extended durations, limited scope in realizable scenarios, and low reusability of these scenarios. In contrast, simulation-based scenario testing offers an effective solution, overcoming the limitations of traditional methods while concurrently enhancing the safety of testing procedures [2].

Currently, researchers have proposed three primary methods of scenario generation (SG): algorithmic modeling, data driven, and standard specifications [3,4].

Algorithmic modeling primarily employs the theoretical foundation of algorithms and scenario modeling to create marginal and diverse scenarios.

Among them, the scenario combination test method [5,6,7] arranges and filters scenario elements, enabling the rapid generation of a multitude of scenarios. Some studies specifically focus on generating scenarios for automotive systems within simulated road environments [8,9], and some generate corner cases based on interactions with other vehicles [10,11]. While algorithmic modeling can produce numerous scenarios, the screening process, which relies on personal experience and judgment, necessitates significant effort to sift out useful scenarios from the large pool of possibilities.

Data driven is the generalization and reconstruction of real accident scenarios to generate simulation scenarios [12]. This includes methods for collecting data independently to extract key information and subsequently generating scenarios [13,14], as well as approaches for extracting scenario elements from accident databases to create scenarios [15,16]. This methodology faces challenges, including the complexity of data collection and processing, which often leads to inherent limitations in the generated scenarios. Moreover, the approach’s generalization capability may be limited, potentially restricting its broader applicability.

Standard specifications is to generate scenarios according to regulatory requirements. In order to standardize scenario testing, develop test contents, design test cases, and improve the test scenario library, the proposed standards and regulations will help realize the systematic, effective, and rapid testing of AVs safety. Numerous scenario projects have been proposed in recent times, including Pegasus [17], cooperative intelligent transportation system-vehicular communication application layer specification and data exchange standard (Phase I) [18], euroFOT [19], and AdaptIVe [20]. It provides a scenario basis for functional verification. However, when testing simulation scenarios based on standard regulations, generalizing them into multiple similar scenarios is necessary. This process often requires repeatedly building scenarios using the existing simulation data. Such an approach faces challenges, including low automation and the labor-intensive nature of manual SG. This can lead to errors, especially when dealing with a large number of test scenarios.

Commonly used scenario building software include PreScan 2021.1.0 [21], VTD 2021.4 [22] and Carmaker 10.0 [23]. PreScan represents an integration of scenario building and control modeling capabilities within the realm of autonomous driving simulations. Distinguished from other scenario building software, PreScan offers a comprehensive library of fundamental components. This library includes a diverse of vehicles, traffic signs, pedestrians, and roads, providing users with extensive resources for scenario creation. Additionally, PreScan stands out for its flexibility in modifying environmental conditions, such as weather and lighting sources. This adaptability enhances the realism and variability of simulation scenarios, making it a valuable tool in the development and testing of autonomous driving systems. Therefore, a large number of scenario testing articles choose PreScan as their simulation software [24,25].

This paper addresses several challenges identified in the previously proposed methods. These include difficulties in identifying effective, available scenarios, challenges in scenario data collection and processing, and the low degree of automation in manually constructed scenarios. This paper proposes an autonomous driving SG system based on PreScan, taking the Phase I as an example, and first constructing a static scenario by using PreScan [26]. On the basis of this, this paper uses the PreScan API and C++ to build a dynamic scenario and obtain the element class, by analyzing this class, we express the element as parameter. These parameterized elements are then organized and displayed in the user interface. Finally, we use WebSocket to establish a connection between the front-end and back-end, facilitating the automated creation of autonomous driving scenarios via front-end parameter input. System accuracy and speed were verified, demonstrating that it is more accurate than manual construction. The system’s speed is nearly 2.5-fold higher than manual methods. Additionally, it can generate concrete scenarios tailored to testing needs, thereby avoiding the complexity of scenario screening.

This paper is divided into five chapters. Section 1 serves as an introduction, providing the context for SG and discussing the relevant work of this system. It highlights the challenges and shortcomings in existing research, and outlines the innovative aspects of this paper. Section 2, scenario construction methodology based on PreScan, presents the dynamic scene generation based on PreScan, which lays the software foundation for this system. Section 3, automatic system design, elaborates on the system design process, architecture, and individual components. Section 4, testing and simulation, uses three subsections—accuracy verification, rapidity verification, and generation results—to compare and validate the advantages and functionalities of this system. Section 5, conclusion, summarizes the system’s capabilities and contributions and offers a perspective on future work.

Our main contributions can be articulated as follows:

• Innovation in the Generation of Scenarios: We have innovated the method of SG, avoiding the repetitive nature of manual construction and introducing a novel system of automation. This development addresses the complexities associated with the selection of scenarios.
• Classification and Combination of Scenario Elements: The methodology proposed in this paper classifies and combines scenario elements to enhance programming efficiency and reduce complexity. With the implementation of new parametric expressions introduced herein, a more intuitive distinction between specific scenarios is facilitated. This provides fresh perspectives for SG and representation.
• Utilization of PreScan for Scenario Visualization: Our approach leverages PreScan for the presentation of simulation scenarios, thereby allowing test personnel to directly observe and test within the simulation software. This obviates the need for test personnel to perform the step of data simulation, thereby conserving effort and time.

2. Scenario Construction Methodology Based on PreScan

Based on the level of abstraction of the scenarios, they can be categorized into functional scenarios, logical scenarios and concrete scenarios. Functional scenarios, being the most abstract, articulate the interactions between entities in the scenario through language. Logical scenarios, a step further in specificity, define these relationships between entities by defining the parameter ranges of variables in the state space. Concrete scenarios, the most detailed, determine the specific value of each parameter to represent the relationship between entities in the scenario, for different values of logical scenarios, corresponding concrete scenarios can be generated [27]. Scenario testing in autonomous driving simulations is predicated on accurately realizing the interrelationships among entities. The premise of scenario testing is to realize the accurate expression and generation of scenarios. This is, beginning with the description of functional scenarios, advancing to the determination of logical scenarios, and culminating in the construction of concrete scenarios. Furthermore, the development of specialized scenario construction software has provided a solid theoretical and practical foundation for SG. These advancements have been instrumental in refining the process of scenario conceptualization, design, and implementation, thereby enhancing the fidelity and effectiveness of autonomous driving simulations.

Scenario construction in autonomous driving simulations can be categorized based on the nature of scenario elements, classifying them into static and dynamic scenario constructions. Static scenario construction focuses on restoring the non-changing elements integral to vehicle operation, such as road layouts and stationary traffic components within the scenario. Utilizing the PreScan editing interface, users can configure elements from an extensive library to swiftly construct static scenarios tailored to varying requirements.

Dynamic scenario construction within autonomous driving simulations builds upon the foundation of static scenarios. This method adheres to the physical laws of the real world and incorporates behavioral logic. It involves the integration of dynamic elements such as traffic signal systems, communication networks, active traffic participants, and variables like weather and lighting conditions. PreScan offers a versatile platform for application developers in the realm of autonomous driving simulations. It enables the use of C++ or Python programming languages to interact with the software’s application programming interface (API), facilitating interaction and communication between different software systems. Within this framework, developers have the option to employ Procedural Programming (PP) methodologies. This approach centers around utilizing the elements and processes inherent in each scenario, directly invoking functions available within the PreScan API. While PreScan offers a comprehensive range of functions through its API, directly invoking these functions can lead to substantial code redundancy. This redundancy may result in decreased program reliability, limited scalability, and increased maintenance challenges. To address these issues, an alternative programming methodology is proposed: Object-Oriented Programming (OOP). This approach encapsulates logical relationships within objects, thereby facilitating more efficient and less complex development processes. By adopting OOP, developers can significantly enhance programming efficiency, reduce development complexity, and avoid the repetitive and cumbersome nature of direct function calls in scenario construction.

In pursuit of improving the efficiency and scalability of simulation scenario construction and addressing the challenge of repeated API, this paper introduces a novel approach utilizing OOP within the framework of PreScan dynamic scenario construction. This methodology centers on the parametric modular management of dynamic scenario elements, leading to the streamlined development of a sophisticated back-end scenario construction program. By implementing OOP principles, this paper facilitates a more efficient, scalable, and systematic process for constructing dynamic simulation scenarios.

3. Automatic System Design

The objective of this paper is to develop a comprehensive automatic system, designed to rapidly produce concrete scenarios tailored to diverse testing requirements. The core architecture of this system is segmented into four fundamental components: scenario construction, scenario parameterization, front-end design, and result generation. Each component is interconnected, working collaboratively to enable efficient data transmission and the generation of concrete scenarios. As shown in Figure 1, scenario construction has two parts: static scenario and dynamic scenario construction. Dynamic scenario construction is realized by calling the API of the static scenario constructed by PreScan to form the scenario element class; scenario parameterization is the natural description of the scenario element class, and describes each element of the scenario element class in the form of parameterization; the front-end design is to provide users with an intuitive interface through the design of the webpage interface, and realize the setting of parameterization elements. The front-end design is designed through the web interface to provide users with an intuitive operating interface to realize the settings of the parameterized elements and form a convenient Human–Computer Interaction (HCI) for the automatic generation of the scenario; the result generation demonstrates the generated visualization of the specific scenario and the scenario data, which is convenient for users to analyze the data. PreScan and the front-end HCI utilize the WebSocket to ensure real-time data communication. This capability enables the selective invocation of varied scenario classes based on user preferences in scenario functionalities. Moreover, it facilitates the real-time management and control of dynamic scenario element classes, thus streamlining the process of automatically generating concrete scenarios as per user requirements.

3.1. Scenario Construction

Scenario construction is divided into two parts: static scenario construction and dynamic scenario construction. In this paper, the PreScan scenario library is used to select vehicles, pedestrians, trees, traffic lights, and build static scenarios based on the characteristics of conventional city streets. Figure 2 classifies the dynamic elements such as vehicles, pedestrians, and environment in the static scenario, and uses OOP to encapsulate the corresponding API of the dynamic elements to form vehicle class, pedestrian class, environment class. Parameterize the dynamic elements according to the needs of dynamic scenario construction and combine the element classes to establish the experimental environment and form the combination class. According to the mutual logical relationship between the dynamic elements in the scenario, inherit the attributes and methods of the experimental environment, respectively construct two-vehicle scenario, three-vehicle scenario and human-vehicle interaction scenario, and form a unit class, so as to make the dynamic elements in the scenario interactive. According to the needs of testing of automatic driving, call the corresponding unit class, respectively, to parameterize the dynamic elements and the mutual logical relationship between the elements and construct the dynamic scenario of automatic driving.

3.2. Scenario Parameterization Design

To more intuitively represent each scenario element within the logical scenario, this paper employs a strategy based on the combined classification of scenario elements during scenario construction. Key information from each element class is mapped to corresponding parameters, thereby representing each logical scenario in a parameterized form. The range of these parameters is determined by the specific testing requirements of the logical scenario [28,29]. This study proposes a method of parametric formal representation as opposed to linguistic representation. This approach is advantageous for effectively handling the generation of a large number of scenarios, and it facilitates subsequent analysis and documentation processes.

In the implementation of scenario parameterization design, elements are classified into vehicle class, pedestrian class, and environment class. The API in the element class can be embodied in the form of controllable parameters, so as to facilitate the use of functions in scenario description and scenario construction. As shown in

Table 1. Information on partially parameterizable representations of scenarios.

Scenario Element Class	Function Name	Parameterization	Direct Assignment
Remote Vehicle (RV) Information	The Speed of RV	${\alpha }_{speed}$	√
	The Acceleration of RV	${\alpha }_{acceleration}$	√
	The Deceleration of RV	${\alpha }_{deceleration}$	√
	The Distance between HV and RV	${\alpha }_{distance\_hr}$	√
	The Offset Rate of RV	${\alpha }_{\mathrm{offset}}$	√
	Vehicle Type of RV (Car, SUV, Bus and Truck)	${\beta }_{\mathrm{vehicletype}}[1/2/3/4]$	×
	The Direction of RV (left, straight and right)	${\beta }_{\mathrm{road}}[1/2/3]$	×
Host Vehicle (HV) Information	The Distance between HV and The Center Point of the Current Lane Stop Line	${\alpha }_{distance\_cp}$	√
	Longitudinal Distance between HV and the Start of In-Vehicle Signage	${\alpha }_{distance\_is}$	√
	Longitudinal Distance Between HV and the Start of The Congestion Location	${\alpha }_{distance\_cl}$	√
	The Speed of HV	${\alpha }_{speed}$	√
	The Acceleration of HV	${\alpha }_{acceleration}$	√
	The Deceleration of HV	${\alpha }_{deceleration}$	√
	The Direction of HV (left, straight and right)	${\beta }_{\mathrm{road}}[1/2/3]$	×
Pedestrian (PED) Information	The Speed of PED	${\alpha }_{speed}$	√
	The Acceleration of PED	${\alpha }_{acceleration}$	√
	Pedestrian Delay Duration	${\alpha }_{delay}$	√
	Pedestrians Type (adults and children)	${\beta }_{\mathrm{pedtype}}[1/2]$	×
Environmental Information	Lighting Conditions	${\alpha }_{light}$	√
	Weather (sunny, rainy and snowy)	${\beta }_{weather}[1/2/3]$	×

√ means it can be assigned directly, and × means it cannot be assigned directly.

, the information that can be directly assigned is directly represented in the form of numbers, and the information that cannot be directly assigned is further categorized by definitions and functions, such as vehicle type with sedan, sport utility vehicle (SUV), bus and truck as the three options; other vehicle actions with left turn, straight ahead and right turn as the three options; pedestrian type with adult and child as the two options; and weather with sunny, rainy and snowy days as the three types of options. For the elements that can be directly assigned, we denote them as such, and for the factors that cannot be directly assigned, we denote them as such.

For example, in intersection collision warning (ICW), the HV turns right through the intersection, and the remote vehicles go straight or turns through the intersection, which can be represented by the following parameters, where $hv$ is the Host Vehicle, and $rv$ is three remote vehicles:

$$\begin{array}{l}IC{W}_5:\left\{hv\right\{{\alpha }_{speed},{\alpha }_{acceleration}\},rv1\{{\alpha }_{speed},{\beta }_{road}[1/2/3]\},rv2\{{\alpha }_{speed},{\beta }_{road}[1/2/3]\},\\ rv3\{{\alpha }_{speed},{\beta }_{road}[1/2/3]\},{\beta }_{\mathrm{weather}}[1/2/3]\}\end{array}$$

With the above approach, logical scenarios are represented in a parameterized form. When generating a specific scenario, only the specific parameters of the scenario need to be determined, and the complete specific scenario can be generated.

3.3. Front-End Design

This paper adopts Vue.js as a front-end framework for web interface design to realize convenient setting of user parameter setting of the system and visual display of the generation results. Vue.js is a lightweight JavaScript framework that focuses on organizing and simplifying web development. The framework has a convenient data update mechanism and implements intermodule interaction using specific methods within components. In addition, Vue.js [30] is very simple to deploy and facilitates communication with the back-end, thus reducing dependency on back-end resources Vue.

The front-end interface of this paper is divided into four parts: scenario selection, scenario introduction, parameter setting and data display, as shown in Figure 3. The scenario selection function is to realize the user’s quick selection of different functional and logical scenarios by designing the interactive elements such as click and drop-down in the first interface; the scenario introduction part is to define and describe the logical scenario, and clarify the state relationship between each element of the logical scenario; and the parameter setting part is to realize the setting function of the parameters of each controllable element: for the elements that can be directly assigned, the user can directly input specific parameter values in the input box to realize the precise setting; for the elements that cannot be directly assigned, the user can set the parameters by single selection. The data display section presents the simulation results of the automatic system in the form of visualization scenarios, charts and numerical values, which are not modifiable. After the user sets the required parameters in the parameter setting section for automatic SG, PreScan will automatically pop up and run the simulation, showing the real-time visualization scenario, which shows the vehicle’s driving status from a top-down perspective; the chart section displays and compares the vehicle data at different moments through line graphs; the numerical section displays the specific scenario parameter data in real time after generation. At the end of the run, the simulation scenario is saved to the specified file in Python executable (.pex) format.

3.4. Front-End and Back-End Communication

The core of automatic SG lies in the real-time data transfer between the HCI front-end interface and the PreScan back-end. This paper employs the WebSocket for seamless communication between the front-end and back-end. WebSocket, a full-duplex communication protocol, enables a persistent connection between client and server. Through WebSocket, the front-end is capable of transmitting data to the back-end in real time. Concurrently, the back-end can relay results and visualized scenarios back to the front-end instantaneously. This real-time, bi-directional communication facilitates continuous data interaction between the front-end and back-end, obviating the need for frequent opening and closing of connections, thereby ensuring a more efficient and uninterrupted connection.

In order to accurately facilitate data transfer between different programming languages, this paper chooses JavaScript object notation (JSON) as the data exchange format, which has the characteristics of easy parsing and generation, and can be used for data exchange and communication between different programming languages and operating systems. As shown in Figure 4, after the user specifies the scenario parameters, the front-end sends the input data to the back-end. After receiving the data, the back-end first determines the appropriate scenario category, selects the appropriate unit class, and then selects the API according to the elements in the unit class to generate the corresponding simulation scenario. At the same time, the data in the simulation scenario is transferred back to the front-end in real time and displayed in the front-end visualization component. The real-time information transfer between the front-end and back-end effectively improves the efficiency of data transfer.

Through the above process, users can design the required scenario test cases according to the scenario parameterization, and only need to enter the set parameters to communicate with the back-end to display the generated results on the front-end. This ensures both the speed of building scenarios and the accuracy of the task.

4. Testing and Simulation

Based on the list of applications given in the Phase I, they are analyzed and summarized to be classified in terms of categories, which are divided into three main categories, namely safety, efficiency and information services, which include 12, 4 and 1 logical scenarios, respectively. Categorized in terms of the main communication methods, they are divided into three categories: V2V (vehicle to vehicle), V2I (vehicle to infrastructure) and V2P (vehicle to pedestrian). Since PreScan is unable to build the vehicle entry payment scenario in the information service category, this paper carries out test simulation and analysis for the two categories of safety and efficiency, as shown in

Table 2. Logical scenario categories.

Serial Number	Form	Main Communication Methods	Functional Scenarios	Logical Scenario
1	Surety	V2V	Forward Collision Warning (FCW)	6
2		V2V/V2I	Intersection Collision Warning (ICW)	5
3		V2V/V2I	Left Turn Assist (LTA)	5
4		V2V	Blind Stop Warning/Lane Change Warning (BSW/LCW)	4
5		V2V	Do Not Pass Warning (DNPW)	2
6		V2V	Emergency Brake Warning (EBW)	5
7		V2V	Abnormal Vehicle Warning (AVW)	4
8		V2V	Control Loss Warning (CLW)	4
9		V2I	Hazardous Location Warning (HLW)	1
10		V2I	Speed Limit Warning (SLW)	1
11		V2I	Red Light Violation	2
12		V2P/V2I	Warning (RLVW)	4
13	Efficiency	V2I	Vulnerable Road User Collision Warning (VRUCW)	1
14		V2I	Green Light Optimal Speed Advisory (GLOSA)	1
15		V2I	In-Vehicle Signage (IVS)	1
16		V2V	Traffic Jam Warning (TJW)	1

; the configuration of the simulation environment is as shown in

Table 3. Realization environment.

Realization Environment	Version
Operating System	Windows 10 64 bit
Graphics Card Configuration	NVIDIA GeForce RTX 3060
Scenario	PreScan 2021.1.0
Front-End Framework	Vue.js 2.5.2
Front-End Environment	Node.js v16.19.1

; Figure 5 shows the scenario selection function and the scenario introduction and parameter setting function realized by the front-end design.

In our system evaluation, the baseline memory footprint was approximately 2384 MB, which indicates the amount of memory occupied when the system is booted up and put on standby. Under standard generation conditions, the average memory usage is approximately 2739 MB. When generating scenario with many elements, the system had a peak memory footprint of approximately 3268 MB. The tests were conducted on Windows 10 with 16 GB of RAM, using the Task Manager to monitor the memory. By averaging over multiple runs, we arrive at these numbers, which represent the typical memory requirements of the system.

4.1. Accuracy Verification

In this study, we have selected four distinct scenarios to evaluate the functionality and accuracy of the system. These scenarios incorporate various factors, including the speed and acceleration of the HV, the speed and direction of RV, and varying weather conditions. Subsequent to the generation process, we conduct a reverse verification to ensure the fidelity of the generation. This verification is accomplished by cross-referencing the elements of the simulated scenarios against the predefined data settings within the system. A perfect correspondence results in a “Yes” verdict, indicating accuracy, while any discrepancies lead to a “No” outcome. This approach is particularly advantageous given that manual construction is prone to human errors, especially in the fine details of data manipulation. Hence, our automated system significantly mitigates the risk of inaccuracies that are often introduced during manual scenario assembly. This approach is designed to rigorously validate the system’s capability to automatically generate scenarios. Detailed information about these test scenarios is presented in

Table 4. Test scenarios parameter information.

Serial Number	Functional Scenarios	Logical Scenario Definition	Parameterization	Accuracy Judgment
a	FCW	HV traveling, RV stopping in same lane	$FC{W}_1:\left\{hv\right\{{20}_{speed}\},rv\{{190}_{distance\_hr},{\beta }_{vehicletypy}[4]\},{\beta }_{\mathrm{weather}}[2]\}$	Yes
b	ICW	HV right turn through intersection, RV straight or turn through intersection	$\begin{array}{l}IC{W}_5:\left\{hv\right\{1_{speed},{0.5}_{acceleration}\},rv1\{2_{speed},{\beta }_{road}[2]\},\\ rv2\{2_{speed},{\beta }_{road}[1]\},rv3\{2_{speed},{\beta }_{road}[2]\},{\beta }_{\mathrm{weather}}[1]\}\end{array}$	Yes
c	VRUCW	Turning at HV junction with pedestrian crossing ahead	$VRUC{W}_4:\left\{hv\right\{4_{speed},{\beta }_{road}[1]\},ped\{{0.7}_{speed}\},{\beta }_{\mathrm{weather}}[1]\}$	Yes
d	RLVW	The vehicle arrives at the intersection with a red light.	$RLV{W}_1:\left\{hv\right\{5_{speed}\},{500}_{lux},{\beta }_{\mathrm{weather}}[3]\}$	Yes

.

The test procedure, as depicted in Figure 6, evaluates various scenarios. The vehicle type of RV can be clearly observed in the FCW as a truck, and the weather is rainy, and the speed of HV can be seen in the results as 20 m/s, and the distance between HV and RV is 190 m. In the ICW, RV1 is set as a straight line, RV2 is set as a right turn, and RV3 is set as a straight line, and the state of the vehicle can be clearly seen in the visualization scenario. In the VRUCW set HV left turn, the speed of crossing pedestrian is 0.7 m/s, the generation results are accurate. In the RLVW, red light running warning, set HV speed is 5 m/s, the light is 500 lux, the weather is snowy. The above four scenarios verify the versatility of the system in this paper, which can accurately generate scenarios with different factors and under different working conditions.

4.2. Rapidity Verification

To evaluate the efficiency of SG, this study conducts a comparative analysis between manual scenario building and the automatic SG system. First, two groups were formed for the experiment: group one consisted of five employees with experience in scenario building and group two consisted of five employees without such experience. Group two received training on how to use the system. Five scenarios were then randomly selected using random generation algorithms, and each group was tasked with randomly generating ten data sets for each scenario. The scenarios were constructed simultaneously by both groups, and the process was timed. The time taken by each group to complete all the scenarios was compared and the results are shown in

Table 5. Manual vs. automatic generation.

SG Methods	Duration Comparison	Accuracy
Manually generated	92 min 24 s	94%
	91 min 06 s	94%
	98 min 13 s	100%
	90 min 46 s	92%
	94 min 33 s	96%
Automatic generation	37 min 45 s	100%
	36 min 47 s	100%
	37 min 06 s	100%
	38 min 23 s	100%
	35 min 31 s	100%

.

According to the data in the table above, it is obvious to compare that the automatic generation system is almost 2.5-fold faster than the manual generation, and the accuracy is also higher than manual generation. It is worth mentioning that in manual generation, PreScan functions such as red light setting, weather setting and vehicle distance setting also take a certain amount of time, and in the late stage of manually scenario generating, due to the fatigue of building the scenario for a long time, the manually generated scenario appeared to have inaccurate parameters, while the automatic generation system completely avoids this problem, realizing that fast and accurate.

4.3. Generation Results

In this study, the logical scenario in ICW intersection collision warning is selected to show the results, and the scenario is defined as the HV going straight through the intersection, and the RV going straight or turning through the intersection. In this test scenario, the HV speed should be 0~60 km/h, the HV acceleration is 0–4 m/s², and the RV speed is: 10 km/h~40 km/h.

For example, in the scenario where the HV makes a right turn at the intersection and the RV either goes straight or turns, the parameters are shown as follows:

$$\begin{array}{l}IC{W}_5:\left\{hv\right\{0_{speed},{0.5}_{acceleration}\},rv1\{4_{speed},{\beta }_{road}[1]\},rv2\{4_{speed},{\beta }_{road}[1]\},\\ rv3\{4_{speed},{\beta }_{road}[1]\},{\beta }_{\mathrm{weather}}[1]\}\end{array}$$

In this scenario, the initial speed of the HV is set to 0 km/h with an acceleration of 0.5 m/s². The RV1 has a speed of 4 m/s and is scheduled to turn left at the intersection. Similarly, the RV2 also travels at a speed of 4 m/s and turns left at the intersection. The weather condition for this scenario is set to sunny. Visualizations of the scenario and the corresponding results are shown in Figure 7.

As shown in Figure 8, the HV’s yaw angle gradually changes from 0 to −1.5780 radians after the right turn. Similarly, the HV’s yaw rate varies during the turn and then stabilizes at 0 as the vehicle realigns. These visualizations provide a valuable tool for testers, increasing the convenience and accuracy of various assessments, such as the calculation of safety distance.

At an intersection, when HV turns right, RV can realize four motion states: stationary, straight ahead, left turn, and right turn. With the automatic generation system, simulation scenarios can be generated quickly and accurately with the required data. Compared to manually writing specific scenarios, the automatic generation system saves a lot of time and reduces the risk of errors. In addition, as scenarios become more complex and require more parameters, the efficiency of the automatic generation system becomes even more apparent.

5. Conclusions

To address the inefficiency of manually constructing automatic driving simulation scenarios, this paper innovatively designs an automatic scenario generation system. This system streamlines the process and significantly improves productivity and accuracy.

Initially, the static scenario was built using the scenario of PreScan, and the dynamic scenario was constructed on the basis of the static scenario by combining and encapsulating the API using the API of PreScan in conjunction with C++. A breakthrough was achieved in scenario representation by parameterizing the logical scenario. This approach, leveraging the encapsulated dynamic scenario element class, simplifies and clarifies the logical scenario description language. Web front-end development was then conducted using a JavaScript framework, enabling the convenient setting of parameters within the automatic generation system. Real-time data communication between the Web front-end and PreScan software was facilitated using WebSocket. Consequently, the automatic generation system can now invoke various scenario classes based on user-selected scenario functions and control dynamic scenario element classes in real time.

This study conducted system testing using 16 functional scenarios outlined in Phase I. This study confirms that the system developed in this paper can automatically generate autonomous driving simulation scenarios with complex and diverse elements, ensuring accurate acquisition of scenario data. The intersection collision scenario was used as a test case, demonstrating the system’s proficiency in rapidly generating scenarios. The system’s ability to visualize data results enhances the simulation experience, providing a more intuitive and efficient approach to scenario testing. In future research, we aim to investigate the compatibility and integration issues between this system and other simulation software, with the goal of developing a more flexible driving simulation system that encompasses a broader array of scenario types. To enhance the realism of the simulated scenarios, the incorporation of actual traffic data is also being considered. This will enable test personnel to rapidly and accurately generate the required testing scenarios. The anticipated improvements are expected to increase the efficiency of autonomous driving simulation tests and contribute to the field of simulation testing.