ADORe: Uniﬁed Modular Framework for Vehicle and

Infrastructure-Based System Level Automation

Mikkel Skov Maarssoe

, Sanath Konthala

, Marko Mizdrak

, Giovanni Lucente

, Matthias

Nichting

, Thomas Lobig

and Andrew Koerner

Institute of Transportation Systems, German Aerospace Center (DLR), Lilienthalplatz 7, 38108 Braunschweig, Germany

{mikkel.maarssoe, sanath.konthala, m cente, matthias.nichting, thomas.lobig,

andrew.koerner}@dlr.de

Keywords:

Automated Driving, Cooperative Automated Driving, Research Framework, Modular Software, Open-Source,

System-Level Automation.

Abstract:

Recent advancements in automated driving have primarily focused on achieving autonomy within individual

vehicles. However, a broader paradigm shift is emerging that leverages both vehicle-level autonomy and col-

laboration with other road users and infrastructure to optimize trafﬁc ﬂow and enhance safety. This paper intro-

duces ADORe

(Automated Driving Open Research), an open-source Automated Driving System developed

by the German Aerospace Center (DLR). ADORe adopts a modular, system-level approach, enabling seamless

integration between Single-Agent Automated Driving for local autonomy and Multi-Agent Autonomous Driv-

ing for infrastructure-assisted decision-making. By utilizing vehicle-to-infrastructure (V2X) communication,

ADORe facilitates coordinated multi-agent planning, dynamic route optimization, and improved situational

awareness through shared data. The framework supports ﬂexible testing via simulation tools like CARLA and

SUMO, alongside deployment on research vehicles equipped with advanced sensors and teleoperation capa-

bilities. Successful demonstrations in research projects like the German national Gaia-X4ROMS and MAD

Urban validate ADORe’s capability to bridge the gap between isolated autonomous driving and cooperative

trafﬁc systems. This collaborative approach highlights the potential of automated driving systems as a corner-

stone of intelligent transportation systems, advancing safety, efﬁciency, and interoperability.

1 INTRODUCTION

Recent progress in automated driving has demon-

strated remarkable advancements in perception,

decision-making, and control, bringing self-driving

vehicles closer to widespread deployment. However,

many current approaches still frame the challenge as

merely replacing human drivers inside the vehicles by

an artiﬁcial intelligence. This perspective alone ne-

glects the broader potential of automated driving as

a system-level innovation. Communication technolo-

gies, such as vehicle-to-vehicle (V2V) and vehicle-to-

infrastructure (V2I) connectivity, enable more com-

https://orcid.org/0009-0003-9999-8711

https://orcid.org/0009-0008-4096-7685

https://orcid.org/0009-0004-3931-2842

https://orcid.org/0000-0002-7844-853X

https://orcid.org/0000-0002-2484-4203

https://orcid.org/0009-0009-4158-5184

https://orcid.org/0009-0000-3837-3433

prehensive approaches to automated driving. By fa-

cilitating real-time information exchange between ve-

hicles and infrastructure, these technologies allow for

multi-agent decision-making that transcends the limi-

tations of local ego-vehicle-based optimization. Such

systems can promote collaboration, where vehicles

collectively negotiate trafﬁc ﬂow, adapt to dynamic

conditions, and coordinate their movement with in-

frastructure like trafﬁc lights and edge computers. A

taxonomy for the different possible classes of co-

operation is provided in SAE J3216 (SAE, 2024b),

distinguishing speciﬁcally ’status-sharing’, ’intent-

sharing’, ’agreement-seeking’ and ’prescriptive co-

operation’. The paradigm shift redeﬁnes automated

driving not merely as individual autonomy but as a

cornerstone of intelligent, cooperative mobility sys-

tems, paving the way for safer, more efﬁcient, and

seamlessly integrated transportation networks.

Automated Driving Open Research (ADORe

)

is the German Aerospace Center’s (DLR) open-

source Automated Driving System (ADS). Unlike

Maarssoe, M. S., Konthala, S., Mizdrak, M., Lucente, G., Nichting, M., Lobig, T. and Koerner, A.

ADORe: Uniﬁed Modular Framework for Vehicle and Infrastructure-Based System Level Automation.

DOI: 10.5220/0013405200003941

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 11th International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS 2025), pages 571-581

ISBN: 978-989-758-745-0; ISSN: 2184-495X

571

Figure 1: DLRs research CAVs, NGC-FASCar, ViewCar2,

& FASCarE.

many ADS that prioritize ego-vehicle performance,

ADORe adopts a system-level approach, facilitating

coordinated decision-making among Cooperative Au-

tomated Vehicles (CAV) and infrastructure systems.

Its modular and containerized framework supports

seamless integration and easy scalability, enabling ve-

hicles to operate both independently and collabora-

tively. ADORe’s dynamic design allows CAVs to

continuously communicate with trafﬁc lights, other

vehicles, and infrastructure components facilitating

the optimization of trafﬁc ﬂow and the enhancement

of safety and efﬁciency. It enables adapting to vary-

ing operating domains by seamlessly switching be-

tween local autonomy, infrastructure-based support

and decision-making, and human-assisted remote op-

eration. By bridging the gap between isolated auton-

omy and cooperative trafﬁc management, ADORe al-

lows researchers to work with a system-wide perspec-

