Car manufacturers ofer 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 diferent problems and properties combined systems of hardware-software configurations have to tackle in an automotive context.
Modern car manufacturers ofer 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 diferent color finishes, these can based on physical components. With the ongoing elec- also describe diferent 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 manufacture the particular car instance.
But not only the number of configuration options is increasing, 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 conothers 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 configconstructable (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 concycle, from development, through production, sales to ifguration 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 conifguration step, after the physical components have been selected and configured.
isting problems that arise in the context of increasingly software-driven vehicles. tomotive sector, this configuration step is often called variant coding [3].
Typically, in the automotive industry, configuration options are realized through Boolean variables, so-called codes, where each code is represented by a variable name a.k.a. identifier. An option selected by a customer is then reflected by setting the corresponding code to true. Besides codes to register customer’s selections, internal codes are used, for example, there can be codes representing spatial regions and codes indicating if the car 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 satisfied in a valid order. Such constraints can express, e.g., mutual exclusivity, as in the selection of left-hand or right-hand steering. But often constraints are much more evolved, encompassing many dozens of codes. Example:
1 → ¬2 ∧ ¬3 with codes 1, 2, 3. In other words, if we select code 1, codes 2 and 3 cannot be selected.
Handling of parameters is mostly done in separate systems, where valid values (or sometimes even valid combinations of values) are specified via tables listing the admissible settings.
of hardware components. This can occur as follows: In a revision of an existing car series, the hardware is slightly modified and a new software function becomes available. Now, this software function could potentially also be provided in the older model, if the necessary hardware can be retrofitted. Checking whether such an update is possible (and which parts have to be exchanged) requires access to the exact configuration of the delivered car as well as configuration systems that have knowledge about constraints for historic configurations, possibly going back to several years or even decades.
present unique challenges for automotive manufacturers. Firstly, the vehicle’s software configuration must be fully defined in both hardware and software terms, ensuring that only compatible software satisfying all dependencies is delivered to the vehicle. Additionally, the delivered software must be correctly configured through variant coding, based on the underlying hardware configuration. Therefore, a combined consideration of hardware and software is highly important Missing Expert. Up to day, software updates are still performed in repair shops by an expert. Manufacturers profit in this context from the expertise of the working staf. Occurring errors can instantly be analyzed by a qualified person. In the best case, the underlying error can be directly fixed by the repair shop staf. Especially in the case of OTA updates, this expertise is missing. In particular, problem analysis and troubleshooting pose a special challenge, as they all have to be done before delivery of the update or – for residual errors – must be ifxable remotely, in the worst case by a downgrade to the previous version.
question arises whether existing systems, into which the software configuration is mostly just cobbled in, still meet all the necessary or desired requirements.
Until today, the configuration process is still mostly divided into two steps. First the hardware configuration, then – on top of it – the software configuration. However, it is questionable whether this two-step process is still the best approach for existing and future use-cases.
In this section, we present various challenges that prevail in current hardware-centric configuration systems and might require additional consideration in future hardware-software co-configuration systems.
ulation-no-156-software-update-and-software-update Frequent Updates. Software updates can be much more frequent than hardware revisions. As software is in an increasing manner not only security but also safety relevant, software updates may have the need to be rolled out quickly. However, as software changes can impact other components of the vehicle, an automatic validity 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 new valid configuration, including the fixed software. software has additional constraints. In addition to the hardware dependency, there are also complex parameterizations (variant coding) and the need for diagnostic options. This raises the question of how to define software components or packages in order to be able to adopt existing concepts.
How to handle hardware/software configurations in the automotive sector has been an active point of research and discussion for several years now [4, 5]. In a survey of German car manufacturers, Sax et al. [6] claim that new ways of checking the consistency of major, regular software updates is an important aspect for not hindering fast development of new functions in the future.
Vehicle function distribution. The distribution of functions in a vehicle and their mapping to ECUs is still done mostly manually. However, with the rapidly changing software architectures in vehicles, the distribution is getting more and more complex. To simplify the initial 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 properin 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 of 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 using 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. Bischof 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 changed and extended behavior of the software. However, version constraints are mostly documented in a numeric way, e.g. via Semantic Versioning.2 Whether the currently employed Boolean formalization of constraints is still the best way to address the problem is questionable.
are other approaches to describing variability in general. One of them is feature modeling. In this, the configuration options (features) are often represented in the form of trees, which represent the relations between the features. The analysis of feature models is often performed with the use of SAT solvers [11]. However, analysis approaches using SMT solvers have also been part of recent research [12].
carried out for older vehicles, new functionalities can also be integrated into existing fleets if technically feasible. Determining which vehicle configurations can still be supplied with new software, as well as documenting and verifying this, is a major challenge given the enormous space of possible congfiurations. Enabling this variance over larger timeframes will require new mechanisms and considerations.
software configuration problems are often solved with the help of package managers. However, automotive
In the area of classic computer systems, configurations are often found in the area of package management and dependency solving. These are mostly so-called component-based systems such as GNU/Linux distributions (e.g. Debian 3). These contain metadata for software packages, which the package managers utilize in their search for valid configurations. While most package managers initially used ad-hoc solvers [13], nowadays more eficient algorithms from the SAT or CSP community are usually employed [14]. Pinckney et al. [15] recently proposed a package solver, PacSolve, for NPM which uses