SceneChecker : Boosting Scenario Veriﬁcation using Symmetry Abstractions (cid:63)

. We present SceneChecker , a tool for verifying scenarios involving vehicles executing complex plans in large cluttered workspaces. SceneChecker converts the scenario veriﬁcation problem to a standard hybrid system veriﬁcation problem, and solves it effectively by exploiting structural properties in the plan and the vehicle dynamics. SceneChecker uses symmetry abstractions, a novel reﬁne-ment algorithm, and importantly, is built to boost the performance of any existing reachability analysis tool as a plug-in subroutine. We evaluated SceneChecker on several scenarios involving ground and aerial vehicles with nonlinear dynamics and neural network controllers, employing different kinds of symmetries, using different reachability subroutines, and following plans with hundreds of way-points in complex workspaces. Compared to two leading tools, DryVR and Flow*, SceneChecker shows 14 × average speedup in veriﬁcation time, even while using those very tools as reachability subroutines 1 .


Introduction
Remarkable progress has been made in safety verification of hybrid and cyber-physical systems in the last decade [2,3,4,5,6,7,8,9]. The methods and tools developed have been applied to check safety of aerospace, medical, and autonomous vehicle control systems [4,5,10,11]. The next barrier in making these techniques usable for more complex applications is to deal with what is colloquially called the scenario verification problem. A key part of the scenario verification problem is to check that a vehicle or an agent can execute a plan through a complex environment. A planning algorithm (e.g., probabilistic roadmaps [12] and rapidly-exploring random trees (RRTs) [13]) generates a set of possible paths avoiding obstacles, but only considering the geometry of the scenario, not the dynamics. The verification task has to ensure that the plan can indeed be The authors are supported by a research grant from The Boeing Company and a research grant from NSF (FMITF: 1918531). We would like to thank John L. Olson, Aaron A. Mayne, and Michael R. Abraham from The Boeing Company for valuable technical discussions. 1 SceneChecker can be found on figshare: https://figshare.com/articles/software/CAV2021_ reduce_v6_ova/14504352, gitlab: https://gitlab.engr.illinois.edu/sibai2/multi-drone_simulator/ -/tree/CAV_artifact, and its website: https://publish.illinois.edu/scenechecker/. An extended version of this paper is available online [1].
safely executed by the vehicle with all the dynamic constraints and the state estimation uncertainties. Indeed, one can view a scenario as a hybrid automaton with the modes defined by the segments of the planner, but this leads to massive models. Encoding such automata in existing tools presents some practical hurdles. More importantly, analyzing such models is challenging as the over-approximation errors and the analysis times grow rapidly with the number of transitions. At the same time, such large hybrid verification problems also have lots of repetitions and symmetries, which suggest new opportunities. We present SceneChecker, a tool that implements a symmetry abstraction-refinement algorithm for efficient scenario verification. Symmetry abstractions significantly reduce the number of modes and edges of an automaton H by grouping all modes that share symmetric continuous dynamics [14]. SceneChecker implements a novel refinement algorithm for symmetry abstractions and is able to use any existing reachability analysis tool as a subroutine. Our current implementation comes with plug-ins for using Flow* [4] and DryVR [6]. SceneChecker's verification algorithm is sound, i.e., if it returns safe, then the reachset of H indeed does not intersect the unsafe set. The algorithm is lossless in the sense that if one can prove safety without using abstraction, then SceneChecker can also prove safety via abstraction-refinement, and typically a lot faster.
SceneChecker offers an easy interface to specify plans, agent dynamics, obstacles, initial uncertainty, and symmetry maps. SceneChecker checks if a fixed point has been reached after each call to the reachability subroutine, avoiding repeating computations. First, SceneChecker represents the input scenario as a hybrid automaton H where modes are defined by the plan's segments. It uses the symmetry maps provided by the user to construct an abstract automaton H v . Automaton H v represents another scenario with fewer segments, each representing an equivalence class of symmetric segments in H. A side effect of the abstraction is that upon reaching waypoints in H v , the agent's state resets non-deterministically to a set of possible states. For example, in the case of rotation and translation invariance, the abstract scenario would have a single segment for any set of segments with a unique length in the original scenario. SceneChecker refines H v by splitting one of its modes to two modes. That corresponds to representing a set of symmetric segments with one more segment in the abstract scenario, capturing more accurately the original scenario 2 .
We evaluated SceneChecker on several scenarios where car and quadrotor agents with nonlinear dynamics follow plans to reach several destinations in 2D and 3D workspaces with hundreds of waypoints and polytopic obstacles. We considered different symmetries (translation and rotation invariance) and controllers (Proportional-Derivative (PD) and Neural Networks (NN)). We compared the verification time of SceneChecker with DryVR and Flow* as reachability subroutines against Flow* and DryVR as standalone tools. SceneChecker is faster than both tools in all scenarios considered, achieving an average of 14× speedup in verification time (Table 1). In certain scenarios where Flow* timed out (executing for more than 120 minutes), SceneChecker is able to complete verification in as fast as 12 minutes using Flow* as a subroutine. SceneChecker when using abstraction-refinement achieved 13× speedup in verification time over not using abstraction-refinement in scenarios with the NN-controlled quadrotor (Section 7).
In our context of cyber-physical systems, Bak et al. [24] suggested using symmetry maps, called reachability reduction transformations, to transform reachsets to symmetric reachsets for continuous dynamical systems modeling non-interacting vehicles. Maidens et al. [25] proposed a symmetry-based dimensionality reduction method for backward reachable set computations for discrete dynamical systems. Majumdar et al. [26] proposed a safe motion planning algorithm that computes a family of reachsets offline and composes them online using symmetry. Bujorianu et al. [27] presented a symmetry-based theory to reduce stochastic hybrid systems for faster reachability analysis and discussed the challenges of designing symmetry reduction techniques across mode transitions.
In a more closely related research, we presented a modified version of DryVR that utilizes symmetry to cache reachsets aiming to accelerate simulation-based safety verification of continuous dynamical systems [28]. We developed the related tool CacheReach that implements a hybrid system verification algorithm that uses symmetry to accelerate reachability analysis [29]. CacheReach caches and shares computed reachsets between different modes of non-interacting agents using symmetry. SceneChecker is based on the theory of symmetry abstractions of hybrid automata we presented in [14]. We suggested computing the reachset of the abstract automaton instead of the concrete one then transform it to the concrete reachset using symmetry maps to accelerate verification. SceneChecker is built based on this line of work with significant algorithmic and engineering improvements. In addition to the abstraction of [14], SceneChecker 1) maps the unsafe set to an abstract unsafe set and verifies the abstract automaton instead of the concrete one and 2) decreases the over-approximation error of the abstraction through refinement. SceneChecker does not cache reachsets and thus saves cache-access and reachset-transformation times and does not incur over-approximation errors due to caching that CacheReach suffers from [29]. At the implementation level, SceneChecker accepts plans that are general directed graphs and polytopic unsafe sets while CacheReach accepts only single-path plans and hyperrectangle unsafe sets. We show more than 30× speedup in verification time while having more accurate verification results when comparing SceneChecker against CacheReach ( Table 1 in Section 7).

