Autonomous Vehicles; Co-Simulation; CARLA; OpenSCENARIO; V2X Communication; Robotics

1 Introduction↩︎

Evaluating Autonomous Vehicles (AVs) requires verification methodologies that scale beyond empirical field testing [1]. Scenario-Based Testing (SBT) solves this limitation by isolating and executing traffic interactions within virtual environments such as CARLA [2]. However, the validity of SBT hinges strictly upon the fidelity of the underlying simulation environment. High-fidelity, deterministic execution becomes especially critical when integrating complex configurations, such as evaluating simulated Electronic Control Units (ECUs) to analyze the causal link where phantom object detection leads to phantom braking. Consequently, any deviation from this fidelity—such as simulation-layer execution latencies or inaccurate asynchronous event handling—fundamentally invalidates the intended test parameters.

Standardizing scenario definitions ensures test reproducibility across platforms. Early standards, such as ASAM OpenSCENARIO XML 1.x [3], optimized predictable trajectory playback but lacked the expressiveness required for complex scenario logic. To resolve this, ASAM finalized the OpenSCENARIO Domain-Specific Language (DSL) v2.1 in 2024 [4]. The declarative DSL separates abstract, logical, and concrete layers. It replaces rigid parameterization with native variables, semantic validation, and composable behaviors, reducing script length and complexity. Table 1 contrasts key structural and operational differences between the XML and DSL schemas.

Integrating the v2.x DSL into continuous simulators like CARLA presents an implementation gap. Existing interpreter-based orchestration frameworks, such as ScenarioRunner [5], predominantly support the legacy XML standard, offering compatibility restricted only to early, deprecated DSL drafts. Consequently, these legacy tools cannot parse the finalized, bifurcated v2.x standard libraries (types.osc and domain.osc) and fail to maintain deterministic execution loops for concurrent actions. The resulting execution drift prevents researchers from leveraging the v2.x standard for high-fidelity validation.

Addressing this gap, OSC2Runner completely replaces legacy interpretation with a ground-up orchestration rewrite, introducing an OpenSCENARIO v2.2 compliant transpiler architecture for CARLA. Designed to fully support the bifurcated standard, the architecture formalizes scenario translation as a multi-stage transpilation pipeline. The ANTLR4 [6] frontend parses the EBNF grammar to generate a type-safe Abstract Syntax Tree (AST). The backend synthesizes this AST into dynamic Behavior Trees (py_trees) [7], bypassing static script generation. This synthesis maps domain modifiers directly to CARLA’s atomic behaviors, ensuring strict spatiotemporal adherence for high-fidelity, closed-loop simulation.

2 Related Work↩︎

The OpenSCENARIO DSL formalization joins an established body of domain-specific languages for autonomous driving. While frameworks such as Scenic [8], GeoScenario [9], and Paracosm [10] provide stochastic scene generation and parameterized test design, their non-standardized semantics limit interoperability and hinder the deterministic execution required for high-fidelity validation. In contrast, the OpenSCENARIO DSL integrates spatial, temporal, and behavioral semantics into a unified framework. This standardization facilitates interoperability with the ASAM OpenX ecosystem and establishes the structural prerequisites for co-simulation architectures.

Although ANTLR4-based lexical analyzers like py-osc2 [11] successfully convert the DSL grammar into an AST, translating this declarative logic into continuous simulation execution remains a bottleneck. For example, RoadLogic [12] translates the DSL into a symbolic automaton and uses Answer Set Programming (ASP) to resolve planning constraints. However, outsourcing execution to an external logic solver introduces asynchronous latencies, compromising the tick-by-tick time synchronization required by continuous simulators.

To circumvent external solvers, other architectures incorporate Behavior Trees to manage state execution natively. The YASE framework [13] employs a multi-stage transpiler mapping an AST to a behavior tree, functioning as an agnostic middle-end within the openPASS ecosystem. Similarly, VIVAS [14] and BeSimulator [15] demonstrate the efficacy of py_trees for natively managing dynamic agent states in CARLA. Building upon these peer-reviewed methodologies, OSC2Runner functions as a direct, native transpiler that maps domain.osc actions strictly to CARLA’s localized Python API. Bypassing intermediate solvers entirely allows the architecture to maintain absolute spatiotemporal synchronization.

