Veriﬁcation of Feature Coordination using the Fluent Calculus

Ralph Hoch and Hermann Kaindl

Institute of Computer Technology, TU Wien, Austria

Keywords:

Veriﬁcation, Fluent Calculus, Situation Calculus, Model Checking.

Abstract:

Previously, an approach based on the Situation Calculus was published for specifying feature coordination

of a software system, but without a physical model or any additional autonomous agent in the environment.

Hence, no veriﬁcation of the feature coordination was possible in spite of its formal speciﬁcation. Veriﬁcation

of safety-critical feature coordination is important, however, and requires additional models. This paper shows

that a speciﬁcation of a software coordinator can be formally veriﬁed using the Fluent Calculus (a derivative

of the Situation Calculus), when combined with additional models. The overall qualitative model is a re-

implementation of a recently published one based on synchronized ﬁnite-state machines, which was used for

model checking. In fact, we show how the model in Fluent Calculus can be systematically derived from the

ﬁnite-state machines. The results of veriﬁcation using the Fluent Calculus correspond to those using model

checking. We also contrast our approach using the Fluent Calculus with model checking. In summary, we

present veriﬁcation of (safety-critical) feature coordination using the Fluent Calculus.

1 INTRODUCTION

Feature interaction occurs, when the interplay of two

or more features gives rise to an overall system be-

havior that is not easily deducible from the individual

behaviors of the features involved, and often unex-

pected (Apel et al., 2013). Undesired feature inter-

action can be safety-critical, e.g., in automotive sys-

tems. Hence, the veriﬁcation of such cyber-physical

systems including (embedded) software is important.

An approach for detecting feature interactions au-

tomatically through model checking can be found in

(Juarez-Dominguez et al., 2008). A feature inter-

action may result directly from conﬂicting requests

to a single variable in the software (as studied for

the speed of a vehicle in (Juarez-Dominguez et al.,

2008)). This is sufﬁcient for detecting that there is a

feature interaction, but not for investigating its inﬂu-

ence on the environment. This would require an addi-

tional physical model and a model of another vehicle,

which is an independent autonomous agent.

Bocovich and Atlee (Bocovich and Atlee, 2014)

also addressed feature interaction resulting from a

conﬂict of features accessing the same software vari-

able(s) at the same point in time. Since the granu-

larity of features may be relevant, resolution for each

software variable under conﬂict was proposed for fea-

ture coordination (with examples in the automotive

domain). They showed how such a resolution can

be speciﬁed using the Situation Calculus. However,

without a physical model or any additional embod-

ied entity in the environment, no veriﬁcation is pos-

sible of whether such a resolution as speciﬁed for the

software actually achieves its purpose in the overall

cyber-physical system.

According to (Rathmair et al., 2016), an additional

physical model is needed for model checking feature

coordination. This work modeled the inﬂuence of

speed also on the distance to another vehicle in the

context of Adaptive Cruise Control (ACC), which is

one of the more advanced features penetrating the au-

tomotive market (Winner and Schopper, 2015). It in-

cludes both Cruise Control (CC), as widely used in

cars, and Distance Control (DC) of a vehicle A fol-

lowing another vehicle B. Overall, this work modeled

a cyber-physical system qualitatively and used the re-

sulting model for model checking the coordination of

features.

Artiﬁcial Intelligence techniques like the Situation

Calculus may be a good ﬁt for modeling such a sys-

tem qualitatively, since they have been proposed and

used early on in the context of robot planning. Hence,

they offer also planning capabilities, so that not only

the speciﬁcation of a feature coordinator is possible,

but also some means for verifying whether it actually

works should be feasible. In this sense, our motiva-

tion was to check this feasibility using the ACC ex-

ample.

Hoch, R. and Kaindl, H.

Veriﬁcation of Feature Coordination using the Fluent Calculus.

DOI: 10.5220/0006771401690179

In Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2018), pages 169-179

ISBN: 978-989-758-300-1

169

We systematically transfer the model of (Rathmair

et al., 2016) to the Fluent Calculus, a derivative of the

Situation Calculus as used in (Bocovich and Atlee,

2014) for specifying feature coordination within soft-

ware, and use the resulting model for a new approach

to the veriﬁcation of cyber-physical feature coordi-

nation. This approach involves a tool supporting the

Fluent Calculus and a simple planner that we imple-

mented on top of it. When the planner can ﬁnd a se-

quence of actions for achieving a goal that formulates

a property to be avoided, then it actually presents an

example of what is to be avoided. This corresponds to

a counterexample in model checking. Hence, we also

contrast our new veriﬁcation approach based on the

Fluent Calculus with the widely studied veriﬁcation

approach based on model checking.

The remainder of this paper is organized in the fol-

lowing manner. First, we provide some background

material for making this paper self-contained, and re-

late it to other work. Then we present a system-

atic transformation from synchronized ﬁnite-state ma-

chines (FSMs) to a representation in the Fluent Calcu-

lus. Based on it, we explain our veriﬁcation approach

and show that it can deliver the same results as model

checking. Finally, we brieﬂy contrast it with model

checking.

2 BACKGROUND AND RELATED

WORK

We cover here some background on and related work

to the Fluent Calculus, feature coordination, model

checking, and the given model of ACC that we trans-

form to the Fluent Calculus for veriﬁcation with our

new approach.

2.1 Fluent Calculus

The original idea was introduced by McCarthy and

Hayes (McCarthy and Hayes, 1969) long time ago.

Their Situation Calculus consists of three elements:

1. Situations

represent the evolving states of the domain, where

certain conditions hold in each state.

2. Actions

represent the changes between situations. A spe-

cial predicate poss determines whether a speciﬁc

action can be performed or not.

3. Fluents

represent the elements of the domain that can

change over time. Typically, predicates are used

for this representation, which take a situation as an

argument. An example is the ﬂuent carrying(o,s),

which states if an object o is carried, e.g., by a

robot, in situation s.

Based on previous work on the Situation Calculus

such as (Reiter, 1991), Thielscher (Thielscher, 1998)

developed the Fluent Calculus. It differs from the Sit-

uation Calculus in how situations are treated and how

ﬂuents are used. The Fluent Calculus deﬁnes that a

new state after the execution of an action is equal to

the previous state with exceptions to the effects of the

action. In addition, ﬂuents are treated as functional

terms. The ﬂuents from the Situation Calculus are

stripped off the situation parameter, and special pred-

icates, e.g., holds, are introduced. These special pred-

icates take a functional term and a state as an argu-

ment. They are used to check whether speciﬁc con-

ditions hold in a speciﬁc state or not. For example,

the ﬂuent carrying(o,s) from the Situation Calculus

translates to a functional term carrying(o) in the Flu-

ent Calculus. Hence, this term is not depended on the

current state anymore. To check whether this term

holds in a speciﬁc state, the holds predicate is used,

e.g., holds(carrying(o), state).

Hence, the Fluent Calculus provides a formalism

to model speciﬁc actions that lead from one situa-

tion to another. This is speciﬁed using the poss and

state update predicates. These predeﬁned predicates

model the preconditions (poss statement) and effects

(state update) of an action. Together, they provide a

formal speciﬁcation of an action.

An implementation of the Fluent Calculus called

FLUX (Thielscher, 2005) is available for the con-

straint logic programming system ECLiPSe.

To il-

lustrate how such an action in Fluent Calculus is ap-

plied in FLUX, we use a simple example. Let us

assume that a vehicle B is currently driving with

medium speed and wants to change to high speed.

This simplistic example already utilizes the main

parts of the Fluent Calculus. The driving speed of

the vehicle changes over time and thus is a ﬂuent.

The change of the driving speed is performed by an

action. For this example, we assume that the name

of this action is switchMediumSpeedToHighSpeedVe-

hicleB. What is missing, is the situation of the do-

main. The current situation of vehicle B is medium

speed. This information is only part of a more com-

plex situation speciﬁcation, but is sufﬁcient for this

example. In essence, the action switchMediumSpeed-

ToHighSpeedVehicleB can only be executed if the cur-

rent speed of vehicle B is medium speed. This is

a precondition for the execution of the action. The

ECLiPSe Constraint Programming System:

http://www.eclipseclp.org

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

170

holds predicate checks if a speciﬁc value vehicleBIs-

SetTo(B, mediumSpeed) holds in state Z. Listing 1

shows this precondition in FLUX.

p o s s ( swi t c hMedi u m Speed T o HighS p e edVeh i c leB (B ) , Z)

:−

% I n p u t ha s t o be of t y p e V e h i c l e B %

knows_val ( [ B ] , v e h i c l e B ( B) , Z) ,

% P r e c o n d i t i o n t h a t t h e s p e e d o f B i s s e t t o

mediumSpeed i n S t a t e Z %

h o l d s ( v e h i c l e B I s S e t T o ( B , mediumSpeed ) , Z) .

Listing 1: Preconditions of the medium-to-high-speed

action in FLUX.

When the action is executed, it has effects on the sit-

uation of the domain, e.g., the speed of vehicle B

changes. In our example, vehicle B is set to high

speed. However, this is not sufﬁcient, since we also

have to specify that vehicle B is not driving with

medium speed anymore. This fact is removed from

the state. Listing 2 shows the effects of the action

in FLUX. Basically vehicleBIsSetTo(B, highSpeed)

is added and vehicleBIsSetTo(B, mediumSpeed) re-

moved from Z1 and results in Z2.

s t a t e _ u p d a t e ( Z1 ,

swi tch Med ium Spe edT oHi ghS pee dB (B ) , Z2 , [ ] ) :−

upd ate ( Z1 , % o r i g i n a l s t a t e %

% S t a t e m e n t s a dded t o t h e S t a t e %

[ v e h i c l e B I s S e t T o ( B , h i g h Spee d ) ] ,

% S t a t e m e n t s removed f rom t h e S t a t e %

[ v e h i c l e B I s S e t T o ( B , mediumSpeed ) ] ,

Z2 % new S t a t e i s s t o r e d i n Z2 %

) .

Listing 2: Effects of the medium-to high-speed-action in

FLUX.

In fact, we previously proposed a veriﬁcation ap-

proach based on the Fluent Calculus already in (Hoch

et al., 2015), which veriﬁes sequences of semanti-

cally speciﬁed services against the speciﬁcations of

its atomic services. In this paper, we propose a com-

pletely different veriﬁcation approach, where all pos-

sible sequences are exhaustively tried out by a planner

and checked against a goal condition that is actually

to be avoided.

2.2 Related Work on Feature

Coordination

Automatically detecting and analyzing feature inter-

actions is outside the scope of this paper, which fo-

cuses on coordinating features with known interac-

tions. Even if these are known, coordinating the fea-

tures involved poses additional challenges (Jackson

and Zave, 1998).

The formulation of resolutions as proposed in

(Bocovich and Atlee, 2014) uses the Situation Calcu-

lus implemented in GOLOG (Levesque et al., 1997).

This work did not investigate, however, the physical

effects from a feature interaction of a software vari-

able, and it did not include independent physical vari-

ables outside the control of the software. Hence, no

veriﬁcation was possible of whether such a resolution

as speciﬁed actually achieves its purpose.

In fact, we can also use this approach for speci-

fying a coordination of CC and DC as given in For-

mula 1.

Poss(setSpeedA(SPEED), Z) ≡

∃ValueCC.ccVehicleAIsSetTo(cc, ValueCC)∧

∃ValueDC.dcVehicleAIsSetTo(dc, ValueDC)∧

minimum(ValueCC, ValueDC, SPEED). (1)

