Basic modelling with mCRL2
Behaviour and transition systems
In process algebras such as mCRL2, the basic units of computation are called actions. The philosophy is that any system can be described in terms of the observations that you can do about that system. The observations one can make with respect to a system are dictated only by its behaviour. By extension, every two systems that one might wish to distinguish must behave differently, or one would not be able to distinguish them by observing them.
Actions correspond to observable events in the behaviour of a system. As a running example, we will be introducing various coffee machines, the behaviour of which will differ, but of which the functionality will usually be expressed in terms of inserting coins into the machines, and retrieving coffee from it. Obvious choices for actions that a coffee machine might perform are ‘accepting a coin’, and ‘dispensing coffee’.
As we already mentioned, coffee machines will usually both accept coins and provide coffee. In fact, most coffee machines will only provide coffee after accepting coins. Before we continue, we formalise this notion of behaviour by saying that the behaviour of a system can be described by a labelled transition system, or LTS for short. These are relational structures that have a convenient graphical representation, and we will use them to give a semantics to the mCRL2 processes we present.
Definition (LTS)
A labelled transition system (LTS) is a tuple , where
is a set of states,
is a set of action labels,
is a transition relation and
is the initial state.
In graphical depictions of LTSs, states are shown as circles. The initial state
is marked by an incoming arrow that has no source state. For and
, we will write
instead of
.
Example
Consider a simple coffee machine that accepts a single coin and then
dispenses coffee. This system could be modelled by the LTS with
,
,
,
and
. Its
graphical representation is as follows:
Sequences and choices
The coffee machine in the example above is not very exciting. It performs only two actions, and it performs them sequentially. More interesting behaviour usually involves some form of choice. Choices in mCRL2 are nondeterministic, that is to say, if a system can choose between two actions to perform, then we don’t know anything about the probability with which it will choose either.
Let us consider a slightly more advanced coffee machine. It provides two kinds
of coffee. The first type costs only one coin, and is of the undrinkable,
asphalty kind. The event that the coffee machine dispenses this bad coffee is
modelled by the action
. The machine may also dispense nice coffee,
modelled by the action , but this will cost you an extra coin. We will
create a model of this machine in the mCRL2 language.
We start by giving an mCRL2 specification of our simple coffee machine, with on the left the semantics of the specification.
act coin, coffee;
init coin . coffee;
|
Note that the act statement explicitly defines the set of the LTS on
the left. The
init statement says that the initial state is a state that
can first perform a
action, followed by a
action. This
sequential behaviour is expressed by the
. operator.
We now wish to express that after inserting a single coin, we can either retrieve bad coffee, or we can insert another coin and get good coffee. This can be expressed as follows:
act coin, good, bad;
init coin . (bad + coin . good);
|
Again the . operator is used to indicate sequential execution (after
inserting a coin, the machine can perform bad + coin . good). Now is
a good time to note that . binds stronger than +, so
bad + coin . good is equal to bad + (coin . good). The
+ operator expresses the choice between either dispensing bad coffee
(bad), or accepting another coin and then dispensing good coffee
(coin . good). In the corresponding LTS, this choice is visualised
as a state that has two outgoing arrows.
Exercise
Give a specification for a machine that sells tea for 10¢ and coffee for 20¢.
Specifying systems
We mentioned in the introduction that we are interested in that part of the
behaviour of systems which we can observe. In the realm of modelling, we
therefore want to have a means of describing properties of systems such as ‘this
coffee machine will always dispense good coffee after inserting two coins’. To
this end, we introduce Hennessy-Milner logic, an extension of Boolean logic that
introduces a modality that expresses that if a system
performs an
action, then directly afterwards, the property
always holds. Note that in particular this is true if the system cannot do an
action. Its dual is the modality
, which says that a
system is able to (as opposed to must) do an
action, after which
holds.
Definition (Action formula)
An action formula over a set of actions is an expression that
adheres to the following syntax in pseudo-BNF, where
.
The following abbreviations may also be used.
An action formula over
is associated with a set
in the following manner.
Example
Let . Then the formula
corresponds to
.
Definition (HML)
A Hennessy-Milner logic formula interpreted over an LTS with action labels
adheres to the following syntax in pseudo-BNF, where
is an action
formula over
.
The following common abbreviations are allowed:
An HML formula is interpreted over an LTS
. Its semantics is given as the set of states
of the LTS in which the formula holds. It is
defined as follows.
We say that satisfies
, denoted
, if and only
if
.
Example
The formula can be used to express
that there is a possibility that a system dispenses good coffee after
accepting one coin. This formula does not hold for the machine in figure with
another coffee machine, because when you insert one coin, the machine will only
provide you with bad coffee.
Example
The formula does hold
for the machine in another coffee machine; it says that always after
accepting a coin, the machine might (is able to) dispense bad coffee or
accept another coin.
Exercises
Show that an arbitrary LTS can never satisfy
, and that it will always satisfy
.
Describe in English what the formula
means.
Give HML formulae expressing the following properties:
The coffee machine can dispense good coffee after two coins have been inserted.
The coffee machine will not dispense bad coffee after two coins have been inserted.
Comparing systems
Given two system models, one might wonder whether they are in some sense interchangeable. This calls for a natural notion of behavioral equivalence that relates systems that cannot be distinguished by observing their behaviour. As we shall see, such an equivalence can be quite straightforward. Not quite coincidentally, HML was originally designed as an alternative way to distinguish systems. In fact, it was shown that two systems are related by the equivalence described below if and only if there is no HML formula that is true for one and false for the other.
Definition (Strong bisimulation)
Let
and be labelled transition systems. A relation
is a strong bisimulation relation if and only if for
(also written
) we have for all
:
if
, then there is a
such that
and
.
if
, then there is a
such that
and
.
Two states are said to be strongly bisimilar, denoted
, if there is a strong bisimulation relation
such that
. Two
LTSs are strongly bisimilar iff their initial states are bisimilar.
Example
In the following diagram, the dotted lines indicate the pairs of nodes that
are related by a relation .
is a bisimulation relation that relates the initial states of the two
transition systems, hence they are bisimilar.
Note that the definition also allows you to compare states within a single
transition system (i.e., ). If two states are found to be
bisimilar, then for all intents and purposes it is reasonable to see them as
only one state, thus giving rise to a natural statespace reduction: if in
an LTS
we merge all states that are bisimilar, the resulting LTS
is
bisimilar to
.
Example
In the following diagram, the dotted lines indicate the pairs of states that
are related by a relation .
is a bisimulation relation, so merging all related states will yield a
smaller, bisimilar transition system (namely the left transition system of
the previous bisimulation example).
Exercise
Are the following two process definitions bisimilar?
act coin, good, bad;
init coin . (bad + coin . good);
act coin, good, bad;
init coin . bad + coin . coin . good;