Recent literature also explores Large Language Models (LLMs) for automated DSL script generation. Frameworks including Text2Scenario [16], LCTGen [17], Chat2Scenario [18], and LeGEND [19] utilize models like GPT-4 to output scenario scripts from natural language or unstructured traffic data. However, these generative approaches focus exclusively on frontend authoring; they inherently assume the existence of a deterministic backend transpiler capable of executing the resulting scripts without behavioral artifacts. By providing this missing execution engine, OSC2Runner renders LLM-driven generation pipelines viable for safety-critical evaluation.

3 Transpiler Architecture for High-Fidelity Execution↩︎

Translating OpenSCENARIO v2.x (hereafter OSC2) into executable simulation commands must prevent execution drift and maintain strict spatiotemporal synchronization, in order to achieve the determinism required for high-fidelity SBT. This section details a multi-pass transpiler architecture designed specifically to map OSC2 declarations to CARLA behaviors without loss of execution integrity. As illustrated in Figure 1, the pipeline operates across three primary stages: Frontend Parsing, Semantic Analysis, and Backend Execution Generation. A dynamic Runtime Context Manager supports this pipeline, ensuring the abstract OSC2 domain model maps accurately to CARLA’s continuous physics and navigation engines.

3.1 Lexing and AST Generation↩︎

Execution fidelity relies fundamentally on exact structural ingestion. The pipeline’s Frontend manages lexical and syntax analysis. It utilizes ANTLR4 to process the raw OSC2 source code against the standard Extended Backus-Naur Form (EBNF) grammar, generating a raw parse tree. To bridge the concrete syntax and the transpiler’s internal logic, an ASTTransformer applies the Visitor pattern to the parse tree, generating a typed Abstract Syntax Tree (AST). The pipeline constructs the AST using strongly-typed data structures to enforce compile-time type safety. This initial transformation evaluates syntax exclusively; it defers scoping, type checking, and symbol resolution. This isolation guarantees that the AST accurately models the source structure, establishing a structurally sound baseline that prevents cascading, non-deterministic execution failures in downstream simulation.

3.2 Semantic Analysis and Symbol Resolution↩︎

A syntactically valid scenario may still violate logical or physical constraints once instantiated in the simulation. To enforce domain adherence, the pipeline passes the syntactic AST to the ModelBuilder for Semantic Analysis. Because OSC2 employs hierarchical ontological structures—such as actor inheritance (e.g., vehicle inheriting from traffic_participant) and forward declarations—the semantic analyzer executes a two-pass methodology:

1. Definition Pass: The transpiler traverses the AST to populate the Symbol Table. It constructs a global scope alongside nested lexical scopes for namespaces, structures, and actors, registering all named entities (variables, methods, actions, and modifiers) as abstract symbols.

2. Resolution Pass: A secondary traversal binds these symbols to their corresponding type definitions, resolves inheritance chains, and evaluates domain constraints. This phase safely resolves implicit fallbacks to standard library domains (e.g., the stdtypes namespace from types.osc), ensuring that simulated actors inherit the correct physical properties before runtime.

Upon completion of these passes, the AST operates as a semantically valid, fully annotated structure ready for deterministic simulation mapping.

3.3 Behavior Tree Synthesis and Runtime Execution↩︎

The critical link between declarative intent and simulation fidelity occurs in the backend, where the pipeline translates the validated AST into an executable format. To circumvent the asynchronous latencies associated with static bytecode interpretation, the transpiler backend synthesizes dynamic Behavior Trees (BTs) using the py_trees framework. This synthesis relies on two primary components:

• Behavior Tree Builder: This code generator maps OSC2 control flow directives (do, serial, parallel, one_of) directly to BT composites. It enforces temporal determinism by wrapping durative actions with strict timeout constraints and maps OSC2 event triggers to native condition checkers (e.g., edge detection for rise/fall expressions).

• Method Registry: To decouple the OSC2 ontology from the CARLA API while preserving execution accuracy, a decorator-based MethodRegistry dynamically dispatches abstract AST actions (e.g., vehicle.drive()) to concrete, atomic Python behaviors (e.g., WaypointFollower, ChangeTargetSpeed). This centralization guarantees that universal movement constraints—such as collision avoidance and traffic rule adherence—apply uniformly across all generated actors.

