An Industry Survey on ECU Software Parameterization Processes in Variant-Rich Industries: Industrial Practices and Implications for the Automotive Industry

Abstract

In the automotive industry, the increasing number of vehicle variants necessitates the configuration of electronic control unit (ECU) software through parameterization. However, with the transition toward software-defined vehicles, autonomous driving, and growing regulatory demands, current approaches to parameter management and ECU parameterization have reached their limits. This raises the question of which methodologies for parameter management are applied in other variant-intensive industries, and to what extent the automotive sector can learn from them. To address this question, semi-structured interviews were conducted across several variant-rich industries to examine how parameter management in embedded systems is organized in their respective development processes. The study identified different practices, challenges, and methodologies, including the adoption of software product line engineering principles as a potential best practice. Nevertheless, the findings reveal that a direct transfer of methods from other industries to the automotive industry is not straightforward, as the automotive domain represents a unique combination of high production volumes, extensive variability, and substantial product complexity.

1. Introduction

The automotive industry is currently undergoing a fundamental transformation that can be described as a holistic evolution of the vehicle as a system [1,2]. Increasingly, customers demand a higher degree of individualization, an extended range of functionalities, and a more comprehensive integration of digital services [3,4]. Driven by these expectations, manufacturers have begun to reconceptualize the automobile. Vehicles are becoming software-driven and highly interconnected systems [3,5]. To enable this transformation, advancements in the electric/electronic (E/E) architecture are required, with particular emphasis on the role of electronic control units (ECUs) as central enablers of functionality [1,2,6].

The shift from hardware-centered to software-driven development is encapsulated in the concept of the software-defined vehicle (SDV). In this paradigm, the majority of vehicle functions are increasingly realized through software rather than hardware, thereby enabling continuous updates and functional expansion over the vehicle’s lifetime [1]. Modern vehicles contain up to 150 million lines of code [7,8]. Driven by advances in advanced driver assistance systems (ADAS), particularly in the field of autonomous driving, this number is expected to increase substantially in the near future. At the same time, the volume of data generated by vehicles themselves is growing, which further intensifies the requirements placed on automotive software.

The management of software variability, defined here as the ability to modify or customize a system [9,10,11], encompasses both configuration and parameterization activities. In the context of this paper, configuration refers to the selection and composition of software functionality and artifacts required to realize a specific product variant. Configuration therefore determines which functions, components, or datasets are included for a given variant. Parameterization, by contrast, denotes the assignment of concrete values to predefined parameters within an already configured software solution [12]. While configuration determines the structural composition of a software variant, parameterization specifies its detailed behavior.

With the advent of SDVs, the large production volumes of modern vehicles, and the associated proliferation of product configurations, the number of software parameterizations has risen dramatically. In this context, software variability increases at a faster rate than hardware variability.

This development, however, is not limited to the automotive sector. A wide range of industries today relies on embedded systems in which ECUs are responsible for managing diverse tasks. The functionality of these systems is largely implemented in software, which is characterized by a high degree of configurability and variability in order to meet heterogeneous customer requirements. As customer demands for individualization and diversity increase, the complexity of software systems grows accordingly. This trend renders the management of software variability an increasingly critical challenge. Managing large-scale software variability continues to pose a considerable challenge for companies across a wide range of industries [13,14].

Against this background, the central research question emerges: how do industries operating in highly variant-rich environments handle the parameterization of ECU software? While existing research on variability management has primarily focused on conceptual approaches and high-level modeling aspects, comparatively little attention has been paid to parameter-based variability and its practical realization in complex industrial environments. In particular, empirical insights into how companies manage ECU parameterization across different domains remain limited. To the best of our knowledge, no comprehensive cross-domain industry study has systematically examined and compared parameter management processes and ECU software parameterization practices across variant-rich industries.

Contribution: To address the identified research gap, this paper presents a cross-industry industrial study on ECU software parameterization and parameter management in variant-rich embedded systems. Based on semi-structured expert interviews conducted across multiple industries, the first contribution of this work is a systematic characterization of current parameterization practices and challenges, highlighting both common patterns and domain-specific differences.

Building on the empirical findings, the second contribution is the derivation of a structured, cross-case software parameterization maturity framework (SPMF) that captures the parameter management lifecycle along multiple dimensions. The framework enables a systematic comparison of industries with fundamentally different boundary conditions and reveals characteristic maturity profiles rather than isolated best practices.

As a third contribution, the paper applies the SPMF to the automotive domain and identifies structural improvement needs and underlying constraints that distinguish automotive parameter management from other industries. This analysis demonstrates that direct transfer of approaches is limited and that automotive challenges are rooted in specific combinations of large-scale variability, supplier integration, regulatory demands, and software lifecycle dynamics.

Finally, the study derives implications for future research and industrial practice by contextualizing software product line engineering (SPLE) as a potential, but constrained, conceptual reference. Rather than recommending generic adoption, the paper outlines where SPLE principles align with identified needs, where automotive-specific boundary conditions complicate their application, and which research directions emerge from these tensions.

Outline: The remainder of this paper is organized as follows. Section 2 provides background information on ECU parameterization and Section 3 includes a review of related work. Section 4 presents the methodology of our industrial study and explains its execution. Section 5 outlines the results of the study, answering the research questions and providing further insights. Section 6 discusses the findings, while Section 7 addresses threats to the validity of our research. Finally, Section 8 concludes the paper by summarizing the key insights.

2. Parameterization of ECUs

As already outlined in the introduction, the automotive industry is currently undergoing a profound transformation, away from traditional, predominantly hardware-oriented vehicle concepts towards modern, software-driven vehicles. However, this development is by no means limited to the automotive sector alone: numerous industries today rely on embedded systems, in which ECUs assume a variety of tasks and whose functionalities are largely implemented through software [15]. These software systems are characterized by a high degree of variability in order to meet diverse customer requirements. As a result, the complexity of these systems is continuously increasing, thereby turning the management of software variability into a growing challenge [16]. In embedded systems, functions are predominantly implemented through ECU software. Such software faces the challenge of representing a wide range of different functionalities and their variants. Due to the large number of required functions, the necessary flexibility and adaptability, as well as various dependencies between hardware and other system components, the complexity of this software is rapidly increasing. Additionally, software is subject to continuous changes over time, such as when new functionalities need to be integrated or existing ones deactivated.

To manage this complex issue, several solution approaches exist. A trivial approach would involve developing an individually tailored software solution for each embedded system. However, in this scenario, every modification or functional change would necessitate complete reprogramming. Given the large number of variants and a correspondingly extensive number of individual products, this approach is not only impractical but also economically unsustainable, as the associated development efforts and costs would be disproportionately high.

To address this challenge, the principle of ECU software parameterization is typically applied. Configuration elements, usually in the form of parameters, are deliberately embedded as placeholders within the source code during software development and are later assigned specific values [17]. In practice, a so-called software platform is commonly developed for this purpose. Such a platform inherently contains all necessary functionalities as well as all potential configurations and parameter values, which are then selectively reduced and specifically tailored through parameterization as required. This approach shifts complexity from programming itself toward the configuration elements. As a result, the development process can be significantly simplified, since changes or the creation of variants no longer necessitate complete rewriting of the software code, but rather adjustments to parameters only.

Against this backdrop, the practical implications of ECU software parameterization become particularly evident when considering established development processes, e.g., in the automotive industry. In this domain, software development typically follows the V-model, in which system design and implementation are structured as a sequential yet iterative process. Within this framework, ECU calibration is performed at a comparatively late stage [12], as illustrated in Figure 1.

At this point in the process, multiple integration and testing cycles take place, resulting in iterative feedback loops in which test results from the right-hand side of the V are fed back into earlier development phases on the left-hand side [18]. Consequently, any required modifications, especially those related to parameterization, may necessitate re-iterating substantial parts of the V-model. Due to the late positioning of calibration activities, such adjustments are associated with significant effort and cost, as large portions of the development process must effectively be revisited.

This challenge further highlights the importance of systematically managing parameters and their evolution. It also motivates the investigation of parameter management practices across different industries, with the aim of improving the predictability and traceability of calibration parameters in complex, software-intensive systems.

3. Related Work

A substantial body of research has addressed different aspects of software variability management in industrial contexts.

Berger et al. [19], for instance, investigate how variability is actually modeled in industrial contexts. Berger et al. [13] extend this analysis by presenting twelve industrial case studies, each examining different methodological approaches as well as key challenges encountered in industrial variant management. Complementing this work, Becker et al. [14] document results from expert discussions with practitioners and identify significant obstacles in adopting and applying SPLE. Despite a general willingness to implement SPLE, major barriers such as integrating legacy systems and coping with the increasing complexity and scale of variable systems are highlighted as substantial challenges.

