Supporting Automated Veriﬁcation of Reconﬁgurable 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

Keywords:

Reconﬁgurable Systems, Product Lines, Model Transformations, Model Checking, Formal Methods, LTL.

Abstract:

The capability to dynamically reconﬁgure in response to change of mode or function, failures, or unantici-

pated hazardous conditions is fundamental for many critical systems. The modelling and veriﬁcation of such

systems are frequently carried out with product lines and model checking, respectively. At ﬁrst, the objectives

and related requirements of reconﬁgurable systems are mapped to a feature model, whereas the units related

to operational modes are selected in individual conﬁgurations. 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 veriﬁcation of completeness, consistency and conﬂict

is carried out with NuSMV model checker. Finally, in circumstances when the counterexample is produced, its

analysis is performed for the identiﬁcation of corresponding problems and their resolutions. The applicability

of the proposed approach is demonstrated through case study of attitude and orbit control system.

1 INTRODUCTION

The principal intention of reconﬁgurable systems is to

enhance the responsiveness in consequence to mode

or function changes, environmental conditions and

unexpected failures (Muram et al., 2020). The recon-

ﬁgurable systems possess the advantages of both ded-

icated product lines and of ﬂexible systems. In par-

ticular, they focus on customized ﬂexibility that can

be supported through product lines. The product lines

have been used for the identiﬁcation and systemati-

zation of commonalities and variabilities to concur-

rently engineer a set of scenarios; the achievement of

a single conﬁguration 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 veriﬁcation of reconﬁgurable 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 veriﬁcation, for

example, (Gruler et al., 2008; Lauenroth et al., 2009;

Lochau et al., 2016). However, previous approaches

https://orcid.org/0000-0001-6613-4149

https://orcid.org/0000-0002-1079-9712

https://orcid.org/0000-0003-3781-4756

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 difﬁcult 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 veriﬁcation of reconﬁgurable sys-

tems. In particular, the objectives and related re-

quirements of reconﬁgurable 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

conﬁgurations are transformed into state based Sym-

bolic Model Veriﬁer (SMV) (Cimatti et al., 1999) lan-

guage. These transformations are achieved by us-

Muram, F., Kanwal, S. and Javed, M.

Supporting Automated Veriﬁcation of Reconﬁgurable 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

297

ing Eclipse Xtend. Speciﬁcally, the mapping rules

are deﬁned to transform the feature model and con-

ﬁgurations 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 veriﬁcation of

completeness, consistency and conﬂict is carried out

with the NuSMV

2.6.0, a new version of symbolic

model checker. Completeness considers whether a set

of conﬁgurations satisfy the system objectives and re-

lated requirements. Consistency checking examines

the correctness of conﬁgurations against the struc-

ture and sequence of the system. Conﬂict veriﬁes

whether the conﬁgurations 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 identiﬁcation 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 veriﬁcation of reconﬁgurable 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.

2 APPROACH

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 reconﬁguration 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)conﬁgurations 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)conﬁgurations, 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 conﬂict in reconﬁgurable systems. The violations

can be produced when the conﬁgurations 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

http://nusmv.fbk.eu/

and groups), and incompatible with the system (cross-

tree) constraints. Counterexample analysis detects the

violation cause(s) and provide measures to make the

conﬁgurations 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

Configurations

Transformation of

Feature Model

Transformation of

Configurations

LTL Formulas

SMV Descriptions

Model Checking

Verification Results:

True or False with a

Counterexample

Configurations

Configuration

Analysis of

Counterexample

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 conﬁguration(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 signiﬁcantly 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 veriﬁcation of reconﬁgurable systems is

a highly knowledge intensive endeavour. Therefore,

the mapping rules are deﬁned 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 deﬁni-

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

298

Table 1: Mapping Rules for a Feature Model.

Graphical Symbols Relationships Deﬁnition 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

Fn)

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 speciﬁc 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-ﬁrst 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 conﬁgurations into formal SMV model

(descriptions). The basic purpose of the SMV lan-

guage is to describe the transition relation of a ﬁ-

Supporting Automated Veriﬁcation of Reconﬁgurable Systems with Product Lines and Model Checking

299

Algorithm 1: Translate Models.

1: Input: Feature Model/Conﬁgurations

2: Output: LTL Formulas/SMV Descriptions

3: procedure TRANSFORM

4: S

← ∅  queue of non-visited features

5: S

← ∅  queue of visited features

6: S

← S

∪ get_parent_features(P)

7: for all f ∈ S

8: S

← S

∪ { f }

9: S

← 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

← S

∪ {r}

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 conﬁgurations

in terms of SMV descriptions provide the infrastruc-

