Improving Efficiency when Deriving Numerous Products from Software Product Lines Simultaneously

In-car infotainment systems must allow for product differentiation and the adaption to the needs of different markets. Product line approaches are applied because large numbers of different product variants need to be developed simultaneously. During development, updated versions of each projected product variant need to be derived from the product line assets repeatedly. Current build tools create each of the numerous product variants one after another. Accordingly, the creation process can take much time. This paper presents an approach to abbreviate this creation process based on the fact that multiple product variants created at once can have parts in common. To benefit from this optimization potential the workflow that creates an individual product variant is subdivided into multiple fragments. Whenever a set of such product variants needs to be created, an optimization algorithm then calculates an individual execution order of the fragments for this set. This order minimizes the total execution time by a systematic reuse of workflow fragment’s results for the creation of multiple different product variants.


The increasing use of software in modern cars challenges the automotive industry. Development productivity needs to be improved because larger software projects need to be developed in shortened time frames and within unchanged budgets. This fact is particularly true for in-car infotainment systems as they are offered in multitudes of variants and possess the most complex software and the shortest product life cycles compared to other automotive embedded systems. Suppliers as well as the car manufacturers (OEM) therefore try to reduce the development efforts by reusing as much software components as possible in multiple products. However, higher margins for particular products or brands are achievable only if they allow for differentiation [8]. This calls for a customized user interface (HMI) software for each product adapted to different brands, languages, markets, car models, or configurations. The individually required development efforts need to be reduced in order to raise the productivity in the development process. Software product lines are used because they enable for flexibility and productivity at the same time [3].

Example of an Infotainment System’s Production Plan

A production plan describes how the product variants derive from the product line’s core assets. It includes tasks similar to those in a standard build process. In order to create an automotive infotainment HMIs it may start with combining a basic software platform and additional modules from the OEM and suppliers. These modules are chosen depending on the desired features (e. g., car navigation or digital radio). If model-driven development is applied, parts of the module’s source code may need to be generated. The selection of different modules, models and generators is an appropriate technique to provide for brand specific operational concepts (e.g., touch screens vs. controllers in the center console). After the base software has been assembled in such a way, it then can be further tailored by adding configuration files and other resources. By this means, it is adapted to market-specific requirements. Pictures of the car shown in the HMI, for instance, are added according to the model, the vehicle category, or the exterior color. Furthermore, depending on the country, appropriate translation files for the HMI are included.

It is essential to automate such derivation processes in order to reduce manual work and achieve reproducible results. This can be achieved by formalizing the production plan using build scripts or build management systems. When multiple product variants are to be created, the corresponding build script of each single product variant is executed one after another to run its derivation process.

Reducing Time Effort when deriving multiple Product Variants simultaneously

Typical development processes of infotainment system HMIs are structured iteratively. During these processes updated versions of the numerous prospected product variants have to be created regularly for usability evaluation and early error-detection. However, because of the complexity of modern infotainment systems, running the derivation process for a single product variant can take hours. If multiple product variants are developed simultaneously, and therefore huge numbers of them need to be created repeatedly, the time effort becomes problematic. This is because the conventional approach does not taken into account that product variants created at once can have parts in common. During development of automotive HMIs such sets of similar product variants are created when localization is to be tested and full-featured product variants in different languages are required. Furthermore, car manufacturers typically deploy new products in one region after another. The feature sets and translations of the infotainment system’s regional variants are equal to a large extend. Shortly before a regional roll-out, repeated builds of these similar software variants are required because development and testing efforts are focused on them.

In this paper, an approach is presented, which reduces the time required to automatically derive a set of product variants sharing common parts. This is achieved by splitting up the derivation process of a single variant into multiple fragments. These fragments are then reordered automatically by an algorithm that identifies those fragments that create equal software parts in multiple variants within the current set. Instead of executing them repeatedly, it reuses the results of a previous execution.

Related Work