tive of automated driving. As such tool, its goal is to

be used for prototypic research testing, and not for full

SAE Level 4 and above driving (SAE, 2024a).

2 STATE OF THE ART

The ﬁeld of Automated Driving Systems (ADS) has

seen a surge in open-source tools in recent years. Due

to the complexity of the driving task, there is no per-

fect tool that ﬁts all needs. Many of these tools are

focused on a particular level of abstraction like trafﬁc

design, sensor processing, driving policy, and others.

Having multiple integrated tools that leverage the

advantages of more than one approach is an obvi-

ous path for ADS technology development, making

the journey from idea to proof-of-concept prototype

faster and easier.

There are already several existing open-source au-

tomation stacks that have been accessible for years

and have matured into well-developed software. Au-

toware (Aut, 2023) is an open-source highly fea-

tured Automated Driving Stack based on ROS2, de-

veloped at Nagoya University. It is well-documented

and maintained. Another automation stack is Apollo

(Apo, 2024), based on the open-source middleware

Apollo Cyber RT, developed by Baidu. RoboCar

(Testouri et al., 2024) is another recent modular and

cost-effective Automated Driving Stack. Alterna-

tively, there are Automated Driving Stacks that are

designed around research into Cooperative Driving

like OpenCDA that focus on providing an environ-

ment for testing cooperative driving algorithms (Xu

et al., 2021). For a comprehensive overview, we refer

the reader to the survey papers (Tang et al., 2023), (Li

et al., 2023).

Alongside these automation stacks, domain-

speciﬁc simulation and modeling tools have been de-

veloped to address particular ADS application re-

quirements. SUMO (Behrisch et al., 2011) is used for

trafﬁc ﬂow simulation (supporting V2X communica-

tion and linking to network simulation tools like ns-3

ucken et al., 2021)), CARLA (Dosovitskiy et al.,

2017) for vehicle dynamics simulation and different

scenarios testing, and CommonRoad (Althoff et al.,

2017), which focuses on planning policies. Compre-

hensive surveys on available tools (Li et al., 2023)

(Tong et al., 2020) emphasize that the need for more

integration of ADS tools, such as with SUMO for traf-

ﬁc simulation and with CARLA for more realistic ve-

hicle dynamics, is critical.

3 METHODS

3.1 Architecture

ADORe is a modular system designed to be easily

adaptable to other frameworks and various hardware

VEHITS 2025 - 11th International Conference on Vehicle Technology and Intelligent Transport Systems

572

components. To achieve this, ADORe is conceptual-

ized as two different categories of modules each con-

taining its own set of nodes, the interface modules,

and the ADORe Core. The ADORe interface mod-

ules are all hardware or companion software speciﬁc,

meaning speciﬁcally designed for the DLR-provided

hardware and software, or other companion software

like the CARLA Simulator. The ADORe Core con-

tains all modules for route planning, trajectory plan-

ning, and control used to achieve automated driv-

ing, and are speciﬁcally designed to avoid hardware

or companion software-speciﬁc implementations, and

are therefore adaptable to other frameworks as long as

they fulﬁll the message and topic requirements of the

ADORe Core ROS2 nodes. The ADORe Core can

be further categorized into two distinct sets of mod-

ules, as the planning behavior differs between them:

on the one hand, the Single-Agent Automated Driving

(SAAD) modules, and on the other hand, the Multi-

Agent Automated Driving (MAAD) modules. A sim-

pliﬁed overview of all the modules can be seen in Fig.

Figure 2: ADORes main categories of modules, ADORe in-

terface and ADORe core. The ADORe Core is further sepa-

rated into modules used for single-agent automated driving

(SAAD) and multi-agent automated driving (MAAD).

What distinguishes ADORe from many other al-

ternative ADS is that it is designed not only to run on

local hardware in a single ego vehicle using SAAD,

but also to perform planning for groups of CAVs when

operating on remote hardware, such as road-based lo-

cal infrastructure communicating through V2X with

the individual vehicles. ADORe is designed around

this collaborative relationship between SAAD and

MAAD, as depicted in Fig. 3. ADORe enables a CAV

running ADORe SAAD to drive autonomously on lo-

cal in-vehicle hardware when out of range of cooper-

ative infrastructure, yet supports switching to receiv-

ing its trajectories, control or maneuver advisories or

commands from ADORe MAAD through V2X when-

ever available. The beneﬁt of using infrastructure-

provided commands and advisories is that they are

based on local infrastructure sensors tailored to the

related terrain and therefore enhancing safety, while

they can also be inﬂuenced by trafﬁc management

systems focusing on the optimized throughput and

efﬁciency of all trafﬁc participants in the local area

(Schindler et al., 2023).

Figure 3: A scenario showing a vehicle driving along a

route, running ADORe SAAD for autonomous driving,

when the car is within range of the infrastructure running

ADORe MAAD, the planning switches to be handled on

the infrastructure and gets switched back again once the ve-

hicle is out of range.

3.2 Integrated Build System &

Development Environment

ADORe features a container-based development en-

vironment built on Docker (Doc, 2024). This sys-

tem serves multiple roles, acting as a development

environment with debugging and development tools

preinstalled, as well as a runtime environment with

all necessary dependencies. It includes a virtual dis-

play for executing commands and programs in con-

