A traffic scene automatic generation and editing method based on a large language model
By processing natural language descriptions through multi-stage prompt chains and large language models, traffic simulation scenarios that conform to standard specifications are generated, solving the problems of inaccurate scenario generation and inflexible editing in existing technologies, and realizing efficient and accurate simulation scenario construction and editing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-03-25
- Publication Date
- 2026-06-26
AI Technical Summary
Existing methods for generating traffic simulation scenarios suffer from insufficient semantic understanding, inaccurate structural modeling, lack of physical constraints, and a lack of standardization and editability, making it difficult to meet the needs of large-scale testing in complex traffic environments.
It employs a multi-stage cue chain to process natural language descriptions, and uses a large language model for task classification, scene editing, semantic understanding, and structured extraction to generate simulation scene files that conform to preset specifications, including road structure layers and vehicle information layers. It also solves for initial position and velocity parameters through a vehicle motion constraint model, supporting flexible scene editing.
It improves the accuracy and cross-platform applicability of traffic scene generation, ensures scene consistency and simulation credibility, and supports cross-platform calls and user-driven scene modification.
Smart Images

Figure CN122285540A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of simulation and testing technology for autonomous driving systems, specifically to a method for automatically generating and editing traffic scenes based on a large language model. Background Technology
[0002] As autonomous driving technology advances to Level 3 and above, system safety verification has become a key factor restricting its large-scale application. Relying solely on real-vehicle road testing is insufficient to cover extreme and long-tail scenarios, and suffers from high costs, long cycles, and uncontrollable safety risks. Therefore, large-scale testing based on simulation environments is gradually becoming the mainstream approach, and the quality and efficiency of test scenario construction directly affect the validity of the verification results.
[0003] Existing methods for constructing traffic simulation scenarios mainly include: scenario reconstruction based on real vehicle data playback, scenario design based on manual modeling or graphical interface editing, and automatic generation methods based on rules or templates. These methods suffer from problems such as high data acquisition costs, reliance on human experience, low generation efficiency, and insufficient scenario diversity and semantic expression capabilities, making it difficult to meet the needs of large-scale testing in complex traffic environments.
[0004] With the development of large language models, using natural language descriptions to drive traffic scene generation has become a new research direction. By parsing accident reports or test requirement texts, unstructured semantics can be transformed into structured simulation scenes, potentially improving scene construction efficiency. However, existing technologies mostly employ single-stage prompts or direct parameter generation methods, which have significant shortcomings: on the one hand, they lack sufficient understanding of the implicit behavioral logic and multi-agent interaction relationships in natural language, leading to semantic deficiencies in the generated results; on the other hand, they lack the ability to finely express road topology, resulting in deviations between the generated scenes and the real environment; furthermore, in the process of generating continuous variables, unreasonable numerical values or failure to meet physical constraints are prone to occur, affecting the credibility of the simulation.
[0005] In terms of engineering implementation, different simulation platforms use different scene description specifications, and existing methods mostly output platform-specific formats, lacking a unified standard and making it difficult to achieve cross-platform reuse. In addition, existing solutions are usually one-time generation processes, lacking the ability to flexibly edit the generated scenes. When users need to adjust scene parameters, they need to regenerate, which is inefficient and makes it difficult to maintain semantic consistency.
[0006] On the other hand, in the construction of collision scenarios, determining the initial positions and motion parameters of multiple vehicles under unified constraints, and ensuring consistent interaction relationships in time and space, is crucial to the accuracy of the simulation. Existing methods often rely on preset trajectories or rule-driven approaches, making it difficult to guarantee the physical consistency of the collision process.
[0007] In view of this, the present invention proposes a method for automatic generation and editing of traffic scenes based on a large language model. Summary of the Invention
[0008] The purpose of this invention is to provide a method for automatically generating and editing traffic scenes based on a large language model, which aims to solve the problems of incomplete semantic understanding, inaccurate structural modeling, lack of physical constraints, and lack of standardization and editability in the existing technology for generating traffic simulation scenes based on natural language.
[0009] In a first aspect, the present invention provides a method for automatically generating and editing traffic scenes based on a large language model, comprising the following steps:
[0010] Step 1: Receive natural language description of traffic scene text input or request to modify the generated scene, perform task determination on the input text based on the large language model, and output task type identifier;
[0011] Step 2: Construct a multi-stage prompt chain that includes task classification, scene editing, semantic understanding, and structured extraction. Perform step-by-step constraint processing on the input text to generate structured scene data. The structured scene data includes a road structure layer for describing the environment and a vehicle information layer for describing dynamic interactions.
[0012] Step 3: Construct a vehicle motion constraint model based on the structured scene data, extract information on the active impactor, the impacted party, and the collision location; generate the theoretical driving path of the vehicle according to the road structure type, and construct a set of equations with the constraint that all vehicles arrive at the collision location at the same time, and solve for the initial position and initial velocity parameters of each vehicle.
[0013] Step 4: Map the road structure layer, vehicle information layer, and motion parameters into scene file elements that conform to preset simulation standards, and combine them to generate standardized scene files;
[0014] Step 5: Based on the generated scene, receive new natural language modification instructions, call the scene editing module in the prompt chain to reconstruct the original description, and re-execute the structured extraction, parameter solving and scene generation steps to obtain the updated simulation scene.
[0015] As a preferred embodiment of the present invention, the multi-stage prompt chain specifically includes:
[0016] Phase 1 is the task classification phase, which determines whether the user's intent is scene generation, scene editing, or other.
[0017] Phase 2 is the scene editing phase, in which the original scene description is rewritten based on the user's modification requests, and a revised scene description is output.
[0018] Phase 3 is the semantic understanding phase, which generates intermediate semantic representations by answering pre-set question templates aligned with the structured scene data model;
[0019] Phase 4 is the information extraction phase, which maps the intermediate semantic representation to structured scene data with a predefined data structure.
[0020] As a preferred technical solution of the present invention, in stage 3, the preset question template includes a set of questions targeting road structure attributes and vehicle behavior attributes. Through the one-to-one correspondence between questions and fields, the implicit semantics in natural language are transformed into explicit structured information.
[0021] As a preferred embodiment of the present invention, the structured scene data includes:
[0022] The road structure layer includes road type, road segment direction, and number of lanes;
[0023] The vehicle information layer includes the number of vehicles, vehicle behavior sequence, collision relationships, the lane where the vehicle is located, and the relative positions between vehicles.
[0024] As a preferred embodiment of the present invention, the process of solving the initial parameters is as follows:
[0025] A coordinate system is established with the center of the road or the center of the intersection. The vehicle trajectory is expressed by a path function. The initial speed parameters are calculated based on the relationship between the path length and the travel time to ensure that all vehicles arrive at the collision point under the same time conditions.
[0026] As a preferred embodiment of the present invention, the path function is determined based on vehicle behavior:
[0027] If a vehicle's behavior involves crossing an intersection, its trajectory is defined as a straight path.
[0028] If a vehicle's behavior is to turn left, right, or make a U-turn, its trajectory is defined as a circular arc path, the shape of which is determined by the lane it is exiting and entering.
[0029] As a preferred embodiment of the present invention, the standardized mapping process includes:
[0030] Static mapping of road network: The road type, road segment direction and number of lanes in the road structure layer are mapped to road elements, lane elements and junction structures for connecting road segments in accordance with the ASAM OpenDRIVE specification through preset XML element templates;
[0031] Participant dynamic mapping: The behavior sequence in the vehicle information layer and the motion parameters calculated in step 3 are mapped into Event, Condition and Action hierarchical elements that conform to the ASAM OpenSCENARIO specification according to the temporal logic.
[0032] As a preferred embodiment of the present invention, the dynamic mapping is implemented through a predefined library of behavioral operators, including:
[0033] Single Action Mapping: Maps lane keeping or parking actions to SpeedAction elements and parameterizes the target speed;
[0034] Composite Action Mapping: Map lane change, turning, or U-turn actions as a sequence of combined elements containing SpeedAction, LaneChangeAction, and AcquirePositionAction, and fill in their dynamic triggering conditions using the solved initial position and speed parameters.
[0035] The technical effects and advantages provided by the present invention in the above technical solution are as follows:
[0036] This invention employs a multi-stage analytical structured data extraction method to transform road structure and vehicle behavior information from natural language descriptions into hierarchical data. Based on this, it introduces time consistency constraints and a path length calculation model to uniformly solve for the initial positions and velocities of vehicles, ensuring that all vehicles arrive at the collision point simultaneously and satisfy the collision location constraints. Because the aforementioned structured modeling and constraint solving process establishes a correspondence between semantic information and physical parameters, it guarantees the consistency of the generated traffic scene in terms of spatial structure and motion. Furthermore, it generates simulation scene files through standardized mapping, enabling cross-platform calls and thus improving the accuracy and engineering applicability of scene construction. Attached Figure Description
[0037] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.
[0038] Figure 1 This is a flowchart of the automatic generation and editing method for traffic scenes according to the present invention;
[0039] Figure 2 This is an application framework diagram of the automatic traffic scene generation and editing method of the present invention.
[0040] Figure 3This is a flowchart of the four-stage cue chain used in the structured data extraction stage of the present invention for the large language model; Detailed Implementation
[0041] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be described in more detail below with reference to the accompanying drawings.
[0042] Throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions. The described embodiments are only a part of the embodiments of this application, not all of them. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application. The embodiments of this application will be described in detail below with reference to the accompanying drawings.
[0043] Example 1
[0044] like Figure 1-2 As shown, this embodiment provides a method for automatic generation and editing of traffic scenes based on a large language model, including the following steps:
[0045] Step 1: Receive natural language description of traffic scene text input or a request to modify an existing scene; treat the input text as the object to be parsed; perform task determination on the input text based on the large language model, and output a task type identifier. When the determination result is a scene generation task, directly enter the semantic parsing stage; when the determination result is a scene editing task, enter the scene editing stage; when the determination result is another type that cannot be processed, output a prompt message.
[0046] Step 2: Construct a multi-stage prompt chain encompassing task classification, scene editing, semantic understanding, and structured extraction, performing step-by-step constraint processing on the input text. Specifically, the task classification stage outputs the task type; the scene editing stage reconstructs the original scene description based on user modification instructions; the semantic understanding stage generates intermediate semantic representations using preset question templates; and the structured extraction stage maps these intermediate semantic representations to a predefined data structure, generating structured scene data. This structured scene data includes a road structure layer and a vehicle information layer. The road structure layer describes road types, road segment directions, and the number of lanes. Road network types include straight roads, intersections, T-junctions, etc.; road segment details include their direction (north, south, east, or west) and the number of lanes. The vehicle information layer describes the number of vehicles, vehicle behavior sequences, collision relationships, and relative positions between vehicles. More details of each attribute are shown in Table 1.
[0047] Table 1: Field descriptions of two-layer structured scenario data in the structured data extraction stage;
[0048]
[0049] To further explain, the semantic understanding stage parses the input text by using a preset set of questions. The set of questions corresponds to road structure attributes and vehicle behavior attributes, respectively. Through the one-to-one correspondence between questions and fields, the implicit semantics in natural language are transformed into explicit structured information.
[0050] The set of semantic questions includes at least the following types:
[0051] The road structure identification problem is used to determine whether a road structure type is a straight road, a curve, an intersection, or a T-junction.
[0052] The problem of road segmentation is used to determine the number of road segments and their spatial location within a road structure.
[0053] Lane attribute determination is used to determine the number of lanes and their left and right distribution in each road segment;
[0054] Vehicle relationship identification is used to determine the number of vehicles, collision relationships, and impact locations.
[0055] Vehicle behavior analysis is a problem used to determine the motion behavior of a vehicle before a collision occurs.
[0056] Spatial location inference is a problem used to determine the initial position and lane number of a vehicle in each road segment.
[0057] Vehicle relative relationship problems are used to determine the front-to-back positional relationship between vehicles on the same road segment;
[0058] By using the aforementioned set of semantic questions, the input text is mapped item by item to structured scenario data fields, thereby reducing semantic ambiguity and improving the consistency of structured results.
[0059] This can be understood as follows: Given the proposed hierarchical structured scene data, the role of the structured data extraction prompting project is to guide the large language model to map any natural language input I to structured scene data S. This formal process is denoted as: S = Extraction(I);
[0060] Existing scene reconstruction methods based on large language models often compress this mapping into a single cue, which neither fully utilizes the model's reasoning ability nor prevents low output accuracy. To leverage the Chain-of-Thought (COT) mechanism while maintaining modularity, we decompose cue extraction into a four-stage cue chain:
[0061] Phase 1 (Task Classification): Determine the user intent T∈{semantic understanding, scene editing}; if T=semantic understanding, proceed to Phase 3; otherwise, proceed to Phase 2.
[0062] Phase 2 (Scene Editing): Rewrite the original description based on the user's modification requests;
[0063] Phase 3 (Semantic Understanding): Generate intermediate semantic representation M by answering questions aligned with the structured scene data model;
[0064] Phase 4 (Structured Extraction): Taking M as input, output the final structured scene data S that conforms to the predefined pattern.
[0065] Each stage is executed sequentially, with the output of the previous stage serving as the input for the next stage. This progressive refinement reduces semantic uncertainty and improves extraction accuracy without requiring additional training.
[0066] like Figure 3 As shown, in stage 1, the task classification stage, before executing any specific extraction task, the large language model first analyzes the user input I and infers the task type T∈{semantic understanding, scene editing, other}. If the input contains scene description text (such as an accident report), it is determined to be T=semantic understanding, and it directly enters the semantic understanding stage (stage 3) as the scene description text D; if the user requests to modify an existing scene, then T=scene editing, and enters the scene editing stage (stage 2); other requests that cannot be handled (T=other) are responded to by the large language model to the best of its ability. This stage is formalized as follows: T=Classify(I), T∈{semantic understanding, scene editing, other};
[0067] Where T represents the inferred task type, I represents the user input, and Classify represents the large language model's performance. Figure 3 (a) shows the classification process indicated by the prompt.
[0068] Existing methods generally lack scalability and cannot be further adjusted according to user needs after generation. Therefore, in Phase 2, the scene editing phase, the text generation capabilities of a large language model are utilized to achieve scene editing. If a user requests modification to the generated scene, the large language model will rewrite the original description according to the requirements (such as changing road types, adding vehicles, or adjusting vehicle behavior), outputting a revised scene description D that best meets the user's needs. This process is denoted as: D = Scene Editing(D, I);
[0069] Where D represents the scene description text, and I contains user modification instructions. Scene editing is performed by a large language model. Figure 3 (b) The rewriting process as prompted. The modified D will be used as input for the next stage.
[0070] Natural language descriptions often contain implicit semantics, and directly generating structured data can easily lead to illusions or missing attributes. Therefore, in stage 3, the semantic understanding stage, an intermediate semantic understanding layer is introduced: by answering a set of predefined questions that are strictly aligned with the data model in Table 1, the unstructured text D is transformed into an explicit, unambiguous intermediate representation M. M consists of the answers to all questions and is output in the form of natural language sentences, reducing the risk of the large language model generating illegal fields. Table 2 shows the one-to-one correspondence between questions and target attributes. Subsequently, M serves as the context input for stage 4, which deterministically generates pattern-compliant structured data S through rule-based extraction. This stage is formalized as follows:
[0071] ;
[0072] Where: M is the answer The intermediate representation is constructed, where D represents the scene description and Understand represents the large language model in... Figure 3 (c) The process of answering predefined questions with prompts.
[0073] In stage 4, the information extraction stage, the large language model summarizes the answers from stage 3 and outputs structured data according to the predefined data model in Table 1. Figure 3 (d) The prompt indicates that each attribute should be given a clear meaning and data type to prevent the generation of non-compliant fields. This process is denoted as:
[0074] S = Extract(M);
[0075] Wherein: S represents the final extracted structured scene data, M represents the intermediate representation, and Extract represents the extraction process of the large language model under corresponding prompts. This stage ensures determinism and consistency, completing the transformation from natural language to structured scene data containing road structure and vehicle information.
[0076] In summary, from classification to editing, then to semantic understanding, and finally to structured extraction, this coherent chain of prompts progressively constrains the model's behavior, guiding unstructured input towards precise, pattern-aligned scene data. This effectively suppresses illusions, improves extraction accuracy, and supports user-driven scene modifications. The extracted structured scene data will serve as input to the subsequent collision planning module, used to generate vehicle trajectories and initial conditions consistent with the scene description, ultimately outputting a concrete, executable scenario.
[0077] Step 3: Construct a vehicle motion constraint model based on the structured scene data, and extract information on the active impactor, the impacted party, and the collision location; generate the theoretical driving path of the vehicle according to the road structure type, where straight-going behavior corresponds to a straight path and turning behavior corresponds to a circular path; calculate the intersection point between different vehicle paths as the collision location, and construct a system of equations with the constraint that "all vehicles arrive at the collision location at the same time" to solve for the initial position and initial velocity parameters of each vehicle along the road direction, so that the collision occurs at the specified location.
[0078] Furthermore, the construction of the vehicle motion constraint model includes:
[0079] Taking the collision time T as a uniform time variable, for any vehicle i, its motion along the driving path satisfies the following relationship: ;
[0080] in, This represents the path length of vehicle i from its initial position to the point of collision. Let represent the initial velocity of vehicle i, and T represent the collision time that all vehicles share.
[0081] The path length It is calculated from the vehicle path function, specifically as follows:
[0082] For a straight path The Euclidean distance from the vehicle along the center line of the lane to the point of collision;
[0083] For circular paths The arc length is calculated from the center, radius, and rotation angle parameters of the circle.
[0084] For all participating vehicles in the scenario, the following time consistency constraint relationship is established:
[0085] , where n is the total number of vehicles i;
[0086] In conjunction with the following constraints:
[0087] The speed of the vehicle that initiates the collision is greater than the speed of the vehicle that is hit.
[0088] The vehicle's initial position is within the effective range of its lane;
[0089] A parametric solution model is constructed based on the aforementioned constraints, and the initial positions of each vehicle are determined using algebraic solutions or numerical iteration methods. and initial velocity .
[0090] Furthermore, in the process of solving the motion parameters, a coordinate system is established with the center of the road or the center of the intersection, the vehicle trajectory is expressed by the path function, and the initial speed parameters are calculated based on the relationship between the path length and the travel time, so as to ensure that all vehicles arrive at the collision position under the same time conditions.
[0091] The extracted structured data contains most of the scene information, but some variables are still missing, such as the initial position and velocity of the vehicles in the lane. Therefore, the collision planning stage of this method solves for the specific values of these variables under the constraints given by the extracted results. Given the road structure R and vehicle information V, the task of collision planning is to determine the longitudinal position s and initial velocity v of each vehicle along the lane direction, ensuring that the active collision vehicle Striker accurately collides with the designated impact part (ImpactPart) of the victim vehicle Victim. This process is formalized as follows:
[0092] ;
[0093] in, Let be the set of all vehicle variables s. Let V be the set of vehicle variables v, and PlanCollision be the collision planning function.
[0094] The collision planning function takes the road structure R and vehicle information V extracted from the text description by a large language model as input. It outputs the initial positions of each vehicle along the road direction. Initial speed of each vehicle ,in: , The number of vehicles in the scene;
[0095] First, the system retrieves the information of the initiating collider, the vehicle being collided with, and the point of impact from the vehicle data, and sets default values for the initial position and speed of each vehicle along the road direction. For scenarios with road structures such as intersections or T-junctions, the system constructs the respective driving trajectories of the two vehicles based on their initial positions and expected behaviors, and then determines the collision location by calculating the intersection of the two trajectories. For other road structures (such as straight roads), the collision point is set based on the vehicle behaviors of the initiating and vehicle being collided with, as well as the point of impact. Finally, the system calculates the longitudinal position and initial speed of the initiating collider and the vehicle being collided with along the road, ensuring that both vehicles arrive at the collision point simultaneously and that the impact occurs at the designated location.
[0096] Table 2: Preset semantic questions and corresponding structured data fields used in the semantic understanding stage of the structured data extraction stage;
[0097]
[0098] Specifically, a coordinate system is established with the center of the intersection as the origin: the positive x-axis is due east, and the positive y-axis is due north. In a "crossroads" or "T-junction" structure, if a vehicle intends to cross the intersection, its trajectory is a straight line running through the intersection, the position of which relative to the center of the intersection is determined by the lane the vehicle is in; if the vehicle is going to turn left, right, or make a U-turn, it travels along an arc, the shape of which is determined by the lane it is entering or leaving. The vehicle's travel path is defined as follows:
[0099] ;
[0100] Where: Line represents a straight path, Direction is the vehicle's direction of travel, LaneOffset is the lateral offset relative to the reference lane, Arc represents a circular path, Center is the coordinates of the center of the circle, Radius is the radius of the circle, EntryAngle is the angle of incidence of the starting point of the circle relative to the center of the circle, TurnAngle describes the angle and direction of the vehicle's travel along the circle from the entrance, Action is the behavior of the vehicle after entering the intersection, GoAcross represents crossing the intersection, and Turn represents turning left, right, or making a U-turn at the intersection.
[0101] Using the collision point obtained in the preceding steps, the algorithm calculates the initial longitudinal position and initial velocity of each vehicle along the lane, under the constraint that "the colliding party and the collided party arrive at the point simultaneously." The calculation formula is as follows:
[0102] ;
[0103] in: For vehicle identification, This represents the starting longitudinal position of the vehicle along the lane. The length of the road segment where the vehicle was initially located. The path length from the starting point to the collision point. The initial speed of the vehicle. This represents the time from the start of the scene to the occurrence of the collision. and The default values are used, and the speed of the vehicle that collides is preset to be higher than that of the vehicle that is collided with.
[0104] After extracting structured data for the natural language description of the functional scenarios and completing the variables through collision planning, the specific scenarios can enter the generation stage. Existing scenario reconstruction methods typically output platform-specific formats, which are difficult to be compatible with any standardized description specifications; while this method directly generates specific scenarios that conform to the ASAM OpenDRIVE and OpenSCENARIO specifications, ensuring interchangeability and reusability across different simulation platforms.
[0105] Step 4: Map the road structure layer to road elements, lane elements, and intersection structures that conform to the preset road description specifications; map the vehicle information layer and motion parameters to behavioral action elements, including speed control actions, lane change actions, and position acquisition actions; combine the above elements to generate a scene file that conforms to the preset simulation standards. The scene file conforms to the specifications of ASAM OpenDRIVE and OpenSCENARIO for the simulation system to call and execute.
[0106] Furthermore, the scene file is described using Extensible Markup Language (EXPLAIN) format, which converts structured data into standardized scene representations through predefined field mapping relationships to achieve cross-simulation platform compatibility.
[0107] The ASAM OpenDRIVE specification defines static road networks in an exchange format for use in driving simulation applications. This specification uses Extensible Markup Language (XML) to describe the structure of elements and their value order, thereby modeling static roads. OpenDRIVE files can contain information such as road geometry, lanes, road markings, and intersections, but do not include traffic participants and moving objects. In contrast, the ASAM OpenSCENARIO specification focuses on describing dynamic content in traffic scenes, such as vehicle, pedestrian, and traffic light states—elements not covered by OpenDRIVE. This specification uses hierarchical elements (events, actions, triggers) to construct scenes and their attributes. OpenSCENARIO currently provides two formats: OpenSCENARIO XML and OpenSCENARIODSL. The former, similar to OpenDRIVE, uses XML files; the latter uses a domain-specific language similar to Python. This paper uses the XML version and leverages existing libraries to convert structured scene descriptions into OpenSCENARIO XML format.
[0108] To generate a road network structure compliant with OpenDRIVE, road structure type and attributes such as direction and number of lanes for each road segment are mapped to corresponding XML elements. Each segment in the road network corresponds to a `road` element, which contains left and right `lane` elements, respectively. For intersections or T-junctions, additional `road` elements are inserted to connect the road segments, clearly distinguishing between turning and straight lanes. Subsequently, this method maps vehicle behavior to `OpenSCENARIO` elements, as shown in Table 3. If a vehicle stays in its current lane or stops, the system associates its behavior with a `SpeedAction` element, using the target speed as a parameter (set to 0 when stopped). If a vehicle will turn at an intersection, an `AcquirePositionAction` element is generated, with the target road ID and lane ID as parameters. Finally, this method merges all converted elements into one OpenDRIVE file and one OpenSCENARIO file, which can be directly read and played back by compatible simulation platforms.
[0109] Step 5: Based on the generated scene, receive new natural language modification instructions from the user, call the scene editing module in the prompt chain to reconstruct the original description, and re-execute the structured extraction, parameter solving and scene generation steps to obtain the updated simulation scene.
[0110] Table 3: Mapping table of vehicle behavior data and standardized elements in the standardized scenario generation stage;
[0111]
[0112] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A large language model-based traffic scene automatic generation and editing method, characterized in that, Includes the following steps: Step 1: Receive natural language description of traffic scene text input or request to modify the generated scene, perform task determination on the input text based on the large language model, and output task type identifier; Step 2: Construct a multi-stage prompt chain that includes task classification, scene editing, semantic understanding, and structured extraction. Perform step-by-step constraint processing on the input text to generate structured scene data. The structured scene data includes a road structure layer for describing the environment and a vehicle information layer for describing dynamic interactions. Step 3: Construct a vehicle motion constraint model based on the structured scene data, extract information on the active impactor, the impacted party, and the collision location; generate the theoretical driving path of the vehicle according to the road structure type, and construct a set of equations with the constraint that all vehicles arrive at the collision location at the same time, and solve for the initial position and initial velocity parameters of each vehicle. Step 4: Map the road structure layer, vehicle information layer, and motion parameters into scene file elements that conform to preset simulation standards, and combine them to generate standardized scene files; Step 5: Based on the generated scene, receive new natural language modification instructions, call the scene editing module in the prompt chain to reconstruct the original description, and re-execute the structured extraction, parameter solving and scene generation steps to obtain the updated simulation scene.
2. The traffic scene automatic generation and editing method based on a large language model according to claim 1, characterized in that, The multi-stage prompt chain specifically includes: Phase 1 is the task classification phase, which determines whether the user's intent is scene generation, scene editing, or other. Phase 2 is the scene editing phase, in which the original scene description is rewritten based on the user's modification requests, and a revised scene description is output. Phase 3 is the semantic understanding phase, which generates intermediate semantic representations by answering pre-set question templates aligned with the structured scene data model; Phase 4 is the information extraction phase, which maps the intermediate semantic representation to structured scene data with a predefined data structure.
3. The method for automatic generation and editing of traffic scenes based on a large language model according to claim 2, characterized in that, The preset question template contains a set of questions targeting road structure attributes and vehicle behavior attributes. Through the one-to-one correspondence between questions and fields, the implicit semantics in natural language are transformed into explicit structured information.
4. The method for automatic generation and editing of traffic scenes based on a large language model according to claim 1, characterized in that, In the structured scene data mentioned above: The road structure layer includes road type, road segment direction, and number of lanes; The vehicle information layer includes the number of vehicles, vehicle behavior sequence, collision relationships, the lane where the vehicle is located, and the relative positions between vehicles.
5. The method for automatic generation and editing of traffic scenes based on a large language model according to claim 1, characterized in that, The specific process of solving for the initial parameters is as follows: A coordinate system is established with the center of the road or the center of the intersection. The vehicle trajectory is expressed by a path function. The initial speed parameters are calculated based on the relationship between the path length and the travel time to ensure that all vehicles arrive at the collision point under the same time conditions.
6. The method for automatic generation and editing of traffic scenes based on a large language model according to claim 5, characterized in that, The path function is determined based on vehicle behavior: If a vehicle's behavior involves crossing an intersection, its trajectory is defined as a straight path. If a vehicle's behavior is to turn left, right, or make a U-turn, its trajectory is defined as a circular arc path, the shape of which is determined by the lane it is exiting and entering.
7. The method for automatic generation and editing of traffic scenes based on a large language model according to claim 1, characterized in that, The standardization mapping process includes: Static mapping of road network: The road type, road segment direction and number of lanes in the road structure layer are mapped to road elements, lane elements and junction structures for connecting road segments in accordance with the ASAM OpenDRIVE specification through preset XML element templates; Participant dynamic mapping: The behavior sequence in the vehicle information layer and the motion parameters calculated in step 3 are mapped into Event, Condition and Action hierarchical elements that conform to the ASAM OpenSCENARIO specification according to the temporal logic.
8. The method for automatic generation and editing of traffic scenes based on a large language model according to claim 7, characterized in that, The dynamic mapping is implemented through a predefined library of behavior operators, including: Single Action Mapping: Maps lane keeping or parking actions to SpeedAction elements and parameterizes the target speed; Composite Action Mapping: Map lane change, turning, or U-turn actions as a sequence of combined elements containing SpeedAction, LaneChangeAction, and AcquirePositionAction, and fill in their dynamic triggering conditions using the solved initial position and speed parameters.