A more domain-specific approach is taken by Fischer et al. [20], who examine variant management within the context of automated production systems (aPS). The findings indicate that variant and version management in this domain are rarely methodologically anchored. Instead, pragmatic approaches dominate, particularly clone-and-own strategies. Berger et al. [21] provide a more detailed perspective on feature modeling and conclude that feature models are primarily used to structure and document variability knowledge, but are rarely leveraged for automated configuration or systematic derivation of software variants.

While these studies provide valuable insights into how software variability is modeled and managed, they primarily focus on variability at a conceptual or feature level. What remains largely unexplored is the systematic investigation of ECU software parameterization processes, particularly how parameters are defined, assigned, and managed across variants and system configurations in industrial practice.

To the best of our knowledge, no existing study provides a comprehensive, cross-industry analysis of ECU parameterization processes that explicitly considers these aspects. This paper addresses this gap by investigating how parameters are managed in variant-rich industries and by deriving implications for improving variability management in the automotive context.

4. Research Approach

In order to understand how companies from various industries manage variant-related parameterization of ECU software and which challenges they encounter, we conducted an industrial study. The primary objective of this study was to answer the following three research questions:

• RQ1: How do different industries manage the parameterization of their ECU software and the associated parameter management, especially in the presence of significant variability?
• RQ2: What challenges do companies currently face in this context, and what challenges are expected to arise in the future?
• RQ3: Which concepts from other industries could be applied to address the challenges in the automotive domain, and how would these concepts need to be adapted?

To ensure the validity and reliability of our findings, we followed a rigorous methodological approach in planning and conducting the study. This approach is illustrated in Figure 2.

The industrial study was conducted through semi-structured expert interviews. To ensure methodological rigor and comparability, the design and execution of these interviews were aligned with the approach presented in Berger et al. [13], thereby building upon an established and validated research procedure. Additionally, we developed a questionnaire, an overview of which is provided in

Table 1. Questionnaire.

ID	Question	Section
1.1	Which industry or sector does your organization operate in?	Personal Information
1.2	What is your department and current position within the organization?
2.1	Please describe the variant diversity of your products. How many distinct product variants exist and what are the respective production volumes?	General Information
2.2	Do your products rely on a generic software solution, or do you deploy multiple software variants? How modular and flexible is the software architecture within your organization?
2.3	To what extent is the software configured? Are adaptations limited to enabling or disabling specific code sections, or are dedicated datasets (e.g., parameter values, characteristic curves/maps) also integrated?
2.4	What is the scale of the parameter space that must be considered in your variant management process?
3.1	Are parameters and product-specific datasets managed centrally? If so, where and within which systems are they maintained?	Parameter Management
3.2	Are modifications to parameters or datasets that are incorporated into the product traceable? How is this traceability represented or documented?
3.3	Are parameters directly linked to requirements, features, or similar artefacts? If so, how is this relationship established and maintained?
3.4	Are hierarchical structures applied to parameters, or are parameters organized according to a specific structural scheme?
4.1	To which entities are individual parameters assigned? What does the variant key represent (e.g., features, product characteristics, functions, or systems)?	Parameter Assignment and Selection
4.2	How are parameters and specific datasets selected and assigned to individual variants? Is this process manual, or is it supported by tools (e.g., configuration scripts, feature models, or configuration tables)?
4.3	How are the specific datasets created?
5.1	Are parameters or datasets verified to ensure compliance with defined specifications and requirements?	Testing, Validation, and Verification
5.2	Is the correctness of the relationships between parameters/datasets and their associated variants validated? For example, is it checked whether the correct parameters have been selected for a given variant?
6.1	How, and in which format, is the final parameterization (parameters and specific datasets) integrated into the product?	Release and Deployment
6.2	Is the release of the parameterization performed manually or automatically?
6.3	How do you verify the correct transfer of the parameterization into the product? Are specific testing procedures or tools employed to support this process?
7.1	What challenges do you currently encounter with your organization’s concept for variant-related parameter management?	Challenges and Future Developments
7.2	Which future requirements do you anticipate that may impact variant-related parameter management for your products?
7.3	What developments or adaptations to your current concept do you expect will be necessary to address these emerging requirements?

, which served as a structured guide throughout the interviews. The questionnaire was designed to cover all relevant work and process steps involved in ECU parameterization. Some questions are intended to capture specific technical aspects in detail, while others are open-ended, allowing participants to elaborate on their individual approaches and company-specific characteristics. This design enables a comprehensive understanding of both common practices and domain-specific variations in parameter management strategies.

4.1. Selection of Participating Companies and Expert Identification

The scope of eligible participating companies was deliberately restricted to organizations operating in variant-rich industries and employing parameter management approaches within ECU-based embedded systems. The products offered by these companies exhibit a pronounced degree of variability.

Against this backdrop, the study adopts a broad cross-industry perspective. The final sample comprises organizations from the following sectors: automotive (two companies), commercial vehicle suppliers (one company), commercial vehicles (two companies), mechanical engineering (two companies), rail vehicles and systems (one company), and aerospace (one company). This sampling strategy facilitates a comparative analysis of practices across industries that depend on ECU-centered embedded systems architectures.

Initial contact with companies was established through dedicated introductory meetings. These meetings were conducted iteratively and across multiple hierarchical levels within the organizations. During this process, suitable experts were identified for participation in the interviews. All selected experts possessed at least 10 years of professional experience in the field of ECU software parameterization.

The identified experts are listed in

Table 2. Context information of identified experts.

Industries	Number of Experts	Department and Current Position
Automotive	2	Software Architect—Software Version/Configuration Management Technical Specialist (Previously Manager)—System Configuration and Release Management
Commercial Vehicle Supplier	1	Director Program Body & Vehicle Control Units
Commercial Vehicles	2	Solution Manager Onboard/Offboard EV Systems Global Diagnostics Lead
Mechanical Engineering	3	Product Owner for Variant Management Manager—Software Engineering
Rail Vehicles	1	Head of Train Control and Information Systems (Engineering)
Aerospace	2	Software Architect—Cabin Management System

according to their industry, with their respective department and current position. Although several interviewees held senior roles such as software architect, product owner, or manager, their responsibilities extended beyond high-level architectural planning. All experts had substantial operational involvement in parameter definition, parameterization, integration, release, or validation activities, either in their current positions or in previous engineering roles. Consequently, the interviews also captured practical challenges, process-specific constraints, and tacit engineering knowledge from day-to-day parameterization activities.

Furthermore, explicit agreements were established concerning the handling and confidentiality of the data collected during the interviews. To ensure compliance with data protection requirements and to safeguard the anonymity of both the participating experts and their respective organizations, no detailed personal or sensitive organizational data were collected.

4.2. Execution of Expert Interviews

Each expert interview was conducted by two of the study’s authors and lasted between 60 and 90 min. One author was primarily responsible for moderating and guiding the interview, while the second author took detailed notes and posed clarifying questions when appropriate.

A maximum of two experts from one company took part in a given interview. The foundation for every interview was a pre-filled version of the questionnaire, which had been completed by the experts beforehand. During the interview, the responses in the pre-filled questionnaire were reviewed jointly with the experts in a step-by-step manner. Each question was discussed in detail, and any ambiguities or uncertainties were clarified in the course of the conversation.

Following the interview, the questionnaire was supplemented with the information captured in the meeting notes. Both participating authors then performed a cross-check of the documented results to identify potential misunderstandings or overlooked details. These were discussed and, if necessary, added to the questionnaire. Consistent with this methodological approach, and given the presence of multiple researchers during the interviews, including for documentation purposes, full audio recording and verbatim transcription were deliberately omitted.

The revised and expanded version of the questionnaire was subsequently formulated in written form and sent back to the experts for review. This allowed the interviewees to verify the correctness of the documented content and to clarify any remaining open questions. Depending on the complexity of the feedback and the need for coordination, this clarification took place either in writing or in a follow-up meeting.

Once the content was confirmed as accurate by the experts, the finalized version of the questionnaire was submitted to the respective company for approval for anonymized publication in a scientific context. If necessary, certain content was removed in a final step to comply with internal release requirements for external publication.

The interviews, including subsequent coordination and follow-up discussions, were conducted over the period from July 2024 to May 2025.

4.3. Questionnaire Analysis

The analysis of the processed questionnaire data was conducted using a structured qualitative content analysis approach following established principles proposed by Mayring [22]. The processed data was systematically coded and gradually condensed into thematic categories reflecting the nine dimensions of the SPMF introduced in Section 5.1.10.

The coding scheme (detailed information to be found in Appendix A) was continuously refined throughout the analysis process through iterative cross-checks between the authors in order to reduce subjective interpretation and improve analytical consistency. Discrepancies in category assignment or interpretation were discussed jointly until consensus was achieved. This procedure increased the traceability and reproducibility of the qualitative analysis. The resulting findings are presented in the following section.

5. Results

As part of our study, nine companies from various industrial sectors were interviewed. These companies differ not only in terms of size and production volume but also with regard to the complexity of their products, the number of product variants, and consequently, the requirements placed on parameter management.

