Modular Design Is Solving Autonomous Driving's Biggest Challenges

:::info Authors:

(1) Tobias Betz, Technical University of Munich, Germany;

(2) Long Wen, Technical University of Munich, Germany;

(3) Fengjunjie Pan, Technical University of Munich, Germany;

(4) Gemb Kaljavesi, Technical University of Munich, Germany;

(5) Alexander Zuepke, Technical University of Munich, Germany;

(6) Andrea Bastoni, Technical University of Munich, Germany;

(7) Marco Caccamo, Technical University of Munich, Germany;

(8) Alois Knoll, Technical University of Munich, Germany;

(9) Johannes Betz, Technical University of Munich, Germany.

:::

Table of Links

Abstract and I. Introduction

II. Related Work

III. Microservice Architecture for an Autonomous Driving Software

IV. Experiments

V. Results

VI. Discussion

VII. Conclusion, Acknowledgments, and References

\

III. MICROSERVICE ARCHITECTURE FOR AN AUTONOMOUS DRIVING SOFTWARE

Following the paradigms of software-definedness, the microservice architecture for autonomous driving software is designed to enhance the modularity of the software, enabling

\

\ efficient development and corresponding software deployment. The core of our architecture is a base image that forms the basic building block for the individual module containers. Specialized containers implementing dedicated functionalities are derived from the base image. The base image can also be used for development as it has the requirements for building the complete code. The base image includes essential installations such as ROS 2 and optional libraries like cuda, cuDNN, and TensorRT, which are not necessarily required by every specialized module. The advantages of using a single base image are manifolds. The configuration and installation of all packages can be centralized using a multi-step process that relies on, e.g., Ansible roles, rosdep installation, and manual configuration. This also simplifies the management of cross-package dependencies, facilitates freezing packages to specific versions, and avoids introducing incompatibilities between (updated) packages and our code.[1] Once configured, the base image rarely needs to be rebuilt. Fig. 2 depicts the build and deployment process of the microservice architecture. We divided the Autoware software into eight dedicated containers based on the functional modules in the software. The containers are sensing, perception, localization, map, planning, control, vehicle, and system. Each container consists of multiple ROS 2 nodes, as shown in Table I. In our architecture, the entire ROS 2 launch structure of Autoware was restructured with the separation of individual modules. The centralized launch package, which listed all packages as dependencies, was split into individual launch packages for each module (with only

\

\ the needed dependencies). As a result, each module can be built and launched individually. The former central launch package included all launch parameters. In contrast, in our architecture, a separate package was created to contain these launch parameters, which are accessible by the module launch files. Additionally, we integrated the launch parameters to be located outside the containers and mounted during the startup of the respective containers. This approach provides the advantage that changes affecting several module containers, such as the vehicle model, only need to be modified in one location, ensuring consistent parameters for all modules. We developed a continuous integration (CI) pipeline for building custom module containers that ensures compatibility with both x86 and aarch64 architectures by using cloud-native hardware resources. The CI pipeline consists of several stages that enable both the creation of the entire software and the targeted creation of individual modules. This approach offers efficiency advantages, eliminating the need to rebuild all containers for each code change. Additionally, it facilitates selective updates and maintenance via a CI pipeline-based multi-stage testing process. Initially, unit tests are conducted, followed by modular tests in which several functions and their interactions are assessed. Due to the modular container structure, a test does not have to be executed repeatedly, but only within the respective container module. We utilize the CI cloud infrastructure to store our built containers in the container registry. The built containers can be seamlessly deployed on both simulation infrastructure and actual vehicles, offering a flexible deployment strategy. Compared to a monolithic architecture, our microservice architecture improves the development and deployment of the software. During development, the software developer only needs to handle the dependencies related to the respective functionality. The building of the software is automatized in the cloud, and the deployment is simplified. This development and deployment workflow of the microservice architecture is successfully used in real vehicle projects [7], [26].

\

:::info This paper is available on arxiv under CC by 4.0 Deed (Attribution 4.0 International) license.

:::

[1] Managing dependencies in ROS 2 is particularly complex and manual optimization, as well as package updates, quickly become a daunting task.