Declarative Scenario-based Testing with RoadLogic

Declarative Scenario-based Testing with RoadLogic Ezio Bartocci ezio.bartocci@tuwien.ac.at TU Wien Vienna, Austria Alessio Gambi alessio.gambi@ait.ac.at AIT Austrian Institute of Technology Vienna, Austria Felix Gigler felix.gigler@ait.ac.at TU Wien Vienna, Austria AIT Austrian Institute of Technology Vienna, Austria Cristinel Mateis cristinel.mateis@ait.ac.at AIT Austrian Institute of Technology Vienna, Austria Dejan Ničković dejan.nickovic@ait.ac.at AIT Austrian Institute of Technology Vienna, Austria Abstract Scenario-based testing is a key method for cost-effective and safe validation of autonomous vehicles (AVs). Existing approaches rely on imperative scenario definitions, requiring developers to manu- ally enumerate numerous variants to achieve coverage. Declarative languages, such as OpenSCENARIO DSL (OS2), raise the abstrac- tion level but lack systematic methods for instantiating concrete, specification-compliant scenarios as simulations. To our knowledge, currently, no open-source solution provides this capability. We present RoadLogic that bridges declarative OS2 specifica- tions and executable simulations. It uses Answer Set Program- ming to generate abstract plans satisfying scenario constraints, motion planning to refine the plans into feasible trajectories, and specification-based monitoring to verify correctness. We evaluate RoadLogic on instantiating representative OS2 scenarios as simulations in the CommonRoad framework. Results show that RoadLogic consistently produces realistic, specification- satisfying simulations within minutes and captures diverse behav- ioral variants through parameter sampling, thus opening the door to systematic scenario-based testing for autonomous driving systems. Keywords scenario-based testing, autonomous vehicles, OpenSCENARIO DSL, answer set programming, symbolic automata, runtime monitoring, motion planning 1 Introduction Testing autonomous vehicles (AVs) is inherently complex and re- quires validating AVs in a broad range of driving scenarios, includ- ing those involving other road users. Conducting exhaustive testing in the real world is costly, impractical, and dangerous [19]. There- fore, simulation-based testing has become an essential approach for scalable, systematic AV validation, enabling engineers to safely and efficiently evaluate critical and rare situations. Thorough testing of AVs in simulation requires the ability to systematically describe, reproduce, and analyze a wide range of po- tentially safety-critical driving situations. To address this challenge, scenario-based testing has emerged as a key methodology for vali- dating AVs, offering a powerful means to define test situations in a rigorous yet human-interpretable way. Originally introduced in the PEGASUS project [28], scenarios come in four levels of abstraction: Listing 1: An overtake scenario in OpenSCENARIO DSL. 1 scenario traffic.overtake: 2 v1: car 3 v2: car 4 5 do parallel(): 6 v2.drive() 7 serial: 8 A: v1.drive() with: 9 lane(same _ as: v2, at: start) 10 lane(left _ of: v2, at: end) 11 position([10..20]m, behind: v2, at: start) 12 B: v1.drive() with: 13 position([1..10]m, ahead _ of: v2, at: end) 14 C: v1.drive() with: 15 lane(same _ as: v2, at:end) 16 position([5..10]m, ahead _ of: v2, at: end) functional, abstract, logical, and concrete scenarios [27]. Functional scenarios are behavior-based, structured descriptions of traffic situ- ations in natural language. Abstract scenarios formalize functional scenarios by describing them declaratively. Logical scenarios refine abstract scenarios as a parameterized set of traffic situations. Con- crete scenarios are executable instances of a logical scenario, with defined scenery, parameters, and road users’ behavior. In recent years, considerable effort has been devoted to instan- tiating scenario-based testing for AVs using scenario description languages and integrating them with driving simulators. Prominent examples include OpenSCENARIO XML [3], a concrete and exe- cutable scenario language, and Scenic [11], a probabilistic scenario language, both integrated with Carla [10]. However, these scenario languages are operational and require detailed specification of how individual scenarios are executed rather than supporting higher- level, more abstract representations of driving situations. The ability to specify high-level dynamic traffic scenarios is addressed by OpenSCENARIO DSL (OS2) [2], a declarative language for describing abstract scenarios. OS2 defines the behavior of all traffic participants, including the ego vehicle and non-playable characters (NPCs). For instance, Listing 1 illustrates a specification of an overtake scenario in OpenSCENARIO DSL in which v1 initially 1 arXiv:2603.09455v1 [cs.SE] 10 Mar 2026 01020304050 0.0 2.5 5.0 7.5 12 Figure 1: Visualization of one of the scenario executions com- pliant with the above OS2 specification generated by Road- Logic. v1 is the (purple) vehicle performing the overtake, while v2 is the (red) vehicle driving straight. drives behind v2 on the same lane (lines 8−11) and finally drives in front of it (lines 14−16). By separating the what (the intended situation) from the how (its execution in simulation), OS2 enables concise expression of abstract scenarios that possibly encompass many valid concrete scenarios, thus promoting automation, reuse, and traceability across the AV testing pipeline. However, OS2 lacks systematic open-source methods for instantiating specification- compliant simulations, such as the one reported in Figure 1. This paper introduces RoadLogic, the first open-source frame- work that automatically generates simulations from OS2 scenario descriptions. The proposed approach consists of the following steps: (1) parsing the input OS2 scenario description into a symbolic au- tomaton representation, (2) encoding the symbolic automaton into an Answer Set Programming (ASP) problem, (3) resolving the ASP problem using an off-the-shelf solver to produce a high-level plan, (4) concretizing the high-level plan into a realistic simulation us- ing an AV planner, and (5) ensuring that the concrete scenario is compliant with the abstract scenario specification, using a runtime monitor generated from its symbolic automaton representation. We implemented the RoadLogic framework on top of the clingo ASP solver [14], the FrenetiX motion planner [32], and the Com- monRoad simulation environment [1], and we evaluated it across a variety of logical scenarios. As our evaluation shows, RoadLogic effectively bridges the gap between high-level declarative scenario descriptions and concrete autonomous vehicle simulations. This paper makes the following main contributions: • We introduce RoadLogic, an open-source framework that automatically instantiates declarative OS2 specifications into realistic and specification-compliant simulations by leverag- ing ASP and AV motion planning. •We deliver an end-to-end pipeline where the OS2 specifica- tions drive both concrete scenario generation and formal conformance monitoring, ensuring that only simulations faithful to the abstract scenario specification are retained. •We evaluate RoadLogic on diverse OS2 scenarios, show- ing that it efficiently produces realistic and specification- compliant simulations bridging declarative scenario design and concrete AV testing. In the remainder of the paper, Section 2 introduces the necessary background; Section 3 presents the main contributions of this work; Section 4 details the evaluation of our approach, followed by Sec- tion 5, which discusses related work. Section 6 critically discusses design choices and implications of our framework. Finally, Section 7 concludes the paper. 2 Background 2.1 OpenSCENARIO DSL OpenSCENARIO DSL is a high-level, human-interpretable domain- specific language for declaratively specifying driving scenarios. This section limits the description to the fragments of the language that we use in this paper. An OS2 specification defines a system of actor objects that have a set of fields defined by their type definition. Let퐴=푎 1 , . . .,푎 푛 denote a set of actors. We denote by푟(푚)a road with푚lanes, where 0 is the leftmost and푚−1 the rightmost lane. Given an actor 푎 푖 ∈ 퐴, we denote by푥(푎 푖 )its position,푣(푎 푖 )its velocity and푙(푎 푖 ) the lane of the actor 푎 푖 on the road 푟(푚). A state푠, defined over the set of actors퐴and the road푟(푚), is the tuple(푥(푎 1 ),푣(푎 1 ),푙(푎 1 ), . . .,푥(푎 푛 ),푣(푎 푛 ),푙(푎 푛 ),푡)defining the position, velocity and lane occupancy of every actor푎 푖 ∈ 퐴on the road푟(푚)at time푡. A trace휏:R ≥0 → 푆is a continuous time sequence of states, where푆is a set of states. We assume that in practice, a trace휏is given as a discrete sequence푠 1 , . . .,푠 푛 of (time- stamped) states with constant-interpolation between the sampled states. Given a set of actors퐴, a road푟(푚), we define the syntax of the fragment of OS2 1 that we use in the paper as follows: 휑 := 휙 | 휑 1 || 휑 2 | 휑 1 ∪ 휑 2 휙 := 휓 | 휙 1 · 휙 2 휓 :=drive(푎) | drive(푎) : 훾 훾 := (푃(푆), @) | 훾 1 ∧훾 2 where푃is an푛-ary predicate over actor states푆, @∈ begin, end. Intuitively, this fragment of OS2 consists of a sequence of driving behaviors (drive(푎)) that can be restricted with constraints (훾) over (pairs of ) state variables defined at the beginning and the end of each segment. The atomic behaviors can be combined into more complex scenarios using serial (·), parallel (||) and one-of (∪) composition. An OS2 scenario휑is evaluated over a finite trace휏defined over an interval[푡,푡 ′ ). We use휏[푡]to denote the state of the system at time푡in trace휏, and푥(휏[푡])(푎)denotes the longitudinal position of actor푎in that state. The semantics of OS2 is defined inductively as follows: (휏,푡,푡 ′ ) |= 휑 1 || 휑 2 ↔ (휏,푡,푡 ′ ) |= 휑 1 and(휏,푡,푡 ′ ) |= 휑 2 (휏,푡,푡 ′ ) |= 휙 1 · 휙 2 ↔ ∃푡 ′ ∈ (푡,푡 ′ ) s.t.(휏,푡,푡 ′ ) |= 휙 1 and(휏,푡 ′ ,푡 ′ ) |= 휙 2 (휏,푡,푡 ′ ) |= 휑 1 ∪ 휑 2 ↔ (휏,푡,푡 ′ ) |= 휑 1 or(휏,푡,푡 ′ ) |= 휑 2 (휏,푡,푡 ′ ) |= drive(푎) : 훾 ↔ ∀푡 ′ ∈ (푡 + 1,푡 ′ )푥(휏[푡 ′ ]) (푎)> 푥(휏[푡 ′ − 1])(푎) and 푥(휏,푡,푡 ′ ) |=훾 (휏,푡,푡 ′ ) |=(푃(푆), begin) ↔ 휏[푡] |= 푃(푆) (휏,푡,푡 ′ ) |=(푃(푆), end) ↔ 휏[푡 ′ ] |= 푃(푆) The above rules define the semantics of OS2 scenarios in terms of trace satisfaction. Parallel composition (휑 1 ∥ 휑 2 ) requires both sce- narios to hold over the same interval, while sequential composition (휑 1 ·휑 2 ) splits the interval into two consecutive segments where each subscenario holds. The choice operator (휑 1 ∪휑 2 ) expresses alterna- tive behaviors by requiring that at least one of the two scenarios is satisfied. The rule fordrive(푎):훾captures the intended meaning 1 We use the mathematical notation for the syntax definition instead of the actual syntax used in Listing 1 to optimize space. 2 of a driving behavior: the actor푎must make continuous forward progress along the road (expressed by the monotonic increase of its longitudinal position), while the associated constraints훾must hold at the specified temporal anchor (either at the beginning or the end of the execution segment). The last two rules define how predicates are evaluated on the trace at these temporal anchors. 2.2 Symbolic Automata A symbolic finite automaton (SFA) [33] is a state machine similar to a regular finite-state automaton. However, transitions in an SFA are not labeled with alphabet letters, but rather with predicates defined over variables that describe whole (possibly infinite) sets of inputs at once. We formalize this idea with an effective Boolean algebraA, a tuple(D,P,[[·]],⊤,⊥,∨,∧,¬), whereDis a set of domain elements,Pis a set of predicates closed under Boolean operations,[[·]]:Ψ →2 D is a denotation function such that for all푃,푃 1 ,푃 2 ∈ P,[[⊥]]=∅,[[⊤]]=D,[[P 1 ∨ P 2 ]]=[[P 1 ]]∪[[P 2 ]], [[P 1 ∧ P 2 ]]=[[P 1 ]]∩[[P 2 ]], and [[¬P]]=D\[[P]]. A symbolic finite automatonAis then a tuple(A,푄,푞 0 ,퐹,Δ), whereAis an effective Boolean algebra,푄is a finite set of locations, 푞 0 ∈ 푄is an initial location,퐹 ⊆ 푄is a set of final locations, and Δ ⊆ 푄×P×푄 is the transition relation. An SFA starts in an initial location and reads an input one piece at a time; at each step, it checks which transition’s condition is satisfied by the current input element, follows that transition, and moves to a new location. If, after consuming the entire input, the automaton ends up in one of its accepting locations, the input is considered accepted; otherwise, it is rejected. This way, the SFA behaves like a traditional automaton but uses logical conditions to express transitions more compactly. A finite word푤overDis a finite sequence휎 1 휎 2 . . .휎 푛 of letters inD. We denote by|푤|the length푛of the word푤. Given a letter 휎 ∈ D, a휎-transition from푞to푞 ′ , denoted by푞 휎 −→ 푞 ′ , is a transition (푞,휓,푞 ′ ) ∈Δsuch that휎 ∈ [[P]]. We say that a SFA퐴accepts a word 푤= 휎 1 휎 2 . . .휎 푛 if there exists a sequence of 휎 -transitions 푞 0 휎 1 −→ 푞 1 휎 2 −→ 푞 2 휎 3 −→· 휎 푛 −→ 푞 푛 , such that푞 푖 ∈ 푄,푞 0 is the initial location and푞 푛 ∈ 퐹. The language 퐿(A) ofA is the set of all words that 퐴 accepts. We use symbolic automata as an intermediate language for rep- resenting OS2 scenarios. The symbolic automata encoding of the scenarios play a twofold role: to derive the high-level plans and to monitor the compliance of the concrete simulations to the abstract scenario intent. 2.3 Answer Set Programming Answer Set Programming (ASP) is a declarative problem-solving paradigm rooted in non-monotonic logic programming and the stable model semantics [8,16,24]. An ASP program consists of a finite set of logical rules of the general form 푎 ← 푏 1 , . . .,푏 푚 , not 푏 푚+1 , . . ., not 푏 푛 (1) where푎and푏 푖 are atoms that may contain variables. In practice, an ASP program consists of a collection of facts and rules. Facts are ground atoms that encode the concrete problem instance (e.g., initial states, vehicles, or road structure), while rules such as Eq.(1) specify logical constraints and state transitions. Together they form the input given to the ASP solver. Eq.(1)illustrates the general rule schema; the concrete instance of the problem is provided separately through ground facts elsewhere in the program. Before reasoning, an ASP solver performs a grounding step that replaces all variables with constants appearing in the program, producing a variable- free (ground) program. Each answer set (or stable model) of the grounded program represents a consistent collection of atoms that jointly satisfy all rules. The symbol “not” denotes default negation (negation as failure), meaning that a literal is assumed false unless it can be proven true within the current model. ASP naturally supports combinatorial search, constraint reason- ing, and discrete-time planning [13]. Beyond standard rules, ASP provides several expressive constructs: choice rules allow the non- deterministic generation of candidate actions or states, integrity constraints (rules with empty heads) eliminate invalid combinations, and weak constraints enable expressing optimization preferences such as minimizing trajectory length or deviation. Modern solvers such as clingo [14] and DLV [23] combine expressive modeling languages with advanced conflict-driven learning and optimiza- tion techniques derived from modern SAT and constraint solving. clingo further supports multi-shot solving [15], which incremen- tally extends existing solution candidates with additional steps or constraints without recomputation from scratch. These features, especially incremental reasoning, make ASP well-suited for gener- ating driving maneuvers under declarative scenario specifications. In this work, ASP serves as the symbolic reasoning engine for in- stantiating abstract driving scenarios. Given a symbolic automaton derived from an OS2 specification, we generate an ASP instance encoding the specification constraints. Combined with a predefined background theory that captures common driving rules and simpli- fied dynamics, the multi-shot solver computes answer sets repre- senting feasible discrete plans that satisfy the declarative scenario constraints. These plans form the symbolic basis for subsequent trajectory refinement and physically realistic simulation. It is worth briefly contrasting ASP with Satisfiability Modulo Theories (SMT), another commonly used paradigm for constraint solving. SMT solvers are particularly effective for reasoning over rich numeric theories such as linear arithmetic or bit-vectors, but typically assume a fixed problem horizon and require all constraints to be encoded upfront. In contrast, ASP is well suited for combina- torial search and non-monotonic reasoning, and naturally supports incremental discrete planning through mechanisms such as multi- shot solving. These properties make ASP particularly convenient for expressing evolving maneuver sequences and exploring alternative scenario realizations under declarative constraints. 2.4 Action Languages and Planning Action languages provide a formal basis for reasoning about actions and change. Originally introduced by Gelfond and Lifschitz [17], they serve as “formal models of parts of natural language that are used for talking about the effects of actions.” In essence, an action language describes how the execution of actions transforms a system from one state to another. Formally, a transition system consists of a set of fluents (proposi- tional variables describing properties of the world), a set of actions, 3 and a transition relation connecting states before and after an ac- tion is executed. A planning problem then asks for a sequence of actions that leads from an initial state to a goal state, given the system’s dynamics. Languages such asAandB[17] define rules of the form “ac- tion훼causes fluent푓if condition휑holds,” which can be directly represented in ASP using predicates such asholds(f, t)and occurs(alpha, t). This encoding allows us to leverage ASP solvers for planning, a paradigm known as answer set planning (see [9,30]). In practice, this integration allows declarative planning problems to be expressed compactly: initial states are represented as facts, dynamic causal laws as transition rules, and goal conditions as constraints. Solvers such as clingo then compute sequences of actions, i.e., plans, that satisfy all specified preconditions and effects. We follow this tradition to express driving dynamics and scenario evolution in our framework, using an ASP encoding that captures both discrete vehicle actions and their causal effects on system state. 2.5 CommonRoad and FrenetiX RoadLogic instantiates scenarios in CommonRoad [1] and execute them against the FrenetiX motion planner [32] using Kaufeld et al.’s multi-agent platform [21] to ensure scenarios realism. CommonRoad is an established framework for motion planning development, which is central to autonomous driving. Common- Road scenarios comprise three main elements: (i) A road network encoded in the Lanelet2 [29] format that describes the “drivable” areas of the map. (i) A set of obstacles representing static and dy- namic objects; (i) A set of planning problems that encode driving tasks. Each planning problem includes the initial state of a vehicle (e.g., position, rotation) and conditions to be met (e.g., reaching a target position within a timeout) to complete the driving task suc- cessfully. We use Kaufeld et al.’s platform to simulate CommonRoad scenarios and record the state of all the vehicles at each simulation step, which yields an execution trace. RoadLogic assumes all the vehicles start from a standstill posi- tion and generates sequences of waypoints that must be reached within a specified time. We map these conditions to CommonRoad initial and goal states to obtain planning problems that FrenetiX solves during scenario execution by driving the simulated vehicles. FrenetiX is an open-source motion planner for CommonRoad that implements a deterministic sampling-based planning algorithm. In a nutshell, FrenetiX computes an overall route from the initial state to the goal areas (i.e., the reference path) and cyclically (re)plans short-term trajectories that avoid collisions. FrenetiX identifies candidate short-term trajectories that are safe and physically fea- sible via rejection sampling, then selects the one that minimizes a user-defined cost function. Typical cost functions penalize trajec- tories that would result in unacceptable risk levels (safety), abrupt changes in direction and speed (comfort), or that are distant from the reference path. 3 RoadLogic In this section, we present RoadLogic, a framework for generating specification-compliant simulations from OpenSCENARIO DSL. 3.1 Overview Figure 2 shows an overview of RoadLogic. The OpenSCENARIO DSL specification is first translated into a symbolic automaton representation that encodes the sequential behavioral, relational, spatial and timing constraints of all actors. The symbolic automaton representation of the abstract scenarios is encoded into a planning problem using the action language formalism. The encoding is ex- tended with a simple set of general physics constraints to ensure the plausibility of the scenario instantiations. This high-level planning problem is solved using Answer Set Programming. A high-level plan is refined to a discrete sequence of waypoints for each actor. The translation of the refined plan into a concrete simulation is performed using an advanced motion planner integrated into an AV simulation environment. The concrete simulation is evaluated for compliance with respect to the original OpenSCENARIO DSL spec- ification by monitoring the generated trace against the symbolic automaton representation of the abstract scenario. 3.2 From OS2 to Symbolic Automata The first step of RoadLogic consists in translating OS2 scenarios into an equivalent symbolic automata representation, in which each location represents a maneuver from the scenario and transitions are annotated with predicated encoding constraints (e.g. spatial relations between vehicles, their velocity) in the scenario. The translationT(·)from an OS2 specification휑into a symbolic automatonA 휑 is done inductively with the following rules: Atomic Maneuver: The atomic behaviordrive(start:훾 1 , end: 훾 2 )is translated into a three-location automaton, with푖the initial, 푓the final, and푠the intermediate location. The transition between 푖and푠is labeled with the start constraint훾 1 and the transition between 푠 and 푓 is labeled with the end constraint훾 2 . T(drive(start:훾 1 , end:훾 2 ))=(푖,푠, 푓,푖, 푓,(푖,훾 1 ,푠),(푠,훾 2 , 푓)) Serial Composition: The serial composition휑 1 ·휑 2 of two scenarios 휑 1 and휑 2 is translated to a symbolic automaton by serially com- posingA 1 =T(휑 1 ) withA 2 =T(휑 2 ). LetT(휑 1 )=(푄 1 ,푖 1 , 푓 1 ,Δ 1 )andT(퐵)=(푄 2 ,푖 2 , 푓 2 ,Δ 2 ). ThenT(휑 1 · 휑 2 )=(푄,푖 1 , 푓 2 ,Δ), where: • 푄= 푄 1 ∪푄 2 \푓 1 ,푖 2 •Δ=Δ 1 ∪Δ ′ 2 ∪(푓 1 ,푃,푞) | (푖 2 ,푃,푞) ∈Δ 2 •Δ ′ 2 excludes transitions involving 푖 2 Parallel Composition: The parallel composition휑 1 || 휑 2 of two sce- narios휑 1 and휑 2 is translated to a symbolic automaton by taking the Cartesian product betweenA 1 =T(휑 1 )andA 2 =T(휑 2 ). Let T(휑 1 )=(푄 1 ,푖 1 , 푓 1 ,Δ 1 ) andT(휑 2 )=(푄 2 ,푖 2 , 푓 2 ,Δ 2 ). ThenT(휑 1 || 휑 2 )= (푄 1 × 푄 2 ,(푖 1 ,푖 2 ),(푓 1 , 푓 2 ),Δ ∥ ), whereΔ ∥ lifts transitions fromΔ 1 andΔ 2 component-wise. One-Of Composition: The one-of composition휑 1 ∨휑 2 defines the scenario choice operation and is translated by the union of the two automataA 1 =T(휑 1 )andA 2 =T(휑 2 ). LetT(휑 1 )=(푄 1 ,푖 1 , 푓 1 ,Δ 1 ) 4 Figure 2: Overview of RoadLogic. andT(휑 2 )=(푄 2 ,푖 2 , 푓 2 ,Δ 2 ). ThenT(휑 1 ∨휑 2 )=(푄,푖, 푓,Δ): We de- fine 푄= 푄 1 ∪푄 2 ∪푖, 푓\푖 1 , 푓 1 ,푖 2 , 푓 2 and Δ=(푖,푃,푞) | (푖 1 ,푃,푞) ∈Δ 1 ∪(푞,푃, 푓) | (푞,푃, 푓 1 ) ∈Δ 1 ∪(푖,푃,푞) | (푖 2 ,푃,푞) ∈Δ 2 ∪(푞,푃, 푓) | (푞,푃, 푓 2 ) ∈Δ 2 ∪Δ ′ 1 ∪Δ ′ 2 , whereΔ ′ 1 andΔ ′ 2 exclude transitions involving 푖 1 , 푓 1 ,푖 2 , 푓 2 . Example 3.1 (Symbolic Automaton of the Overtake Scenario). Fig- ure 3 depicts the symbolic automaton generated from the OS2 overtake scenario from Listing 1. The use of the symbolic automaton representation of the OS2 scenario is twofold: to facilitate the ASP planning problem definition and to monitor whether the concrete simulation is compliant with the original scenario. 3.3 ASP Encoding of Scenario Constraints We encode the instantiation of OS2 scenarios as a discrete-time planning problem in ASP. In the planning view, the objective is to find a sequence of actions that leads from an initial state to a goal state while satisfying all scenario and domain constraints. Following the conventions in ASP planning [9], a planning problem is represented by: (i) a set of fluents describing the possible states of the world, (i) a set of actions with their preconditions and effects, and (i) a set of transition rules that relate successive time steps. Solving the ASP program yields one or more answer sets, each corresponding to an abstract plan. Incremental solving. To efficiently compute plans in evolving do- mains, we employ multi-shot solving [15]. Instead of repeatedly re-grounding and re-solving the entire program for increasing hori- zons, multi-shot solving allows adding or retracting rules and incre- mentally extending the temporal scope of the problem. We structure our ASP program into three subprograms:#program base, which contains static domain facts and constants;#program step(t), which defines the dynamic transition rules per time step; and #program check(t), which expresses goal satisfaction. At each iteration, the solver incrementally advances the time step푡, adding the corresponding rules and checking whether all goal constraints are met. This approach combines the declarativity of ASP with the iterative refinement commonly found in planning frameworks. Discretization of time and space. We abstract the continuous driving environment by discretizing both space and time into a grid-based representation. Time progresses in integer steps푡=0,1,2, . . ., each corresponding to a pre-defined unit of real time (e.g. one second). The road network is modeled as a two-dimensional grid: the lon- gitudinal 푥 -axis corresponds to distance in meters (segments), and the lateral푦-axis corresponds to lane identifier integers. Thus, a cell(푆,퐿)represents a rectangle of one meter length and one lane width. The ego vehicle starts at position(0,0)at time 0. Vehicle actors move along the grid according to longitudinal and lateral velocities, expressed as integers in segments per step and lanes per step, respectively. We restrict lateral motion to at most one lane per time step (velocity _ lat ∈ −1,0,1), while the longitudinal velocity is non-negative. State representation. We represent the discrete state of each ac- tor (vehicle) with the fluentstate(V, loc(S,L), dyn(Vel _ lon, Vel _ lat)), indicating that vehicle푉is located at segment푆and lane퐿with longitudinal and lateral velocitiesVel _ lonandVel _ lat. In planning notation, we express that a fluent holds at time푇 as: holds(state(V, loc(S,L), dyn(Vel _ lon, Vel _ lat)), T). This representation allows compact reasoning about the evolution of all vehicles across time and space. Action representation. Changes in vehicle dynamics are modeled as actions of the form: change _ dynamics(V, Delta _ Vel _ lon, Vel _ lat). Each action updates the longitudinal velocity byDelta _ Vel _ lon (representing instantaneous acceleration) and sets a new lateral velocity Vel _ lat. Exactly one such action occurs for each vehicle at every time step: occurs(change _ dynamics(V, Delta _ Vel _ lon, Vel _ lat), t): acceleration _ lon(Delta _ Vel _ lon), velocity _ lat(Vel _ lat) = 1 :- vehicle(V). This compact choice rule [8,13] encodes the non-deterministic selection of a single action from the available options. State transitions. The new state at time푡is derived deterministically from the previous state and the applied actions as follows: holds(state(V, loc(S,L), dyn(Vel _ lon,Vel _ lat)), t) :- holds(state(V, loc(S _ prev,L _ prev), 5 init start AB C fin 푝 v1 ≤ 푝 v2 − 10 푝 v1 ≥ 푝 v2 − 20 푙 v1 = 푙 v2 푙 v1 < 푙 v2 푝 v2 ≤ 푝 v1 − 1 푝 v2 ≥ 푝 v1 − 10 푙 v1 = 푙 v2 푝 v2 ≤ 푝 v1 − 5 푝 v2 ≥ 푝 v1 − 10 Figure 3: Symbolic automaton derived from the overtake scenario dyn(Vel _ lon _ prev,Vel _ lat _ prev)), t-1), occurs(change _ dynamics(V, Delta _ lon, Vel _ lat), t), L = L _ prev + Vel _ lat _ prev, S = S _ prev + Vel _ lon _ prev, Vel _ lon = Vel _ lon _ prev + Delta _ Vel _ lon, velocity _ lon(Vel _ lon). This transition rule propagates the vehicle position according to its prior velocity, updated by the acceleration at step 푡 . Symbolic automaton constraints. The symbolic automaton derived from the OS2 specification (Section 3.2) defines the logical structure of the scenario through its nodes푠 푖 and edges푒 푖 = (푠 푖−1 ,훾 푖 ,푠 푖 ), where each label훾 푖 represents a conjunction of symbolic predicates that must hold to enable the transition. For each훾 푖 , we generate a goal rule that enforces its satisfaction at some time푇 푖 ≤ 푡 : goal _ i(t) :- query(t), T <= t, gamma _ i(T). The sequential satisfaction of all such subgoals forms the overall scenario goal: goal(T1, ..., Tn, t) :- goal _ 1(T1), ..., goal _ n(Tn), 0 <= T1 <= ... <= Tn <= t. These goal rules are placed in thecheck(t)subprogram, ensur- ing that the multi-shot solver only terminates once all required conditions along the automaton path are satisfied. Domain constraints. We combine the constraints explicitly defined in the OS2 scenario with additional domain constraints to ensure physical and behavioral realism: (1) vehicles must not stop com- pletely after initialization, (2) longitudinal and lateral velocities remain within specified bounds, (3) vehicles stay within road limits, (4) lane changes cannot occur in consecutive steps, and (5) collisions are forbidden. For instance, to prevent immediate successive lane changes, we define a blocking durationchange _ durafter a lane change and enforce that vehicles remain on the new lane during this interval. Similarly, safety distances are maintained by prohibiting configurations in which two vehicles occupy the same or adjacent segments within a minimum longitudinal gap. Example 3.2 (ASP Encoding of the Overtake Scenario). Listing 3.3 shows an excerpt of the ASP encoding for the overtake scenario used in our running example. The rules describe three sequential goals: (i) the vehiclev1is left of the other carv2, (i) it reaches a longitudinal offset ahead ofv2, and (i) it returns to the same lane in front of it. The solver incrementally extends the horizon until all goals are achieved. Figure 4 visualizes the corresponding time steps in which these conditions hold. Listing 3.3: ASP encoding of a goal sequence % INITIAL SETUP FACTS: #program base. init(state(v1,loc(0,0),dyn(1,0))). 1 init(state(v2, loc(S1, L1), dyn(1,0))) : segment(S1), lane( L1), -20 <= (S2 - S1) <= -10, L2 = L1 1 :- init(state(v1, loc(S2, L2), dyn(1,0))). vehicle(v1). vehicle(v2). #program check(t). % GOAL RULES: goal1(t) :- holds(state(v1,loc(S1,L1),dyn( _ , _ )), t), holds( state(v2,loc(S2,L2),dyn( _ , _ )), t), L1 < L2. goal2(t) :- holds(state(v1,loc(S1,L1), dyn( _ , _ )), t), holds( state(v2,loc(S2,L2),dyn( _ , _ )), t), 1 <= (S1 - S2) <= 10. goal3(t) :- holds(state(v1,loc(S1,L1),dyn( _ , _ )), t), holds( state(v2,loc(S2,L2),dyn( _ , _ )),t), 5<=(S1 - S2)<=10, L1=L2. % GOAL ASSERTION: goal(T1,T2,T3,t) :- goal1(T1), goal2(T2), goal3(T3), 0 <= T1<= T2<=T3 <= t, t > T3 + 1. :- query(t), not goal( _ , _ , _ ,t). 0102030405060 segment 1 0 -1 -2 lane v1 v2 Fluents at time: 4 0102030405060 segment 1 0 -1 -2 lane v1v2 Fluents at time: 7 0102030405060 segment 1 0 -1 -2 lane v1v2 Fluents at time: 9 Figure 4: Selected frames from the ASP model output of the running example. From answer sets to concrete scenarios. Each computed answer set represents a high-level discrete plan, containing facts of the form: 6 holds(state(V, loc(S,L), dyn(Vel _ lon, Vel _ lat)), T). We extract these fluents to define the initial state and a sequence of waypoints which serve as the basis for generating concrete sce- narios for each vehicle. In this paper, we illustrate the application of RoadLogic by generating concrete scenarios in CommonRoad; however, the approach is generic and can be adapted to generate scenarios in other simulators. Therefore, we encode information about initial, intermediate, and final expected states into Common- Road planning problems (see Section 2.5) but force all vehicles to start from a standstill position in compliance with state-of-the-art driving simulators, such as CARLA [10] and BeamNG.tech [5]. As described in the next section, we simulate the concrete Com- monRoad scenarios using Kaufeld et al.’s platform and the FrenetiX motion planner. 3.4 Concrete Scenario Execution and Monitoring The ASP solver determines what must happen at the symbolic level, i.e., the ordering of maneuvers and relational constraints between actors, while Frenetix determines how these constraints are realized in continuous space under vehicle dynamics and road geometry. Multiple trajectories may satisfy the same high-level plan; RoadLogic controls concretization by enforcing ASP-derived intermediate goals in sequence and by rejecting executions that violate the symbolic automaton during monitoring. RoadLogic generates scenarios containing multiple intermedi- ate goals. However, neither Kaufeld et al.’s simulation platform nor the FrenetiX motion planner support this setup. Specifically, Kaufeld et al.’s platform assumes that driving agents must achieve a single goal; therefore, it removes them from the simulation as soon as they reach the target position. Likewise, the FrenetiX motion planner, which also assumes there is a single target goal, cannot plan a reference path that traverses all the intermediate locations before reaching the final one. To solve these limitations, we extended the original implementa- tion of Kaufeld et al.’s platform to keep track of intermediate goals and remove the agents only when they reach their final goal. We extended FrenetiX by allowing the driving agents to dynamically change their (current) goals, such that agents will recompute the reference path after reaching an intermediate goal. We used the updated platform and motion planner to solve the (multi-goal) plan- ning problems derived from the ASP high-level plans, effectively using the simulations to refine the high-level plans into physically feasible trajectories that respect vehicle dynamics, road geometry, and scenario specifications. After executing a scenario, RoadLogic collects the execution traces and monitors their compliance with the symbolic automaton specifications, using the algebraic runtime verification [18] frame- work. Additionally, RoadLogic checks that the vehicles reached the goals within the allotted time and that all the vehicles completed the whole simulation, ensuring that also the global invariants of the execution hold. If the generated execution trace does not com- ply with the symbolic automaton specification, and hence to the intended OS2 scenario, the concrete instantiation is rejected and a new plan is generated. 3.5 Implementation RoadLogic is implemented in Python 3.10 and released under the permissive BSD 3-Clause license. It includes an ANTLR4-based parser for OS2 scenarios, using the official grammar from the community project py-osc2 [26]. The high-level planning engine relies on the Potassco clingo ASP solver [14], while the low- level motion planning is performed by the Frenetix planner [32] within the CommonRoad simulation framework [1]. The com- plete source code and experiment scripts are publicly available at https://anonymous.4open.science/r/roadlogic-03F1/. Animated visualizations of the executions shown in Figures 1, 4, 7, and 9 are available in the replication package under paper/animations. 4 Evaluation In this section we present the evaluation results. We first formulate our research questions, describe the experimental setup and then perform the evaluation that allows us to respond to the questions. 4.1 Research Questions We seek to answer the following research questions: (RQ1) Effective Scenario Generation. Can RoadLogic generate scenarios that result in realistic executions and satisfy the declarative OS2 specifications in an acceptable time? Rationale: Addressing this research question determines whether RoadLogic reliably and efficiently bridges the gap between declar- ative scenario specifications and executable simulations. Metrics: To demonstrate that RoadLogic generates scenarios that satisfy the specification, we verify that the monitors return a positive verdict after checking each scenario execution trace. We also verify this result using visual inspection. We log the time to complete each step of RoadLogic pipeline (see Section 3) to assess overall performance and the impact of each activity. (RQ2) Generated Scenario Diversity. Can RoadLogic generate quantifiably different scenarios from the same OS2 specifications? Rationale: Systematically generating diverse scenarios might stress different behaviors and possibly expose more bugs, thus improving testing effectiveness. Doing so while ensuring that all scenarios meet developers’ expectations ensures they fulfill the intended purpose, thereby achieving high test quality. Metrics: To assess how different the generated scenarios are, we implemented a scenario similarity metric based on occupancy grid [7]. In a nutshell, we measure the similarity between scenarios as the Jaccard Index of their observed occupancy of the grid: similarity(푆 1 ,푆 2 )= |푂퐺 1 ∩푂퐺 2 | |푂퐺 1 ∪푂퐺 2 | (2) where OG 푖 is the set of cells in the grid representation (see Sec- tion 3.3) occupied by any vehicle in scenario S 푖 at any time. Sim- ilarity values close to 1 indicate vehicles covered similar ground; conversely, values close to 0 suggest that the vehicles followed different trajectories. 4.2 Experimental Setup We evaluate RoadLogic on a suite of 7 OS2 specifications cover- ing various scenarios and variations: (1) Follow is a car-following scenario that involves two vehicles, lead and tail, driving in the 7 same direction; the tail must follow the lead’s trajectory. (2) Over- take is an overtaking scenario that involves two vehicles, lead and tail, driving in the same direction in the same lane; the tail drives faster than the lead, thus it must switch lane and pass it to avoid colliding. (3) Overtake + 3rd actor, (4) Overtake + fixed lane, and (5) Overtake + obstacle are variations of the basic overtaking sce- nario and involve a third vehicle (moving and standing) or force the lead to keep its lane. (6) Change lane is a scenario where one vehicle changes lane while the other drives freely. (7) Dodge obsta- cle involves a vehicle traveling in a lane that must avoid a second vehicle parked on the same lane. We evaluate two different strategies of using RoadLogic: (1) base strategy in which all responsibility for generating different concrete scenarios is given to the ASP planner, and (2) refined strategy in which the input parameters are sampled from given ranges and the ASP planner generates plans with the sampled parameters instead. To address RQ1, we use RoadLogic with the base strategy. In this base experiment, we generate 10 concrete scenarios for each of the 7 OS2 specifications. To address RQ2, we use RoadLogic with the refined strategy and randomly sample the scenario input parameters, generating different ASP planning problems. In this experiment, we generate 50 concrete scenarios for each of the 7 OS2 specifications. 4.3 RQ1. Effective Scenario Generation. We evaluate RoadLogic using the base strategy. For each scenario, we generate 10 concrete simulations. We use the scenario monitors to check the compliance of the simulations to the abstract scenarios. The evaluation shows that all the instantiated simulations from all the scenarios conform to their respective scenario specification. Figure 5 shows the computation times for generating scenarios using the base strategy. For each scenario, we split the total compu- tation time across the main (planning, execution, instrumentation, monitoring) tasks. We see that most benchmark specifications com- plete the full scenario generation pipeline within minutes. We also observe that the computation time is sensitive to the minimum time horizon needed for a satisfying plan. In all scenarios except one, the execution (i.e. simulation in the CommonRoad framework) is the activity that dominates the overall scenario generation time. One major exception is Experiment 4, in which the high-level ASP planning presents a clear computational bottleneck. This scenario requires a sequence of complex maneuvers (including two consec- utive changes of the lane) and requires a longer time horizon for completion, thus increasing the complexity of the ASP planning problem. RQ1: RoadLogic is effective in generating concrete executions from abstract OS2 scenarios with reasonable cost in most of the cases. 4.4 RQ2. Scenario Diversity We evaluate the scenario diversity generated by RoadLogic with both the base and the refined strategy. Figure 6 shows the variability results for both strategies, with each plot having the label X-Y, where X denotes the scenario number 001-b • Follow 002-b • Overtake 003-b • Overtake + 3rd actor 004-b • Overtake + fixed lane 005-b • Overtake + obstacle 006-b • Change lane 007-b • Dodge obstacle 0 500 1000 1500 Time (s) 2m21s 3m28s 4m08s 21m12s 5m16s 3m59s 4m52s PlanExec.Instr.Mon. Figure 5: Computation time of base pipeline on the scenario benchmark. 001-b001-r002-b002-r 003-b003-r004-b004-r 005-b005-r006-b006-r 01 IoU similarity 007-b007-r Figure 6: Similarity heatmaps for all experiments. Each pair (x-b, x-r) corresponds to one scenario under the base strategy and one under refined settings. All heatmaps share the color scale shown in the bottom left. and Y whether the experiment was done using the base or the refined strategy. We first observe that the base strategy results in scenario instantiations with little diversity. The reason for this lack of diversity is that we use the incremental mode of the clingo 8 solver. In the incremental mode, the plan generation is done doing the depth-first search. In essence, a new plan is typically created by varying the last step of the old plan, thus considerably limiting the variation in the prefix of the generated plans. In contrast, the refined strategy results in much higher vari- ation of the generated scenario instances, as shown in Figure 6. We illustrate this variability by depicting three different instanti- ations of the Scenario 5 using the refined strategy in Figure 7. To enforce input parameter variation, every partition is encoded as a different ASP planning problem. We observe clustering in some scenarios (especially scenarios 3 and 7). This can be explained by an implementation detail of the parameter variation – the param- eter variation proceeds in alphanumerical order of the sampled parameters, meaning that these clusters likely are setups where the parameters flip between two sets of qualitatively different plans. We also observe that the parameter variation impacts the diversity of under-constrained scenarios (e.g. scenarios 1 or 7) more than those that have tighter qualitative constraints (e.g. scenario 2). This is not surprising since over-constrained scenarios leave less freedom for diversity. Figure 7: Three concrete simulations generated from Scenario 5 using the refined strategy. The enforcement of the parameter variations, resulting in the high variability, also comes at a cost. First, the scenario instantiation success rate is not anymore 100% as for the base strategy. This is reflected in Figure 8 (top). It shows that with the refined strategy, RoadLogic still generates many successful scenario instantiations (blue bar), but also sometimes simulations that do not conform to the scenario specification (orange bar) or times out without generating a simulation (grey bar). Scenario 4 seems especially hard to resolve using the refined strategy, where we observe many timeouts. We also see in Figure 8 (bottom) that the refined strategy increases computation times compared to the base strategy (Figure 5). RQ2: RoadLogic can instantiate abstract OS2 scenarios with high-variability, especially when enforcing input parameter partitioning. 4.5 Threats to Validity Internal validity: The restriction in this paper to a fragment of OS2 can represent a threat to validity. To mitigate this threat, we selected 0.0 0.5 1.0 Outcome fractions PositiveNon-zero costTimeout 001-r • Follow (var.) 002-r • Overtake (var.) 003-r • Overtake + 3rd actor (var.) 004-r • Overtake + fixed lane (var.) 005-r • Overtake + obstacle (var.) 006-r • Change lane (var.) 007-r • Dodge obstacle (var.) 10000 Time (s) 14m38s 28m06s 1h23m 4h12m 53m54s 15m22s 17m28s PlanExec.Instr.Mon. Figure 8: Success rate and computation time of pipeline with sampled parameters on the scenario benchmark. the representative subset of OS2 that is sufficient to demonstrate the feasibility and the effectiveness of the approach. The depth-first search of the ASP solver tends to favor struc- turally similar solutions and hence can introduce the search bias. This bias can artificially limit scenario diversity and prevent ex- ploring hard-to-reach parts of the search space. We address this threat by defining an alternative refined strategy that enforces more random input parameter choices. External Validity: Like many other evaluations, our study faces an external validity concern regarding the generalizability of the results. To address this, we experimented with seven different sce- narios and two simulation environments with different physics properties and levels of accuracy. The collected evidence is consis- tent across scenarios. The evaluation focuses on scenarios with a small number of actors to keep the symbolic planning and monitoring behavior interpretable in this initial study. This is not a conceptual limitation of RoadLogic; larger multi-agent scenarios are primarily limited by ASP planning complexity and simulation cost, and constitute an important direction for future work. Construct Validity: The diversity evaluation relies on an occupancy- grid similarity metric. This metric may overemphasize certain geo- metric differences while under-representing distinct behavioral phenomena (e.g., different speed profiles or interactions). Thus, conclusions about diversity may not be fully complete and may depend on the chosen metric. 5 Related Work OpenSCENARIO 2 is a family of standard description languages for automated driving systems (ADS) scenarios. Version XML (also 2 https://w.asam.net/standards/detail/openscenario-xml/ 9 known as 1.x) [3,4] consists of an XML-based document that speci- fies step-by-step, using a procedural and imperative language, the behaviour, triggers, and manoeuvres of ADS. Although this version is suitable for well-defined, concrete scenarios that a simulation engine can execute directly, this standard lacks the flexibility to specify abstract scenarios that describe the intent or what the sce- nario should look like, leaving simulation engines to determine how to execute them. In contrast, OpenSCENARIO DSL (also known as 2.0) (OS2) 3 provides an object-oriented declarative domain speci- fication language (DSL) that can describe more complex dynamic scenarios more abstractly by specifying the goal or intent of the scenarios rather than a fixed and concrete sequence of events, al- lowing also parametric and probabilistic variations. It is important to note that apart from the common OpenSCENARIO name, the XML and DSL variants have little in common, the former covering the specification of logical and the latter the abstract scenarios. RoadLogic is built on top of OS2, enabling the possibility to concretize abstract OS2 scenarios into executable and monitorable ones through planning using ASP and compliant-checking using symbolic automata. Several survey papers provide useful taxonomies [31,36] about Scenario-based testing or focus on automating the generation pro- cess [12,35] and scenario analysis. In particular, Zhang et al.[35] emphasize the open challenge: searching for critical executable sce- narios from a very abstract one —a problem we try to address with RoadLogic. Becker and Neurohr [6] tried to address this problem by considering a simplified dynamic vehicle model (e.g., the bicycle model), vehicle trajectories as Bèzier splines, and encode abstract scenarios in a series of linear constraints systems that represent both temporal and spatial relations. In contrast, RoadLogic uses ASP for the resolution of the logical constraints and in a high-level discrete-time plan where we can encode more easily specific driving rules. Moreover, the work [6] does support scenarios in OS2 like in RoadLogic and does not provide a monitor to check whether the simulation is compliant with the goal of the abstract scenario. Wang et al. [34] also use ASP to generate collision-free ADS scenarios that satisfy logical constraints. In the paper, the authors mention that these ASP programs can be translated into OpenSCE- NARIO XML (1.0). Similarly, Karimi et al. [20] specify and solve complex logical constraints of autonomous driving scenarios, such as traffic rules, as ASP programs to automatically generate intersec- tion test cases of increasing complexity, later executed in CARLA. Klampfl and Wotawa demonstrate in [22] the suitability of the ASP programs and reasoning for specifying high-level autonomous driv- ing scenarios, proposing a novel approach to continuously monitor these specifications over data from the simulation environment to detect and explain potential discrepancies. In contrast with these ap- proaches, RoadLogic integrates ASP into a complete pipeline: takes input from an OS2→symbolic automata→high-level planning via ASP→motion-planning-based concretization→specification monitoring in simulation. This pipeline makes sure that gener- ated scenarios remain both feasible and specification-compliant, bridging the gap between logical design and executable tests. Lin et al. [25] consider the problem of format interoperability between different scenario description languages by proposing a 3 https://w.asam.net/standards/detail/openscenario/v200/ Listing 2: The overtake scenario refined with additional con- straints preventing the vehicle v2 from changing lane. 1 scenario traffic.refined _ overtake: 2 v1: car 3 v2: car 4 5 do parallel(): 6 v2.drive() with: 7 lane(0, at: start) 8 lane(0, at, end) 9 ... translator from OpenSCENARIO XML (1.x) to the CommonRoad format, enabling scenario simulation with CommonRoad tools. In- teroperability is also key in RoadLogic, but within OS2. Although some commercial tools support OS2 scenarios, such as Foretellix’s Foretify toolchain 4 , ours is the first, to our knowledge, open-source toolchain framework that both supports OS2 and gen- erates both a concrete scenario to simulate and a monitor in terms of symbolic automaton, verifying at runtime that the generated scenario is compliant with the original specification. 6 Discussion The primary application of OS2 is large-scale verification and val- idation for assessing the safety and functionality of AVs. Its high level of abstraction and declarative style capture scenarios in terms of their intent, emphasizing what a scenario should achieve rather than how it is instantiated. This abstraction naturally supports systematic exploration of the scenario space to uncover potential unknowns. Therefore, generating concrete simulations from ab- stract scenarios provides a powerful mean for scenario elicitation. Figure 9 illustrates the detection of an unknown detected by Road- Logic from the overtake specification. We see that (1) the vehicle v1is behind the vehiclev2in the middle lane at the beginning of the execution trace, (2)v1is in the left lane with respect tov2in the middle of the trace, and (3)v1is in the same (leftmost) lane asv2, but in front of it. It therefore satisfies the constraints of the overtake scenario. This behavior may however not meet the original intent of the scenario – thatv2does not change lane during the overtake maneuver. This additional constraint can be enforced in OS2, by restrictingv2to drive straight, without changing the lane, as shown in Listing 2 (lines 7 and 8). Figure 9: A concrete behavior that satisfies the overtake sce- nario specification without being an actual overtake. The translation from a highly abstract and declarative formal- ism such as OS2 to concrete simulations also exposes subtle but impactful design choices. OS2 scenarios intentionally omit many 4 https://w.foretellix.com/foretify-toolchain-overview/ 10 low-level details such as vehicle dynamics or physical constraints that must nevertheless be resolved to obtain plausible and realistic simulations. In our approach, these missing aspects are addressed implicitly by representing domain knowledge in the form of addi- tional ASP rules. This, however, raises an important question: what should remain explicit in the OS2 specification, and what should instead be treated as implicit, domain-wide knowledge applied uniformly across all scenarios? 7 Conclusions and Future Work We introduced in this paper RoadLogic, the first open-source frame- work for automatically translating OS2 abstract autonomous driv- ing scenario descriptions to concrete simulations. RoadLogic ren- ders declarative driving scenarios executable, thus bridging the gap between the abstract and the concrete scenario layers. In this paper, we established the foundations for translating declarative OS2 specifications into concrete simulations, concen- trating on the core maneuvers and the compositional operators used to construct complex scenarios. Adding many of the additional con- structs from OS2 requires mainly engineering effort, which we plan to invest in improving our implementation. We also intend to sup- port additional constructs, including events and non-highway road networks, which will require further research. While we demon- strated the effectiveness of our translation pipeline, we believe that the efficiency of the concrete scenario generation can be im- proved. We plan to optimize the ASP encoding of the scenarios and explore alternative planning methods, such as rapidly-exploring random trees (RRTs) to ensure more efficient simulation genera- tion. Although we used specific simulation and motion planning environment to implement RoadLogic, our methodology does not depend on them. We hence intend to adapt RoadLogic to other AV environments such as Carla and BeamNG. Acknowledgments. This research was funded in whole or in part by (i) the Austrian Science Fund (FWF) 10.55776/DOC1345324; (i) the Vienna Science and Technology Fund (WWTF) under Grant ICT22-023 (TAIGER); (i) the European Union, RobustifAI project, ID 101212818. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the Euro- pean Union or the European Health and Digital Executive Agency (HADEA). Neither the European Union nor the granting authority can be held responsible for them; and (iv) the EU’s Horizon Europe research and innovative programme under Grant Agreement No. 101160022 (VASSAL). References [1] Matthias Althoff, Markus Koschi, and Stefanie Manzinger. 2017. CommonRoad: Composable benchmarks for motion planning on roads. In 2017 IEEE Intelligent Vehicles Symposium (IV). IEEE, Los Alamitos, CA, USA, 719–726. doi:10.1109/IVS. 2017.7995802 [2] ASAM. 2024.ASAM OpenSCENARIO® DSL BS 2.1.0 Specification. https://publications.pages.asam.net/standards/ASAM_OpenSCENARIO/ ASAM_OpenSCENARIO_DSL/latest/index.html. Accessed: 13.11.2024. [3] ASAM e.V. 2020.ASAM OpenSCENARIO: User Guide (Version 1.0.0). https://releases.asam.net/OpenSCENARIO/1.0.0/ASAM_OpenSCENARIO_BS- 1-2_User-Guide_V1-0-0.html. Revision date: 5 July 2020. [4]ASAM e.V. 2020. OpenSCENARIO UML Model Documentation (Version 1.0). https: //releases.asam.net/OpenSCENARIO/1.0.0/Model-Documentation/index.html. [5] BeamNG GmbH. 2025. BeamNG.tech. https://w.beamng.tech/ [6]Jan Steffen Becker and Christian Neurohr. 2025. Correct-by-construction instanti- ation of abstract scenarios. International Journal on Software Tools for Technology Transfer 27, 5 (2025), 465–485. doi:10.1007/s10009-025-00827-9 [7] Thilo Braun, Julian Fuchs, Felix Reisgys, Lennart Ries, Johannes Plaum, Barbara Schüt, and Eric Sax. 2023. A Review of Scenario Similarity Measures for Vali- dation of Highly Automated Driving. In 26th IEEE International Conference on Intelligent Transportation Systems, ITSC 2023, Bilbao, Spain, September 24-28, 2023. IEEE, Bilbao, Spain, 689–696. doi:10.1109/ITSC57777.2023.10422046 [8] Gerhard Brewka, Thomas Eiter, and Miroslaw Truszczynski. 2011. Answer set programming at a glance. Commun. ACM 54, 12 (2011), 92–103. doi:10.1145/ 2043174.2043195 [9]Son Cao Tran, Enrico Pontelli, Marcello Balduccini, and Torsten Schaub. 2023. Answer Set Planning: A Survey. Theory and Practice of Logic Programming 23, 1 (Jan. 2023), 226–298. doi:10.1017/S1471068422000072 [10]Alexey Dosovitskiy, German Ros, Felipe Codevilla, Antonio Lopez, and Vladlen Koltun. 2017. CARLA: An Open Urban Driving Simulator. In Proceedings of the 1st Annual Conference on Robot Learning. 1–16. [11] Daniel J Fremont, Tommaso Dreossi, Shromona Ghosh, Xiangyu Yue, Alberto L Sangiovanni-Vincentelli, and Sanjit A Seshia. 2019. Scenic: a language for scenario specification and scene generation. In Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation. 63–78. [12] Yuan Gao, Mattia Piccinini, Yuchen Zhang, Dingrui Wang, Korbinian Möller, Roberto Brusnicki, Baha Zarrouki, Alessio Gambi, Jan Frederik Totz, Kai Storms, Steven Peters, Andrea Stocco, Bassam Alrifaee, Marco Pavone, and Johannes Betz. 2025. Foundation Models in Autonomous Driving: A Survey on Scenario Generation and Scenario Analysis. CoRR abs/2506.11526 (2025). arXiv:2506.11526 doi:10.48550/ARXIV.2506.11526 [13] Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub. 2012. Answer Set Solving in Practice. Morgan & Claypool Publishers. doi:10.2200/ S00457ED1V01Y201211AIM019 [14]Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub. 2014. Clingo = ASP + Control: Preliminary Report. CoRR abs/1405.3694 (2014). arXiv:1405.3694 http://arxiv.org/abs/1405.3694 [15]Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub. 2019. Multi-shot ASP solving with clingo. Theory Pract. Log. Program. 19, 1 (2019), 27–82. doi:10.1017/S1471068418000054 [16] Michael Gelfond and Vladimir Lifschitz. 1988. The Stable Model Semantics for Logic Programming. In Logic Programming, Proceedings of the Fifth International Conference and Symposium, Seattle, Washington, USA, August 15-19, 1988 (2 Vol- umes), Robert A. Kowalski and Kenneth A. Bowen (Eds.). MIT Press, 1070–1080. [17]Michael Gelfond and Vladimir Lifschitz. 1998. Action languages. Linköping University Electronic Press. [18]Stefan Jaksic, Ezio Bartocci, Radu Grosu, and Dejan Nickovic. 2018. An Algebraic Framework for Runtime Verification. IEEE Trans. Comput. Aided Des. Integr. Circuits Syst. 37, 11 (2018), 2233–2243. doi:10.1109/TCAD.2018.2858460 [19] Nidhi Kalra and Susan M. Paddock. 2016. Driving to Safety: How Many Miles of Driving Would It Take to Demonstrate Autonomous Vehicle Reliability? RAND Corporation. [20] Amin Karimi, Héctor Muñoz-Avila, and Dorsa Sadigh. 2022. Automatic Gen- eration of Test-cases of Increasing Complexity for Autonomous Vehicles at In- tersections. In Proceedings of the ACM/IEEE 13th International Conference on Cyber-Physical Systems (ICCPS). 247–258. https://w.cs.unc.edu/~psd/files/ research/2022/karimi-iccps-2022-automatic-test-cases.pdf Uses ASP for reason- ing over traffic rules and Scenic for executing test-cases in CARLA. [21]Marc Kaufeld, Rainer Trauth, and Johannes Betz. 2024. Investigating Driving Interactions: A Robust Multi-Agent Simulation Framework for Autonomous Vehicles. In 2024 IEEE Intelligent Vehicles Symposium (IV). 803–810. doi:10.1109/ IV55156.2024.10588423 [22]Lorenz Klampfl and Franz Wotawa. 2024. Leveraging Answer Set Programming for Continuous Monitoring, Fault Detection, and Explanation of Automated and Autonomous Driving Systems. In 35th International Conference on Principles of Diagnosis and Resilient Systems (DX 2024) (Open Access Series in Informatics (OASIcs), Vol. 125). 10:1–10:20. doi:10.4230/OASIcs.DX.2024.10 [23]Nicola Leone, Gerald Pfeifer, Wolfgang Faber, Thomas Eiter, Georg Gottlob, Simona Perri, and Francesco Scarcello. 2006. The DLV system for knowledge representation and reasoning. ACM Transactions on Computational Logic (TOCL) 7, 3 (2006), 499–562. [24]Vladimir Lifschitz. 2019. Answer Set Programming. Springer. doi:10.1007/978-3- 030-24658-7 [25] Yuanfei Lin, Michael Ratzel, and Matthias Althoff. 2023. Automatic Traffic Sce- nario Conversion from OpenSCENARIO to CommonRoad. In 26th IEEE Interna- tional Conference on Intelligent Transportation Systems, ITSC 2023, Bilbao, Spain, September 24-28, 2023. IEEE, 4941–4946. doi:10.1109/ITSC57777.2023.10422422 [26]Pierre R. Mai. 2024. PMSF py-osc2: Python package for ASAM OpenSCENARIO DSL 2.x. https://github.com/PMSFIT/py-osc2. Version 0.1.0, accessed January 2025. [27]Till Menzel, Gerrit Bagschik, and Markus Maurer. 2018. Scenarios for develop- ment, test and validation of automated vehicles. In 2018 IEEE Intelligent Vehicles 11 Symposium (IV). IEEE, 1821–1827. [28]PEGASUS research project. 2017. Securing Automated Driving Effectively. https: //w.pegasusprojekt.de/en/about-PEGASUS. [29] Fabian Poggenhans, Jan-Hendrik Pauls, Johannes Janosovits, Stefan Orf, Max- imilian Naumann, Florian Kuhnt, and Matthias Mayr. 2018. Lanelet2: A high- definition map framework for the future of automated driving. In 21st Interna- tional Conference on Intelligent Transportation Systems, ITSC 2018, Maui, HI, USA, November 4-7, 2018, Wei-Bin Zhang, Alexandre M. Bayen, Javier J. Sánchez Med- ina, and Matthew J. Barth (Eds.). IEEE, 1672–1679. doi:10.1109/ITSC.2018.8569929 [30]Tran Cao Son, Chitta Baral, Nam Tran, and Sheila McIlraith. 2006. Domain- dependent knowledge in answer set planning. ACM Transactions on Computa- tional Logic (TOCL) 7, 4 (2006), 613–657. [31] Shuncheng Tang, Zhenya Zhang, Yi Zhang, Jixiang Zhou, Yan Guo, Shuang Liu, Shengjian Guo, Yan-Fu Li, Lei Ma, Yinxing Xue, and Yang Liu. 2023. A Survey on Automated Driving System Testing: Landscapes and Trends. ACM Trans. Softw. Eng. Methodol. 32, 5, Article 124 (2023), 62 pages. doi:10.1145/3579642 [32]Rainer Trauth, Korbinian Moller, Gerald Würsching, and Johannes Betz. 2024. FRENETIX: A High-Performance and Modular Motion Planning Framework for Autonomous Driving. IEEE Access (2024), 1–1. https://doi.org/10.1109/ACCESS. 2024.3436835 [33]Margus Veanes, Peli de Halleux, and Nikolai Tillmann. 2010. Rex: Symbolic Regular Expression Explorer. In Third International Conference on Software Testing, Verification and Validation, ICST 2010, Paris, France, April 7-9, 2010. IEEE Computer Society, 498–507. doi:10.1109/ICST.2010.15 [34]Ruolin Wang, Yuejiao Xu, Jie Peng, and Jianmin Ji. 2023. A 2 CoST: An ASP-based Avoidable Collision Scenario Testbench for Autonomous Vehicles. In Proc. of KR 2023: the 20th International Conference on Principles of Knowledge Representation and Reasoning, Pierre Marquis, Tran Cao Son, and Gabriele Kern-Isberner (Eds.). 690–699. doi:10.24963/KR.2023/67 [35]Xinhai Zhang, Jianbo Tao, Kaige Tan, Martin Törngren, José Manuel Gaspar Sánchez, Muhammad Rusyadi Ramli, Xin Tao, Magnus Gyllenhammar, Franz Wotawa, Naveen Mohan, Mihai Nica, and Hermann Felbinger. 2021. Finding Crit- ical Scenarios for Automated Driving Systems: A Systematic Literature Review. CoRR abs/2110.08664 (2021). arXiv:2110.08664 https://arxiv.org/abs/2110.08664 [36]Ziyuan Zhong, Yun Tang, Yuan Zhou, Vania de Oliveira Neves, Yang Liu, and Baishakhi Ray. 2021. A Survey on Scenario-Based Testing for Automated Driving Systems in High-Fidelity Simulation. arXiv:2112.00964 [cs.SE] https://arxiv.org/ abs/2112.00964 12