texts without standard input or output, enabling pro-

grams that require a display to run in a headless en-

vironment (no standard input and standard output),

such as an automated build server. Known as the

ADORe CLI, this build system leverages GNU Make

non-conventionally as a command runner and oper-

ates within a containerized Docker context, support-

ADORe: Uniﬁed Modular Framework for Vehicle and Infrastructure-Based System Level Automation

573

ing both x86 and ARM64 architectures. The ADORe

CLI uses Docker ”volumes” to link the host ﬁlesys-

tem to the ADORe source code directory, allow-

ing system requirements and dependencies to be dy-

namically added by individual components, modules,

or nodes. Additionally, it integrates ccache, a tool

that caches C++ compilations to reduce repeat com-

pile times, enhancing development efﬁciency. The

ADORe CLI comes preinstalled with ROS 2 Jazzy

and Ubuntu 24.04, both of which are conﬁgurable,

along with a collection of common ROS development

tools, network debugging tools, and other command-

line tools. This system supports not only a standard-

ized development environment but also facilitates au-

tomation for automated building and testing.

3.3 Simulation & Visualization

3.3.1 Visualization

ADORe allows visualizing with all common ROS2

visualization tools like RViz (RVi, 2024), Foxglove

(Fox, 2024), and Lichtblick (lic, 2024).

This is done via a visualization node which is re-

sponsible for subscribing to all relevant messages and

converting them to visualizable messages (primarily

Marker Arrays). Including:

• Ego vehicle

• Other detected trafﬁc participants

• Road/lane boundaries

• Planned trajectories

• Goal point

• Route to goal

• Satellite image of the map area

• Driven path

Figure 4: Example of ADORe visualization in Lichtblick.

3.3.2 Simulation

For testing in simple cases, ADORe provides a ROS2

node for simulating a vehicle with a simple vehicle

model which utilizes tire forces based on a simpliﬁed

dynamic bicycle model involving front and rear tire

stiffness, considers the effects of yaw rate, lateral ve-

locity, and steering angle, accounts for rotational iner-

tia and lateral tire forces through friction and stiffness

parameters, implements a simpliﬁed dynamic force

balance to compute lateral acceleration and yaw rate

changes (Rajamani, 2011). Many instances of the

Simulated Vehicle node can be spawned to test multi-

vehicle systems. The Simulated Vehicle node also

has several additional features, such as manual driv-

ing through a teleoperations panel, the ability to tog-

gle between manual and autonomous driving, and op-

tional generated/synthetic input noise.

3.3.3 CARLA Simulator Interface

The CARLA Simulator (Dosovitskiy et al., 2017) is

a popular open-source simulation tool for automated

driving with a realistic graphical output. ADORe

has an interface to CARLA extending its applicabil-

ity in research. For example, the interface facilitates

the simulation and testing of the ADORe vehicle au-

tomation using the precise vehicle models provided

by CARLA and it supports the execution of complex

driving scenarios. Additionally, the interface enables

the evaluation of perception models by leveraging

CARLA’s realistic graphical environment in conjunc-

tion with the ADORe automation framework. The in-

terface ensures bidirectional data exchange by con-

verting information into the appropriate formats for

both simulators. The CARLA Simulator is provided

in a containerized way by the CARLA team allowing

a straightforward deployment and execution together

with the ADORe framework.

3.3.4 SUMO Interface

The SUMO (Simulation of Urban Mobility) (Al-

varez Lopez et al., 2024) tool is a widely used open-

source microscopic trafﬁc simulation tool. It is ca-

pable of supporting the simulation and analysis of

intermodal trafﬁc ﬂows within the context of large-

scale networks. ADORe provides an interface to

SUMO. This enables the utilization of SUMO for the

lightweight simulation of vehicles and trafﬁc ﬂows

in the vicinity of a vehicle that is simulated with

ADORe. Furthermore, it permits the operation of an

automated vehicle within a SUMO simulation via the

ADORe automation. This allows for the easy assess-

ment of the impact of an automated vehicle operated

VEHITS 2025 - 11th International Conference on Vehicle Technology and Intelligent Transport Systems

574

by ADORe on the surrounding trafﬁc ﬂow. To achieve

the aforementioned functionality, the ADORe SUMO

bridge synchronizes both the ADORe and SUMO

simulations and transfers the information of all sta-

tuses of the trafﬁc participants in the simulations. The

data exchange is based on libsumo, which is the C++

interface of SUMO. The direction of data transfer

for each participant is determined based on whether

a given trafﬁc participant is simulated in SUMO or

ADORe. In each time step, the vehicle status is trans-

ferred and translated.

3.4 Hardware & Sensors

3.4.1 Research Vehicles

ADORe is deployed to all three of DLR’s research

vehicles seen in Fig. 1. There is the NGC-FASCar,

a Mercedes EQV equipped with an acceleration and

steering interface solution developed by Paravan.

Then there is also the FASCarE, a Volkswagen eGolf,

and the ViewCar2, a Volkswagen Passat GTE. Both

cars are controlled using enhanced CAN-bus inter-

faces. ADORe’s trajectory tracker sends commands

to a vendor-speciﬁc low-level interface to control the

actual vehicle. While the vendor-speciﬁc interface

part cannot be open-sourced, the trajectory tracker’s