The actual implementation in FLUX differs

slightly from this equation as we utilize several Poss

statements to express the minimum. Each Poss state-

ment has a set of non-overlapping conditions and the

minimum is built by choosing the ﬁtting Poss state-

ment. Since we use a qualitative model we chose this

approach.

GOLOG differs from FLUX in the way it handles

variable resolution. GOLOG uses (backward) regres-

sion as opposed to the forward progression of FLUX.

More information on this and how GOLOG programs

can be interpreted in FLUX is given in (Schiffel and

Thielscher, 2005).

2.3 Background on Model Checking

Model checking (or property checking) is a for-

mal veriﬁcation technique based on models of sys-

tem behavior and properties, speciﬁed unambigu-

ously in formal languages (see, e.g., (Baier and Ka-

toen, 2008)). The behavioral model of the system un-

der veriﬁcation is often speciﬁed using an FSM, in our

case using synchronized FSMs. Their expressiveness

is sufﬁcient for our case, but Petri nets, e.g., could be

used as well, if needed (depending on the tool used).

The properties to be checked on the behavioral model

are formulated in a speciﬁc property speciﬁcation lan-

guage, usually based on a temporal language. Several

tools such as NuSMV (NuSMV, 2014) exist for per-

forming these checks by systematically exploring the

state-space of the system. When such a tool ﬁnds a

property violation, it reports it in the form of a coun-

terexample.

Many model checking approaches use Computa-

tional Tree Logic (CTL) for property speciﬁcation,

with the following CTL operators:

Veriﬁcation of Feature Coordination using the Fluent Calculus

171

• AG (Always Globally): an expression p is true in

the initial state s

and in each state of all transi-

tions s

→ s

→ ··· → s

• EF (Eventually in the Future): for an expression p

and an initial state s

, there exists a state sequence

→ s

→ ··· → s

such that p is true in s

2.4 A Given Minimalist Model of ACC

Our example, as adopted from (Rathmair et al., 2016),

is based on Adaptive Cruise Control (ACC). The

high-level structure of this model is illustrated in Fig-

ure 1.

Figure 1: High-level structure of ACC model used.

It contains a model of vehicle A, which involves

a Coordinator of CC and DC. It also contains vehicle

B, whose behavior is, of course, not under control of

vehicle A. And it contains a simple physical model

of the environment, where the distance between vehi-

cles A and B is important with respect to a potential

accident.

The property that such a model has been checked

against in (Rathmair et al., 2016) formalizes such an

accident, more precisely a rear-end collision accident

that DC has to avoid, and hence also ACC. Formula 2

deﬁnes this property in CTL in the sense that it is al-

ways (globally) true that the physical distance is dif-

ferent from a collision:

AG(state phy dist 6= COLLISION) (2)

3 MODELING CYBER-PHYSICAL

FEATURE COORDINATION IN

THE FLUENT CALCULUS

Rather than creating a new model from scratch, we

built upon the qualitative model of ACC as deﬁned

in (Rathmair et al., 2016). In contrast to the original

model, we used the Fluent Calculus for modeling the

cyber-physical system including the feature coordina-

tion. Hence, we transform the given model in syn-

chronous FSMs to a model represented in the Fluent

Calculus, where both models are supposed to capture

the same overall behavior of ACC. In fact, we spec-

ify a systematic transformation approach that could,

in principle, also be automated.

Instead of replicating exactly the same FSMs from

(Rathmair et al., 2016) here, we present isomorphic

FSMs below, which have already action names as la-

bels, i.e. names of the actions to be formally deﬁned

in the Fluent Calculus. This is primarily for didactic

reasons, so that it will be easier to see the correspon-

dence of the FSMs with the actions as deﬁned in the

Fluent Calculus.

First, we have to specify how the following terms

in the Fluent Calculus are derived:

• terms identifying the state machines,

• terms for each state in each state machine,

• terms for each state transition.

Based on these terms, we deﬁne the preconditions and

effects of all actions as derived from the conditions of

state transitions, the state from where a transition is

going out (its root), and the state where the transition

leads to (its target).

Before we actually explain the details of the

derivation of these terms, let us show the FSM on the

behavior of vehicle B as an example. This FSM, as

given in Figure 2, is isomorphic to the FSM labeled

Vehicle B in (Rathmair et al., 2016, Figure 6). The

action names on transitions are abbreviated in Fig-

ure 2. They are automatically inferred from the orig-

inal model according to the rules deﬁned in the text.

For example MtL translates to switchMediumSpeed-

ToLowSpeedVehicleB.

Figure 2: FSM of vehicle B.

The systematic transformation approach to this

derivation is as follows:

• Each FSM is a term {FSM.name}{FSM.context}

with an argument. The argument {FSM.name} is

a constant used during the veriﬁcation process to

ensure that actions are only performed when ap-

propriate. The sufﬁx {FSM.context} is not neces-

sary, but makes the term more human readable.

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

172

Figure 3: FSM of vehicle A.

Example: FSM of CC is ccVehicleA(cc).

FSM.context is VehicleA since CC is executed for

Vehicle A.

• Each FSM is also a compound term {FSM.name}

{FSM. context} IsSetTo(object, value) with two

arguments. This term may change over time and

thus is a ﬂuent. The ﬁrst argument is the object on

which the term operates and the second argument

is the value.

Example: FSM of CC results in ccVehicleAIs-

SetTo(object, value), where object and value are

to be reset for concrete values, e.g., ccVehicleAIs-

SetTo(cc, requLowSpeed).

• Each state of an FSM is a value that the term

of this FSM can hold. The value is repre-

sented as a constant and is the name of the state

{FSM.state.name}{FSM.name}.

Example: The state Requ Low Speed of the

CC FSM in Vehicle A results in the value re-

quLowSpeedCC. This value is used with the

corresponding term ccVehicleAIsSetTo of the

