6. Veriﬁcation of supervisors€¦ · 6. Veriﬁcation of supervisors Large parts of this chapter have been reproduced from [GM14], with permission from the authors. 6.1 Properties

6. Verification of supervisors

Large parts of this chapter have been reproduced from [GM14], with permission from the authors.

6.1 Properties of supervisors

In the previous chapter we have discussed how to obtain supervisors such that the controlled system

they induce satisfy previously stated requirements. If one has sufficient trust in the implementations

of the synthesis algorithm there is no need to doubt that the supervised system has the synthesised

properties. However, there are many properties that are much harder too express in terms of

requirements that can be synthesised or for which this is even impossible.

� Example 6.1 Consider, again, the dining philosophers. A practically acceptable supervisor for

such a system should allow each philosopher to eat once in a while. How can we express this

in terms of requirements? Through the mechanism of marked states we can only express that a

specific system state should be reachable. It does not express that it will be reached and in a setting

with multiple global marked states it is not even guaranteed that each of them is reachable. In

conclusion, the concept of marked states is not capable of expressing the progress requirement that

each philosopher should be allowed to eat.

Can we express this requirement by means of a requirement? We can provide a requirement that

achieves the required progress, but this basically requires that we manually develop a supervisor

that guarantees progress and subsequently call it a requirement. An example is a supervisor that

simply dictates that the philosophers eat alternatingly. �

Another shortcoming with our synthesis approach is that sometimes the modelling of an informal

requirement in terms of automata or state-based expressions is not straightforward. In such cases it

would be wise to check whether or not the requirement model achieves the intended purpose.

For both situations sketched above, it may be useful to establish whether the controlled system really

108 Chapter 6. Verification of supervisors

has the properties that are desired. The technique that is used for this is called model checking.

In model checking, a complex algorithm is performed on a model of the system under consideration,

and a model of the desired property in order to establish whether or not that property holds for

that system. In this chapter we will describe how we can use an existing model checker, mCRL2,

for the purpose of model checking properties of controlled systems. In Figure 6.1 our approach is

sketched.

Figure 6.1: Model checking controlled systems.

A model of the controlled system (or supervisor) as developed in CIF is transformed automatically

into a model that can be processed by the model checker mCRL2. Most of the details of this

transformation are not important for our purposes. The ones that are will be discussed later.

The properties that we wish to verify need to be formulated in a logic that can be understood by

the mCRL2 tool set. This logic is the modal μ-calculus. It is difficult to model properties in the

modal μ-calculus. Therefore, we will not present the full modal μ-calculus but restrict its treatment

to a part that is more easily understood and that can be used to demonstrate the usefulness of the

verification approach.

6.2 Introduction to the mCRL2 toolset

mCRL2 stands for micro Common Representation Language 2. It is a specification language that

can be used to specify and analyse the behaviour of distributed systems and protocols and is the

successor to μCRL. Extensive theory is available for verifying processes manually. A major part of

this theory has been implemented in the accompanying toolset, allowing automatic analysis and

verification of systems.

6.2 Introduction to the mCRL2 toolset 109

Philosophy

The mCRL2 approach builds upon the rich literature of process algebras, which are algebraic

formalisms for compositional specification of concurrent systems. The formalism extends the

algebra of communicating processes (ACP) [BeKl84a] with various features including notions of

data, time, and multi-actions. A multi-action is an action that combines more than one different

actions into one. Multi-actions are not available in CIF. Like in every process algebra, a fundamental

concept in mCRL2 is the process. Processes can perform actions and can be composed to form new

processes using algebraic operators. A system usually consists of several processes (or components)

in parallel.

A process can carry data as its parameters. The state of a process is a specific combination of

parameter values. This state may influence the possible actions that the process can perform. In

turn, the execution of an action may result in a state change. Every process has a corresponding

state space or Labelled Transition System (LTS) which contains all states that the process can reach,

along with the possible transitions between those states.

Using the algebraic operators, very complex processes can be constructed containing, for example,

lots of parallelism. A central notion in mCRL2 is the linear process. This is a process from which

all parallelism has been removed to produce a series of condition - action - effect rules. Complex

systems, consisting of hundreds or even thousands of processes, can be translated to a single

linear process. Even for systems with an infinite state space, the linear process (being an abstract

representation of that state space) is finite and can often be obtained very easily. Therefore, most

tools in the mCRL2 toolset operate on linear processes rather than on state spaces.

Specifications in mCRL2 are built upon atomic (inter)actions, which can be composed using various

algebraic operators. The specified behavior can then be simulated, visualized or verified against its

requirements. Requirements are defined by using a rich logic, namely the modal μ-calculus with

data and time. This logic is very suitable to express patterns of (dis)allowed behavior. An excellent

textbook on modal logics is [BaierKatoen]. In [Bradfield01] a detailed historical account and an

accessible presentation of the modal μ-calculus is presented. In order to mechanically verify the

requirements, an extensive tool set has been developed for mCRL2. It can be downloaded from

www.mcrl2.org.

Model checking is provided using Parameterised Boolean Equation Systems (PBES). Given a

linear process and a formula that expresses some desired behaviour of the process, a PBES can be

generated. The solution to this PBES indicates whether the formula holds on the process or not. An

attempt can be made to remove data from a PBES in order to obtain a BES, which is often easier to

solve.

History

Around 1980 many process algebras were designed to model behaviour. Most notably were CCS

(Calculus of Communicating Processes, [Mil80]), ACP (Algebra of Communicating Processes,

[BeKl84a]) and CSP (Communicating Sequential Processes, [Hoa85]). These process algebras

were mainly used as an object of study, mainly due to their lack of proper data types.

In order to use these languages for actual modelling of behaviour a number of process algebraic

specification languages have been designed, which invariably were extended with equational

datatypes. The most well known is LOTOS (Language of Temporal Ordering Specifications ,


Brinksma), but others are PSF (Process Specification Formalism, Mauw and Veltink) and μCRL

(micro Common Representation Language, Groote and Ponse).

Unfortunately, the use of abstract data types made these languages unpleasant when it came to the

specification of complex behaviour. Therefore, we designed the language mCRL2 (the successor

of μCRL) to contain exactly those data types that one would expect when writing specifications,

namely Bool, Pos, Nat, Int, Real, lists, sets, bags, functions and functional data types. These data

types are machine independent. For instance there is no upperbound on natural numbers, sets are

not necessarily finite, quantification can be used within boolean terms and lambda abstraction is

part of the language. Furthermore, the language features time and multi-actions, which were not

present in most of the process specification languages of the previous generation.

Note that mCRL2 is extremely rich and it is easy to express non-computable behavioural specifica-

tions in it. Typically, for those specifications, tool supported analysis will not be very fruitful. The

advanced use of mCRL2 requires a good understanding of the language, the underlying notions and

even of the implementation of the analysis tools. For more straightforward use this is not needed.

An effective rule of thumb is that everything that could be done using languages such as LOTOS,

PSF and μCRL, can be done without a problem using mCRL2.

Toolset overview

An overview of the mCRL2 toolset is given in the picture below. It shows the main concepts that

play a role (in blue) and the operations that can be performed on these concepts (in red). In the

toolset, a file format is associated with every concept and operations are implemented in tools. In

order to get a feeling for the relevant concepts and tools, we describe the workflow of a typical

analysis using mCRL2 below.

All tools can be accessed via a command-line interface. Another possibility is to use the mcrl2-gui

tool which provides access to the tools via a GUI.

6.2 Introduction to the mCRL2 toolset 111

The rest of this section describes the different categories of tools that are part of mCRL2.

mCRL2 specification and linearisation

Every analysis starts off by specifying the behaviour of the system being studied. This can be any

kind of system, though the main application of mCRL2 is in distributed software systems. The

specification can be seen as a model of the real system: it is a simplified, or abstracted version of

reality. Obtaining a specification that is faithful to the real system is far from trivial and beyond the

scope of this overview.

An mCRL2 specification is a plain-text file containing a model in the mCRL2 language. It can be

created using any text editor. For a description of the mCRL2 language we refer to the Language

reference.

Typically, the specification of a distributed system contains several processes that run in parallel.

The first step in the mCRL2 analysis process is to linearise this specification to obtain a Linear

Process Specification (LPS). This is an mCRL2 specification from which all parallelism has been

removed. All that remains is a series of condition – action – effect rules that specify how the system

as a whole reacts to certain stimuli given its current state. Because of its much simpler form, the

LPS is much more suitable for automated analysis than an mCRL2 specification. Therefore, most

tools in the mCRL2 toolset operate on LPSs.

The main tool for linearisation is mcrl22lps. Given an mCRL2 specification, it produces an

equivalent LPS on which other tools can be run. We investigate these tools below.

LPS tools

An LPS is stored in a binary file format for efficiency. After having obtained an LPS, a very useful

analysis method is by simulating the model. Starting from the initial state, sequences of actions can

be performed which can quickly reveal unexpected or erroneous behaviour. It is also a good way of

getting acquainted with the modelled behaviour.

The mCRL2 toolset contains two tools for simulation of an LPS: lpssim (command-line interface)

and xsim (graphical user interface).

Some statistical information about an LPS can be collected using the lpsinfo tool. The LPS itself

can also be printed in a pretty, human-readable format. The tool for this task is lpspp.

In essence, the LPS is a symbolic (or implicit) representation of the state space or labelled transition

system (LTS) that describes the behaviour of the system explicitly. This LTS can be constructed

from the LPS using a state space generator. In mCRL2 the tool that performs this task is lps2lts.

As state space generation can take a lot of time, it is often beneficial to reduce the LPS or make it

more suitable for state space generation. Several tools are available for this, of which we mention a

few here: lpssumelm, lpssuminst, lpsparelm, lpsconstelm and lpsrewr.

LTS tools

Once an LTS has been generated from an LPS, it can be visualised in several ways using interactive

GUI tools. The most straightforward way of visualising an LTS is by showing it as a node-link


diagram or graph. The ltsgraph tool performs this task. It can reorganise the produced image using

a force-directed algorithm.

The picture produced by ltsgraph can become very cluttered for larger LTSs. Another LTS

visualisation tool is ltsview which employs a clustering technique to reduce the complexity of the

image. It produces a 3D visualisation of the LTS and aims to show symmetry in the behaviour of

the system.

The tool diagraphica also clusters states to reduce complexity, producing a 2D image. It clusters

states based on state parameter values, instead of on structural properties like ltsview.

Apart from these visualisation tools, a powerful tool is ltsconvert which can reduce an LTS modulo

various equivalences. This often produces an LTS that is dramatically smaller than the original

LTS, while important properties are maintained. The tool can also convert between various LTS file