Runtime Context Management: High-fidelity simulations require dynamic evaluation. Because parameters like relative speeds or lane offsets cannot resolve fully at compile time, the backend utilizes an ExecutionContext. Functioning as a continuous state manager, it recursively evaluates AST expression nodes during execution. It implements \(\mathcal{O}(1)\) caching mechanisms for live actor lookups and real-time physical unit conversions. This allows the system to continuously re-evaluate declarative statements as mathematical primitives within the active simulation loop, maintaining strict spatial synchronization.

Finally, prior to ticking the primary BT, a ScenarioInitializer parses the AST for constraints designated with the at: start modifier. It calculates spatial dependencies and executes the lazy-spawning or teleportation of actors. This ensures the concrete, initialized simulation state strictly mirrors the theoretical initial conditions defined in the OSC2 script.

4 Simulation Ontology and Execution Mapping↩︎

Achieving high simulation fidelity requires that the abstract domain model and physical type definitions of the OSC2 standard (formalized in the domain.osc and types.osc [4]) map deterministically to the underlying physics engine. Any ambiguity or latency in this translation introduces execution drift, compromising the validity of the test.

OSC2Runner resolves this by binding the abstract ASAM ontology directly to the CARLA API via concrete, atomic behaviors registered within the MethodRegistry [2], [4]. Table 2 details the scope of this integration, providing a comprehensive matrix of the supported actions, modifiers, and condition semantics natively executed by the transpiler framework to ensure environment synchronization.

4.1 Execution of Actions and Modifiers↩︎

Translating the declarative intents of the DSL—such as core movement actions (e.g., vehicle.drive(), person.walk())—into continuous physical motion requires strict tick-by-tick evaluation. The runtime execution context dynamically delegates parameters to the mapped atomic behaviors based on the active modifiers present in the generated AST.

To enforce scenario constraints without degrading simulation realism, the architecture processes the dynamic modifiers detailed in Table 2 through two primary functional execution categories:

• Kinematic Modifiers: Constraints evaluating velocity and acceleration profiles (e.g., speed, change_speed, acceleration) execute via continuous dynamic adjustments using Proportional-Integral-Derivative (PID) control. By evaluating these parameters dynamically within the ExecutionContext, the system guarantees strict, real-time relative mathematical evaluations (e.g., faster_than) against other simulated entities without introducing asynchronous calculation delays.

• Spatial Modifiers: Constraints dictating exact positioning and routing (e.g., position, lane, keep_lane, change_lane) strictly utilize OpenDRIVE topological map projections. This direct binding enables the localized planner to calculate precise lateral offsets, dynamic splines, and target waypoints, while concurrently enforcing fundamental simulation parameters such as collision avoidance and traffic light compliance.

By enforcing this explicit, strongly-typed mapping between the OSC2 standard libraries and CARLA’s localized Python API, OSC2Runner transforms declarative scenario constraints into reliable, continuous, tick-by-tick velocity control and exact spatial tracking.

5 Experimental Results and Analysis↩︎

This section evaluates the execution determinism and simulation fidelity of the OSC2Runner architecture through two empirical case studies. Case Study 1 analyzes a highly concurrent, multi-actor scenario to validate spatiotemporal evaluation precision, continuous mathematical projections, and cross-actor event synchronization. Case Study 2 isolates environmental physics integration, measuring the architecture’s capacity to mediate declarative kinematic modifiers against the continuous tire-friction limits of the simulation engine.

5.1 Case Study 1: Adversarial Cut-In and Event Synchronization↩︎

The baseline scenario defines an adversarial interaction: a Heavy Goods Vehicle (HGV) rapidly overtakes and cuts in front of an ego vehicle (the “hero”). The HGV subsequently performs a sudden deceleration, forcing the ego vehicle to execute a concurrent evasive lane change and visual warning. Finally, both vehicles synchronize their deceleration to stop safely before a static obstacle. Figure 2 illustrates the scenario’s progression from initialization to the final synchronized halt.

The transpiler first evaluates the declarative initialization constraints (lines 26-34). The ExecutionContext dynamically resolves mixed-unit math (e.g., mapping kph and mph to SI base units) and calculates the exact topological spawning coordinates for the npc relative to the hero using OpenDRIVE splines.

import "domain.osc"
use std.stdtypes