output is simple enough to be adopted for any kind

of vehicle interface. All DLR’s research vehicles are

outﬁtted with LIDARs and cameras as well as GNNS

and a high-precision IMU. The research vehicles have

a DLR-internal sensor perception and fusion solution

which is also based on ROS, so the interface with

ADORe is based on ROS2 messages to provide ve-

hicle state information and surrounding object data.

Thus the interface is generic and modular and can be

adapted to a wide range of automation capable vehi-

cles.

3.5 Single-Agent Automated Driving

The ADORe SAAD is responsible for calculating

routes, trajectories, decisions, V2X, and the actual

vehicle command to drive the vehicle to fulﬁll its

goals. Fig. 5 shows the different ROS2 nodes and

topics communicating with each other and gives an

overview of the ﬂow of execution. ADORe SAAD

receives through its interfaces the current ego vehi-

cle state, other trafﬁc participants, and a variety of

V2X topics. Using these topics, ADORe SAAD ﬁrst

sends the necessary information to the mission con-

troller, which handles everything related to naviga-

tion. Afterwards, the decision maker is used to deter-

mine which planner is to be used. Different planners

exist for different purposes, which generate appropri-

ate trajectories, see below for details. The planned

trajectories can also be published using V2X. Lastly,

ADORe SAAD uses the trajectory tracker to calculate

low-level vehicle commands.

Figure 5: The ADORe SAAD nodes and topics overview,

yellow boxes being ROS2 topics & messages, and blue

boxes are nodes.

3.5.1 Mission Controller

The Mission Controller is responsible for the vehi-

cle’s high-level navigation, this includes map loading,

keeping track of goals, and route planning. The Mis-

sion Controller keeps track of a queue of goals. This

enables, for example, multiple pick up and drop-offs

at different locations. When many destinations should

be reached, many successive routes can be planned.

Two formats of HD maps are supported.

Road2Simulation maps and OpenDRIVE maps.

When the high deﬁnition (HD) map is loaded from

a ﬁle, a lane graph weighted by the lengths of the

lanes is created and Dijkstra is used to ﬁnd the short-

est path to the goal along the drivable lanes. The Mis-

sion Controller keeps track of the progress along this

route and adjusts accordingly, recalculating when the

vehicle deviates too far from it.

A local cut-out of the larger map, the route, and

the goal are sent onward to other parts of the automa-

tion.

ADORe: Uniﬁed Modular Framework for Vehicle and Infrastructure-Based System Level Automation

575

3.5.2 Decision Maker & Trajectory Planner

The Decision Maker is the core component of

ADORe SAAD, responsible for managing the high-

level decision-making required for seamless and safe

automated vehicle operation. It operates through a hi-

erarchical state machine that dynamically determines

the type of trajectory and action executed by ADORe

SAAD. At its highest level of abstraction, the De-

cision Maker can transition between currently seven

prioritized states:

• Emergency Stop: Halts the vehicle as quickly as

possible.

• Minimum Risk Maneuver: Strategically brings

the vehicle to a stationary position safely.

• Requesting Assistance: Signals for human inter-

vention when the vehicle encounters a situation

requiring external input (see Sec. 4.1.1).

• Remote Operations: Allows human operators

to guide the vehicle remotely during challenging

scenarios. (see Sec. 4.1.1).

• Safety Corridor: Engages when a safety corridor

message is received, such as one issued by emer-

gency vehicles, instructing the vehicle to clear a

path (see Sec. 4.1.2).

• Standstill: State for stopping or remaining sta-

tionary.

• Follow Route: Creates a trajectory following the

lane center of a route provided by the mission con-

troller.

• Follow Reference: Follows a reference trajec-

tory provided from elsewhere, typically ADORe

MAAD.

The transition into and behavior within each state

depends on the data received through the topics and

interfaces described in Sec. 3.5. For instance, if local-

ization is lost, the Emergency stop state is triggered.

Alternatively, when a reference trajectory is available,

the Follow reference state is prioritized to ensure op-

timal trajectory execution.

The Decision Maker and Trajectory Planner work

in tandem to enable seamless transitions between lo-

cal automation, infrastructure-assisted driving, and

remote operations.

The Decision Maker determines the vehicle’s cur-

rent operational state and generates the appropriate

reference inputs for the Trajectory Planner. Depend-

ing on the state, the reference can take different forms:

a reference path to the goal, safety corridor lanes, or a

multi-agent-based reference trajectory from MAAD.

For example, when providing a reference path to the

goal, the Decision Maker also computes a reference

velocity using the Intelligent Driver Model (IDM)

(Malinauskas, 2014), ensuring safe minimum dis-

tance and time headway from other vehicles. These

references are then passed to the Trajectory Planner.

The Trajectory Planner uses these inputs, along

with additional information such as vehicle dynamics

and constraints, to generate a feasible and safe tra-

jectory. It employs a nonlinear constraints optimizer,

named OptiNLC (Opt, 2024), an OSQP-based opti-

mization solver (Stellato et al., 2020) library devel-

oped by DLR, to solve the optimal control problem.

The optimization cost function is designed to ensure

the vehicle follows the center of the lane smoothly

while adhering to kinematic and dynamic constraints.

It prioritizes passenger comfort by minimizing lateral

deviation, aligning the vehicle’s heading with the ref-