FSM. The result is ccVehicleAIsSetTo(cc, re-

quLowSpeedCC).

• Each transition in an FSM is transformed to an

action in the Fluent Calculus. The name of

the action is deﬁned through the root and target

state of the transition and is switch {FSM. transi-

tion.root.name} To {FSM.transition.target.name}

{FSM. name}.

Example: The transition in the CC FSM from

Figure 4: FSM of the distance classiﬁcation.

Requ Medium Speed to Requ Low Speed re-

sults in the action switchRequMediumSpeedToRe-

quLowSpeed.

Much as Figure 2 shows the action names for ve-

hicle B, Figure 3 shows the action names for vehicle

A and Figure 4 the distance classiﬁcation in the envi-

ronment.

The FSM in Figure 2 contains the action

switchMediumSpeedToHighSpeedVehicleB as a label

of a transition. In fact, it corresponds to the example

of an action speciﬁed in the Fluent Calculus above (in

the Background section). Still, we have to explain

how the action speciﬁcations can be systematically

transformed from the FSMs (based on the terms de-

rived above).

The systematic transformation of transitions in

FSMs to actions in the Fluent Calculus is as follows:

• Transitions between states are transformed to ac-

tions. Actions consist of state update and poss

statements.

• Conditions of the actions are given as proposi-

tional logic formulas in disjunctive normal form.

• The arguments of an action are all distinct ele-

ments of the propositional logic formula.

• The root of the state transition in the FSM is a

precondition in the corresponding poss statement

of the action in the Fluent Calculus.

• For each disjunctive part of the condition of a tran-

sition, one poss statement is created.

• The effects of an action are modeled via a

state update predicate.

• The positive effect of an action is the target node.

• The negative effect of an action is the root node.

To demonstrate this systematic transformation,

let us consider the transition from low speed to

medium speed in the Coordinator FSM. It consists of

two separate or-connected conditions condCo M and

condCo H given as propositional formulas in (Rath-

mair et al., 2016). These conditions consist of several

logical expressions related to states in the FSMs. The

disjunctive normal form of this condition is shown in

Listing 3.

Veriﬁcation of Feature Coordination using the Fluent Calculus

173

(

( requMediumSpeedCC ∧ ¬requLowSpeedDC ) ∨

( ¬requLowSpeedDC ∧ requMediumSpeedDC )

) ∨

(

requHighSpeedCC ∧

¬requLowSpeedDC ∧

¬requMediumSpeedDC

) ∨

(

¬requLowSpeedDC ∧

¬requMediumSpeedDC ∧

requH ighSp eedDC

)

Listing 3: Example condition on a transition.

Hence, there are or-connected blocks of and-

connected atoms. Each or-block, e.g., (requMedi-

umSpeedCC ∧ ¬requLowSpeedDC), is treated as

one set of preconditions for an action, in this case

the switchLowSpeedToMediumSpeedCoordinator ac-

tion. That is, the action can only be executed

if (at least) one set of preconditions is fulﬁlled.

E.g., the precondition set (requMediumSpeedCC ∧

¬requLowSpeedDC) states, that the corresponding

action can only be executed if the cruise control re-

quests medium speed and, at the same time, the dis-

tance control does not request low speed.

In the Coordinator FSM, the condition on

the transition states that the CC FSM has to

be in state requMediumSpeed and the DC FSM

cannot be in state requLowSpeed to trigger the

transition. In the Fluent Calculus, these states

are terms ({FSM.state.name}{FSM.name}) re-

lated to the terms of the FSM ({FSM.name}

{FSM.context}IsSetTo(object, value)) and, thus, we

can systematically derive a representation. For exam-

ple, the atomic element requMediumSpeedCC in the

condition is a value of ccVehicleAIsSetTo and only

holds if ccVehicleAIsSetTo(cc, requMediumSpeedCC)

is true. That is, this part of the condition only evalu-

ates to true if cruise control requests medium speed.

This is one part of the precondition set. The second

part is ¬requLowSpeedDC and is transformed to

dcVehicleAIsSetTo(DC, requLowSpeedDC). Together,

they are one precondition set for the corresponding

switchLowSpeedToMediumSpeedCoordinator action.

Preconditions are checked via the poss predicate

in the Fluent Calculus. In fact, there can be many

poss statements with different conditions for one ac-

tion. We utilize this and generate one poss statement

per precondition set. Each poss statement also con-

tains the root state of the transition in the FSM as an

additional precondition. Hence, the switch from low

speed to medium speed has the additional precondi-

tion that the coordinator has currently set the speed to

low speed. Corresponding poss statements in FLUX

for the ﬁrst two or-connected sets in Listing 3 are

shown in Listing 4.

% requMediumSpeedCC and n o t requLowSpeedDC %

p o s s ( swit c h L owSpeed T o M ediumS p e e d Coordi n a t or (A ,

DC, CC) , Z ) :−

% o b j e c t t h a t t h e a c t i o n o p e r a t e s on %

knows_val ( [ A] , v e h i c l e A (A) , Z ) ,

% r o o t s t a t e i n FSM a s a p r e c o n d i t i o n %

h o l d s ( c o o r d i n a t o r V e h i l c e A I s S e t T o ( A, l owSpeed ) ,

Z ) ,

% requMediumSpeedCC p r e c o n d i t i o n %

h o l d s ( c c V e h i c l e A I s S e t T o ( CC, requMediumSpeedCC ) ,

Z ) ,

% n o t requLowSpeedDC p r e c o n d i t i o n %

knows_not ( d c V e h i c l e A I s S e t T o (DC,

requLowSpeedDC ) , Z ) .

% requMediumSpeedDC and n o t RequLowSpeedCC %

p o s s ( swit c h L owSpeed T o M ediumS p e e d Coordi n a t or (A ,

DC, CC) , Z ) :−

