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 ,
110 Chapter 6. Verification of supervisors
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
112 Chapter 6. Verification of supervisors
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:
8 edge zero , one goto L2;
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) =
114 Chapter 6. Verification of supervisors
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_L1) +
6 (Locvar_lock_picking == loc_lock_picking_L1) -> zero .
BehProc_lock_picking(loc_lock_picking_L2) +
7 (Locvar_lock_picking == loc_lock_picking_L1) -> one .
BehProc_lock_picking(loc_lock_picking_L2) +
8 (Locvar_lock_picking == loc_lock_picking_L2) -> zero .
BehProc_lock_picking(loc_lock_picking_zero_on_three) +
9 (Locvar_lock_picking == loc_lock_picking_L2) -> one .
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 .
BehProc_lock_picking(loc_lock_picking_L0) +
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.
6.3 From CIF to mCRL2: an informal treatment 115
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;
8 edge zero , one goto L1;
9 location L1:
10 edge loc_L1;
11 edge zero , one goto L2;
12 location L2:
13 edge loc_L2;
14 edge zero goto zero_on_three;
116 Chapter 6. Verification of supervisors
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.
6.3 From CIF to mCRL2: an informal treatment 117
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) +
5 (Locvar_philosopher1 == loc_philosopher1_Thinking) -> P1_f2 .
BehProc_philosopher1(loc_philosopher1_F2) +
6 (Locvar_philosopher1 == loc_philosopher1_F1) -> P1_f2 .
BehProc_philosopher1(loc_philosopher1_Eating) +
7 (Locvar_philosopher1 == loc_philosopher1_F2) -> P1_f1 .
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) =
13 (Locvar_philosopher2 == loc_philosopher2_Thinking) -> P2_f1 .
BehProc_philosopher2(loc_philosopher2_F1) +
14 (Locvar_philosopher2 == loc_philosopher2_Thinking) -> P2_f2 .
BehProc_philosopher2(loc_philosopher2_F2) +
15 (Locvar_philosopher2 == loc_philosopher2_F1) -> P2_f2 .
BehProc_philosopher2(loc_philosopher2_Eating) +
16 (Locvar_philosopher2 == loc_philosopher2_F2) -> P2_f1 .
BehProc_philosopher2(loc_philosopher2_Eating) +
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
) +
23 (Locvar_fork1 == loc_fork1_OnTable) -> P2_f1 . BehProc_fork1(loc_fork1_F2
) +
24 (Locvar_fork1 == loc_fork1_F1) -> P1_f . BehProc_fork1(loc_fork1_OnTable)
+
25 (Locvar_fork1 == loc_fork1_F2) -> P2_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) =
30 (Locvar_fork2 == loc_fork2_OnTable) -> P1_f2 . BehProc_fork2(loc_fork2_F1
) +
31 (Locvar_fork2 == loc_fork2_OnTable) -> P2_f2 . BehProc_fork2(loc_fork2_F2
) +
32 (Locvar_fork2 == loc_fork2_F1) -> P1_f . BehProc_fork2(loc_fork2_OnTable)
+
33 (Locvar_fork2 == loc_fork2_F2) -> P2_f . BehProc_fork2(loc_fork2_OnTable)
;
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 ,
118 Chapter 6. Verification of supervisors
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:
6.3 From CIF to mCRL2: an informal treatment 119
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);
120 Chapter 6. Verification of supervisors
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) |
6.3 From CIF to mCRL2: an informal treatment 121
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 ,
55 q1leave | awrite_count | aread_count ,
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},
122 Chapter 6. Verification of supervisors
65 (
66 allow({ q1enter | awrite_count | aread_count ,
67 q1leave | 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,
124 Chapter 6. Verification of supervisors
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
6.4 Specification of behavioral properties 125
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)
�
126 Chapter 6. Verification of supervisors
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:
6.4 Specification of behavioral properties 127
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
128 Chapter 6. Verification of supervisors
• 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 Specification of behavioral properties 129
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,
130 Chapter 6. Verification of supervisors
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.
6.4 Specification of behavioral properties 131
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.
132 Chapter 6. Verification of supervisors
�
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.
6.4 Specification of behavioral properties 133
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. �
134 Chapter 6. Verification of supervisors
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 Specification of behavioral properties 135
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]
136 Chapter 6. Verification of supervisors
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
6.4 Specification of behavioral properties 137
�
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.
138 Chapter 6. Verification of supervisors
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.
6.4 Specification of behavioral properties 139
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).
�
140 Chapter 6. Verification of supervisors
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 ,〈a〉X 〈a〉X ∨〈b〉true
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.
6.4 Specification of behavioral properties 141
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
142 Chapter 6. Verification of supervisors
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? �
6.4 Specification of behavioral properties 143
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.
144 Chapter 6. Verification of supervisors
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.
146 Chapter 6. Verification of supervisors
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.
148 Chapter 6. Verification of supervisors
[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.