scenario hello_world:
  carla_map: map with:
    keep(it.map_file == "Town06")
    
  env: environment
  hero: vehicle with:
    keep(it.model == "vehicle.tesla.model3")
    keep(it.name == "hero")
  npc: vehicle with:
    keep(it.model == "vehicle.carlamotors.european_hgv")
    keep(it.name == "npc")
  obstacle: stationary_object

  # --- GLOBAL VARIABLES ---
  var v_hero: speed = 35kph
  var v_npc_fast: speed = v_hero + 12.42mph
  var v_npc_slow: speed = v_hero - 10kph      
  var lag: length = 5m              
  var safety_gap: length = (lag * 3) - 3m      

  do parallel:
    # --- INITIALIZATION ---
    serial:
      hero.assign_position() with:
        lane(1, at: start)
        speed(0kph, at: start)
      npc.assign_position() with:
        lane(side: right, side_of: hero, at: start)
        position(distance: lag, behind: hero, at: start)
        speed(0kph, at: start)
      emit go_signal

    # --- HERO (EGO) LOGIC ---
    serial:
      wait @go_signal
      one_of:
        hero.drive() with:
          speed(v_hero)
        wait fall(npc.position.ahead_of(hero) > safety_gap)
      
      parallel:
        serial:
          hero.change_lane(num_of_lanes: 1, side: right)
          emit CRASH_AVOIDED
        serial:
          hero.set_lights(mode: "high_beam")
          wait elapsed(0.5s)
          hero.set_lights(mode: "auto")

      wait @OBSTACLE_DETECTED                
      hero.change_speed(target: 0kph, rate_profile: asap)
      wait hero.speed < 0.1kph

    # --- NPC (ADVERSARIAL) LOGIC ---
    serial:
      wait @go_signal
      one_of:
        npc.drive() with:
          speed(v_npc_fast)
        wait rise(npc.position.ahead_of(hero) >= lag * 2)

      npc.change_lane(num_of_lanes: 1, side: left)
      one_of:
        npc.drive() with:
          speed(v_npc_slow)
        wait @CRASH_AVOIDED

      npc.change_speed(target: 0kph, rate_profile: asap)
      emit OBSTACLE_DETECTED

5.1.1 Longitudinal Control and Actuator Dynamics↩︎

Rather than artificially snapping the ego vehicle to commanded speeds, the architecture relies on a decoupled Proportional-Integral-Derivative (PID) controller featuring conditional integration (anti-windup) to calculate throttle and brake inputs dynamically. Figure 3 illustrates this closed-loop response by mapping the vehicle’s speed against its raw throttle actuation throughout the baseline scenario.

The telemetry confirms a highly responsive and stable control loop that strictly respects the physical constraints of the simulated environment. At \(t \approx 5\) s, the vehicle is commanded to accelerate to a cruising velocity of 35 kph. The controller immediately saturates the throttle output to 1.0 to overcome the vehicle’s resting inertia. As the target speed is approached, the throttle smoothly drops and settles at an equilibrium value of approximately 0.4, representing the exact continuous force required to counteract the simulation’s aerodynamic drag and rolling resistance at that velocity.

Furthermore, the controller exhibits robust dynamic adaptability during transitional phases. At \(t \approx 30\) s, an evasive lane change maneuver induces lateral tire friction (scrub radius), causing a brief dip in forward velocity. The controller reacts cleanly, briefly increasing the throttle to re-establish the 35 kph target without inducing steady-state oscillation. Later, at \(t \approx 61\) s, a command to reduce speed to 25 kph demonstrates the architecture’s asymmetric actuator mapping: the throttle drops entirely to 0.0, allowing simulated environmental friction to naturally and smoothly decelerate the ego vehicle. Once 25 kph is reached, the throttle resumes at a lower equilibrium state (\(\approx 0.35\)). Finally, the terminal stop command at \(t \approx 74\) s permanently cuts propulsion. This exact correlation between semantic intent, continuous actuation, and physical velocity provides a rigorously validated foundation for evaluating more complex kinematic maneuvers.

5.1.2 Syntax Evaluation and Spatiotemporal Precision↩︎