formats, some of which are textual, others binary.

An equally powerful tool is ltscompare which can check whether two LTSs are behaviourally

equivalent or similar using various notions of equivalence/similarity.

The tool lts2lps can transform an LTS into an LPS, such that symbolic computation can be continued,

e.g. after minimisation.

Model checking using PBESs

The aforementioned tools aid in getting more insight into the behaviour specified by an mCRL2

specification. However, a system’s analysis often involves showing that the modelled system

exhibits certain desired properties (or does not exhibit undesired ones). This can be done using

model-checking techniques, which are very powerful verification methods.

In mCRL2, model checking is provided using parameterised boolean equation systems (PBESs).

As mentioned before, the central notion in mCRL2 is the LPS. Not surprisingly, model checking

also starts off with an LPS, which contains a symbolic specification of the system’s behaviour.

The other input needed for model checking, is a formula expressing a desired property that the

system should not violate (or satisfy). Such formulas are expressed in the regular modal μ-calculus

(extended with data) and can be entered into a plain-text file using any text editor. The syntax of

these formulas is described in the Language reference.

Given an LPS and a formula, the tool lps2pbes produces a PBES in which the model checking

question of “does the formula hold for this LPS?” is encoded. The PBES is stored in a binary file

format. By solving the PBES, an answer to this question can be found. The main tool for trying to

solve a PBES is pbes2bool. It attempts to solve a given PBES and (if successful) returns either true

or false.

Note that solving PBESs is generally undecidable, so the attempt may fail. In this case, more

in-depth analysis of the PBES may be required. The tool pbespp is provided to pretty print a PBES

in a human-readable format. Statistical information can be obtained using pbesinfo and the PBES

can be simplified using pbesrewr. Furthermore some tools for simplifying the PBES are available,

such as pbesparelm and pbesconstelm.

6.3 From CIF to mCRL2: an informal treatment 113

Integration with other tools

The mCRL2 toolset also integrates with other tool sets. An interface with the TorX tool is provided

by lps2torx. Furthermore, mCRL2 can be used as a language front-end for the LTSmin toolset.

Furthermore, a number of textual file formats are available, that facilitate easy integration with other

tools. Examples are the Aldebaran format for labelled transition systems, that is, e.g., supported by

μCRL and CADP. The CWI format for Boolean equation systems, and finally, the GM file format,

which is supported by the PGSolver tools.

Finally, some tools may profit from the use of an external SMT solver. For this purpose, mCRL2

can use the CVC3 automatic theorem prover for SMT problems.

6.3 From CIF to mCRL2: an informal treatment

For the purpose of this course we have been modelling (parts of) systems using the automata-based

language CIF. In order to use the mCRL2 tool set these CIF models need to be transformed into

mCRL2 models that express the same behaviour. The CIF tool set has the capabilities to perform

this transformation automatically. This results in a mCRL2 model that has the same behaviour as

the CIF model. The transformation of CIF models into mCRL2 models is not defined formally in

these lecture notes. The transformation is discussed and illustrated by means of examples.

� Example 6.2 — Transformation of a single CIF automaton into mCRL2. Consider the fol-

lowing automaton, which is a model for the lock picking problem from Exercise 2.10.

1 event zero , one , open , alarm;

2

3 automaton lock_picking:

4 location L0:

5 initial

6 edge zero , one goto L1;

7 location L1:


9 location L2:

10 edge zero goto zero_on_three;

11 edge one goto one_on_three;

12 location zero_on_three:

13 edge zero goto open_door;

14 edge one goto alarm_state;

15 location one_on_three:

16 edge zero goto alarm_state;

17 edge one goto open_door;

18 location open_door:

19 edge open goto L0;

20 location alarm_state:

21 edge alarm goto L0;

22 end

The mCRL2 version of this model is the following.

1 sort LocSort_lock_picking = struct loc_lock_picking_L0 |

loc_lock_picking_L1 | loc_lock_picking_L2 |

loc_lock_picking_zero_on_three | loc_lock_picking_one_on_three |

loc_lock_picking_open_door | loc_lock_picking_alarm_state;

2

3 proc BehProc_lock_picking(Locvar_lock_picking : LocSort_lock_picking) =


4 (Locvar_lock_picking == loc_lock_picking_L0) -> zero .

BehProc_lock_picking(loc_lock_picking_L1) +

5 (Locvar_lock_picking == loc_lock_picking_L0) -> one .







BehProc_lock_picking(loc_lock_picking_zero_on_three) +


BehProc_lock_picking(loc_lock_picking_one_on_three) +

10 (Locvar_lock_picking == loc_lock_picking_zero_on_three) -> zero .

BehProc_lock_picking(loc_lock_picking_open_door) +

11 (Locvar_lock_picking == loc_lock_picking_zero_on_three) -> one .

BehProc_lock_picking(loc_lock_picking_alarm_state) +

12 (Locvar_lock_picking == loc_lock_picking_one_on_three) -> zero .

BehProc_lock_picking(loc_lock_picking_alarm_state) +

13 (Locvar_lock_picking == loc_lock_picking_one_on_three) -> one .

BehProc_lock_picking(loc_lock_picking_open_door) +

14 (Locvar_lock_picking == loc_lock_picking_open_door) -> open .


15 (Locvar_lock_picking == loc_lock_picking_alarm_state) -> alarm .

BehProc_lock_picking(loc_lock_picking_L0);

16

17 act zero , renamed_zero , one , renamed_one , open , renamed_open , alarm ,

renamed_alarm;

18

19 init BehProc_lock_picking(loc_lock_picking_L0);

In the first line a new data type is introduced. This datatype is used to represent the locations of the

automaton.

In lines 3-15 the edges of the CIF automaton are represented one by one. Depending on the value

of a parameter (Lockvar_lock_picking in this case) representing the current location of the CIF

automaton, the enabled events are provided and the value of the parameter is changed to reflect the

ove to the target location.

In line 17 actions representing the events of the CIF automaton are declared. mCRL2 does not

discriminate between controllable and uncontrollable events.

Finally, in line 19, the process representing the CIF automaton is declared. Note that the parameter

is initialized with the initial location.

Using the mCRL2 tool set it is possible to obtain the state space of this mCRL2 model as well.


0

1

2

3

4

5

6

zeroone

zeroone

zero

one

zero

one

zero

one

open

alarm

The initial location is depicted in green. As can be seen from the state space this is the same

behaviour as described by the CIF model. Also observe that the produced mCRL2 model does not

show the original location names from the CIF model. �

Practically, to be able to transform a CIF model to an mCRL2 model and to a state space the

following steps must be taken:

1. In the CIF tool set: Apply Convert CIF to mCRL2 ... on the file with the CIF model.

This results in a file with extension mcrl2.

2. In the mCRL2 tool set:

(a) Apply mcrl22lps (in menu Transformation) on the mcrl2 file. The result is a file

with extension lps (for Linear Process Specification).

(b) Apply lps2lts on the lps file to obtain a file with extension lts (for Labelled

Transition System).

(c) Apply ltsgraph (from Analysis menu) to obtain a visualization of the state space.

In the above example we have seen that te location names of the CIF plant are not available in the

mCRL2 model. If it is desirable to have these one can apply a trick. If one adds a self loop in every

location of the CIF model with an event that reflects the name of the location, then it will become

visible in the mCRL2 model as well in terms of a loop.

� Example 6.3 Extending the CIF model from the previous example as described results in the

following CIF model

1 event zero , one , open , alarm;

2 event loc_L0 , loc_L1 , loc_L2 , loc_zero_on_three , loc_one_on_three ,

loc_open_door , loc_alarm_state;

3

4 automaton lock_picking:

5 location L0:

6 initial;

7 edge loc_L0;


9 location L1:

10 edge loc_L1;


12 location L2:

13 edge loc_L2;

14 edge zero goto zero_on_three;


15 edge one goto one_on_three;

16 location zero_on_three:

17 edge loc_zero_on_three;

18 edge zero goto open_door;

19 edge one goto alarm_state;

20 location one_on_three:

21 edge loc_one_on_three;

22 edge zero goto alarm_state;

23 edge one goto open_door;

24 location open_door:

25 edge loc_open_door;

26 edge open goto L0;

27 location alarm_state:

28 edge loc_alarm_state;

29 edge alarm goto L0;

30 end

In line 2 the additional events are declared. In lines 7, 10, 13, 21, 25 and 28 the loops are added

Transformation to mCRL2 and subsequent computation of the state space results in:

01

2

34

5

6

loc_L0

zerooneloc_L1

zeroone

loc_L2

zeroone

loc_zero_on_three

zeroone

loc_one_on_three

zeroone

open

loc_open_door

alarm

loc_alarm_state

The only difference with the previous state space are the loops announcing the location names. �

Another difference is that in mCRL2 there is no notion of marked state. If we consider the marked

state important we would have to add it ourselves in the mCRL2 model. One way of achieving

this is to label every marked state in the CIF models by a new globally declared event. Then the

resulting mCRL2 state space will have a loop with the introduced label for each marked state.

Exercise 6.1 Consider the reconfigurable machine tool from Exercise 4.55. Adapt the CIF

models in such a way that (1) the location names from the original CIF automata become

available in the mCRL2 model, and (2) the marked state is represented in the right way in the

mCRL2 model. Use the tools to obtain the state space and validate that you did this correctly. �

� Example 6.4 — Network of automata (without variables). Transformation of the network of

automata for the modelling of the dining philosophers results in the following mCRL2 model.


1 sort LocSort_philosopher1 = struct loc_philosopher1_Thinking |

loc_philosopher1_F1 | loc_philosopher1_F2 | loc_philosopher1_Eating;

2

3 proc BehProc_philosopher1(Locvar_philosopher1 : LocSort_philosopher1) =

4 (Locvar_philosopher1 == loc_philosopher1_Thinking) -> P1_f1 .

BehProc_philosopher1(loc_philosopher1_F1) +



6 (Locvar_philosopher1 == loc_philosopher1_F1) -> P1_f2 .

BehProc_philosopher1(loc_philosopher1_Eating) +



8 (Locvar_philosopher1 == loc_philosopher1_Eating) -> P1_f .

BehProc_philosopher1(loc_philosopher1_Thinking);

9

10 sort LocSort_philosopher2 = struct loc_philosopher2_Thinking |

loc_philosopher2_F1 | loc_philosopher2_F2 | loc_philosopher2_Eating;

11

12 proc BehProc_philosopher2(Locvar_philosopher2 : LocSort_philosopher2) =









17 (Locvar_philosopher2 == loc_philosopher2_Eating) -> P2_f .

BehProc_philosopher2(loc_philosopher2_Thinking);

