=Paper=
{{Paper
|id=Vol-557/paper-5
|storemode=property
|title=Interactive Configuration of Embedded Systems Product Lines
|pdfUrl=https://ceur-ws.org/Vol-557/paper5.pdf
|volume=Vol-557
|dblpUrl=https://dblp.org/rec/conf/splc/BotterweckPK09
}}
==Interactive Configuration of Embedded Systems Product Lines==
https://ceur-ws.org/Vol-557/paper5.pdf
Interactive Configuration of
Embedded Systems Product Lines
Goetz Botterweck Andreas Polzer and Stefan Kowalewski
Lero – The Irish Software Engineering Research Centre Embedded Software Laboratory
University of Limerick RWTH Aachen University
Limerick, Ireland Aachen, Germany
Email: goetz.botterweck@lero.ie Email: {polzer, kowalewski}@embedded.rwth-aachen.de
Abstract—This paper addresses product configuration and Features Implementation
product derivation in product lines of embedded systems. We
show how domain-specific languages (DSLs), which are used to B
Engineering
Ad Cd
Domain
Mappings
describe the implementation of the product, can be translated
into configurable models with formal semantics. This facili- Feature Implementation
tates, tool support during configuration including (1) side-by- Model Components
side visualization of features and corresponding implementation
components, (2) automated reasoning to calculate consequences
of the user’s configuration decisions and (3) visual explanations
Requirements
for automatically calculated consequences. In addition, we discuss
(4) how a completed configuration can be turned into a product- Application Engineering
Product
Product Product
specific model in the domain-specific language, using negative
Configuration Derivation
variability and subsequent pruning of the implementation model.
The approach is demonstrated for product lines of embedded
systems using Simulink as an domain-specific language for the
Aa Ca
model-based engineering of embedded systems. We report on
first evaluation results with a product line of parking assistant Product Implemented
applications, including experimentation on a rapid prototyping Configuration Product
platform with a 1:5 model car.
I. I NTRODUCTION Fig. 1. Simplified Framework for Software Product Line Engineering.
Many approaches in Software Product Lines (SPL) structure
the applied models into two areas (see figure 1): A model
describing the available choices, e.g., a feature or variability inclusion of other models in the interactive configuration
model d and, one or more implementation models, which process can provide additional benefits:
describe how these choices are implemented Cd . Usually these 1) The user can see (visual representations of) dependen-
two types of models are mapped onto each other to support cies between features and the related elements in other
further techniques. models (e.g., an edge representing that the feature f1
During Product Configuration the user (i.e., a customer or requires the component c1 ).
an application engineer supporting him) decides which of the 2) When making configuration decisions (in the feature
available product options to choose. In Product Derivation, model) the user can immediately see consequences in
he generates or assembles the product implementation that related models (e.g., after the user selects the feature f1 ,
corresponds to these configuration decisions. the tool automatically selects the component c1 ).
There are well-known techniques and tools for the interac- 3) Moreover, it is possible to apply configuration decisions
tive configuration of feature models, for instance in commer- in the implementation model first (e.g., indicating that
cial tools such as pure::variants [1] or our earlier work on the implementation component c1 will not be available)
interactive configuration with formal semantics [2], [3]. and derive implications for the feature model from that
Interestingly, during product configuration the developer (f1 is no longer an option).
typically configures the feature model d only – even though In this paper, we address this side-by-side configuration
the mappings between the feature model and other SPL models by integrating the implementation model into the configu-
are available . Interaction with the implementation models Cd ration process. This allows us to provide the functionality
is usually not provided at this stage. sketched above. To further motivate our research, we will first
While there might be good reasons to abstract from the use a sample case from product lines of embedded systems
implementation deliberately (e.g., to hide complexity), the (section II). We will then explain our approach (sections III
Eclipse‐based Models Implementation DSL
Ad Bd Cd Domain 1 Dd Domain
Feature
Mapping Simulink mdl2sl Simulink
Model Transformation
Model Model Model
(*.fm)
(*.sl) (*.mdl)
Domain Engineering
2
sl2fm
Transformation
SPL Integrated SPL Model (as *.fm)
Ai Bi Ci
Domain
Feature Mapping
Simulink
Model Model
Model
Requirements
3 4
Product
Product Product
Configuration Derivation
Application Engineering
Aa Ca Application 5 Da Application
Feature Simulink sl2mdl Simulink
Configuration Model Generator Model
(*.sl) (*.mdl)
6
Code
Generation
Executable
Program
Fig. 2. Overview of our approach.
to VI). The paper concludes with a discussion (section VII), control (observed by the sensors, influenced by the actuators)
an overview of related work (section VIII) and some final is called the plant. The whole system (consisting of sensors,
remarks. controller, actuators, and the plant) is called a control loop [4].
II. S AMPLE C ASE : E MBEDDED S YSTEMS IN C ONTROL When developing the code for such a controller, the main
E NGINEERING requirements are the reaction time, the input-output stability
As a sample case for this paper, we want to apply Software and the control error. The behavior of the control loop depends
Product Line techniques to the domain of control engineering. on both the controller and the plant. To understand the
Such control system are typically developed using model- behavior of the plant and the controller, models of both are
based tools like Matlab/Simulink. They can be considered as developed in a first step. These models are improved using the
(or implemented as) a special form of embedded systems. results of simulation.
The task of a controller is to influence an environment with If the desired behavior is achieved, a next development step
actuators to achieve a certain behavior. To this end, the con- is performed. The model of the controller will be translated
troller gathers information of the environment using sensors. to source code and executed using a prototyping hardware.
With the information provided by the sensors the controller During this development step either a prototyping plant or a
uses the actuators to influence the controlled environment. In real-time model of the plant is influenced by the controller.
many cases, the part of the environment that is the object of In this development timing requirements can be observed and
tested. further processing with Eclipse-based frameworks, such as
During the third development step the controller code is the numerous frameworks from the Eclipse Modeling Project
executed on the real product hardware. This is the first time (EMP) [7] or openArchitectureWare (oAW) [8].
the real plant (and not the simulated one) is tested with the To enable the integrated configuration of feature and im-
controller. Cost and safety issues are the main reasons for the plementation models, we transform these models and the
late testing with the real plant. One important task during this mappings between them into an integrated SPL model .
stage is to optimize the controller. To this end, the controller The basic idea is to represent all configurable parts of the
has parameters that can adopted until the control loop finally product line (feature selected? component present?) as one
meets the requirements. large feature tree, where different subtree represent different
To built such systems, model-based design is a common SPL models. So, for instance, we can have one subtree with
engineering practice. Simulink is a very well-known example the real feature model i and one subtree representing the
of a domain-specific modeling language for embedded sys- configuration status of components i , as well as mappings
tems, including corresponding tools. Using such development and between them i . This enables us to interactively configure
frameworks is one way to tackle the increasing complexity. the whole product line within one integrated model.
While this is already a nice foundation, in an industrial This translation is realized by an model transformation
context we require additional techniques that help us to build in ATL (Atlas Transformation Language) [9]. It applies an
whole product lines of such systems. To this end, model- semantic interpretation of the domain-specific concepts in the
based design techniques for embedded systems are extended Simulink model, translating them into feature model elements,
with mechanisms for variability and model-driven product which make up the integrated SPL model . Some rules
derivation. for translation are shown in Table I for the Simulink model
We discussed some concepts and techniques for this in [5], (translating from Cd to i ) and Table II for the mapping model
[6] where we extend domain specific implementation models (translating from d to i ).
with variability. In this paper we focus on how feature models
Representation within
and the related implementation models can be combined to Simulink Cd the integrated
support their integrated, interactive configuration. (concepts in the meta-model) SPL model i
Simulink Model m mandatory feature f (m)
III. OVERVIEW OF OUR A PPROACH System s optional feature f (s)
Block b optional feature f (b)
Before we explain the details of our approach, we first
contained blocks/systems subfeatures
want to give an overview as an orientation for the reader, see in blocks/systems
figure 2. Similar to common SPL Engineering methods our Line from block a f (b) requires f (a)
approach can be structured into Domain Engineering (upper to block b but not vice-versa
layer) and Application Engineering (lower layer). TABLE I
T RANSLATION FROM S IMULINK TO THE INTEGRATED SPL MODEL
The overall goal of this process is to turn a product line
implementation Dd (upper right corner of figure 2) into an
product-specific implementation Da (lower right corner) and
finally an executable program. Representation within
To support common techniques and processes from Embed- Mapping d the integrated
(concepts in the meta-model) SPL model i
ded Systems Engineering, we integrated our approach with
Feature f mapped to f (f ) requires f (c)
the domain specific language Simulink. Hence, the chain of component c
processes to begins in the Simulink world (right-hand
TABLE II
side of figure 2) moves over ( ) to the Eclipse-based Models T RANSLATION FROM MAPPING MODEL TO THE INTEGRATED SPL MODEL
(left-hand side), which are configured and processed. Finally,
by code generation ( ) we return to the implementation DSL.
In the following sections we will now discuss these processes The elements created in the target model are fine
in more detail. grained elements of a feature model, which we call feature
model primitives. Examples for such feature model primi-
IV. D OMAIN E NGINEERING tives are f1 -hasOptionalSubfeature-f 2, f3 -requires-f4 or f 1-
For the context of this paper, we will assume that most hasBeenSelected. These primitives have clearly defined se-
processes, which are necessary to create the product line mantics, including the corresponding behavior of our S2T2
artefacts ( d to Dd ) have already been performed. See [5] for Configurator tool during interactive configuration. These
more details. semantics are given by further translation of the feature model
Those processes that are of interest here, start off with the primitives into propositional logic. For instance, f3 -requires-
mdl2sl transformation , which converts the implementation f4 would be translated into ¬f3 ∨f4 . Details of this translation
given in Simulink’s native .mdl format Dd into an correspond- can be found in [2].
ing Eclipse-based implementation model Cd . Subsequently, we In summary, the transformations provide the following re-
are able to map this model to the feature model and perform sult: We now have (1) an integrated model presenting features,
List of feature model primitives Interactive Feature Graph
f1 exludes f3 User asking why c2 is
automatically selected
f2 requires f3 f1 is implemented by c1
Visual explanations:
Eliminated feature f2 is implemented by c2 user selected f3 and
f3 requires c2
Selected feature
Fig. 3. The S2T2 Configurator showing an integrated SPL model during configuration.
their implementation, and relations between them in one model exclusive; f2 requires f3 ). The features and components are
and (2) this model can be used in an interactive configuration connected via requires edges, which represent that features are
tool. implemented by certain components.
V. P RODUCT C ONFIGURATION
In the example, the user decided earlier that f2 is eliminated
After converting the given SPL artefacts into one integrated and f3 is selected (this is indicated by the red cross in front
model, we can use our tool S2T2 Configurator to per- of f2 and the green check mark in front of f3 ). From these
form an interactive configuration . decisions and information in the model the tool derived that,
Whenever a model is loaded, the Configurator internally f1 has to be eliminated and c2 has to be selected. In the
transforms it into a formal representation, which is used by a screenshot, the user just asked why c2 was selected (see the
reasoning engine to keep the configured model in an consistent open context menu). The tool responded by highlighting f3 ,
state, to calculates consequences of the user’s decisions and, c2 and the requires edge between them.
on demand, and to provides visual explanations for such
consequences [2].
Figure 3 shows the Configurator with a very simple model We can apply this tool to handle more realistic models,
with just three features f1 to f3 (left-hand side) and two which have been derived from a real Simulink implementa-
components c1 and c2 (right-hand side). Within the feature tion model (using the model transformation briefly explained
model, we have two dependencies (f1 and f3 are mutually earlier).
Feature Model Implementation Model (Simulink)
Feature‐Implementation Mappings
Subsystem 1
Application bus bus
separator creator
i1 o1
Block 2
i2 Block 3 o2
Feature 2
(optional,
(eliminated)
i3 eliminated) o3
Feature 1 o4
i4 Block 4
(selected)
(optional,
i5 selected) Block 5 o5
switch
i6 o6
Fig. 4. Pruning of models.
VI. P RODUCT D ERIVATION corresponding implementation blocks are connected to the
Given the product configuration a we now have to turn same port of a third block. This pattern is not a legal Simulink
this into an executable product. In the overview in figure 2 model, because Simulink does not know anything about the
this corresponds to the process of Product Derivation . alternative group and the elements which will be removed later
to obtain a legal model.
A. Negative Variability Hence, to create and test such a model within the Simulink
The first step towards the executable product is the deriva- tools, we have to introduce helper mechanism like Switch
tion of the Application Simulink Model Ca . blocks. When we later apply negative variability, these helper
Here, we apply a well-known technique called negative mechanisms have to be adapted (or removed) as well. An
variability: The Domain Simulink Model Cd contains the union example is depicted in the figure 4, where two signals lead
of all possible product-specific Simulink Models Ca . Based into Block 5 and are handled by a switch block. Whenever,
on the configuration decisions in the product configuration a only one of these two signals is left, we can remove the switch
we then copy the Simulink models while filtering out all block altogether.
elements, which correspond to eliminated features. Hence, the A second situation, where we have to adopt additional
term negative variability. components in the Simulink model are Bus elements. These
This technique can, for instance, be implemented with ATL elements allow to combine multiple signals into one logical
model transformations (as demonstrated in earlier work [10]) bus, to simplify the model (Bus Creator). In a different
or with openArchitectureWare’s XVar component. For the location in the same model, such a bus can again be separated
approach discussed here we are currently experimenting with into the single signals (Bus Separator). Whenever we apply
a connector that connects our Configurator to openArchitec- negative variability, some signals within these buses might
tureWare [8]. have to be removed (because the blocks providing these signals
are no longer present). Hence, we have to adapt the bus. See
B. Pruning the bus creator and bus separator in figure 4. In the given
The technique of negative variability is a first step, but it example, the signals i3 , o2 and o3 could be pruned.
is not sufficient to get a consistent model. We will briefly
discuss two situations, where we have to adapt more than just VII. D ISCUSSION
removing some affected blocks. In this work we implemented an approach, where we
The first situation arises with alternative features. With combined the feature, the mapping, and the implementation
such alternative groups of features, often the outputs of the model into one big feature model. To this end, we transformed
Compass
Rear Brake
Throttle Steering
Rear Velocity
Front Brake
Sensor
Front Velocity
Sensor
Front Distance
Sensors
Side Distance Sensor Microcontroller Housing
Fig. 5. The model car of the VeRa Rapid Control Prototyping platform.
the Simulink blocks of the implementation model into features realistic Simulink models and evaluate the configuration ap-
and the mappings into constraints between the features and the proach.
blocks represented as features. During the implementation we made the experience that
We experimented with this approach by using a product line Simulink is less strict about the syntax and the contents of
of parking assistant applications, which is implemented using values and parameters. This causes problems during transfor-
a Simulink model and a Rapid-Control-Prototyping system mation because the mechanisms further down the tool chain,
called VeRa. The model of the parking assistant can be simu- such as Eclipse Modeling Framework (EMF, for handling
late within Simulink or executed on a 1:5 model car, which is models), ATLAS Transformation Language (ATL, for trans-
shown in figure 5. The application contains variability because forming models) and our Configurator are more strict about
of alternative distance sensors and an optional compass sensor, values.
which helps the car to orientate itself in a parking bay. For instance, it is perfectly legal to name a Block ”S-
This model contains a large number of blocks, subsystems Function” in Simulink, actually including the quotes in the
and buses. Two parking algorithms are implemented to deal value. However, this will lead to technical problem when
with the variability: One which uses the compass information converting this to an EMF model. Similarly, Simulink does
and one without this information. not care if names of blocks are unique. In EMF, however,
The transformation of a big Simulink model like our parking it is desirable to have unique names since these are used as
assistant into a feature model does not need remarkable time. identifiers in references.
So scalability in terms of execution time of the transformation
seems to stay in reasonable bounds. VIII. R ELATED WORK
However, for larger models, during configuration the cog- In earlier work we presented the basic architecture of the
nitive complexity and usability become an issue. Some tech- configurator [2] and discussed interaction techniques [3]. Here
niques how to mitigate these problem with interaction tech- we extend this work by (1) a new approach of visualizing
niques introduced to our S2T2 Configurator have been features and implementation, (2) using a configured feature
described in [3]. Up to now, we do not know if our approach model for product derivation and (3) pruning approaches
scales in terms of usability. Hence, we intend to use large, to adapt the implementation model. The whole approach is
evaluated using a parking assistant as application and a tool In future work, we intend to improve (1) the product
chain using a Rapid Control Prototyping System. derivation mechanisms, including the connector which links
Approaches which are related to our work can be roughly our Configurator to openArchitectureWare and (2) the model
grouped in two categories, (1) approaches to deal with variabil- transformation that implements the pruning.
ity in domain-specific languages and (2) approaches to model
X. ACKNOWLEDGMENTS
variability in model-based development with Matlab/Simulink.
Weiland [11] addresses the challenges of variability in This work is partially supported by Science Foundation
Matlab/Simulink. He uses marked standard Simulink blocks Ireland under grant no. 03/CE2/I303 1 to Lero – The Irish
like switches to represent the different choices. Hence, the Software Engineering Research Centre, http://www.lero.ie/.
Simulink model contains the whole variability, a variant is then R EFERENCES
chosen by setting the corresponding parameters and selecting [1] D. Beuche, “Modeling and building software product lines with
a specific signal path. pure::variants,” in 12th International Software Product Line Conference
Kubica [12] starts from a feature model modeled in (SPLC 2008), Limerick, Ireland, September 2008. [Online]. Available:
http://doi.ieeecomputersociety.org/10.1109/SPLC.2008.53
pure::variants, where the developer has to choose the desired [2] G. Botterweck, M. Janota, and D. Schneeweiss, “A design of a
features. Subsequently, the corresponding Simulink model configurable feature model configurator,” in Proceedings of the 3rd
is build automatically from templates and fragment models International Workshop on Variability Modelling of Software-Intensive
Systems (VAMOS 09), January 2009. [Online]. Available: http:
stored in the configuration tool. //www.vamos-workshop.net/proceedings/VaMoS 2009 Proceedings.pdf
There are other approaches, which are dealing with domain- [3] G. Botterweck, D. Schneeweiss, and A. Pleuss, “Interactive techniques
specific techniques as well. For instance, Voelter and Gro- to support the configuration of complex feature models,” in 1st
International Workshop on Model-Driven Product Line Engineering
her [13] describe how to use openArchitectureWare [8] for (MDPLE 2009), held in conjunction with ECMDA 2009, Twente, The
Software Product Line Engineering. They use aspect-oriented Netherlands, June 2009. [Online]. Available: https://feasiple.de/public/
and model-driven methods to generate products. To evaluate proceedings-mdple2009.pdf
[4] J. Lunze, Regelungstechnik 1. Springer, 2004.
their approach they discuss a product line of Smart Home [5] A. Polzer, S. Kowalewski, and G. Botterweck, “Applying software
applications. product line techniques in model-based embedded systems engineering,”
When dealing with variability, a typical challenge is the in 6th International Workshop on Model-based Methodologies for
Pervasive and Embedded Software (MOMPES 2009), Workshop
mapping of features or variation points to their implementa- at the 31st International Conference on Software Engineering
tion. Czarnecki and Antkiewicz [14] used a template-based (ICSE 2009), Vancouver, Canada, May 2009. [Online]. Available:
approach where visibility conditions for model elements are http://doi.ieeecomputersociety.org/10.1109/MOMPES.2009.5069132
[6] A. Polzer, G. Botterweck, and S. Kowalewski, “Variabilität im mod-
described in OCL. Heidenreich et al. [15] present FeatureMap- ellbasierten Engineering von eingebetteten Systemen,” in 7. Workshop
per, a tool-supported approach which can map features to Automotive Software Engineering, 2009.
arbitrary EMF-based models [16]. [7] Eclipse-Foundation, “Eclipse Modeling Project.” [Online]. Available:
http://www.eclipse.org/modeling/
[8] “openArchitectureWare homepage.” [Online]. Available: http://www.
IX. C ONCLUSIONS openarchitectureware.org/
[9] Eclipse-Foundation, “ATL (ATLAS Transformation Language).”
In this paper, we presented an approach to the configuration [Online]. Available: http://www.eclipse.org/m2m/atl/
of product lines within an existing tool for feature configura- [10] G. Botterweck, L. O’Brien, and S. Thiel, “Model-driven derivation of
product architectures,” in Proceedings of the twenty-second IEEE/ACM
tion. international conference on Automated software engineering (ASE
The necessary translation from the implementation model 2007), Atlanta, GA, USA, 2007, pp. 469–472. [Online]. Available:
into feature models and the targeted feature modeling lan- http://dx.doi.org/10.1145/1321631.1321711
[11] J. Weiland and E. Richter, “Konfigurationsmanagement variantenreicher
guage, present some limits with respect to expressive power. simulink-modelle,” in Informatik 2005 - Informatik LIVE!, Band 2.
We can only “translate” model structures that are related to Koellen Druck+Verlag GmbH, Bonn, September 2005.
configuration, such as selection/elimination or x−requires−y [12] S. Kubica, “Variantenmanagement modellbasierter funktionssoftware
mit software-produktlinien,” Ph.D. dissertation, Universität Erlangen-
dependencies. More domain-specific concepts, e.g., voltages Nürnberg, Institut für Informatik, 2007, arbeitsberichte des Instituts für
or oscilloscopes cannot be represented in a feature model in Informatik, Friedrich-Alexander-Universität Erlangen Nürnberg.
a meaningful way. [13] M. Voelter and I. Groher, “Product line implementation using
aspect-oriented and model-driven software development,” in 11th
On the other hand, this translation enables us to configure International Software Product Line Conference (SPLC 2007), Kyoto,
an integrated model of the whole product line within one Japan, September 2007. [Online]. Available: http://www.voelter.de/data/
configuration tool. In particular, it provide the functionality pub/VoelterGroher SPLEwithAOandMDD.pdf
[14] K. Czarnecki and M. Antkiewicz, “Mapping features to models: A
described in the introduction: template approach based on superimposed variants,” in GPCE’05,
1) The user can browse dependencies between features and Tallinn, Estonia, September 29 - October 1 2005. [Online]. Available:
http://dx.doi.org/10.1007/11561347 28
the related elements in other models. [15] F. Heidenreich, J. Kopcsek, and C. Wende, “Featuremapper: Mapping
2) After applying configuration decisions he/she can im- features to models,” in ICSE Companion ’08: Companion of
mediately see consequences in related models. the 13th international conference on Software engineering. New
York, NY, USA: ACM, 2008, pp. 943–944. [Online]. Available:
3) It is possible to apply configuration decisions in the http://doi.acm.org/10.1145/1370175.1370199
implementation model first and derive implications for [16] Eclipse-Foundation, “EMF - Eclipse Modelling Framework.” [Online].
the feature model from that. Available: http://www.eclipse.org/modeling/emf/