=Paper=
{{Paper
|id=Vol-2405/09_paper
|storemode=property
|title=Efficient Software Controller Variant Development and Validation (ECoVaDeVa) Overview of a Flemish ICON Project
|pdfUrl=https://ceur-ws.org/Vol-2405/09_paper.pdf
|volume=Vol-2405
|authors=Bart Meyers,Simon Van Mierlo,Davy Maes,Hans Vangheluwe
|dblpUrl=https://dblp.org/rec/conf/staf/MeyersMMV19
}}
==Efficient Software Controller Variant Development and Validation (ECoVaDeVa) Overview of a Flemish ICON Project==
https://ceur-ws.org/Vol-2405/09_paper.pdf
Efficient Software Controller Variant
Development and Validation (ECoVaDeVa)
Overview of a Flemish ICON Project
Bart Meyers1 , Simon Van Mierlo2 , Davy Maes1 , and Hans Vangheluwe2,3
1
Flanders Make vzw, Belgium
{bart.meyers, davy.maes}@flandersmake.be
2
University of Antwerp - Flanders Make vzw, Belgium
{simon.vanmierlo, hans.vangheluwe}@uantwerpen.be
3
McGill Unviversity, Canada
Abstract. This paper describes the goals, (partial) results and lessons
learned of the ECoVaDeVa project, a Flemish project that groups aca-
demic and industrial partners around the efficient, model-based develop-
ment of software controller variants for Cyber-Physical Systems (CPSs).
ECoVaDeVa’s high-level goal is to apply Product Line Engineering (PLE)
techniques to CPS controller design in all phases of the development life-
cycle (design, simulation, testing, deployment) as an extension of existing
software product line techniques. While PLE is well researched in soft-
ware development, it is not clear whether these results apply to CPS
controller design. The added complexity stems from the heterogeneity
of models representing the system, involving plant, controller and envi-
ronment, software and hardware, and virtual test benches (model-in-the-
loop, hardware-in-the-loop, etc.). The envisioned result of the project is
a set of tools, techniques, and guidelines for the efficient management of
CPS controller product variants. The techniques developed during the
project are demonstrated on a common use case: a windshield wiper.
1 Project Details
Name and Acronym of the Project: Efficient Software Controller Variant
Development and Validation (ECoVaDeVa)
List of Participants:
AnSyMo/CoSyS-lab (University of Antwerp)
CodesignS (Flanders Make Strategic Research Center)
Dana Belgium
Atlas Copco
Siemens PLM Software Belgium
Link to Official Website:
https://www.flandersmake.be/en/projects/ecovadeva
Status and Duration: ongoing. Project start date: January 1st , 2017. Planned
end date: June 30th , 2019.
Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
50 Bart Meyers, Simon Van Mierlo, Davy Maes, and Hans Vangheluwe
2 Project Description
2.1 ICON Project Description
ECoVaDeVa is a Interdisciplinary Collaborative Research (ICON) project. An
ICON project involves a strategic research center (including academic partners)
and industrial partners. The goal is to transfer basic research to the industrial
partners. In the project, a common research challenge is identified for all of
the industrial partners. In the strategic basic research part, generic research
questions are formulated and addressed to improve upon the state-of-the-art
by the strategic research center. In the applied research part, the results of this
research are then translated to the specific case of each of the industrial partners
in separate work packages. This requires a close collaboration between academic
and industry partners. In this paper, we focus on the results of the strategic
basic research, as applied research results are confidential.
2.2 Problem Description and Goals
In a previous research project (VARIES4 ), Flanders Make (formerly FMTC) and
Dana (formerly Spicer) investigated variability tools with respect to their appli-
cability in real-life mechatronic applications beyond the classical toy examples.
From that project, a number of research challenges were identified.
The main goal of this project is to increase the efficiency of the develop-
ment and validation process of Cyber-Physical System (CPS) controller soft-
ware variants. This efficiency gain is achieved by bridging the gap from business
software Product Line Engineering (PLE) methods and tool prototypes only
demonstrated on toy problems to industrial-scale CPS software development
and validation processes. More specifically, the project aims to:
Create a methodology and provide tool support for building central variabil-
ity models for CPSs with variability in hardware and software architectures
and automatically generating a configuration tool from these models;
Provide insights to companies in the various possibilities to implement vari-
ability in behaviour simulation languages such as The MathWorks Simulink
and SISW Imagine.Lab by offering them a decision tree for selecting the
most appropriate variability mechanisms;
Create a methodology and a toolbox that companies can use to automate
their specific build and validation process of CPS software variants, includ-
ing the generation of Model-in-the-Loop and Hardware-in-the-Loop tests;
Create a consistency tool, that allows for early detection of inconsistencies
between central variability models and controller and plant simulation tools
if the product line evolves due to change requests.
2.3 Methodology Overview
Figure 1 illustrates the simplified idea of applying PLE techniques to CPS con-
troller software variant development and validation. A key element of the ac-
4
https://artemis-ia.eu/news/varies.html
ECoVaDeVa Overview 51
Fig. 1. Overview of the ECoVaDeVa approach.
cepted PLE approach [5] is the development of a (orthogonal) Central Variabil-
ity Model (CVM) [2]. This model, often represented as a feature diagram [4],
describes the set of all possible functionalities and parameters with which a prod-
uct variant can be equipped and their mutual (in)compatibility. For instance, for
a hydrostatic continuous variable transmission, one cannot select a chosen num-
ber of forward gears. Coupling this CVM to the controller, plant and test family
model allows for the automatic generation of the controller software executable,
the corresponding test suites, and the necessary plant models for performing the
various XiL tests. To apply PLE techniques to CPS controller software variant
development and validation, several aspects of Figure 1 require further research
and will be investigated within the project:
[RQ1] How to create/organize the CVM for real-life CPS controller software
variants and to generate a configuration tool for the application engineer
(top-level of Figure 1)?
[RQ2] How to express variability in the modelling languages used by the
various involved disciplines (bottom-left corner of Figure 1)?
[RQ3] How to implement the actual build and validation process, tak-
ing into account CPS software specific practices such as heterogeneous
tool chains, and X-in-the-loop (XiL) testing (we focus on model-in-the-loop
(MiL) and hardware-in-the-loop (HiL) testing)?
[RQ4] How to keep the various models consistent with each other if the
product line is subject to a change request?
52 Bart Meyers, Simon Van Mierlo, Davy Maes, and Hans Vangheluwe
In order to validate and communicate new approaches within the basic re-
search of the project, we established a windshield wiper controller use case. The
case consists of CVMs and configuration tools, family models in Simulink, C++,
MagicDraw, etc., and a fully automatic way to generate variants, covering all
aspects of Figure 1. In the applied research of the project, the approaches that
are investigated in the basic research are validated by the industrial partners in
industry-scale environments.
3 Project Results
Selected results of the strategic basic research are explained in this section.
During the project, we made use of the commercial tool pure::variants5 to model
the CVM and its relationship with modelling languages (RQ1 and RQ2).
Variability, Binding Times and Variant Generation. Approaches exist
for implementing variability by means of variation points in modelling languages,
but often, these are partial solutions. In the context of RQ2 and RQ3, it was
investigated how existing constructs can be used to express variation points in
relevant family modelling languages (Simulink, Amesim, SysML, etc.), and how
they can be linked to the CVM. Different types of variation points (optional,
alternative, multiple instances, etc.), different binding times (i.e., the moment in
the design work flow a variant choice is applied, for example, at compile-time),
and different levels of granularity (depending on the family modelling languages,
this can be topological, connection, element property, etc.) are investigated. This
includes the support for generating variants. A gap analysis for each used fam-
ily modelling language discovered missing constructs. A notable example is the
lack of support for model-time variability in Simulink, where Simulink model
variants are automatically generated from a Simulink family model. A remedy
was achieved by using rule-based model transformation for Simulink [3]. The
transformation rules were defined using Simulink.
Consistency. In current approaches, it may be possible that variants are
generated from a product family, that result in errors when building/simulating
them. This is caused by a mistake in the family model, but such errors are
notoriously hard to find in a product family, because of the interdependencies of
variation points within the family model. This hinders the short and predictable
product delivery times, aimed for by automatic generation of variants. In the
context of RQ4 and based on an approach for UML [1], we have developed an
approach to detect inconsistencies that result in build/simulation errors early.
These are inconsistencies between CVM and family model, and are detected at
the level of the product family instead of the level of the variant. Errors can
thus be detected and resolved before customer orders of product variants are
requested, avoiding unexpectedly long delivery times. In its current form, our
approach is compatible with Simulink, but the principles can be reused for other
tools as well. In its current status, the approach is partly implemented as a
software tool that automatically checks for errors and reports them to the user.
5
http://www.pure-systems.com/products/pure-variants-9.html
ECoVaDeVa Overview 53
Plant Variability. For plant modelling, acausal modelling languages provide
more natural abstractions, as the physical world is acausal by nature. It is then
appropriate to model the variation points, if multiple product variants exist, in
such an acausal language as well. In the specific case of Simscape for example,
variability mechanisms of Simulink [8] can be reused. Currently however, no
dedicated variation point support exist for acausal modelling languages. In the
context of RQ2, we investigated how variability can be expressed in three acausal
modelling languages: Modelica, Simscape, and Amesim. We make the distinction
between energy-conserving (domain-specific) networks that represent a set of
mathematical equations, and physical signals, coming from a sensor in the plant.
We showed that each of these languages has concepts to model variability, but
certain types of variability cannot be expressed. As a special point of focus, we
showed that some variability concepts can generate variants whose causality is
different, which might be an unwanted side effect and needs to be taken into
account.
Architectural Variability. In order to deal with controller software on
an industrial scale, an architectural overview needs to be maintained. Partial
solutions exist for e.g., the automotive sector, for which AUTOSAR has support
for variability [7]. In this project, a solution that applies to CPSs in general is of
interest. Notably, the SYSMOD Model-Based Systems Engineering toolbox [9]
provides support for variability, by implementing each aspect of PLE as shown
in Figure 1 (including CVM) as a SysML profile, but the approach provides very
limited support for specifying variation points. Related to RQ1 and RQ2, we
investigated variability modelling in SysML, including what components exist in
the system and their interface and relationships, a link to implementation models
and code, link to middleware, and deployment. The outcome of this research is
that technically, SysML can be used together with a CVM to express variability,
but improvements w.r.t. tool and language support for usability and readability
are recommended.
Dissemination. We have built a physical demo of the windshield wiper
use case to attract attention to the problem of variability management in CPS
design. It has been exposed at the Flanders Make Symposium, the Hannover
Messe and will be exposed at the MATLAB Expo 2019 Benelux.
4 Identified Research Challenges
Cyber-physical controller design typically follows a (derivative of a) V-model
process, in order to deal with different levels (e.g., concept, system, component,
implementation). Each layer comes with different models and tools. Some CVM
features are associated to models at the concept level (e.g., use an automatic
or manual transmission), whereas other features are only relevant further down-
stream (e.g., which clutch control algorithm will be used). The clutch algorithm
feature is not yet available, and it may be unknown during concept design that
this involves a variation point. Consequently, the CVM should be split up ac-
cordingly so that the right stakeholders have access to the right (partial) CVM
54 Bart Meyers, Simon Van Mierlo, Davy Maes, and Hans Vangheluwe
at the right time in the development process. Additionally, variation points need
to be modelled in the right model, and need to be bound at the desired moment
(i.e., binding time) in the tool chain, conforming the layer in which they are de-
fined. Another layer of features depends on the different tasks performed during
the development process: a model from which software is generated may need to
change if it is used for MiL testing. Approaches for multi-view variability exist
(e.g., [6]). However, existing approaches do not directly translate to the above-
mentioned V-model process, binding times and testing strategies times within the
multi-discipline setting of CPS design.
5 Conclusion
In the ECoVaDeVa project, academic and industrial researchers have investi-
gated the applicability of variability techniques in CPS development. Notably,
specific answers were provided for dealing with variability in a multi-discipline
setting, consistency at family level, variability in plant modelling and variabil-
ity for architectural models. Additionally, research challenges were identified
related to managing variability in layered CPS design processes based on the V-
model. The project is aligned with the core subject of STAF, as it aims to define
methods, techniques and tools that deal with variability through model-driven
engineering and model transformation.
References
1. M. Alférez, R. E. Lopez-Herrejon, A. Moreira, V. Amaral, and A. Egyed. Consis-
tency checking in early software product line specifications - the VCC approach. J.
UCS, 20(5):640–665, 2014.
2. S. Bühne, K. Lauenroth, and K. Pohl. Why is it not sufficient to model requirements
variability with feature models? In AURE’04, pages 5–12, 2004.
3. J. Denil, P. J. Mosterman, and H. Vangheluwe. Rule-based model transformation
for, and in simulink. In SpringSim ’14, page 4. ACM, 2014.
4. K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature-
oriented domain analysis (FODA) feasibility study. Technical report, Carnegie-
Mellon University Software Engineering Institute, November 1990.
5. K. Pohl, G. Böckle, and F. van der Linden. Software Product Line Engineering -
Foundations, Principles, and Techniques. Springer, 2005.
6. D. Rabiser, H. Prähofer, P. Grünbacher, M. Petruzelka, K. Eder, F. Angerer, M. Kro-
moser, and A. Grimmer. Multi-purpose, multi-level feature modeling of large-scale
industrial software systems. Software and System Modeling, 17(3):913–938, 2018.
7. J. Thomas, C. Dziobek, and B. Hedenetz. Variability management in the autosar-
based development of applications for in-vehicle systems. In VaMoS’11, pages 137–
140, 2011.
8. J. Weiland and P. Manhart. A classification of modeling variability in simulink. In
VaMoS’14, pages 7:1–7:8, 2014.
9. T. Weilkiens. SYSMOD - The Systems Modeling Toolbox - Pragmatic MBSE with
SysML, 2nd edition. Tim Weilkiens, 12 2016.