This diversity was central to our analysis, as it enabled us to explore a wide range of approaches and methodologies for handling parameters. To provide context for the specific conditions and requirements under which each company operates, both with respect to their products and the methods applied in parameter management, we present a brief overview in

Table 3. Industrial case study context.

Industry	Automotive (1)	Automotive (2)	Commercial Vehicle Supplier	Commercial Vehicles (1)	Commercial Vehicles (2)	Mechanical Engineering (1)	Mechanical Engineering (2)	Rail Vehicles and Systems	Aerospace
Production Volume p.a.	>1000 k	>1000 k	>10 k	>100 k	>100 k	N/A	>100 k	>1 k	>700
Examined System	Entire System	Entire System	Sub- systems	Entire System	Entire System	Entire System	Entire System	Sub-system s1	Sub-system s2
Variant Count	>1000 k	>1000 k	N/A	>1000 k	N/A	>10 k	N/A	N/A	N/A
Configuration Item Count	>10 k	>10 k	>1 k	>10 k	N/A	≤3 k *	≤20 *	≤1 k *	>5 k

Legend: N/A = Not Available, k = thousands, * = Per Product, s1 = Central Vehicle Control System, s2 = Cabin Management System.

.

The differing industrial contexts in which the companies operate naturally lead to divergent requirements for parameter management and the surrounding processes. In particular, the number of product variants, the number of parameters used, and the production volume play a decisive role. It should be noted that, from a software engineering perspective, the number of produced units does not directly affect the underlying principles of variability management. However, production volume has a significant impact on the requirements for automating the parameterization of software variants. In scenarios with low production volumes, the need for automation may be less pronounced, as configuration activities are performed less frequently. In contrast, high production volumes require a much higher degree of automation to ensure efficiency and consistency. Ultimately, it is the combination of these aforementioned factors that shapes and constrains the solution approaches adopted by industrial practitioners.

From an analytical standpoint, it is also relevant to distinguish whether parameter management refers to a single control unit or to an entire ECU network. The latter typically introduces significantly higher system complexity, e.g., terms of interdependencies, which is reflected in the methods and tools employed.

5.1. Research Question 1: Parameter Management Across Industries

To address the first research question, the interview results were compiled and documented on a case-by-case basis. For each case, the contextual characteristics are first summarized, followed by a description of the entire configuration processes of their ECU software and the associated parameter management. In addition to the individual case descriptions presented above, a maturity framework is introduced to enable a structured, cross-case evaluation of the findings. The framework assesses each case along nine dimensions that span the full lifecycle of ECU software parameterization, from parameter definition and variant modelling through configuration, validation, and deployment, to toolchain integration. Based on the interview findings, each of the nine companies is individually assigned to a maturity level for every dimension, providing a comparable and systematic characterization of current practices across industries. This framework-based assessment is presented in Section 5.1.10. and constitutes the concluding response to research question 1.

5.1.1. Automotive (1)

This automotive manufacturer offers highly customizable vehicles with millions of produced units and a similarly large number of variants across multiple platforms. To maintain competitiveness, a generic software solution is deployed for each vehicle model and ECU, which is parameterized via a standardized diagnostic interface. Variant management must handle several thousand parameters; the body control module (BCM) alone contains approximately one thousand parameters.

Software parameterization relies on two artefact types: parameters and datasets. Parameters control the activation or deactivation of functions, whereas datasets typically contain shared information such as characteristic curves. Both are managed via data containers that include the rules governing parameter and dataset selection for each variant. Variants are represented by alphanumeric feature codes forming the variant key. These codes and their dependencies are centrally maintained; however, no consistent methodology exists. The codes may represent technical features, regulatory markets, or other attributes, and their semantics are not consistent across vehicle projects.

Parameters are defined centrally within ECU-specific ODX files that describe parameter types, minimum and maximum values, and CAN signal mappings. Although parameters are theoretically linked to requirements—within the tool, where parameters are defined—this linkage is only partially implemented and rarely used in practice. No further formal associations exist. Instead, the relationship between parameter values and vehicle equipment is manually maintained in Excel-based data containers. These matrices list features vertically and parameters horizontally, with cells containing the corresponding parameter values. Parameters themselves are managed as a flat list without hierarchy, and their relationships to functions or equipment are largely implicit knowledge held by engineers. Parameter values are not centrally managed and often exist only in engineering documentation or expert knowledge. Datasets are generated using a dedicated tool and managed through version control, ensuring traceability.

Changes to data containers—containing parameter values or datasets—can be tracked through part numbers, although identifying the exact changes requires manual comparison. Data containers are managed via a dedicated bill of materials, allowing variant-dependent allocation over time (e.g., assigning different containers to left-hand-drive and right-hand-drive vehicles).

Parameterization is deployed to vehicles via diagnostic protocols such as UDS using XML-based data. A vehicle-unspecific data container is transformed into a vehicle-specific byte array containing the required parameters and datasets and loaded into the ECU through the diagnostic address. The ECU identifies the parameterization based on diagnostic service naming conventions. Correct transmission is verified using standard diagnostic procedures.

5.1.2. Automotive (2)

This automotive manufacturer operates roughly ten parallel platforms, including legacy systems, current architectures, and platforms under development. Across these platforms, hundreds of vehicle projects and millions of variants exist.

Software variability is managed using a modular, component-based generic software architecture. Parameterization involves both enabling or disabling code sections and integrating specific datasets. These adjustments are organized into two parameterization artefacts known as configuration calibrations (Configuration-Cals) and performance calibrations (Performance-Cals). Configuration-Cals contain parameters used to activate or deactivate vehicle functions or select between alternatives. Performance-Cals contain parameters used to fine-tune behavior, such as engine characteristic maps, and are tailored to specific variants.

All parameters and datasets are managed centrally. A key element of the process is end-of-line programming, where ECU software is adapted to individual production orders directly on the assembly line. Each configuration file is identified by a unique part number. Any modification in series production requires a new part number, ensuring complete traceability. A dedicated tool supports version management by highlighting differences between file versions.

Parameters within Configuration-Cals and Performance-Cals are controlled through Option Codes and therefore inherit their hierarchy from the option code structure. At the architecture and system level, the manufacturer maintains a comprehensive variability model within the Gears tool. Option Codes representing vehicle characteristics (e.g., left- or right-hand drive) are hierarchically structured and linked to requirements.

However, at component and subcomponent levels an end-to-end toolchain cannot be established. A significant share of the software is externally sourced, preventing direct linkage of external parameters to internal Option Codes and feature models within Gears. Consequently, parameter assignments to Option Codes must partially rely on engineering expertise. This discontinuity is an inherent limitation of integrating externally supplied software.

Vehicle functions act as the central control element in configuration. Option Codes are assigned to functions and simultaneously linked to requirements. ECU-specific configuration files are then generated using the proprietary XML-based tool Variant Editor for ECUs. After automated approval, functional testing, and review, the resulting OBD-2-compliant binary files are deployed to vehicles.

Correct parameter transmission into the final product is verified through diagnostic tool support by reading and comparing checksums.

5.1.3. Commercial Vehicle Supplier

This ECU manufacturer supplies ECUs for commercial vehicles such as trucks and buses. Production volumes reach tens of thousands of units with high variant diversity driven by strong customer-specific customization.

Three delivery models exist. In the first, only hardware is provided and the customer develops and configures the software. In the second, hardware is delivered with pre-installed software that allows parameter adjustments. In the third model, hardware, software, and a dedicated toolchain are supplied.

The manufacturer provides a generic software platform adapted to customer requirements. Configuration occurs in two stages. During pre-development, potential functionalities are anticipated and placeholders or configurable parameters are implemented with default values. In customer-specific projects, configuration options are defined jointly with the customer, including the activation or deactivation of functions, code segments, and parameterized datasets such as characteristic curves. Consequently, the platform evolves continuously.

Parameter scope depends on the ECU type. Simpler ECUs such as door control units contain relatively few parameters, whereas complex ECUs such as BCMs involve several thousand.

Parameters are managed in a central repository. Customer-specific development projects use structured storage defined jointly with the customer, whereas internal projects use project-specific databases. Although parameters are not hierarchically structured, they are clustered by functional domains and linked to requirements. Most ECUs are AUTOSAR-based, and parameter management in the vehicle therefore follows AUTOSAR-compliant structures. Deviations are rare and typically customer-driven.

Validation follows the V-model across component, system, and vehicle levels. A significant portion of these tests is performed by the customer. ECU test environments are initially created manually and later executed automatically.

Since predefined software variants do not exist, parameterization is managed through assignments to customers, ECUs, and other identifiers within a software bill of materials (SBOM). The SBOM contains identifiers such as hardware IDs, software IDs, customer IDs, and parameter configurations, providing visibility into available functions and configuration possibilities. Most validation activities are again performed by the customer.