The model-driven development of software product lines has already been investigated. The authors focus on variability modeling in domain engineering (e.g., in [10,7]). However, because deriving individual products from the shared assets is a time consuming and expensive activity [4] there is also much optimization potential in application engineering. Rabiser et al. provide an overview of the current state of research in this field [11]. The tools and techniques used to assemble a specific product significantly impact the efficiency and cost of the product line development effort [3,2]. A high level of automation is crucial in the case of large a number of variants and high frequency of variant production [3,1]. Different research projects concerning build tools for model-driven software development are presented by Kleppe [9]. Wagelaar generates build scripts from workflow fragments, which are described using domain-specific languages [13]. However, the distinctive requirements of software product lines are not considered. Elsner et al. evaluate the applicability of different build tools as product generation facility in model-driven product-lines [6]. They split up the workflow into fragments separated by concern and map them to variable features of the product line. Model-weaving is used to put fragments together creating a build script for the generation of a single product variant. This approach cannot tap the optimization potential by reusing previous results of the generation process when creating multiple product variants at once. Furthermore, the application of model-weaving requires a meta-model of the targeted scripting language [6]. However, this may not be on-hand, it may be expressed in an unsuitable technology, or it can be unknown. A redevelopment exclusively for this purpose is expensive. The approach presented in this paper avoids this drawback.

Abbreviating Derivation Processes through Reuse

As previously described, a production plan can be formalized using build scripts. However, using a separate script for each product variant can lead to high maintenance efforts. It is therefore beneficial to use a single generic script for large product families that describes the derivation of all product variants from the product line assets. However, in order to create specific variants, additional information needs to be provided. This information configures the generic workflow leading to the execution of different concrete workflows for each individual product variant. The required information can be provided by the variant configuration.

The process described in this generic script can be regarded as a course of several steps called fragments. When creating groups of product variants, these workflow fragments are executed repeatedly. However, if they are configured the same way and operate on the same input data, they will lead to the same results. Efficiency can be boosted, if such fragments are called only once and its results are reused whenever possible. This reduces computation efforts and lowers the overall time required when creating groups of product variants. The larger and the more similar these groups are, the more results can be reused and the more time can be saved.

Required Information for Automated Analysis

In order to reuse as much results as possible, an optimized execution order of the workflow fragments needs to be determined. In smaller projects this order can be identified manually and the workflow fragments can be run accordingly. But if numerous product variants and fragments exist and frequent changes occur, this process becomes too complex and the effort required is no longer acceptable. Therefore, in large industrial projects such as those for developing infotainment systems this task requires automation.

This can be done by means of automated analysis. The optimization algorithm needs to determine which execution of a fragment can be replaced by reusing results of a previous execution for creating another variant. This requires knowledge about the differences and similarities of the product variants which can be found in their variant configurations. Furthermore, it needs to be known which fragment is configured by which information from the variant configuration. Also, the data- and control-flow in the build process leads to dependencies between the fragments. As they constrain their execution order they need to be taken into account when reordering the fragments.

DSLs to describe Variability, Variant Configurations and Workflow Fragments

In order to be able to evaluate the approach, a textual DSL has been developed to express the information required by the optimization algorithm. In future versions, the information may automatically be determined from existing artifacts by means of tool specific adapters (already done in tools like SCons).
In Fig. 1 the DSL is used to provide the required meta-information for a workflow fragment. Furthermore, a set of product variants is defined that is built simultaneously.

Two simple textual DSLs have been developed that allow describing the variability of a product line (variant declaration) and the configuration of the derived products (variant configuration).