% o b j e c t t h a t t h e a c t i o n o p e r a t e s on %

knows_val ( [ A] , v e h i c l e A (A) , Z ) ,

% r o o t s t a t e i n FSM a s a p r e c o n d i t i o n %

h o l d s ( c o o r d i n a t o r V e h i l c e A I s S e t T o ( A, l owSpeed ) ,

Z ) ,

% requMediumSpeedDC p r e c o n d i t i o n %

h o l d s ( d c V e h i c l e A I s S e t T o (DC, requMediumSpeedDC ) ,

Z ) ,

% n o t requLowSpeedCC p r e c o n d i t i o n %

knows_not ( c c V e h i c l e A I s S e t T o (CC,

requLowSpeedCC ) , Z ) .

Listing 4: Example poss statements for actions.

The arguments of the action are given through the

elements it depends on. In Listing 4, the arguments

are A, DC and CC, or the vehicle, the distance con-

trol and the cruise control, respectively. It has to be

noted that this is not necessarily required, the argu-

ments could also be omitted, but we include them for

better readability.

Still missing are the effects of an action. The ef-

fects are the ﬂuents that are added and removed when

an action is performed. In our example, the effect of

switching from low speed to medium speed is that the

vehicle is driving with medium speed after execution

of the action. Additionally, the fact that the vehicle

is driving low speed has to be removed. Hence, the

positive effect is the addition of the target state as a

value, and the negative effect is the removal of the

root state as a value. The effects are speciﬁed via the

state update predicate and shown in Listing 5.

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

174

s t a t e _ u p d a t e ( Z1 ,

switch L o w SpeedTo M e d iumSpe e d C oordina t o r (A, _ ,

_ ) , Z2 , [ ] ) :−

upd ate ( Z1 ,

% p o s i t i v e e f f e c t : a d d in g medium s p e e d %

[ c o o r d i n a t o r V e h i l c e A I s S e t T o (A, mediumSpeed ) ] ,

% n e g a t i v e e f f e c t : r e m o v i ng low s pe e d %

[ c o o r d i n a t o r V e h i l c e A I s S e t T o (A, l owS peed ) ] ,

) .

Listing 5: Example state update statement of an action.

Using the systematic transformation deﬁned

above, a very verbose model results. Often, many

state transitions in the FSM have the same conditions

but different root states, or they have repeating condi-

tions on different state transitions. For example, the

condCo M condition shown above is used in a transi-

tion from low speed to medium speed, medium speed

to medium speed and high speed to medium speed.

With this in mind, the transformation can be op-

timized. All conditions that are repeated on differ-

ent state transitions leading to the same state can be

written as a single poss statement. In this case, the

root nodes are or-connected preconditions. Hence,

condCo M can also be written as shown in Listing 6.

Note, that also the name of the action has changed,

since it does not depend on the root state anymore.

% requMediumSpeedDC and n o t requLowSpeedDC %

p o s s ( sw i tchTo M ediu m Speed Vehic l eA (A , DC, CC) , Z ) :−

% o b j e c t t h a t t h e a c t i o n o p e r a t e s on %

knows_val ( [ A] , v e h i c l e A (A) , Z ) ,

(

% r o o t s t a t e low s p e e d a s a p r e c o n d i t i o n %

h o l d s ( c o o r d i n a t o r V e h i l c e A I s S e t T o ( A,

low Spee d ) , Z ) ;

% r o o t s t a t e medium sp e e d a s a p r e c o n d i t i o n %

h o l d s ( c o o r d i n a t o r V e h i l c e A I s S e t T o ( A,

mediumSpeed ) , Z ) ;

% r o o t s t a t e h i gh s p e e d a s a p r e c o n d i t i o n %

h o l d s ( c o o r d i n a t o r V e h i l c e A I s S e t T o ( A,

h i g h S p e e d ) , Z )

) ,

% requMediumSpeedCC p r e c o n d i t i o n %

h o l d s ( c c V e h i c l e A I s S e t T o ( CC, requMediumSpeedCC ) ,

Z ) ,

% n o t requLowSpeedDC p r e c o n d i t i o n %

knows_not ( d c V e h i c l e A I s S e t T o (DC,

requLowSpeedDC ) , Z ) .

% n o t requLowSpeedCC a nd requMediumSpeedDC %

p o s s ( sw i tchTo M ediu m Speed Vehic l eA (A , DC, CC) , Z ) :−

% o b j e c t t h a t t h e a c t i o n o p e r a t e s on %

knows_val ( [ A] , v e h i c l e A (A) , Z ) ,

(

% r o o t s t a t e low s p e e d a s a p r e c o n d i t i o n %

h o l d s ( c o o r d i n a t o r V e h i l c e A I s S e t T o ( A,

low Spee d ) , Z ) ;

% r o o t s t a t e medium sp e e d a s a p r e c o n d i t i o n %

h o l d s ( c o o r d i n a t o r V e h i l c e A I s S e t T o ( A,

mediumSpeed ) , Z ) ;

% r o o t s t a t e h i gh s p e e d a s a p r e c o n d i t i o n %

h o l d s ( c o o r d i n a t o r V e h i l c e A I s S e t T o ( A,

h i g h S p e e d ) , Z )

) ,

% requMediumSpeedDC p r e c o n d i t i o n %

h o l d s ( d c V e h i c l e A I s S e t T o (DC, requMediumSpeedDC ) ,

Z ) ,

% n o t requLowSpeedCC p r e c o n d i t i o n %

knows_not ( c c V e h i c l e A I s S e t T o (CC,

requLowSpeedCC ) , Z ) .

Listing 6: Example optimized poss statements for actions.

The effects of this action have to be adapted as

well. The result is shown in Listing 7.

s t a t e _ u p d a t e ( Z1 , s w itch T oMed i umSpe e dVeh i cleA (A,

_ , _ ) , Z2 , [ ] ) :−