Deployment of parameterization data to the vehicle is performed via standard diagnostic interfaces. Over the air (OTA) capable ECUs are available, but OTA updates are still limited because commercial vehicle E/E architectures evolve slowly to minimize development costs. Consequently, only a small number of ECUs support OTA updates.

5.1.4. Commercial Vehicles (1)

This truck manufacturer follows a modular vehicle architecture in which up to 20,000 parts can be combined, enabling more than one million configurations. Generic software is used for each system and configured through parameters that activate or deactivate functions or assign values such as maximum vehicle speed. Some systems, particularly engines, additionally use datasets for characteristic curves. Each vehicle contains approximately 60 ECUs, each with hundreds of parameters and thousands of potential values.

Variant-specific parameter management is governed by Configuration Rules. These rules define the assignment of parameters to vehicle variants. Variants are represented by Feature Codes describing vehicle attributes, functions, or systems. Feature Codes are maintained in a central product data management (PDM) system.

Parameters themselves are generally not managed centrally but are referenced within the Configuration Rules. These references ensure full traceability across the vehicle lifecycle by clearly identifying which parameters apply to each configuration.

Although parameters do not possess an inherent hierarchy, they can be categorized into two groups. The first group represents the vehicle’s physical configuration, ensuring the software reflects the installed equipment. The second group controls behavioral characteristics used for deeper customization. These behavioral parameters are often hard-coded (e.g., characteristic curves) and managed in separate configuration files with their own part numbers. They are therefore managed as independent parts rather than standard parameters.

Requirements are linked to parameters through design systems referencing the relevant software items that provide parameters. Configuration Rules reference the same items. Changes to Configuration Rules are managed similar to other product parts, with article numbers adjusted via engineering change orders. Typically, one valid Configuration Rules file exists per system and hardware generation.

Configuration Rules automatically generate binary configuration files based on vehicle specification and ECU software version. Extensive testing ensures parameter and dataset correctness. However, complete coverage of all possible configurations is infeasible. Relationships between parameters and variants are validated during development, and Configuration Rules are tested for completeness to ensure correct input-output mappings.

5.1.5. Commercial Vehicles (2)

This commercial vehicle manufacturer produces more than 100,000 vehicles annually, with nearly every vehicle configured as a unique product. High product variability is addressed through generic software architectures supporting extensive parameterization options.

An illustrative example is the software solution for the braking feature. In this context, a feature denotes a vehicle function that is directly perceivable by the end customer. The generic software is adapted to the specific vehicle configuration through parameterization. Key influencing factors include the target delivery market and vehicle characteristics such as the number of axles. Parameterization therefore involves activating or deactivating specific code sections, assigning parameter values, and integrating datasets that define characteristic curves or maps.

Parameter numbers vary significantly between ECUs, ranging from a few parameters to several thousand. All parameters are managed in a central database and assigned unique IDs to support traceability. These IDs are linked to requirements, although the connection is not tool-supported and must be maintained manually.

An implicit hierarchy exists in which parameters are first grouped by ECU, then by software version. Some parameters are globally valid and integrated once into the vehicle system while being accessible by multiple ECUs.

Parameters are defined per ECU and then linked to Sales Codes representing customer-selected options such as equipment features or delivery regions. Parameter control across the lifecycle is supported by documentation systems. Temporal validity is defined through activation and deactivation dates, while linkage to hardware and documentation logic follows bill-of-material-like structures.

Rules determining parameter selection for given Sales Codes are created manually. In contrast, the derivation of parameterizations and associated testing procedures is automated. Validation involves plausibility checks, functional tests, hardware-in-the-loop simulations, and vehicle testing.

Parameters are ultimately written into the vehicle in binary format using diagnostic protocols such as ODX-D and ODX-E. Prior to deployment, parameters undergo a multi-stage manual approval process involving development, integration, verification, validation, and production. Correct deployment is verified using diagnostic procedures and checksum validation.

5.1.6. Mechanical Engineering (1)

This manufacturer operates in a domain characterized by high product individuality, with up to 10,000 variants in the field. Products run on a unified operating system on which application software is deployed and parameterized. These parameters range from simple scalar values to complex structures such as characteristic curves. Up to 3000 parameters may be required per product.

All parameters are centrally managed in the product line engineering (PLE) tool pure::variants. They are organized as a flat list without hierarchical structure. Variant keys, represented by features, are defined in an ERP system (SAP). These features include product attributes, functional properties, and country-specific regulatory codes, but they follow no consistent modeling methodology. The feature definitions and their dependencies are manually synchronized from SAP into pure::variants by data managers to maintain consistency between both systems.

Within pure::variants, parameters are linked to these features. However, the mapping between parameters and features is maintained manually and lacks version control, making modifications difficult to track. Traceability is therefore limited to parameter and feature changes recorded by the tool’s version control system.

The generation of product-specific configuration files follows a multi-stage automated workflow. After a customer order is defined by sales and entered into SAP, the configuration is transferred to pure::variants, which contains a comprehensive 150% feature model representing all possible configuration options. From this model, a project-specific 100% feature model is derived based on the customer order. The selection of parameters for the configuration file is automated once the specific 100% feature model is generated.

Parameter values are subsequently calculated externally using mapping tables or CAD-based calculations, which may generate values such as characteristic curves. These values are then imported into pure::variants via a plug-in, which compiles the final configuration file. The entire process is fully automated from customer order to configuration file generation.

Due to the computational effort required for parameter calculations, a buffer period of six to eight weeks exists between order entry and configuration file completion. Each parameter and parameter value is assigned a validity period, which is then matched against the production date of the corresponding product.

New parameters initially receive the status unvalidated. If such parameters are used during configuration compilation, the system generates a warning. A four-eyes validation process is then performed to verify parameter correctness and dependencies before the parameter is marked as validated. The six-to-eight-week buffer allows sufficient time for this validation.

Final parameter values are exported as JSON files, which are compressed into encrypted ZIP archives. Operating system parameters are stored in a single file, while each ECU receives a separate configuration file. Deployment to the product occurs via standard diagnostic interfaces. OTA updates are not yet supported; therefore, parameterization changes must be applied during production or through manual maintenance procedures. After deployment, an end-of-line production test verifies the basic functionality of the product.

5.1.7. Mechanical Engineering (2)

This manufacturer operates in a context characterized by low variant diversity but high production volumes. Because only a limited number of variants exist, software parameterization does not rely on explicit variant keys or feature abstractions. Instead, a modular software platform architecture is used, consisting of decoupled software units.

Software parameterization is performed through parameters that enable or disable functions or define preset values. These parameters are directly linked to product article numbers. However, parameter management is not fully centralized and no hierarchical parameter structure exists. Some parameters are maintained within a PDM system, but systematic links to original requirements are not established.

Traceability of parameter changes is limited. Only parameters managed within the PDM system allow historical tracking; changes to other parameters are not consistently documented.

Parameter assignments to article numbers are defined through configuration scripts. During production, these scripts are executed using the target article number as input, automatically determining the required parameters. The corresponding values are extracted, converted into binary files, and applied to parameterize the software.

Validation of the configuration occurs only in the final step, once the entire product has been fully parameterized. At this stage, a comprehensive system-level test verifies the entire software parameterization. Meaningful validation requires the complete software, including parameters, to be present during this final testing phase.

5.1.8. Rail Vehicles and Systems

This manufacturer of rail vehicles and systems applies a platform-based development strategy across a broad product portfolio including trams, suburban trains, metro trains, regional trains, high-speed trains, and locomotives. Production volumes per order typically range between 10 and 200 vehicles, with each order usually consisting of identical vehicles for a specific rail operator.

For platforms supporting multiple projects, a generic application software is used for the central vehicle control system. This software follows a modular architecture and is configured by activating or deactivating specific functions or by selecting between alternative functional variants.

A parameter database manages predefined parameters as placeholders without assigned values. Once a customer order is received, parameter values are assigned according to the project specification. For example, a parameter representing air conditioning may receive values such as “standard” or “premium” configuration. Additionally, specific values, such as a maximum temperature setting, may be defined. Unlike predefined variants, parameter values are tailored to each customer order, making the platform dynamic and evolving over time.

Parameters are categorized by type but are not hierarchically structured. “Options” enable or disable code sections or functions, while “variants” allow selection among predefined parameter values.

Parameters also differ in accessibility. Approximately 90% are manufacturer-defined parameters, modified by the manufacturer, while roughly 10% are customer-defined parameters, modifiable by the customer, such as door opening durations. For safety-critical functions, parameterization is generally avoided due to extensive effort required for software certification. Therefore, the degree of safety criticality of parameters is not labeled, whereas their modifiability during runtime is labeled.

The number of parameters considered in variant management varies by platform and may range from a single option to several hundred for the central vehicle control system. Parameters are managed centrally both within the product and during development. Development uses project-specific storage structures organized through baselines and integrated with configuration management tools.