ture to facilitate the veriﬁcation of completeness, con-

sistency and conﬂicts with a feature model, and es-

pecially, analysing the veriﬁcation results to provide

useful feedback for aiding the manager/developers in

resolving violations. Similar to the generation of LTL

formulas, the mapping of conﬁgurations 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 conﬁg-

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 identiﬁer 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 speciﬁed 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) deﬁnes 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

satisﬁed, it is changed to a True state. The branch

condition(s) can be a guard expression and/or ﬁnish-

ing of the preceding state. The feature’s state shall

be switched back to False after ﬁnishing 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: ’’’

5: MODULE



’’’

A consistent and complete set of conﬁgurations is

obtained by selecting a complete group of features

in a manner that follows a correct feature hierar-

chy. Moreover, the semantics of the conﬁgurations

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)conﬁguration of systems. While selecting the

conﬁgurations, 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 deﬁnes the transition re-

lation of features. The child-feature is initially set to

false. However, if the condition(s) are satisﬁed, 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 conﬁgurations which show that exactly one

ENASE 2021 - 16th International Conference on Evaluation of Novel Approaches to Software Engineering

300

1 MODULE main

2 VAR

3 ParentFeature : boolean;

4 ChildFeature : boolean;

5 ASSIGN

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 conﬁguration.

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-

ciﬁc conﬁguration. Figure 3 shows the rules for map-

ping an Alternative relationship into SMV descrip-

tions. For the purpose of veriﬁcation, 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 deﬁned, 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

conﬁgurations 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 conﬁguration 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

1 VAR

2 ParentFeature : boolean;

3 ChildFeature1 : boolean;

4 ...

5 ChildFeature3 : boolean;

6 -- temporary variable

7 tem_alternative_k : {undetermined,

selected_1 ,..., selected_3 };

8 ASSIGN

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 ) :=

undetermined;

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

: TRUE;

23 ChildFeature1 : FALSE;

24 esac;

25 init( ChildFeature3 ) := FALSE;

26 next( ChildFeature3 ) := case

27 tem_alternative_k = selected_3

: TRUE;

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 conﬁguration.

2.3 Formal Veriﬁcation and Dealing

with Violations

This subsection discusses the identiﬁcation and reso-

lution of violations (i.e., incompleteness, inconsisten-

cies and conﬂicts) in the reconﬁgurable systems. The

formal veriﬁcation 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 Veriﬁcation of Reconﬁgurable Systems with Product Lines and Model Checking

301

1 VAR

2 ParentFeature : boolean;

3 ChildFeature1 : boolean;

4 ChildFeature2 : boolean;

5 -- temporary variables

6 isSelected_1 : boolean;

7 isSelected_2 : boolean;

8 ASSIGN

9 ... -- the initialisation of

condition is omitted

10 init( ChildFeature1 ) := FALSE;

11 next( ChildFeature1 ) := case

12 ParentFeature & isSelected_1

: TRUE;

13 ChildFeature1 : FALSE;

14 esac;

15 ...

16 init( ChildFeature2 ) := FALSE;

17 next( ChildFeature2 ) := case

18 ParentFeature & isSelected_2 :

TRUE;

19 ChildFeature2 : FALSE;

20 esac;

Figure 4: Mapping rules for Or.

or features in conﬁgurations with respect to system

objectives and requirements. The inconsistency of

conﬁgurations 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. Conﬂict 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 conﬁgurations. The anal-

ysis of counterexample not only detects the typical

possible causes of incompleteness, inconsistency, and

conﬂict but also provides the recommendations to re-

solve the speciﬁc deviation.

To locate the causes of deviations, the veriﬁca-

tion result (i.e., output trace ﬁle) 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 ﬁnd

out why the particular conﬁguration(s) deviate from

the speciﬁcation deﬁned 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 reconﬁg-

ured and transformed again into to their formal de-

scriptions, and then will be re-veriﬁed until no more

deviations are detected.

3 CASE STUDY

In this section, we brieﬂy 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 speciﬁcations are presented. The standard

objectives and requirements for AOCS are mapped

into a feature model, whereas tailoring rules, cus-

tomer speciﬁcations, units related to AOCS opera-

tional modes are selected in individual conﬁgura-

tions (Javed et al., 2019). In this paper, we focus

on four different conﬁgurations 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-

ﬁgurations, Sun Sensors are used as the primary

sensor in combination with a Magnetometer to

provide full attitude determination capability. In

STTH and STRW conﬁgurations, a Star Tracker

is used as a primary attitude sensor. In all conﬁgu-

rations, the attitude is estimated using a kinematic

(Kalman) ﬁlter-based estimation for which Gyro

