Software development in the automotive context: An introduction to Systems Engineering

The code size in automotive software is increasing 

The complexity of modern cars is steadily increasing, which is not only due to more advanced mechanical components but also because of the large number of computers and software-programs, featured in today’s automobiles. Currently even low-end cars have embedded around 50 electronic control units (ECUs) – small boxes installed in various locations all over the vehicle, which contain the software code needed for functions like controlling your engine, managing your anti-lock brakes or even just opening your side windows. 

The more features your car has, the more ECUs are required to calculate and execute those functions. Therefore, modern premium cars may contain up to 100 ECUs with up to 100 million lines of code (MLOC).  

While this already sounds like a lot, it gets even more impressive, when compared to other current devices and vehicles. For example, the U.S. Air Force’s modern F-35 Joint Strike Fighter, is controlled by 24 MLOC. With an increasing number of automobile functions, such as autonomous driving, the code size is set to rise to 300 MLOC in the next years.

In cars, all software code constantly interacts with or is even directly embedded in so-called E/E components. These electrical and electronic components can be things as simple as a car’s headlights, for example, but also roof openers, parts of the exhaust system, or even the sensors and actuators needed to make a car drive by itself. 

Autonomous driving and traceability 

Although autonomous cars are expected to make our roads safer, they will hardly be impeccable and prevent each and every accident. Therefore, international legislators are imposing strict rules for the development of autonomous cars, to be able to identify later what caused an accident. Car manufacturers thus will have a judicial liability to show the authorities who is responsible for which function and its results.

This concept, called traceability, and it stands for the ability to verify who is responsible and the ability of keeping track how a specific part of software has been produced and by whom. As many ECUs with software code or even whole systems (such as a power steering) are developed and produced by automotive suppliers, it is crucial for OEMs to secure themselves by applying tight traceability. 

Managing the complexity of automotive software development 

However, this requirement does not make the cooperation between different teams and companies less complicated. Numerous developers with different requirements and motivations must be aligned, when working on a highly complex system as a car. OEMs therefore more than ever get a coordinating role to establish the traceability between the components and parts developed by their suppliers. 

Like for large-scale construction projects, experts from various disciplines need to be orchestrated, making sure they all contribute to one, commonly agreed upon architecture. And like in many large-scale projects, there must be a structured approach to think of, architect and build such a complex system like a self-driving car. 

One approach to that is the concept of Systems Engineering. It provides methods and tools to design and manage very complex systems from coming up with an initial idea to setting up an architecture and finally implementing everything in a product. 

What did we learn? 

This article series will give you an overview to Systems Engineering in the automotive context. To sum up: 

In this article we saw that modern cars are highly complex systems, for which certain legal standards apply. Automotive OEMs need to coordinate their various suppliers and development teams – which can be done through Systems Engineering.

In the next article we will look at the V-model, what architecture means in the context of automotive development and what all this has to do with building houses and installing taps. 

In the following article we will understand which roles in the V-model are required, how their interfaces are described and what artifacts they produce. We will look at the practical problems of implementing systems engineering in a large company structure and deal with verification, validation, and the four-eyes principle and how these concepts are used in software development.