A critical metric of simulation fidelity is the architecture’s capacity to evaluate dynamic spatial constraints continuously without execution drift. In the ego vehicle’s logic block, a one_of composite bounds a drive action with a spatial trigger: wait fall(npc.position.ahead_of(hero) > safety_gap) (line 42). Legacy interpreters often process spatial queries at fixed, low-frequency intervals, resulting in delayed trigger execution.

In contrast, OSC2Runner natively binds this expression to CARLA’s continuous evaluation loop. To resolve this query dynamically, the ExecutionContext computes the longitudinal distance as the projection of the relative position vector onto the ego vehicle’s heading direction, formalized in Equation 1 :

\[D_{\text{longitudinal}} = (x_{\text{npc}} - x_{\text{ego}}) \cdot \cos(\theta) + (y_{\text{npc}} - y_{\text{ego}}) \cdot \sin(\theta) \label{eq:longitudinal95dist}\tag{1}\]

where \((x_{\text{npc}}, y_{\text{npc}})\) and \((x_{\text{ego}}, y_{\text{ego}})\) denote the global coordinates of the respective vehicles, and \(\theta\) represents the heading (Yaw) of the ego vehicle relative to the map’s x-axis.

Figure 4 illustrates this transformation of the vehicle’s state from raw displacement to higher-order motion derivatives. By overlaying the longitudinal distance to the NPC against the ego vehicle’s steering input, the exact execution moment of the evasive maneuver can be empirically validated across five temporal phases:

1. Initial Phase (0–15 Seconds) - Rear-Facing Distance: The longitudinal distance curve initializes at \(-5\) meters before smoothly dipping to \(-20\) meters. According to Equation 1 , a negative projection indicates the npc is positioned behind the ego vehicle’s current heading. The flat steering line (at 0.0) confirms the ego vehicle is driving straight while the npc varies its lag distance.

2. Transition and Trigger Event (15–30 Seconds): The distance crosses from negative to positive, indicating the npc is actively overtaking. At \(t \approx 28.5\) seconds, the AST evaluates that \(D_{\text{longitudinal}}\) has crossed the safety_gap condition (\(11.71\,\text{m}\)). Immediately following this trigger, a rapid increase in the ego vehicle’s steering input is recorded (reaching nearly \(0.12\)). This confirms the transpiler successfully initiated the parallel behavior tree (steering and lighting logic) on the exact simulation tick the threshold was breached.

3. Evasive Maneuvering (30–55 Seconds): Significant fluctuations occur in the distance curve. Because \(\theta\) is time-dependent (\(\theta(t)\)), the longitudinal projection dynamically recalculates as the ego vehicle’s forward axis rotates during the lane change. The steering oscillation (around 50 seconds) reflects the PID controller’s active stabilization of the vehicle’s lateral jerk.

4. Separation Phase (60–75 Seconds): The longitudinal distance reaches a peak of approximately \(95\) meters, representing the point where the npc has accelerated far ahead of the stabilized ego vehicle.

5. Convergence (75–80 Seconds): The distance drops sharply and plateaus at a negligible relative distance near \(0\) meters. This aligns with Phase 5 of the scenario, indicating both vehicles have reached a state of synchronized halting before the static obstacle.

5.1.3 Kinematic Rate Profiling and PID Adherence↩︎

In the baseline scenario, the npc vehicle transitions between various acceleration and deceleration phases designated with either smooth or asap rate profiles. Figure 5 plots the vehicle’s longitudinal acceleration against its kinematic jerk across the entire scenario to validate this translation.

To evaluate trajectory fidelity, this analysis calculates the vehicle’s jerk \(J(t)\) as the time derivative of longitudinal acceleration \(A(t)\), such that \(J(t) = \frac{d A(t)}{dt}\). However, because the underlying PID controllers update actuator commands at discrete 20Hz simulation intervals (\(\Delta t = 0.05\) s), the raw acceleration profile inherently exhibits step-wise discontinuities. Directly differentiating this discrete signal yields a sequence of Dirac delta-like impulses (\(J(t) \approx \delta(t)\)) that obscure the macroscopic physical intent of the maneuver.