erence path, and promoting smooth, efﬁcient motion.

By optimizing control inputs at each point within

the planning horizon, the algorithm iteratively solves

for the trajectory that satisﬁes convergence criteria.

While the current implementation focuses on longi-

tudinal motion planning guided by IDM, future de-

velopments aim to include more sophisticated lateral

planning and lane-changing capabilities, further en-

hancing the system’s robustness and adaptability.

3.5.3 Trajectory Tracker

To ensure that the automated vehicle follows the

planned trajectory, we have developed multiple con-

trollers to provide ﬂexibility. These include a PID

controller, a Model Predictive Controller (MPC), and

an iterative Linear Quadratic Regulator (iLQR).

The PID controller computes control commands

by penalizing errors in position, velocity, and head-

ing relative to a point on the reference trajectory, with

separate PID gains for each error type. Anti-windup

mechanisms prevent integral terms from growing un-

controllably, while additional terms for comfort con-

straints (e.g., limits on steering velocity and accelera-

tion jerk) ensure smooth transitions.

The Model Predictive Controller improves upon

this by considering not just a single reference point on

the planned trajectory but a prediction horizon. This

also uses OptiNLC, the same OSQP-based optimiza-

tion solver library as is used in trajectory planning.

This approach results in smoother and more comfort-

able control outputs. The MPC’s cost function incor-

porates various factors to optimize trajectory track-

ing, including minimizing lateral deviation, penaliz-

ing steering angle velocity, and reducing longitudinal

jerk.

The iLQR controller also works in an MPC-like

way. At each time step, it calculates a control se-

quence over a longer horizon while only executing

VEHITS 2025 - 11th International Conference on Vehicle Technology and Intelligent Transport Systems

576

the ﬁrst part. It operates by iteratively reﬁning an ini-

tial control sequence through forward and backward

passes, leveraging linear approximations of system

dynamics and quadratic approximations of the cost

function. In the forward pass, the algorithm simu-

lates the system’s response to the current control se-

quence using nonlinear dynamics, generating a state

trajectory. The backward pass linearizes the dynamics

around this trajectory and applies dynamic program-

ming to compute a time-varying feedback control law

that minimizes a local quadratic approximation of the

cost-to-go.

This implementation of iLQR incorporates a cost

function that penalizes deviations in longitudinal and

lateral position, velocity, and heading while adding

regularization terms for jerk and steering rate to en-

sure smooth and feasible motion. The dynamics

are represented using discretized linearized matrices,

which model how states and controls inﬂuence the

system over time. Cost derivatives are computed to

approximate the sensitivity of the cost function, en-

abling precise control updates. A line search mech-

anism ensures stability by scaling control updates

while warm-starting from previously computed tra-

jectories accelerates convergence.

3.6 Multi-Agent Autonomous Driving

ADORe MAAD is designed for working on infras-

tructure or surrounding hardware that remotely com-

municates with ADORe SAAD on one or multiple ve-

hicles. The idea of communication with infrastructure

for planning for multiple CAVs gains multiple advan-

tages. First, each vehicle gains access to information

not achievable by a single vehicle like in the scenario

seen in Fig. 6. In Fig. 6 the DLR CAV is driving along

a road, and due to the viewing angle the car is unable

to see the person running toward the CAV’s driving

direction. However, the person is within the view-

ing angle of the infrastructure on the trafﬁc light, and

through communication the CAV can gain an under-

standing of trafﬁc that not even humans can achieve.

Secondly, since ADORe MAAD is designed for

planning multiple CAVs’ trajectories simultaneously,

it can optimize goals that involve many agents, for

example, to improve trafﬁc and eliminate phantom

queues.

Due to the nature of controlling multiple vehicles,

the structure of ADORe MAAD is simpliﬁed by re-

moving the trajectory controller, to avoid assumptions

of the individual vehicles and their hardware. The

ADORe MAAD nodes and topics, when controlling

groups of vehicles, can be seen in Fig. 7.

The ADORe interfaces are responsible for provid-

Figure 6: Example of the advantages when combining in-

frastructure and local autonomous driving, the CAV is driv-

ing along a road, and unable to see the person running to-

wards it, as they are hidden behind another vehicle.

Figure 7: ADORe MAAD ROS2 nodes and topics

overview.

ing ADORe MAAD with a list of trafﬁc participants,

the HD map, and a list of the trafﬁc participants the

framework can control. The respective controllabil-

ity is deﬁned through received V2X messages, which

contain state, capability and goal point information

(see (Schindler et al., 2024)) to be sent to the view

node. A map provider node is responsible for creat-

ing a local map for the view component. This com-

ponent, described in Sec. 3.6.1 generates a view mes-

sage, containing information on each vehicle’s driv-

ing options and where they are heading. The view

message is then sent to the trafﬁc predictor, which as

ADORe: Uniﬁed Modular Framework for Vehicle and Infrastructure-Based System Level Automation

577

described in Sec. 3.6.2, will generate trajectories for

all trafﬁc participants. Lastly, the MAAD decision

maker, which is intended to be used for creating im-

provement to the trajectories in the future, but right

now only has the functionality of ﬁltering out the traf-

ﬁc participants not relevant for the vehicles driving

using ADORe SAAD.

3.6.1 View

The purpose of the View module is to provide a lo-

