Drivora: Unified ADS Testing Platform

• Drivora is an open-source CARLA-based infrastructure that unifies scenario definition, simulation execution, and ADS integration for search-based testing.
• It decouples the testing engine from scenario execution and supports parallel, multi-vehicle testing using evolutionary computation.
• The platform provides interoperability by hosting multiple testing algorithms and ADSs through a unified interface with the OpenScenario abstraction.

Drivora is an open-source, CARLA-based infrastructure for search-based testing of autonomous driving systems (ADSs). It is designed as a unified and extensible platform rather than a single testing algorithm: it provides a unified scenario definition called OpenScenario, decouples the testing engine from scenario execution and ADS integration, supports parallel execution and multi-autonomous-vehicle testing, and exposes 12 ADSs through a unified interface while integrating 5 search-based testing methods (Cheng et al., 9 Jan 2026). Its central purpose is to reduce the reusability, integration, and scalability problems that arise when search-based ADS testing methods are implemented as one-off systems with heterogeneous scenario spaces, simulators, and ADS bindings.

1. Scope, rationale, and conceptual position

Drivora addresses a software-engineering problem in autonomous driving evaluation: existing search-based ADS testing approaches are often built on distinct scenario encodings, simulator integrations, and ADS-specific dependencies, which makes them difficult to reuse, compare, and adapt across settings (Cheng et al., 9 Jan 2026). The infrastructure therefore standardizes three layers that are commonly entangled in prior work: scenario representation, execution in simulation, and the interface to the ADS under test.

The platform is built on CARLA and is explicitly oriented toward search-based testing rather than fixed benchmark playback. In the formulation described in the paper, the testing engine explores new scenarios with evolutionary computation; scenario execution can run arbitrary scenarios via a parallel mechanism intended to maximize hardware utilization; and ADS integration is handled through a unified interface that simplifies configuration and the addition of new systems (Cheng et al., 9 Jan 2026). This separation of concerns is a defining characteristic: Drivora is neither a planner nor a verifier in the narrow control-theoretic sense, but an infrastructure for generating, executing, and evaluating candidate test scenarios against multiple ADS implementations.

A frequent misconception is to treat Drivora as a single fuzzing method or as an ADS benchmark comparable to a static scenario suite. The paper states the opposite: Drivora is a testbed that can host multiple testing algorithms, multiple ADSs, and multiple scenario-generation designs, including multi-AV testing (Cheng et al., 9 Jan 2026). This suggests a platform role analogous to a common runtime and data model for scenario search, rather than a claim about one specific search heuristic being universally preferable.

2. System architecture and separation of responsibilities

The architecture is organized into four main components: ADS & Seed Integration, Testing Configuration, Testing Engine, and Scenario Execution Layer (Cheng et al., 9 Jan 2026). The first component provides resources, notably the ADS set and a seed scenario set. The second uses a compact configuration in config.yaml built around three fields—Tester, Agent, and Scenario—to instantiate a testing campaign. The third contains the search-based logic. The fourth executes scenarios in CARLA and collects runtime observations.

Within the Testing Engine, the paper identifies five subcomponents: Scenario Mutation, Scenario Execution, Testing Oracle, Testing Feedback, and Scenario Selection (Cheng et al., 9 Jan 2026). Scenario Mutation generates a population of scenarios by perturbing attributes exposed by the scenario template. Scenario Execution dispatches those scenarios to the execution layer. The Testing Oracle checks whether the ADS satisfies predefined testing requirements $G$, such as collision avoidance or route completion. Testing Feedback computes objective values from runtime observations, for example distance to NPC vehicles or time to complete the route. Scenario Selection then uses those signals to choose scenarios that seed the next generation.

The Scenario Execution Layer is the runtime substrate. It supports $K \geq 1$ isolated execution instances and $M \geq 1$ AVs in a single scenario (Cheng et al., 9 Jan 2026). Each execution instance can run in an isolated container with a CARLA server, accept a scenario in Drivora’s OpenScenario format, and produce a sequence of scene_obs records. The observation structure summarized in the paper includes step, timestamp, egos, other_actors, and agent_logs (Cheng et al., 9 Jan 2026). This layout is important because it allows the testing engine to remain agnostic to the internal design of the ADS while still exposing sufficient information for fitness computation and oracle evaluation.

