---
title: 'Drivora: Unified ADS Testing Platform'
url: https://www.emergentmind.com/topics/drivora
type: topic
---

# Drivora: Unified ADS Testing Platform

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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685]. 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` [2601.05685]. 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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685].

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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685].

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 [2601.05685]. 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 [2601.05685]. 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\) [2601.05685]. 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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685].

ADS integration is handled through a minimal agent API centered on `setup_env()` and `run_step()` [2601.05685]. 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 [2601.05685].

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 [2601.05685]. 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 [2601.05685]. 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 [2601.05685]. It also discovers a deadlock involving three AVs controlled by the same ADS in a multi-vehicle scenario [2601.05685].

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 [2601.05685].

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 [2601.05083]. It is also distinct from “DriveVer,” a lightweight plug-and-play test-time verifier that scores and refines candidate trajectories during inference [2607.00399]; from “DriveAgent,” an LLM-based multi-agent reasoning framework built on multimodal sensor fusion and urgency-aware decision generation [2505.02123]; and from the two “DRIVE” frameworks, one focused on dependable robust interpretable concept-bottleneck driving models [2409.10330] and one focused on dynamic rule inference and verified evaluation for constraint-aware planning via probabilistic soft constraints and convex optimization [2508.04066]. 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 [2601.05685]. 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 [2601.05685].

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.

Source: https://www.emergentmind.com/topics/drivora