18-06-2012, 12:12 PM
Challenges in Automotive Software Engineering
[attachment=24680]
ABSTRACT
The amount of software in cars grows exponentially. Driving
forces of this development are cheaper and more powerful
hardware and the demand for innovations by new functions. The
rapid increase of software and software based functionality brings
various challenges (see [21], [23], [25], [26]) for the automotive
industries, for their organization, key competencies, processes,
methods, tools, models, product structures, division of work,
logistics, maintenance, and long term strategies. From a software
engineering perspective, the automotive industry is an ideal and
fascinating application domain for advanced techniques. Although
the automotive industry may adopt general results and solutions
from the software engineering body of knowledge gained in other
domains, the specific constraints and domain specific
requirements in the automotive industry ask for individual
solutions and bring various challenges for automotive software
engineering. In cars we find literally all interesting problems and
challenging issues of software and systems engineering.
Categories and Subject Descriptors
D.2 [Software Engineering]: D.2.1 Requirements/Specifications
(D.3.1), D.2.2 Design Tools and Techniques, D.2.10 Design
(D.2.2), D.2.11 Software Architectures
General Terms
Design, Economics, Reliability, Experimentation, Human Factors,
Standardization
Keywords
Automotive Software Engineering, Model Driven Development,
Embedded Systems
1. INTRODUCTION
In many technical products, software plays a dominant role today.
In cars, this applies even to the extreme. Today software in cars is
a dominant factor for the car industry, bringing various problems
but being nevertheless decisive for competition.
One can easily see that the amount of software in cars has been
growing exponentially over the last 30 years, and one can expect
this trend to continue for another 20 years at least.
The first software found its way into cars only at a time about
thirty years ago – so software grew in only more or less four
generations of cars. From one generation to the next, the software
amount was growing by a factor of ten, or even more. Today we
find in premium cars more than ten million lines of code and we
expect to find in the next generation ten times more.
Many new innovative functions in cars are enabled and driven by
software. Recent issues are energy management and the current
step into hybrid solutions, which can only be realized in an
economic way by plenty of software. It is mainly the application
domain specific innovations with their stronger dependencies and
feature interactions that ask for cross application domain
organizations.
In the following, we shortly describe the history of software in
cars as far as it is relevant to understand the current challenges.
Then we sketch the state of practice with its problems, challenges,
and opportunities. Based on a short estimation of the future
development we describe our expectation how the field will
develop. Finally we describe current research in the domain of
automotive software engineering (see also [14]).
2. The History
Just 30 year ago, software was first deployed into cars to control
the engine and, in particular, the ignition.
The first software-based solutions were very local, isolated and
unrelated. The hardware/software systems were growing bottom
up. This determined the basic architecture in cars with their
dedicated controllers (Electronic Control Units or ECUs) for the
different tasks as well as dedicated sensors and actuators. Over the
time to optimize wiring, bus systems (see [29]) were deployed
into the cars by which the ECUs became connected with the
sensors, and actuators.
Given such an infrastructure, ECUs got connected, too, and could
exchange information. As a result the car industry started to
introduce functions that were realized distributed over several
ECUs connected by the bus systems. Such functions were built
bottom up. A systematic top down design was never used. If we
would not go in evolutionary steps but re-design the
hardware/software systems in cars from scratch today, we would
certainly come up with a quite different solution.
3. State of Practice
Today premium cars feature not less than 70 ECUs connected by
more than 5 different bus systems. Up to 40 % of the production
costs of a car are due to electronics and software.
3.1 The Role of Software in Cars
Within only 30 years the amount of software in cars went from 0
to more than 10.000.000 lines of code. More than 2000 individual
functions are realized or controlled by software in premium cars,
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
ICSE’06, May 20-28, 2006, Shanghai, China.
Copyright 2006 ACM 1-59593-085-X/06/0005...$5.00.
33
today. 50–70% of the development costs of the software/hardware
systems are software costs. For a view on the network in a car see
Figure 1.
Software as well as hardware became enabling technologies in
cars. They enable new features and functionalities. Hardware is
becoming more and more a commodity – as seen by the price
decay for ECUs – while software determines the functionality and
therefore becomes the dominant factor.
3.2 Embedded Software as Innovation Driver
Software is today the most crucial innovation driver for technical
systems, in general. By software we realize innovative functions,
we find new ways of implementing known functions with reduced
costs, less weight or higher quality, we save energy and, what is,
in particular, important, we combine functions and correlate them
into multi-functional systems.
Figure 1. Onboard Network
This way software allows for completely new solutions of, in
principle, known tasks. What has been said here for embedded
systems, in general, applies to cars, in particular.
3.3 Deficits in Engineering Software in Cars
Today the engineering of software in cars is still in its infancy.
The quick increase of software and the traditional structures of the
car industry make it difficult for this old economy to adapt fast
enough to the quite different requirements of software-intensive
system, which cars become more and more.
Following its tradition to find its own proprietary solutions (see
[7]) the car industry developed to a large extent its own
approaches also in the software domain. It is amazing to see the
amount of proprietary technology in the software in cars. This
applies to operating system, communication protocols, tools,
architecture, in fact, basically to all aspects of software in cars. Of
course, automotive software engineering has its own domain
specific requirements (see below). Nevertheless the car industry
could have done much better by benefiting from existing
experiences and technology from other domains, in particular,
telecommunication and avionics.
Livecycle management of software in cars is in its early stage.
Many suppliers and even some OEMs are not even at CMM level
2. This is, in particular, a problem in a situation where the systems
are developed by distributed concurrent engineering and the
software is highly complex, multi-functional, distributed, real time
and safety critical.
Reuse of solutions (see [22]) from one car to the next is
insufficient and only done in a consequent way in some limited
areas. In many sub-domains the functionality from one car
generation to the next is only changed and enhanced by 10 %
while more than 90 % of the software is rewritten. The reason is a
low level, hardware specific implementation, which makes it
difficult to change, adopt, and port existing code.
Finally, the amount of automation in software production for
software in cars is quite low. Tools are only used in an isolated
manner. There is neither a properly defined design flow nor
seamless tool chains for distributed functions.
4. The Domain Profile
Traditionally the car industry is highly vertically organized. In
software engineering we would say it is modular. The mechanical
engineers worked hard for over 100 years to make the various
sub-systems in cars in their development and production quite
independent. This facilitates independent development and
production of the sub-parts and allows for an enormous division
of labor.
As a result, suppliers could take over a considerable part of the
engineering, the development, and also the production by a
consequent outsourcing. Ideally, the parts of cars are produced by
a chain of suppliers and more or less only assembled by the car
manufacturer (called OEM in the following). Thus, a large
amount of the engineering and production is outsourced and the
cost and risk distribution can be optimized. A car is (or better
was) considered as a kit of subparts that are assembled by the
OEM.
With software becoming a major force of innovation the situation
changed drastically:
• Traditionally quite unrelated and independent functions
(such as braking, steering, or controlling the engine) that
were freely controlled by the driver get related and start to
interact. The car turns from an assembled device into an
integrated system. Phenomena like unintentional feature
interaction become issues.
• Assembling sub-parts becomes system integration.
• The behavior of cars becomes much more programmable.
Certain properties, such as comfort or sportive handling are
no longer solely determined the mechanics but also by the
software.
• The costs of cars get more and more influenced by
development costs of software, for which the traditional cost
models dominated by the cost by part paradigm are no
longer fully valid.
Size and structure of the embedded software/hardware systems in
cars are enormous. The application software is built on top of real
time operating systems and bus drivers. Most of the software is
hard real time critical or at least soft real time critical.
The requirements for the software systems in cars are quite
specific:
• wide range of different users (drivers and passengers, but
also maintenance)
34
• specific maintenance situation
• safety critical functions
• specific context of operation of the systems
• heterogeneity of functions (from embedded real time control
to infotainment, from comfort functions like air condition to
driver assistance, from energy management to software
download (flash) functionality, from air bags to on board
diagnosis and error logging).
As a result the complexity and spectrum of requirements for on
board software is enormous.
5. THE FUTURE
The increase of software and functionality in cars is not close to
an end, in the contrary. We can expect a substantial growth in the
future. The future development is driven by the following trends:
• high demand of new innovative or improved functionality
• quickly changing platforms and system infrastructures
• rapid increase in development cost in spite of a heavy cost
pressure
• demand for higher quality and reliability
• shorter time-to-market
• increased individualization
As a result there is a high demand for dedicated research on
software and systems engineering.
5.1 Innovation in Functionality
Software will remain the innovation driver in cars for the next two
decades. We will see many new software-based functions in cars
in the future. Each new software based function that comes into
the cars enables several further features. This accelerates the
development.
5.1.1 Crash Prevention, Crash Safety
Already today the safety standards in cars are very high. The rates
of people seriously injured or killed in their cars in accidents are
decreasing in spite of increased traffic. Statistically, software in
cars helped impressively to prevent accidents and many severe
injuries in accidents. Nevertheless, the systems are far from being
perfect by now. New generations of crash prevention, pre-crash,
and crash mitigating functions are in preparation.
5.1.2 Advanced Energy Management
Hybrid cars are just at their beginning. In future cars we can
expect a technical infrastructure that takes care of many in-car
issues like energy consumption, car calibration, and management
of the electric energy available.
5.1.3 Advanced Driver Assistance
The complexity of the software systems in cars for their drivers,
passengers, but also for maintenance is too high. What can help is
various driver assistance functions at all levels, supporting
instantaneous driver reactions but also providing short term
driving assistance in, for instance, lane departure or tour planning.
5.1.4 Adaptable MMI
What seem less far in the future are integrated seamless adaptive
MMI (Man Machine Interface) systems in cars. Cars get more
complex also due to software – but they get safer due to that
software and they get more convenient. But to get an easy access
to this convenience we have to offer those functions to drivers and
passengers in a way where they do not have to operate all this
complexity explicitly. Adaptive context aware assistance systems
which grasp the situations and are able to react within a wide
range without too much explicit interaction by the driver or the
passengers can lead to a new quality of MMIs.
5.1.5 The Programmable Car
Equipped with various actuators and sensors, as premium cars are
today, we get already close to a point where we can purely by
programming, by introducing new software, create new functions
for cars. This comes close to the vision of the programmable car.
5.1.6 Personalization and Individualization
A promising issue is personalization and individualization of cars.
Drivers are quite different. When cars get more and more
complex, of course, it is crucial to adapt the ways cars have to be
operated to the individual demands and expectations of the users.
5.1.7 Interconnection Car Networking
Another notable line of innovation is the networking of on-board
and off-board systems. Using wireless connections, in particular
peer-to-peer solutions, we can connect cars, which gives many
possibilities to improve safety issues in the traffic or to find new
solutions in the coordination of traffic far beyond the classical
road signs of today. For instance, in the long-term future when we
can imagine that all road signs are complemented by digital
signals between the cars, we can have a completely different way
of coordinating traffic.
5.2 Cost Reduction
The software costs in car increase enormously. These are not only
pure development costs. Sometimes even more significant are
maintenance costs and especially warranty costs.
5.3 Innovative Architectures
The car of the future will certainly have much less ECUs in favor
of more centralized multi-functional multipurpose hardware, less
communication lines and less dedicated sensors and actuators.
Arriving today at more than 70 ECUs in a car, the further
development will rather go back to a small number of ECUs by
keeping only a few dedicated ECUs for highly critical functions
and combining other functions into a small number of ECUs,
which then would be rather not special purpose ECUs, but very
close to general-purpose processors. Such a radically changed
hardware would allow for quite different techniques and
methodologies in software engineering.
6. CHALLENGES
Software issues hit the car industry in a dramatic way. In a time of
only 30 years the amount of software related development
activities went from 0 to 30 or even 40 %. If we assume that an
engineer works about 35 to 40 years in industry, it is obvious that
the companies where not able to gather sufficient competencies
quickly enough. A second problem is that there are not enough
software engineers educated by the universities in the skills
needed in the embedded and especially the automotive domain.
The high intensity of software in cars puts the car industry under
stress and a high change pressure. The reasons are manifold. First
35
of all, an important issue is the dependencies between the
different functions in the car leading to all kinds of wanted or
unwanted feature interactions.
This is quite different from what the automotive industry was used
to before software came into the cars. Over a hundred years the
car industry managed to make their different functionality as
independent as possible such that cars could be developed and
produced in a highly modular way. With the coming up of
software-based functions in the cars these independence
disappeared. Today a car has to be understood much more as a
complex system where all the functions act together. So software
engineering in cars needs to take a very massive step into systems
engineering.
[attachment=24680]
ABSTRACT
The amount of software in cars grows exponentially. Driving
forces of this development are cheaper and more powerful
hardware and the demand for innovations by new functions. The
rapid increase of software and software based functionality brings
various challenges (see [21], [23], [25], [26]) for the automotive
industries, for their organization, key competencies, processes,
methods, tools, models, product structures, division of work,
logistics, maintenance, and long term strategies. From a software
engineering perspective, the automotive industry is an ideal and
fascinating application domain for advanced techniques. Although
the automotive industry may adopt general results and solutions
from the software engineering body of knowledge gained in other
domains, the specific constraints and domain specific
requirements in the automotive industry ask for individual
solutions and bring various challenges for automotive software
engineering. In cars we find literally all interesting problems and
challenging issues of software and systems engineering.
Categories and Subject Descriptors
D.2 [Software Engineering]: D.2.1 Requirements/Specifications
(D.3.1), D.2.2 Design Tools and Techniques, D.2.10 Design
(D.2.2), D.2.11 Software Architectures
General Terms
Design, Economics, Reliability, Experimentation, Human Factors,
Standardization
Keywords
Automotive Software Engineering, Model Driven Development,
Embedded Systems
1. INTRODUCTION
In many technical products, software plays a dominant role today.
In cars, this applies even to the extreme. Today software in cars is
a dominant factor for the car industry, bringing various problems
but being nevertheless decisive for competition.
One can easily see that the amount of software in cars has been
growing exponentially over the last 30 years, and one can expect
this trend to continue for another 20 years at least.
The first software found its way into cars only at a time about
thirty years ago – so software grew in only more or less four
generations of cars. From one generation to the next, the software
amount was growing by a factor of ten, or even more. Today we
find in premium cars more than ten million lines of code and we
expect to find in the next generation ten times more.
Many new innovative functions in cars are enabled and driven by
software. Recent issues are energy management and the current
step into hybrid solutions, which can only be realized in an
economic way by plenty of software. It is mainly the application
domain specific innovations with their stronger dependencies and
feature interactions that ask for cross application domain
organizations.
In the following, we shortly describe the history of software in
cars as far as it is relevant to understand the current challenges.
Then we sketch the state of practice with its problems, challenges,
and opportunities. Based on a short estimation of the future
development we describe our expectation how the field will
develop. Finally we describe current research in the domain of
automotive software engineering (see also [14]).
2. The History
Just 30 year ago, software was first deployed into cars to control
the engine and, in particular, the ignition.
The first software-based solutions were very local, isolated and
unrelated. The hardware/software systems were growing bottom
up. This determined the basic architecture in cars with their
dedicated controllers (Electronic Control Units or ECUs) for the
different tasks as well as dedicated sensors and actuators. Over the
time to optimize wiring, bus systems (see [29]) were deployed
into the cars by which the ECUs became connected with the
sensors, and actuators.
Given such an infrastructure, ECUs got connected, too, and could
exchange information. As a result the car industry started to
introduce functions that were realized distributed over several
ECUs connected by the bus systems. Such functions were built
bottom up. A systematic top down design was never used. If we
would not go in evolutionary steps but re-design the
hardware/software systems in cars from scratch today, we would
certainly come up with a quite different solution.
3. State of Practice
Today premium cars feature not less than 70 ECUs connected by
more than 5 different bus systems. Up to 40 % of the production
costs of a car are due to electronics and software.
3.1 The Role of Software in Cars
Within only 30 years the amount of software in cars went from 0
to more than 10.000.000 lines of code. More than 2000 individual
functions are realized or controlled by software in premium cars,
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
ICSE’06, May 20-28, 2006, Shanghai, China.
Copyright 2006 ACM 1-59593-085-X/06/0005...$5.00.
33
today. 50–70% of the development costs of the software/hardware
systems are software costs. For a view on the network in a car see
Figure 1.
Software as well as hardware became enabling technologies in
cars. They enable new features and functionalities. Hardware is
becoming more and more a commodity – as seen by the price
decay for ECUs – while software determines the functionality and
therefore becomes the dominant factor.
3.2 Embedded Software as Innovation Driver
Software is today the most crucial innovation driver for technical
systems, in general. By software we realize innovative functions,
we find new ways of implementing known functions with reduced
costs, less weight or higher quality, we save energy and, what is,
in particular, important, we combine functions and correlate them
into multi-functional systems.
Figure 1. Onboard Network
This way software allows for completely new solutions of, in
principle, known tasks. What has been said here for embedded
systems, in general, applies to cars, in particular.
3.3 Deficits in Engineering Software in Cars
Today the engineering of software in cars is still in its infancy.
The quick increase of software and the traditional structures of the
car industry make it difficult for this old economy to adapt fast
enough to the quite different requirements of software-intensive
system, which cars become more and more.
Following its tradition to find its own proprietary solutions (see
[7]) the car industry developed to a large extent its own
approaches also in the software domain. It is amazing to see the
amount of proprietary technology in the software in cars. This
applies to operating system, communication protocols, tools,
architecture, in fact, basically to all aspects of software in cars. Of
course, automotive software engineering has its own domain
specific requirements (see below). Nevertheless the car industry
could have done much better by benefiting from existing
experiences and technology from other domains, in particular,
telecommunication and avionics.
Livecycle management of software in cars is in its early stage.
Many suppliers and even some OEMs are not even at CMM level
2. This is, in particular, a problem in a situation where the systems
are developed by distributed concurrent engineering and the
software is highly complex, multi-functional, distributed, real time
and safety critical.
Reuse of solutions (see [22]) from one car to the next is
insufficient and only done in a consequent way in some limited
areas. In many sub-domains the functionality from one car
generation to the next is only changed and enhanced by 10 %
while more than 90 % of the software is rewritten. The reason is a
low level, hardware specific implementation, which makes it
difficult to change, adopt, and port existing code.
Finally, the amount of automation in software production for
software in cars is quite low. Tools are only used in an isolated
manner. There is neither a properly defined design flow nor
seamless tool chains for distributed functions.
4. The Domain Profile
Traditionally the car industry is highly vertically organized. In
software engineering we would say it is modular. The mechanical
engineers worked hard for over 100 years to make the various
sub-systems in cars in their development and production quite
independent. This facilitates independent development and
production of the sub-parts and allows for an enormous division
of labor.
As a result, suppliers could take over a considerable part of the
engineering, the development, and also the production by a
consequent outsourcing. Ideally, the parts of cars are produced by
a chain of suppliers and more or less only assembled by the car
manufacturer (called OEM in the following). Thus, a large
amount of the engineering and production is outsourced and the
cost and risk distribution can be optimized. A car is (or better
was) considered as a kit of subparts that are assembled by the
OEM.
With software becoming a major force of innovation the situation
changed drastically:
• Traditionally quite unrelated and independent functions
(such as braking, steering, or controlling the engine) that
were freely controlled by the driver get related and start to
interact. The car turns from an assembled device into an
integrated system. Phenomena like unintentional feature
interaction become issues.
• Assembling sub-parts becomes system integration.
• The behavior of cars becomes much more programmable.
Certain properties, such as comfort or sportive handling are
no longer solely determined the mechanics but also by the
software.
• The costs of cars get more and more influenced by
development costs of software, for which the traditional cost
models dominated by the cost by part paradigm are no
longer fully valid.
Size and structure of the embedded software/hardware systems in
cars are enormous. The application software is built on top of real
time operating systems and bus drivers. Most of the software is
hard real time critical or at least soft real time critical.
The requirements for the software systems in cars are quite
specific:
• wide range of different users (drivers and passengers, but
also maintenance)
34
• specific maintenance situation
• safety critical functions
• specific context of operation of the systems
• heterogeneity of functions (from embedded real time control
to infotainment, from comfort functions like air condition to
driver assistance, from energy management to software
download (flash) functionality, from air bags to on board
diagnosis and error logging).
As a result the complexity and spectrum of requirements for on
board software is enormous.
5. THE FUTURE
The increase of software and functionality in cars is not close to
an end, in the contrary. We can expect a substantial growth in the
future. The future development is driven by the following trends:
• high demand of new innovative or improved functionality
• quickly changing platforms and system infrastructures
• rapid increase in development cost in spite of a heavy cost
pressure
• demand for higher quality and reliability
• shorter time-to-market
• increased individualization
As a result there is a high demand for dedicated research on
software and systems engineering.
5.1 Innovation in Functionality
Software will remain the innovation driver in cars for the next two
decades. We will see many new software-based functions in cars
in the future. Each new software based function that comes into
the cars enables several further features. This accelerates the
development.
5.1.1 Crash Prevention, Crash Safety
Already today the safety standards in cars are very high. The rates
of people seriously injured or killed in their cars in accidents are
decreasing in spite of increased traffic. Statistically, software in
cars helped impressively to prevent accidents and many severe
injuries in accidents. Nevertheless, the systems are far from being
perfect by now. New generations of crash prevention, pre-crash,
and crash mitigating functions are in preparation.
5.1.2 Advanced Energy Management
Hybrid cars are just at their beginning. In future cars we can
expect a technical infrastructure that takes care of many in-car
issues like energy consumption, car calibration, and management
of the electric energy available.
5.1.3 Advanced Driver Assistance
The complexity of the software systems in cars for their drivers,
passengers, but also for maintenance is too high. What can help is
various driver assistance functions at all levels, supporting
instantaneous driver reactions but also providing short term
driving assistance in, for instance, lane departure or tour planning.
5.1.4 Adaptable MMI
What seem less far in the future are integrated seamless adaptive
MMI (Man Machine Interface) systems in cars. Cars get more
complex also due to software – but they get safer due to that
software and they get more convenient. But to get an easy access
to this convenience we have to offer those functions to drivers and
passengers in a way where they do not have to operate all this
complexity explicitly. Adaptive context aware assistance systems
which grasp the situations and are able to react within a wide
range without too much explicit interaction by the driver or the
passengers can lead to a new quality of MMIs.
5.1.5 The Programmable Car
Equipped with various actuators and sensors, as premium cars are
today, we get already close to a point where we can purely by
programming, by introducing new software, create new functions
for cars. This comes close to the vision of the programmable car.
5.1.6 Personalization and Individualization
A promising issue is personalization and individualization of cars.
Drivers are quite different. When cars get more and more
complex, of course, it is crucial to adapt the ways cars have to be
operated to the individual demands and expectations of the users.
5.1.7 Interconnection Car Networking
Another notable line of innovation is the networking of on-board
and off-board systems. Using wireless connections, in particular
peer-to-peer solutions, we can connect cars, which gives many
possibilities to improve safety issues in the traffic or to find new
solutions in the coordination of traffic far beyond the classical
road signs of today. For instance, in the long-term future when we
can imagine that all road signs are complemented by digital
signals between the cars, we can have a completely different way
of coordinating traffic.
5.2 Cost Reduction
The software costs in car increase enormously. These are not only
pure development costs. Sometimes even more significant are
maintenance costs and especially warranty costs.
5.3 Innovative Architectures
The car of the future will certainly have much less ECUs in favor
of more centralized multi-functional multipurpose hardware, less
communication lines and less dedicated sensors and actuators.
Arriving today at more than 70 ECUs in a car, the further
development will rather go back to a small number of ECUs by
keeping only a few dedicated ECUs for highly critical functions
and combining other functions into a small number of ECUs,
which then would be rather not special purpose ECUs, but very
close to general-purpose processors. Such a radically changed
hardware would allow for quite different techniques and
methodologies in software engineering.
6. CHALLENGES
Software issues hit the car industry in a dramatic way. In a time of
only 30 years the amount of software related development
activities went from 0 to 30 or even 40 %. If we assume that an
engineer works about 35 to 40 years in industry, it is obvious that
the companies where not able to gather sufficient competencies
quickly enough. A second problem is that there are not enough
software engineers educated by the universities in the skills
needed in the embedded and especially the automotive domain.
The high intensity of software in cars puts the car industry under
stress and a high change pressure. The reasons are manifold. First
35
of all, an important issue is the dependencies between the
different functions in the car leading to all kinds of wanted or
unwanted feature interactions.
This is quite different from what the automotive industry was used
to before software came into the cars. Over a hundred years the
car industry managed to make their different functionality as
independent as possible such that cars could be developed and
produced in a highly modular way. With the coming up of
software-based functions in the cars these independence
disappeared. Today a car has to be understood much more as a
complex system where all the functions act together. So software
engineering in cars needs to take a very massive step into systems
engineering.