To resolve these discrete control artifacts, a centered, 1.0-second rolling kinematic low-pass filter was applied to the raw acceleration data prior to differentiation. The resulting filtered profiles mathematically validate the DSL translation: the smooth recovery maneuver (occurring at \(t \approx 25\text{--}35\) s) generates a bounded, bell-shaped jerk curve indicative of a comfort-optimized trajectory planner. In contrast, the asap emergency stop (occurring at \(t \approx 79\) s) produces a maximized jerk spike, accurately reflecting the immediate saturation of the vehicle’s braking actuators against the physical tire friction limit. The telemetry confirms that the MethodRegistry successfully maps human-readable adjectives to explicit mathematical boundaries.

5.1.4 Cross-Actor Event Synchronization↩︎

Rather than relying on hardcoded temporal delays, the DSL script utilizes a blackboard architecture for bidirectional event synchronization. The npc maintains its v_npc_slow deceleration profile until it receives the CRASH_AVOIDED signal emitted by the ego vehicle’s evasive maneuver (lines 47 and 67). Conversely, the ego vehicle suspends its cruising state until the npc halts and emits the OBSTACLE_DETECTED flag (lines 53 and 71).

Figure 6 maps the propagation latency of this blackboard synchronization during the final stopping phase. The graph isolates the discrete time delta between the npc achieving a 0 kph state (emitting the OBSTACLE_DETECTED event) and the hero vehicle reacting by dropping its throttle input. The empirical data proves an event latency of exactly 100.0 ms. Within a discrete simulation environment operating at standard tick rates, this verifies that compiling the AST into py_trees achieves near-instantaneous orchestration across independent logic branches.

5.2 Case Study 2: Environmental Physics and Kinematic Profiling↩︎

This case study isolates the MethodRegistry’s capacity to translate declarative kinematic modifiers (e.g., rate_profile) and environmental injections directly into the continuous physics engine. The validation scenario executes a straight-line braking test from an initial cruise speed of 80 kph across three distinct phases: Phase 1 (dry asphalt, asap profile), Phase 2 (dry asphalt, smooth profile), and Phase 3 (wet asphalt, asap profile). Figure 7 contrasts the simulated environment under the baseline and degraded friction conditions. Listing [lst:logic_vertical] details the OSC2 syntax used to dynamically manipulate the ego vehicle’s kinematic controller and the global road friction model.

# --- SCENARIO A: DRY ASAP ---
hero.drive(duration: run_time) with:
    speed(test_speed)
emit DRY_BRAKE_ASAP_TRIGGERED
hero.change_speed(target: 0kph, rate_profile: asap)

# --- SCENARIO B: DRY SMOOTH ---
hero.drive(duration: run_time) with:
    speed(test_speed)
emit DRY_BRAKE_SMOOTH_TRIGGERED
hero.change_speed(target: 0kph, rate_profile: smooth)

# --- ENVIRONMENT SHIFT ---
serial:
    env.rain(intensity: 100.0)
    env.set_road_friction(value: 0.4)

# --- SCENARIO C: WET ASAP ---
emit WET_BRAKE_ASAP_TRIGGERED
hero.change_speed(target: 0kph, rate_profile: asap)

5.2.1 Longitudinal Kinematics and Actuator Response↩︎

Figure 8 plots the longitudinal velocity and corresponding throttle actuation across the three execution phases, isolating the behavioral differences induced by semantic rate profiles and environmental friction limits. The telemetry confirms that the architecture explicitly rejects artificial velocity snapping in favor of continuous physical actuation. This adherence is immediately observable during the acceleration segments. In the dry asphalt conditions (Phase 1 at \(t \approx 10\) s and Phase 2 at \(t \approx 45\) s), a saturated throttle input of 1.0 rapidly accelerates the vehicle to the 80 kph target. Conversely, under the degraded wet asphalt condition (Phase 3 at \(t \approx 95\) s), the identical 1.0 throttle saturation produces a visibly shallower acceleration gradient. The underlying physics engine correctly restricts the longitudinal force application based on the reduced tire grip coefficient, requiring a longer temporal window to reach the target speed.

The deceleration profiles further validate the translation of OSC2 modifiers. Comparing the dry asphalt stops isolates the semantic rate profiles: the asap command (initiated at \(t \approx 18\) s) produces a near-vertical velocity drop, confirming maximal brake actuator saturation allowed by the road surface. In contrast, the smooth command (initiated at \(t \approx 55\) s) generates an extended, asymptotic deceleration curve. This confirms that the PID controller dynamically modulates the braking force to track the bounded \(2.5\,\text{m/s}^2\) passenger comfort limit, overriding the default maximum deceleration capability.

