A few letters can sometimes say more than long reports. Let’s take the example of “E/E” in E/E architecture. E/E architecture plays a critical role in the design, development, and operation of modern vehicles and complex systems, enabling the integration of advanced technologies and functionalities to meet the needs of users and stakeholders. Sandu Buraga, Senior Project Manager at Harman International, explains how new E/E architectures impact the way innovative automotive software is designed. Application protocols such as NDS.Live are helpful for making map data available via mobile services in this environment. A common data standard is essential for driving interoperability, compatibility, efficiency, innovation, safety, security, and global market access in E/E architecture and the future of mobility. It serves as a foundational element that underpins collaboration, integration, and progress across the automotive and transportation industries.
Continuous evolution of automotive features
Roughly speaking, the development of E/E architectures can be divided into three stages: The first generation of distributed architectures can be found in the 1980s, the second generation in the 1990s, and the third generation, which is still present, began around the year 2000.
Whereas the 80ies and 90ies were predominantly concentrated on ICE motor control and vehicle dynamics, from 2000 onwards, the focus was onso called classic ADAS functions such as speed limit assistants, lane keeping, AAC, lights and more. From around 2015 onwards features such as L2+ ADAS, with Tesla as pioneer in this field, became increasingly important. Nowadays companies and developers have L3 ADAS features on their list, take Mercedes-Benz and its traffic jam motorway assistant as an example. But it is also worth taking a look into the crystal ball: In the future, L2+ features will likely proliferate in all vehicle classes partly due to legal requirements, partly due to market demand and because of electrification. Furthermore, the L3 features portfolio will increase and reach the tipping point.
First, it was all about controlled air and fuel supply
Distributed architecturestarted in the second half of the 1970s by introducing an ECU addressing one function: controlling air and fuel intake for an optimal engine operation based on input from driver and burned gases outtake. In the next decade more ECUs werde added in an incremental manner addressing various functions related to powertrain, vehicle dynamics, comfort, and multimedia. Usually, one ECU box was focussing on customer function, for that reason these are also called hardware functions.
The first challenge was related to the harness, because these ECUs had to be interconnected and physical buses were needed. In this context CAN bus emerged and the central communication gateway as well. However, by increasing the number of ECUs to up to 150 for premium vehicles, challenges in the industrialization phase on assembly line and supply chain occurred, that grew and added additional overhead that had to be handled by manufacturing and procurement.
Domain centralized architecture topology
As early as 2010, traditional carmakers became more and more aware, that due to the above-mentioned reasons, the number of deployed ECUs had to be drastically reduced, leading to the next evolutionary step: central domain controllers. They consolidate more functions in one powerful computer and the mindset shifted from hardware functions to software functions, one of the prerequisites of what we call software defined vehicle today.
Examples of domain controllers are IVI domain controllers, usually grouping the in-cabin experience related functions such as instrument cluster, radio and multimedia, navigation or in-cabin sensing and monitoring ADAS functions, AR SW, etc. focusing in general to offer a rich user experience. Modern IVI domain controllers are also called Digital or Intelligent Cockpits and are powered by powerful SoCs like Samsung Exynos Auto 9, the Qualcomm Snapdragon 8 family, or nVidia. The current trend is for these to include GPU and NPU resources as well.
Another example of domain controllers is ADAS controllers grouping L2+ functions and Vehicle Dynamics controllers grouping functions required for controlling the dynamics of the vehicle like ABS, ESP, etc. Compared to the IVI Domain controllers, such systems are functional safety relevant and subject to various regulatory and non-regulatory requirements for safety, but like the IVI systems they have important computing resources.
In this context, moving so many functions in one ECU led to a lot more communication between functions within the same ECU and in between individual ECUs. So new busses had to be developed both from a hardware but also from a software perspective. CAN busses were not sufficient anymore, so the Ethernet bus took over and a second trend focuses on IPC (Inter Process communication) and virtual intermachine communication. The same trend can be observed in the field of completely centralized architectures.
Evolution of E/E architecture: 5 generations at a glance
| Architecture | Generation | Main features |
| Distributed | 1 | Independent engine-control units (ECUs)Isolated functionsEach function has its own ECU (1:1 connection) |
| 2 | Collaboration of ECUs within one domainDomains: body/comfort, chassis, power train, infotainment3 or 4 independent networksLimited communication among domains | |
| 3 | Stronger collaboration via central gatewayCross-functional connectionAbility to handle complex functions (e.g. adaptive cruise control) | |
| Domain centralized | 4 | Central domain controllerAbility to handle more complex functionsConsolidation of functions (cost optimization) |
| Vehicle centralized | 5 | Virtual domainLimited dedicated hardwareEthernet backboneHigh-complexity, high-computing functions |
Relevance and impact for navigation based applications
Since the early ADAS functions from 2000 onwards, experts observed that map data improves the quality of such features. And a feature like speed limit detection would become a so-called distributed software feature: The main implementation would reside in the front facing camera ECU handling the image processing aspects, but the map data is provided by the IVI ECU and can be exchanged using the CAN bus.
The CAN bus on the other hand has limited bandwidth and latency. That’s why protocols like ADASIS or OEM proprietary ones were developed to handle with these scarcities. The most prominent protocol is the ADASIS v2.1, that compacts the map data to fit the CAN messages, estimates a horizon based on the position of the car to reduce the map data to be transferred as much as possible and to transfer the data to the ADAS consumer ECUs in advance to address the latency issue.
Domain centralized and vehicle centralized era
In this new “geological” era dominated by fast buses, the CAN bus becomes less and less relevant, and intensive data features like map data, no longer need to be compacted, predicted and transferred in advance due to latency issue.
Map data can be made available through relocatable services which can reside in the cloud or in the vehicle using application protocols like NDS.Live or others.
That’s why new E/E architectures impact the way how automotive software is designed and architected.
A common data standard is crucial for the future of E/E architecture for several reasons:
In the NDS.Live Developer Portal you can find out more about the possibilities and functions of NDS.Live.
Back to news →