Specifying Scenarios in SceneChecker
A scenario verification problem is specified by a set of fixed obstacles, a plan, and an agent that is supposed to execute the plan without running into the obstacles (e.g., see Figure 1.B). For ground and air vehicles, for example, the agent moves in a subset of the 2D or the 3D Euclidean space called the workspace. A plan is a directed graph G = V, S with vertices V in the workspace called waypoints and edges S called segments 3 .A general graph allows for nondeterministic and contingency planning.
An agent is a control system that can follow waypoints. Let the state space of the agent be X and Θ ⊆ X be the uncertain initial set. Let s init be the initial segment in G that the agent has to follow. From any state x ∈ X, the agent follows a segment s ∈ S by moving along a trajectory. A trajectory is a function ξ : X × S × R ≥0 → X that meets certain dynamical constraints of the vehicle. Dynamics are either specified by ordinary differential equations (ODE) or by a black-box simulator. For ODE models, ξ is a solution of an equation of the form: dξ dt (x, s,t) = f (ξ (x, s,t), s), for any t ∈ R ≥0 and ξ (x, s, 0) = x, where f : X × S → X is Lipschitz continuous in the first argument. Note that the trajectories only depend on the segment the agent is following (and not on the full plan G). We denote by ξ .fstate, ξ .lstate, and ξ .dom the initial and last states and the time domain of the time bounded trajectory ξ , respectively.
We can view the obstacles near each segment as sets of unsafe states, O : S → 2 X . The map tbound : S → R ≥0 determines the maximum time the agent should spend in following any segment. For any pair of consecutive segments (s, s ), i.e. sharing a common waypoint in G, guard((s, s )) defines the set of states (a hyperrectangle around a waypoint) at which the agent is allowed to transition from following s to following s .
Scenario JSON file is the first of the two user inputs. It specifies the scenario: Θ as a hyperrectangle; S as a list of lists each representing two waypoints; guard as a list of hyperrectangles; tbound as a list of floats; and O as a list of polytopes.
Output of SceneChecker is the scenario verification result (safe or unknown) and a number of useful performance metrics, such as the number of modesplits, number of reachability calls, reachsets computation time, and total time. SceneChecker can also visualize the various computed reachsets.