Finally, comparing the two asap stops isolates the environmental integration. Despite both Phase 1 and Phase 3 requesting maximum emergency deceleration, the wet asphalt condition (\(t \approx 103\) s) significantly extends the stopping duration. The physical simulation successfully caps the maximum achievable deceleration to align with the degraded \(0.4\) environmental friction limit, proving that environmental modifiers dynamically constrain the vehicle’s kinematic capabilities without requiring manual parameterization of the underlying control algorithms.

5.2.2 Higher-Order Kinematics and Jerk Analysis↩︎

Figure 9 plots the ego vehicle’s longitudinal acceleration alongside its filtered kinematic jerk, providing a granular comparative analysis of the three stopping phases.

The Phase 1 deceleration event (dry asphalt, asap) occurring at \(t \approx 18\) s establishes the maximum physical braking boundary of the ego vehicle chassis. The acceleration curve drops abruptly to approximately \(-12\,\text{m/s}^2\). Consequently, the jerk profile exhibits high-magnitude, near-instantaneous impulses (ranging from \(-9\) to \(+12\,\text{m/s}^3\)). This mathematically reflects a step-input command where the actuators are instantaneously saturated to achieve the absolute minimum stopping distance.

In direct contrast, the Phase 2 deceleration event (dry asphalt, smooth) occurring at \(t \approx 55\) s demonstrates algorithmic mediation of the physical actuators. Rather than a severe spike, the acceleration smoothly ramps down to form a flat plateau at precisely \(-2.5\,\text{m/s}^2\), aligning with the predefined passenger comfort threshold. The corresponding jerk profile replaces the violent Dirac-like impulses with controlled, bounded inflection points. This confirms that the MethodRegistry successfully overrides maximum braking capabilities when a smooth semantic profile is declared.

Phase 3 (wet asphalt, asap), initiated at \(t \approx 103\) s, isolates the boundary between algorithmic intent and environmental physics. Because the rate profile is declared as asap, the controller issues the exact same step-input actuator command as Phase 1. Consequently, the jerk profile remains sharp and impulsive. However, because the road friction was globally reduced to \(0.4\), the physical simulation limits the maximum achievable deceleration to approximately \(-3.5\,\text{m/s}^2\). The absolute magnitude of the jerk spikes is heavily compressed compared to Phase 1, proving that while OSC2 dictates the kinematic intent, the continuous physics engine retains ultimate authority over the execution boundaries.

5.2.3 Spatial Dynamics and Stopping Distance Verification↩︎

In classical vehicle dynamics, the theoretical minimum stopping distance \(d_{\text{stop}}\) for a point-mass under constant deceleration is formalized in Equation 2 :

\[d_{\text{stop}} = \frac{v_0^2}{2|a|} \label{eq:stopping95dist}\tag{2}\]

where \(v_0\) represents the initial velocity, \(a\) represents the constant deceleration rate, \(\mu\) represents the dimensionless coefficient of friction, and \(g\) represents gravitational acceleration (\(9.81\,\text{m/s}^2\)). The maximum deceleration is physically bounded by the tire-road friction limit (\(|a| \leq \mu g\)).

Figure 10 maps the ego vehicle’s velocity against the physical distance traveled from the exact moment the braking trigger is evaluated. The telemetry strictly correlates with the mathematical expectations while demonstrating the compounding non-linearities of a continuous physics engine [20]. In Phase 2 (dry, smooth), the PID controller dynamically bounds the deceleration to a comfort limit of \(-2.5\,\text{m/s}^2\). Given an initial velocity of 80 kph (\(22.22\,\text{m/s}\)), Equation 2 yields an expected stopping distance of \(98.7\) meters. The simulated vehicle achieves a full stop at exactly \(95.2\) meters. This minor variance accurately reflects the additive deceleration provided by aerodynamic drag and the non-instantaneous jerk profile required to transition the chassis weight safely.

