=Paper=
{{Paper
|id=Vol-3812/paper2
|storemode=property
|title=Challenges in Automotive Hardware-Software Co-Configuration
|pdfUrl=https://ceur-ws.org/Vol-3812/paper2.pdf
|volume=Vol-3812
|authors=Florian Jost,Carsten Sinz
|dblpUrl=https://dblp.org/rec/conf/confws/JostS24
}}
==Challenges in Automotive Hardware-Software Co-Configuration==
https://ceur-ws.org/Vol-3812/paper2.pdf
Challenges in Automotive Hardware-Software
Co-Configuration
Florian Jost1,* , Carsten Sinz2
1
Mercedes-Benz AG, Leibnitzstr. 2, Böblingen, 71032, Germany
2
Karlsruhe University of Applied Sciences, Moltkestraße 30, 76133 Karlsruhe, Germany
Abstract
Car manufacturers offer their customers an enormous number of configuration options to individualize their vehicles. While
configuration options mostly covered physical components in the past, over the last years the number of software-related
options has increased immensely. Existing systems for car configuration should thus be optimized and extended to handle
the shift towards more software-related features, e.g. for automatic driver assistance systems. In this article, we highlight
different problems and properties combined systems of hardware-software configurations have to tackle in an automotive
context.
Keywords
Automotive Configuration, Hardware-Software Co-Configuration, Future Challenges
1. Introduction 2. State of the Art
Modern car manufacturers offer a vast number of config- Classically, the possible configurations through which
uration options for their products. In the past, these op- a car can be realized are represented by configuration
tions covered parts and functionality that were primarily options. In addition to different color finishes, these can
based on physical components. With the ongoing elec- also describe different engine designs, or optional extras
trification of cars, the rate of functionality implemented such as an improved infotainment system. An existing
in software and thus also the variance in software is in- order, i.e. a set of configuration options, can then be
creasing [1]. translated into the physical parts that are needed to man-
ufacture the particular car instance.
But not only the number of configuration options is in-
creasing, the same holds for the complexity of their in- Historically, with the increasing emergence of software
terdependencies. Some options are mutually dependent, functionality and the associated ECUs (electronic con-
others are mutually exclusive. This results in an enor- trol units) in the car, the existing hardware configuration
mous configuration space with more than 10100 possible systems were adapted to also manage software config-
constructable (valid) configurations for a product line urations. But, as automotive software can have a wide
[2]. The inherent complexity of the problem challenges variety of requirements for the installed hardware (e.g.
automotive manufactures in all stages of the product life- sensors for autonomous driving systems), software con-
cycle, from development, through production, sales to figuration cannot be treated independent of the hardware
after-sales. Due to the increasing importance of software configuration. However, this close connection is often
in this context, hardware-software co-configurations are not reflected in current configuration systems, where
playing an increasingly substantial role. mostly software configuration is treated as a second con-
figuration step, after the physical components have been
In this publication, we describe upcoming or already ex- selected and configured.
isting problems that arise in the context of increasingly
software-driven vehicles. Additionally, software often comes with configurable
parameters that can be set to different values. As an ex-
ample, emergency call numbers differ from country to
country and have to be set accordingly. The basic func-
tionality of the software remains the same, independent
ConfWS’24: 26th International Workshop on Configuration, Sep 2–3, of the value the parameter is set to. Thus, instead of writ-
2024, Girona, Spain ing software for each possible parameter setting, an ECU
*
Corresponding author. runs through an additional configuration step, where
$ florian_benedikt.jost@mercedes-benz.com (F. Jost);
correct parameter values are written to the ECU (special
carsten.sinz@h-ka.de (C. Sinz)
0009-0006-9670-8856 (F. Jost); 0000-0001-9718-1802 (C. Sinz) bits get set in the programmable ROM of the ECU). The
© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License high-level software then can adapt its functionality by
Attribution 4.0 International (CC BY 4.0).
CEUR
CEUR Workshop Proceedings (CEUR-WS.org)
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
reading the corresponding bits in the ROM. In the au-
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
tomotive sector, this configuration step is often called of hardware components. This can occur as follows: In a
variant coding [3]. revision of an existing car series, the hardware is slightly
modified and a new software function becomes available.
Typically, in the automotive industry, configuration op-
Now, this software function could potentially also be
tions are realized through Boolean variables, so-called
provided in the older model, if the necessary hardware
codes, where each code is represented by a variable name
can be retrofitted. Checking whether such an update is
a.k.a. identifier. An option selected by a customer is then
possible (and which parts have to be exchanged) requires
reflected by setting the corresponding code to true. Be-
access to the exact configuration of the delivered car as
sides codes to register customer’s selections, internal
well as configuration systems that have knowledge about
codes are used, for example, there can be codes repre-
constraints for historic configurations, possibly going
senting spatial regions and codes indicating if the car
back to several years or even decades.
possesses left or right steering.
The set of valid configurations is described by a set of
Boolean formulas (rules, constraints) that all have to be OTA Update. Over-the-air (OTA) software updates
satisfied in a valid order. Such constraints can express, present unique challenges for automotive manufacturers.
e.g., mutual exclusivity, as in the selection of left-hand Firstly, the vehicle’s software configuration must be fully
or right-hand steering. But often constraints are much defined in both hardware and software terms, ensuring
more evolved, encompassing many dozens of codes. that only compatible software satisfying all dependencies
is delivered to the vehicle. Additionally, the delivered
Example: software must be correctly configured through variant
𝑐1 → ¬𝑐2 ∧ ¬𝑐3 coding, based on the underlying hardware configuration.
with codes 𝑐1 , 𝑐2 , 𝑐3 . In other words, if we select code Therefore, a combined consideration of hardware and
𝑐1 , codes 𝑐2 and 𝑐3 cannot be selected. software is highly important
Handling of parameters is mostly done in separate
Missing Expert. Up to day, software updates are still
systems, where valid values (or sometimes even valid
performed in repair shops by an expert. Manufacturers
combinations of values) are specified via tables listing
profit in this context from the expertise of the working
the admissible settings.
staff. Occurring errors can instantly be analyzed by a
qualified person. In the best case, the underlying error
3. Challenges can be directly fixed by the repair shop staff. Especially
in the case of OTA updates, this expertise is missing. In
Since software has become central in modern cars, the particular, problem analysis and troubleshooting pose
question arises whether existing systems, into which the a special challenge, as they all have to be done before
software configuration is mostly just cobbled in, still meet delivery of the update or – for residual errors – must be
all the necessary or desired requirements. fixable remotely, in the worst case by a downgrade to the
Until today, the configuration process is still mostly previous version.
divided into two steps. First the hardware configuration,
then – on top of it – the software configuration. However, Certification. The automotive sector is highly stan-
it is questionable whether this two-step process is still dardized and regulated. Automotive manufacturers must
the best approach for existing and future use-cases. guarantee that their products satisfy all kinds of stan-
In this section, we present various challenges that dards from different domains. The regulations classically
prevail in current hardware-centric configuration sys- certify a vehicle to satisfy predefined security and safety
tems and might require additional consideration in future standards. With the increasing use of driver assistant
hardware-software co-configuration systems. systems in the automotive sector, the certification re-
quirements, especially in software, grow. In particular,
Hardware Upgrade. Automotive manufactures re- lawmakers want to know in the future exactly which soft-
cently started to offer subscription models for features ware is delivered in which car. An example is the UN ECE
1
that are not present at the time of sale, but can be regulation 156, describing the requirements for a soft-
retrofitted – often by a simple software switch – into ware update management system (SUMS) and the future
already delivered vehicles. For this, the manufacturers scope for type approval procedures under consideration
need the possibility to enable functions for vehicles in the of the software.
field. Typically, this also requires a check, whether the
hardware of the car supports the extended functionality.
It might even be the case that an OEM (Original Equip-
1
ment Manufacturer) allows a retrofit including an update https://unece.org/transport/documents/2021/03/standards/un-reg
ulation-no-156-software-update-and-software-update
Frequent Updates. Software updates can be much software has additional constraints. In addition to the
more frequent than hardware revisions. As software is hardware dependency, there are also complex parame-
in an increasing manner not only security but also safety terizations (variant coding) and the need for diagnostic
relevant, software updates may have the need to be rolled options. This raises the question of how to define soft-
out quickly. However, as software changes can impact ware components or packages in order to be able to adopt
other components of the vehicle, an automatic validity existing concepts.
and conformity check of the target vehicle configuration
is required. In the best case, after a fix in an existing
software package, a package manager should compute a 4. Related Work
new valid configuration, including the fixed software.
How to handle hardware/software configurations in the
automotive sector has been an active point of research
Vehicle function distribution. The distribution of and discussion for several years now [4, 5]. In a survey
functions in a vehicle and their mapping to ECUs is still of German car manufacturers, Sax et al. [6] claim that
done mostly manually. However, with the rapidly chang- new ways of checking the consistency of major, regular
ing software architectures in vehicles, the distribution software updates is an important aspect for not hindering
is getting more and more complex. To simplify the ini- fast development of new functions in the future.
tial process in development, algorithmic support is an
obvious solution. This requires a detailed specification The configuration problem in the automotive industry
and documentation of dependencies of the software to and solutions to it were already described in the early
be distributed. This initial distribution, we call it static 2000s. Sinz [7] describes a rule system based on Boolean
vehicle function distribution, can also be extended to the logic. Here, not only checking individual configurations
dynamic case, in which functions can be (re-)distributed is covered, but also ways to determine common proper-
in real-time to corresponding computing nodes. This ties of all valid configurations. Moreover, the mapping
allows an improved energy usage, as ECUs can be turned from code sets into concrete physical components is also
off and on if needed – complex algorithms might even considered. In a later publication, Sinz [8] also describes
be run in the cloud. For both use cases, a complete de- the verification of such rule systems in order to detect
scription of the hardware and software dependencies is and minimize errors at an early stage. Astesana et al. [9]
required. on the other hand, describe vehicle configurations by us-
ing a CSP framework, with Renault as a case study. More
Version Constraints. For software configurations, the recent publications also deal with the topic of classic
specific version of a software package and its dependen- configurations. Bischoff et al. [10] describes a graphical
cies are vital information. In a major software release, editor for visualizing and editing item selection rules.
dependencies might change drastically, reflecting the In addition to the control systems mentioned above, there
changed and extended behavior of the software. How- are other approaches to describing variability in general.
ever, version constraints are mostly documented in a One of them is feature modeling. In this, the configura-
numeric way, e.g. via Semantic Versioning.2 Whether tion options (features) are often represented in the form
the currently employed Boolean formalization of con- of trees, which represent the relations between the fea-
straints is still the best way to address the problem is tures. The analysis of feature models is often performed
questionable. with the use of SAT solvers [11]. However, analysis ap-
proaches using SMT solvers have also been part of recent
Variance over time. If software updates can still be research [12].
carried out for older vehicles, new functionalities can also
be integrated into existing fleets if technically feasible. In the area of classic computer systems, configurations
Determining which vehicle configurations can still be are often found in the area of package management
supplied with new software, as well as documenting and and dependency solving. These are mostly so-called
verifying this, is a major challenge given the enormous component-based systems such as GNU/Linux distribu-
space of possible configurations. Enabling this variance tions (e.g. Debian 3 ). These contain metadata for software
over larger timeframes will require new mechanisms and packages, which the package managers utilize in their
considerations. search for valid configurations. While most package man-
agers initially used ad-hoc solvers [13], nowadays more
efficient algorithms from the SAT or CSP community are
Software Packaging. In classic computer systems,
usually employed [14]. Pinckney et al. [15] recently pro-
software configuration problems are often solved with
posed a package solver, PacSolve, for NPM which uses
the help of package managers. However, automotive
2 3
https://semver.org https://www.debian.org
an SMT approach instead of SAT/CSP solvers. As an our-insights/rethinking-car-software-and-electro
alternative to SAT and SMT, there are also publications nics-architecture.
that describe and solve package update problems with [6] E. Sax, R. Reussner, H. Guissouma, H. Klare, A Sur-
Answer Set Programming [16, 17]. vey on the State and Future of Automotive Software
Release and Configuration Management, Technical
The distribution of different functions in the architecture
Report 11, Karlsruher Institut für Technologie (KIT),
of a vehicle represents an enormous challenge in mod-
2017.
ern vehicles. Ruhnau et al. [18] take a first step towards
[7] C. Sinz, Baubarkeitsprüfung von Kraftfahrzeugen
mastering this challenge by describing an ontology for
durch automatisches Beweisen, Diplomarbeit, Uni-
function distribution, covering both static and dynamic
versität Tübingen, 1997.
distribution.
[8] C. Sinz, Verifikation regelbasierter Konfigura-
tionssysteme, Ph.D. thesis, Universität Tübingen,
5. Conclusion Tübingen, Germany, 2003.
[9] J.-M. Astesana, L. Cosserat, H. Fargier, Constraint-
In this paper, we have described various challenges that based vehicle configuration: A case study, in: 2010
exist in the area of hardware/software configurations in 22nd IEEE International Conference on Tools with
the automotive sector. Many of these challenges arise Artificial Intelligence, 2010, pp. 68–75.
from the increasing complexity and relevance of software [10] D. Bischoff, W. Küchlin, O. Kopp, Poseidon: A
in vehicles. We have listed that research work already ex- graphical editor for item selection rules within fea-
ists for some of the topics. For others, there are promising ture combination rule contexts, in: PLM in Transi-
approaches from related problem areas, the suitability of tion Times, Springer, Cham, 2023, pp. 3–14.
which we will investigate in more detail in future work. [11] D. Benavides, S. Segura, A. Ruiz-Cortés, Automated
analysis of feature models 20 years later: A litera-
ture review, Information Systems 35 (2010) 615–636.
Acknowledgments [12] J. Sprey, C. Sundermann, S. Krieter, M. Nieke,
J. Mauro, T. Thüm, I. Schaefer, SMT-based vari-
The research presented in this paper was done in the con-
ability analyses in FeatureIDE, in: Proceedings of
text of the SofDCar (19S21002) project, which is founded
the 14th International Working Conference on Vari-
by the German Federal Ministry for Economic Affairs
ability Modelling of Software-Intensive Systems,
and Climate Action.
ACM, 2020.
[13] P. Abate, R. D. Cosmo, R. Treinen, S. Zacchiroli, A
References modular package manager architecture, Informa-
tion and Software Technology 55 (2013) 459–474.
[1] C. Fehling, M. Frank, O. Kopp, Digital sustainability [14] P. Abate, R. D. Cosmo, G. Gousios, S. Zacchiroli,
and digital diversification: The two key challenges Dependency solving is still hard, but we are getting
for automotive software development, in: IEEE better at it, in: 27th Intl. Conf. Software Analysis,
18th Intl. Conf. Software Architecture Companion Evolution and Reengineering (SANER), IEEE, 2020.
(ICSA-C), 2021, pp. 162–166. [15] D. Pinckney, F. Cassano, A. Guha, J. Bell, M. Culpo,
[2] A. Kübler, C. Zengler, W. Küchlin, Model counting T. Gamblin, Flexible and optimal dependency man-
in product configuration, in: Proc. of the 1st Intl. agement via Max-SMT, in: 45th Intl. Conf. Software
Workshop on Logics for Component Configuration, Engineering (ICSE), 2023, pp. 1418–1429.
LoCoCo 2010, Edinburgh, UK, 2010, pp. 44–53. [16] M. Gebser, R. Kaminski, T. Schaub, aspcud: A linux
[3] H. Takimizu, T. Fukaya, Y. Ito, N. Sakano, ECU package configuration tool based on answer set pro-
variant coding system, Mitsubishi Motors Technical gramming, Electronic Proceedings in Theoretical
Review 18 (2006). Computer Science 65 (2011) 12–25.
[4] O. Media, Effective hardware-software co-design [17] T. Gamblin, M. Culpo, G. Becker, S. Shudler, Us-
for automotive systems, 2014. URL: https://embedd ing answer set programming for HPC dependency
edcomputing.com/application/automotive/effect solving, in: Proc. Intl. Conf. on High Performance
ive-hardware-software-co-design-for-automotiv Computing, Networking, Storage and Analysis, SC
e-systems. ’22, IEEE Press, 2022.
[5] O. Burkacky, J. Deichmann, G. Doll, C. Knochen- [18] J. Ruhnau, M. Sommer, J. Henle, A. Walz, S. Becker,
hauer, Effective hardware-software co-design for E. Sax, Ontology for vehicle function distribution,
automotive systems, 2018. URL: https://www.mcki in: IEEE Intl. Systems Conf. (SysCon), Vancouver,
nsey.com/industries/automotive-and-assembly/ Canada, 17-20 April 2023, IEEE, 2023, p. 1–6.