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.