Table 3 summarizes the spatial outcomes across all phases, contrasting the empirically observed stopping distances against the theoretical point-mass expectations calculated via Equation 2 . The variance between these values provides the strongest validation of the architecture’s physical fidelity. In Phase 1 (dry, asap), the vehicle achieves a peak deceleration of \(12.0\,\text{m/s}^2\), which yields a theoretical point-mass stopping distance of \(20.6\) meters. The simulated vehicle requires \(28.3\) meters to halt. This \(7.7\)-meter delta reflects the non-instantaneous mechanical reality of actuator latency and chassis weight transfer omitted by rigid kinematic equations.

This disparity is amplified under degraded environmental conditions. In Phase 3 (wet, asap), the \(0.4\) global friction coefficient caps the peak deceleration at \(3.5\,\text{m/s}^2\). While basic point-mass kinematics predict a \(70.5\)-meter stopping distance, the continuous physics engine requires \(125.4\) meters. This significant \(54.9\)-meter extension accounts for longitudinal tire slip, hydroplaning loss¹, and the resulting degradation of average deceleration across the maneuver’s lifespan. By exposing the inadequacy of basic kinematic snapping, this telemetry confirms that the OSC2Runner forces abstract domain commands to rigorously compete against high-fidelity tire models and environmental constraints.

6 Discussion and Limitations↩︎

While the Python-based evaluation loop guarantees tick-by-tick determinism, the OSC2Runner architecture introduces measurable computational overhead. Specifically, relying on the ExecutionContext to continuously resolve complex spatial projections (such as Equation 1 ) and maintain dynamic py_trees states within Python creates a scaling bottleneck. In high-density traffic scenarios involving dozens of concurrent adversarial actors, this runtime overhead restricts the maximum achievable simulation frame rate before execution drift or latency occurs.

Furthermore, while the current architecture successfully validates core longitudinal, lateral, and environmental modifiers, its ontological scope remains bounded. The MethodRegistry accurately maps foundational vehicle kinematics and synchronization events, but expanding this mapping to encompass edge-case domains—such as complex pedestrian intent models, intricate intersection right-of-way arbitration, and probabilistic weather generation—requires further development to achieve complete standard coverage.

7 Conclusion and Future Work↩︎

The OSC2Runner architecture resolves the spatial and temporal drift inherent in legacy interpretation frameworks by formalizing scenario translation as a multi-pass compilation pipeline natively integrated with the CARLA simulation engine. By bypassing static trajectory playback, the architecture synthesizes type-safe Abstract Syntax Trees (AST) directly into continuous, execution-ready behavior trees (py_trees).

Mapping the standard domain ontology directly to atomic simulation behaviors via a custom MethodRegistry successfully enforces strict spatiotemporal constraints. Telemetry data demonstrates tick-by-tick determinism, highlighting precise spatial trigger evaluation and near-instantaneous (100.0 ms) blackboard event synchronization during concurrent, multi-actor maneuvers. Furthermore, kinematic analysis confirms that the architecture respects the continuous physical boundaries of the simulation. The transpiler successfully mediates proportional-integral-derivative (PID) control to satisfy passenger comfort constraints and accurately degrades actuator limits in response to injected environmental friction, reflecting the non-linear mechanical realities of simulated vehicles.

Ensuring that abstract scenario declarations strictly adhere to underlying physical constraints provides the execution fidelity necessary for advanced validation paradigms, such as hardware-in-the-loop (HiL) and simulated ECU co-simulation. By establishing a highly reliable backend execution engine, this framework bridges a critical operational gap in the testing ecosystem, offering the foundational mechanism required to make automated, LLM-driven scenario generation pipelines viable for industrial-grade certification.

Future work will focus on migrating the ExecutionContext and its continuous spatial queries to native C++ bindings directly within the CARLA engine to mitigate Python-induced latency bottlenecks. Additionally, research will prioritize expanding the MethodRegistry to achieve complete standard compliance with the finalized ASAM OpenSCENARIO v2.2.0 syntax. Furthermore, coupling this deterministic execution core with macroscopic traffic simulators (e.g., SUMO), V2X network simulators (e.g., ns-3), and production-grade autonomous driving stacks such as Autoware [21] will enable comprehensive, closed-loop evaluation across increasingly complex Operational Design Domains (ODDs). Finally, integrating virtual Electronic Control Units (ECUs) [22] and simulated CAN bus architectures, such as SocketCAN [23], will expand the architecture’s utility beyond kinematic safety validation into the critical domain of autonomous vehicle cybersecurity and communication resilience.

References↩︎