18

19 sort LocSort_fork1 = struct loc_fork1_OnTable | loc_fork1_F1 | loc_fork1_F2

;

20

21 proc BehProc_fork1(Locvar_fork1 : LocSort_fork1) =

22 (Locvar_fork1 == loc_fork1_OnTable) -> P1_f1 . BehProc_fork1(loc_fork1_F1

) +


) +

24 (Locvar_fork1 == loc_fork1_F1) -> P1_f . BehProc_fork1(loc_fork1_OnTable)

+


;

26

27 sort LocSort_fork2 = struct loc_fork2_OnTable | loc_fork2_F1 | loc_fork2_F2

;

28

29 proc BehProc_fork2(Locvar_fork2 : LocSort_fork2) =


) +


) +


+


;

34

35 act P1_f1 , renamed_P1_f1 , P1_f2 , renamed_P1_f2 , P1_f , renamed_P1_f , P2_f1 ,

renamed_P2_f1 , P2_f2 , renamed_P2_f2 , P2_f , renamed_P2_f;

36

37 init allow({P1_f1 ,

38 P1_f2 ,


39 P1_f ,

40 P2_f1 ,

41 P2_f2 ,

42 P2_f},

43 rename ({ renamed_P1_f2 -> P1_f2 ,

44 renamed_P1_f -> P1_f ,

45 renamed_P2_f2 -> P2_f2 ,

46 renamed_P2_f -> P2_f},

47 block({P1_f2 , P1_f , P2_f2 , P2_f},

48 comm({P1_f2 | P1_f2 -> renamed_P1_f2 ,

49 P1_f | P1_f -> renamed_P1_f ,

50 P2_f2 | P2_f2 -> renamed_P2_f2 ,

51 P2_f | P2_f -> renamed_P2_f},

52 (

53 allow({P1_f1 ,

54 P1_f2 ,

55 P1_f ,

56 P2_f1 ,

57 P2_f2 ,

58 P2_f},

59 rename ({ renamed_P1_f1 -> P1_f1 ,

60 renamed_P1_f -> P1_f ,

61 renamed_P2_f1 -> P2_f1 ,

62 renamed_P2_f -> P2_f},

63 block({P1_f1 , P1_f , P2_f1 , P2_f},

64 comm({P1_f1 | P1_f1 -> renamed_P1_f1 ,

65 P1_f | P1_f -> renamed_P1_f ,

66 P2_f1 | P2_f1 -> renamed_P2_f1 ,

67 P2_f | P2_f -> renamed_P2_f},

68 (

69 allow({P1_f1 ,

70 P1_f2 ,

71 P1_f ,

72 P2_f1 ,

73 P2_f2 ,

74 P2_f},

75 (

76 BehProc_philosopher1(loc_philosopher1_Thinking)

77 ||

78 BehProc_philosopher2(loc_philosopher2_Thinking)

79 ))

80 ||

81 BehProc_fork1(loc_fork1_OnTable)

82 )))))

83 ||

84 BehProc_fork2(loc_fork2_OnTable)

85 )))));

A process definition is introduced for each of the automata in isolation, much as explained before.

Important to notice is that in principle each of the automata is transformed as shown previously,

and that it takes some effort to synchronize these automata in a way compatible with CIF. This can

be seen by the many occurrences of the allow, rename, block and communication operators. It goes

beyond the scope of these lecture notes to explain this in detail.

The resulting state space is as follows:


0 12

3

4

5

6

7

8

P1f1P2f1

P1f2

P2f2

P1f2

P2f2

P1f2

P2f2

P1f1P2f1

P1f1P2f1

P1f

P2f

�

Exercise 6.2 Change the CIF models in such a way that the location names become available

via self loops in the mCRL2 model. Check if you did this correctly by producing the state space

in mCRL2. �

There are some important differences between CIF and mCRL2 that need to be explained into some

detail since they influence the way we have to state the properties that we want to verify. The most

prominent differences are that mCRL2 does not have variables and that mCRL2 does not allow

inspection of the system/component states. This means that the mechanisms of variables from CIF

has ben replaced by using events in mCRL2.

� Example 6.5 — Automaton with a variable. Consider the CIF model of the counter, as an

example of an automaton with a variable.

count = 3

count < 5

incrementcount := count +1

count > 0

decrementcount := count−1

In mCRL2 this automaton is represented as follows:

1 sort LocSort_counter = struct loc_counter_L;

2

3 act value_count : Int;

4

5 proc BehProc_counter(Locvar_counter : LocSort_counter , count : Int) =

6 value_count(count) . BehProc_counter(Locvar_counter , count) +

7 (( Locvar_counter == loc_counter_L) && (count < 5)) -> increment .

BehProc_counter(Locvar_counter , (count + 1)) +

8 (( Locvar_counter == loc_counter_L) && (count > 0)) -> decrement .

BehProc_counter(Locvar_counter , (count - 1));

9

10 act increment , renamed_increment , decrement , renamed_decrement;

11

12 init BehProc_counter(loc_counter_L , 3);


The variable count as used in the CIF model is represented by parameter count in the process

definition of the mCRL2 process. Guard and updates from CIF edges are easily captured using this

parameter.

The state space obtained is the following:

0 12 345

decrement

increment

value_count(3)

decrement

increment

value_count(2)

decrement

increment

value_count(4)

decrement

increment

value_count(1)

decrementvalue_count(5) incrementvalue_count(0)

�

One can see that instead of having variables, variables and their changes in values have been

captured in events. To reflect that a variable has a specific value in a state the state has a self-loop

that announces this value. In line 6 of the mCRL2 model these loops are introduced.

The treatment of networks of automata with multiple variables is not discussed in detail here.

Variables that are local to a single automaton (and not read by any other automaton) are captured as

illustrated and variables that are used outside their defining automaton are represented by separate

processes in the transformation to mCRL2.

� Example 6.6 Consider the CIF model for the supermarket. It consists of three automata and the

count variables of the automata representing the queues are used by a customer process that decides

which queue the next customer joins. The resulting mCRL2 model is the following.

1 sort LocSort_queue1 = struct loc_queue1_l0 | loc_queue1_l1;

2

3 proc BehProc_queue1(Locvar_queue1 : LocSort_queue1) =

4 sum count : Int . (( Locvar_queue1 == loc_queue1_l0) && (count < 2)) ->

q1enter | aread_count(count) | awrite_count ((count + 1)) .

BehProc_queue1(loc_queue1_l1) +

5 sum count : Int . (( Locvar_queue1 == loc_queue1_l0) && (count > 0)) ->

q1leave | aread_count(count) | awrite_count ((count - 1)) .

BehProc_queue1(Locvar_queue1);

6

7 sort LocSort_queue2 = struct loc_queue2_l0;

8

9 proc BehProc_queue2(Locvar_queue2 : LocSort_queue2) =

10 sum count2 : Int . (( Locvar_queue2 == loc_queue2_l0) && (count2 < 2)) ->

q2enter | aread_count2(count2) | awrite_count2 (( count2 + 1)) .

BehProc_queue2(Locvar_queue2) +

11 sum count2 : Int . (( Locvar_queue2 == loc_queue2_l0) && (count2 > 0)) ->

q2leave | aread_count2(count2) | awrite_count2 (( count2 - 1)) .

BehProc_queue2(Locvar_queue2);

12

13 sort LocSort_customer = struct loc_customer_l0;

14

15 proc BehProc_customer(Locvar_customer : LocSort_customer) =

16 sum count : Int . sum count2 : Int . (( Locvar_customer == loc_customer_l0

) && (count <= count2)) -> q1enter | aread_count(count) |


aread_count2(count2) . BehProc_customer(Locvar_customer) +

17 sum count2 : Int . sum count : Int . (( Locvar_customer == loc_customer_l0

) && (count2 <= count)) -> q2enter | aread_count2(count2) |

aread_count(count) . BehProc_customer(Locvar_customer);

18

19 act value_count , vread_count , vwrite_count , aread_count , awrite_count : Int

;

20

21 proc VarProc_count(v:Int) =

22 value_count(v) . VarProc_count(v) +

23 vread_count(v) . VarProc_count(v) +

24 sum m:Int . true -> vwrite_count(m) . VarProc_count(m) +

25 sum m:Int . true -> vread_count(v) | vwrite_count(m) . VarProc_count(m);

26

27 act value_count2 , vread_count2 , vwrite_count2 , aread_count2 , awrite_count2

: Int;

28

29 proc VarProc_count2(v:Int) =

30 value_count2(v) . VarProc_count2(v) +

31 vread_count2(v) . VarProc_count2(v) +

32 sum m:Int . true -> vwrite_count2(m) . VarProc_count2(m) +

33 sum m:Int . true -> vread_count2(v) | vwrite_count2(m) . VarProc_count2(m

);

34

35 act q1enter , renamed_q1enter , q1leave , renamed_q1leave , q2enter ,

renamed_q2enter , q2leave , renamed_q2leave;

36

37 init allow({ value_count ,

38 value_count2 ,

39 q1enter | awrite_count | aread_count | vwrite_count2 |

aread_count2 ,

40 q1leave | awrite_count | aread_count | vwrite_count2 |

vread_count2 ,

41 q2enter | awrite_count2 | aread_count2 | vwrite_count |

aread_count ,

42 q2leave | awrite_count2 | aread_count2 | vwrite_count |

vread_count},

43 comm({ aread_count2 | vread_count2 -> aread_count2 ,

44 awrite_count2 | vwrite_count2 -> awrite_count2},

45 (

46 allow({ value_count ,

47 q1enter | awrite_count | aread_count | aread_count2 ,

48 q1leave | awrite_count | aread_count ,

49 q2enter | awrite_count2 | aread_count2 | vwrite_count |

aread_count ,

50 q2leave | awrite_count2 | aread_count2 | vwrite_count |

vread_count},

51 comm({ aread_count | vread_count -> aread_count ,

52 awrite_count | vwrite_count -> awrite_count},

53 (

54 allow({ q1enter | awrite_count | aread_count | aread_count2 ,


56 q2enter | awrite_count2 | aread_count2 | aread_count ,

57 q2leave | awrite_count2 | aread_count2},

58 comm({ aread_count | aread_count -> aread_count ,

59 aread_count2 | aread_count2 -> aread_count2},

60 rename ({ renamed_q1enter -> q1enter ,

61 renamed_q2enter -> q2enter},

62 block({q1enter , q2enter},

63 comm({ q1enter | q1enter -> renamed_q1enter ,

64 q2enter | q2enter -> renamed_q2enter},


65 (

66 allow({ q1enter | awrite_count | aread_count ,


68 q2enter | awrite_count2 | aread_count2 ,

69 q2leave | awrite_count2 | aread_count2},

70 (

71 BehProc_queue1(loc_queue1_l0)

72 ||

73 BehProc_queue2(loc_queue2_l0)

74 ))

75 ||

76 BehProc_customer(loc_customer_l0)

77 ))))))

78 ||

79 VarProc_count (0)

80 )))

81 ||

82 VarProc_count2 (0)

83 )));