Transforming Scenarios to Hybrid Automata
The input scenario is first represented as a hybrid automaton by a Hybrid constructor. This constructor is a Python function that parses the Scenario file and constructs the data structures to store the scenario's hybrid automaton components. In what follows, we describe the constructed automaton informally. In our current implementation, sets are represented either as hyper-rectangles or as polytopes using the Tulip Polytope Library 4 .
Scenario as a hybrid automaton A hybrid automaton has a set of modes (or discrete states) and a set of continuous states. The evolution of the continuous states in each mode is specified by a set of trajectories and the transition across the modes are specified by guard and reset maps. The agent following a plan in a workspace can be naturally modeled as a hybrid automaton H, where s init and Θ are its initial mode and set of states.
Each segment s ∈ S of the plan G defines a mode of H (e.g. see Figure 1.A). The set of edges E ⊆ S × S of H is defined as pairs of consecutive segments in G. For an edge e ∈ E, guard(e) is the same as that of G. The reset map of H is the identity map. We will see in Section 5 that abstract automata will have nontrivial reset maps.
Verification problem An execution of length k is a sequence σ := (ξ 0 , s 0 ), . . . , (ξ k , s k ). It models the behavior of the agent following a particular path in the plan G. An execution σ must satisfy: The set of reachable states is Reach H := {σ .lstate | σ is an execution}. The restriction of Reach H to states with mode s ∈ S (i.e., agent following segment s) is denoted by Reach H (s). Thus, the hybrid system verification problem requires us to check whether ∀s ∈ S, Reach H (s) ∩ O(s) = / 0.

Specifying Symmetry Maps in SceneChecker
The hybrid automaton representing a scenario, as constructed by the Hybrid constructor, is transformed into an abstract automaton. SceneChecker uses symmetry abstractions [14]. The abstraction is constructed by the abstract function (line 1 of Algorithm 1) which uses a collection of pairs of maps Φ = {(γ s : X → X, ρ s : S → S)} s∈S that is provided by the user. We describe below how these maps are specified by the user in the Dynamics file. These maps should satisfy: where ∀s ∈ S, the map γ s is differentiable and invertible. Such maps are called symmetries for the agent's dynamics. They transform the agent's trajectories to other symmetric ones of its trajectories starting from symmetric initial states and following symmetric modes (or segments in our scenario verification setting). It is worth noting that (1) does not depend on whether the trajectories ξ are defined by ODEs or black-box simulators. Currently, condition (1) is not checked by SceneChecker for the maps specified by the user. However, in the following discussion, we present some ways for the user to check (1) on their own. For ODE models, a sufficient condition for (1) to be satisfied where f is the right-hand-side of the ODE [30]. For black-box models, (1) can be checked using sampling methods. In realistic settings, dynamics might not be exactly symmetric due to unmodeled uncertainties. In the future, we plan to account for such uncertainties as part of the reachability analysis.
In scenario verification, a given workspace would have a coordinate system according to which the plan (waypoints) and the agent's state (position, velocity, heading angle, etc.) are represented. In a 2D workspace, for any segment s ∈ S, an example symmetry ρ s would transform the two waypoints of s to a new coordinate system where the second waypoint is the origin and s is aligned with the negative side of the horizontal axis (see Figure 1.D). The corresponding γ s would transform the agent's state to this new coordinate system (e.g. by rotating its position and velocity vectors and shifting the heading angle). For such a pair (γ s , ρ s ) to satisfy (1), the agent's dynamics have to be invariant to such a coordinate transformation and (1) merely formalizes this requirement. Such an invariance property is expected from vehicles' dynamics-rotating or translating the lane should not change how an autonomous car behaves.
Dynamics file is the second input provided by the user in addition to the Scenario file and it contains the following: polyVir(X , s): returns γ s (X ) for any polytope X ⊂ X and segment s ∈ S. modeVir(s): returns ρ s (s) for any given segment s ∈ S. virPoly(X , s): returns γ −1 s (X ), implementing the inverse of polyVir. computeReachset(initset, s, T ): returns a list of hyperrectangles overapproximating the agent's reachset starting from initset following segment s for T time units, for any set of states initset ⊂ X, segment s ∈ S, and T ≥ 0.

