101 Automotive Software Complexity

Prolog: what is Software Complexity?

The Software Complexity in Automotive noticeable in the everyday life of software and system development essentially results solely from the diversity of vehicle products.

Introduction

Automotive OEMs have developed different strategies regarding the equipment of their vehicles. Leaders in terms of variants are German OEMs, which offer their customers a variety of configuration options for a vehicle model. The goal of the OEMs is to provide the largest fit and individual wishes possible.

In the 2010s, a customer could customize their personal vehicle. Alongside classics like interior and exterior color, engine power, and rims, numerous additional options such as sunroof (yes/no), navigation (none, small, medium, premium), driver assistance functions (with/without traffic sign recognition), and many other options were available to them.

All these options are controlled via configurations and ultimately considered during production and thus also during development.

The advantage: The individual options are very easy to oversee. The customer can decide for each option whether they are willing to pay the price of an option. The OEM is pleased because they can offer customers individual, tailored vehicles that the customer is willing to pay for.

The disadvantage: The number of theoretically possible variants of a vehicle model is the product of all possible options. The theoretically achievable variety could quickly generate several billion variants. A short calculation example: You have 32 options and can only choose yes or no, which means you have 2^32 = 4,294,967,296 possibilities.

The problem

The majority of options influence the fundamental vehicle platform architecture - the combination and interaction of sensors, actuators, control units, and mechatronic components.

?? Selection of the customer configuration in the ordering process directly affects the software.

If a customer orders an electric sunroof, a sunroof and a control of the sunroof for opening and closing must be installed. An electrical line must be laid. There must be logic that detects a user's operation and performs control of the electric sunroof.

That sounds still feasible. However, this also means that the central locking system must be able to control a installed sunroof. For this, it must know whether the sunroof is open or closed. It thus needs information about the position status of a sunroof.

An online infotainment system should be able to inform the user about the status of the sunroof via an app. And there are many other cross dependencies.

All these dependencies resulting from a customer's possibility of whether they want an electric sunroof or not inevitably result in variants at the system level, which in turn result in variants at the component level (ECUs) and ultimately in variants at the software level.

As a result of these conscious product portfolio decisions, many additional, not immediately apparent variants are created, which must be analyzed, implemented, and tested in software at several levels. The implementation in software is basically done by using parameters. Parameters are the standard principle for implementing variants in software development in this case.

In the example of our sunroof, there will certainly be a parameter in the central locking system that could be called "Electric_sunroof_installed" and queried in the code.

Just a reminder: in this example code is identical in all customer vehicles. In production, at the end of the line, the control units are informed (via in-line/offline flash programming) about a vehicle-specific configuration, indicating what was actually installed in the customer vehicle.        

The parameters thus serve to control functions in the code.

In our example, there will be a function at the vehicle level that requires all doors, windows, and the sunroof to be closed when a closing request from a user is detected. This requirement is assigned to multiple levels of a unit and implemented in the code. In the implementation, there will be a query about the installation of a sunroof. If one is installed, closing will be requested; if none is installed, the function code will be skipped (if/else).

?

During the closing process, the user naturally wants to ensure that the sunroof is actually closed. This is done automatically by checking the closing status. If the window has not been completely closed, for example, due to contamination and the control did not take place within the specified time frame, an error message or a renewed control of the closing actuator may occur.

?

And now a bit more complexity:

What if the customer wants to keep the sunroof open? In this case, a user configuration in the infotainment system could help. This should of course only be visible if a sunroof is installed. So here, too, information about the installation of a sunroof must be available. If it is installed, there will be a menu entry for "Sunroof"; if not, the entry will be hidden. In the menu, the user may be able to set whether they want the sunroof to close when a closing request is made or not. This information must also be accessible to the central locking system.

?

So many additional lines of code arise at several points. And now imagine if you cross this option with even more options of the central locking system:

Variants for locks (lock cylinders: yes/no), 
remote control (with/without keyless entry), 
sunroof yes/no, 
convertible yes/no, 
number of doors (2, 3, 4, 5, 6, 7),
gullwing doors (yes/no), 
sliding doors (with and without automatic closing assistance),
sliding doors (one-sided or both-sided),
frunk (yes/no), 
door opening mode (all doors at once, one side, only driver's door), 

and many more variants.         

The number of possibilities that must be distinguished and treated by the software increases very quickly, as here too, the product of all individual options forms the total variants. And they all must work and be tested.

Summary

Software complexity mainly and directly results from product portfolio decisions. If you want to get a grip on software complexity, each hardware variant at the vehicle level must be examined and, ideally, avoided. Customer-specific settings and the provision of vehicle functions must be implemented in software in the SDV.

Epilogue

Variations in software will always exist. However, variations must be limited to the absolute minimum. In particular, decisions at the system level can cause massive cross-effects that are not foreseeable at the system level.

Each additional variant or variant option leads to an exponential increase in the total number of variants that must be considered in software.