Note that there are five mCRL2 process definitions used. Three for the automata and two for the

variables. �

R With the current implementation of the transformation of CIF models to mCRL2 models thereare some limitations. For example, currently there is no support for using the implicit locationvariables. This means that the user of the tools, i.e., you, must first manually introduce thesevariables explicitly, before transforming to mCRL2. This is very inconvenient and hopefullywe will be able to extend the tools in the future to make this manual step unnecessary.

Exercise 6.3 Translate the models that you have developed previously for the following systems

to mCRL2 and generate the state space.

1. Dining philosophers

2. Wolf, goat, cabbage problem

3. Tic tac toe

�

6.4 Specification of behavioral properties

In this section we discuss how to denote properties of a reactive system. A property describes some

aspect of the behavior of a system. For instance, deadlock freedom is a simple, but a generally very

desired property. Also, the property that every message that is sent will ultimately be received, is a

typical behavioral property.

There are three main reasons to formulate properties of systems:

• Systems are often so complex that their behavior cannot neatly be characterized by a descrip-

tion of its external behavior. Only certain properties can be formulated. For instance, in a

leader election protocol processes can negotiate to select one, and only one, leader. In the

more advanced versions of this protocol it is almost impossible to predict which process will

become the leader [DKR82]. Hence, describing the external behavior of the protocol is hard.

6.4 Specification of behavioral properties 123

But in this case it is relatively easy to denote the property that exactly one leader will be

chosen.

• In the early design stages, it is unclear what the behavior of a system will be. Hence, writing

down basic properties can help to establish some of the essential aspects of the system

behavior before commencing a detailed behavioral design. In UML, use cases are used for

this purpose. These are examples of potential runs of the system. The property language

described in this chapter allows use cases to be denoted, but also allows far more complex

properties to be denoted.

• It is very common that behavioral descriptions contain mistakes. By checking that a behav-

ioral specification satisfies desirable properties, an extra safeguard is built in to guarantee the

correctness of the specification.

Although properties address only aspects of the behavior, it turns out that it is not easy to formulate

them precisely. The reason for this is that most people are used to think rather sloppily about

behavior. They are often only thinking about normal behavior, and not taking all possibilities into

account: It is too simplistic that a light can only go off by turning the switch. Power failure, a

blown fuse, a cut wire, or a broken lightbulb are also potential causes. Computer systems allow

even more complexity.

6.4.1 Hennessy-Milner logic

Hennessy-Milner logic is the underlying modal logic for our property language [HeMi85]. Its

syntax is given by the following BNF grammar:

φ ::= true | false | ¬φ | φ ∧φ | φ ∨φ | φ → φ | 〈a〉φ | [a]φ .

A modal formula is either valid or invalid in a state. A modal formula is considered to be valid for

a transition system iff it is valid in its initial state.

The modal formula true is valid in each state of a process and the modal formula false is never

valid. The connectives ∧ (and), ∨ (or), ¬ (not), and→ (implication) have their usual meaning. For

example, the formula φ1∧φ2 is valid wherever both φ1 and φ2 hold.

The diamond modality 〈a〉φ is valid whenever an a-action can be performed such that φ is valid

after this a has been done. For example, the formula 〈a〉〈b〉〈c〉true expresses that a process can do

an a followed by a b followed by a c.

Using the connectives, more complex properties can be formulated. Expressing that after doing an

a action both a b and a c must be possible is done by the formula 〈a〉(〈b〉true∧〈c〉true). Expressing

that after an a action, no b is possible can be done by 〈a〉¬〈b〉true.

The box modality [a]φ is more involved. It is valid when for every action a that can be done, φholds after doing that a. The formula [a]〈b〉true says that whenever an a can be done, a b action

is possible afterwards. The formula [a]false says that whenever an action a is done, a situation

is reached where false is valid. As this cannot be, the formula expresses that an action a is not

possible. Likewise, [a][b]false holds when a trace ab does not exist.

Clearly, [a]φ and 〈a〉φ express different properties. A good way to understand the differences is by

giving two transition systems, one where 〈a〉φ holds and [a]φ is invalid, and vice versa, one where

[a]φ is valid, and 〈a〉φ is invalid. In the leftmost transition system of figure 6.2, for φ = 〈b〉true,

the formula 〈a〉φ is valid, and [a]φ is not. In the second transition system the situation is reversed,


aa

b

a

b

a

Figure 6.2: Four labeled transition systems distinguishing box and diamond formulas

namely [a]φ is valid, and 〈a〉φ is not. Both formulas are true in the third transition system and both

are invalid in the fourth (i.e., the rightmost) one.

In the labeled transition system at the left of Figure 6.2, an a action is possible to a state where φholds, and one to a state where φ does not hold. Therefore, 〈a〉φ is valid, and [a]φ is not. In the

second labeled transition diagram there is no a-transition at all, so certainly not one to a state where

φ is valid. Hence, 〈a〉φ is not valid. But all a-transitions (which are none) go to a state where φ is

valid. So, [a]φ holds. In the third, all a-transitions go to a state where φ is valid, and in the fourth,

all a-transitions go to a state where φ does not hold.

How can one establish whether a modal formula is valid in the initial state of a labeled transition

system? For Hennessy-Milner formulas, the procedure is straightforward. Consider a formula φand a labeled transition system. Label each state with all subformulas of φ that hold in that state.

This should be done by working from the smaller to the larger subformulas.

As a first step, each state is labeled with true, and none with false. Subsequently, the following

steps are repeatedly executed, until all subformulas are considered. Each state is labeled with a

formula ¬φ , if it is not labeled with φ . A state is labeled with φ∧ψ if it is labeled with φ and ψ .

Similarly, a state is labeled with φ∨ψ if it is labeled with φ or ψ . A state is labeled with 〈a〉φ if

there is an outgoing a transition to a state where φ holds. Similarly, a state is labeled with [a]φ if

all outgoing a transitions go to states where φ holds. Note that as the number of subformulas is

linear in the size of the formula, the complexity of this procedure is linear in the product of the size

of the transition system and that of the formula.

Note that the procedure terminates, as there are only a finite number of possible labelings. At some

point, the labeling cannot be extended anymore. At termination, the initial state is labeled with φiff φ is valid in the initial state.

true,〈a〉〈b〉true

true true,〈b〉true

true

aa

b

true

true, [a]〈b〉true true,〈b〉true, [a]〈b〉true

true, [a]〈b〉true

aa

b

Figure 6.3: Labeling an LTS with subformulas


Consider the transition systems in figure 6.3. At the left the formula 〈a〉〈b〉true is verified, and at

the right the formula [a]〈b〉true. It is clear that in the initial states, the first formula holds, and the

second does not.

R In applying the sketched approach towards establishing truth of a given requirement formulaon a given labeled transition system, as mentioned, any state needs to be labelled by true if itis a sub-formula of the property of interest). This clutters the graphical representation toomuch without really adding any information to it. Therefore, we omit it in the future.

Exercise 6.4 Establish validity of the formula [a][b]false for the following transition system

aa

b

�

Exercise 6.5 For each of the formulas given below, give the set of states of this transition

system in which it is satisfied.

a

a

ab

a a

a

1. 〈a〉true2. 〈b〉true3. [a]false4. [b]false5. [a]〈b〉true6. 〈a〉〈b〉true7. [a]〈a〉[a][b]false8. 〈a〉(〈a〉true∧〈b〉true)9. [a](〈a〉true∨〈b〉true)

10. 〈a〉([b][a]false∧〈b〉true)11. 〈a〉([a](〈a〉true∧ [b]false)∧〈b〉false)

�


The following identities are valid for Hennessy-Milner formulas. These identities are not only

useful to simplify formulas, but can also help to reformulate a modal formula to check whether its

meaning matches intuition. For instance, the formula ¬〈a〉[b]false can be hard to comprehend. Yet

the equivalent [a]〈b〉true clearly says that whenever an action a can be done, an action b must be

possible after that a. Note that the equations show that the box and diamond modalities are dual to

each other, just like the ∧ and the ∨ are duals of each other.

¬〈a〉φ = [a]¬φ ¬[a]φ = 〈a〉¬φ〈a〉false = false [a]true = true〈a〉(φ ∨ψ) = 〈a〉φ ∨〈a〉ψ [a](φ ∧ψ) = [a]φ ∧ [a]ψ〈a〉φ ∧ [a]ψ ⇒ 〈a〉(φ ∧ψ)

Besides these identities, the ordinary identities of propositional logic are also valid.

Exercise 6.6

1. Give a modal formula that says that in the current state an a can be done, followed by a b.

Moreover, after the a no c is allowed.

2. Give a modal formula that expresses that whenever an a action is possible in the current

state, it cannot be followed by an action b or an action c.

3. Give a modal formula that expresses that whenever in the current state an a action can be

done when a b is also possible, the a cannot be followed by a b. In other words, the action

a cancels a b.

�

Exercise 6.7 Is the requirement formula 〈a〉true∨ [a]〈c〉true valid for the following transition

systems?

aa

b c

a

b

c

Provide a single requirement formula that is valid for exactly one of the following two transition

systems. �

Exercise 6.8 Consider the following transition systems:


a

b

u

aa

b u

aa

bu

u

Determine if the requirement formula 〈a〉[b]false holds for the given transition systems. Explain

your answer.

Also, for each pair of transition systems, provide a Hennessy-Milner logic formula that holds

for one of the transition systems, but not for the other. �

Exercise 6.9 Determine if the requirement formula [a]〈b〉true holds for the following transition

systems.

a

a,b

b

ab

b

a

b

c

a

b

c

a

c

What about the formula 〈a〉[b]false? �

Exercise 6.10 Give some different transition systems for which the requirement formula

[a]〈b〉true∨ [a]〈c〉true holds. �

Exercise 6.11 Give an argument why the formulas 〈a〉(〈b〉true∨〈c1〉false) and¬[a] ([b]false∧[c2]true)are equivalent.

�

Exercise 6.12 Consider formulas φ1 = 〈a〉〈b〉true and φ2 = [a](〈b〉true∧ [c]false). Give transi-

tion systems where φ1 is valid and φ2 is invalid and vice versa. �

Exercise 6.13 A scientist interacts with the world in the following ways, and only in the

following ways:

