Modern Middlewares for Automated Vehicles: A Tutorial

TL;DR

The paper surveys modern automotive middlewares by separating communication middlewares from architecture platforms and analyzing five representative systems (SOME/IP, FastDDS, Zenoh, ROS 2, and AUTOSAR Adaptive Platform). It argues that DDS-based solutions are the most feature-rich and mature, while ROS 2 excels for development and AUTOSAR AP supports deployment-ready capabilities; Zenoh demonstrates competitive performance in wireless and high-data-rate contexts. The discussion highlights near-future E/E architectures (zone-based) and the role of middleware in enabling scalable, updateable software in automated vehicles, while identifying open research challenges in real-time guarantees, security, resource orchestration, and ML integration. The findings aim to guide manufacturers and researchers in selecting middleware strategies and in prioritizing research for reliable, secure, and adaptable automotive software systems. The work underscores that deterministic real-time behavior and robust safety/security remain central unresolved issues as vehicle software ecosystems grow in complexity and capability.

Abstract

This paper offers a tutorial on current middlewares in automated vehicles. Our aim is to provide the reader with an overview of current middlewares and to identify open challenges in this field. We start by explaining the fundamentals of software architecture in distributed systems and the distinguishing requirements of Automated Vehicles. We then distinguish between communication middlewares and architecture platforms and highlight their key principles and differences. Next, we present five state-of-the-art middlewares as well as their capabilities and functions. We explore how these middlewares could be applied in the design of future vehicle software and their role in the automotive domain. Finally, we compare the five middlewares presented and discuss open research challenges.

Figures (14)

• Figure 1: Illustration of a domain-based E/E architecture. Actuator controllers are depicted in black with gray representing a sensor. The components are connected within their own domain. The domains are determined by the function that the ECU contribute to, for example drive train control while cooperation between domains is limited wang_review_2024.
• Figure 2: Illustration of a zone-based E/E architecture. Actuator controllers are depicted in black with gray representing a sensor. Each component is connected to a zone control unit, which in turn is connected to a central vehicle computer VC1. This architecture divides the vehicle into four separate zones connected according to proximity with a high degree of cross-zone cooperation wang_review_2024.
• Figure 3: Illustration of the interaction of software and hardware in a domain-based E/E architecture. The automotive software system depicted is based on the requirements outlined in \ref{['sec:background:signal_oriented_example']}.
• Figure 4: Illustration of the different domains interacting with middlewares. Domains are positioned according to their topical closeness. Black signifies increased importance from the perspective of the authors.
• Figure 5: Illustration depicting the role of a middleware in the development of distributed software. The middleware functions as an intermediary between the application and the operating system. In this case AUTOSAR AP makes use of DDS and the operating systems network stack to communicate across the two devices.

Theorems & Definitions (13)

• Definition 2.1: E/E Architecture
• Definition 2.2: ECU
• Definition 2.3: Automotive Software System
• Definition 2.4: Domain-based E/E Architecture
• Definition 2.5: Software Architecture
• Definition 3.1: Middlewares
• Definition 3.2: Automotive Software Stack
• Definition 3.3: Automotive Middlewares
• Definition 3.4: Software Design Pattern
• Definition 3.5: Communication Middlewares