Txt2Sce: Text to OpenSCENARIO Generation

• Txt2Sce is a text-driven framework that automates the conversion of detailed natural language descriptions into standardized OpenSCENARIO files for autonomous driving validation.
• It employs advanced LLM parsing techniques, including Few-Shot, Chain-of-Thought, and Syntax Alignment, to transform inputs into hierarchically organized scenario representations.
• The approach integrates accident report mining and controlled mutation operators to generate reproducible scenario families, enhancing the effectiveness of ADS testing.

Searching arXiv for the cited Txt2Sce papers to ground the article in current arXiv records. Autonomous-driving research uses Txt2Sce to denote text-driven scenario generation methods that transform natural-language descriptions into executable test scenarios, typically in OpenSCENARIO format, for simulator-based validation of Autonomous Driving Systems (ADSs). In the arXiv literature, the term is most directly associated with Text2Scenario, a framework that combines a LLM parser, a hierarchically organized scenario repository, and a Domain Specific Language (DSL) corpus to generate simulator-ready scenarios from user text (Cai et al., 4 Mar 2025). A later work with the same shorthand extends the idea from general textual descriptions to textual accident reports, using LLM extraction, schema- and map-constrained generation, and a derivation-based scenario tree to produce large families of OpenSCENARIO files for ADS testing (Ji et al., 2 Sep 2025). Across these formulations, Txt2Sce denotes a shift from labor-intensive manual scenario authoring toward standardized, text-conditioned, closed-loop test generation.

1. Definition and problem setting

Txt2Sce addresses a persistent bottleneck in autonomous-driving validation: the conversion of high-level scenario descriptions into precise, executable simulation assets. In "Text2Scenario" (Cai et al., 4 Mar 2025), the problem is framed around the fact that manual creation of AD test scenarios is laborious and time-consuming, and that even simple multi-actor scenes can exceed 200 lines of DSL code, requiring substantial expertise for correctness and maintenance. The framework therefore aims to automate scenario generation while preserving control, standardization, and compatibility.

The 2025 report-based formulation, "Txt2Sce: Scenario Generation for Autonomous Driving System Testing Based on Textual Reports" (Ji et al., 2 Sep 2025), situates the same problem in the context of accident analysis. There, textual accident reports are treated as compact sources of high-level causal structure, temporal order, and inter-actor interactions, in contrast to methods that rely on visual data and simulator-specific interfaces. The output target is explicitly OpenSCENARIO, with the stated goal of improving portability across platforms and ADS implementations, reusability and reproducibility, and compatibility with tooling such as schema validation.

A plausible implication is that the two works describe closely related but distinct operating points within the same research direction: one centered on free-form scenario descriptions (Cai et al., 4 Mar 2025), the other on structured mining of real-world accident narratives and combinatorial variant generation (Ji et al., 2 Sep 2025).

2. System architecture and core representations

The architecture in Text2Scenario is described as a five-stage framework anchored in the ASAM OpenSCENARIO approach (Cai et al., 4 Mar 2025). The pipeline enumerates six pivotal scenario elements, parses user text into a logical scenario, assembles scenario primitives into a DSL script, executes the scenario in Carla, and evaluates the ADS using embedded metrics. The six elements are:

1. Road Topology
2. Transportation Facilities
3. Temporary Changes
4. Traffic Participants
5. Climate
6. Ego Vehicle

The logical scenario representation is a dictionary-style structure keyed by these six components. Static elements include topology, lanes, road markers, traffic signs, temporary changes, climate, and ego type or position. Dynamic elements include traffic-participant type, position relation to the ego, oracle behaviors such as longitudinal and lateral maneuvers, and global behavior such as turning or going forward (Cai et al., 4 Mar 2025).

A central design choice is the use of a hierarchical scenario repository. The repository is organized as a six-tier hierarchy and enumerates component values such as intersection, roundabout, T-junction, single, two-lanes, three-lanes, traffic signs such as traffic light, stop sign, speed limit, temporary objects such as cone barrel, warning sign, bucket, and climate attributes including sunny, rainy, snowy, with density and time qualifiers (Cai et al., 4 Mar 2025). Dynamic dependencies are explicitly structured: Climate and Topology have highest precedence, while other components must conform to them.

The report-based Txt2Sce uses a different intermediate organization. It first builds schema/map databases, then converts text into a seed scenario, validates it, disassembles it into mutable blocks, mutates those blocks, and reassembles them into a derivation-based scenario tree (Ji et al., 2 Sep 2025). There, the scenario is formalized as

• $E$: environment,
• $R$: road topology,
• $A$: actors,
• $M$: maneuvers or events,
• $P$: parameters.

This suggests that the later work moves from single-scenario synthesis toward structured exploration of scenario families.

3. LLM parsing and prompt engineering