• coffee for taking coffee

• tea for taking tea


• pub for producing a publication

• biscuit for taking a biscuit

Which of the following properties can you express in Hennessy-Milner logic?

1. the scientist is not willing to drink coffee now;

2. the scientist is willing to drink coffee and tea now;

3. the scientist is willing to drink coffee but not tea now;

4. the scientist never drinks alcoholic beverages;

5. always produces a paper after drinking coffee;

6. the scientist can always drink tea immediately after having two coffees in a row

7. the scientist must have a biscuit after drinking coffee

�

Exercise 6.14 Give one labelled transition system that satisfies the following properties:

• 〈a〉(〈b〉〈c〉true∧〈c〉true)• 〈a〉〈b〉([a]false∧ [b]false∧ [c]false)• [a]〈b〉([c]false∧〈a〉true)

�

It is (of course) our purpose to establish properties of CIF models.

As a simple example, consider the case of the lock picking system. Assume that for some

undisclosed reason we have decided to use the mCRL2 model in which also the CIF locations are

made available by means of the self loops. Now, we are interested in the property that it is possible

to reach the alarm state with four one’s. The Hennessy-Milner formula that expresses this is the

following:

〈one〉〈one〉〈one〉〈one〉〈loc_alarm_state〉true

Note how the introduction of the event for being in the alarm state helped us in formulating the

desired property.

Exercise 6.15 Provide some more Hennessy-Milner formulas that can be used to test whether

the provided model for the lock picking case is satisfactory. Give both positive and negative

tests. �


6.4.2 Regular formulas

It is often useful to allow more than just a single action in a modality. For instance, to express that

after two arbitrary actions, a specific action must happen. Or to say that after observing one or

more receive actions, a deliver must follow.

A very convenient way to do this, as put forward by [MatMih00], is the use of regular formulaswithin modalities. Regular formulas are based on action formulas, which we define first:

Action formulas have the following syntax:

af ::= α | true | false | af | af ∩af | af ∪af .

Action formulas define a set of actions. An action α represents the set with exactly the action α .

The formula true stands for the set of all actions and the formula false is the empty set. Note that

this notation is rather confusing, as in this place true and false are not Booleans. This set of actions

can be used instead of an action in a Hennessy-Milner formula. For example, the modal formula

〈true〉〈a〉true expresses that an arbitrary action followed by an action a can be performed. The

formula [true]false expresses that no action can be done.

The connectives ∩ and ∪ in action formulas denote intersection and union of sets of actions. The

notation af denotes the complement of the set af with respect to the set of all actions. The formula

〈a〉〈b∪ c〉true says that an action other than an a can be done, followed by either a b or a c. The

formula [a]false says that only an a action is allowed.

The precise definitions of modalities with action formulas in them is the following. Let af be a set

of actions then:

〈af 〉φ =∨

α∈af

〈α〉φ [af ]φ =∧

α∈af

[α]φ .

Exercise 6.16 Let E denote the set of events. Give a simple explanation of what the following

formulas express:

1. [E]false2. 〈E〉true3. 〈a〉true∧ [a]false4. [E]φ ∧〈E〉true5. 〈E〉true∧ [E](〈E〉true∧ [E](〈E〉true∧ [a]false))

For each formula give a labelled transition system that satisfies the formula. �

Regular formulas extend the action formulas to allow the use of sequences of actions in modalities.

The syntax of regular formulas, with af an action formula, is:

R ::= ε | af | R·R | R+R | R� | R+.

The formula ε represents the empty sequence of actions. So, [ε]φ = 〈ε〉φ = φ . In other words, it is

always possible to perform no action and by doing so, one stays in the same state.

The regular formula R1·R2 represents the concatenation of the sequences of actions in R1 and R2.

For instance, 〈a·b·c〉true is the same as 〈a〉〈b〉〈c〉true expressing that a sequence of actions a, b,


and c can be performed. The regular formula R1+R2 denotes the union of the sequences in R1

and R2. Therefore, [a·b+ c·d]false expresses that neither the sequence ab nor the sequence cd is

possible.

The definitions of both operators is the following:

〈R1+R2〉φ = 〈R1〉φ ∨〈R2〉φ , [R1+R2]φ = [R1]φ ∧ [R2]φ ,〈R1·R2〉φ = 〈R1〉〈R2〉φ , [R1·R2]φ = [R1][R2]φ .

All the modal formulas described up to now are rather elementary, and not of much use to formulate

requirements of real system behavior. By allowing R� and R+, this improves substantially, because

they allow iterative behavior.

The regular formula R� denotes zero or more repetitions of the sequences in R. Similarly, the

formula R+ stands for one or more repetitions. Thus, 〈a�〉ϕ expresses that a state can be reached in

which ϕ holds, by performing zero or more a’s. And [a+]φ expresses that the formula φ must hold

in any state reachable by doing one or more actions a.

Two formulas, the always and eventually modalities, are commonly used. The always modality is

often denoted as �φ and expresses that φ holds in all reachable states. The eventually modality is

written as ♦φ and expresses that there is a sequence of actions that leads to a state in which φ holds.

Using regular formulas these can be written as follows:

�φ = [true�]φ , ♦φ = 〈true�〉φ .

The always modality is a typical instance of a so-called safety property. Such properties typically

say that something bad will never happen. A typical example is that two processes cannot be in

a critical region at the same time. Entering the critical region is modeled by the action enter and

leaving the critical region is modeled by an action leave. In a modal formula we want to say that it

is impossible to do two consecutive enters without a leave action in between:

[true�·enter·leave�·enter]false.

A similar safety requirement, which occurs quite often, is that between an action a and a consecutive

action b, an action c must happen. This is expressed by saying that if an a happens followed by a bwithout a c in between, falsum has to hold in the state that is reached.

[true�·a·c�·b]false.

A very similar property is the following. Namely, between an action a and a subsequent action b an

action c is not allowed to happen. This can be rephrased by saying that between an action c that

follows an action a an action b must happen. With this, we get a similar formula to the one above:

[true�·a·b�·c]false.

There is one safety property that gives rise to a very particular shaped formula. It says that there is

no deadlock in any reachable state:

[true�]〈true〉true.


The eventuality modality ♦φ is a typical example of a liveness property stating that something

good will happen. For instance, the following formula expresses that after sending a message, it

can eventually be received:

[true�·send]〈true�·receive〉true.

Compare this to the following formula

[true�·send·receive�]〈true�·receive〉true

which states that after a send, a receive is possible as long as it has not happened.

Exercise 6.17 Give a requirement formula for the requirement that

• the events a, b, and c can be executed directly after each other, not necessarily starting

from the initial state.

• for any state in the system it holds that event e is possible and after any event e property pholds

�

Exercise 6.18 Reconsider the properties of Exercise 6.13. Perhaps you can formulate some of

them in an easier way now? Perhaps some that could not be formulated before can be formulated

using the new primitives?

A scientist interacts with the world in the following ways, and only in the following ways:

• coffee for taking coffee

• tea for taking tea

• pub for producing a publication

• biscuit for taking a biscuit

• beer for taking a beer

Which of the following properties can you express in Hennessy-Milner with regular formulas?

1. the scientist is not willing to drink coffee now;

2. the scientist is willing to drink coffee and tea now;

3. the scientist is willing to drink coffee but not tea now;

4. the scientist never drinks alcoholic beverages;

5. always produces a paper after drinking coffee;

6. the scientist can always drink tea immediately after having two coffees in a row

7. the scientist must have a biscuit after drinking coffee

�

Exercise 6.19 Give modal formulas for the following properties:

1. As long as no error happens, a deadlock will not occur.

2. Whenever an a can happen in any reachable state, a b action can subsequently be done

unless a c happens canceling the need to do the b.

3. Whenever an a action happens, it must always be possible to do a b after that, although

doing the b can infinitely be postponed.


�

Exercise 6.20 What is the difference between the following two formulas? Which one is used

more often?

[send]〈true�·receive〉true.[true�·send]〈true�·receive〉true.

�

Exercise 6.21 Give formulas for the following properties:

1. an error does not occur

2. there is an a-path along which eventually b is disabled

3. along every a-path, b is always enabled

4. invariantly, if b is enabled, then c is also enabled

5. invariantly, it is impossible to do two consecutive open actions without an intermediate

close action

6. invariantly, after a receive, no two consecutive sends can happen, unless another receive

occurs before the (second)send

�

Exercise 6.22 Express each of the following properties

1. the system contains a path to a deadlock state

2. along every a-path, if b is disables, then c is enabled

3. invariantly, after taking an a action, a b action can eventually happen, unless an erroroccurs.

�

Exercise 6.23 Give a labelled transition system for which the property [a]〈true ·b〉true holds,

but the property [true� ·a]〈true ·b〉true does not hold. What is the essential difference between

these two properties? �

To establish validity of a regular formula basically the same approach can be used as for Hennessy-

Milner formulas. We only detail the cases for 〈R〉φ and [R]φ since the others can easily be reduced

to the cases for Hennessy-Milner formulas.

• label a state with 〈R〉φ if there is some R-reachable state labelled by φ• label a state with [R]φ if all R-reachable states are labelled by φ

Exercise 6.24 Determine if the requirement formula �(〈d〉true∧ [a]〈u〉true) holds for the

following transition systems.


0 1

2

cd

ba

a,u,d

0

1 2

b

d

a

u,d

u,d

�

There are some limiting differences between CIF and mCRL2. These differences have consequences

for expressing properties. As the properties are eventually verified on the mCRL2 model it is

sometimes necessary to reformulate these for this purpose. Let us consider an example.

Consider the case of the dining philosophers and assume that we have decided that the state labels

are to be made available by means of self-loops. Now, for double checking our earlier findings

we wish to establish that the system (without supervisor) has deadlocks and that the system under

supervision does not have such a deadlock anymore. As we have learnt previously the property of

absence of deadlock may be expressed as [true∗]〈true〉true. Thus if we verify this property on the

plant model it should result in false as we know that the system deadlocks. However, if we perform

the verification using the tools we will obtain the answer that the property does hold! The reason

is that we have introduced at least one self-loop for every state. As an undesired consequence we

have obtained a model of the dining philosophers without deadlock.

From this small example we observe that we have to be very careful when formulating properties.

For example, we have to make sure that we deal with the additional events representing state name

information in the right way. In this case, a better formula for expressing absence of deadlock

would have been the following:

[A∗]〈A〉true

where A denotes the set of all original CIF events, excluding the events representing the state

information. In this case A can for example be represented by the notation p1 f 1+ p1 f 2+ p2 f 1+p2 f 2+ p1 f + p2 f .

