Supporting Automated Verification of Reconfigurable Systems
with Product Lines and Model Checking
Faiz Ul Muram
1 a
, Samina Kanwal
2 b
and Muhammad Atif Javed
3 c
School of Innovation, Design and Engineering, Mälardalen University, Västerås, Sweden
National University of Sciences and Technology, Islamabad, Pakistan
RISE, Research Institutes of Sweden, Västerås, Sweden
Reconfigurable Systems, Product Lines, Model Transformations, Model Checking, Formal Methods, LTL.
The capability to dynamically reconfigure in response to change of mode or function, failures, or unantici-
pated hazardous conditions is fundamental for many critical systems. The modelling and verification of such
systems are frequently carried out with product lines and model checking, respectively. At first, the objectives
and related requirements of reconfigurable systems are mapped to a feature model, whereas the units related
to operational modes are selected in individual configurations. After that, the proposed approach performs
automated transformation of particular models into formal constraints and descriptions for leveraging the ana-
lytical powers of model checking techniques; the formal verification of completeness, consistency and conflict
is carried out with NuSMV model checker. Finally, in circumstances when the counterexample is produced, its
analysis is performed for the identification of corresponding problems and their resolutions. The applicability
of the proposed approach is demonstrated through case study of attitude and orbit control system.
The principal intention of reconfigurable systems is to
enhance the responsiveness in consequence to mode
or function changes, environmental conditions and
unexpected failures (Muram et al., 2020). The recon-
figurable systems possess the advantages of both ded-
icated product lines and of flexible systems. In par-
ticular, they focus on customized flexibility that can
be supported through product lines. The product lines
have been used for the identification and systemati-
zation of commonalities and variabilities to concur-
rently engineer a set of scenarios; the achievement of
a single configuration is based on the selection and
composition of commonalities and variabilities (Javed
and Gallina, 2018; Javed et al., 2019). The integration
between product line and model checking is essential
for the formal verification of reconfigurable system
behaviour against its formal requirements that are of-
ten expressed in temporal logic (Gan et al., 2014).
There exist several efforts to apply the model
checking technique for product line verification, for
example, (Gruler et al., 2008; Lauenroth et al., 2009;
Lochau et al., 2016). However, previous approaches
have not considered the automated transformations of
product lines. These approaches often assume that
formal descriptions and constraints of the product line
can be easily created. Unfortunately, this makes the
approaches hard to apply in practice because creat-
ing formal descriptions and constraints requires the
underlying knowledge of formal techniques (Muram
et al., 2016; Muram et al., 2017; Muram et al.,
2019). Moreover, this task is often accomplished in
a laborious and manual manner, which is also error-
prone (Gruler et al., 2008; Lauenroth et al., 2009).
In case of violations the results produced by model
checkers (e.g., counterexamples) are rather cryptic
and verbose (Muram et al., 2015; Muram et al., 2019).
As a consequence, they are difficult to interpret and
understand for those who have limited knowledge of
the underlying formal techniques.
This paper focuses on the automated transforma-
tions and formal verification of reconfigurable sys-
tems. In particular, the objectives and related re-
quirements of reconfigurable systems are mapped to
a feature model, which in turns automatically trans-
formed into the formal constraints i.e., Linear Tem-
poral Logic (LTL) (Pnueli, 1977); whereas the units
related to operational modes selected in individual
configurations are transformed into state based Sym-
bolic Model Verifier (SMV) (Cimatti et al., 1999) lan-
guage. These transformations are achieved by us-
Muram, F., Kanwal, S. and Javed, M.
Supporting Automated Verification of Reconfigurable Systems with Product Lines and Model Checking.
DOI: 10.5220/0010455702970305
In Proceedings of the 16th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2021), pages 297-305
ISBN: 978-989-758-508-1
2021 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
ing Eclipse Xtend. Specifically, the mapping rules
are defined to transform the feature model and con-
figurations into formal constraints and descriptions.
This way, our approach helps to alleviate the burden
of manually encoding formal constraints and descrip-
tions, and therefore, increase productivity and avoid
potential translation errors. The formal verification of
completeness, consistency and conflict is carried out
with the NuSMV
2.6.0, a new version of symbolic
model checker. Completeness considers whether a set
of configurations satisfy the system objectives and re-
lated requirements. Consistency checking examines
the correctness of configurations against the struc-
ture and sequence of the system. Conflict verifies
whether the configurations are compatible with the
system constraints or not. In circumstances when the
counterexample is produced by the model checker, its
analysis is performed for the identification of corre-
sponding problems and their resolutions. The appli-
cability and technical feasibility of the proposed ap-
proach is demonstrated through case study of Attitude
and Orbit Control System (AOCS).
The rest of this paper is organized as follows: Sec-
tion 2 describes the tool-supported method for the for-
mal verification of reconfigurable systems. Section 3
demonstrates the effectiveness of proposed approach
through AOCS product line scenario. Section 4 dis-
cusses related work. Section 5 concludes the paper
and presents future research directions.
The modern variable systems are often composed of
several distinct sensors, controllers and actuators that
can operate in both isolation and conjunction. For
such systems, the capability to adjust, in particular,
the reconfiguration in consequences to mode or func-
tion changes, environmental conditions and system
failures is perceived as fundamental. Product lines
provide the means to handle (re)configurations of sys-
tems. To be able to build a product line, the objec-
tives and related requirements are mapped to a feature
model; however, for (re)configurations, the scenario
information or operational modes could be used (Mu-
ram et al., 2020). The principal focus of our approach
is to formally verify the completeness, consistency
and conflict in reconfigurable systems. The violations
can be produced when the configurations are incom-
plete with respect to the system objective and related
requirements, inconsistent with the organization and
sequence of the system (i.e., decomposition hierarchy
and groups), and incompatible with the system (cross-
tree) constraints. Counterexample analysis detects the
violation cause(s) and provide measures to make the
configurations valid. An overview of our approach is
shown in Figure 1. In the following sections, we de-
scribe each step of our approach.
G(p -> F q)
Feature Model
Transformation of
Feature Model
Transformation of
LTL Formulas
SMV Descriptions
Model Checking
Verification Results:
True or False with a
Analysis of
Figure 1: An Overview of the Proposed Approach.
2.1 Generating LTL Constraints
In this subsection, we present our algorithmic solu-
tion for the generation of formal constraints from a
feature model. The relationships between features
(e.g., decomposition hierarchy, groups and cross-tree
constraints) need to be represented in an appropri-
ate formalism so that the selection or deselection
of features will become the formal constraints for
the configuration(s). In this context, LTL is used
for describing the temporal relationships or proper-
ties among the features (Pnueli, 1977). LTL extends
the classical propositional logic, for instance, nega-
tion (¬ϕ), implication (), conjunction (), and dis-
junction () with several future operators, such as
Fϕ (“Finally/Sometime”), Gϕ (“Globally/Always”)
and ϕ
U ϕ
(“Until”). To make the formulation of
some formulas significantly more concise and intu-
itive, we have also used the LTL past operators, to
reason about previous states and transitions, such as
Hϕ (“Historically”) and Oϕ (“Once”).
The construction of LTL formulas (constraints)
for formal verification of reconfigurable systems is
a highly knowledge intensive endeavour. Therefore,
the mapping rules are defined to formally represent
the semantics of a feature model elements. By us-
ing these mapping rules, an input feature model is
automatically transformed to the corresponding LTL
formulas. Table 1 summarises the modelling ele-
ments of a feature model along with their defini-
tions and mapping rules that constitutes the relation-
ships between features, such as optional and manda-
tory features, feature groups, and cross-tree con-
straints. The mapping is achieved by using Xtend
ENASE 2021 - 16th International Conference on Evaluation of Novel Approaches to Software Engineering
Table 1: Mapping Rules for a Feature Model.
Graphical Symbols Relationships Definition Mapping Rules
Mandatory: If parent feature F1 is selected
in a product, then child feature F2 must be
selected. This indicates the commonality.
G (F1 -> F F2)& H (F2 -> O F1)
Optional: If parent feature F1 is selected in
a product, then child feature F2 may be se-
lected or not. This expresses the variability.
In particular, F2 will be selected if F1 and
isSelected condition are true.
G ((F1 & isSelected -> F F2)| (F1
-> F ! F2))
F1 Fn
Alternative (Xor): The semantic repre-
sents the case in which only one feature of
the children needs to be selected when its
parent feature P is part of the product.
(P -> F ((F1 & ! ... & ! Fn)| (!
F1 & !... & Fn)))
F1 Fn
Or: If parent feature P is selected in a prod-
uct, then at least one of the children must be
selected. The traversal of features depend
on the evaluation of isSelected conditions.
G ((P & isSelected_1)-> F F1)
|...| G ((P & isSelected_n)-> F
F1 F2
Excludes: Both features cannot be part of
the same product. If F1 is selected then F2
cannot not selected, and vice versa.
! (F1 & F2), or more complex,
(i)F (F1)-> (! F1 U isSelected)
(ii)F (F2)-> (! F2 U !isSelected)
language, which is tightly integrated with Java but
has more concise syntax than Java. All the aspects
of a domain specific language implemented in Xtext
can be implemented in Xtend, since it is easier to
use and allows to write better readable code. Algo-
rithm 1 shows the skeleton of transformation mod-
els. Similar to our previous research (Muram et al.,
2016; Muram et al., 2017; Muram et al., 2019),
the breadth-first search algorithm is extended with
three helper functions: get_parent_features(),
get_child_features(), and generate_ltl_for
mulas(). The function get_parent_features()
returns a set of parent features. Given a certain fea-
ture f , its child-features (or siblings) can be obtained
by using the get_child_features() function. A
feature r is called a child feature (or sibling) of f if
there is an edge (relation) from f to r, so that a set
of child-features (or siblings) of f can be obtained by
following all of its edges.
The generate_ltl_formulas( f ) function is not
realised as a single function but rather a polymor-
phism of multiple functions. That is, depending on
the type of relationships between features i.e., decom-
position hierarchy and cross-tree constraints, a partic-
ular function for generating LTL formulas for that re-
lationship will be invoked. The functions can have the
same name but require different input types. This can
be obtained in traditional programming languages by
using the if/then/else or switch/case con-
struct. The generation of Mandatory feature is pre-
sented in Algorithm 1 (Line 21–25). For code gener-
ation the string templates are surrounded by the pair
of a triple single quotes (’’’). However, the termi-
nals for interpolated expression, called guillemets (
and ) are used to represent the parametrised place-
holders that will be bound to and substituted with the
actual values extracted from the input model elements
by the Xtend engine. In NuSMV, LTL formulas are
introduced by the LTLSPEC keyword.
2.2 Generating SMV Descriptions
This subsection presents the automated transforma-
tion of a set of configurations into formal SMV model
(descriptions). The basic purpose of the SMV lan-
guage is to describe the transition relation of a fi-
Supporting Automated Verification of Reconfigurable Systems with Product Lines and Model Checking
Algorithm 1: Translate Models.
1: Input: Feature Model/Configurations
2: Output: LTL Formulas/SMV Descriptions
3: procedure TRANSFORM
4: S
queue of non-visited features
5: S
queue of visited features
6: S
7: for all f S
8: S
{ f }
9: S
\ { f }
10: F
f eatures
get_child_features( f )
11: use generate_smv_model
12: generate_ltl_formulas( f )
13: for all r F
f eatures
14: if (r 6∈ S
) then
15: S
16: end if
17: end for
18: end for
19: extract <feature> id, name, relati-
20: ons and generate ltl formulas:
21: for all relations.isTypeO f (Mandatory) do
22: ’’’
23: LTLSPEC G( f F r & H r O f
nite Kripke structure. The encoding of configurations
in terms of SMV descriptions provide the infrastruc-
ture to facilitate the verification of completeness, con-
sistency and conflicts with a feature model, and es-
pecially, analysing the verification results to provide
useful feedback for aiding the manager/developers in
resolving violations. Similar to the generation of LTL
formulas, the mapping of configurations into SMV
descriptions is obtained by using Xtend framework.
As described in Section 2.1, three helper functions
are created. First two functions are same, however,
the generate_smv_model( f ) function is responsible
for generating SMV descriptions for a set of config-
urations. We illustrate the skeleton of the function
generate_smv_model( f ) in Algorithm 2.
The SMV model consists of several modules,
which are used to encapsulate variables deceleration
and assignments. The identifier after the keyword
MODULE is the name associated with the module. An
instance of a module is created using the VAR dec-
laration. In particular, the features are specified by
boolean state variables in the section VAR and their
corresponding transition relations are described in the
section ASSIGN by a combination of two functions
given in NuSMV (Cimatti et al., 1999). These vari-
ables are initialised with initial values as shown in
the init(identifier) clause, whereas the function
next(identifier) defines the next state of the vari-
able based on current states. It is often combined
with the branching structure case/esac” for select-
ing one of many possible choices. The state is initially
set to False. However, if the branch condition(s) are
satisfied, it is changed to a True state. The branch
condition(s) can be a guard expression and/or finish-
ing of the preceding state. The feature’s state shall
be switched back to False after finishing the execu-
tion. Similar to generate_ltl_formulas( f ), the
function generate_smv_model( f ) is not realised as
a single function but rather a polymorphism of multi-
ple functions.
Algorithm 2: Generating SMV descriptions.
1: procedure GENERATE(smv_model)
2: extract <feature> id, name, relati-
3: ons and generate SMV descriptions:
4: ’’’
A consistent and complete set of configurations is
obtained by selecting a complete group of features
in a manner that follows a correct feature hierar-
chy. Moreover, the semantics of the configurations
should not be contradicted with constraints (requires,
excludes) of the system (i.e., feature model). It
is assumed that two features cannot have the same
name. This assumption is rather realistic because
the same name can imply ambiguity problems dur-
ing (re)configuration of systems. While selecting the
configurations, if a parent feature is selected (or des-
elected) then all mandatory child-features linked with
a particular parent feature will be selected (or dese-
lected). The ASSIGN section defines the transition re-
lation of features. The child-feature is initially set to
false. However, if the condition(s) are satisfied, it is
changed to a true state (see Line 15), as shown in Fig-
ure 2. The feature’s state shall be switched back to
false after the execution.
The Xor-groups (Alternatives) are transformed as
a set of configurations which show that exactly one
ENASE 2021 - 16th International Conference on Evaluation of Novel Approaches to Software Engineering
1 MODULE main
3 ParentFeature : boolean;
4 ChildFeature : boolean;
6 init( ParentFeature ) := TRUE;
7 next( ParentFeature ) := case
8 ParentFeature : FALSE;
9 TRUE : ParentFeature ;
10 esac;
11 init( ChildFeature ) := FALSE;
12 next( ChildFeature ) := case
13 ParentFeature : TRUE;
14 ChildFeature : FALSE;
15 TRUE : ChildFeature ;
16 esac;
Figure 2: Generic rules for SMV description.
child-feature will be selected in each configuration.
In reality, the developers/corresponding manager(s)
are responsible for the exclusiveness of conditions,
i.e., selection of the child-feature based on a spe-
cific configuration. Figure 3 shows the rules for map-
ping an Alternative relationship into SMV descrip-
tions. For the purpose of verification, it is possi-
ble to initialise a constraint, namely isSelected with
the boolean values that is evaluated to true. How-
ever, in cases when the different types of variables
may have dependencies among constraints, tempo-
rary variables of enumerated types can be introduced
to handle them. Accordingly, a temporary variable
named tem_alternative_k is defined, where k is
an incrementally generated number. This variable
is used as a program counter to determine which
procedure, function or feature state is being exe-
cuted at present. The variable tem_alternative_k
has an enumerated type that includes a normal state
undetermined” and the values corresponding to the
configurations or child-features (Line 7). It might be
noted that the non-deterministic assignment is a pow-
erful means provided by the NuSMV model checker
for exhaustively exploring multiple possible execu-
tion paths yielded by the values of an enumerated
state. The evaluation of the conditions is made using a
case/esac construct (Line 16–19). The next state
of tem_alternative_k will be either selected_1,
selected_2 or selected_3 (Line 22, 27).
An Or relationship represents that any number of
features can be selected in a configuration instead of
one and only one. We initialised a constraint, namely
isSelected with the boolean values that is evaluated
to true when the corresponding element is selected.
We use the logical AND operator (“&”) to represent
all incoming conditions, as shown in Figure 4. The
cardinality <min..max> might be applied, where min
denotes a lower bound limit and max denotes upper
2 ParentFeature : boolean;
3 ChildFeature1 : boolean;
4 ...
5 ChildFeature3 : boolean;
6 -- temporary variable
7 tem_alternative_k : {undetermined,
selected_1 ,..., selected_3 };
9 -- if the parent feature is not a root
feature, then FALSE must be used.
10 init( ParentFeature ) := TRUE;
11 next( ParentFeature ) := case
12 ParentFeature : FALSE;
13 esac;
14 ... -- the initialisations of
conditions are omitted
15 init( tem_alternative_k ) :=
16 next( tem_alternative_k ) := case
17 ParentFeature & (
tem_alternative_k =
undetermined ) : { selected_1
,..., selected_3 };
18 TRUE : undetermined;
19 esac;
20 init( ChildFeature1 ) := FALSE;
21 next( ChildFeature1 ) := case
22 tem_alternative_k = selected_1
23 ChildFeature1 : FALSE;
24 esac;
25 init( ChildFeature3 ) := FALSE;
26 next( ChildFeature3 ) := case
27 tem_alternative_k = selected_3
28 ChildFeature3 : FALSE;
29 esac;
Figure 3: Mapping rules for Alternatives.
bound limit within a group of features the number of
features that can be part of a configuration.
2.3 Formal Verification and Dealing
with Violations
This subsection discusses the identification and reso-
lution of violations (i.e., incompleteness, inconsisten-
cies and conflicts) in the reconfigurable systems. The
formal verification is achieved by using the NuSMV
model checker that takes the generated SMV model
(descriptions) and LTL formulas, and exhaustively
explore the deviations of an LTL formula by travers-
ing complete state space. In case an LTL formula does
not satisfy the SMV model, NuSMV will generate a
counterexample that consists of the execution traces
of the SMV descriptions leading to the deviation. The
incompleteness may occur due to the absence of units
Supporting Automated Verification of Reconfigurable Systems with Product Lines and Model Checking
2 ParentFeature : boolean;
3 ChildFeature1 : boolean;
4 ChildFeature2 : boolean;
5 -- temporary variables
6 isSelected_1 : boolean;
7 isSelected_2 : boolean;
9 ... -- the initialisation of
condition is omitted
10 init( ChildFeature1 ) := FALSE;
11 next( ChildFeature1 ) := case
12 ParentFeature & isSelected_1
13 ChildFeature1 : FALSE;
14 esac;
15 ...
16 init( ChildFeature2 ) := FALSE;
17 next( ChildFeature2 ) := case
18 ParentFeature & isSelected_2 :
19 ChildFeature2 : FALSE;
20 esac;
Figure 4: Mapping rules for Or.
or features in configurations with respect to system
objectives and requirements. The inconsistency of
configurations may happen when a hierarchical or se-
quential order is not followed, such as inaccurate re-
lation or groups between features/units, or misplace-
ment of features. Conflict occurs when a cross-tree
constraint is violated, for instance, an optional feature
is excluded, however, due to the requires constraint, it
has to be included in some configurations. The anal-
ysis of counterexample not only detects the typical
possible causes of incompleteness, inconsistency, and
conflict but also provides the recommendations to re-
solve the specific deviation.
To locate the causes of deviations, the verifica-
tion result (i.e., output trace file) is scrutinised and
parsed to identify the false LTL formulas. The ex-
tracted formulas and SMV descriptions together with
mapping rules for a feature model are traversed to find
out why the particular configuration(s) deviate from
the specification defined in a feature model. This is
performed in three steps. First, the absence of units or
missing obligatory feature cause (either one or mul-
tiple features/units could be missing) is detected and
the corrective measures, i.e., add the missing oblig-
atory features/units is suggested. Second, the hier-
archical dependency and sequence between features
are scrutinised from the SMV descriptions, for exam-
ple, multiplicity causing the deviations of the LTL for-
mulas are located and appropriate recommendations,
i.e., remove or replace the features or units are pre-
sented. Finally, the constraints between features are
scrutinised, for instance, requires or excludes causing
the deviation of the LTL formulas are located and ap-
propriate recommendations, i.e., insert or delete fea-
tures are provided. Based on the deviation causes and
given recommendations, the systems can be reconfig-
ured and transformed again into to their formal de-
scriptions, and then will be re-verified until no more
deviations are detected.
In this section, we briefly describe a variable sys-
tem that belongs to a space domain, in particular,
the AOCS (Javed et al., 2019). It consists of sen-
sors, actuators, software, and ground support equip-
ment to control the satellite’s attitude and orbit. In
the ECSS-E-ST-60-30C standard, the AOCS require-
ments, operational objectives, tailoring rules and cus-
tomer specifications are presented. The standard
objectives and requirements for AOCS are mapped
into a feature model, whereas tailoring rules, cus-
tomer specifications, units related to AOCS opera-
tional modes are selected in individual configura-
tions (Javed et al., 2019). In this paper, we focus
on four different configurations of AOCS, which are:
(i) Sun Sensors to THrusters (SSTH); (ii) Sun Sen-
sors to Reaction Wheels (SSRW); (iii) Star Tracker to
THrusters (STTH); and (iv) Star Tracker to Reaction
Wheels (STRW). Figure 5 shows the feature model
of AOCS that presents the different allowed combina-
tions of sensors, actuators, as well as the associated
functional software modules.
Sensing Principles. In SSTH and SSRW con-
figurations, Sun Sensors are used as the primary
sensor in combination with a Magnetometer to
provide full attitude determination capability. In
STTH and STRW configurations, a Star Tracker
is used as a primary attitude sensor. In all configu-
rations, the attitude is estimated using a kinematic
(Kalman) filter-based estimation for which Gyro
measurements are an exogenous input.
Actuation Principles. In SSTH and STTH con-
figurations, the spacecraft attitude is modified us-
ing a Thruster actuator, whereas in SSRW and
STRW configurations, the spacecraft attitude is
primarily controlled using Reaction Wheels.
Software Functional Modules. They are clas-
sified into different functional groups, such as
Sensor Processing, Guidance, Estimation, Control
and Command Distribution.
Operational Modes. The AOCS consists of sev-
eral modes, for instance, in case of major anomaly
ENASE 2021 - 16th International Conference on Evaluation of Novel Approaches to Software Engineering
Figure 5: Feature Model of AOCS.
a Safe Mode is automatically initiated to reach
and control safe pointing attitude and angular
rates. A Normal Mode concerns the mission level
performances of spacecraft during the operational
phase. Typically, SSTH variant would be used
for a Safe Mode. It might be used in combina-
tion with SSRW for long term safety and variant
STRW for a Normal Mode.
To demonstrate the qualification of AOCS config-
urations, the formal verification is performed by using
the NuSMV model checker. In particular, the AOCS
feature model and configurations are automatically
transformed into LTL formulas and SMV descriptions
by applying mapping rules described in Section 2.1
and Section 2.2, respectively. The generated SMV
descriptions and LTL formulas are combined into one
input file and executed by the NuSMV model checker
version 2.6.0. The evaluation is conducted on a reg-
ular computer equipped with a 2.90 GHz i7 proces-
sor and sixteen gigabytes of memory running Win-
dows 10. The approach is implemented using Java
and automated transformations have been realised us-
ing Eclipse Xtend
. Figure 6 shows the verification
results including the list of satisfied and unsatisfied
LTL formulas. The NuSMV model checker gen-
erates a counterexample demonstrating a sequence
of permissible state executions leading to a state in
which the deviation occurs in LTL formula. By
looking at the results, we found that four LTL for-
mulas are false. In order to identify the deviations
$ NuSMV AOCS.smv
-- specification (G (Sensors -> F Gyro) & H (
Gyro -> O Sensors)) is false
-- as demonstrated by the following execution
Trace Description: LTL Counterexample
Trace Type: Counterexample
-> State: 1.1 <-
AttitudeandOrbitControlSystem = TRUE
Sensors = FALSE
-- specification (G (
AttitudeandOrbitControlSystem -> F (
Sensors & Actuators & SoftwareFunctional
Modules)) & H ((Sensors & Actuators &
SoftwareFunctionalModules) -> O
AttitudeandOrbitControlSystem)) is false
-- specification (G ((GroundCommand &
Guidance) -> F AttitudeGuidance) & H (
AttitudeGuidance -> O (GroundCommand &
Guidance))) is false
-- specification ((G ((Sensors & isSelected_2
) -> F Magnetometer) | G (((Magnetometer
& isSelected_9) & Sensors) -> F
SunSensor)) | G ((Sensors & isSelected_4
) -> F ReactionWheelTachometer)) is true
-- specification (F StarTracker -> (!
StarTracker U (!isSelected_2 & Sensors))
) is false
Figure 6: NuSMV Verification Results.
Supporting Automated Verification of Reconfigurable Systems with Product Lines and Model Checking
causes, the counterexample analysis is performed (as
depicted in Section 2.3). In this case, the specifica-
tion of AOCS system is deviated due to (i) incom-
plete configurations, i.e., missing GroundCommand
feature, which is required by AttitudeGuidance;
(ii) inconsistency in hierarchical dependency and se-
quence: (a) Gyro feature can only be selected after
its parent feature Sensors is selected, and (b) when
parent feature AttitudeandOrbitControlSystem
is selected, then mandatory child feature Sensors
must be selected, subsequently Gyro would be
selected; and (iii) conflict: an optional feature
StarTracker is added, but due to the excludes con-
straint, it has to be excluded in SSRW configura-
tion. These deviations can be resolved by adding
GroundCommand feature, removing StarTracker
feature in the SSRW configuration and correcting
the sequence of AttitudeandOrbitControlSystem,
Sensors and Gyro, respectively. NuSMV took three
seconds to verify AOCS system, which is quite rea-
sonable. Without the counterexample analysis, users
would have to study and investigate the syntax and se-
mantics of the trace file in order to determine the rela-
tionship between the execution traces and models, and
then locate the corresponding violations manually.
The work presented in (Gruler et al., 2008) extended
the process algebra Calculus of Communicating Sys-
tems (CCS) by introducing a variant operator that
allows to model an alternative choice between two
processes. A multivalued modal µ-calculus is used
for specifying the properties of individual configu-
rations of a PL-CCS program. However, the verifi-
cation using a model checker is not performed that
is prerequisite for practical evaluation. For incre-
mental verification of software product lines, a delta-
oriented extension of CSS (DeltaCCS) is described
in (Lochau et al., 2016). A core product (process) is
first verified against a given property by using Maude
model checker, then different variants are derived
from the core process by applying CCS Delta sets.
Lauenroth et al. (Lauenroth et al., 2009) presented a
model-checking approach to verify every permissible
product specified with I/O-automata against provided
Computational Tree Logic (CTL) properties. The au-
thors just used three operators (EX, EU and EG) to
define one property of each type.
Classen et al. (Classen et al., 2011) focused on the
feature-oriented extension of SMV language called
f SMV that is equivalent to high-level representation
of finite transition systems. An algorithm on top of
the symbolic model-checking is presented to check
whether a set of valid products in the feature diagram
( f SMV) satisfies one or more feature CTL properties.
Shi et al. (Shi et al., 2014) presented the Bilattice-
based Feature Transition Systems (BFTSs) for mod-
elling partial (i.e., incomplete) software product line
designs, while the Action CTL formulas are used
to express system behavioural properties. To carry
out the model checking with exiting χChek engine,
the translations from BFTS to multi-valued Kripke
structure and from ACTL to CTL formulas are pre-
sented. Beek et al. (ter Beek et al., 2016) presented
QFLan specifications to model the quantitative prop-
erties such as price and weight of a product line, and
a prototypical Maude interpreter integrated with Z3
and MultiVeStA model checker. Previous studies on
the model checking of product lines have not consid-
ered the automated transformations of feature model
and configurations into LTL constraints and formal
descriptions. In addition, the counterexample anal-
ysis for identifying the causes of deviations and their
resolutions has not been considered.
Gan et al. (Gan et al., 2014) used the NuSMV
model checker to verify the design of an AOCS. They
manually translated the AOCS implementation i.e.,
Ada source code abstractions to SMV language. The
required system behaviour that is extended state ma-
chine diagrams with prioritized transitions are trans-
lated into LTL properties. However, they have not
considered the product lines. The automatic transfor-
mations of sequence diagrams (Muram et al., 2016),
activity diagrams (Muram et al., 2019) and service
choreographies (Muram et al., 2015; Muram et al.,
2017) are investigated for the containment checking
problem. In this paper, we performed the automated
transformations and formal verification of reconfig-
urable systems modelled in a product line.
This paper targets the integration of product line and
model checking for the formal verification of recon-
figurable system behaviour against its formal require-
ments. To achieve this, the objectives and related re-
quirements of reconfigurable system are mapped to
a feature model, whereas the units related to oper-
ational modes are selected in individual configura-
tions. To leverage the NuSMV model checker for
the formal verification, the automated transformations
of these models into LTL constraints and formal de-
scriptions are performed. Subsequently, the analysis
of model checker results is performed for the identi-
fication and resolution of deviations (i.e., incomplete-
ENASE 2021 - 16th International Conference on Evaluation of Novel Approaches to Software Engineering
ness, inconsistency and conflict), in order to satisfy
the configuration(s) with a feature model. The ap-
plicability of the proposed approach is demonstrated
through AOCS family/product line. It is noteworthy
that the proposed approach is generally applicable to
the broad range of scenarios and domains.
In the future, we plan to perform automatic extrac-
tion of feature and configuration models from docu-
ment files. We also plan to consider additional scenar-
ios and application, such as electric quarry site (Javed
et al., 2020). Another direction for future work is
to attach the evidence obtained from runtime model
checking with the assurance cases that are constructed
to provide comprehensive, logical and defensible jus-
tification of the safety and security of a reconfigurable
production system (Muram et al., 2020).
This work is partially supported by FiC (Future fac-
tories in the Cloud) project funded by SSF (Swedish
Foundation for Strategic Research). The third author
has also participated during the tenure of an ERCIM
Alain Bensoussan” Fellowship Programme.
Cimatti, A., Clarke, E. M., Giunchiglia, F., and Roveri,
M. (1999). NuSMV: A new symbolic model veri-
fier. In 11th Int’l Conf. on Computer Aided Verifica-
tion (CAV), pages 495–499.
Classen, A., Heymans, P., Schobbens, P., and Legay, A.
(2011). Symbolic model checking of software product
lines. In 33rd International Conference on Software
Engineering, ICSE ’11, Waikiki, Honolulu, HI, USA,
pages 321–330.
Gan, X., Dubrovin, J., and Heljanko, K. (2014). A sym-
bolic model checking approach to verifying satellite
onboard software. Sci. Comput. Program., 82:44–55.
Gruler, A., Leucker, M., and Scheidemann, K. D. (2008).
Modeling and model checking software product lines.
In 10th IFIP WG 6.1 International Conference on For-
mal Methods for Open Object-Based Distributed Sys-
tems, FMOODS ’08, Oslo, Norway, volume 5051,
pages 113–131.
Javed, M. A. and Gallina, B. (2018). Safety-oriented pro-
cess line engineering via seamless integration between
EPF composer and BVR tool. In 22nd International
Systems and Software Product Line Conference - Vol-
ume 2, SPLC ’18, Gothenburg, Sweden, pages 23–28.
Javed, M. A., Gallina, B., and Carlsson, A. (2019). To-
wards variant management and change impact anal-
ysis in safety-oriented process-product lines. In
34th ACM/SIGAPP Symposium on Applied Comput-
ing, SAC ’19, Limassol, Cyprus, pages 2372–2375.
Javed, M. A., Muram, F. U., Fattouh, A., and Punnekkat, S.
(2020). Enforcing geofences for managing automated
transportation risks in production sites. In Depend-
able Computing - EDCC Workshops, DREAMS ’20,
Munich, Germany, volume 1279, pages 113–126.
Lauenroth, K., Pohl, K., and Toehning, S. (2009). Model
checking of domain artifacts in product line engineer-
ing. In 24th IEEE/ACM International Conference on
Automated Software Engineering, ASE ’09, Auckland,
New Zealand, pages 269–280.
Lochau, M., Mennicke, S., Baller, H., and Ribbeck, L.
(2016). Incremental model checking of delta-oriented
software product lines. J. Log. Algebraic Methods
Program., 85(1):245–267.
Muram, F. U., Javed, M. A., Hansson, H., and Punnekkat,
S. (2020). Dynamic reconfiguration of safety-critical
production systems. In 25th IEEE Pacific Rim Interna-
tional Symposium on Dependable Computing, PRDC
’20, Perth, Australia, pages 120–129.
Muram, F. U., Javed, M. A., Tran, H., and Zdun, U. (2017).
Towards a framework for detecting containment viola-
tions in service choreography. In 2017 IEEE Interna-
tional Conference on Services Computing, SCC’ 17,
Honolulu, HI, USA, pages 172–179.
Muram, F. U., Tran, H., and Zdun, U. (2015). Counterex-
ample analysis for supporting containment checking
of business process models. In 13th International
Business Process Management Workshops, BPM ’15,
Innsbruck, Austria, volume 256, pages 515–528.
Muram, F. U., Tran, H., and Zdun, U. (2016). A model
checking based approach for containment checking of
UML sequence diagrams. In 23rd Asia-Pacific Soft-
ware Engineering Conference, APSEC ’16, Hamilton,
New Zealand, pages 73–80.
Muram, F. U., Tran, H., and Zdun, U. (2019). Support-
ing automated containment checking of software be-
havioural models using model transformations and
model checking. Sci. Comput. Program., 174:38–71.
Pnueli, A. (1977). The temporal logic of programs. In
18th Annual Symposium on Foundations of Computer
Science, Providence, Rhode Island, USA, SFCS ’77,
pages 46–57.
Shi, Y., Wei, O., and Zhou, Y. (2014). Model check-
ing partial software product line designs. In Interna-
tional Workshop on Innovative Software Development
Methodologies and Practices, InnoSWDev ’14, Hong
Kong, China, pages 21–29.
ter Beek, M. H., Legay, A., Lluch-Lafuente, A., and Vandin,
A. (2016). Statistical model checking for product
lines. In 7th International Symposium on Leveraging
Applications of Formal Methods, Verification and Val-
idation, ISoLA ’16, Imperial, Corfu, Greece, volume
9952, pages 114–133.
Supporting Automated Verification of Reconfigurable Systems with Product Lines and Model Checking