calized representation of the HD map at the agent

level, removing unnecessary structures and informa-

tion while delivering the lane features essential for

downstream planning tasks. The function of the View

module can be understood by considering the type of

information a multi-agent trajectory planner requires

to plan the ego vehicle’s trajectory and predict the tra-

jectories of other trafﬁc participants. This required

information includes:

• The state of each trafﬁc participant, including the

ego vehicle. This comprises position, orientation,

yaw rate, speed, acceleration, dimensions, and ID.

• A description of the center lane (with any poten-

tial forks) as well as the left and right lanes, if

present, for each trafﬁc participant in the scenario.

The role of the View module is to associate each

trafﬁc participant with its respective lane and incorpo-

rate this information into the published View topic.

The view message consists of a vector of vehi-

cle items. Each vehicle item contains the state of

the vehicle and vectors for its center lanes (plural, to

account for forks), left lanes, and right lanes. Each

lane item further includes the points deﬁning its cen-

ter line.

3.6.2 Trajectory Predictor

Planning in a multi-agent environment like trafﬁc re-

quires predicting the trajectories of other trafﬁc par-

ticipants. This must be done simultaneously with

planning, as the trajectory of the ego vehicle affects

and is affected by the trajectories of other trafﬁc par-

ticipants.

There are two ways in which this is done. Firstly,

a primitive forces-based approach where each agent

is pulled toward making progress on the lane centers

while being repulsed by other agents. This method

beneﬁts from being fast to compute while suffering

from a lack of optimality. A second, more com-

plex approach involves modeling the trafﬁc scenario

as a dynamic game and computing its Generalized

Nash Equilibrium (GNE) (Lucente et al., 2024). The

GNE represents a strategy combination in which each

player of the game adopts their best strategy, assum-

ing that the strategies of the other players remain un-

changed. In this context, each vehicle is modeled as

a player, and its objective is to choose the optimal

strategy (trajectory) that minimizes its cost while re-

specting collision constraints. To compute the GNE,

the constrained optimization problems are reformu-

lated as unconstrained optimization problems using

the augmented Lagrangian method. These uncon-

strained problems are then solved using the Trust Re-

gion method (Lucente et al., 2024).

While the Trust Region method ensures local conver-

gence, it cannot guarantee global convergence. Con-

sequently, there is no assurance that the equilibrium

found constitutes a true Nash equilibrium. For this

reason, the solver’s performance is sensitive to the ini-

tial solution. If the initial guess is sufﬁciently close to

the GNE, it is reasonable to assume that the solution

will converge to the global minimum and, thereby, to

the GNE.

3.6.3 Middleware Service

ADORe is used in very varying projects that impose

different requirements in terms of back-end connec-

tivity. The requirements usually revolve around ob-

taining mission goals or propagating the vehicle sta-

tus. To avoid project-speciﬁc implementation details

within the ADORe core, we implemented a simple

middleware service. This backend service is respon-

sible for interfacing with the different project-speciﬁc

backends while keeping the API for the ADORe side

stable. Only a small portion of project-speciﬁc glue

code in the form of a Python ROS2 node is needed,

while the middleware service handles complex hand-

shakes and any other kind of server communication.

4 EXPERIMENTS

ADORe has successfully been tested in multiple re-

search projects. Also, several demonstrations have

been conducted in different use cases, performed in

different cities and under multiple environmental con-

ditions.

4.1 Passenger Transport

In the German national research project Gaia-

X4ROMS, which deals with the support and remote

operation of automated and networked mobility ser-

vices, the NGC-FASCar has demonstrated a pro-

totypic implementation of a shuttle service (Rom,

2024). It was bookable through a mobile app to

VEHITS 2025 - 11th International Conference on Vehicle Technology and Intelligent Transport Systems

578

pickup individual passengers at speciﬁc bus stops.

The CAV drove around the perimeter along the green

path shown in Fig. 8. During the drives, it had to

interact with a mobile trafﬁc light sending out V2X

messages.

Figure 8: Gaia-X4ROMS driving demo area, showing the

two different pick-up and drop-off locations and a trafﬁc

light.

A video of the vehicle driving the

route observed in Fig. 8 can be seen in:

https://github.com/DLR-TS/adore_videos/

blob/main/links.md#hamburg-driving-demo.

4.1.1 Remote Operations

A main use case that has been worked on at DLR is

remote operations, where a remote operator is taking

over control of CAVs running ADORe SAAD, in sit-

uations where the CAV is unable to make decisions

itself. The focus is primarily on remote assistance

while remote driving plays a minor role. Detailed in-

formation regarding the related project scope is pro-

vided at (Rem, 2024). An example scenario where

remote operations could be beneﬁcial can be seen in

Fig. 9, where the CAV is driving along a given route,

that is blocked by temporal road construction. How-

ever, due to the solid line road marking, the CAV is

not allowed to cross the line to pass the obstacle, even

though there is no other way to get around. The ve-

hicle simply may not be allowed to perform this ac-

tion due to its restricted Operational Design Domain

(ODD).

During the scenario, the CAV is approaching the

obstacle while continuously monitoring its Operating

Domain in conjunction with the deﬁned ODD. In case

there is a mismatch, the CAV is triggering a Mini-

mum Risk Maneuver (MRM) while at the same time

