The SDV Revolution: Why is it so important?
Nowadays, hardly any conversation among automotive experts goes by without the term software-defined vehicle (SDV) being mentioned. Software has become a central component of modern automotive development. Today, software is no longer just a part of the car; it defines the car and determines its functions and characteristics – from engine control to infotainment and driver assistance systems.
Today more than ever, consumers expect their cars to evolve through updates that improve battery performance, make parking easier, and optimize autonomous driving. They are not interested in AUTOSAR, DDS, or Automotive Android. What counts is the driving experience. Manufacturers need to take these expectations into account to be among the winners of this trend in automotive development.
The Role of Middleware in ADAS/AD HPC Architectures
The architectures for classic edge ECUs and zonal gateways have largely been clarified. However, there is an unresolved challenge concerning high-performance computers (HPC), which have been developed in modern vehicle architectures as central computing units specifically for ADAS/AD. As the "brain" of the vehicle, HPCs perform computationally intensive tasks such as sensor fusion, AI algorithms, and decision logic. Their task here is to process multi-gigabit data streams generated by cameras, lidar, radar, IMU, and GNSS – often asynchronously, irregularly, and abruptly. This is precisely where middleware comes into play, as its role is to ensure that data is processed between edge ECUs, gateways, and HPCs in zonal architectures with minimal latency and high reliability.
What to look out for in HPC middleware?
OEMs and Tier 1 suppliers require a middleware layer that must fulfill several conditions:
- Deterministic timing for high-bandwidth sensor ingestion
Safety-critical applications require safety. Perception algorithms rely on synchronized data from asynchronous sensors such as lidar, cameras, and radar. - Interoperability with industry standards
Middleware must be able to work seamlessly and without friction with AUTOSAR, DDS, CAN FD, and Ethernet. - Low-code development with visual workflows
Because speed is critical, developers need plug-and-play sensor interfaces and graphical tools to focus on differentiation – not standard code. - Integration of ROS 2
The open-source tool ROS 2, the second-generation Robot Operating System, is widely used for prototype development. Therefore, middleware should ideally enable the integration of ROS 2.
The Solution: RTMaps – Built for Speed and Interoperability
RTMaps (Real-Time Multisensor applications) was specially developed for the development of high-bandwidth multisensor software.
Main Functions:
- Deterministic real-time sensor data processing
Synchronization of multi-gigabit data streams in minutes – instead of hours. - Interoperability with AUTOSAR Adaptive, DDS, SOME/IP, Ethernet, CAN FD, ROS/ROS 2
Developed from the ground up to meet automotive standards. - Low-code GUI: visual compilation of data flows; expandability in C++ or Python
Provide more, program less. Native support for major sensor manufacturers such as Velodyne, Hesai, and Sony. In addition, RTMaps is software- and hardware-independent and supports both x86- and ARM-based devices.
Figure 3: The graphical user interface of RTMaps allows synchronized real-time recording with minimal configuration effort for a wide variety of components – from cameras, GPS, lidar, radar, and IMU to CAN/Ethernet buses and many more.
Your Next Step
If you are building on an autonomous HPC system and need a deterministic, interoperable, and developer-friendly middleware, try RTMaps today. Start a pipeline with your sensors and see how quickly you can get synchronized, testable results.
Download the RTMaps trial and accelerate your SDV development:
