pith. sign in

arxiv: 2604.16452 · v2 · pith:RRUT436Xnew · submitted 2026-04-07 · 💻 cs.RO · cs.PL· cs.SY· eess.SY

Compiling OpenSCENARIO 2.1 for Scenario-Based Testing in CARLA

Thoshitha Gamage , Lasanthi Gamage This is my paper

Pith reviewed 2026-05-10 18:23 UTC · model grok-4.3

classification 💻 cs.RO cs.PLcs.SYeess.SY
keywords OpenSCENARIO 2.1CARLA simulatorscenario-based testingcompiler architecturebehavior treesautonomous vehicle simulationDSL translation
0
0 comments X

The pith

A compiler pipeline converts OpenSCENARIO 2.1 scenarios into executable CARLA behavior trees by mapping the standard ontology through a custom registry.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The authors build a multi-pass compiler that takes scenarios written in the OpenSCENARIO 2.1 domain-specific language and turns them into code that runs inside the CARLA simulator. This matters because it lets engineers describe vehicle tests in a declarative, intent-driven way and then execute those tests reproducibly at large scale without depending on legacy parsers or outside logic tools. The pipeline starts with ANTLR4 to build an abstract syntax tree, applies semantic checks in the middle, and ends by generating deterministic behavior trees that call CARLA functions directly. A concrete multi-actor cut-in maneuver with simultaneous actions and changing values demonstrates that the approach handles concurrency and dynamic expressions. The result is a working baseline for standardized scenario-based testing that future performance work can build on.

Core claim

The paper claims that OpenSCENARIO 2.1 scenarios can be translated directly into CARLA-executable py_trees behavior trees through a custom method registry that maps the standardized domain ontology to CARLA's procedural API, eliminating external logic solvers, as validated by a multi-actor cut-in and evasive maneuver that exercises concurrent actions, dynamic mathematical expressions, and asynchronous signaling.

What carries the argument

Multi-pass compiler architecture with ANTLR4 frontend for AST generation, semantic middle-end, and runtime backend that synthesizes py_trees behavior trees from a custom method registry mapping the OpenSCENARIO 2.1 ontology to CARLA functions.

If this is right

  • Standardized OpenSCENARIO 2.1 scenarios become directly runnable in CARLA for reproducible testing.
  • Concurrent actions and asynchronous signaling in multi-actor scenarios can be expressed without additional solvers.
  • The generated behavior trees provide deterministic execution that supports large-scale scenario suites.
  • Python-based implementation creates a baseline that can later be ported to C++ for lower overhead.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The registry-based mapping could be reused or extended to connect OpenSCENARIO 2.1 with other open simulators that expose procedural APIs.
  • Automated checks during the semantic middle-end could be expanded to catch timing or safety violations before runtime.
  • Scaling the approach to thousands of scenarios would depend on reducing Python overhead through the suggested C++ path.

Load-bearing premise

A custom method registry can map the full OpenSCENARIO 2.1 ontology to CARLA's procedural API without external logic solvers or loss of expressiveness for concurrent and dynamic behaviors.

What would settle it

Execution of the compiled cut-in scenario in CARLA that produces mismatched actor timings, failed concurrent actions, or incorrect handling of dynamic expressions would show the mapping is incomplete.

Figures

Figures reproduced from arXiv: 2604.16452 by Lasanthi Gamage, Thoshitha Gamage.