step WriteNavigationConfiguration for InfotainmentSystemFamily invokes "buildScript_writeNavConfig.xml" {
  passing // Define the required feature values...
    hasNavigation as "navigation", // ...and how they are passed...
    streetFirst as "streetFirst"; // the build script
  after // Relies on the outcome of another workflow fragment...
    CollectModules; // it need to executed after that
build allEuropeanVariants for InfotainmentSystemFamily {
  build // The variants included in this build 
    Highline_EUR_NL in "Highline_NL",
    Highline_EUR_DE in "Highline_DE",
    Highline_EUR_GB in "Highline_GB";
  steps // The workflow fragments to be executed for each variant
    CollectModules, // Not shown in example
    CopyTranslation, // Not shown in example
    WritePartNo, // Not shown in example
    CreateJAR; // Not shown in example
Figure 1. Defining a workflow fragment and a set of product variants

In infotainment system families multiple product variants contain the same basic software modules, but differ in particular restrained facets (e.g., systems with the same basic features are offered with different brand-specific skins or different languages). Accordingly, major parts of their variant configurations are also identical. The redundancy is error-prone and requires additional maintenance effort, especially if numerous product variants need to be managed. For that reasons, the DSL to define product variants uses a concept of inheritance which is known to developers by its usage in programming languages. It allows defining equal parts of multiple variant configurations in their common ancestors. A valid variant configuration results from adding the remaining variant-specific information to the basic inherited information. Derived values can also be overridden by new values. Such inheritance hierarchies can consist of multiple levels. A set of variants is described as a tree of hierarchically inheriting variant configurations.

The syntaxes of each of these DSLs follow popular programming languages. They therefore look familiar to developers and can be picked up by them without difficulty. In contrast to the popular graphical notation of feature models [5], these DSLs use textual notations. This can simplify their usage, as no specific editors or diff-/merge-tools are required and their models can be managed easily in version control systems [12].

Fig. 2 shows a description of an infotainment system product line’s variability and the configuration of four different product variants.

// The declaration introduces the variation points
declaration InfotainmentFamily { 
  declare partNo; // A variant-specific identifier
  declare hasNavigation overidable; // Has navigation module
  declare hasPhone overidable; // Has phone module
  declare digitalRadio overidable; // Type of digital radio
  declare streetFirst overidable; // Enter street first?
  declare language; // The language of the HMI
// The variant configurations assign values to the variation points 
abstract configuration Highline for InfotainmentFamily { 
  define hasNavigation = "TRUE"; 
  define hasPhone = "TRUE";
  define streetFirst = "FALSE";

configuration HL_NAR_US extends Highline for InfotainmentFamily {
  define digitalRadio = "SDARS,Sirius"; 
  define language = "en";
  define streetFirst = "TRUE"; // Overrides inherited value
  define partNo = "875533.214.US";

abstract configuration HL_EUR for InfotainmentFamily {
  define digitalRadio = "DAB"; // Digital radio in europe is DAB 

configuration HL_EUR_GB extends HL_EUR for InfotainmentFamily {
  define language = "en";
  define partNo = "391280.321.GB";

configuration HL_EUR_DE extends HL_EUR for InfotainmentFamily {
  define language = "de";
  define partNo = "123412.123.GE";

configuration HL_EUR_NL extends HL_EUR for InfotainmentFamily {
  define language = "nl";
  define partNo = "1214111.130.GN";
Figure 2. Variability description and variant configurations

Optimization Algorithm

Based on the information provided using the DSLs, an algorithm calculates an optimized execution order of the fragments for a given set of product variants. This order reduces the total number of fragment executions while complying with the stated dependencies and constraints. The current implementation is rather simple but provided good results in the prototypes it was tested with. It consists of the following steps (Fig. 3):

Figure 3. Optimization Workflow

First of all it determines the workflow fragments (A to E) and variant configurations (1 to 4) included in this build. They are places inside trees ordered according to their inheritance hierarchy respectively ordering constraints (1). Both trees are then simplified for subsequent processing (2). Each workflow fragment is then linked to the top-most element in the tree of variant configurations that provides all required feature values (3). In the final step, the workflow fragments are rearranged in a way that all their ordering constraints are fulfilled (4). Optionally, the resulting tree can be flattened if the targeted build tool doesn’t support parallelization.

Using the Results in Build Tools

There are various standard build automation tools available (e.g., ANT, MWE, SCons, make), which can be applied to generate the product variants from the product line assets. The technology for each project and purpose has to be selected individually as each of these tools offers different advantages and a different set of functions. However, especially those which are applicable in model-driven development still undergo major modifications [6]. It is not reasonable to limit the applicability of the optimization algorithm to a specific technology or tool. Therefore, the algorithm was implemented as a model-to-model (M2M) transformation, writing its outcome to a tool independent result model. This model then is processed by a tool-specific transformation, which converts it to the format required by the chosen build tools, e.g. a scripting language. The build tool is then employed to actually perform the generation of the product variants using this input (Fig. 4).

Figure 4. Models and transformations in the selected approach

This approach allows enhancing different build tools with the capability to run the fragments in the optimized execution order. There is no need to adapt the build tools as all required information is provided using their standard input format. The optimization algorithm can be implemented independently of the build tool. Furthermore, the tool-specific transfer of the results requires little effort. Such tool-specific transformations were written for ANT and MWE to prove the applicability and to serve as an example. Based on the tool-independent result models, they both create an executable code in the tool specific scripting languages. When this code is run in the appropriate build engine, the fragments are executed in the calculated order. The technology specific transformation also adapts the results to the features provided by the build tool: In the case of ANT, its capabilities to parallelize parts of the workflow are used, whereas in MWE all fragments are executed sequentially.

Drawbacks and Limitations

Using this approach, time saving can be achieved when larger sets of product variants are created at once and some of them share commonalities. However, for single product variants created one after another, additional complexity occurs. The approach also requires that the outcomes of each execution of a workflow fragment are savable and can be restored when deriving other variants. In order to reduce the time effort, the optimization algorithm needs to decide on the optimum order of the fragment without being restrained by lots of dependencies between the fragments. Because of that, the workflow fragments need to be implemented in a way that they can be executed in different orders. Couplings between the fragments should to be avoided, e.g., relying on the outcomes of other fragments. Since in existing workflows that is often not the case, splitting them up and migrating them to this technique can be challenging.

Summary and Outlook

If large numbers of similar product variants are developed simultaneously, the usage of conventional variant management and build automation requires the cumbersome configuration of redundant information in variant configuration and leads to time-consuming build processes. This paper presents an approach to accelerate such build processes by reusing intermediate results. It is based on splitting up workflows into fragments. The workflow fragments required for building a given set of product variants are then reordered accordingly by an optimization algorithm. Its results can be used with different build tools.
In the future, it has to be investigated whether this approach is also applicable in connection with build tools like Maven, which determine the execution order of the working steps by themselves. Furthermore, the optimization algorithm has to be further improved in order to attain better optimization results. The current one reduces the total number of fragment executions. In the future, the optimization might also take the computation effort of each workflow fragment into account. As they serve for evaluation purposes only, the DSLs that have been used for variability description and variant configuration are still very basic. The DSL was tested in an infotainment system family consisting of 25 product variants. The extent of their variant configurations could be reduced by 74% by using the concept of inheritance. However, it became obvious, that for applicability in practice, additional information needs to be provided, which cannot be expressed with the DSL so far, e.g., each attribute needs to be assigned to a data type and its range of values needs to be limited. Moreover, the variability of the product line cannot be restricted. Prospectively, it has to be investigated how the ideas of this paper can be used in conjunction with the popular feature models [5].


  1. Beuche, D.; Dalgarno, M. 2006. Software Product Line Engineering with Feature Models. In: Methods&Tools 14 (4), 9–17.
  2. Chastek, G. J.; Donohoe, P.; McGregor, J. D. 2004. A Study of Product Production in Software Product Lines. Carnegie-Mellon University, Pittsburgh. SEI.
  3. Clements, P.; Northrop, L. 2001. Software Product Lines, Practices and Patterns. Addison Wesley, Boston.
  4. Deelstra, S.; Sinnema, M.; Bosch, J. 2005. Product derivation in software product families: a case study. In: Journal of Systems and Software (74), 173–194.
  5. Czarnecki, K. 1998. Generative Programming. TU Ilmenau.
  6. Elsner, C.; Lohmann, D.; Schröder-Preikschat, W. 2008. Towards Separation of Concerns in Model Transformation Workflows. In: Thiel, S.; Pohl, K. (Ed.): Proceedings of the 12th SPLC (Limerick, Ireland, September 8-12, 2008). Limerick: University, 81–88.
  7. Elsner, C.; Lohmann, D.; Schwanninger, C. 2009. Eine Infrastruktur für modellgetriebene hierarchische Produktlinien. In: Liggesmeyer, P.; Engels, G.; Münch, J.; Dörr, J.; Riegel, N. (Ed.): Software Engineering 2009. Bonn: Köllen Verlag (LNI, 143), 107–113.
  8. Hüttenrauch, M.; Baum, M. 2008. Effiziente Vielfalt. Berlin: Springer.
  9. Kleppe, A. 2006. First European Workshop on Composition of Model Transformations – CMT 2006. Bilbao, 2006.
  10. D. Muthig, C. Atkinson, Model-Driven Product Line Architectures. SPLC2, 110-129, 2002.
  11. Rabiser, R.; Grünbacher, P.; Dhungana, D. 2010. Requirements for product derivation support. Results from a systematic literature review and an expert survey. In: Journal Information and Software Technology 52 (3).
  12. Völter, M. 2010. Architecture as Language. In: IEEE Software 27 (2), 56.
  13. Wagelaar, D. 2006. Blackbox Composition of Model Transformations using Domain-Specific Modelling Languages. In: Kleppe, A. Proceedings of the First European Workshop on Composition of Model Transformations (Bilbao, July 10, 2006, Bilbao).


The full paper can be downloaded at ACM.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: