How DDS simplifies multi - ECU E/E architectures

The automotive industry continues to evolve and so does the underlying architecture. From a general perspective, traditional vehicle architectures are more rigid, heavily wired, and limited in their ability to change. Software is typically bundled with hardware in a vendor lock-in manner and a substantial software update is hard to do in traditional architectures where many small ECUs must support the new advanced functionalities.

As we move away from small Electronic Control Units (ECUs) and simple systems, using traditional platform solutions leads to an inefficient development process. When you must specify the whole system upfront, any subsequent change request is painful. We need technologies that allow us to develop flexible, modular software, and we cannot do that with the traditional approach.

Jakob Zwirchmayr, Software Architect, Product Innovation TTTech Auto

Traditional E/E architectures were driven by car models. For a modern Software Defined Vehicle (SDV) approach, Electronic Platforms must be in the center and they need to serve multiple car models. This E/E platform first approach means that the platform development is decoupled from vehicle releases. The Electronic Platform Architecture consisting of software, networking and electronics components/ECUs decouples software from hardware, making it easier to update the software. In short, a flexible architecture like this is easier to integrate and use while maintaining system-level functionality.

The shift from car platforms first to electronic platforms first approach

With the software-defined vehicles the functionality of the vehicle is mainly enabled through software. Safety plays a key role in many of these functions. As a safety-critical real-time system, modern vehicle therefore requires a holistic approach to system development: it must enable seamless and safe updating of software functions, considering all the electronics, sensors, actuators, networking, and power supply of the system. At the same time, the software should be easily deployed onto the next generation hardware. The automotive industry needs solutions for more flexible software development. The traditional approach is no longer proportional to the size of the challenge.

To successfully transition to an SDV approach, the industry needs to shift away from today’s technology. Currently, monolithic software architectures and a distributed E/E architecture make software development complex and expensive as they are inflexible and have long development cycles.

Roland Berger Insights, The SDV Approach

Software-defined car

 

Software and flexibility

Today, auto-tech players face a triple challenge: modern cars must be developed quickly, they must be flexible enough to change again and again, and all this without compromising functional safety and security. As we look to a software-centric future, we need to better understand what this means for software development.

Traditionally developed applications are called "monoliths". Monolithic means too large, too regular, or unable to be changed. Consequently, monoliths scale poorly in modern complex automotive use cases. We can generally think of applications as blocks of different software components. In a traditional approach, these components would have a single code base and updating one component usually requires changes that affect the entire block. This means that as the application scales, the code base can become extremely large and complicated. As a result, developers can only add limited new functionality to these applications. If one part of the application fails, the entire application can fail. Knowing that modern vehicles consist of numerous applications of different types and safety criticality that are continuously updated, it is obvious why this characteristic makes monoliths unfavorable for the modern automotive industry.  

The SDV approach is characterized by new service-oriented or microservice-based architectures (MSAs) and a central, zonal E/E architecture. This means functions can be broken down into more manageable parts, speeding up development and testing, and lowering costs.

Roland Berger Insights, The SDV Approach

So, what is a more change-friendly software development practice? Unlike monoliths, which are limited and scale vertically, modular applications allow more flexibility and independence between software components. They scale horizontally, meaning each module can grow independently as needed. These applications are also called microservices and are based on a distributed, modular architectural approach. Each microservice is self-contained and can be debugged, deployed, and managed without impacting other microservices. This makes it easier to add redundancy and diversify implementations, which is especially important for fail-operational performance capabilities. With the right knowledge and technology, modular application development can significantly advance the in-vehicle system by increasing its growth potential while ensuring system safety and reducing time to market.

 

Traditional vs modern

Looking at the currently used vehicle platforms, the AUTOSAR Classic platform architecture is suitable and widely used for the real-time safety-critical applications deeply embedded in the ECU. However, due to its centralized software definition, it is not flexible enough for modern software development because it is difficult to have multiple development streams. Unlike AUTOSAR Classic, AUTOSAR Adaptive is designed to support more flexible use cases. It targets high-performance microprocessors/SOCs and flexible software configuration. AUTOSAR Adaptive is designed to support the concept of the new generation vehicle with multiple functions with different safety requirements, higher computing power and continuous vehicle updates.

But does it offer enough flexibility to support the most complex use cases in the automotive industry efficiently and future-proof?

Compared to Classic AUTOSAR, Adaptive is indeed more flexible. It is much better prepared for the evolution of software running on POSIX OS and high-performance SoCs, for example, by moving to a service-oriented communication paradigm. However, it does not address some of the challenges of rapid software development cycles in highly integrated next-gen vehicle architectures, such as the extensive amounts of manifests and specifications that must be written and for which tool support is typically required. Although the Adaptive Design methodology is more decoupled than Classic AUTOSAR system specification, it still exercises a great deal of control over the application design, e.g., by relying on system-wide manifests. Usually, additional processes are required for managing/organizing changes in manifests, which often requires additional tools due to their complexity.

“It can be a cumbersome and slow development process to define system properties at the beginning of development with a centralized design paradigm and well-defined roles as well as an iterative process.”, says Jakob Zwirchmayr, software architect at TTTech Auto, about the traditional development practices.

In today's automotive industry, and especially in safety-critical domains, software companies are aware of the system requirements and constraints. However, that doesn't mean they must adhere to all pre-established frameworks and imposed standards. Next-generation system complexity should be handled by the right technology, relieving software developers from complex system configuration efforts.

 

Communication is key

Software-defined vehicles require exceptional cross-vehicle communication capabilities as ECUs inside the vehicle become more integrated than before.

The traditional approach of incrementally adding new electronic control units (ECUs) with their own power, processing, data and connectivity for each new function no longer works; it will not scale to accommodate all of the new requirements for computing power, data processing and power distribution.

Aptiv Insights 

As we reach higher levels of automation, the vehicle must demonstrate correct behavior, reliability, and responsiveness. This quality of performance can only be achieved through effective real-time cross vehicle data exchange.

 

How to build large modern in-vehicle systems?

To build highly safe and performant modern in-vehicle systems, many requirements must be met: We need to design, build and integrate without reducing the quality of service (QoS) and without compromising safety.

Open Management Group Data Distribution System (OMG DDS) is the technology that meets the criteria of the modern software development paradigm. It is a proven technology with a wide ecosystem that allows applications to express Quality-of-Service (QoS) requests and offers. It supports incremental system development, where QoS parameters and data types can be refined incrementally. The DDS QoS specification is particularly powerful when combined with technologies that provide QoS guarantees, such as Time-Sensitive Networking. This ensures the reliability of the network connecting the ECUs.

 

DDS Middleware is a software layer that abstracts the Application from the details of the operating system, network transport, and low-level data formats.

“The incremental approach can be applied already in early development and carried over to later integration phases.” Jakob explains. He adds, “System properties such as end-to-end latency, priority for traffic, etc. are important and must be defined and validated. The earlier such properties can be partially stated and validated, the better. Proper incremental workflows help avoid costly big-bang integration steps late in the project."

DDS technology also improves the workflow between software developers and system integrators. Their interaction becomes easier because DDS avoids the centralized information storage that is usually a bottleneck, by checking whether producers (nodes that produce information) and consumers (declare an interest in the topic such as location, pressure etc.) are compatible and indicating those that are not. In DDS, information (data) and the associated QoSs are the only contracts that bind microservices.

It simplifies development: “Eighty percent of typical networking code is dedicated to handling data selection and errors. DDS accelerates development by abstracting this complexity away from application code.” And it simplifies integration: “System integration is essentially a free benefit of DDS. Ubiquitous information availability allows spontaneous integration, including dynamic discovery and related QoS matching.” DDS-Foundation, Key technical benefits

The automotive industry is introducing next-generation vehicles and placing high demands on powerful computing, software quality, connectivity, flexibility, error-free and safe performance. As we move toward a software-defined mobility, DDS technology provides everything needed to succeed:

• The standard DDS middleware is a software layer that abstracts the application layer from the details of the operating system, network transport, and low-level data formats.
• The same concepts and APIs are provided in different programming languages allowing applications to exchange information across operating systems, languages, and processor architectures.
• Low-level details such as data wire format, discovery, connections, reliability, interoperable protocols, transport selection, QoS, security, etc. are managed by the middleware.

 

Simply Works. Developers First. Great Ecosystem.

ZettaScale Technology has developed Cyclone DDS, a technology based on the 20-year-proven DDS communications standard that meets the most stringent safety requirements and runs in the most safety-critical environments. This makes it the right technology to support the transition to the highest level of automation and ultimately realize the software-defined vehicle.

Visit ZettaScale's articles section to learn more about what makes DDS unique and more.

 

MotionWise and Cyclone DDS equals innovation

TTTech Auto and ZettaScale Technology have already announced their collaboration to provide cutting-edge communication technologies for software-defined vehicles.

Modern vehicle development must be viewed holistically as system-wide safety is one of the biggest challenges on the road to higher levels of autonomy. Our upcoming joint product MotionWise Cyclone DDS ensures just that by providing effective communication, flexible software development and integration as well as interoperability with various technologies such as other DDS implementations and the Robot Operating System (ROS 2). It includes a comprehensive toolset and Time Sensitive Network (TSN) extensions. MotionWise Cyclone DDS also supports multiple operating systems such as Classic AUTOSAR, Linux and QNX.

MotionWise Cyclone DDS is the result of years of experience and knowledge invested in DDS technology and safety-critical automotive systems. With this product, ZettaScale and TTTech Auto are specifically targeting the automotive market, considering all system performance constraints. To ensure the most stringent safety requirements, MotionWise Cyclone DDS is certifiable to automotive safety level ISO 26262 ASIL D.

Jakob Zwirchmayr, TTTech Auto

Stay tuned to learn more about our upcoming joint software solution for safe and flexible application development, the technology that will take vehicle safety to the next level.

 

Accelerate your journey towards highly automated driving with MotionWise safe vehicle software platform. MotionWise delivers safety by design and fail-operational performance while managing the high complexity of solution elements. As a result, OEMs and Tier 1 suppliers can benefit from faster time-to-market for their automated driving projects and increased competitive edge at reduced costs.  

Stay informed about the most recent technological findings in the automotive industry – visit us at www.tttech-auto.com and follow us on LinkedIn for more on this exciting topic.