The resulting architecture is strongly decoupled. A new search strategy can reuse the same execution layer and ADS bindings; a new ADS can reuse the same scenario format and testing engine; and a new scenario design can be introduced without rewriting the rest of the platform (Cheng et al., 9 Jan 2026). A plausible implication is that Drivora functions as a common interoperability layer for search-based testing research in CARLA.

3. OpenScenario and the scenario space

Drivora’s scenario abstraction is called OpenScenario in the paper. It is defined using low-level, simulator-actionable parameters so that scenarios can be executed directly in CARLA while remaining extensible to new testing designs (Cheng et al., 9 Jan 2026). The paper emphasizes that even high-level behaviors can be reduced to such parameters; for example, a lane-changing NPC can be represented as a sequence of waypoints that the vehicle follows (Cheng et al., 9 Jan 2026).

The template includes actor definitions, map scoping, environment parameters, and signal timing. The paper’s table lists the following entities and representative attributes.

Entity	Brief role	Representative attributes
ego_vehicles	AVs under test	id, model, route, start_time, config_path
npc_vehicles	Non-ego traffic vehicles	id, model, route, start_time
npc_walkers	Pedestrians	id, model, route, start_time
npc_obstacles	Static obstacles	id, model, location
map_region	Spatial scope in CARLA	town, region_segment
weather	Environment settings	CARLA weather parameters
traffic_lights	Signal timing	green_time, red_time, yellow_time

This design gives Drivora a common scenario space that can host multiple testing methods. Routes are represented as explicit waypoint sequences; actor start times are explicit; weather maps directly to CARLA parameters; and traffic lights are controlled by explicit phase durations (Cheng et al., 9 Jan 2026). The scenario model is intentionally minimal but extensible: new entities or attributes can be added without changing the overall architecture.

The importance of this representation lies in compatibility. Prior search-based methods often optimize over different abstractions, but many of those abstractions can be translated into low-level trajectories, timing, and environment parameters. Drivora’s OpenScenario therefore acts as a normalization layer for heterogeneous scenario-generation strategies (Cheng et al., 9 Jan 2026). This suggests that the platform’s main contribution is not expressiveness in the abstract, but executable interoperability.

4. Search-based testing workflow and evolutionary computation

The testing framework is described as being built on a classical evolutionary computation paradigm (Cheng et al., 9 Jan 2026). In operational terms, an individual corresponds to a scenario instance conforming to the OpenScenario template, and a generation contains $N$ such scenarios, which are executed, scored, and filtered before mutation produces the next batch.

Scenario Mutation perturbs the actionable parameters in the scenario template, including ego and NPC routes, start times, weather, traffic-light settings, and the addition or removal of vehicles, pedestrians, or obstacles (Cheng et al., 9 Jan 2026). Scenario Execution evaluates each mutated scenario in CARLA. The Testing Oracle determines whether the ADS satisfies predefined testing requirements $G$. Testing Feedback extracts objective values from scene_obs, such as distance to NPC vehicles or route-completion time. Scenario Selection uses those outputs to retain promising scenarios for continued search (Cheng et al., 9 Jan 2026).

The paper does not impose a single fixed objective function or formal specification language. Instead, it presents the oracle and feedback subsystems as pluggable components (Cheng et al., 9 Jan 2026). This is methodologically significant because different testing campaigns may optimize different notions of criticality: collision proximity, deadlock, traffic-law violations, coverage, or multi-objective combinations. The infrastructure is designed to support such variation without changing the execution substrate.

Although mutation is emphasized more than crossover in the paper, the surrounding design is generic enough to support custom recombination and alternative search procedures (Cheng et al., 9 Jan 2026). A plausible implication is that Drivora’s evolutionary-computation default should be understood as a reference design rather than a hard architectural constraint. The platform primarily standardizes how scenarios are represented, executed, and evaluated.

5. Parallel execution, multi-AV testing, and ADS integration

Scalability is a major design goal. Drivora supports parallel execution with $K \geq 1$ isolated execution instances and requires only that the number of individuals per generation satisfy $N \geq K$ (Cheng et al., 9 Jan 2026). The paper reports that throughput grows almost linearly with the number of parallel instances $K$, which it interprets as validation of the parallel execution layer (Cheng et al., 9 Jan 2026). The execution model is containerized: each instance can run in an isolated Docker container with its own CARLA server.

