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.