R Some of the mathematical notations used in this chapter cannot be directly used for the mCRL2toolset. On http://mcrl2.org/web/user_manual/language_reference/mucalc.htmlyou can find the syntax used for describing the modal μ-calculus formulas in mCRL2.

Exercise 6.25 Give a formulation of the property of absence of deadlock for the dining philoso-

phers case without explicitly mentioning any of the original CIF events. �

Exercise 6.26 Transform the dining philosophers system to mCRL2 (with location information).

Express the property that the two philosophers are eating at the same time. Express the property

that each philosopher may be eating in the future. �


Exercise 6.27 Consider the CIF model of the counter and its translation to mCRL2. Express

the property that the counter is always between 2 and 5. �


6.4.3 Fixed point modalities

Although regular expressions are very expressive and suitable for stating most behavioral properties,

they do not suit every purpose. Examples of properties that cannot be expressed by the regular

modal μ-calculus discussed previously are the following

• all behaviour inevitably reaches a state where a formula φ holds

• there is some behaviour where the formula φ holds everywhere

By adding explicit minimal and maximal fixed point operators to Hennessy-Milner logic, a much

more expressive language is obtained. This language is called the modal μ-calculus. As a sign of

its expressiveness, it is possible to translate regular formulas to the modal μ-calculus. However,

the expressiveness comes at a price. Formulating properties using the modal μ-calculus requires

experience.

The modal μ-calculus in its basic form is given by the following syntax. Note that Hennessy-Milner

logic is included in this language.

φ ::= true | false | ¬φ | φ ∧φ | φ ∨φ | φ → φ | 〈a〉φ | [a]φ | μX .φ | νX .φ | X .

The formula μX .φ is the minimal fixed point and νX .φ stands for the maximal fixed point. Typically,

the variable X is used in fixed points, but other capitals, such as Y and Z are used as well. In this

chapter, we restrict attention to so-called closed formula, i.e., formula in which each occurrence of

a (recursion) variable X is within the scope of a minimal or maximal fixed point operator.

A good way to understand fixed point modalities is by considering X as a set of states. The formula

μX .φ is valid for all those states in the smallest set X that satisfies the equation X=φ , where Xgenerally occurs in φ . Here we abuse notation, by thinking of X and φ as the sets of states where

both are valid. Similarly, νX .φ is valid for the states in the largest set X that satisfies X=φ .

We can illustrate this by looking at two simple fixed point formulas, namely μX .X and νX .X . Thus,

we are interested in respectively the smallest and largest sets of states X that satisfy the equation

X=X . Now, any set satisfies this equation. The smallest set to satisfy it is the empty set. This

means that μX .X is not valid for any state. This is equivalent to saying that μX .X=false. The

largest set to satisfy the equation X=X is the set of all states. Therefore, νX .X is valid everywhere.

In other words, νX .X=true.

As another example consider the formulas μX .〈a〉X and νX .〈a〉X . One may wonder whether these

hold for state s in the following transition system:

s a

The only sets of states to be considered are the empty set X=∅ and the set of all states X={s}.Both satisfy the fixed point equation X = 〈a〉X . Namely, if X=∅, then the equation reduces to

∅=〈a〉∅, which is valid (since 〈a〉X represents the set of all states such that there is an a-transition

that ends in a states from X , and for X = ∅ we have 〈a〉∅ = ∅). If X={s} it is also clear that

this equation holds. Thus, μX .〈a〉X is valid for all states in the empty set. Hence, this formula

is not valid in s. However, νX .〈a〉X is valid for all states in the largest set, being {s} in this case.

Therefore, νX .〈a〉X is valid.

An effective intuition to understand whether or not a fixed point formula holds is by thinking of it

as a graph to be traversed, where the fixed point variables are states and the modalities 〈a〉 and [a]


are seen as transitions. A formula is true when it can be made true by passing a finite number of

times through the minimal fixed point variables, whereas it is allowed to traverse an infinite number

of times through the maximal fixed point variables. In the example with a single a-loop above,

the formulas μX .〈a〉X and νX .〈a〉X can only be made true by passing an infinite number of times

through X . Thus, the minimal fixed point formula does not hold, and the maximal one is valid.

Safety properties express that some undesired behavior will never happen. These properties are

generally formulated using the maximal fixed point operator. Dually, liveness properties say that

something good will happen within a finite number of steps. These are formulated using the

minimal fixed point operator.

In order to be sure that a fixed point μX .φ or νX .φ exists, X must occur positively in φ . This

means that X in φ must be preceded by an even number of negations. For counting negations

φ1→φ2 ought to be read as ¬φ1∨φ2. For instance, μX .¬X and νX .¬([a]¬X∨X) are not allowed.

In the first case, the variable X is preceded by one negation. But there is no set of states that is

equal to its complement. Therefore there is no solution for the fixed point equation X=¬X , and

certainly no minimal solution. Hence, μX .¬X is not properly defined. In the second formula the

first occurrence of X is preceded by two negations, which is fine, but the second is preceded by

only one. The formula νX .¬([a]¬X ∨¬X) is well defined as both occurrences of the variable X are

preceded by an even number of negations.

The minimal and maximal fixed point operators are each other’s duals. This boils down to the

following two equations:

¬νX .φ = μX .¬φ [X :=¬X ],¬μX .φ = νX .¬φ [X :=¬X ].

The notation φ [X :=¬X ] stands for φ where each X is replaced by ¬X . Note that using these

equations, it is always possible to remove the negations from modal formulas, provided they have

solutions (i.e., variables occur in the scope of an even number of negations).

Regular formulas containing a � or a + are straightforwardly translated to fixed point formulas.

The translation is:

〈R�〉φ = μX .(〈R〉X ∨φ), [R�]φ = νX .([R]X ∧φ),〈R+〉φ = 〈R〉〈R�〉φ , [R+]φ = [R][R�]φ .

Note that with the rules given above, every regular formula can be translated to a fixed point modal

formula. From a strictly formal standpoint, regular formulas are unnecessary. However, they turn

out to be very practical to formulate many commonly occurring requirements.

Exercise 6.28 Rewrite each of the following regular formulas into a modal μ-calculus formula

without using regular formulas:

1. [true�]〈true〉true2. [true� · error]false3. 〈a�〉[b]false4. [a�]〈b〉true5. [true∗](〈b〉true→ 〈c〉true)6. [true∗ ·open · close

∗ ·open]false7. [true∗ · receive · receive∪ send

∗ · send · receive∗ · send]false


�

Answer

1. νX .([true]X ∧〈true〉true)2. νX .([true]X ∧ [error]false)3. μX .(〈a〉X ∨ [b]false)4. νX .([a]X ∧〈b〉true)5. νX .([true]X ∧ (〈b〉true→ 〈c〉true))6. νX .([true]X ∧ [open]νY.([close]Y ∧ [open]false))7. νX .([true]X ∧ [receive]νY.([receive∪ send][send](νZ.[receive]Z∧ [send]false)))

�

In the previous section we have seen that ♦φ means that φ can eventually become valid. More

precisely, there is a run starting in the current state on which φ becomes valid. Very often a stronger

property is required, namely that φ will eventually become valid along every path. The formula to

express this is:

μX .([true]X ∨φ).

Intuitively, this property expresses that either φ holds in the current state, or in each of the following

states, X must hold. Since the property has a least fixed point operator, X may only be traversed

finitely many times, which means that along each behaviour, within a finite number of steps, φmust hold.

Strictly speaking, this formula will also become true for paths ending in a deadlock, because in

such a state [true]X becomes valid. In order to avoid this anomaly, the absence of a deadlock must

explicitly be mentioned:

μX .(([true]X ∧〈true〉true)∨φ).

A variation of this is that an a action must inevitably be done, provided there is no deadlock before

the action a.

μX .[a]X .

In order to express that a must be done anyhow, the possibility for a deadlock before an action amust explicitly be excluded. This can be expressed by the following formula:

μX .([a]X ∧〈true〉true).

The last two formulas are not valid for the following transition system. The reason is that the b can

infinitely often be done, and hence, an a action can be avoided.

b

a

The formula μX .([a]X ∨〈a〉true) is valid in the initial state of the previous transition system. This

transition system distinguishes between the last formula and the two before that.


We started this subsection by claiming that we were not capable of formulating the property that

there is some behavior where the formula φ holds everywhere. With the modal μ-calculus we can

express this property:

νX .φ ∧〈true〉X .

This property expresses that in the current state φ must hold, and that there is a successor state in

which X again holds. Since this is a maximal fixed point, this must be traversed infinitely often,

and hence we find that tere is a behavior along which φ holds in every state.

Exercise 6.29 Formulate the property that along every a-path, b must eventually be disabled. �

Answer The formula μX .[a]X ∨ [b]false expresses that [b]false must become valid after a finite

number of a-steps. �

Exercise 6.30 Formulate the following properties:

1. as long as no receive event has happened, send may not occur

2. after every receive eventually a send must happen

�

Answer The first property is captured by νX .[receive]X ∧ [send]false, or without using any

explicit fixed point operator by [receive∗][send]false.

The second property is expressed by [true∗ · receive]νX .([send]X ∧ 〈true〉true) or by [true∗ ·receive][send

∗]〈true〉true. �

Exercise 6.31 Give formulas for the following properties:

1. the system can always execute some event

2. the system is guaranteed to terminate3. all requests (event r) will eventually be granted (event g)

�

Answer The system can always execute some event is the same as stating that the system

does not deadlock. The formula is [true∗]〈true〉true. The system is guaranteed to termi-

nate is expressed by μX .([true]X ∧ 〈true〉true∨ 〈terminate〉true). The last formula is given

by [true∗][r]μX .(([true]X ∧〈true〉true)∨ (〈g〉true∧ [g]false)). �

Until now, we have only addressed fixed point formulas where the fixed point operators are used

in a straightforward way. However, by nesting different fixed point operators, a whole new class

of properties can be stated. In these formulas one can reach a minimal fixed point variable from a

maximal fixed point variable and vice versa. Consider, for instance variables, X and Y in formula

(6.1) below. These properties are often called fairness properties, because these can express that

some action must happen, provided it is unboundedly often enabled, or because some other action

happens only a bounded number of times.


Consider for instance the formula

μX .νY.((〈a〉true∧ [b]X)∨ (¬〈a〉true∧ [b]Y )). (6.1)

It says that from the states on each infinite b-trail, there are only a finite number of states where

a-transitions are possible. This is caused by the minimal fixed point operator before the X . The Xcan only finitely often be traversed, and this exactly occurs in a state where an a action is possible.

The variable Y can be traversed infinitely often, as it is preceded by a maximal fixed point, meaning

that infinite b sequences where no a is possible are allowed.