The infrastructure also supports multi-AV scenarios with $M \geq 1$ ego vehicles in a single world (Cheng et al., 9 Jan 2026). Each AV has its own route and start time in ego_vehicles, and all AVs are controlled by the same ADS under test through a unified interface. This enables traffic-level testing phenomena, such as deadlocks among multiple autonomous vehicles, that are not exposed by single-ego scenario execution (Cheng et al., 9 Jan 2026).

ADS integration is handled through a minimal agent API centered on setup_env() and run_step() (Cheng et al., 9 Jan 2026). The former initializes the simulator, spawns actors, and prepares the ADS agent. The latter advances the simulation by one tick, consumes the current simulation state, returns control actions, and records internal ADS logs into the scenario observation. The paper argues that this abstraction is sufficient to unify modular ADSs, end-to-end systems, and vision-language-based systems (Cheng et al., 9 Jan 2026).

This integration strategy matters because it lowers the marginal cost of adding a new ADS. The testing engine and scenario execution layer do not need to know the ADS internals, only how to initialize it and query it at runtime (Cheng et al., 9 Jan 2026). In practice, Drivora is therefore positioned as a portability layer for ADS testing experiments, not merely a scenario generator.

6. Evaluation, discovered violations, and broader context

The paper presents a demo evaluation rather than a comprehensive benchmark study. Three main aspects are emphasized: violation discovery, execution efficiency, and multi-AV testing (Cheng et al., 9 Jan 2026). In the reported case studies, Drivora discovers a side collision at a junction caused by aggressive acceleration in the presence of other vehicles; a front collision caused by inadequate deceleration behind an NPC vehicle; and a prolonged stationary failure in a vision-language-based ADS that misinterprets a speed-limit sign as a stop sign (Cheng et al., 9 Jan 2026). It also discovers a deadlock involving three AVs controlled by the same ADS in a multi-vehicle scenario (Cheng et al., 9 Jan 2026).

These examples illustrate the infrastructure’s intended use: searching for failure-inducing scenarios across distinct ADS architectures under a shared execution and logging model. The paper does not claim that the case studies constitute exhaustive comparative evidence across all supported testers and ADSs; rather, it positions them as demonstrations that the unified scenario model, parallel execution, and ADS abstraction are operationally useful (Cheng et al., 9 Jan 2026).

Within the broader literature, Drivora occupies the testing layer rather than the planning or reasoning layer. This distinguishes it from the similarly named “DrivoR,” which is a pure-transformer end-to-end planner using camera-aware register tokens and lightweight transformer decoders for trajectory generation and scoring (Kirby et al., 8 Jan 2026). It is also distinct from “DriveVer,” a lightweight plug-and-play test-time verifier that scores and refines candidate trajectories during inference (He et al., 1 Jul 2026); from “DriveAgent,” an LLM-based multi-agent reasoning framework built on multimodal sensor fusion and urgency-aware decision generation (Hou et al., 4 May 2025); and from the two “DRIVE” frameworks, one focused on dependable robust interpretable concept-bottleneck driving models (Lai et al., 2024) and one focused on dynamic rule inference and verified evaluation for constraint-aware planning via probabilistic soft constraints and convex optimization (Geng et al., 6 Aug 2025). The naming overlap can obscure an important distinction: Drivora is an infrastructure for testing ADSs, not a driving policy, rule-inference planner, or test-time trajectory corrector.

The paper acknowledges several limitations. Drivora is bound to CARLA, so its realism is limited by CARLA’s fidelity; generating realistic and high-coverage scenarios still depends on the underlying mutation or generation method; and large-scale search remains computationally expensive even with parallelization (Cheng et al., 9 Jan 2026). Future work identified in the paper includes systematic cross-ADS and cross-tester experiments, continued maintenance and extension of the platform, and the incorporation of advanced scenario-mutation methods, notably reinforcement-learning-based approaches (Cheng et al., 9 Jan 2026).

In that sense, Drivora is best understood as infrastructure for experimental unification. Its principal contribution is not a new oracle, a new planner, or a new search heuristic in isolation, but a common engineering substrate on which those components can be combined, compared, and scaled.