In Text2Scenario, the LLM is used as a parser with a prompt-engineered pipeline consisting of Role Setting → Few-Shot (FS) → Chain-of-Thought (CoT) → Syntax Alignment Checking (SAC) → Self-Consistency (SC) (Cai et al., 4 Mar 2025). The model is positioned as an “expert in autonomous driving testing”, is given input-output examples, is guided through reasoning steps, is aligned to repository syntax and semantics, and is stabilized through majority voting over multiple inference chains.

The paper attributes distinct functions to these stages. Few-Shot injects the repository dictionary and exemplar mappings. Chain-of-Thought is used to mitigate ambiguity and infer implicit semantics. Syntax Alignment Checking performs both knowledge validation and syntax harmonization, for example normalizing expressions such as “go forward” instead of “straight forward” while preserving novel elements if no repository match exists. Self-Consistency aggregates multiple inference chains, with an example of $n=10$ paths given in the description (Cai et al., 4 Mar 2025).

A representative example is the text “Unprotected left turn for traffic vehicle.” The reasoning sequence described in the paper maps “left turn” to an intersection, excludes a protective traffic light, and infers “yield” as the longitudinal oracle because unprotected left turns require the turning vehicle to yield to oncoming traffic (Cai et al., 4 Mar 2025). No explicit formal function $f:\mathrm{NL}\rightarrow\mathrm{DSL}$ is defined; instead, the mapping proceeds through the dictionary-like representation $\mathcal{R}$ and subsequent DSL assembly.

The report-based Txt2Sce likewise uses an LLM, but with a multi-turn dialogue designed around extraction from accident narratives (Ji et al., 2 Sep 2025). The turns identify participants, extract ordered pre-crash events, express positions through seven relative relationships $R1$–$R7$, and recover environment and timing information before producing structured JSON. The prompts are constrained by an entity database encoding documented OpenSCENARIO elements, types, cardinalities, and valid ranges. This is paired with post-processing and xmllint validation.

4. DSL assembly, OpenSCENARIO generation, and execution

A defining feature of Text2Scenario is its priority-based DSL assembly algorithm (Cai et al., 4 Mar 2025). The paper provides pseudocode under the title “Algorithm 1: Priority Ranking-based DSL Padding”, with inputs DSL material library $R$0, target DSL-based file $R$1, LLM scenario representation $R$2, and action chain of traffic participants $R$3. Static elements are matched first:

• $R$4
• $R$5
• $R$6
• $R$7

and so forth, after which dynamic behaviors are concatenated as event chains (Cai et al., 4 Mar 2025). The material library includes prior knowledge, weather APIs, maps, routes, and event fragments such as acceleration, deceleration, lane-change, and synchronization. Complex maneuvers are decomposed into action chains; for instance, “overtaking” becomes “change lanes → accelerate → change lanes → continue at speed”.

The assembler can append an autopilot fragment if the vehicle has not reached its target after executing the chain (Cai et al., 4 Mar 2025). Route search is randomized over candidate start and target waypoints, with interaction labels such as cut-in used to feed assembly. The final output is an executable OpenSCENARIO $R$8 file, although the paper does not provide a formal grammar or example DSL code snippet.

The later Txt2Sce work formalizes OpenSCENARIO generation more explicitly (Ji et al., 2 Sep 2025). It uses a template skeleton prepared from a selected OpenDRIVE map, inserts LLM-generated XML fragments into storyboard and actions, validates them with XSD, and executes them using CARLA scenario_runner. After seed generation, the scenario is disassembled into blocks, mutated through operator families, and reassembled according to a fixed insertion order: weather → NPCs → signals → events → obstacles (Ji et al., 2 Sep 2025).

The mutation operators include Target Speed, Transition Dynamics, Vehicle Performance, Waypoint, Dimension, NPC Category, Weather, Traffic Signal, and Obstacle Insertion mutations. The complexity is described as exponential in the number of blocks without pruning, with total scenarios

$R$9

and approximate complexity $A$0 under branching factor $A$1 and depth $A$2 (Ji et al., 2 Sep 2025).

5. Evaluation methodology and empirical results

The evaluation of Text2Scenario uses 92 scenario descriptions selected from NHTSA pre-collision scenarios (23), C-NCAP 2024 ADAS protocol (17), and custom expert texts (52), generating 368 scenarios across six Carla maps (urban, suburban, rural) (Cai et al., 4 Mar 2025). The LLMs evaluated are Yi-34B-Chat, GPT-3.5, and GPT-4, with ablations across parser configurations from LLM-BP through LLM-BP-FS-CoT-SAC-SC. The systems under test are Autoware, Apollo, Interfuser, and Dora-RS.

The evaluation metrics include element-level parsing accuracy, scenario feasibility, semantic fidelity, driving rationality, construction time, and ADS violations such as rule violations, collisions, and timeout (Cai et al., 4 Mar 2025).

The reported element-level parsing accuracies are summarized below.

Model	Average parsing accuracy
GPT-4	0.92
Yi-34B	0.88
GPT-3.5	0.80