Figure 1
Figure 1. Figure 1: The 3-stage OSC2 Execution Pipeline mapping DSL definitions to CARLA behaviors. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Simulation state following the declarative initialization [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Phase 2 execution: The ego vehicle concurrently exe [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Phase 5 execution: Both actors synchronize their de [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
read the original abstract

While the ASAM OpenSCENARIO 2.1 Domain-Specific Language (DSL) enables declarative, intent-driven authoring for Scenario-Based Testing (SBT), its integration into open-source simulators like CARLA remains limited by legacy parsers. We propose a multi-pass modern compiler architecture that translates the OpenSCENARIO 2.1 DSL directly into executable CARLA behaviors. The pipeline features an ANTLR4 frontend for Abstract Syntax Tree (AST) generation, a semantic middle-end, and a runtime backend that synthesizes deterministic py_trees behavior trees. Mapping the standardized domain ontology directly to CARLA's procedural API via a custom method registry eliminates the need for external logic solvers. A demonstrative multi-actor cut-in and evasive maneuver, selected from a wider suite of validated scenarios, confirms the compiler's ability to process concurrent actions, dynamic mathematical expressions, and asynchronous signaling. This framework establishes a functional baseline for reproducible, large-scale SBT, paving the way for future C++ optimizations to mitigate current Python-based computational overhead.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper proposes a multi-pass compiler pipeline using ANTLR4 for AST generation, a semantic middle-end, and a py_trees backend to translate OpenSCENARIO 2.1 DSL scenarios directly into executable behaviors for the CARLA simulator. A custom method registry maps the DSL ontology to CARLA's procedural API without external logic solvers. Validation is provided via a single demonstrative multi-actor cut-in and evasive maneuver scenario that exercises concurrent actions, dynamic expressions, and asynchronous signaling, positioning the work as a functional baseline for reproducible scenario-based testing.

Significance. If the mapping generalizes beyond the single example, the architecture could establish a reproducible baseline for integrating the standardized OpenSCENARIO 2.1 DSL with open-source simulators like CARLA, enabling large-scale SBT without reliance on legacy parsers or external solvers. The direct translation to deterministic behavior trees and avoidance of logic solvers are notable strengths for determinism and simplicity.

major comments (3)
  1. [Abstract and evaluation] Abstract and evaluation section: The central claim that the compiler processes concurrent actions, dynamic mathematical expressions, and asynchronous signaling (and thus establishes a functional baseline for the full DSL) rests on a single multi-actor demonstrator selected from an unspecified wider suite. No coverage metrics, error analysis, or additional scenarios are provided to substantiate that the custom method registry and middle-end preserve semantics for the complete OpenSCENARIO 2.1 ontology.
  2. [Compiler architecture (middle-end and registry)] Description of the semantic middle-end and custom method registry: The paper asserts that the registry enables direct mapping to CARLA's API without external solvers or loss of expressiveness for concurrent/dynamic behaviors, but provides no registry contents, semantic rules, or translation examples. This makes it impossible to verify the no-loss claim or assess whether external logic is implicitly required for general cases.
  3. [Evaluation and results] No quantitative evaluation: The manuscript offers no metrics on translation success rate, runtime overhead of the Python-based py_trees backend, or comparison against prior OpenSCENARIO parsers, which weakens the claim of a viable baseline for large-scale SBT.
minor comments (2)
  1. [Abstract] Clarify the scope of the 'wider suite of validated scenarios' and whether the demonstrated cut-in maneuver is representative or exhaustive.
  2. [Conclusion] The paper mentions future C++ optimizations but does not discuss current performance bottlenecks or profiling data from the Python implementation.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the thoughtful and constructive review. We address each major comment point by point below, providing clarifications where the manuscript may have been unclear and indicating revisions that will be incorporated to strengthen the paper.

read point-by-point responses

  1. Referee: [Abstract and evaluation] Abstract and evaluation section: The central claim that the compiler processes concurrent actions, dynamic mathematical expressions, and asynchronous signaling (and thus establishes a functional baseline for the full DSL) rests on a single multi-actor demonstrator selected from an unspecified wider suite. No coverage metrics, error analysis, or additional scenarios are provided to substantiate that the custom method registry and middle-end preserve semantics for the complete OpenSCENARIO 2.1 ontology.

    Authors: The referee correctly notes that the evaluation centers on a single demonstrative scenario. This scenario was deliberately chosen as it exercises the key DSL features cited (concurrent actions via parallel behavior-tree composites, dynamic expressions via runtime Python evaluation, and asynchronous signaling via event nodes). The manuscript states that the example is drawn from a wider suite of validated scenarios; however, space limitations prevented full enumeration. We will revise the evaluation section to include concise descriptions of two additional scenarios from the suite and a qualitative discussion of how the middle-end and registry handle their constructs. We agree that coverage metrics and systematic error analysis would further substantiate the baseline claim, but these were outside the scope of the current functional demonstration; we will explicitly note this limitation and identify it as future work. revision: partial

  2. Referee: [Compiler architecture (middle-end and registry)] Description of the semantic middle-end and custom method registry: The paper asserts that the registry enables direct mapping to CARLA's API without external solvers or loss of expressiveness for concurrent/dynamic behaviors, but provides no registry contents, semantic rules, or translation examples. This makes it impossible to verify the no-loss claim or assess whether external logic is implicitly required for general cases.

    Authors: We accept that the absence of explicit registry contents and translation examples limits verifiability. The method registry provides direct one-to-one mappings from OpenSCENARIO 2.1 domain elements to CARLA procedural API calls, while the middle-end performs semantic checks (type consistency, expression simplification) without invoking external solvers. Concurrency and dynamic behavior are realized entirely within deterministic py_trees trees. To address the concern, we will add an appendix containing (i) a representative subset of registry mappings and (ii) concrete translation examples for concurrent actions (Parallel nodes), dynamic expressions (runtime-evaluated leaves), and asynchronous signaling. This will allow readers to inspect the claimed direct mapping and absence of implicit external logic. revision: yes

  3. Referee: [Evaluation and results] No quantitative evaluation: The manuscript offers no metrics on translation success rate, runtime overhead of the Python-based py_trees backend, or comparison against prior OpenSCENARIO parsers, which weakens the claim of a viable baseline for large-scale SBT.

    Authors: The referee is right that quantitative metrics are missing. The manuscript prioritizes architectural description and functional demonstration over benchmarking. We will augment the results section with measured compilation times (ANTLR frontend, middle-end, py_trees synthesis) and CARLA execution overhead for the presented scenario. Translation success is 100 % on the validated suite; we will state this explicitly. Direct runtime comparisons with prior parsers are difficult because many are proprietary or simulator-specific, but we will expand the related-work discussion to highlight qualitative distinctions. These additions will better support the baseline claim while acknowledging the current Python implementation's overhead as motivation for the planned C++ backend. revision: partial

Circularity Check

0 steps flagged

No circularity detected in compiler architecture description

full rationale

The paper describes a multi-pass compiler pipeline (ANTLR4 frontend for AST, semantic middle-end, py_trees backend) that maps OpenSCENARIO 2.1 ontology to CARLA via a custom method registry. No equations, fitted parameters, self-definitional constructs, or load-bearing self-citations appear in the provided text. The central claim of a functional baseline for SBT is presented as an engineering translation without reduction to inputs by construction or prior author results. The single demonstrative scenario is offered as confirmation of processing capabilities rather than a statistical prediction or renamed known result. The derivation chain is self-contained as an architectural proposal.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

The approach assumes ANTLR4 can parse the full DSL without ambiguity, that CARLA's API exposes all required procedural primitives, and that behavior trees can faithfully encode the DSL's concurrency and timing semantics.

axioms (2)
  • domain assumption ANTLR4 grammar for OpenSCENARIO 2.1 produces a complete and unambiguous AST
    Invoked in the frontend description; no grammar provided or validated in the abstract.
  • domain assumption CARLA procedural API plus custom registry covers all OpenSCENARIO 2.1 actions without external solvers
    Central to eliminating logic solvers; stated as a design choice but unproven beyond the demo.
invented entities (1)
  • Custom method registry no independent evidence
    purpose: Direct mapping from OpenSCENARIO ontology to CARLA API calls
    New component introduced to avoid external solvers; no independent evidence of completeness provided.

pith-pipeline@v0.9.0 · 5488 in / 1434 out tokens · 48171 ms · 2026-05-10T18:23:06.376561+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

17 extracted references · 17 canonical work pages

  1. [1]

    ASAM OpenSCENARIO XML, 2020

    ASAM. ASAM OpenSCENARIO XML, 2020. 1

    work page 2020

  2. [2]

    ASAM OpenSCENARIO DSL 2.1.0, 2024

    ASAM. ASAM OpenSCENARIO DSL 2.1.0, 2024. 1, 2, 4

    work page 2024

  3. [3]

    Declarative Scenario-based Testing with RoadLogic,

    Ezio Bartocci, Alessio Gambi, Felix Gigler, and Dejan Nick- ovic. Declarative Scenario-based Testing with RoadLogic. arXiv preprint arXiv:2603.09455, 2026. 2

    work page arXiv 2026

  4. [4]

    The Y ASE Framework: Holistic Scenario Modeling with Behav- ior Trees

    Max Paul Bauer, Anthony Ngo, and Michael Resch. The Y ASE Framework: Holistic Scenario Modeling with Behav- ior Trees. In2021 IEEE 94th Vehicular Technology Confer- ence (VTC2021-Fall), pages 1–7, 2021. 2

    work page 2021

  5. [5]

    Text2Scenario: Text-driven scenario generation for autonomous driving test

    Xuan Cai, X Bai, Zhiyong Cui, D Xie, D Fu, H Yu, and Y Ren. Text2Scenario: Text-Driven Scenario Gen- eration for Autonomous Driving Test.arXiv preprint arXiv:2503.02911, 2025. 2

    work page arXiv 2025

  6. [6]

    ScenarioRunner for CARLA, 2024

    CARLA Team. ScenarioRunner for CARLA, 2024. 1

    work page 2024

  7. [7]

    CARLA: An Open Urban Driv- ing Simulator

    Alexey Dosovitskiy, German Ros, Felipe Codevilla, Antonio Lopez, and Vladlen Koltun. CARLA: An Open Urban Driv- ing Simulator. InProceedings of the 1st Annual Conference on Robot Learning, pages 1–16, 2017. 1, 4

    work page 2017

  8. [8]

    Scenic: A Language for Scenario Specification and Scene Generation

    Daniel J Fremont, Tommaso Dreossi, Shromona Ghosh, Xi- angyu Yue, Alberto L Sangiovanni-Vincentelli, and Sanjit A Seshia. Scenic: A Language for Scenario Specification and Scene Generation. InProceedings of the 40th ACM SIG- PLAN Conference on Programming Language Design and Implementation, pages 63–78, 2019. 2

    work page 2019

  9. [9]

    System- level Simulation-based Verification of Autonomous Driving Systems with the VIV AS Framework and CARLA Simula- tor.Science of Computer Programming, 242:103253, 2025

    Srajan Goyal, Alberto Griggio, and Stefano Tonetta. System- level Simulation-based Verification of Autonomous Driving Systems with the VIV AS Framework and CARLA Simula- tor.Science of Computer Programming, 242:103253, 2025. 2

    work page 2025

  10. [10]

    Driving to Safety: How Many Miles of Driving Would it take to Demonstrate Au- tonomous Vehicle Reliability?Transportation Research Part A: Policy and Practice, 94:182–193, 2016

    Nidhi Kalra and Susan M Paddock. Driving to Safety: How Many Miles of Driving Would it take to Demonstrate Au- tonomous Vehicle Reliability?Transportation Research Part A: Policy and Practice, 94:182–193, 2016. 1

    work page 2016

  11. [11]

    Pierre R. Mai. Pmsf py-osc2 framework, 2024. 2

    work page 2024

  12. [12]

    Paracosm: A language and tool for testing autonomous driving systems.arXiv preprint arXiv:1902.01084, 2019

    Rupak Majumdar, Aman Mathur, Marcus Pirron, Laura Stegner, and Damien Zufferey. Paracosm: A language and tool for testing autonomous driving systems.arXiv preprint arXiv:1902.01084, 2019. 2

    work page arXiv 1902

  13. [13]

    The Prag- matic Bookshelf, Raleigh, North Carolina, 2013

    Terence Parr.The Definitive ANTLR 4 Reference. The Prag- matic Bookshelf, Raleigh, North Carolina, 2013. Torrossa Resource ID: 5241753. 1

    work page 2013

  14. [14]

    GeoScenario: An open DSL for Autonomous Driving Scenario Representation

    Rodrigo Queiroz, Christian Berger, and Krzysztof Czar- necki. GeoScenario: An open DSL for Autonomous Driving Scenario Representation. In2019 IEEE Intelligent Vehicles Symposium (IV), pages 287–294. IEEE, 2019. 2

    work page 2019

  15. [15]

    LeGEND: A Top-Down Ap- proach to Scenario Generation of Autonomous Driving Sys- tems Assisted by Large Language Models

    Shuncheng Tang, Zhenya Zhang, Jixiang Zhou, Lei Lei, Yuan Zhou, and Yinxing Xue. LeGEND: A Top-Down Ap- proach to Scenario Generation of Autonomous Driving Sys- tems Assisted by Large Language Models. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 1497–1508, 2024. 2

    work page 2024

  16. [16]

    BeSimulator: A Large Language Model Powered Text-based Behavior Simulator,

    Jianan Wang, Bin Li, Jingtao Qi, Xueying Wang, Fu Li, and Hanxun Li. BeSimulator: A Large Language Model Powered Text-based Behavior Simulator.arXiv preprint arXiv:2409.15865, 2024. 2

    work page arXiv 2024

  17. [17]

    Chat2scenario: Scenario Extraction from Dataset through Utilization of Large Language Model

    Yongqi Zhao, Wenbo Xiao, Tomislav Mihalj, Jia Hu, and Arno Eichberger. Chat2scenario: Scenario Extraction from Dataset through Utilization of Large Language Model. In 2024 IEEE intelligent vehicles symposium (IV), pages 559–

    work page 2024