Symmetry Abstraction of the Scenario's Automaton
In this section, we describe how the abstract function in Algorithm 1 uses the functions in the Dynamics file to construct an abstraction of the scenario's hybrid automaton provided by the Hybrid constructor. Given the symmetry maps of Φ, the symmetry abstraction of H is another hybrid automaton H v that aggregates many symmetric modes (segments) of H into a single mode of H v . is mapped to γ s (guard(e)) using polyVir which becomes part of guard v (e v ) in H v . For any x ∈ X, reset(x, e), which is equal to x, is mapped to γ s (γ −1 s (x)) and becomes part of reset v (x, e v ) in H v . In our example in Section 4, the γ −1 s (x) would represent x in the absolute coordinate system assuming it was represented in the coordinate system defined by segment s. The γ s (γ −1 s (x)) would represent γ −1 s (x) in the new coordinate system defined by segment s . The guard v (e v ) would be the union of rotated hyperrectangles centered at the origin that result from translating and rotating the guards of the edges represented by e v . The initial set Θ of H is mapped to Θ v = γ s init (Θ ), the initial set of H v . A formal definition of symmetry abstractions can be found in [1] (or [14]).

Modes and Transitions
The . That means the obstacles near any segment s ∈ S in the environment will be mapped to be near its representative segment ρ s (s) in H v .
A forward simulation relation between H and

SceneChecker Algorithm Overview
A sketch of the core abstraction-refinement algorithm is shown in Algorithm 1. It constructs a symmetry abstraction H v of the concrete automaton H resulting from the Hybrid The unsafe set is transformed accordingly for each mode as shown in D. SceneChecker computes the reachset of C which turns out to be unsafe; to illustrate the process this abstract reachset transformed to the original scenario is shown in E. The colors refer to a different abstract modes. The algorithm refines C to F adding s 2 v (same segment as s 1 v but different guard). The reachset of F is safe and the algorithm terminates (H).
constructor. SceneChecker attempts to verify the safety of H v using traditional reachability analysis. SceneChecker uses a cache to store per-mode initial sets from which reachsets have been computed and thus avoids repeating computations. An example run is shown in Figure 1.
if result = safe or unknown then return: result 7: The core algorithm verify (Algorithm 2) is called iteratively. If verify returns (safe, ⊥) or (unknown, ⊥), SceneChecker returns the same result. If verify instead results in (refine, s * v ), splitMode (check the extended version of this paper [1] for the formal definition) is called to refine H v by splitting s * v into two modes s 1 v and s 2 v . Each of the two modes would represent part of the set of the segments of S that were originally mapped to s v in rv. Then the edges, guards, resets, and the unsafe sets related to s v are split according to their definitions.
The function verify executes a depth first search (DFS) over the mode graph of H v . For any mode s v being visited, computeReachset computes R v , an over-approximation of the agent's reachset starting from initset following segment s v for time tbound v (s v ).
0, verify recursively calls s v 's children continuing the DFS in line 6. Before calling each child, its initial set is computed and the part for which a reachset has already been computed and stored in cache is subtracted. If all calls return safe, then initset is added to the other initial sets in cache[s v ] (line 12) and verify returns safe. Most importantly, if verify returns (refine, s * v ) for any of s v 's children, it directly returns (refine, s * v ) for s v as well (line 7). If any child returns unknown or R v intersects O v (s v ), verify will need to split s v . In that case, it checks if rv −1 [s v ] is not a singleton set and thus amenable to splitting (line 10). If s v can be split, verify returns (refine, s v ). Otherwise, verify returns (unknown, ⊥) implicitly asking one of s v 's ancestors to be split instead.
Correctness SceneChecker ensures that all the refined automata H v 's are abstractions of the original hybrid automaton H (a proof is given in the extended version of this paper [1]). For any mode with a reachset intersecting the unsafe set, SceneChecker keeps refining that mode and its ancestors until safety can be proven or H v becomes H.