By exchanging the minimal and maximal fixed point symbol, the meaning of the formula can

become quite different. The formula

νX .μY.((〈a〉true∧ [b]X)∨ (¬〈a〉true∧ [b]Y )) (6.2)

says that on each sequence of states reachable via b actions, only finite substretches of states cannot

have an outgoing a transition. If an infinite sequence of b’s is possible where a is enabled in every

state, as shown below, this formula holds. This shows that this formula is not equal to formula (6.1),

which is invalid if a is always enabled.

b

a

Exercise 6.32 Formulate the property that it is possible to infinitely often do a r event �

Answer νX .(μY (〈r〉X ∨〈r〉Y )) �

Exercise 6.33 Explain the difference between the following two formulas

[true�·a]μX .([b]X∧〈true〉true).[true�·a]μX .(([true]X∧〈true〉true)∨〈b〉true).

�

Answer The first formula says that after an a the event b must be done within a finite number

of steps. The second formula says that an event b only needs to be possible after a within a finite

number of steps. �

Exercise 6.34 Are the following formulas equivalent, and if not, explain why:

[send·receive�]〈true�·receive〉true and [send]μX .([receive]X ∧〈true〉true).

�


Answer The transition system with two locations, a self-loop with event send for the initial

location and a receive-labelled transition from the initial location to the other location is valid

for the first formula, and invalid for the second one. �

In the case where there are fixed point symbols, the procedure for establishing validity of a formula

w.r.t. a given labelled transition system is slightly more complicated. We only sketch an algorithm

for formulas with only one fixed point symbol. For a minimal fixed point μX .φ , we do not label the

diagram with μX .φ , but we use all other subformulas of φ , including X . It is initially assumed that

X does not hold, i.e., no state is initially labeled with X . Then states are labeled by valid formulas,

as is done above. When a state is labeled with φ , it is also labeled with X . When labeling is ready,

the formula μX .φ holds in the initial state iff it is labeled with X .

〈b〉true 〈a〉X ∨〈b〉true

a

a

a

b

〈a〉X 〈a〉X ∨〈b〉true

X ,〈b〉true 〈a〉X ∨〈b〉true

a

a

a

b

X ,〈a〉X 〈a〉X ∨〈b〉true



X ,〈b〉true 〈a〉X ∨〈b〉true

a

a

a

b

Figure 6.4: Labeling an LTS with subformulas for a minimal fixed point formula.

As an example consider figure 6.4 and the formula μX .(〈a〉X∨〈b〉true), which expresses that there

is a finite sequence of a actions after which a b is possible. After two rounds of labeling we arrive

at the situation at the left, where no state is labeled with X . Note that the one but last state gets the

labeling 〈a〉X∨〈b〉true, but this is because it is also labeled with 〈b〉true. As the one but last state is

labeled with 〈a〉X∨〈b〉true, it will also be labeled with X . After a next round of updating the labels,

one obtains the diagram in the middle of figure 6.4. Now, it can be observed that 〈a〉X∨〈b〉trueholds in the third state. So, it is labeled with X , too. After repeating this procedure two more steps,

it can be seen in the diagram at the right that X and therefore μX .(〈a〉X∨〈b〉true) holds in the

initial state.

For a maximal fixed point νX .φ it is assumed that X holds initially in all states, and therefore all

states are initially labeled with X . The same procedure as for the minimal fixed point is followed,

except that X is removed from a state if φ does not hold when the labeling process stabilizes. If Xis removed, it might be that other formulas must be removed also, as they were present due to the

existence of X . If removing of labels stabilizes again, it can be that more X’s must be removed as φis not a label of that state anymore. Hence more formulas must be removed, etc. As there are only a

finite number of X’s, this process also terminates. If the initial state is labeled with X , the formula

νX .φ is valid.


X , [a]X 〈a〉true, [a]X ∧〈a〉true

X , [a]X 〈a〉true, [a]X ∧〈a〉true

X , [a]X

a

a

〈a〉true

〈a〉true

[a]X

a

a

Figure 6.5: Labeling an LTS with subformulas for a maximal fixed point formula.

The formula [a�]〈a〉true or equivalently νX .([a]X∧〈a〉true) says that always one more a can be done

after an arbitrary a-sequence. It is checked in figure 6.5. Note that in the last state, [a]X∧〈a〉true is

not true and therefore X must be removed. Subsequently, X must be removed from the second and

finally also from the initial state. Therefore, the formula νX .([a]X∧〈a〉true) does not hold in the

initial state. The final labeling is shown in the figure at the right.

Exercise 6.35 Consider the following transition system:

1 2

a

b

c

For each of the following formulas determine for which states it holds:

1. μX .(〈c〉true∨〈true〉X)2. νX .(〈c〉true∧ [true]X)3. μX .(〈c〉true∨ [true]X)4. νX .(〈c〉true∧〈true〉X)

�

Answer The first property holds in both states. The other properties only hold in state 2. �

Exercise 6.36 Consider the formulas φ1 = μX .[a]X and φ2 = νX .[a]X . If possible, give transi-

tion systems where φ1 is valid in the initial state and φ2 is not valid and vice versa. �

Answer The formula μX .[a]X is invalid for a transition system with a single state with an

a-loop. The formula νX .[a]X is valid for that transition system. For the other way around,

there is no transition system for which the formula μX .[a]X does not hold. In fact μX .[a]X is

logically equivalent to the formula true. �

This procedure can also be used for nested fixed points. For a maximal fixed point variable, assume

initially that it holds in all states, and for a minimal fixed point variable assume it holds in no state.

Approximate the fixed point variables as sketched above from the inner to the outer variables. A


fixed point variable has a stable solution when all variables in it scope also have a stable solution.

Consider as an example formulas (6.1) and (6.2) and the transition diagram directly below these.

The initial approximation in (6.1) is that X holds in no state (minimal fixed point) and Y holds

everywhere (maximal fixed point), especially in s. Using the algorithm above quickly shows that Ycannot be valid in s, which is stable for Y . As X and Y are valid in the same states, X is not valid in

s, which is also a stable solution. So, formula (6.1) does not hold in s.

In formula (6.2), the initial approximation is that X is valid in s, and Y is nowhere valid. But then it

becomes clear that Y holds in s via the labeling procedure above, which is the stable solution. This

is also the stable solution for X . Formula (6.2) is valid in s.

Exercise 6.37 Establish if the formula μX .([true]X ∨φ) holds, for arbitrary formula φ , in the

transition system with a single location and without any transitions, i.e., the deadlocked state. �

Answer It holds since [true]X holds by absence of an outgoing transition. �

Exercise 6.38 Establish in which states of the following transition system the formula μX .[a]false∨〈true〉X holds.

12 3a

a

a

a

And what about the property νX .[a]false∨〈true〉X? �

Answer The first property holds in the states 1 and 3. The second property holds in all states. �

Exercise 6.39 Give a labeled transition system that distinguishes between the following formu-

las μX .([a]X ∨〈true�·a〉true) and μX .[a]X . �

Answer A transition system with two locations with an a-labelled transition from the initial

location to the other location and a b-labelled loop for the initial state. The formula μX .([a]X ∨〈true�·a〉true) holds, whereas the formula μX .[a]X does not hold. �

Exercise 6.40 Explain what the following formulas express:

μX .νY.([a]Y ∧ [b]X) and νX .μY.([a]Y ∧ [b]X).

Is there a transition system that shows that these formulas are not equivalent? �


Answer The first formula states that any sequence of only a’s and b’s ends in an infinite

sequence of a’s. The second formula expresses that each sequence of a’s and b’s only contains

finite subsequences of a’s.

The transition system with only a single location with an a-loop shows the difference. The first

formula is valid, and the second formula is not. �

6.4.4 Modal formulas with data

Similar to the situation with processes, we also need data, and sometimes time in modal formulas

to describe real world phenomena. Modal formulas are extended with data in three ways, similar to

processes. In the first place, modal variables can have arguments. Secondly, actions can carry data

arguments. Moreover, existential and universal quantification is possible. The extensions lead to

the following extensions of the syntax, where α stands for an action, R represents a regular formula,

φ stands for a modal formula, and af stands for an action formula.

α ::= τ | a(t1, . . . , tn) | α|α.

af ::= t | true | false | α | af | af ∩af | af ∪af | ∀d : D.af | ∃d : D.af .R ::= ε | af | R·R | R+R | R� | R+.φ ::= true | false | t | ¬φ | φ∧φ | φ∨φ | φ→φ | ∀d : D.φ | ∃d : D.φ | 〈R〉φ | [R]φ |

μX(d1 : D1:=t1, . . . ,dn : Dn:=tn).φ | νX(d1 : D1:=t1, . . . ,dn : Dn:=tn).φ |X(t1, . . . , tn).

Any expression t of sort IB is an action formula. If t is true, it represents the set of all actions, and

if false, it represents the empty set. The action formula ∃n : IN.a(n) represents the set of actions

{a(n) | n∈IN}. More generally, the action formula ∃d : D.af represents⋃

d:D af . Dually, ∀d : D.afrepresents

⋂d:D af .

These quantifications are useful to express properties involving certain subclasses of actions. For

example, the formula

[true�·∃n : IN.error(n)]μX .([shutdown]X ∧〈true〉true)

says that whenever an error with some number n is observed, a shutdown is inevitable.

There can be a side condition on the error, for instance, using a predicate fatal. A shutdown should

only occur if the error is fatal:

[true�·∃n : IN.(fatal(n)∩ error(n))]μX .([shutdown]X ∧〈true〉true).

If fatal(n) holds, fatal(n) is true and represents the set of all actions. The expression fatal(n)∩error(n) represents the set with exactly the action error(n), provided fatal(n) is valid. Thus,

∃n : IN.(fatal(n)∩ error(n)) is exactly the set of all those error(n) actions which are fatal. Note

that fatal, being a predicate, and error, being an action, are very different objects.

Conversely, one may be interested in stating that as long as no fatal error occurs, there will be no

deadlock.

[(∀n : IN.(fatal(n)∩ error(n)))�]〈true〉true.

In such cases the universal quantifier can be used in action formulas.


In modal formulas, it is also allowed to use universal and existential quantifications over data with

the standard meaning. Thus, ∀d : D.φ is true if φ holds for all values from the domain D substituted

for d in φ . For the existential quantifier, φ only needs to hold for some value in D substituted for d.

Quantification allows for the use of data that stretches throughout a formula. For instance, stating

that the same value is never delivered twice can be done as follows:

∀n : IN.[true�·deliver(n)·true�·deliver(n)]false.

Note that this is not possible using the quantifiers of action formulas, as their scope is only limited

to a single action formula.

