One approach to handle the complexity of embedded systems is the use of models and domain-specific languages (DSLs) like Matlab / Simulink. If we want to apply such techniques to families of similar systems we have to describe their variability, i.e., commonalities and differences between the similar systems. Here, approaches from Software Product Lines (SPL) and variability modeling might be helpful. In this paper, we discuss three challenges which arise in this context: (1) We have to integrate mechanisms for describing variability into the DSL. (2) To efficiently derive products, we require techniques and toolsupport that allow us to configure a particular product and resolve variability in the DSL. (3) When resolving variability, we have to take into account dependencies between elements, e.g., when removing Simulink blocks we have to remove the signals between these blocks as well. The approach presented here uses higher-order transformations (HOT), which derive the variability mechanisms (as a generated model transformation) from the meta-model of the DSL.
Embedded systems are present in our everyday life. For instance, they are integrated into washing machines (to save energy and water), mobile devices (to simplify our lives) and in cars (to guarantee our safety).
In many cases, the engineering of embedded systems has to fulfill conflicting goals, such as reliability and safety on the one hand and the need for cost reductions and economic efficiency on the other hand. Moreover, the complexity of such systems is increasing due to the extension of functionality and increased communication with the environment. One possibility to deal with the complexity, requirements and the cost pressure is to use model-based development techniques like Matlab / Simulink. The advantages of such an approach are that connections between system components are expressed in an intuitive way on a higher abstraction level, which hides implementation details. Other benefits are support for simulation and increased reuse due to the component-oriented approach.
In the context of this paper we regard a “system” as a Matlab / Simulink model that
contains components (Blocks) and provides a certain functionality. Nowadays, such
systems are reused with small, but significant changes between different applications.
Such variability causes additional complexity, which has to be handled. Some
wellknown techniques for this are suggested by Software Product Lines (SPL) [
The main contributions of this paper are (1) an analysis of Matlab / Simulink
mechanism for variability, (2) concepts for managing realizing this variability with model
transformations, (3) a mapping mechanism which adjusts the model according to
configuration decisions (extension of [
The remainder of the paper is structured as follows: First, we will give an overview of our approach (in Section 2). After this we will explain methods of modeling variability with Matlab / Simulink (Section 3) and how the suggested variability concepts are managed (Section 4). Subsequently, we explain the additional pruning methods (Section 5) and the implementation with model transformations (Section 6). 2
We address the challenges described in the introduction with a model-driven approach
that relies on higher-order transformations. Before we go into more details, we will
give a first overview of our approach (see Figure 1). The approach is structured into
two levels (1) Domain Engineering and Application Engineering, similar to other SPL
frameworks [
Domain Engineering starts with the consideration of the context and requirements of
the product line during Feature Analysis leading to the creation of a Domain Feature
Model d, which defines the scope and available configuration options of the product
line. Subsequently, in Feature Implementation a corresponding implementation is
created. Initially, this implementation is given in the native Simulink format (*.mdl
files). To access this native implementation in our model-based approach, we have to
convert it into a model. For this we use techniques based on Xtext [
To prepare the derivation of products a higher-order transformation (HOT) is executed, which reads the DSL meta-model and generates the derivation transformation , which will later be used during Application Engineering. 2.2
The first step in Application Engineering is Product Configuration , where, based on the constraints given by the Domain Feature Model d, configuration decisions are Requirements
Features
Requirements Metamodel Product Line Requirements
Product Requirements made, which defines the particular product in terms of selected or eliminated features. This results in a product-specific configuration which is saved in the Application Feature Model a. After some further processing , this configuration is used in the Product Derivation transformation generated earlier by the HOT. This derivation reads the Domain Implementation Model Cd and – based on the product-specific configuration – derives a product-specific implementation. After additional pruning operations , the result is saved as the Application Implementation Model Ca , which can be used in further processing steps (e.g., Simulink code generation) to create the final executable product.
We will now describe these processes in more detail. We start with the process of Feature Implementation ( in Section 3). We will then explain the required adaptation techniques including the Derivation tions (Section 5).
(Section 4) and the subsequent Pruning Opera3
Matlab / Simulink is a modeling and simulation tool provided by Mathworks. The tool provides Blocks which can be represented graphically and Lines which indicate communication. Blocks can contain other blocks, which allows to abstract functionality in special blocks called Subsystems. A similar technique is used by summarizing multiple lines into Buses.
In many cases, a feature can be implemented in Matlab / Simulink by a subsystem which contains the functionality for this particular feature. All necessary information consumed by the subsystem has to be provided by an interface, called Input ports. These input ports are normally buses. The information provided by a component are made available via Output ports, which are again organized buses and some additional signals.
We identified different possibilities to introduce variability in Matlab / Simulink for the required Feature Implementation . Predominantly, we use the technique called negative variability. When applying this technique a model is created, which contains the union of all features across all possible configurations. When deriving a productspecific model this “union” model is modified such that features that were selected are activated and features that were not selected are deactivated or deleted.
To realize such a model in Simulink we can use two different approaches: (1) embedding the variability mechanisms internally (i.e., within the Simulink model) or (2) manipulating the model, based on variability information described externally (i.e., outside of the model).
We will now describe these two different techniques by explaining how common
structures of feature models (Optional feature, Or Group, Alternative Group) can be
implemented. For more information on these structures and feature models see [
The first option is to realize variability by inserting artificial elements into the Simulink model. See the example model in Figure 2 where the blocks that implement features (Feature A, Feature B, Feature C, . . . ) have been augmented with additional elements for variability (Feature A active, Integration, Variant, VP)
Mandatory features are – by definition – present in all variants. Hence, there is nothing to do for the implementation of mandatory features when deriving a product. There is no mandatory feature in the example.
Optional features can be realized in Matlab / Simulink models as a triggered subsystem, which is a special block that can be activated using a boolean signal (see Feature A in Figure 2). By using these mechanisms we are able to activate or deactivate a feature implementation.
When modelling Alternative (XOR) group and Or group we have to realize similar variability mechanisms. However, in addition we have to take care of the resulting signals and how they are fed into subsequent blocks. For alternative features we apply a Switch block (see the block VPin Figure 2) to choose the right output signal.
For OR-related features the integration of the results cannot be described for the general case, but has to be implemented depending on the particular case. In particular we have to take into the account the case when more than one feature of the group is selected and present in the implementation. We can implement an integration block for such cases in different ways. One example, is the case where limit is calculated for a certain dimension. Then the integration can be done by using a minimum (or maximum) function. In doing so, the lowest (highest) value is used by the system. As an example for this see Feature D and Feature E which are combined using an Integration block. 3.2
A second possibility, besides variability within the model, is the direct manipulation of the model with an external tool. To this end, during product derivation it is necessary to analyze the structure of a model file and delete the blocks representing deactivated features in such a way that a desired configuration is obtained.
When creating the union model it might be necessary to create a model, which could not be executed as-is within Simulink since the execution semantics of the created structure is undefined. This is because the variability decisions are still to be made and we have not yet removed certain elements.
As an example consider the case when we want to combine signals of two alternative features in an XOR group. In the union model, we might create the blocks for these two features side-by-side and feed their results into the same inport of the next block. As long as we configure this model (i.e., when the variability is applied), some parts will be removed, such that we get a valid and executable Simulink model. However, if we leave the union model (i.e., no variability applied) we do not realize the exclusion of the two features (“the X in XOR”). This leads to two signals feeding into on inport, which is an invalid Simulink model with undefined execution semantics.
In the example in figure Figure 2 this would correspond to connecting the F B Bus outport of Block Feature B directly to the port F bus of the bus Output Signals, while at the same time connecting the F C Bus outport of Block Feature C directly to the same port F bus. If we would try to execute such a model, Simulink would respond with an error message.
The advantage of this kind of external method is that we do not have to pollute the domain model with artificial variability mechanisms.
Analyzing both possibilities, we came to the conclusion that a combination of both is an appropriate way of introducing variability. There are two major requirements which have to be fulfilled introducing variability methods. On the one hand we have to keep the characteristics of model based development (e.g., easy testing and simulation, capturing of dependencies possible), on the other hand the derived product should no longer contain any variability mechanisms. The mechanisms, which we introduced to realize this are explained in the next section. 4
In this section we introduce the variability mechanisms we used in Simulink models and how they are influenced by configuring a corresponding feature tree. For instance the feature tree shown in Figure 3. This feature tree has an optional Feature A, XOR-grouped Feature B and Feature C, and OR-grouped Feature D and Feature E. Additionally the requires relation indicates that Feature B needs Feature A, i.e., whenever is selected has to be selected as well. This structure defines a set of legal configurations. Each of these configurations contains a list of selected features.
The mechanism that implements the structure of the feature tree has to fulfill certain requirements. In particular, it is important to keep the ability of simulating and testing the model. Therefore, it is necessary to build a model which has correct syntax, even after the variability mechanisms have been introduced. Additionally, the developer must have the possibility to introduce new features directly in the model. But due to the fact that there are space and performance requirements the mechanisms have to be removed if the model is converted into a program executable on an embedded hardware.
To this end we used in general the approach of modeling variability within Simulink but with blocks which are specially marked as variability blocks. These special blocks are adopted afterwards according to the desired configuration. This means for obtaining a configuration, features which are not necessary will be deleted. Additionally signals between blocks are rerouted to be able to eliminate the variability blocks, which are not necessary in the derived product. The exact methods for a switch-block, triggered subsystem and, arbitrary integration mechanism is given in the following paragraphs.
The switch-block is used to express the relation between alternative grouped features. Therefore only one of them will give their contribution to the system. Using this, the developer of the implementation is able to simulate all features simply by choosing a configuration of the switch which selects to corresponding feature implementation block.
When deriving the executable product, it is necessary to delete those features that are not selected in the feature configuration. The output of each selected feature has to be connected with the port the switch block points to. All other corresponding signals have to be removed. In the end, no variability mechanism should be left in the model.
The situation is a bit simpler for triggered subsystems, which implement optional features. During simulation these blocks can be selected easily using trigger-signals. This will take effect on the simulation. If the corresponding feature is selected then the trigger-port has to be activated. When deriving an executable program, whenever the corresponding feature is deactivated, the subsystem has to be deleted. If it is activated nothing has to be done.
The mechanism to join the signals of OR-grouped features are not so easy to adopt. In the case of simulating the system the developer has to activate the desired features. This can be done either by using triggered subsystems to implement the features or just by disconnecting their signals with the block which joins the signals.
In case of deriving a real product two cases have to be distinguished. If only one feature is selected the other feature and the block joining the signals can be deleted. If more than one feature is selected the feature which are not selected can be deleted. But in this case the integration mechanism is still necessary. 5
Dealing with blocks implementing features and the mechanisms to express variability is not the only adaptation which has to be done. There are additional components in the Simulink model which have to be changed as well, depending on the choices in the configuration
Especially, the interfaces for input or output signals which provide the information and supply the result from and to other systems have to be considered here. These blocks are interrelated with the configuration. They are necessary to define access to the signals. Therefore all signals provided from other systems are listed and treated in a way that the information is available in a common way. For instance the information for an input port is stored, renamed and mapped to internal representations which realizes the concrete representation.
Most of the signals, which are provided in the interface blocks are only needed for one feature. If this feature is not present the corresponding signals can be cleared out to optimize the implementation.
Buses that contains more than one signal have to be adopted in a similar fashion, i.e., only the required signals should remain within the buses. Hence, we have to prune out signals which are no longer needed because the corresponding features are to be removed.
These adoptions are not only necessary on the highest level of the model but also for subsystems. In general, it is possible that features are not visible at the highest level, for instance when subsystems are used to implement features. Since these subsystems use the same techniques as the main model of the whole system, it is necessary to adopt their interfaces and buses recursively in a similar fashion. 6
The implementation discussed here (see Figure 4) is a technical realization of the approach shown earlier (see Figure 1).
The technical implementation follows the same structure, with Domain Engineering (Processes to ) and Application Engineering (processes to ). We will now discuss the model transformations in more detail. 6.1
The higher-order transformation (HOT) Metamodel2Derivation.atl reads the meta-model of the DSL and generates a model transformation , which is able to copy instances of this DSL.
Some excerpts of Metamodel2Derivation.atl are shown in Listing 1. The transformation is generated as an ATL query which concatenates the output as one Requirements
Requirements Metamodel Product Line Requirements ing 1, lines 4–8) generates copy rules for all meta-classes in the meta-model. Details of each copy rule (e.g., the rule, from and to part) are generated by the function Class.toRuleString() (see Listing 1, lines 10–21) and other functions which were omitted for space reasons.
Examples of how the resulting transformation looks like, will be discussed in the next section.
Listing 1. Metamodel2Derivation.atl, transformation (3), excerpt.
The generated derivation transformation DeriveImplementation.atl realizes a
principle called “negative variability” [
Hence, the derivation transformation has to selectively copy the elements, filtering out those that should not be included, copying only those which will become part of the product-specific model, here the Application Implementation Model Cd.
This selective copying is realized using the following mechanisms: – For each meta-class in the DSL there is one copy rule. For instance, the rule Block (see Listing 2, lines 9–19) will copy instances of the meta-class Block. – Each copy rule contains a condition that refers to an .isVisible() helper function, which controls whether an element is “visible” for the particular product and, hence, is copied or not. For instance, when processing the source element s the rule Block checks whether s.isVisible() (see Listing 2, line 12). – To avoid inconsistent references, the following check is performed: Whenever references are processed, it is checked if the referenced elements are visible, as well. For instance, when copying references to .generalization, .ownedAttribute, and .ownedOperation the visibility is checked (see Listing 2, lines 16–18).
2 3 create TARGET : TARGETMETA from SOURCE : SOURCEMETA , CONFIG :
CONFIGMETA ; 17 18 ) to t : TARGETMETA ! Block mapsTo s ( name <− s . name , subsystemblockbody <− s . subsystemblockbody−>
select ( o ∣ o . isVisible ( ) ) , normalblockbody <− s . normalblockbody−>
select ( o ∣ o . isVisible ( ) ) , scopeblockbody <− s . scopeblockbody−>
select ( o ∣ o . isVisible ( ) )
Listing 2. DeriveImplementation.atl, transformation (6), excerpt. – The visibility functions determine whether instances of a certain meta-class will be copied. For instance, Block.isVisible() (see Listing 2, lines 5– 6) calculates this for each instance of Block. In the initial version of DeriveImplementation.atl which is automatically generated from the meta-model all visibility functions default to true. – In a second transformation, DeriveImplementationVisibility.atl Listing 3 these visibility functions are manually redefined. These functions access the product configuration and determine, which elements go into the product and which do not. Later on, these will be overloaded over the default visibility functions, by using ATL’s superimpose mechanisms.
The selective copying is controlled by the function s.isVisible() defined in DeriveImplementationVisibility.atl . This function reads the Application Feature Model a and decides how this influences the filtering of elements in the Domain Implementation Model.
For this decision to be made, it is necessary to know how the various features in the feature model ( d and a) are related to the corresponding elements in the Matlab / Simulink implementation model.
2 3 create TARGET : TARGETMETA from SOURCE : SOURCEMETA , CONFIG :
CONFIGMETA ; 4 5 −− t r u e i f B l o c k i s r e f e r e n c e d by a s e l e c t e d f e a t u r e 6 helper context SOURCEMETA ! Block def : isSelected ( ) : Boolean = 7 [ . . ] 8 9 −− t r u e i f B l o c k i s r e f e r e n c e d by an e l i m i n a t e d f e a t u r e 10 helper context SOURCEMETA ! Block def : isDeselected ( ) : Boolean = 11 [ . . ] 12 13 helper context SOURCEMETA ! Block def : isVisible ( ) : Boolean = 14 if self . isSelected ( ) then 15 if self . isDeselected ( ) then 16 true . debug ( ’feature conflict for block’ + self . name ) 17 else 18 true 19 endif 20 else 21 if self . isDeselected ( ) then 22 false 23 else 24 true −− d e f a u l t t o v i s i b l e 25 endif 26 endif ; 27 [ . . ]
Listing 3. DeriveImplementationVisibility.atl, transformation (5), excerpt.
This is represented by the Mapping d between the Domain Feature Model d and the Domain Implementation Model Cd implemented as a model which contains as elements dependencies. These dependencies relate features and the corresponding implementation, with a link mechanisms available from the meta-model. Using this meta-model we are able to map a feature given in the configuration model to a block given in the implementation model.
To implement pruning operations we are currently experimenting with and implementing new user-defined methods. These methods will adopt the copy rules in such a way that the methods given in Section 5 are realized. These pruning operations are influenced by the configuration and the mapping of features. However, they affect model components which are only indirectly referenced by the mapping model. 7
Several projects deal with Product Derivation. The ConIPF project provides a
methodology for product derivation [
When dealing with variability in domain-specific languages a typical challenge is
the mapping of features to their implementations. Here, Czarnecki and Antkiewicz [
Voelter and Groher [
In earlier work [
The approach presented here can be seen as an integration and extension of
work from Weiland [
Tisi et al. provide an literature review on higher-order transformations [
In this paper we presented an approach to introduce and adopt variability in a modelbased domain specific language (Matlab / Simulink) for developing embedded systems.
With our approach we are able to simulate and test variable Simulink-models by introducing mechanisms to manage variability and additionally derive models which contains only the product specific components. This provides us with memory and computation time efficient models.
All model transformations were implemented in the ATLAS Transformation
Language (ATL) [
This work was supported, in part, by Science Foundation Ireland grant 03/CE2/I303 1 to Lero – the Irish Software Engineering Research Centre, http://www.lero.ie/. The higher-order transformation ( in the overview) was inspired by an ATL case study by Dennis Wagelaar.