A Containerized Microservice Architecture for a ROS 2 Autonomous Driving Software: An End-to-End Latency Evaluation

TL;DR

This paper tackles end-to-end latency and resource utilization in a containerized ROS 2 Autoware autonomous driving software stack. It proposes a modular microservice architecture with eight ROS 2 containers built from a common base image and an accompanying CI pipeline, then evaluates three deployment modes (bare-metal, single-container, multi-container) on two hardware platforms (x86 and aarch64) using DDS and ROS 2 benchmarks plus a real-world Autoware application in AWSIM. Key findings show that containerization can reduce mean end-to-end latency by about 5–8% and lower maximum latencies, while also reducing CPU and memory usage, with results consistent across platforms though nuanced by workload. These insights inform practical deployment decisions for software-defined vehicles and provide an open-source testbed for future research on containerized autonomous driving pipelines.

Abstract

The automotive industry is transitioning from traditional ECU-based systems to software-defined vehicles. A central role of this revolution is played by containers, lightweight virtualization technologies that enable the flexible consolidation of complex software applications on a common hardware platform. Despite their widespread adoption, the impact of containerization on fundamental real-time metrics such as end-to-end latency, communication jitter, as well as memory and CPU utilization has remained virtually unexplored. This paper presents a microservice architecture for a real-world autonomous driving application where containers isolate each service. Our comprehensive evaluation shows the benefits in terms of end-to-end latency of such a solution even over standard bare-Linux deployments. Specifically, in the case of the presented microservice architecture, the mean end-to-end latency can be improved by 5-8 %. Also, the maximum latencies were significantly reduced using container deployment.

Figures (6)

• Figure 1: Considered software deployments: bare-metal (no containers), one container, isolation via dedicated containers.
• Figure 2: Schematic of the build and deployment process of the microservice architecture: After committing code changes to the Autoware repository on the CI server, the test procedure and docker image build steps are triggered. The built images are stored in the container registry and can be pulled from the cloud onto the host system. The corresponding module images are based on a base image that contains the necessary basic installations. This module image, in turn, also serves as a container for the development of features.
• Figure 3: The abstraction layers of a ROS 2 application executed in bare-metal (left) and in multiple containers (right). Using containerization, an additional layer is introduced. Each container consists of independent individual layers, but shares a common Linux kernel.
• Figure 4: End-to-end latency histograms (a) using the bare-metal setup, (b) using the single-container setup, and (c) using the multi-container setup (blue= x86, red= aarch64).
• Figure 5: CPU utilization of the systems for the different deployment variants.