New Dawn of Monoliths in Automotive

July 8th, 2020 – Reading time: 9 minutes

For the last decades the continued increase of Electronic Control Units (ECU) in cars kept software simple. With autonomous driving, this no longer suffices as shown by Tesla and propagated by automotive suppliers. The introduction of extensive coordination comes with high demands on performance and latencies.

Figure 1: The trend from central computing power to more decentralization is starting to revert.

Automotive Software Development Today

Cars today can have as many as 150 ECUs (e.g. the 2017 BMW 7-series models). The distribution keeps each domain segregated.

Today’s cars are at the top of complex machineries, overshadowing even the most ambitious deep space projects. And still, automotive software development is kept manageable though this distribution based on the concept of decentralisation. Mostly requiring only isolated knowledge creates flexibility in stuffing and results in quicker technological advances.

Heavy tailoring to meet the minimalistic hardware specs results in little reusability. The strong focus on binary size and performance leads to complex toolchains that need hours to run.

Additionally, this separation and unified communication channel have caused outsourcing and fragmentation in the software development. Several suppliers have become market leaders for specialized hard and automotive software. Most development teams are spread over the globe. Some depend heavily on engineering service providers.

Figure 2: Since electronics have been introduced to cars, the number of ECUs has consistently grown – until now (example: Ford cars).

In the Wake of Autonomous Driving

Autonomous Driving and Artificial Intelligence causes an increase by leap and bounds in complexity. Not only in code, but also in run time behaviour, architecture, safety, security, processes and required knowledge. This will lead to three significant changes:

  1. More centralisation with powerful board computers to ensure performance and provide the possibility of data fusion
  2. Introduction of unusual languages and knowledge for automotive such as TensorFlow
  3. A strong focus on reusability and more shared software in between the industry

Back to Centralization

Autonomous Driving requires Sensor Fusion to create a situation awareness. Synchronization of sensor information is crucial to create an accurate picture of the situation. This fact is for example reflected in Teslas central unit[1] and the reason for Tier 1 like BOSCH[2] or IT and electronic manufacturers[3] to promote central control units. Latencies could cause an information mismatch and lead to wrong decisions. To reduce the complexity of synchronization, sources of latencies need to be kept in check. The easiest way to achieve this is by processing all information at once. Highly autonomous cars already have powerful, central ECUs. This trend will continue for as long as we advance autonomous capabilities.

Advances in robotics implementing more decentralized intelligence to establish highly sophisticated, autonomous drones is far from reaching the automotive industry. Safety requirements demand predictable systems with extensive safeguards. More incidental systems that push the boundaries in robotics are for now limited to that field, until we find to proof their reliability and safety.

Artificial Intelligence Knowledge Comes from Other Industries

Artificial Intelligence is a complex field that has yielded numerous specialized libraries – and even programming languages. Close to none in C/C++ – the predominant language in the automotive industry. To get up and running with this technology, the use of established tools and libraries is key. As an example, BMW provides some python AI algorithms based on TensorFlow[4] (current de facto standard for AI applications) and in job portals companies are searching for “Python Developer Automotive”. With more powerful computers introduces to automotive, running code with high resource demands becomes feasible.

It is likely to have toolchains that start in with teaching artificial intelligence in simulated environments utilizing super computers. In this set up the advantages of established libraries can be used. When a result is achieved that reliably creates the desired result, it is reduced of its learning capabilities and compiled to a binary. This binary in turn is integrated into the ECU software.

Increased Complexity Requires More Reusability

With long learning periods for autonomous systems and complex subsystems such as Sensor Fusion it is essential to reuse more parts to assemble new software. The difficulty to prove the safety of artificial intelligence generated behaviour, makes it an expensive endeavour. This will not be limited to reuse of internal software and will include a significant degree of third-party software. Licencing and management of open source software (OSS) will be an important part of any automotive project. With a high demand for high levels of autonomous driving it will be key to collaborate within the automotive industry. Only by sharing knowledge the ambitious time-to-market can be achieved without jeopardizing the safety along the way.


Autonomous Driving will bring significant change to the automotive industry. Probably most regarding the extend of knowledge and software sharing. Third-party libraries and open source combined with powerful central board computers will enable high level autonomous driving to an extend that we are yet left to imagine.







  • Ulf Stocker

    Head of CoE Software Engineering

  • Nils Berger


How can we accelerate your development?
Let’s start


INVENSITY Software Engineering Services

Core Competences

  • Architecture for legacy code
  • Staged continous integration
  • Continous integration


This report is intended for general guidance and information purposes only. This report is under no circumstances intended to be used or considered as financial or investment advice.

The information contained herein may be subject to changes without prior notice. INVENSITY does not accept any form of liability, neither legally nor financially, for loss (direct or indirect) caused by the understanding and/or use of this report or its content.

Learn more