upd ate ( Z1 ,

% p o s i t i v e e f f e c t : a d d in g medium s p e e d %

[ c o o r d i n a t o r V e h i l c e A I s S e t T o (A, mediumSpeed ) ] ,

% n e g a t i v e e f f e c t : r e m o v i ng low s pe e d AND

h i g h s p e e d %

[

c o o r d i n a t o r V e h i l c e A I s S e t T o ( A, l owSp eed ) ,

c o o r d i n a t o r V e h i l c e A I s S e t T o ( A, h i g h S p eed ) ] ,

) .

Listing 7: Example of optimized state update statement of

an action.

Certain self-transitions can be omitted as well. For

example, it is not necessary to set the speed in cruise

control to high speed if it is already at high speed.

However, for the sake of veriﬁcation, the approach

described above is sufﬁcient and further optimizations

are omitted here.

With the approach deﬁned above, the environ-

ment part is transformed accordingly. After the trans-

formation, the Coordinator shown in Figure 3 al-

ready contains the means to resolve conﬂicts of fea-

tures. This approach is similar to the one introduced

by Bocovich et al. (Bocovich and Atlee, 2014) (and

sketched above), since actions may inﬂuence the same

variable. In contrast, in our case the variable is not a

single statement, but a value of different terms. The

conﬂict between the values of these terms are resolved

in the coordinator according to the deﬁnition in (Rath-

mair et al., 2016). Although we do not use the same

variable, the approach of Bocovich et al. could be

implemented as well. Currently, our model uses re-

quMediumSpeedDC and requMediumSpeedCC to de-

ﬁne values of terms related to DC and CC. However,

there could also be one general term requestSpeedIs-

SetTo(speed, Value) that states a request on the speed

variable. In this case, the variable resolution of Bo-

covich et al. can be used directly.

Veriﬁcation of Feature Coordination using the Fluent Calculus

175

4 VERIFICATION BASED ON

THE FLUENT CALCULUS

USING A PLANNER

Much as veriﬁcation through (unbounded) model

checking provides a proof (or disproof) of given prop-

erties (such as strict avoidance of a collision situa-

tion), we strive for such a veriﬁcation based on the

Fluent Calculus. A key question is how to handle

such a property in this context, and how to check

it. The Situation Calculus and the Fluent Calculus

have been used traditionally, e.g., for robot planning,

where a formula speciﬁes a goal condition. In such

a setting, the planner tries to ﬁnd a sequence of ac-

tions (called a plan) that leads to a situation where this

condition is fulﬁlled. Our key idea for veriﬁcation us-

ing a planner is to formulate a property to be avoided

(e.g., a collision) as a goal condition. If the planner

ﬁnds a related plan for achieving such a goal condi-

tion, then it actually presents an example of what is

to be avoided. This corresponds to a counterexample

in model checking. Otherwise, however, the planner

needs to perform an exhaustive search that does not

ﬁnd any such goal for proving that no property viola-

tion can occur. Note, that this approach uses a plan-

ner for veriﬁcation, while the approach in (Bensalem

et al., 2014) uses a model checker for planning.

Under such an exhaustive search regime, each and

every combination of actions is visited, so that the

search space is fully explored. Any search approach

could be used, in principle, for implementing such an

exhaustive planner. We chose depth-ﬁrst search be-

cause of its linear-space requirements, and since it is

already provided in the PROLOG-based tool environ-

ment. In essence, all possible sequences of actions are

tried recursively until a situation with the given goal

condition is found, or all possibilities are exhausted.

Starting from the given root node, the ﬁrst child node

is generated. From this newly generated node, again

the ﬁrst child node is generated. In this way, the

depth-ﬁrst search follows one path in the tree until

it cannot be extended any further (having reached a

leaf node), from where it backtracks to the previous

node and continues with the next node, etc. This is

illustrated in Figure 5(a). This search continues until

a situation satisfying the goal condition is found, or

there is no further action to be tried.

It is well known, however, that depth-ﬁrst search

can, in general, result in inﬁnite cycles. This hap-

pens if and when an action leads from one situation

to an already visited situation on the same path. Fig-

ure 5(b) illustrates an example of such a cycle. To pre-

vent this, usually the already visited nodes are stored

for guaranteeing that only new situations are explored

Figure 5: Search space of planner.

in each path. When the already visited situations are

stored, the search can look them up and recognize that

a newly generated situation, e.g., node S3 in the ﬁg-

ure, is the same as an already visited one, e.g., node

S1. This path is terminated and the planner backtracks

to continue with the next situation, e.g., node S4. With

this cycle detection and avoidance, a termination of

the search is guaranteed for a ﬁnite state space.

Storing only the visited nodes for the path from

the root to the currently visited situation has linear-

space requirements. However, this may lead to visit-

ing situations more than once, if they can be reached

from the root via several different paths. This is called

a directed acyclic graph (DAG). An example of such

a graph is illustrated in Figure 5(c). We chose to store

all visited states for detecting DAGs as well and for

terminating corresponding branches. For example, in

Figure 5, node S3/S6 can be reached through two dif-

ferent paths. However, the child nodes of S3/S6 only

have to be expanded once. When arriving again from

node S5, the path can be terminated. In general, this

approach has exponential space requirements, but it

can still be used when enough storage is available

(like in our example). For implementing such an ap-

proach to storing nodes, many PROLOG engines pro-

vide a tabling technique. The engine in ECLiPSe,

however, has no built-in support for tabling, which

made a custom implementation necessary.

So far, this planning approach looks straight-

forward, but there is an intricacy involved. As de-

scribed in the previous section, each FSM has a

predicate with corresponding actions. In the model-

checking tool NuSMV (used in (Rathmair et al.,

2016)), all state transitions of all the synchronous

FSMs happen in one execution cycle. This is in con-

trast to our planner, where the actions are executed