it is requesting remote assistance as explained in Sec.

3.5.2. The MRM consists of a smooth braking maneu-

ver accompanied by hazard lights. Contacting of the

remote operator is currently achieved by pushing re-

lated state information via MQTT wirelessly through

Figure 9: Example of a situation an CAV can encounter,

where human intervention could be required.

the nearby infrastructure or by using mobile commu-

nication. The CAV and remote operator then begin

the negotiation depicted in Fig. 10.

Figure 10: The communication between the AV running

ADORe SAAD and the remote operator to escape a situ-

ation.

After ﬁrst sending a request for remote assistance

the CAV will continuously throughout the negotiation

transmit odometry at 1 Hz. The remote operator, upon

receiving the request and odometry will then see a vi-

sualization of the CAV in their visualization tool seen

in Fig. 11. From the visualization tool, the remote op-

erator can then enter a set of waypoints that they want

the CAV to drive, as seen in Fig. 11.A, which is then

sent to the CAV.

After the CAV receives the waypoints, it will

calculate a trajectory locally using its own planner as

described in Sec. 3.5.2, and return it to the remote

ADORe: Uniﬁed Modular Framework for Vehicle and Infrastructure-Based System Level Automation

579

Figure 11: A. The remote operator’s visualization of the

AV running ADORe SAAD with placed waypoints. B. The

remote operator’s visualization of the received trajectory.

operator for ﬁnal approval. When the remote operator

receives the trajectory, it will be visualized as shown

in Fig. 11.B, and the remote operator can then decide

to either approve or reject. If the remote operator re-

jects the trajectory, the CAV will generate a new one

for approval. If the trajectory is accepted, the CAV

will begin driving the trajectory until it reaches the

end, where it switches back to automated driving and

stops contact with the remote operator. A video of

the car driving the remote operations example shown

in Fig. 11 can be seen here: https://github.com/

DLR-TS/adore_videos/blob/main/links.md#

remote-operation-demo-braunschweig.

4.1.2 Safety Corridor

Part of the German national project Gaia-X4AMS

(Advanced Mobility Services) was about leveraging

vehicle automation to create safety corridors during

emergencies (Ams, 2024). In this scenario, the au-

tomated vehicle detects an emergency through V2X

communication, receiving detailed information about

the safety corridor. This information includes a

polygonal area representing the path an emergency

vehicle will take. Upon receiving this data, the au-

tomated vehicle promptly calculates and executes an

evasive trajectory to vacate the polygon area. By do-

ing so, it helps forming an emergency lane, ensuring a

clear path for the emergency vehicle to pass through.

4.2 Collaborative Automated Driving

The collaborative relationship outlined in this pa-

per between ADORe SAAD and ADORe MAAD

has been developed as part of the German national

research project MAD-Urban (Managed Automated

Driving) (Mad, 2024). Throughout this project, pro-

tocols and the related system architecture for ”Man-

Figure 12: Ego Vehicle (white) leaving the safety corridor

to form emergency lane for emergency vehicle (red) to pass

by.

aged Automated Driving” have been developed and

implemented in research vehicles and local infras-

tructure components of DLR and project partners

(Schindler et al., 2024). First tests successfully estab-

lished the link between SAAD and MAAD, so that

infrastructure-based trajectories have been followed

by CAVs. The work is continued to bring the tech-

nology to public roads.

5 CONCLUSION

This paper introduces ADORe, German Aerospace

Center’s research framework for system-level auto-

mated driving of single CAVs controlled in-vehicle,

and multiple CAVs controlled by surrounding infras-

tructure, achieving both automated driving and coop-

erative automated driving. ADORe is ROS2-based

and comes packaged with its own integrated build

system and developer environment. The software

framework is divided into three stacks. First, the

ADORe interfaces, tailored to speciﬁc hardware or

software, are the only modules that would need mod-

iﬁcation to adapt to new vehicles or software. Sec-

ondly, the ADORe single-agent autonomous driving

stack, designed for use inside of a single vehicle,

which based on its conditions and available data can

make decisions on how to drive, plan, and execute tra-

jectories independently. Thirdly, the ADORe multi-

agent automated driving is intended to run on infras-

tructure, and will generate trajectories for all CAVs in

the local area, allowing for trafﬁc optimizations not

possible by a single vehicle. ADORe has been suc-

cessfully used and demonstrated in several research

projects. While being further developed in recently

VEHITS 2025 - 11th International Conference on Vehicle Technology and Intelligent Transport Systems

580

started and upcoming research projects, it is open-

source and available on Github: https://github.

com/DLR-TS/adore.

REFERENCES

(2023). Home Page - Autoware. [Online; accessed 10. Dec.

2024].

(2024). AMS. [Online; accessed 17. Dec. 2024].

(2024). Apollo. [Online; accessed 10. Dec. 2024].

(2024). Docker: Accelerated Container Application Devel-

opment. [Online; accessed 19. Dec. 2024].

(2024). Foxglove - Visualization and observability for

robotics developers. [Online; accessed 20. Dec. 2024].

(2024a). J3016 202104: Taxonomy and Deﬁnitions for

Terms Related to Driving Automation Systems for

On-Road Motor Vehicles - SAE International. [On-

line; accessed 13. Dec. 2024].

(2024b). J3216 202107: Taxonomy and Deﬁnitions for