Compliance with configuration and change management standards such as DIN EN 50716 [23] ensures full traceability of parameter and dataset modifications. Parameters are closely linked to requirements through requirements management and essentially serve as tools for fulfilling requirements within a generic software framework, thereby representing specific manifestations of these requirements.

Parameter definitions and assignments to individual variants are performed manually but supported by specialized tools that enable automated dataset generation for individual projects.

The parameterization, consisting of parameters and datasets, is imported into the vehicle’s software application via standard diagnostic interfaces in a proprietary XML-like format and stored locally. Transmission integrity is verified through mechanisms such as checksum validation. Parameterization is automatically approved in the vehicle after passing multiple validation steps, while manual approval occurs earlier during development as part of the software release process.

Testing is performed at multiple levels, focusing on validating the customer-specific configuration rather than the generic software across all potential variants. Additionally, requirement traceability is employed to validate the correctness of relationships between parameters, datasets, and their corresponding variants. Traceability is maintained throughout the V-model via documentation and source code using requirement tags.

5.1.9. Aerospace

This aerospace manufacturer produces more than 700 aircraft annually. Each aircraft is highly customized and effectively unique. Unlike the automotive sector, configurations cannot be grouped into predefined variants; instead, each aircraft is tailored to specific customer requirements. The analysis focuses on the cabin management system and its parameterization.

The manufacturer uses generic software solutions defined per aircraft family. A new software system is created for each new aircraft family, which is typically developed every 10 to 20 years. For each airline ordering aircraft from a given family, a dedicated configuration set is created to adapt the generic software to the airline’s specific requirements. A configuration set usually applies to between one and ten aircraft.

Software parameterization includes several adaptation domains. Functions may be enabled or disabled, content can be customized (e.g., audio announcements, language settings, frequency databases), and cabin layout parameters can be adjusted. The latter includes seating configurations, lighting, speakers, ventilation, and wiring layouts, which determine the number and placement of control units and their interactions.

Parameterization is performed by selecting parameters and assigning airline-specific values. A typical generic software system contains approximately 5000 parameters excluding their potential values.

Parameters are managed in a central SQL database within a requirements-based development process, while parameter values are maintained in a separate tool. Direct linking of parameters to requirements ensures full traceability. Therefore, all changes to parameters, their values and datasets are documented and traceable.

There is no hierarchical structure for parameters; instead, they are organized as a flat list. However, the parameters are categorized according to different types. Certification-relevant parameters are safety-critical and cannot be modified. User-modifiable parameters can be modified by the end user, such as language settings or audio files.

Parameters are not linked to predefined variants or feature models. Instead, configurations are created individually based on customer requirements using a wizard-based configuration tool. This tool presents configuration options to users and validates dependencies between parameters and datasets.

Because no predefined variants exist, all parameters, values, and dependencies must be systematically defined. Configuration rules and dependencies are maintained within a dedicated configuration tool. Configuration management is performed by specialized engineers known as Realizers within the customizing department. Once parameter assignments are defined, they are transferred into an automated toolchain that implements the parameterization.

Safety-critical systems are comprehensively tested for each configuration instance to verify compliance with specifications. Tests include both expected and boundary parameter values. Due to the large number of parameters and combinations, exhaustive test coverage is not feasible. Once the software is parameterized in the aircraft, basic functionality tests are performed to confirm system operation.

Parameterization is integrated into the aircraft as a Parameter Data Item (PDI), a standardized format subject to certification procedures under DO-178C [24]. Each PDI represents field-loadable software and is assigned a unique software part number. Any modification results in a new part number, ensuring traceability. Each software version therefore has a corresponding PDI containing all parameters and values for a specific aircraft. The PDI specifies which parameter values apply to which ECU and where they are stored. Typically, values are stored on a redundant central computer, while smaller ECUs retrieve the required parameters when needed. Instead of generating individual PDIs per ECU, a single PDI is created per software version and customer. The distribution of parameter values to the respective ECUs occurs automatically.

Deployment of the PDI to the aircraft is performed via standard diagnostic interfaces. Data integrity is verified using checksum validation, and the maintenance system continuously checks for inconsistencies between configuration sets and software versions.

Before deployment, each PDI undergoes a manual approval process. During this process, the baseline software parameterization is replaced with the customer-specific parameterization, creating a new aircraft software baseline that must be formally authorized.

5.1.10. Software Parameterization Maturity Framework (SPMF)

To enable a systematic cross-case evaluation beyond individual case descriptions, a SPMF was developed. The framework structures the parameter management lifecycle into nine dimensions (D1–D9), each assessed across three maturity levels: L1 (Basic), L2 (Structured), and L3 (Optimized). The dimensions were derived inductively from the interview findings and previous case descriptions and cover the full lifecycle of ECU software parameterization, from the initial definition of variant models and parameter structures through parameterization, validation, and deployment, to the cross-cutting integration of toolchains. The three lifecycle phases, Phase A: Definition & Modelling (D1–D3), Phase B: Configuration & Validation (D4–D6), and Phase C: Deployment & Operation (D7–D8), are complemented by D9 (Toolchain Integration) as a cross-cutting dimension spanning all phases. The SPMF thus provides a structured basis for comparing practices across industries that differ substantially in production volume, product complexity, and regulatory environment.

Figure 3 presents the structure of the SPMF with its nine dimensions and their assignment to the three lifecycle phases.

Building on this structure, each of the nine surveyed companies was assigned to a maturity level for every dimension based on the interview findings. Where multiple companies from the same sector were interviewed, their individual assignments are shown separately, reflecting the distinct practices of each organization. Figure 4 presents the full maturity matrix with company-level assignments across all nine dimensions.

The three maturity levels used in the SPMF are defined as follows. L1 (Basic) denotes predominantly implicit, project-specific, or manually enforced practices in which parameterization activities rely strongly on expert knowledge and lack systematic tool or process integration. L2 (Structured) represents explicitly defined practices that are consistently applied within a project or organizational unit and are typically supported by tools or documented processes, while still featuring manual steps or incomplete lifecycle coverage. L3 (Optimized) describes systematically integrated, organization-wide practices that are anchored in established processes, supported by end-to-end toolchains, and consistently applied across the entire parameter lifecycle. For each dimension D1 to D9, maturity levels were assigned based on the presence, explicitness, and degree of automation and integration of the corresponding practices, as derived from the interview data and the subsequent cross-case analysis.

A consistent pattern emerges: parameters are universally managed as a central configuration element, and all companies make use of some form of deployment verification. However, substantial differences exist in the degree to which variant models are formally structured (D1), requirements are systematically linked to parameters (D3), temporal change is managed through baselines (D5), and toolchains are integrated end-to-end (D9). These dimensions represent the primary differentiators between industries with historically evolved, pragmatic approaches and those operating under stringent regulatory frameworks that enforce traceability and configuration management by design.

To consolidate the individual company assignments into a sector-level perspective, Figure 5 depicts radar profiles for the five industry groups, Automotive, Commercial Vehicles (including Commercial Vehicle Suppliers), Mechanical Engineering, Rail Vehicles and Systems, and Aerospace, plotted across all nine dimensions. Several patterns are immediately apparent. Rail and Aerospace consistently reach L3 in the dimensions governed by regulatory certification requirements, most notably D3 (Requirement Traceability), D5 (Temporal Management), D6 (Testing & Validation), and D9 (Toolchain Integration), where standards such as DIN EN 50716 [23] and DO-178C [24] effectively mandate mature practices. Automotive, by contrast, shows a characteristic imbalance: relatively strong performance in D1 (Variant Modelling) and D4 (Assignment & Selection), but markedly lower maturity in D3 and D5, reflecting the historically evolved, timestamp-based approaches to parameter management that are increasingly under pressure in the context of software-defined vehicles. Commercial Vehicles exhibit the closest profile to Automotive but score consistently higher in D3 and D9, suggesting that the smaller number of vehicle configurations and closer customer integration facilitate more systematic traceability. Mechanical Engineering presents an inverse pattern in D8 (OTA & Lifecycle Updates): despite strong performance in Phase A and B dimensions, both companies operate without OTA capability, which is a rational consequence of their product architecture and requirements rather than an indication of organizational immaturity. Across all five groups, D8 reveals the widest intra-sector variance, with Rail at L1 and Aerospace at L3, a divergence driven by the fundamentally different certification burden of OTA updates in safety-critical rail systems versus the field-loadable PDI concept established in civil aviation under DO-178C [24].

5.2. Research Question 2: Identified Challenges

To address the second research question, the interview responses related to current challenges were analyzed both on a case-by-case basis and across cases. The processed results reflect past, current, and anticipated future challenges companies face in the parameterization and management of ECU software. Additionally, they provide insight into potential future developments aimed at addressing these challenges. However, it is important to note that the findings presented here are limited to the challenges that the participating companies explicitly approved for publication.

