-This paper addresses product configuration and product derivation in product lines of embedded systems. We show how domain-specific languages (DSLs), which are used to describe the implementation of the product, can be translated into configurable models with formal semantics. This facilitates, tool support during configuration including (1) side-byside visualization of features and corresponding implementation components, (2) automated reasoning to calculate consequences of the user's configuration decisions and (3) visual explanations for automatically calculated consequences. In addition, we discuss (4) how a completed configuration can be turned into a productspecific model in the domain-specific language, using negative 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 model-based engineering of embedded systems. We report on first evaluation results with a product line of parking assistant applications, including experimentation on a rapid prototyping platform with a 1:5 model car.
I. INTRODUCTION
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 model d and, one or more implementation models, which describe how these choices are implemented Cd. Usually these two types of models are mapped onto each other to support further techniques.
During Product Configuration the user (i.e., a customer or an application engineer supporting him) decides which of the available product options to choose. In Product Derivation, he generates or assembles the product implementation that corresponds to these configuration decisions.
There are well-known techniques and tools for the
interactive configuration of feature models, for instance in
commercial tools such as pure::variants [
Interestingly, during product configuration the developer typically configures the feature model d only – even though the mappings between the feature model and other SPL models are available . Interaction with the implementation models Cd is usually not provided at this stage.
While there might be good reasons to abstract from the implementation deliberately (e.g., to hide complexity), the g ian iren oDm igenn
E g n i r e e n i g n E n o i t a c li p p A s t tc en rPduo ireuq m e R
Ad Aa
Cd
In this paper, we address this side-by-side configuration by integrating the implementation model into the configuration process. This allows us to provide the functionality sketched above. To further motivate our research, we will first use a sample case from product lines of embedded systems (section II). We will then explain our approach (sections III g n i r e e n i g n E n i a m o D g n i r e e n i g n E n o i t a c i l p p A
Ad Feature
Model (*.fm) s t tc en rPduo ireuq m e R
Aa
5 sl2mdl
6
to VI). The paper concludes with a discussion (section VII),
an overview of related work (section VIII) and some final
remarks.
control (observed by the sensors, influenced by the actuators)
is called the plant. The whole system (consisting of sensors,
controller, actuators, and the plant) is called a control loop [
ENGINEERING
As a sample case for this paper, we want to apply Software Product Line techniques to the domain of control engineering. Such control system are typically developed using modelbased tools like Matlab/Simulink. They can be considered as (or implemented as) a special form of embedded systems.
The task of a controller is to influence an environment with actuators to achieve a certain behavior. To this end, the controller gathers information of the environment using sensors. With the information provided by the sensors the controller uses the actuators to influence the controlled environment. In many cases, the part of the environment that is the object of When developing the code for such a controller, the main requirements are the reaction time, the input-output stability and the control error. The behavior of the control loop depends on both the controller and the plant. To understand the behavior of the plant and the controller, models of both are developed in a first step. These models are improved using the results of simulation.
If the desired behavior is achieved, a next development step is performed. The model of the controller will be translated to source code and executed using a prototyping hardware. During this development step either a prototyping plant or a real-time model of the plant is influenced by the controller. In this development timing requirements can be observed and tested.
During the third development step the controller code is executed on the real product hardware. This is the first time the real plant (and not the simulated one) is tested with the controller. Cost and safety issues are the main reasons for the late testing with the real plant. One important task during this stage is to optimize the controller. To this end, the controller has parameters that can adopted until the control loop finally meets the requirements.
To built such systems, model-based design is a common engineering practice. Simulink is a very well-known example of a domain-specific modeling language for embedded systems, including corresponding tools. Using such development frameworks is one way to tackle the increasing complexity.
While this is already a nice foundation, in an industrial context we require additional techniques that help us to build whole product lines of such systems. To this end, modelbased design techniques for embedded systems are extended with mechanisms for variability and model-driven product derivation.
We discussed some concepts and techniques for this in [
III. OVERVIEW OF OUR APPROACH
Before we explain the details of our approach, we first want to give an overview as an orientation for the reader, see figure 2. Similar to common SPL Engineering methods our approach can be structured into Domain Engineering (upper layer) and Application Engineering (lower layer).
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.
To support common techniques and processes from Embedded Systems Engineering, we integrated our approach with the domain specific language Simulink. Hence, the chain of processes to begins in the Simulink world (right-hand side of figure 2) moves over ( ) to the Eclipse-based Models (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 in more detail.
IV. DOMAIN ENGINEERING
For the context of this paper, we will assume that most
processes, which are necessary to create the product line
artefacts ( d to Dd) have already been performed. See [
Those processes that are of interest here, start off with the mdl2sl transformation , which converts the implementation given in Simulink’s native .mdl format Dd into an corresponding Eclipse-based implementation model Cd. Subsequently, we are able to map this model to the feature model and perform
The elements created in the target model are fine
grained elements of a feature model, which we call feature
model primitives. Examples for such feature model
primitives are f1-hasOptionalSubfeature-f 2, f3-requires-f4 or f
1hasBeenSelected. These primitives have clearly defined
semantics, including the corresponding behavior of our S2T2
Configurator tool during interactive configuration. These
semantics are given by further translation of the feature model
primitives into propositional logic. For instance,
f3-requiresf4 would be translated into :f3 _f4. Details of this translation
can be found in [
In summary, the transformations provide the following
result: We now have (1) an integrated model presenting features,
further processing with Eclipse-based frameworks, such as
the numerous frameworks from the Eclipse Modeling Project
(EMP) [
To enable the integrated configuration of feature and implementation models, we transform these models and the mappings between them into an integrated SPL model . The basic idea is to represent all configurable parts of the product line (feature selected? component present?) as one large feature tree, where different subtree represent different SPL models. So, for instance, we can have one subtree with the real feature model i and one subtree representing the configuration status of components i , as well as mappings and between them i . This enables us to interactively configure the whole product line within one integrated model.
This translation is realized by an model transformation
in ATL (Atlas Transformation Language) [
Representation within the integrated SPL model i mandatory feature f (m) optional feature f (s) optional feature f (b) subfeatures f (b) requires f (a) but not vice-versa Representation within the integrated SPL model i f (f ) requires f (c) Simulink Cd (concepts in the meta-model) Simulink Model m System s Block b contained blocks/systems in blocks/systems Line from block a to block b Mapping d (concepts in the meta-model) Feature f mapped to component c List of feature model primitives f1 exludes f3 f2 requires f3 Eliminated feature
Selected feature f1 is implemented by c1 f2 is implemented by c2 User asking why c2 is automatically selected Visual explanations: user selected f3 and f3 requires c2 their implementation, and relations between them in one model and (2) this model can be used in an interactive configuration tool. exclusive; f2 requires f3). The features and components are connected via requires edges, which represent that features are implemented by certain components.
V. PRODUCT CONFIGURATION
After converting the given SPL artefacts into one integrated model, we can use our tool S2T2 Configurator to perform an interactive configuration .
Whenever a model is loaded, the Configurator internally
transforms it into a formal representation, which is used by a
reasoning engine to keep the configured model in an consistent
state, to calculates consequences of the user’s decisions and,
on demand, and to provides visual explanations for such
consequences [
Figure 3 shows the Configurator with a very simple model with just three features f1 to f3 (left-hand side) and two components c1 and c2 (right-hand side). Within the feature model, we have two dependencies (f1 and f3 are mutually In the example, the user decided earlier that f2 is eliminated and f3 is selected (this is indicated by the red cross in front of f2 and the green check mark in front of f3). From these decisions and information in the model the tool derived that, f1 has to be eliminated and c2 has to be selected. In the screenshot, the user just asked why c2 was selected (see the open context menu). The tool responded by highlighting f3, c2 and the requires edge between them.
We can apply this tool to handle more realistic models, which have been derived from a real Simulink implementation model (using the model transformation briefly explained earlier). i1 i2 i3 i4 i5 i6
switch
Block 5
bus creator o1 o2 o3 o4 o5 o6 Implementation Model (Simulink) Feature‐Implementation Mappings
Given the product configuration a we now have to turn this into an executable product. In the overview in figure 2 this corresponds to the process of Product Derivation . A. Negative Variability
The first step towards the executable product is the derivation of the Application Simulink Model Ca.
Here, we apply a well-known technique called negative variability: The Domain Simulink Model Cd contains the union of all possible product-specific Simulink Models Ca. Based on the configuration decisions in the product configuration a we then copy the Simulink models while filtering out all elements, which correspond to eliminated features. Hence, the term negative variability.
This technique can, for instance, be implemented with ATL
model transformations (as demonstrated in earlier work [
B. Pruning
The technique of negative variability is a first step, but it is not sufficient to get a consistent model. We will briefly discuss two situations, where we have to adapt more than just removing some affected blocks.
The first situation arises with alternative features. With such alternative groups of features, often the outputs of the corresponding implementation blocks are connected to the same port of a third block. This pattern is not a legal Simulink model, because Simulink does not know anything about the alternative group and the elements which will be removed later to obtain a legal model.
Hence, to create and test such a model within the Simulink tools, we have to introduce helper mechanism like Switch blocks. When we later apply negative variability, these helper mechanisms have to be adapted (or removed) as well. An example is depicted in the figure 4, where two signals lead into Block 5 and are handled by a switch block. Whenever, only one of these two signals is left, we can remove the switch block altogether.
A second situation, where we have to adopt additional components in the Simulink model are Bus elements. These elements allow to combine multiple signals into one logical bus, to simplify the model (Bus Creator). In a different location in the same model, such a bus can again be separated into the single signals (Bus Separator). Whenever we apply negative variability, some signals within these buses might have to be removed (because the blocks providing these signals are no longer present). Hence, we have to adapt the bus. See the bus creator and bus separator in figure 4. In the given example, the signals i3, o2 and o3 could be pruned.
VII. DISCUSSION
In this work we implemented an approach, where we combined the feature, the mapping, and the implementation model into one big feature model. To this end, we transformed
the Simulink blocks of the implementation model into features realistic Simulink models and evaluate the configuration apand 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 transfora 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 transshown 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. RELATED 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 [
Approaches which are related to our work can be roughly grouped in two categories, (1) approaches to deal with variability in domain-specific languages and (2) approaches to model variability in model-based development with Matlab/Simulink.
Weiland [
Kubica [
There are other approaches, which are dealing with
domainspecific techniques as well. For instance, Voelter and
Groher [
When dealing with variability, a typical challenge is the
mapping of features or variation points to their
implementation. Czarnecki and Antkiewicz [
IX. CONCLUSIONS
In this paper, we presented an approach to the configuration of product lines within an existing tool for feature configuration.
The necessary translation from the implementation model into feature models and the targeted feature modeling language, present some limits with respect to expressive power.
We can only “translate” model structures that are related to configuration, such as selection/elimination or x requires y dependencies. More domain-specific concepts, e.g., voltages or oscilloscopes cannot be represented in a feature model in a meaningful way.
On the other hand, this translation enables us to configure an integrated model of the whole product line within one configuration tool. In particular, it provide the functionality described in the introduction: 1) The user can browse dependencies between features and
the related elements in other models. 2) After applying configuration decisions he/she can im
mediately see consequences in related models. 3) It is possible to apply configuration decisions in the implementation model first and derive implications for the feature model from that.
In future work, we intend to improve (1) the product derivation mechanisms, including the connector which links our Configurator to openArchitectureWare and (2) the model transformation that implements the pruning.
X. ACKNOWLEDGMENTS