The automotive industry is undergoing a profound transformation, driven by increasing demands for automation, connectivity and personalized experiences. This evolution is fundamentally reshaping the electrical and electronic (E/E) architecture of vehicles, moving away from distributed systems towards a more centralized compute model. With this transition comes new levels of complexity for in-vehicle software, which in turn require new approaches to design, development and deployment.

This blog post explores the concept of a data-centric communication framework and its critical role in enabling the creation of software-defined vehicles (SDVs). 

The Shift Toward Centralized E/E Architectures

For decades, automotive E/E architectures were characterized by numerous Electronic Control Units (ECUs), each dedicated to a specific function such as turn signals. Today, the increasing demand for advanced features has led to a surge in the number of ECUs and the greater complexity of the wiring harness that connects them.

To manage this, OEMs are turning to a more centralized vehicle architecture, where single-function ECUs are being replaced by multifunction compute platforms. This evolution often involves the introduction of Zonal gateways that manage specific areas of the vehicle, communicating with central compute units over high-bandwidth networks such as Ethernet. While this shift reduces hardware costs with less cabling, it dramatically increases the complexity of the software systems that now need to manage a wider range of functionalities and data flows.

The Software Imperative: Modularity, Scalability and Agility

As vehicles become more software-driven, the automotive market is witnessing a significant increase in the importance of software development. Notably, a substantial portion of this growth is concentrated in the ADAS and highly automated driving domains.

Modular software system architecture composed of interoperable software components can manage this burgeoning software complexity. This vision involves software "Lego-like blocks" with standardized interfaces that can be independently developed by different teams or suppliers and seamlessly assembled. This approach has several benefits:

• Reduced Costs: Fosters a supplier ecosystem and enables the reuse of components.
• Faster Development: Allows for parallel development and continuous integration/continuous development (CI/CD) practices.
• Simplified Updates and Repairs: Facilitates over-the-air (OTA) updates and targeted software recalls.
• Enhanced Functionality and Revenue Streams: Enables the addition of new features and services throughout the vehicle's lifecycle.

Interoperable communication provides the cornerstone of this modular and agile future. Choosing the right communication architecture is paramount to building software systems that can be easily assembled and evolved.

Data-Centric vs. Application-Centric Architectures

Why is data centricity important? Legacy software architectures are often based on an application-centric approach, which features tight coupling; the communication paths are often point-to-point and application-specific. This tight coupling hinders reuse and makes the system brittle and costly to maintain and upgrade.

While this approach might work for smaller, static systems, it becomes increasingly problematic for next-generation vehicles, primarily around the disruption and expense of adding or upgrading new functionality. OTA updates in particular benefit heavily from a data-centric approach. The number of communication paths in such systems tends to grow quadratically with the number of components (n²), leading to a tangled web of dependencies that is otherwise difficult to manage and evolve without a data-centric approach. 

The Simplicity of Data-Oriented Communication

In contrast to the application-centric model, a data-centric communication framework focuses on the data itself as the primary asset and the central artifact of interaction. Instead of applications directly communicating with each other, they interact with a shared data space (databus) for flexible communication with other software components, resulting in a data-oriented architecture (DOA). Software components publish the data they produce to the databus and subscribe to the data they need, without needing to know the specifics of other components.

This decoupling of applications from the data offers significant advantages:

• Simplified Software Development: Developers can focus on their component's inputs and outputs without worrying about the intricacies of inter-component communication.
• Loose Coupling: Components are independent and can be developed, deployed, and updated without impacting other parts of the system.
• Enhanced Reusability: Components can be easily reused in different contexts as long as the required data is available on the bus.
• Improved Scalability and Evolvability: New components can be added, and existing ones modified or replaced with minimal disruption to the overall system.
• Increased Agility: Faster development cycles and easier integration of new features.

The software databus ensures the right data gets to the right place at the right time. By reducing the complexity of data delivery, a data-centric framework enables application developers to concentrate on the core logic.

The Power of DDS: A Standard for Data-Centric Connectivity

DDS is an open standard that has been successfully deployed across industries where reliable, real-time data sharing is critical.  

Because it is based on the Data Distribution Service (DDS^™) standard, RTI Connext Drive software is a great example of the type of data-centric framework needed to successfully design and build the vehicles of tomorrow. Connext Drive is already running in over a million vehicles now on the road and is used by numerous OEMs, as well as the majority of top new EV entrants. Connext Drive provides a single platform spanning simulation to production and meets stringent automotive requirements like ASIL D, ISO 21434 (security), and ASPICE processes.

DDS is increasingly becoming integrated into the broader automotive standards landscape. It was adopted by AUTOSAR for the Adaptive Platform and later for the Classic Platform's RTE, while initiatives such as COVESA VSS can also be mapped to DDS data models. In addition, DDS can be bridged to legacy automotive networks such as CAN and SOME/IP via AUTOSAR bindings and software gateways. This growing adoption highlights DDS as a reliable, scalable and high-performance core communication foundation for the next generation of software-defined vehicles. 

This blog is an excerpt from the recent Automotive Week webinar. We invite you to listen to the full webinar on demand.  

About the author:

Rajive Joshi is the System Architect and Principal Solution Architect at RTI and Chair of the Software Portability Working Group at AVCC.