measurements are an exogenous input.

• Actuation Principles. In SSTH and STTH con-

ﬁgurations, the spacecraft attitude is modiﬁed us-

ing a Thruster actuator, whereas in SSRW and

STRW conﬁgurations, the spacecraft attitude is

primarily controlled using Reaction Wheels.

• Software Functional Modules. They are clas-

siﬁed 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

302

AttitudeandOrbit

ControlSystem

Guidance

Attitude

Guidance

Sensors

Sun

Sensor

Magnetometer

Gyro

SunSensorSignal

Conditioning

Magnetometer

SignalConditioning

ReactionWheel

SignalConditioning

Estimation

SunSensor/Magnetometer

MeasurementHandling

AttitudeEstimation

Filter

Control

Command

Distribution

Attitude

Control

ThrusterCommand

Distribution

Actuators

Thrusters

SoftwareFunctional

Modules

Sensor

Processing

Ground

Command

Star

Tracker

ReactionWheel

Tachometer

StarTrackerSignal

Conditioning

GyroSignal

Conditioning

StarTrackerMeasurement

Handling

AngularMomentum

Estimation

MomentumManagement

Control

ReactionWheelCommand

Distribution

MomentunManagement

Guidance

Reaction

Wheels

AOCS

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 qualiﬁcation of AOCS conﬁg-

urations, the formal veriﬁcation is performed by using

the NuSMV model checker. In particular, the AOCS

feature model and conﬁgurations 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 ﬁle 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 veriﬁcation

results including the list of satisﬁed and unsatisﬁed

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

See http://www.eclipse.org/xtend

$ NuSMV AOCS.smv

-- specification (G (Sensors -> F Gyro) & H (

Gyro -> O Sensors)) is false

-- as demonstrated by the following execution

sequence

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 Veriﬁcation Results.

Supporting Automated Veriﬁcation of Reconﬁgurable Systems with Product Lines and Model Checking

303

causes, the counterexample analysis is performed (as

depicted in Section 2.3). In this case, the speciﬁca-

tion of AOCS system is deviated due to (i) incom-

plete conﬁgurations, 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) conﬂict: an optional feature

StarTracker is added, but due to the excludes con-

straint, it has to be excluded in SSRW conﬁgura-

tion. These deviations can be resolved by adding

GroundCommand feature, removing StarTracker

feature in the SSRW conﬁguration 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 ﬁle in order to determine the rela-

tionship between the execution traces and models, and

then locate the corresponding violations manually.

4 RELATED WORK

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 conﬁgu-

rations of a PL-CCS program. However, the veriﬁ-

cation using a model checker is not performed that

is prerequisite for practical evaluation. For incre-

mental veriﬁcation of software product lines, a delta-

oriented extension of CSS (DeltaCCS) is described

in (Lochau et al., 2016). A core product (process) is

ﬁrst veriﬁed 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 speciﬁed with I/O-automata against provided

Computational Tree Logic (CTL) properties. The au-

thors just used three operators (EX, EU and EG) to

deﬁne 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 ﬁnite 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) satisﬁes 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 speciﬁcations 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 conﬁgurations 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 veriﬁcation of reconﬁg-

urable systems modelled in a product line.

5 CONCLUSIONS

This paper targets the integration of product line and

model checking for the formal veriﬁcation of recon-

ﬁgurable system behaviour against its formal require-

ments. To achieve this, the objectives and related re-

quirements of reconﬁgurable system are mapped to

a feature model, whereas the units related to oper-

ational modes are selected in individual conﬁgura-

tions. To leverage the NuSMV model checker for

the formal veriﬁcation, 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-

ﬁcation and resolution of deviations (i.e., incomplete-

ENASE 2021 - 16th International Conference on Evaluation of Novel Approaches to Software Engineering

304

ness, inconsistency and conﬂict), in order to satisfy

the conﬁguration(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 conﬁguration models from docu-

ment ﬁles. 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-

tiﬁcation of the safety and security of a reconﬁgurable

production system (Muram et al., 2020).

ACKNOWLEDGEMENTS

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.

REFERENCES

Cimatti, A., Clarke, E. M., Giunchiglia, F., and Roveri,

M. (1999). NuSMV: A new symbolic model veri-

ﬁer. In 11th Int’l Conf. on Computer Aided Veriﬁca-

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 reconﬁguration of safety-critical

production systems. In 25th IEEE Paciﬁc 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-Paciﬁc 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, Veriﬁcation and Val-

idation, ISoLA ’16, Imperial, Corfu, Greece, volume

9952, pages 114–133.

Supporting Automated Veriﬁcation of Reconﬁgurable Systems with Product Lines and Model Checking

305