Terms Related to Cooperative Driving Automation for

On-Road Motor Vehicles - SAE International. [On-

line; accessed 13. Dec. 2024].

(2024). lichtblick. [Online; accessed 10. Dec. 2024].

(2024). MAD Urban. [Online; accessed 17. Dec. 2024].

(2024). OptiNLC. [Online; accessed 20. Dec. 2024].

(2024). Remote Operation: An important building block

from Braunschweig for the mobility of the future.

[Online; accessed 17. Dec. 2024].

(2024). ROMS Abschlussevent. [Online; accessed 17. Dec.

2024].

(2024). rviz. [Online; accessed 20. Dec. 2024].

Althoff, M., Koschi, M., and Manzinger, S. (2017). Com-

monroad: Composable benchmarks for motion plan-

ning on roads. In 2017 IEEE Intelligent Vehicles Sym-

posium (IV), pages 719–726. IEEE.

Alvarez Lopez, P., Banse, A., Barthauer, M., Behrisch, M.,

Cou

eraud, B., Erdmann, J., Fl

otter

od, Y.-P., Hilbrich,

R., Nippold, R., and Wagner, P. (2024). Simulation of

urban mobility (sumo).

Behrisch, M., Bieker, L., Erdmann, J., and Krajzewicz, D.

(2011). Sumo - simulation of urban mobility: An

overview. In of Oslo Aida Omerovic, S. . U., Simoni,

R. I. R. T. P. D. A., and Bobashev, R. I. R. T. P. G.,

editors, SIMUL 2011, The Third International Confer-

ence on Advances in System Simulation, pages 63–68,

Barcelona, Spain. ThinkMind.

Dosovitskiy, A., Ros, G., Codevilla, F., Lopez, A., and

Koltun, V. (2017). CARLA: An open urban driving

simulator. In Proceedings of the 1st Annual Confer-

ence on Robot Learning, pages 1–16.

Li, Y., Yuan, W., Zhang, S., Yan, W., Shen, Q., Wang,

C., and Yang, M. (2023). Choose Your Simulator

Wisely: A Review on Open-source Simulators for Au-

tonomous Driving. arXiv.

Lucente, G., Maarssoe, M. S., Konthala, S. H., Abulehia,

A., Dariani, R., and Schindler, J. (2024). Deepgame-

tp: Integrating dynamic game theory and deep learn-

ing for trajectory planning. IEEE Open Journal of In-

telligent Transportation Systems, pages 1–1.

ucken, L., Schwamborn, M., Mintsis, E., Koutras,

D., Karagounis, V., Correa, A., Sepulcre, M.,

Coll Perales, B., Thandavarayan, G., Blokpoel, R.,

Zhang, X., Huisken, G., Boerma, S., Maerivoet,

S., Carlier, K., P

apics, P., Ons, B., Tourw

e, S.,

Banse Bueno, O. A., and Schindler, J. (2021). Tran-

sAID Deliverable 6.2/2 - Assessment of Trafﬁc Man-

agement Procedures in Transition Areas. [Online; ac-

cessed 11. Dec. 2024].

Malinauskas, R. (2014). The intelligent driver model: Anal-

ysis and application to adaptive cruise control.

Rajamani, R. (2011). Vehicle dynamics and control.

Springer Science & Business Media.

Schindler, J., Dariani, R., Klein, P., Lee, A., and Fleck,

T. (2024). Automated Vehicles Controlled By Smart

Infrastructure – The Architecture Of Managed Auto-

mated Driving. In ERTICO, editor, 2024 ITS World

Congress Paper Publications Part 2, pages 1210–

1220, Dubai, VAE. ERTICO.

Schindler, J., Klein, P., Fleck, T., and Lee, A. (2023).

Managed Automated Driving (MAD) - a Concept for

Empowering Road Infrastructure. In ERTICO, edi-

tor, 2023 ITS European Congress Book of Abstracts,

pages 933–944, Lisbon, Portugal. ERTICO.

Stellato, B., Banjac, G., Goulart, P., Bemporad, A., and

Boyd, S. (2020). Osqp: an operator splitting solver

for quadratic programs. Mathematical Programming

Computation, 12(4):637–672.

Tang, S., Zhang, Z., Zhang, Y., Zhou, J., Guo, Y., Liu,

S., Guo, S., Li, Y.-F., Ma, L., Xue, Y., and Liu, Y.

(2023). A Survey on Automated Driving System Test-

ing: Landscapes and Trends. ACM Trans. Software

Eng. Method., 32(5):1–62.

Testouri, M., Elghazaly, G., and Frank, R. (2024). Robo-

Car: A Rapidly Deployable Open-Source Platform for

Autonomous Driving Research. arXiv.

Tong, K., Ajanovic, Z., and Stettinger, G. (2020). Overview

of Tools Supporting Planning for Automated Driving.

arXiv.

Xu, R., Guo, Y., Han, X., Xia, X., Xiang, H., and Ma,

J. (2021). Opencda: an open cooperative driving

automation framework integrated with co-simulation.

In 2021 IEEE International Intelligent Transportation

Systems Conference (ITSC), pages 1155–1162. IEEE.

ADORe: Uniﬁed Modular Framework for Vehicle and Infrastructure-Based System Level Automation

581