What role will E/E architectures play in the electric car of the future – Eight questions for Carsten Hoff from dSpace

They are known as the ‘nerve pathways of the car’ – the countless data lines in modern cars that connect sensors, engines and control units with each other in kilometre-long cable harnesses. Not only do all these systems have to harmonise perfectly with each other, but some of them also communicate with the outside world via the internet. A highly complex system, of which car buyers are generally aware as little as possible, if manufacturers and suppliers have their E/E architecture under control.

So it’s no wonder that E/E architectures have become a hugely important topic for OEMs and their partners, and billions are being invested. After all, sales trends show that many customers, especially in the Chinese market, are more interested in software issues and connectivity services than the technical details of their (future) car’s drive system. Purchase decisions today are sometimes based on software update cycles or how well the car fits into their own digital ecosystem. And not according to the battery chemistry, the design of the electric motors or even the number of cylinders.

But how does it all interact? Where are the trends heading, where are the opportunities and risks? In an interview with electrive, Carsten Hoff, CEO of the dSPACE Group and conference chair at the EEHE (‘electrical + electronic systems in hybrid and electric vehicles’) conference, which took place in Bamberg, Germany, answers these questions.

Mr Hoff, most car buyers are probably not familiar with E/E architectures, but they do know what over-the-air software updates are. How should an OEM prepare its E/E architecture in order to be optimally equipped for OTA updates?

OTA updates require a holistic approach, as they not only require special E/E architectures in the vehicle, but also have a significant impact on the OEM and its development processes.

The vehicle’s E/E architecture must be designed in such a way that it will still be able to receive, verify, distribute to one or more control units and ultimately execute future software several years from now. This requires modular hardware and software architectures. Typically, these communicate service-based via Ethernet, so that communication between the control units is flexible.

The effects on the OEM are just as extensive. In addition to the obviously necessary backend connection, the development-related changes are more far-reaching. Instead of delivering a finished vehicle, in future a vehicle will be developed further over many years. This requires consistent data and version management and the ability to test and homologate these different software versions. One solution for mastering this complexity is virtual verification using a so-called digital loop.

In short: OTA capability must be a basic principle of the entire architecture and development process, not just an add-on at a later date.

Is the E/E architecture of a vehicle primarily relevant for connectivity issues? What role do electric drives and autonomous driving play?

Connectivity is an important driver, but by no means the only one. Autonomous driving in particular has an impact on the E/E architecture, as enormous amounts of data have to be generated and processed. However, these issues do not affect communication between the control units so much as the control units concerned.

For the control units of autonomous driving functions, for example, this means redundancy concepts and high functional safety requirements in combination with high bandwidths and real-time requirements.

Connectivity control units have more flexible and different interfaces. They typically have faster update cycles and are linked to high security requirements.

How do you see the German manufacturers positioned in this area? With its new class, BMW has announced a completely new architecture with four large central computers, while VW is working with the US startup Rivian.

The German OEMs have recognised that a far-reaching transformation is necessary. BMW is taking a bold step forward with its new class and is relying on a centralised computer architecture that replaces many individual control units. Volkswagen is using co-operations such as with Rivian to bring innovative software and hardware solutions to its portfolio. These and similar steps can be observed throughout the industry – not just among German OEMs.

However, clear differences can be recognised in the implementation. A key factor in consistent implementation is the extent to which legacy issues can be jettisoned.

There is often talk of a ‘zonal’ E/E architecture. What is behind this term?

The ‘zones’ of an E/E architecture are only one part of the overall concept. As a rule, a zonal architecture consists of one to a few high-performance computers (HPCs), several zone control units and the sensor/mechatronic components.

The HPCs have centralised functions and perform the essential tasks. For example, there could be one HPC each for all driving functions, connectivity and autonomous driving functions. The zone control units – such as the front end, passenger cell and rear end, which connect the sensor/mechatronic components – are logically arranged below this. Exceptions to this are the sensors for the autonomous driving functions, which are usually connected directly to the HPC.

The new structure drastically reduces complexity, simplifies wiring harnesses, saves weight, lowers costs and increases flexibility when integrating new functions.

In short: zonal architectures are the answer to the increasing complexity of modern vehicles.

What role does cybersecurity play in development? Is it possible to standardise measures, or do the safeguards have to be specifically adapted?

With the introduction of new cybersecurity standards such as ISO/SAE 21434 and UN R.155 at the latest, functional security is not the only key development objective. Just like OTA updates, cybersecurity must be considered holistically, as it affects every networked component and must be ensured for years in the post-production phase. This requires new processes, procedures and methods, starting with a Threat-And-Risk-Analysis (TARA), cybersecurity tests (also in combination with functional tests) and, if necessary, the subsequent decommissioning of functions.

How much expertise do the OEMs actually have in the ‘nerve centres of the car’, and what role do the suppliers play in the E/E architecture?

In the context of software-defined vehicles (SDV) and zonal architectures, OEMs are increasingly building up their own expertise, particularly in key areas such as software architecture, system integration and functional safety. The definition of the architecture, bus systems and communication is clearly in the hands of the OEMs. This applies in particular to OEMs that have a high level of system understanding or want to develop defined parts of the application themselves.

At the same time, suppliers remain indispensable partners – especially when it comes to providing hardware platforms, basic software or specific technologies such as high-voltage components or driver assistance systems. However, cooperation is shifting: OEMs are providing fewer specifications and taking on more system responsibility, while suppliers are increasingly acting as development partners.

What trends do you see in E/E architecture? Where is hardware heading, and what requirements will future software have to fulfil?

The direction is clear: greater centralisation of computing power on powerful HPCs and zone controllers, connected via fast Ethernet networks. Hardware and software are becoming more decoupled, resulting in more flexible and modular systems.

On the software side, development and testing is becoming increasingly modular. Virtualisation plays an important role here, as this is the only way to meet the high requirements for fast development cycles, greater complexity and increased quality.

The range of functions required is constantly increasing. Can this also become a cost trap? What costs are we talking about for the E/E architecture of a modern, networked electric car, and where will the costs go if the demands on the systems continue to increase?

Of course, increasing functional complexity is a high risk for exploding costs. The E/E architecture already accounts for a significant proportion of the total costs of a vehicle.

However, with the right methods, processes and tools, it is possible not only to stop costs spiralling, but also to reverse them. The aforementioned virtualisation is one possibility. Zonal architectures with powerful HPCs lead to a considerable simplification of the wiring harnesses. BMW has announced that the wiring harness of the new class is 30% lighter and the number of variants has been reduced by a factor of 3,000.

In addition, the new E/E architectures with software monetisation and OTA updates also open up new opportunities for OEMs.