---
title: 'Txt2Sce: Text to OpenSCENARIO Generation'
url: https://www.emergentmind.com/topics/txt2sce
type: topic
---

# Txt2Sce: Text to OpenSCENARIO Generation

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 **Large Language Model (LLM)** parser, a **hierarchically organized scenario repository**, and a **Domain Specific Language (DSL) corpus** to generate simulator-ready scenarios from user text [2503.02911]. 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 [2509.02150]. 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"** [2503.02911], 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"** [2509.02150], 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 [2503.02911], the other on structured mining of real-world accident narratives and combinatorial variant generation [2509.02150].

## 2. System architecture and core representations

The architecture in **Text2Scenario** is described as a **five-stage framework** anchored in the **ASAM OpenSCENARIO** approach [2503.02911]. 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 [2503.02911].

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 [2503.02911]. 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** [2509.02150]. 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)** [2503.02911]. 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 [2503.02911].

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 [2503.02911]. 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 [2509.02150]. 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 [2503.02911]. The paper provides pseudocode under the title **“Algorithm 1: Priority Ranking-based DSL Padding”**, with inputs **DSL material library \(\mathcal{L}\)**, **target DSL-based file \(\mathcal{T}\)**, **LLM scenario representation \(\mathcal{R}\)**, and **action chain of traffic participants \(\mathcal{A}\)**. Static elements are matched first:

- \(\mathcal{T}.\mathrm{Climate}' \leftarrow \mathcal{R}.\mathrm{Climate}\ \mathcal{L}\)
- \(\mathcal{T}.\mathrm{Topology} \leftarrow \mathcal{R}.\mathrm{Topology}\ \mathcal{L}\)
- \(\mathcal{T}.\mathrm{TransportationFacilities} \leftarrow \mathcal{R}.\mathrm{Transportation\ Facilities}\ \mathcal{L} \sim \mathcal{T}.\mathrm{Topology}\)
- \(\mathcal{T}.\mathrm{TemporaryChanges} \leftarrow \mathcal{R}.\mathrm{Temporary\ Changes}\ \mathcal{L} \sim \mathcal{T}.\mathrm{Topology}\)

and so forth, after which dynamic behaviors are concatenated as event chains [2503.02911]. 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 [2503.02911]. 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 \((.xosc)\)** file, although the paper does **not** provide a formal grammar or example DSL code snippet.

The later Txt2Sce work formalizes OpenSCENARIO generation more explicitly [2509.02150]. 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** [2509.02150].

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

\[
\mathrm{Sum}_{sce} = M(b_1) + M(b_1)\times M(b_2) + \dots + \prod_{i=1}^{n} M(b_i)
\]

and approximate complexity \(O(b^n)\) under branching factor \(b\) and depth \(n\) [2509.02150].

## 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)** [2503.02911]. 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** [2503.02911].

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** [2503.02911]. 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%** [2503.02911]. 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 [2503.02911]. 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 [2503.02911]:

| 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 [2503.02911].

The report-based Txt2Sce evaluates a different axis: the generation of scenario families from accident reports [2509.02150]. 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%)** [2509.02150].

## 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 [2503.02911]. **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 [2509.02150]. 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 [2503.02911]. 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 [2509.02150].

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 \(f:\mathrm{NL}\rightarrow\mathrm{DSL}\) mapping is defined, and executability remains imperfect even for the best model [2503.02911]. 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 [2509.02150].

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 [2503.02911; 2509.02150].

Source: https://www.emergentmind.com/topics/txt2sce