Theorem 1 (Soundness). If SceneChecker returns safe, then H is safe.
if result = refine then return: refine, s * If verify is provided with the concrete automaton H and unsafe set O, it will be the traditional safety verification algorithm having no over-approximation error due to abstraction. If such a call to verify returns safe, then SceneChecker is guaranteed to return safe. That means that the refinement ensures that the over-approximation error of the reachset caused by the abstraction is reduced to not alter the verification result.
Counter-examples SceneChecker currently does not find counter-examples to show that the scenario is unsafe. There are several sources of over-approximation errors, namely, computeReachset and guard intersections. Even after all the over-approximation errors from symmetry abstractions are eliminated, as refinement does, it still cannot infer unsafe executions or counter-examples because of the other errors. We plan to address this in the future by combining the current algorithm with systematic simulations.

Experimental Evaluation
Agents and controllers In our experiments, we consider two types of nonlinear agent models: a standard 3-dimensional car (C) with bicycle dynamics and 2 inputs, and a 6-dimensional quadrotor (Q) with 3 inputs. For each of these agents, we developed a PD controller and a NN controller for tracking segments. The NN controller for the quadrotor is from Verisig's paper [9] but modified to be rotation symmetric (check the extended version of this paper [1] for more details). Similarly, the NN controller for the car is also rotation symmetric. Both NN controllers are translation symmetric as they take as input the difference between the agent's state and the segment being followed. The PD controllers are translation and rotation symmetric by design.

