Vehicle E/E-Architecture: Reduce to the Max
The car is probably the most underrated mobile technical system of our days. At around 100 million lines of code per modern high-end car, its software contents is four times that of an F35 fighter plane, and more than five times that of a Boeing 787’s total flight software (FIG. 1) [1, 2]. While that amount of software is just about manageable, the electronic architecture is turning into a hindrance to innovation.
A family-size car can easily have 70 electronic control units (ECUs) spread over all over the vehicle (FIG. 2). A luxury sedan or a vehicle with a particularly high take rate can have around 100 ECUs. This proliferation is owed to the traditional concept of “one ECU per function”. By providing individual hardware for each function the vehicle has turned into an ecosystem of heterogeneous embedded hardware. Networking these “boxes” is a highly complex task that is getting trickier with every additional ECU. The situation has got to a point where the old “one function – one box” belief has no future any longer.
Mind you, the traditional approach is not very economical either: After all, each hardware has its own computing power and memory. However, it is rarely the case that all ECUs are active at the same time. In fact it is rather unlikely for that to happen because some functions are exclusive to others, owed to the fact that they apply to different driving situations. So, there is a certain share of computing power and memory in the car that deserves attention. Moving on towards a centralized server-based architecture will change the situation: Some of the cost of moving on to a server architecture will be compensated by cutting back on decentralized computing power and lower cabling complexity. As the transition to the new centralized architecture is likely to happen in steps, the true dimension of this benefit will only become visible over time as the trade-off between server and ECU computing power becomes clearer.
The limits of a close hardware-software link
Yet, this ECU proliferation is not just uneconomical. It also stands in the way of innovation. Future cars (and some already on the road!) will have completely new capabilities such as automation, a high level of connectivity, a subsequent great need for cyber security, much more safety and comfort, and an electrified drivetrain which also poses new requirements to connectivity, for instance. Connectivity is also of the essence for car sharing. The old heterogeneous vehicle E/E architecture (electronic and electric) is not ready for this. Its mix of embedded systems coming from diverse sources is neither particularly permeable for a smooth data exchange nor is easily updateable – if at all. There is also no solution to adding new functions after vehicle production because there is no host to new software without yet another ECU. Cyber security is also a challenge with a heterogeneous network of ECUs. So, what to do? Well, it is time to clear up and re-structure the E/E architecture, and that is exactly what is happening now (FIG. 3). The current heterogeneous ECU network is being replaced by an architecture with a few High Performance Computers providing the computing power and the memory for the functions of a certain vehicle domain (such as powertrain, interior, body etc.).
The number of these in-vehicle servers will depend on the OEM approach to the server-based architecture and obviously on the model and take rate of the car. However, a count of three in-vehicle servers can be heard in the industry as an initial rule of thumb.
Enter the Automotive Server
This approach to a server-based architecture is a major transition because it is a radical change for the industry. The benefits of a server architecture, however, are so great that the shift has begun. By centralizing computing power and memory in a few in-vehicle servers, it becomes possible to provide sufficient and flexible capacity for applications. The data interchange within a server and between them is smooth and fast as it will be based on powerful communication technology such as GB Automotive Ethernet, for instance. And the underlying strict separation of hardware and software means that (new) functions can be almost freely allocated to the right place.
Different operating systems such as Adaptive Autosar, Android, Java VM, and Automotive-grade Linux can be run safely on the same hardware through virtualization with hypervisor technology and through applying lightweight container solutions. ASIL-rated functions, which require certain measures to ensure the higher level of availability and reliability, can be run on a separate micro-controller, called companion controller.
The in-vehicle server will offer several times the computing power of conventional automotive μ-controller systems which typically have between 500 and 3000 Dhrystone MIPS (= Million Instructions Per Second). The computing power of the initial Continental in-vehicle server generation is provided by a high-performance system-on-chip (SoC). Currently this groundbreaking product concept is being expanded into the Body & Security High Performance Computing platform (B&S HPC). Looking into the future, the Continental in-vehicle server is already designed for the extremely demanding durability requirements of a battery electric vehicle (BEV): In contrast to a car with a combustion engine, parts of the electrical system of a BEV are also active during the charging periods, which does include at least one of the servers in an electric vehicle. Hence this server has several times the operating hours of a server in a conventional car.
The end-of-line is no longer the end of the line
If a certain buffer of computing power is designed-in to an in-vehicle server, it will be possible to add new functions to a vehicle on the road. Probably one of the most important single advantage of a server architecture is its updateability over-the-air (OTA). One of the in-vehicle servers in the car will act as central gateway to all incoming and outgoing data and it will also provide core security features such as intrusion detection and verification of software certificates.
This allows to transmit and install software patches and security updates in a safe and well-coordinated manner. Providing software services to functions in the car will thus become possible as well. Benefits such as predictive maintenance will help to increase vehicle availability and to make necessary appointments at a work shop much less of a nuisance. Distributed computing will also become a reality, e.g. to facilitate the use of artificial intelligence (AI) by using the enormous computing power in the cloud.
The true level of connectivity
But still, why is it all necessary? Why centralize and network to such a new level? Why the focus on updateability and smooth data interchange? A look into the very near future provides an answer. Let us assume for a moment that a family goes out on a trip to an amusement park and let us have a look at what will be going on behind the scenes in a future car with a server-based architecture.
It all really starts before the family even sets out: The parents will typically prepare this kind of outing by planning and/or making reservations via a smart device. By synchronizing with, for instance, a smartphone, the car will “know” about the plan. So, before the vehicle is even driven out of the garage, the best route is already calculated – factoring in that the route should offer a good level of 5G coverage to support entertainment on the road. The vehicle will diagnose itself to ensure availability for the expected date and length of the trip. If something comes up during this check, a message will be shown at an early point (FIG. 4) or will be sent to a smartphone. Speaking of driving out of the garage: An increasing number of future cars will be able to do that autonomously and to open the doors and the hatch via Smart Key as soon as the family approaches the car and has been acknowledged as legitimate to enter the vehicle via the driver’s smartphone.
Know your occupants – know their needs
While everybody gets in, settings are adjusted to the diver’s preferences, and internet access vis Bluetooth is prepared for the occupants’ tablets or smartphones (“Bring Your Own Device”, BYOD technology). During an initial period of manual driving a Digital Companion supports the driver with navigation hints or warnings generated in an environment model which in turn is based on sensor signals and external information (e.g. V2X). In this phase the Infotainment/Interaction and Vehicle servers and the provision of Software Services (apps) need to interact seamlessly. Once on the motorway, the driver activates the Automated Driving (AD) function. If the kids in the rear seats get bored, the AI-based algorithms of the Digital Companion will recognize the type of occupant to accommodate for his/her special needs. So, depending, e.g., on the occupant age or emotional state, suitable entertainment suggestions or support are provided by an avatar on the rear-seat entertainment screen. This kind of support relieves the parents while driving and keeps the family relaxed. Plain everyone who has ever been on that kind of trip with their kids, will know the situation and its potential implications…
Human-machine interaction
Towards the end of the AD section, the driver needs to be brought back into the loop to take back control over the car. To optimize this important transition, the driver’s level of attention is detected through camera-based driver monitoring (FIG. 5). However, other parameters such as medical details can also be included to ascertain that the driver is capable of taking back the driving task (i.e. drowsiness detection).
Depending on the result of this interaction between the car and the driver, the transition process is adapted to ensure a smooth back delegation. If that fails for some reason (e.g. a medical emergency), a minimum risk maneuver will be carried out to bring the car to a safe state.
Assuming that the back delegation went smoothly, the navigation system now begins to provide the turn-by-turn information to get the car to the vehicle exit zone of the amusement park. While the family leaves the vehicle and enters the park, the car parks and locks itself autonomously and may use the parking time for installing OTA updates and preparing the return journey.
This scenario reveals the level of data exchange and connectivity within the car and between the car and the internet/the cloud. Every server in the car (AD with environment model, Body Electronics, Infotainment/Interaction with occupant model) needs to communicate data with the other servers to provide a smooth and safe ride. Permanent access to the cloud and to software services is channeled through a central gateway that provides access and security. This can be done perfectly well within an in-vehicle server-based architecture but causes problems in a decentralized architecture with many dedicated ECUs.
Conclusion
Future cars will be Always On because drivers will expect to have information, apps and services at their fingertips wherever they go – inclusive of using the car. A connected vehicle that can synchronize with other smart devices will create a seamless experience of comfort and safety. Plus, future cars will have to meet extremely ambitious efficiency levels, will have to emit next to no emissions, and shall avoid accidents on the way to Vision Zero. This requirement mix necessitates a new approach to the E/E architecture which is seamlessly connected to the cloud. New functions in the vehicle – spread over practically all domains – will make use of vehicle-internal networking, and connecting the vehicle to the cloud to make services and apps accessible.
This briefly sketched scenario shows that the driver has changing needs and expectations depending on the driving situation or mode, the traffic situation, the type of trip, and his/her momentary condition. The vehicle interior in particular needs to adapt to these changing requirements to provide the right amount of data at the right time, on the appropriate channel, and to make sure that the driver is indeed capable of processing what is expected from him/her. This is enabled by the new level of connectivity and sufficient computing power of the in-vehicle servers.
About the Author:
Dr. Karsten Michels is Senior Vice President at Continental AG.
Sources
[1] https://spectrum.ieee.org/transportation/systems/this-car-runs-on-code
[2] https://www.informationisbeautiful.net/visualizations/million-lines-of-code
All images © Continental AG
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