For GPT-4, the paper reports Topology: 0.95, Lanes: 0.98, Traffic signs: 1.00, Road markers: 0.97, Temporary change type/position: 0.95/0.92, Traffic participant type/position: 0.98/0.83, Oracles (longitudinal/lateral): 0.74/0.77, Global behavior: 0.83, Climate type/density/time: 0.99/0.97/0.95, and Ego type/position/global behavior: 0.99/0.95/0.86 (Cai et al., 4 Mar 2025). The paper explicitly notes that LLMs excel at explicit static elements, whereas dynamic multi-actor behaviors are harder.

Feasibility results show substantial model dependence: GPT-4: 87.31% success; Yi-34B: 5.47%; GPT-3.5: 20.21% (Cai et al., 4 Mar 2025). Human experts are said to have near-perfect formation rates because of iterative debugging, whereas the LLM-based pipeline lacks a closed-loop feasibility check. Human evaluation over 23 scenarios yielded semantic fidelity 0.97 and driving rationality 0.95, with ICC consistency 0.92 and 0.76, respectively (Cai et al., 4 Mar 2025). Construction time was approximately 15s for GPT-3.5, 55s for GPT-4, 130s for Yi-34B, versus >600s on average for human experts.

The compatibility study reports 533 safety violations across the 368 generated scenarios, distributed as follows (Cai et al., 4 Mar 2025):

SUT	Rule	Collisions	Timeout
Apollo	31	23	49
Autoware	37	11	19
Interfuser	76	49	60
Dora-RS	61	67	50

The paper gives illustrative cases: Apollo collided due to poor motorcycle detection at dusk; Autoware violated a solid line in a roundabout; Interfuser clipped a vehicle during lane change or overtake; Dora-RS failed to detect a roadside door opening (Cai et al., 4 Mar 2025).

The report-based Txt2Sce evaluates a different axis: the generation of scenario families from accident reports (Ji et al., 2 Sep 2025). It begins from California DMV Autonomous Vehicle Collision Reports, collects 387 PDFs, uses 180 for LLM interpretation, and retains 33 seed scenarios after clustering and filtering. This yields 33 scenario trees, 4,373 valid OpenSCENARIO files, 1,832 runnable files after pruning, and 1,519 scenario categories. Testing Autoware in CARLA surfaces 1,788 unexpected behaviors, broken down into Failure to Start: 185 (10.4%), Misinterpretation of Signals/Obstacles: 58 (3.3%), Collisions: 179 (10.2%), Path Planning Failures: 223 (12.6%), and Smoothness Issues: 1,143 (64.8%) (Ji et al., 2 Sep 2025).

6. Comparative context, limitations, and research significance

The main comparison in Text2Scenario is with methods that either require manual setup or avoid standardized DSL outputs (Cai et al., 4 Mar 2025). LawBreaker converts traffic laws to STL specs and fuzzes violations but still requires manual scenario initialization. DriveDreamer-2 generates multi-perspective videos and avoids DSL, but lacks closed-loop interaction and targets planning-focused end-to-end ADS. CTG++ and ScenarioNet provide language-guided traffic simulation or SUMO scenario generation, but the paper states that controllability and DSL standardization remain limited. Txt2Sce is distinguished by generating standardized, manipulable OpenSCENARIO DSL files from natural language, enabling closed-loop simulation with ADS stacks and precise evaluation.

The report-based Txt2Sce makes a related claim at the level of portability and standardization (Ji et al., 2 Sep 2025). It contrasts itself with methods such as SoVAR and LeGEND, which generate simulator-specific perception data and are tightly coupled to LGSVL, whereas Txt2Sce produces standardized OpenSCENARIO artifacts.

The limitations reported in the literature are consistent across the two autonomous-driving variants. Text2Scenario identifies robustness of the LLM, scalability constraints due to reliance on repository components and hand-curated DSL fragments, and a format limitation because the current output targets OpenSCENARIO (Cai et al., 4 Mar 2025). The later work emphasizes text ambiguity and LLM errors, incomplete mapping from report detail to scenario formalism, simulator fidelity, prompt sensitivity, and the risk that aggressive mutation ranges may produce unrealistic conditions (Ji et al., 2 Sep 2025).

A common misconception would be to treat Txt2Sce as a fully end-to-end text-to-code generator with guaranteed semantic correctness. The papers do not support that characterization. In Text2Scenario, no formal DSL grammar is provided, no explicit $A$3 mapping is defined, and executability remains imperfect even for the best model (Cai et al., 4 Mar 2025). In the report-based system, technical validity is supported by schema checks and simulation sanity, but semantic validity still depends partly on manual checks and execution outcomes (Ji et al., 2 Sep 2025).

Taken together, these works position Txt2Sce as a research program in which natural language becomes a first-class interface for ADS scenario authoring, while hierarchical repositories, OpenSCENARIO schemas, map constraints, and derivation structures supply the formal control needed for reproducible testing. This suggests a broader methodological significance: text is used not merely as documentation, but as a structured source for generating executable validation artifacts and, in the derivation-tree formulation, for isolating the conditions that trigger ADS failures (Cai et al., 4 Mar 2025, Ji et al., 2 Sep 2025).