The majority of the identified challenges can be categorized into three overarching groups that were consistently reported across most participating companies: (1) lifecycle traceability, (2) complexity and scalability, and (3) toolchain continuity and legacy system integration.

Lifecycle traceability encompasses all challenges related to the holistic tracking and documentation of changes throughout the product lifecycle—for instance, the traceability of parameter modifications. This category also includes issues arising from increasing regulatory demands and change management requirements, which further intensify the need for end-to-end transparency across engineering and operational domains.

The second group, complexity and scalability, includes challenges associated with the growing customizability and variability of products. These are closely linked to ECU-centric parameterization and challenges resulting from OTA updates. Ultimately, these difficulties stem from the rising complexity and volume of parameterization data, which complicates manual handling, increases the necessity for automation, and hinders efficient data maintenance and creation processes.

The third group, toolchain continuity and legacy system integration, covers challenges caused by the absence of an end-to-end toolchain spanning the entire development process and the broader product lifecycle. It also includes problems related to the integration of legacy systems, particularly regarding the compatibility of heterogeneous tool landscapes. Incompatibilities often occur when integrating outdated or proprietary systems as well as supplier-specific tools, thereby creating discontinuities in data and process flows.

Table 4. Overview of challenges across individual industries.

Challenges	Automotive	Commercial Vehicle Supplier	Commercial Vehicles	Industrial Engineering	Rail Vehicles and Systems	Aerospace
Comprehensive Traceability	●	○	○	●	○	○
Rising Regulatory Demands	●	○	●	○	○	○
Change Management	●	○	●	●	○	○
Increase in Customizability & Variability	●	●	●	●	○	●
ECU-Centric Parameterization	●	○	●	○	○	○
OTA Updates	●	●	○	○	○	○
Lack of End-to-End Toolchain	●	●	●	●	○	○
Integration of Legacy Systems	○	○	○	●	○	○

Legend: ● = Affected; ○ = Not Affected.

provides a consolidated overview of the industries affected by these challenges. The assessment of whether an industry is impacted is based on its current processes, existing boundary conditions, and foreseeable changes to these conditions. A solid circle indicates that the respective industry is affected by the corresponding challenge, whereas a hollow circle denotes that the industry is not affected. The results reveal significant inter-industry differences: some sectors are currently undergoing major transformations and face numerous challenges, while others encounter few or none.

Two prominent examples of industries in transition are automotive and commercial vehicles, both facing a broad spectrum of challenges. Companies in the automotive sector, in particular, are confronted with almost every challenge enumerated in Table 4. In contrast, sectors such as rail vehicles and systems and aerospace experience little to no disruption. Several factors explain this discrepancy. In some cases, these industries anticipated challenges early and implemented corresponding solutions in advance. Moreover, their regulatory environments differ substantially from those in the automotive domain. Strong documentation requirements and long-standing regulatory obligations have already driven the establishment of mature traceability and configuration processes in rail and aerospace industries.

Another reason why industries such as rail vehicles and systems and aerospace face fewer challenges in the parameterization and management of ECU software lies in the fundamental differences between their products and those of other sectors. In the automotive industry, vehicles are developed, produced, and maintained throughout their lifecycle in extremely high volumes—amounting to millions of units—with an exceptionally large degree of variability.

In contrast, companies operating in the rail and aerospace industries manufacture products in substantially smaller quantities: rail vehicle manufacturers typically produce only a few thousand units per year, while aerospace companies often produce only hundreds. In many cases, products in these industries are configured jointly with the customer and sales departments. For some projects, it is sufficient to configure products from a predefined modular system. However, there are also numerous cases in which customer-specific developments are required, at least for certain components or subsystems.

Such an approach is feasible due to the low production volumes and corresponding pricing structures, whereas in industries such as automotive and commercial vehicles, this is generally not realistic. Even exceptions within the automotive sector, such as luxury and premium vehicle brands, still operate with production volumes that exceed those typically found in the rail or aerospace domains.

A cross-case analysis indicates that the lack of hierarchical structure in parameter management, the need for improvements in usability and changeability, and the absence of standardized parameterization approaches constitute challenges that extend across multiple industries, as shown in Figure 4 with D2 & D4 in the SMPF.

Moreover, insufficient traceability represents a widespread issue, particularly when considering one of the most pervasive problems: the absence of a systematic analysis of parameter usage. This challenge is not confined to any specific sector but spans industries and affects the entire lifecycle of ECU parameterization. In many cases, companies lack a structured evaluation of parameterization data that could provide critical insights into system utilization and optimization potential.

Several key questions remain largely unanswered: Which parameters are selected most frequently? Which parameters are never used? Which parameterizations remain active in the current vehicle fleet? Addressing these questions adequately is impossible without appropriate data analytics capabilities. A systematic analysis of available data, combined with the expansion of data collection strategies, has the potential to significantly enhance ECU parameterization and parameter management across the full lifecycle—from development and validation to deployment and in-field operation.

In addition, all industries are affected by more general challenges that are not specific to ECU parameterization and management. These include pressure to shorten time-to-market, high testing efforts, and the conflict between customer, sales, and development requirements, which collectively add to the complexity of managing software and parameterization processes effectively.

5.3. Research Question 3: Implications for the Automotive Industry

The overall objective of the conducted survey was twofold. First, it aimed to identify and characterize current practices of ECU software parameter management across variant-rich industries, including their requirements, challenges, and boundary conditions. Second, it sought to derive opportunities for improving parameter management in the automotive domain by systematically assessing and contextualizing practices observed in other industries.

This second objective is addressed in this section. The analysis follows a structured, stepwise logic. In Section 5.3.1, automotive-specific challenges and improvement needs are derived from the cross-case analysis, i.e., SPMF. Building on these identified needs, Section 5.3.2 examines why SPLE, as an established methodological approach, emerges as a potentially suitable conceptual reference for addressing selected deficits. However, as discussed in Section 5.3.3, specific boundary conditions of the automotive industry complicate the direct application of classical SPLE concepts. Finally, Section 5.3.4 outlines the resulting implications for future research, discussing how SPLE-inspired approaches may need to be adapted for automotive ECU parameter management and identifying promising directions for further investigation.

5.3.1. Derivation of Improvement Needs from the SMPF

The cross-case evaluation using the SPMF, summarized in Figure 3 and Figure 4, reveals a set of recurring improvement needs that are particularly pronounced in the automotive domain. These needs are consistently concentrated in four closely related areas:

• Variability and variant modeling: The SPMF indicates that achieving higher maturity levels in variability modeling requires the establishment of explicit and consistent variability models from which both product variants and software parameters can be systematically derived. In the automotive cases, variants are often represented through heterogeneous constructs such as feature codes, option codes, or sales codes, whose semantics differ across projects and platforms. This limits their suitability as a stable backbone for parameter derivation. Closely linked to this issue is requirement traceability. To enable predictable and traceable parameter creation along the V-model, variability models must not only represent product options, but must also be aligned with upstream engineering artifacts such as requirements. Consequently, variability modeling cannot be implemented in isolation but needs to cover the variability of the system as a whole and be applied consistently across organizational and technical boundaries.
• Parameter definition and structuring: A second improvement need concerns the definition and internal structuring of parameters themselves. The SPMF highlights that parameters are predominantly managed as flat lists, which limits comprehensibility, reuse, and automated processing. At minimum, this creates a need for introducing hierarchical or otherwise structured parameter models. Such structures are a prerequisite for systematically assigning attributes to parameters, for example with respect to homologation relevance, safety criticality, or market validity. Without explicit parameter models, these attributes remain implicit expert knowledge, increasing the risk of inconsistencies and errors, particularly in highly variant and regulated environments. Structured parameter models are therefore a key enabler for both traceability and controlled evolution over time.
• Temporal management of parameters: The third improvement need identified by the SPMF relates to temporal management. In the examined automotive cases, parameter validity is often managed through isolated timestamps for activation and phase-out. While this approach is workable for limited change scenarios, it becomes increasingly fragile as software update frequencies rise and parameterization complexity grows. To reach higher maturity levels, variability and parameter models must be embedded into a release-oriented lifecycle management approach. This implies that parameter sets are versioned and approved as part of coherent baselines, allowing the evolution of parameterization to be managed explicitly over time. Such an approach is also a prerequisite for complying with regulatory requirements such as UNECE R155 and R156 [25], which mandate that software, including its parameterization, must be uniquely identifiable across versions and throughout the vehicle lifecycle.
• End-to-end toolchain integration: Finally, the SPMF highlights toolchain integration as a cross-cutting improvement need that directly affects all other dimensions. Variability models, parameter models, and release management mechanisms can only be applied consistently if they are supported by an integrated tool landscape. End-to-end traceability presupposes that relevant artifacts are maintained in tools that are connected via defined interfaces, enabling automated data exchange and consistency checks. In the absence of such integration, manual data transfer becomes unavoidable, significantly increasing effort and introducing a high risk of human error. As a result, traceability and correctness cannot be reliably ensured at scale. Consequently, mature parameter management in the automotive domain necessarily depends on toolchains that support model consistency, lifecycle control, and traceability in an automated manner.