Symmetries
We experimented with two different collections of symmetry maps Φs: 1) translation symmetry (T), where for any segment s in G, γ s maps the states so that the coordinate system is translated by a vector that makes its origin at the end waypoint of s, and 2) rotation and translation symmetry (TR), where instead of just translating the origin, Φ rotates the xy-plane so that s is aligned with the x-axis, which we described in Section 4. For each agent and one of its controllers, we manually verified that condition (1) is satisfied for each of the two Φs using the sufficient condition for ODEs in Section 4.
Scenarios We created four scenarios with 2D workspaces (S1-4) and one scenario with a 3D workspace (S5) with corresponding plans. We generated the plans using an RRT planner [31] after specifying a number of goal sets that should be reached. We modified S4 to have more obstacles but still have the same plan and named the new version S4.b and the original one S4.a. When the quadrotor was considered, the waypoints of the 2D scenarios (S1-4) were converted to 3D representation by setting the altitude for each waypoint to 0. Scenario S5 is the same as S2 but S5's waypoints have varying altitudes. The scenarios have different complexities ranging from few segments and obstacles to hundreds of them. All scenarios are safe when traversed by any of the two agents.
We verify these scenarios using SceneChecker and CacheReach, each with two instances, one with DryVR and the other with Flow*, implementing computeReachset. We also use DryVR and Flow* as independent tools to verify the same scenarios. The results of experiments with tools that involve DryVR (i.e., SceneChecker+DryVR, CacheReach+DryVR, and DryVR) are stochastic and change between runs. The reason is that each time DryVR is called, it randomly samples traces of the system from which it computes the requested reachset. We fix the random seed for repeatable results in this section. We show close averaging-based results on SceneChecker's website.
SceneChecker is able to verify all scenarios with PD controllers. The results are shown in Table 1 5 and plotted for C-S1 using SceneChecker+Flow* in Figure 1.
Observation 1: SceneChecker offers fast scenario verification and boosts existing reachability tools Looking at the two total time (Tt) columns for the two instances of SceneChecker with the corresponding columns for Flow* and DryVR, it becomes clear that symmetry abstractions can boost the verification performance of reachability engines. For example, in C-S4.a, SceneChecker+DR was around 20× faster than DryVR. In C-S3, SceneChecker with Flow* was around 16× faster than Flow*. In scenario Q-S5, SceneChecker timed out at least in part because a computeReachset call to Flow* timed out. Even when many refinements are required and thus causing several repetitions of the verification process in Algorithm 1, SceneChecker is still faster than DryVR and Flow* (C-S4.b). All three tools resulted in safe for all scenarios when completed executions. Table 1: Comparison between SceneChecker, DryVR (DR), Flow* (F*), and CacheReach (CacheR). Both SceneChecker and CacheReach use reachability tools as subroutines. The subroutines used are specified after the '+' sign. Φ is TR. The table shows the number of mode-splits performed (Nrefs), the total number of calls to computeReachset (Rc), the total time spent in reachset computations (Rt), and the total computation time in minutes (Tt). In scenarios where a tool ran over 120 minutes, we marked the Tt column as 'Timed out' (TO) and the other ones as 'Not Available' (NA). Observation 2: SceneChecker is faster and more accurate than CacheReach Since CacheReach only handles single-path plans, we only verify the longest path in the plans of the scenarios in its experiments. CacheReach's instance with Flow* resulted in unsafe reachsets in C-S1 and C-S4.b scenarios likely because of the caching over-approximation error. In all scenarios where CacheReach completed verification besides C-S4.b, it has more Rc and longer Tt (more than 30× in C-S2) while verifying simpler plans than SceneChecker using the same reachability subroutine. In all Q scenarios, CacheReach's instance with Flow* timed out, while its instance with DryVR terminated with an error.
Observation 3: More symmetric dynamics result in faster verification time SceneChecker usually runs slower in 3D scenarios compared to 2D ones (Q-S2 vs. Q-S5) in part because there is no rotational symmetry in the z-dimension to exploit. That leads to larger abstract automata. Therefore, many more calls to computeReachset are required. We only used SceneChecker's instance with DryVR for agents with NN-controllers 6 . We tried different Φs. The results are shown in Table 2. When not using abstractionrefinement, SceneChecker took 10.5, 130.95, and 74.15 minutes for the QNN-S2, QNN-S3, and QNN-S4 scenarios, while DryVR took 5.22, 52.56, and 61.31 minutes for the same scenarios, respectively. Comparing these results with those in Table 2 shows that the speedup in verification time of SceneChecker is caused by the abstractionrefinement algorithm, achieving more than 13× in certain scenarios (QNN-S4 using Φ = T). SceneChecker+DR was more than 10× faster than DryVR in the same scenario.  Observation 4: Choice of Φ is a trade-off between over-approximation error and number of refinements The choice of Φ affects the number of refinements performed and the total running times (e.g. QNN-S2, QNN-S3, and QNN-S4). Using TR leads to a more succinct H v but larger over-approximation error causing more mode splits. On the other hand, using T leads to a larger H v but less over-approximation error and thus fewer refinements. This trade-off can be seen in Table 2. For example, QNN-S4 with Φ =T resulted in zero mode splits leading to |S v | i = |S v | f = 7, while Φ = TR resulted in 4 mode splits, starting with |S v | i = 1 modes and ending with |S v | f = 5, and longer verification time because of refinements. On the other hand, in QNN-S3, Φ = TR resulted in Nref= 5, |S v | f = 6, and Tt= 12.7 min while Φ =T resulted in Nref= 4, |S v | f = 11, and Tt= 16.83 min.
Observation 5: Complicated dynamics require more verification time Different vehicle dynamics affect the number of refinements performed and consequently the verification time (e.g. QNN-S2, QNN-S4, CNN-S2, and CNN-S4). The car appears to be less stable than the quadrotor leading to longer verification time for the same scenarios. This can also be seen by comparing the results of Tables 1 and 2. The PD controllers lead to more stable dynamics than the NN controllers requiring less total computation time for both agents. More stable dynamics lead to tighter reachsets and fewer refinements.

Limitations and Discussions
SceneChecker allows the choice of modes to be changed from segments to waypoints or sequences of segments as well. The waypoint-defined modes eliminate the need for segments of G to have few unique lengths, but only allow Φ =T. SceneChecker splits only one mode per refinement and then repeats the computation from scratch. It has to refine many times in unsafe scenarios until reaching the result unknown. We plan to investigate other strategies for eliminating spurious counter-examples and returning valid ones in unsafe cases. In the future, it will be important to address other sources of uncertainty in scene verification such as moving obstacles, interactive agents, and other types of symmetries such as permutation and time scaling. Finally, it will be useful to connect a translator to generate scene files from common road simulation frameworks such as CARLA [32], commonroad [33], and Scenic [34].