Using the existential quantifier we can express that some action takes place, about which we do

not have all information. For instance, after sending a message, the message can eventually be

delivered with some error code n. The error code is irrelevant for this requirement, but as it is a

parameter of the action deliver, it must be included in the formula.

∀m : Message.[true�·send(m)]〈true�·∃n : IN.deliver(m,n)〉true.

Note that it does not really matter where the quantifiers are put. That is,

∀d : D.[true�·a(d)]false = [true�]∀d : D.[a(d)]false = [true�·∃d : D.a(d)]false

but it is good practice to put quantifiers as close as possible around the place where they are used.

A very powerful feature is the ability of allowing data in fixed point variables as parameters. Using

this feature, it is possible, for instance, to count the number of events. Saying that a buffer may

never deliver more messages than it received can be done as follows:

νX(n : IN:=0).[deliver∪receive]X(n)∧[receive]X(n+1)∧ [deliver](n>0∧X(n−1)).

Here n counts the number of received messages that have not been delivered. The notation n : IN:=0

says that n is a natural number that is initially set to 0. The core of the formula is in its last conjunct,

which is false if a deliver is possible while n=0. This conjunct then becomes false, turning the

whole modal formula into false.

Note that the fixed point variables that depend on data, are effectively variables ranging over func-

tions from data elements to sets of states. Although this turns modal formulas into rather advanced

mathematical objects, the use of data in variables is generally quite intuitive and straightforward.

Another example consists of a merger process. It reads two streams of natural numbers, and delivers

a merged stream. Reading goes via actions r1 and r2 and data is delivered via stream s. The property

that the merger must satisfy is that as long as the input streams at r1 and r2 are ascending, the output

must be ascending too. This can be formulated as follows. The variables in1, in2, and out contain

the last numbers read and delivered.

νX(in1 : IN:=0, in2 : IN:=0,out : IN:=0).∀l : IN.([r1(l)](l≥in1→X(l, in2,out))∧[r2(l)](l≥in2→X(in1, l,out))∧[s(l)](l≥out∧X(in1, in2, l))).

It does not appear to be possible to phrase this property without using data in the fixed point

variables.

6.5 Using the mCRL2 toolset 145

6.5 Using the mCRL2 toolset

In principle we want to use the model checking capabilities of the mCRL2 tool set to establish if a

CIF model M has some property φ . As has become clear in the previous sections the transformation

of CIF models to mCRL2 models is not completely straightforward. There are limitations that

require that the CIF model is first transformed into another CIF model M′. For example, to allow

the use of the implicit location variables these have to be made explicit.

A second major difference is that the way mCRL2 deals with variables is different. Therefore,

we have introduced self-loops in each state with a value for each variable. As a consequence in

formulating properties of interest it should be taken into account that these self-loops are present.

To give an exampl. Assume that we are interested in formulating absence of deadlock. In modal

μ-calculus absence of deadlock is easily captured by the formula ¬[true∗]〈true∗〉true. However,

with the introduced self-loops in mind, no mCRL2 model that results from a CIF model with at

least one variable will have deadlock, even if the original CIF model does have deadlock.

Therefore, a major step in verifying CIF models using mCRL2 is the reformulation of the properties

in such a way that good care is taken of the events that are merely introduced for making available

location information and variable value information.

Specification of modal μ-calculus properties requires that the syntax of mCRL2 is used. The web-

page http://mcrl2.org/web/user_manual/language_reference/mucalc.html describes

this syntax.

Verification of a property w.r.t. some mCRL2 model requires the following steps:

• Adapt the mCRL2 model obtained from the transformation by adding immediately after the

keyword init the operator allow with as a first argument the set of all event names of interest

(including the original CIF event names, the location-event names, and the value-event names

in the following way. Replace

init ...;

by

init allow({ comma-separated-list-of-relevant-events }, ... );

where ... refers to the process term already provided by the transformation.

• Apply mcrl22lps on the resulting mCRL2 file with the option no-alpha checked! This is

important since otherwise the resulting LPS may be wrong.

• Apply lps2pbes on the lps file of the mCRL2 model of interest. In the menu that opens

insert the file that contains the model μ-calculus formula (with extension mcf). The result is

a file with extension pbes.

• Apply ps2bool on this pbes file to obtain a true or false, which indicates whether the

formula holds or not, respectively.

Exercise 6.41 Consider the dining philosophers case that we have considered frequently in

previous examples and exercises. Transform the corresponding CIF model with the plant

automata and the supervisor to mCRL2 and verify that indeed there is absence of deadlock.


Also verify the progress property/properties that each philosopher may eat in some future. Does

this property hold? �

Bibliography

[Bee+14] D. A. van Beek et al. “CIF 3: Model-Based Engineering of Supervisory Controllers”.

In: Tools and Algorithms for the Construction and Analysis of Systems - 20th Interna-tional Conference, TACAS 2014, Held as Part of the European Joint Conferences onTheory and Practice of Software, ETAPS 2014, Grenoble, France, April 5-13, 2014.Proceedings. Edited by Erika Ábrahám and Klaus Havelund. Volume 8413. Lecture

Notes in Computer Science. Springer, 2014, pages 575–580.

[CW10] K. Cai and W.M. Wonham. “Supervisor Localization: A Top-Down Approach to

Distributed Control of Discrete-Event Systems”. In: IEEE Transactions on AutomaticControl 55.3 (2010), pages 605–618.

[CL99] C. G. Cassandras and S. Lafortune. Introduction to Discrete Event Systems. Interna-

tional Series on Discrete Event Dynamic Systems. Springer-Verlag, 1999.

[CL08] C.G. Cassandras and S. Lafortune. Introduction to Discrete Event Systems. Springer,

2008.

[Flo+07] H. Flordal et al. “Compositional synthesis of maximally permissive supervisors using

supervisor equivalence”. In: Discrete Event Dynamic Systems 17.4 (2007), pages 475–

504.

[Gla90] Rob J. van Glabbeek. “The Linear Time-Branching Time Spectrum (Extended Ab-

stract)”. In: CONCUR ’90, Theories of Concurrency: Unification and Extension, Am-sterdam, The Netherlands, August 27-30, 1990, Proceedings. 1990, pages 278–297.

DOI: 10.1007/BFb0039066. URL: http://dx.doi.org/10.1007/BFb0039066.

[Gla93] Rob J. van Glabbeek. “The Linear Time - Branching Time Spectrum II”. In: CONCUR’93, 4th International Conference on Concurrency Theory, Hildesheim, Germany,August 23-26, 1993, Proceedings. 1993, pages 66–81. DOI: 10.1007/3-540-57208-

2_6. URL: http://dx.doi.org/10.1007/3-540-57208-2_6.

[GM14] J.F. Groote and M.R. Mousavi. Modeling and analysis of communicating systems. MIT

Press, 2014.


[HTL08] R.C. Hill, D.M. Tilbury, and S. Lafortune. “Modular supervisory control with equivalence-

based conflict resolution”. In: Proceedings of ACC. 2008, pages 491–498.

[LLW05] R.J. Leduc, M. Lawford, and W.M. Wonham. “Hierarchical interface-based supervisory

control-part II: parallel case”. In: IEEE Transactions on Automatic Control 50.9 (2005),

pages 1336–1348.

[LA14] Hai Lin and Panos J. Antsaklis. Hybrid dynamical systems: An introduction to controland verification. Now Publishers Inc., 2014.

[MF08] R. Malik and H. Flordal. “Yet another approach to compositional synthesis of discrete

event systems”. In: Proceedings of WODES. 2008, pages 16–21.

[Mar+10] J. Markovski et al. “Coordination of resources using generalized state-based require-

ments”. In: Proceedings of WODES. 2010, pages 297–302.

[MMF13] Sahar Mohajerani, Robi Malik, and Martin Fabian. “Compositional nonblocking ver-

ification for extended finite-state automata using partial unfolding”. In: 2013 IEEEInternational Conference on Automation Science and Engineering, CASE 2013, Madi-son, WI, USA, August 17-20, 2013. 2013, pages 930–935. DOI: 10.1109/CoASE.

2013.6654014. URL: http://dx.doi.org/10.1109/CoASE.2013.6654014.

[Oue+11] Lucien Ouedraogo et al. “Nonblocking and Safe Control of Discrete-Event Systems

Modeled as Extended Finite Automata”. In: IEEE Trans. Automation Science andEngineering 8.3 (2011), pages 560–569. DOI: 10.1109/TASE.2011.2124457. URL:

http://dx.doi.org/10.1109/TASE.2011.2124457.

[QC00] M.H. de Queiroz and J.E.R. Cury. “Modular supervisory control of composed systems”.

In: Proceedings of ACC. 2000, pages 4051–4055.

[RW87] P.J. Ramadge and W.M. Wonham. “Supervisory control of a class of discrete event

processes”. In: SIAM Journal on Control and Optimization 25.1 (1987), pages 206–

230.

[Ric08] Elaine Rich. Automata, Computability, and Complexity: Theory and Applications.

Pearson Prentice Hall, 2008.

[Sch15] K. W. Schmidt. “Computation of supervisors for reconfigurable machine tools”. In:

Discrete Event Dynamic Systems 25 (2015), pages 125–158.

[Sha01] A.C. Shaw. Real-Time Systems and Software. John Wiley & Sons, Inc., 2001.

[SSR09] R. Su, J. van Schuppen, and J. Rooda. “Synthesize nonblocking distributed supervisors

with coordinators”. In: Proceedings of the 17th Mediterranean Conference on Controland Automation. 2009, pages 1108–1113.

[SSR10] R. Su, J.H. van Schuppen, and J.E. Rooda. “Aggregative synthesis of distributed

supervisors based on automaton abstraction”. In: IEEE Transactions on AutomaticControl 55.7 (2010), pages 1627–1640.

[ST06] R. Su and J.G. Thistle. “A distributed supervisor synthesis approach based on weak

bisimulation”. In: Proceedings of WODES. 2006, pages 64–69.

[Swa17] Lennart Swartjes. PhD thesis. Eindhoven, The Netherlands: Department of Mechanical

Engineering, Eindhoven University of Technology, 2017.

[WW96] K.C. Wong and W.M. Wonham. “Hierarchical control of discrete-event systems”. In:

Discrete Event Dynamic Systems: Theory and Applications 6.3 (1996), pages 241–273.

[Won10] W.M. Wonham. Supervisory control of discrete-event systems. Technical report. Uni-

versity of Toronto, 2010.

Documents

6. Veriﬁcation of supervisors€¦ · 6. Veriﬁcation of supervisors Large parts of this chapter have been reproduced from [GM14], with permission from the authors. 6.1 Properties