5.3.2. Why SPLE Emerges as a Relevant Concept

PLE, or more specifically SPLE [26], was identified as a key best practice. The objective of SPLE is to establish and manage a shared platform that enables the systematic development of product families, while reducing costs and improving time-to-market [26,27]. In the examined case study from the field of Mechanical Engineering (1), this methodology was successfully implemented, replacing the previously established parameter management system entirely.

From an analytical perspective, SPLE aligns closely with the deficits revealed by the SPMF, particularly in the areas of variability modeling, parameter derivation, and traceability. A central principle of SPLE is the explicit separation of the problem space and the solution space. In the problem space, variability models are defined to capture customer-visible options and system characteristics. In the solution space, these variability concepts are realized through concrete engineering artifacts, such as requirements, software components, parameterization data, and parameter structures. This separation enables a systematic mapping between product variability and implementation artifacts, directly addressing the need for explicit variant semantics and predictable parameter derivation.

The relevance of SPLE is also supported by empirical evidence from the examined Mechanical Engineering (1) case, where SPLE replaced a previously ad hoc parameter management approach and was retrospectively assessed as highly successful. In this case, variability models and parameter mappings enabled the automated derivation of fully configured product instances from a comprehensive variability space, demonstrating the scalability and methodological consistency of SPLE-based approaches in variant-rich environments.

Several mature tool solutions already exist to support SPLE in practice, such as Gears from BigLever Software or pure::variants from PTC as also mentioned by the industry cases. These tools provide capabilities for creating and maintaining variability models, linking them to solution-space artifacts, and automatically deriving 100% product variants from 150% variability models. From an SPMF perspective, such capabilities directly contribute to higher maturity levels in dimensions related to variant modeling, parameter definition and assignment as well as toolchain integration. In principle, their systematic adoption would enable the automotive domain to reach the highest maturity levels in these areas.

However, it must be noted that classical SPLE approaches do not explicitly address all dimensions identified by the SPMF. In particular, temporal management aspects, such as coordinated evolution, release-based lifecycle control, and parameter validity over time, are not treated as first-class concerns within traditional SPLE frameworks. SPLE does not prescribe concrete mechanisms for release and version management of parameterization artifacts in highly dynamic, regulatory-driven environments. This limitation is particularly relevant for the automotive domain and motivates the subsequent discussion of automotive-specific boundary conditions.

5.3.3. Automotive-Specific Constraints Limiting SPLE Applicability

Naturally, SPLE is already a well-established research field, and it could therefore be argued that concluding that SPLE should be applied represents only a limited or incremental contribution. This is particularly relevant given that many companies, especially in the software domain, have been applying SPLE principles since the early 2000s [28,29]. However, findings from this study, as well as prior research [30], indicate that holistic, end-to-end processes at the level of the whole vehicle are typically not based on SPLE methodologies (as show by the categorization of Auto (1 & 2) in D1, D2 & D4). At best, individual elements of SPLE are applied in isolation, often without a comprehensive understanding or systematic adoption of the underlying concepts. Several reasons, particularly specific to the automotive industry, help explain this situation.

A first fundamental limitation originates from the automotive industry’s strong reliance on externally developed ECU software. A substantial share of vehicle functionality is implemented in supplier-delivered software components that are integrated as partially opaque artifacts. Although such software is often compliant with standards such as AUTOSAR at the interface level, its internal variability models, parameter structures, and evolution mechanisms remain under supplier control.

This fragmentation fundamentally undermines the end-to-end variability ownership typically assumed by SPLE, where a single organization governs both problem-space models and solution-space assets. As reflected by lower maturity levels in dimensions such as requirement traceability (D3) and toolchain integration (D9), OEM-level variability models cannot be fully synchronized with supplier-internal parameterization logic, thereby limiting consistency across ECU boundaries.

A central mechanism behind this limitation becomes particularly visible when considering the interaction between variant modeling (D1) and toolchain integration (D9). Since software artifacts and parameters are developed and maintained within supplier-specific tool environments, discontinuities arise in the engineering toolchain. As a result, variability defined at the OEM level cannot be seamlessly propagated into the supplier-controlled parameter space. These toolchain breaks prevent the establishment of a continuous traceability chain across artifacts and lifecycle phases.

This issue is highly relevant in the context of SPLE-based approaches. Within SPLE, variability is typically captured in a problem-space model and systematically propagated to solution-space artifacts along the development lifecycle, for instance in alignment with model-based systems engineering (MBSE) practices and the automotive V-model. This requires a consistent mapping between variability models, requirements, and parameterization artifacts. However, due to the described toolchain discontinuities and distributed artifact ownership, such traceability cannot be ensured in current automotive practice.

From an operational perspective, this often leads to duplicated parameter definitions, redundant parameterization efforts, and manual alignment between OEM-level variant descriptions and supplier-internal parameter implementations.

Consequently, enabling SPLE-inspired approaches in the automotive domain requires the development of tool-supported integration mechanisms that extend across organizational boundaries. In particular, there is a need for collaborative tool ecosystems in which OEMs can formally communicate variability models to suppliers in a structured and traceable manner, rather than relying on document-based specifications. Such mechanisms would form the basis for achieving end-to-end traceability and consistent parameter derivation across distributed development environments.

A second boundary condition arises from the coexistence of established automotive software engineering standards and SPLE concepts. Automotive development processes are deeply rooted in AUTOSAR-based architectures, diagnostic data models such as ODX and PDX, and homologation-driven workflows. These standards define concrete artifacts, interfaces, and lifecycle processes that are not inherently aligned with the abstractions commonly used in classical SPLE toolchains. Consequently, SPLE cannot simply be introduced as a replacement methodology, but instead must coexist with and be integrated into existing engineering processes and data structures. This significantly increases the complexity of applying SPLE in automotive environments and reinforces the need for selective, context-specific adoption rather than a purely holistic transfer of established SPLE approaches.

A third limitation concerns temporal dynamics and lifecycle control. As highlighted in the SPMF, automotive parameterization practices historically evolved around relatively static parameterization processes, whereas SPLE traditionally assumes controlled but comparatively stable evolution of reusable assets. In contrast, the transition toward SDVs introduces frequent software updates, post-production feature changes, and regulatory requirements for software update traceability. This creates a mismatch between the temporal assumptions underlying traditional SPLE frameworks and the operational realities of automotive parameter management, particularly regarding deployment and temporal variability management.

Finally, organizational scale and production volume further complicate the application of SPLE. Automotive systems must support millions of unique vehicle configurations in mass production, significantly amplifying the consequences of modeling errors, inconsistent parameter assignments, or incomplete variability constraints. While SPLE provides mechanisms for managing variability at scale, its effectiveness under such conditions depends heavily on governance structures, validation processes, and toolchain maturity that extend beyond the scope of classical SPLE concepts.

Taken together, these boundary conditions indicate that the challenges observed in the automotive domain cannot be addressed through a straightforward adoption of SPLE alone. Instead, they point toward the need for automotive-specific adaptations that explicitly account for supplier integration, regulatory compliance, legacy standards, and high-frequency software evolution. These observations form the basis for the implications and future research directions discussed in the following section.

5.3.4. Implications for Future Research and Industrial Practice

The analysis of automotive-specific boundary conditions demonstrates that improving ECU software parameter management cannot be achieved through the isolated adoption of existing methodologies. Instead, future research must address a set of interrelated challenges that arise at the intersection of variability management, supplier integration, regulatory requirements, and software lifecycle dynamics.

A first major research direction concerns the selective application and adaptation of SPLE concepts for the automotive domain. Rather than solely pursuing a holistic software product line approach at vehicle level, future work should also investigate how SPLE principles can be applied to those parts of the parameter space that remain under OEM control, while explicitly accounting for supplier-controlled software artifacts. This includes the development of hybrid and federated variability models that combine OEM-level problem-space abstractions with well-defined interfaces to supplier-internal configuration mechanisms. Such collaboration and governance models must establish clear ownership boundaries and traceability responsibilities without requiring full transparency of supplier-internal implementations, thereby enabling the controlled integration of supplier black-box software into OEM-governed variant models. Addressing this challenge directly targets one of the most critical structural limitations identified by the SPMF.

A second research direction relates to the integration of SPLE-inspired concepts with established automotive standards and toolchains. As shown by the SPMF, automotive development is deeply anchored in AUTOSAR-based architectures, diagnostic data formats such as ODX and PDX, and homologation-driven release processes. Future research should therefore focus on aligning variability models, parameter models, and derivation mechanisms with these existing artifacts, rather than replacing them. This includes investigating mappings between variability models and AUTOSAR configuration structures, as well as mechanisms for linking parameter models to diagnostic and parameterization data used throughout the vehicle lifecycle.