one after the other. To ensure that each part of the

overall system has all information available for its ex-

ecution, a linearization is required. Since some parts

of the system depend on environment values, a spe-

ciﬁc order of execution can be derived. For exam-

ple, the distance control depends on the value of the

distance classiﬁcation. The coordinator depends on

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

176

the distance and cruise control. In contrast, the cruise

control and vehicle B do not depend on the other parts

of the model. Hence, a possible execution sequence

for the planner is:

1. Vehicle B

2. CC (of vehicle A)

3. DC (of vehicle A)

4. Coordinator (of vehicle A)

5. Distance classiﬁcation

However, this execution sequence does not take

into account that sensor values can only be read with

a delay, which is essential in the model in (Rathmair

et al., 2016). Since the distance control measures the

speed of vehicle B and also the distance, there is such

a delay involved. In the original model of (Rathmair

et al., 2016), this is solved by using temporary vari-

ables that hold the values of the previous cycle. In

our approach, this delay of sensors is implemented

by rearranging the execution sequence of the actions.

Since DC has to use the values of the previous cycle,

the actions of vehicle B and the distance classiﬁcation

are the last steps in an execution cycle. By doing so,

DC can only access the values of the previous cycle,

since the new values are generated thereafter. Fig-

ure 6 illustrates this execution cycle actually used by

our planner, whose implementation in FLUX is given

in Listing 8.

Figure 6: Execution cycle.

s c h e d u l e _ p l a n ( Z , P , Zn ) :−

(

% f i r s t : e x e c u t e CC %

schedul e _ p l anCCA (Z , P , Z1 ) ,

% s econ d : e x e c u t e DC, u s e r e s u l t of CC a s

world s t a t e %

sched u l e_pla n D CA ( Z1 , P , Z2 ) ,

% t h i r d : e x e c u t e C o o r d i n a t o r , u s e r e s u l t o f

DC a s w o r l d s t a t e %

s c h e d u l e _ p l a n C o o dA ( Z2 , P , Z3 ) ,

% f o u r t h : e x e c u t e V e h i c l e B , u s e r e s u l t o f

C o o r d i n a t o r a s w o r l d s t a t e %

s c h e d u le_ p l a n V e hB ( Z3 , P , Z4 ) ,

% f i f t h : e x e c u t e D i s t a n c e C l a s s i f i c a t i o n , u s e

r e s u l t o f V e h i c l e B a s w o r l d s t a t e %

s c h e d u l e _ p l a n D i s t a n c e ( Z4 , P , Z5 )

) ,

s c h e d u l e _ p l a n ( Z5 , P , Zn ) . % c o n t i n u e w i t h n e x t

c y c l e %

Listing 8: Planner in FLUX.

Each schedule planXX statement calls a function

that determines, which speciﬁc action of the FSM is

executed. The possible actions are all actions that are

generated for a speciﬁc FSM. Only one of the actions,

based on their preconditions, is chosen and executed.

Listing 9 shows the possible actions for Vehicle B.

s c h e d u l e _pla n S p e e d V e hB ( Z , [ VehB | P ] , Zn ) :−

( VehB= s w itchTo L o w SpeedV e h icleB ( _ ) ,

p o s s ( VehB , Z ) , s t a t e _ u p d a t e ( Z , VehB , Z1 , [ ] ) ) ;

( VehB= s witch T o Mediu m Speed V e hicl e B ( _ ) ,

p o s s ( VehB , Z ) , s t a t e _ u p d a t e ( Z , VehB , Z1 , [ ] ) ) ;

( VehB= swit c h T o H i g hSpe e d V e h i c l eB ( _ ) ,

p o s s ( VehB , Z ) , s t a t e _ u p d a t e ( Z , VehB , Z1 , [ ] ) ) ;

( VehB= " VehB − N o t h i n g " , Z1=Z , t r u e ) .

Listing 9: Vehicle B planner.

The sequence given in Listing 8 is executed until

the goal state is reached or the exhaustive search is

ﬁnished. In our case, the goal condition is a property

to be avoided. It is fulﬁlled if and when the distance

classiﬁcation detects a collision. Listing 10 speciﬁes

this property in FLUX.

s c h e d u l e _ p l a n ( Z , _ , Z ) :−

knows_val ( [ D i s t a n c e ] , d i s t a n c e I s S e t T o ( D i s t a n c e ,

c o l l i s i o n ) , Z ) .

Listing 10: Property to be avoided.

5 CONTRASTING WITH MODEL

CHECKING

Now let us contrast this new approach with model

checking. We do this in terms of veriﬁcation results,

execution time for veriﬁcation of our example, and

conceptually.

First of all, it is important that our new approach

using the Fluent Calculus delivers the same veriﬁca-

tion results as model checking (as reported in (Rath-

mair et al., 2016)). Hence, we ran the planner as spec-

iﬁed above, and it did not ﬁnd a plan (a sequence of

actions) leading to a goal speciﬁed through the colli-

sion property. This veriﬁed the model, and this veri-

ﬁcation result is consistent with the veriﬁcation result

reported in (Rathmair et al., 2016) for the model that

we transformed ours from systematically (as speciﬁed

above). Rathmair et al. model-checked a slightly sim-

pler model as well (one without the Too Close state in

the distance classiﬁcation). This led to a counterex-

ample of a collision. We modiﬁed our derived model

in the same way and, in fact, our planner found a se-

quence of actions leading to a goal state with the colli-

sion condition. Therefore, also our approach based on

the Fluent Calculus did not verify this simpler model.

Again, this result is consistent with the one reported

in (Rathmair et al., 2016).

Veriﬁcation of Feature Coordination using the Fluent Calculus

177

According to (Rathmair et al., 2016), a veriﬁca-

tion run against the collision property using the model

checking tool NuSMV takes a fraction of a second

on a usual PC. We measured the execution times

