Recent efforts in the automotive domain to initiate a paradigm-shift from a traditional hardware-driven to a function-driven development process create new challenges to tackle. A hardware-driven variant handling mechanism will get more and more inappropriate. Instead, new concepts and methods are necessary to model and configure concrete systems. A software document which is used in the early phase of development is the so called function net model. Variability in function nets is captured implicitly and is strongly dependent on the hardware infrastructure, constraints are collected with informal annotations, and variants are generated manually. This results in a situation where function nets get too complex, time consuming and unsuitable for future standards. In this paper, we will present a model-driven approach for function nets to capture variability explicitly, to express formal constraints, and to generate concrete variants with the support of an automated configuration process. By this, it is possible to use the generated variants as skeletons for virtual prototyping, so that requirement specifications can be verified efficiently.
Variability in automotive software engineering has achieved a degree of complexity which can no longer be handled with traditional hardware-driven methodologies [1][2][3]. Function net models are software documents which are used in an early phase of such a development process to describe the first virtual realization of the system structure [4]. Typically, it consists of functional modules that interact via signals.
Variation points and their variants are captured implicitly by modeling a so called maximal function net model. The idea behind that is to capture every functional module, e.g., a sensor, an actuator, a control algorithm etc. In this way, a function net corresponds to an Electronic Control Unit (ECU) together with all its physical connections to bus systems, sensors, and actuators. Figure 1 illustrates two forms of a maximal function net model. Figure 1(a) represents a function net model specified in an Excel sheet, while Figure 1(b) is a visualization of this Excel sheet as graph. In both forms, it is very difficult or nearly impossible to extract useful information manually out of it. Communication dependencies between function nets, i.e., communication dependencies between ECUs, which have an influence on variability are handled by using informal annotations. Variants are then generated manually by removing specific parts of the function net with the help of these annotations. In a hardware-driven process, this can be regarded equally to removing hardware components such as ECUs, sensors, or actuators and the appropriate software portions. Any implications to other hardware and software components have to be solved manually.
Regarding the current trend in automotive software engineering, we can observe a paradigm-shift from a hardware-driven process to a function-driven process [5]. Therefore, a hardware-driven variant handling mechanism will get more and more inappropriate, because it gets too complex and is not suitable for future standards: it completely depends on the underlying hardware infrastructure, consistency has to be ensured manually, i.e., there is no formalization to express dependencies, and there is also no automated support to configure and validate concrete variants.
In a research project at our department, we are providing new concepts, methods, and tools for handling complexity and variability in software documents for automotive software engineering [6][7][8][9]. We have developed a formal language to model function nets, and a formal language to model variation points and variants. Furthermore, we have integrated these two modeling languages in order to reduce synchronization overhead. Modeling guidelines, some of which can be checked on syntactical level and others which completely rely on behalf of the function net architect, are also provided. Moreover, methodology rules for the usage of such an integrated modeling language are also specified. What is still missing is the possibility to express constraints between functional modules or its signals inside one or many function net models. Furthermore, there is also a need to have an automated support to configure concrete variants out of the family which also ensures the consistency. Because we are not only dealing with function net models but with several software documents, we need a configuration engine which is independent from the input language.
Including the missing concepts will enhance the development process in a way, that out of the family of function net models, we can generate skeleton variants for virtual prototypes (i.e., behavioral simulation on a PC). This allows an early and efficient verification of requirement specifications.
In this paper, we will introduce an approach to express constraints in and between function net models. Furthermore, a configuration process is integrated which is coupled with an independent back-end inference engine. The output of the configuration process is a concrete variant of a function net.
The paper is structured as follows: Section 2 describes and motivates the problems in more detail. Here, we also illustrate an example which is used continuously in the whole paper. Section 3 and 4 include the main contribution of this paper. Here, we explain the language to express constraints and the whole configuration process. Section 5 describes related work and finally Section 6 concludes this paper.
This section describes the initial situation of our approach that is relevant to explain the problems we are going to tackle and the contribution of this paper. Nevertheless, we will not describe the conceptual background but illustrate an example and refer to them appropriately. Figure 2 shows an example of a function net model integrated with a variability model [6,8]. It illustrates a part of a Central Locking System (CLS), with a Vehicle Access Controller (VAC), a Data Transceiver (DT), and a Central Locking Master (CLM). A VAC can lock (l) or unlock (ul) the vehicle. For this, it has to authorize itself with some authentication data (ad).
To communicate between functional modules we use ports. Thereby, we distinguish between data ports, i.e., signals with a data storage characteristic, and control ports, i.e., signals initiating a functionality. In Figure 2 data ports are visualized with a rectangular shape, while control ports are visualized with a circle shape. Furthermore, these two types of ports are distinguished between provided and required ports. In Figure 2 provided ports are marked black, while required ports are marked white.
Variation points and their variants are captured in the variability model [6,8]. For example, a VAC is a variation point, which has two variants, i.e., a Remote Control (RC) and an Identification Transmitter (IDT) for a more comfortable access. In the same way, a DT is also a point of variation which has for example Antennas (At) as variants. A further variant could be a key slot (not shown in Figure 2). Variation points have group cardinalities and variants have variant cardinalities in the same way as Czarnecki et al. have introduced [10]. For example, in Figure 2 .4] of At expresses that a valid CLS can have at least one but at most four instances of the variant. By using group and variant cardinalities it is possible to restrict valid systems. In the subsequent sections, we will see that this is not enough to express constraints. Finally, variants can be specified more fine-grained (depicted with the dots in Figure 2). For example, ports and their connections can differ depending on the variant. For our explanations in this paper, we will not need them and therefore, they are neglected here.
As explained before, currently we cannot express more complex constraints between functional modules or its signals inside one or many function nets. Furthermore, an automated support to configure concrete variants is also not possible. The next two subsections will describe the mentioned problems in more detail.
In Figure 2, we have denoted two constraints for IDT (solid black line with arrow), i.e., the exclusion of RC if it is selected and the necessity of exactly four Ats. Please note that the exclusion can also be modeled with the expression of group cardinalities. This kind of constraints and obviously more complex constraints are often needed when modeling a family of function nets. As mentioned before, in our current prototype it is not possible to express more complex constraints which is a strong limitation of our integrated concept. Therefore, there is a need for an appropriate constraint language in order to express dependencies between variants.
An important requirement is that the language has sufficient expressiveness. It should be possible to combine multiple variants and to formulate nested statements. It should also be possible to define constraints between different variability models. Another important requirement is that constraints should be reusable. Having gained experience in often used constraints, it should be possible to predefine standard constraints and reuse them. Furthermore, the constraint language should not cause that much time-consuming training effort for the configuration process. This minimizes error-proneness and enhance usability.
Consider again Figure 2. We have depicted check boxes for the variability model to illustrate the configuration process. In the example, IDT is selected which requires exactly 4 Ats. Obviously, this is a valid configuration from which a concrete variant can be derived. The variant can then be used as skeleton for virtual prototypes to verify the requirements specification. Such a virtual prototype can for example be modeled with tools such as Matlab R Simulink R and Stateflow R [11]. In our current implementation such a configuration process is not supported.
There is a need for back-end configuration engine which infers valid variants. The configuration engine should be independent from the input language. This means, that it should be possible to handle different kind of models, such as function net models, Simulink models, and even source code. Furthermore, it should be possible to combine different models and process them as input. For this, the configuration process should be easily extendable and highly performant.
Because we do not plan to design a new constraint language, we have investigated literature to find a suitable one that fulfills our requirements and is adaptable to our prototype. As one important requirement, we have identified that the constraint language should not cause additional expenses. Therefore, the selection of our language depends on the input language of the underlying configuration engine. As we will see in Section 4, we will use smodels as configuration engine which requires Weight Constraint Rule Language (WCRL) as input language [12]. Soininen et. al. have shown that WCRL has sufficient expressiveness. It is also possible to reuse rules. Therefore, WCRL is a language that is suitable for our purposes. In this paper, we do not show the complete definition of WCRL but limit it to a portion that is enough for the variability and function net model. For the complete definition, please refer to the authors of WCRL [12].
A weight constraint rule is of the form
where C i is a weight constraint which in turn is of the form
where L, U ∈ Z are lower and upper bounds, a i is a literal (atomic formula or predicate), and w i ∈ N 0 is a weight.
A weight constraint C i is satisfied for a set S iff
where S is a set of literals.
To illustrate WCRL consider again Figure 2. To express the exclusion of RC if IDT is selected, we can define a weight constraint rule as follows:
ExcludeRC ← IsSelectedIDT, where ExcludeRC = − ∞ ≤ {InstOfType(X, RC) : InstDomain(X)} ≤ 0, and
The expression InstOfType(X, RC) : InstDomain(X) returns, out of the whole set of instances, i.e., the selected variants, a subset of a literals X which are of type RC (and a have default weight of 1). The same holds for IDT.
To express that exactly 4 Ats are needed if IDT is selected, we can define another weight constraint rule:
where IsSelectedIDT is defined as above, and
In this way, it is possible to express formal constraints which are also processable by the configuration process which is presented next.
A constraint language allows the restriction or precision of the configuration domain. We are now able to model a family of function nets and to express constraints across variants. What is still missing is a methodology and appropriate concepts to configure a concrete variant out of the family. In this section, we will provide such a configuration process and explain the steps relevant for it.
Figure 3 gives an overview of the whole configuration process. The input document will be a function net family as shown in Figure 2 and the output document after configuration will be a comletely configured function net. The configuration steps are (1) the selection of the variants in the variability model. This is done with the help of the integrated prototype [8]. The result of this step will be a function net family plus selected variants. Because WCRL is the input language for the back-end inference engine, we need (2) a transformation from the language of function net families to an equivalent model in WCRL which is the result of this step. The transformation rules are defined with support of openArchitectureWare (oAW) [13]. The function net model in WCRL is the input for the inference engine smodels which (3) infers a configured function net in WCRL. In order to visualize the result we (4) transform it back to the function net model. Note that steps (2)-( 4) are internally processed so that a user does not notice them.
In the following subsections, we will explain the above outlined steps in more detail by illustrating them with the example of Section 2. We will start with step (2), i.e., a function net family plus selected variants which are transformed to a model in WCRL.
Consider Figure 4. We have a family of function nets where WCRL constraints can be expressed (see Section 3) and in addition variants can be selected. In the example, we want to configure an IDT and four Ats. As explained above, we first have to transform the function net family to a model in WCRL.
The bottom part of the figure shows the result after transformation, i.e., a model in WCRL. For example, the functional module VAC is transformed to Function(VAC) <-. This is a short notation for a weight constraint rule where the right part is always true (and therefore empty). Such a rule is also called a fact. The information that VAC is also a variation point is captured in the next line. Furthermore, we need the association information between VAC as a functional module and variation point. This is expressed in the third line. In the same way, variants of variation points, constraints, cardinalities, and selections are all transformed to WCRL.
To implement transformation rules, we have used the oAW framework, more precisely the component Xpand. Xpand is a template-based language to generate code based on EMF (Eclipse Modeling Framework) models [14]. Figure 5 illustrates an Xpand template that processes all variation points and variants of our integrated models (which are also based on EMF) and generates the appropriate WCRL code. Having now the model in WCRL, we can use the inference engine smodels to generate a valid configuration.
We have decided to use an independent inference engine, which is able to process combined models and has a reasonable performance. We will not present in this paper our classification and evaluation method for our decision, because it is still work in progress. But among all evaluated possibilities, smodels seems to be a good candidate [15]. In Section 5 we will give some arguments for our decision. Using smodels as back-end inference engine, a WCRL model is taken as input which then infers a configured WCRL model as output (for the input from Figure 4). Figure 6 shows an example of the output. We have one instance IDT 1 of type IDT (line 1 and 2), and four instances of type At. Furthermore, all instances for ports and their connections are inferred.
Finally, the result of smodels has to be transformed back to the function net model. Therefore, we again specify our transformation rules using oAW. We do not describe this in detail, because it is analogous as described in Subsection 4.1. Figure 7 illustrates the result of this step. The function net has now one instance of IDT and four instances of At, which all are connected appropriately. Note that in this model the complete variability is bind (there is no green colored functional module) and therefore it is a variant that can be used as a skeleton for virtual prototyping.
In terms of expressing constraints, two different approaches exist: structural/ graphical definition and textual definition. The former is usually adopted by configuration systems involving feature trees [16], and the possible relations include simple 'requires' and 'excludes' relations and cardinality constraints [10], and relations like 'recommends' or 'discourages' in some cases [17].The latter requires the use of a constraint language/logic, including OCL [18], WCRL [12], or Prolog [17] to express arbitrary logic formulas constraining the model, allowing less user-friendly yet much more expressive constraints. Among different languages, OCL has the advantage as the most well-known language since defining complex constraints requires a considerable amount of proficiency in the relevant language.
In [19] and [20], different methods for product configuration are summarized. Some are rule-based, logic-based and constraint-based configuration; the strengths and weaknesses of tools adopting different approaches are discussed in [21]. Answer Set Programming (ASP) [22] emerges to be an important and widely accepted means for product configuration, and is suitable for the representation of configuration knowledge [23]. Since the configuration task is NP-complete, performance of the inference engine seems to be important for medium to large scale models. There exist several solvers including pure ASP solvers such as smodels [15], DLV [24], and hybrid approaches integrated with SAT solvers such as ASSAT [25]. A theoretical comparison can be found in [26] and comparison of their performance in relevant sections of each paper and in [27].
Regarding the different ASP solvers, there exist considerable amount of data on using smodels, which has a long history of development and wide acceptance. It allows a direct integration into our configuration process with the use of WCRL as input language. In contrast, OCL requires an extra model transformation. However, we plan to integrate OCL into our configuration process in order to compare both in more detail. The disadvantage in performance and lack of advanced concepts (such as non-monotonic reasoning, learning, powerful heuristics) may be neglected considering the current scope of our work; and it is easy to migrate later to different engines with the same interface (WCRL I/O) for better performance.
In this paper, we have illustrated a model-driven approach to configure an integrated variability and function net model. First, we have explained the need for a constraint language in order to restrict the configuration domain. Therefore, we have included WCRL as an appropriate language. Second, we have motivated the necessity for an independent back-end inference engine. Here, smodels seems to be a tool which is adaptable, extendable, and with high performance. We plan to start a benchmark where this can be evaluated more precisely.
The possibility to configure concrete variants of function nets allow the generation of skeleton variants for virtual prototyping. For example, in this way, variants of Simulink models can be simulated in order to verify efficiently requirement specifications in an early phase of a model-driven development process.