Third, the findings highlight the need for advanced temporal management mechanisms that go beyond the assumptions of classical SPLE. With the increasing relevance of SDVs, OTA updates, and post-production changes, future research must address how parameterization can be treated as a time-dependent engineering artifact. This includes release- and baseline-oriented lifecycle models that ensure traceability, reproducibility, and regulatory compliance across software versions, while still supporting high-frequency updates in the field.

Finally, future research should investigate governance and organizational models that enable consistent parameter management across distributed development environments. This encompasses the definition of clear ownership boundaries, validation responsibilities, and approval processes for parameters that span multiple ECUs and organizational units. Given the scale and variability of automotive systems, such governance mechanisms are a prerequisite for translating methodological concepts into sustainable industrial practice.

In summary, the SPMF provides a structured basis for identifying where existing approaches fall short and for guiding future research toward context-specific adaptations. Addressing these research directions is essential for developing parameter management concepts that are compatible with the technical, organizational, and regulatory realities of the automotive industry.

6. Discussion

In summary, the cases examined reveal highly diverse requirements and challenges in the handling of parameterization. Given the qualitative and exploratory nature of this study, the findings should be interpreted as indicative insights rather than statistically generalizable conclusions. Consequently, it is only partially possible to derive universally applicable practices, as many requirements are strongly domain-specific.

In some sectors, such as aerospace or rail vehicle manufacturing, explicitly defined variant models or feature structures are often not required within the respective product development processes. In these cases, parameterization is typically performed in direct consultation with the customer, where specific parameter values are selected and adapted without being linked to a higher-level variant structure.

In contrast, the automotive sector, as well as the commercial vehicle domain, are characterized by the combination of high production volumes, extensive product customization, and customer-specific online configuration. This context limits the transferability of concepts from other industries, as the automotive domain requires clearly defined variant models to systematically control parameters. Customers do not select parameters directly; instead, they configure vehicle features, which are internally realized through parameterization.

The absence of a structured variant model in many other domains further complicates comparisons, as requirements are directly linked to parameter values without traversing an abstract intermediary layer such as a variant tree. The result is an alternative form of parameter management which, while functional, is organized according to entirely different principles.

From the analysis and the answers to the research questions, several key insights can be derived: it became clear that the requirements and boundary conditions of the industries studied differ significantly, which is also depicted in Table 4. While one might assume that concepts could be transferred across sectors due to the shared use of ECUs and parameters, a closer look reveals substantial differences. A transfer of concepts to the automotive/commercial vehicles domain is therefore only possible to a limited extent. The study findings indicate that SPLE has been applied in several cases, as shown in D1, D2 and D4 in the SPMF—although often still involving manual tasks and maintenance steps. A transfer to the automotive industry appears fundamentally feasible but requires further investigation and adaptation to industry-specific conditions. The identified potential indicates that SPLE could substantially improve existing parameter management practices. Additionally, it was observed that some companies already apply central principles of SPLE without explicitly labeling them as such. Examples of this include the Automotive (1) & (2) case (e.g., both several maturity levels 1 and levels 2 in D1, D2 and D4), and the Commercial Vehicles (2) case (maturity level 2 and level 3 in D1, D2 and D4), where the introduction of abstract product families and product properties clearly resembles the definition of variability in the problem space.

The fact that SPLE as a term is not known or institutionalized in those companies suggests that it would be worthwhile to promote this methodology more actively in the respective industries and to demonstrate its applicability in targeted ways. This would not only contribute to methodological consolidation but also help to better leverage existing potential.

We also found out, that over time, comparable approaches to parameter management have become established in the automotive and commercial vehicle industries. These historically developed structures were largely shaped by the requirements of conventional vehicles and today show only minor differences between automotive companies. However, in the context of SDVs, these established practices are increasingly under pressure and must be further developed to meet new technological and organizational requirements.

7. Threats to Validity

In order to ensure methodological rigor, potential threats to validity of the industry study are considered. The categorization proposed by [31] is widely used in empirical software engineering and distinguishes four categories: conclusion validity, internal validity, construct validity, and external validity. Conclusion validity refers to the degree to which statistical conclusions are justified [32]. As this study is based on qualitative expert interviews rather than statistical testing, this category is less applicable. Instead, following recommendations from mixed-methods research [33], reliability is discussed as a more relevant perspective. Reliability emphasizes the consistency and reproducibility of qualitative results, which is central in interview-based studies. Accordingly, the present study considers construct validity, internal validity, external validity, and reliability as the key dimensions of validity.

7.1. Construct Validity

Construct validity refers to the extent to which the study investigates what it intends to measure [31]. A central risk in qualitative interview studies lies in misunderstandings of terminology or differing interpretations by participants. To mitigate this risk, the experts received the questionnaire in advance, which allowed them to prepare and clarify definitions internally. During the interviews, all questions were discussed in detail in a dialogical manner, enabling direct clarification of ambiguities. In addition, two authors were present in each interview—one moderating and one observing—ensuring that notes were cross-checked and potential misunderstandings addressed. This procedure aligns with recommendations for case study reliability in software engineering research [34].

7.2. Internal Validity

Internal validity relates to causal inferences that can be drawn from the study [31]. While the study does not aim to establish strict causal relationships, certain biases may still have affected the results. Examples include social desirability bias, selective disclosure due to company-internal restrictions, or potential interviewer influence. These risks were mitigated by ensuring confidentiality, guaranteeing anonymization, and by publishing results only in aggregated form. Furthermore, having two authors present reduced interviewer bias, since clarifying questions were asked independently from the moderator. Such measures are consistent with guidelines for reducing bias in qualitative empirical studies [34].

7.3. External Validity

External validity concerns the generalizability of results [31]. As the study involved companies from multiple sectors, the range of perspectives supports representativeness. Nevertheless, voluntary participation introduces self-selection bias: companies already interested in or challenged by ECU parameterization and parameter management may have been more inclined to contribute. Consequently, the findings should be understood as indicative insights from a heterogeneous set of companies, rather than as statistically generalizable results. This limitation is characteristic of qualitative survey-based research [35].

7.4. Reliability

Reliability addresses the consistency and reproducibility of the results [33]. Since the study relies on semi-structured interviews, replication is inherently limited: different researchers might obtain slightly different outcomes. Nevertheless, methodological measures were taken to strengthen reliability. All interviews followed a standardized guideline, were conducted by two researchers, and the results were documented in a structured questionnaire template. Moreover, participants validated the documented content, ensuring that the final data accurately reflected their perspectives.

A further limitation affecting reliability and data fidelity is that the interviews were not audio-recorded. Consequently, the analysis relied on detailed written documentation generated during and immediately after the interviews. This may have reduced the level of granularity available for later analysis and limited the possibility of revisiting exact formulations or subtle contextual nuances. To mitigate this risk, two researchers were present in each interview, enabling independent note-taking and immediate cross-validation of documented statements. Detailed notes were taken during and immediately after each interview by both researchers. These notes captured key process steps, tool interactions, dependencies, and expert evaluations in a structured manner, providing a sufficiently detailed basis for qualitative analysis despite the absence of audio recordings. In addition, the documented interview results were subsequently reviewed and confirmed by the respective participants.

These measures increase transparency and traceability, which are essential for reproducibility in empirical software engineering [34].

8. Conclusions

In this study, variant-based parameter management across various industries was examined. The objective was to analyze the underlying processes, identify best practices, and assess their transferability to the automotive domain. To this end, the specific boundary conditions and requirements of each industry were first gathered, and the relevant processes were systematically documented. Subsequently, the challenges faced by the respective companies were analyzed. Proven solution approaches from other industries were then compared with the automotive sector’s domain-specific challenges. However, the results revealed that direct transferability is limited due to the particular complexity and specificity of the automotive industry. In many cases, only general principles can be adopted. PLE, or more specifically SPLE, emerged as a particularly promising methodological approach for parameter management. The survey results also suggest that new and more advanced methods are needed to meet current requirements.

The findings suggest that the automotive and commercial vehicle industries tend to possess established processes and practices that have evolved over many years and exhibit structural similarities across many companies within the sector, which can also be seen in the SPMF (Figure 4) by the categorization into similar maturity levels. At the same time, it was recognized that these traditional approaches are increasingly reaching their limits in the context of SDVs and are not sustainable in their current form.

In light of the qualitative scope of this study, the findings are intended to provide directional insights and serve as a basis for future research, rather than supporting statistically generalizable claims. Against this backdrop, it would be valuable to expand this study to include new OEMs, particularly those not shaped by historically evolved structures and that have embraced the software-first paradigm from the outset. It can be expected that such companies have developed novel and innovative approaches to parameter management that are more compatible with the requirements of an SDV concept.

Future research should also explore in depth how an SPLE methodology or corresponding framework can be concretely applied to the specific context of an automotive OEM. In this regard, the challenges identified in this study, along with the associated solution strategies, should be further investigated and methodologically integrated.