needed for veriﬁcation by our planner, and they are

also within a fraction of a second.

Hence, for this minimalist model, the execu-

tion times for veriﬁcation are negligible for both ap-

proaches. As our planner is not really optimized for

speed, it is conceivable that model checking will run

faster for larger search spaces than our planner. Still,

such a comparison for scaling is left for future work.

Anyway, in theory the complexity is the same for both

approaches (without bounds).

We use the Fluent Calculus as a means for veri-

ﬁcation in this paper, but such a model may be used

for other purposes as well. Since the model primar-

ily speciﬁes actions, these speciﬁcations may also be

used for planning or plan execution. After all, re-

lated approaches have been proposed long time ago in

the context of robot planning and execution, see, e.g.,

(Nilsson, 1982). This is in contrast to model check-

ing, where only veriﬁcation is possible.

6 CONCLUSION

In this paper, we propose a new approach to formal

and automated veriﬁcation based on the Fluent Cal-

culus. While previously only the speciﬁcation of a

software feature coordinator was published in (Bo-

covich and Atlee, 2014), our approach can formally

verify it. This requires additional models of the en-

vironment (an autonomous agent and some simple

physics), which facilitate verifying safety of software

more generally.

This approach is fully implemented for the model

in (Rathmair et al., 2016), from which our represen-

tation in the Fluent Calculus is systematically trans-

formed from. We also propose this transformation

here, which could be more generally used for deriving

representations in the Fluent Calculus. This calculus

(much as the Situation Calculus) is usually employed

for planning and plan execution, where re-planning is

more ﬂexible at run-time than using FSMs.

It is hard to judge, in general, which formal veri-

ﬁcation approach is easier to use. For someone hav-

ing speciﬁed a feature coordinator according to (Bo-

covich and Atlee, 2014) through such a calculus, us-

ing it for veriﬁcation purposes as well seems more

appropriate than using FSMs and model checking.

ACKNOWLEDGMENT

The FeatureOpt project (No. 849928), is funded

by the Austrian Federal Ministry of Transport, In-

novation and Technology (BMVIT) under the pro-

gram “ICT of the Future” between June 2015 and

May 2018. More information can be found at

https://iktderzukunft.at/en/.

REFERENCES

Apel, S., Batory, D., K

astner, C., and Saake, G. (2013).

Feature-Oriented Software Product Lines: Concepts

and Implementation. Springer.

Baier, C. and Katoen, J.-P. (2008). Principles of Model

Checking. MIT Press, Cambridge, MA, USA.

Bensalem, S., Havelund, K., and Orlandini, A. (2014). Ver-

iﬁcation and validation meet planning and scheduling.

International Journal on Software Tools for Technol-

ogy Transfer, 16(1):1–12.

Bocovich, C. and Atlee, J. M. (2014). Variable-speciﬁc

resolutions for feature interactions. In Proceedings

of the 22Nd ACM SIGSOFT International Symposium

on Foundations of Software Engineering, FSE 2014,

pages 553–563, New York, NY, USA. ACM.

Hoch, R., Kaindl, H., Popp, R., Ertl, D., and Horacek,

H. (2015). Semantic Service Speciﬁcation for V&V

of Service Composition and Business Processes. In

Proceedings of the 48nd Annual Hawaii International

Conference on System Sciences (HICSS-48), Piscat-

away, NJ, USA. IEEE Computer Society Press.

Jackson, M. and Zave, P. (1998). Distributed feature com-

position: A virtual architecture for telecommunica-

tions services. IEEE Transactions on Software En-

gineering (TSE), 24(10):831–847.

Juarez-Dominguez, A. L., Day, N. A., and Joyce, J. J.

(2008). Modelling feature interactions in the automo-

tive domain. In Proceedings of the 2008 International

Workshop on Models in Software Engineering, MiSE

’08, pages 45–50, New York, NY, USA. ACM.

Levesque, H. J., Reiter, R., Lesp

erance, Y., Lin, F., and

Scherl, R. B. (1997). Golog: A logic programming

language for dynamic domains. The Journal of Logic

Programming, 31(1):59 – 83.

McCarthy, J. and Hayes, P. J. (1969). Some philosophi-

cal problems from the standpoint of artiﬁcial intelli-

gence. In Meltzer, B. and Michie, D., editors, Machine

Intelligence 4, pages 463–502. Edinburgh University

Press, Edinburgh.

Nilsson, N. J. (1982). Principles of Artiﬁcial Intelligence.

Springer, Berlin, Heidelberg, Germany.

NuSMV (2014). NuSMV: a new symbolic model checker.

Rathmair, M., Luckeneder, C., and Kaindl, H. (2016). Min-

imalist qualitative models for model checking cyber-

physical feature coordination. In Proceedings of the

23rd Asia-Paciﬁc Software Engineering Conference

(APSEC), USA. IEEE.

Reiter, R. (1991). The frame problem in situation the cal-

culus: A simple solution (sometimes) and a complete-

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

178

ness result for goal regression. In Lifschitz, V., ed-

itor, Artiﬁcial Intelligence and Mathematical Theory

of Computation, pages 359–380. Academic Press Pro-

fessional, Inc., San Diego, CA, USA.

Schiffel, S. and Thielscher, M. (2005). Interpreting golog

programs in ﬂux. In In 7th International Symposium

On Logical Formalizations of Commonsense Reason-

ing, The, USA. AAAI Press.

Thielscher, M. (1998). Introduction to the Fluent Calculus.

Electron. Trans. Artif. Intell., 2:179–192.

Thielscher, M. (2005). FLUX: A logic programming

method for reasoning agents. TPLP, 5(4-5):533–565.

Winner, H. and Schopper, M. (2015). Adaptive cruise

control. In Handbuch Fahrerassistenzsysteme, pages

851–891. Springer.

Veriﬁcation of Feature Coordination using the Fluent Calculus

179