An action-based framework for verifying logical and
behavioural properties of concurrent systems
R. De Nicola
, A. Fantechi , S. Gnesi , G. Ristori
Università La Sapienza Roma
I.E.I. - C.N.R. Pisa
Università degli Studi di Pisa
Abstract
A system is described which supports proving both behavioural and logical
properties of concurrent systems; these are specified by means of a process
algebra and its associated logic. The logic is an action based version of the
branching time logic CTL, which we call ACTL. It is interpreted over transition
labelled structures while CTL is interpreted over state labelled ones. The core of
the system are two existing tools, AUTO and EMC. The first builds the labelled
transition system corresponding to a term of a process algebra and permits proof
of equivalence and simplification of terms, while the second checks the validity
of CTL logical formulae. The integration is realized by means of two translation
functions from the action based branching time logic ACTL to CTL and from
transition-labelled to state-labelled structures. The correctness of the integration is
guaranteed by the proof that the two translation functions when coupled preserve
satisfiability of logical formulae.
1. Introduction
Process algebras [9, 21, 23, 28] are generally recognized as a convenient tool for describing
concurrent systems at different levels of abstraction. They rely on a small set of basic operators
which correspond to primitive notions of concurrent systems and on one or more notions of
behavioural equivalence or preorder. The operators are used to build complex systems from more
elementary ones. The behavioural equivalences are used to study the relationships between
different descriptions (e.g. specification and implementation) of the same system at different levels
of abstractions and thus to perform part of the analysis.
The basic operational semantics of process algebras is usually defined in terms of Labelled
Transition Systems, which are then factorized by means of observational equivalences or testing
preorders. A few verification environments are now available which can be used to verify
properties of concurrent systems specified by means of process algebras with respect to these
behavioural relations [4, 11, 12, 19, 20].
The equivalence (preorder)-based approach to system verification has a major disadvantage:
specifications, even at the most abstract level, tend to be too concrete; they are, anyway,
Note:
The research has been partially supported by the CEC under ESPRIT project 2304 LOTOSPHERE and
EBRA project 3011 CEDISYS and by "Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo" of CNR.
A preliminary version appeared in the Proceedings of the 3rd Workshop on Computer Aided Verification;
Aalborg, 1991.
descriptions of system behaviours even when it is assumed that some of the actual actions are
invisible. Logic is a good candidate to provide more abstract specifications, since it permits describing systems properties rather than systems behaviours. Indeed, different types of temporal and
modal logics have been proposed for the abstract specification of concurrent systems; in particular,
modal and temporal logics, due to their ability to deal with notions such as necessity, possibility,
eventuality, etc., have been recognized as a suitable formalism for specifying properties of
concurrent systems [16, 22, 29].
Modal and temporal logics have been equipped with model checkers to prove satisfiability of
formulae and thus properties: a system, usually finite state, is considered as a potential model for
the formula expressing the desired property. Actually, elegant temporal logics like CTL and CTL*
have been put forward [16, 18], and sophisticated and efficient model checkers, like EMC, have
been developed for them [10]; these logics are interpreted over Kripke Structures and permit
formulating properties of systems in terms of their states; we qualify they as "state-based" logics.
Now, an apparent contrast pops up between the logical models and the behavioural models; in
the former reasoning is based on state properties and on state changes while in the latter a central
role is played by the actions which cause state changes. To overcome this problem, specific logics
for process algebras have been proposed, (see e.g. [7, 22, 27, 32]) that are interpreted over
Labelled Transition Systems; tools have been developed to support reasoning with them [8, 11].
These logics express properties of systems in terms of the actions they can perform and thus they
can be qualified as "action-based". However, either we have logics, like Hennessy-Milner logic
[22], that are not sufficiently expressive or fragments of µ-calculus [26], that require using fixed
points and lack directness in describing systems properties (see e.g. [27]).
Recently, a new action-based logic, ACTL [15], has been proposed, that is more expressive
than Hennessy-Milner Logic and can naturally describe safety and liveness properties. ACTL has
the same expressive power as CTL and thus also as the fragments of µ-calculus which can be
model checked in polynomial time [17], but, differently from these, ACTL does not require
recursive definitions.
The main aim of this paper is presenting a verification environment based on a single
underlying model, namely that of Labelled Transition Systems. More specifically, we will present a
system in which behavioural properties of concurrent systems are described by means of a process
algebra, and logical properties are expressed as ACTL formulae so that it is always possible to
reason in terms of the actions systems can perform.
The verification environment consists of the behavioural verificator AUTO [12] and of an
efficient model checker for ACTL. AUTO builds the labelled transition systems corresponding to
process algebra terms (accepted process algebras are CCS [28], Meije [1], LOTOS [3]) and permits
minimizing and checking equivalences of transition systems. Efficient model checking for ACTL is
achieved by means of two modules implementing two translation functions, from ACTL to CTL
formulae and from Labelled Transition Systems to Kripke Structures, which provide the correct
input to EMC model checker [10].
The proposed translations functions (derived from those of [15] and slightly modified to obtain
an efficient implementation) are proved to preserve the truth of the formulae. This result guarantees
that the verification of an ACTL formula on a given system is correctly reduced to the
corresponding verification of a CTL formula on a Kripke Structure. Our model translator
transforms the transition systems built by AUTO into Kripke Structures. The latter are used as
models to verify, via EMC model checker, satisfiability of ACTL formulae which have been
translated into CTL by our logic translator. Both translations are linear; this, coupled with the
2
linear algorithm of EMC, guarantees linear model checking for ACTL.
Our decision not to directly implement the model checker, but to reuse EMC, and to base the
process algebra manipulation on AUTO was due to the aim of rapidly building a prototypal
environment to experiment with the descriptive power of the new logic while relying on widely
used and continuously upgraded tools. The use of AUTO and EMC has had the nice side effect of a
quick integration of our environment within LITE [33], an integrated support environment for
LOTOS, so that logical properties of systems described in the subset of LOTOS accepted by AUTO
can be checked.
The rest of the paper is organized as follows. In the next section, the relevant definitions about
the used logics are summarized. Section 3, the core of the paper, contains the description of our
verification environment. In Section 4, a couple of specification and verification examples is
presented to give a flavour of the potentiality of the environment. The proof of correctness of the
proposed transformation functions is reported in Appendix A, while additional details on one of the
verification examples are given in Appendix B.
2. ACTL: An action based version of CTL
In this section we present the logic CTL [16] whose interpretation domains are Kripke Structures
and the logic ACTL proposed in [15] that is based on actions rather than states and thus is
interpreted over Labelled Transition Systems. Kripke Structures and Labelled Transition Systems,
when used as semantic models in an interleaving semantics, have the same expressive power; they
differ because in the former states are labelled to describe how they are modified by the transitions,
while in the latter transitions are labelled to describe the actions which cause state changes.
A Kripke Structure (or KS) is a 5-tuple = (S, AP, , →, 0S) where:
• S is a set of states;
• AP is a finite, non-empty set of atomic proposition names ranged over by p, p1, ...;
• L: S→2AP is a function that labels each state with a set of atomic propositions true in that
state;
• → º S S is the transition relation; an element (r, s)∈→ is called a transition and it is
written as r→s;
• 0S is the initial state.
A Labelled Transition System (or LTS) is a 4-tuple = (Q, A∪{τ}, →, 0Q) where:
• Q is a set of states;
• A is a finite, non-empty set of visible actions; the silent action τ is not in A;
• → ⊆ Q × (Α∪{τ}) × Q is the transition relation; an element (r,α,q)∈ → is called a
transition, and is written as r−α→q;
• 0Q is the initial state.
We let Aτ = Α∪{τ}; Aε = Α∪{ε}, ε ∉ Aτ. Moreover, we let r, q, s … range over states; a, b, …
over A; α, β, … over Aτ and k, ... over Aε.
Paths over a LTS, = (Q, Aτ, →, 0Q), are now introduced:
• A sequence (q0,α0,q1) (q1,α1,q2)… ∈ →∞ is called a path from q0; a path that cannot be
extended, i.e. is infinite or ends in a state without outgoing transitions, is called a fullpath;
3
the empty path consists of a single state q ∈ Q and it is denoted by q;
• if π = (q0,α0,q1) (q1,α1,q2)… we denote the starting state, q0, of the sequence by first(π)
and the last state in the sequence (if the sequence is finite) by last(π); if π is an empty path
(i.e. π = q), then first(π) = last(π) = q
• concatenation of paths is denoted by juxtaposition: π = ρθ; it is only defined if ρ is finite and
last(ρ)=first(θ).
When π = ρθ we say that θ is a suffix of π and that it is a proper suffix if ρ ≠ q, q ∈ Q.
We write path(q) for the set of fullpaths from q and let π, ρ, σ, η range over paths.
The notation for paths of Labelled Transition Systems carries over to Kripke Structures in the
obvious way. The only difference is that transitions are no longer triples but pairs, so a path of a
Kripke Structure is a sequences of pairs (s0, s1) (s1, s2)… .
The actual models that we use are assumed to have only infinite fullpaths; it is not a strong
constraint since it is always possible to extend finite fullpaths with τ-loops. Our choice is dictated
by a requirement of EMC that inputs only "fair" structures, that is Kripke Structures in which all
fullpaths are infinite in length.
CTL is a language of state formulae interpreted over Kripke Structures and it is just a subset of
CTL* [16] a logic which combines linear and branching time operators. The syntax of CTL* is
given in terms of path formulae that are interpreted over paths and state formulae that are true or
false of a state. CTL is the branching time subset of CTL* in which every linear time operator is
immediately preceded by a path quantifier; it is defined as the set of state formulae ϕ given by the
following grammar, where γ ranges on path formulae and p ranges on AP:
ϕ ::= p | ¬ ϕ | ϕ ∧ ϕ | ∃γ | ∀γ
γ ::= X ϕ | ϕ U ϕ
We write true for ¬(p0∧¬p0) where p0 is some arbitrarily chosen atomic proposition name.
As usual, a set of logic operators and modalities can be derived from the basic ones: false, ϕ ∨ ϕ',
ϕ ⇒ ϕ', Fϕ (eventually), Gϕ (always) [16].
Let = (S, AP, , →, 0S) be a Kripke Structure. Satisfaction of a state formula ϕ (path formula
γ) by a state s (path ρ), notation s » ϕ or just s » ϕ (ρ » γ or ρ » γ), is defined inductively by:
s»p
s » ¬ϕ
s » ϕ∧ϕ'
s » ∃γ
s » ∀γ
ρ » ϕUϕ'
iff
iff
iff
iff
iff
iff
ρ » Xϕ
iff
p ∈ (s);
s ‰ ϕ;
s » ϕ and s » ϕ';
there exists a path θ ∈ path(s) such that θ » γ;
for all paths θ ∈ path(s) θ » γ;
there exists a suffix θ of ρ such that first(θ) » ϕ' and for all suffixes η of ρ,
such that θ is a proper suffix of η: first(η) » ϕ;
there exist s, s', θ such that ρ = (s, s')θ and s' » ϕ.
To define the logic ACTL, in [15], a tiny auxiliary logic of actions is introduced.
4
The collection Afor of action formulae over A is defined by the following grammar where χ, χ',
range over action formulae, and a∈A:
χ ::= a | ¬χ | χ∨χ'
We write true for a0∨¬a0, where a0 is some arbitrarily chosen action, and false for ¬ true. An
action formula permits expressing constraints on the actions that can be observed (along a path or
after next step); for instance, a ∨ b says that the only possible observations are a and b, while true
stands for "all actions are allowed" and false for "no actions can be observed", that is only silent
actions can be performed.
The satisfaction of an action formula χ by an action a, notation a » χ, is defined inductively by:
•a»b
• a » ¬χ
• a » χ∨χ'
iff
iff
iff
a = b;
a ‰ χ;
a » χ or a » χ'.
The syntax of ACTL, a subset of ACTL* [15], is defined by the state formulae generated by the
following grammar, where ϕ, ϕ', … range over state-formulae, γ over path formulae and χ and χ'
are action formulae:
ϕ ::= true | ¬ϕ | ϕ∧ϕ' | ∃γ | ∀γ
γ ::= Xχϕ | Xτϕ | ϕ χUχ'ϕ' | ϕ χUϕ'
The satisfaction relation for ACTL formulae is given below.
Let = (Q, Aτ, →, 0Q) be a LTS. Satisfaction of a state formula ϕ (path formula γ) by a state q
(path ρ), notation q » ϕ or just q » ϕ (ρ » γ, or ρ » γ), is given inductively by:
• q » true
• q » ¬ϕ
• q » ϕ∧ϕ'
• q » ∃γ
• q » ∀γ
• ρ » ϕ χ U χ 'ϕ'
• ρ » ϕ χUϕ'
• ρ » Xχ ϕ
• ρ » Xτ ϕ
always;
iff q ‰ ϕ;
iff q » ϕ and q » ϕ';
iff there exists a path θ ∈ path(q) such that θ » γ;
iff for all paths θ ∈ path(q) θ » γ;
iff there exists θ = (q,a,q')θ', suffix of ρ, s.t. q' » ϕ', a » χ', q » ϕ
and for all η = (r,β ,r')η ', suffixes of ρ, of which θ is a proper
suffix, we have r » ϕ and ( β» χ or β = τ );
iff there exists a suffix θ of ρ s. t. first(θ) » ϕ' and for all η = (r,β,r')η'
of which θ is a proper suffix we have r » ϕ and ( β » χ or β = τ );
iff ρ = (q,a,q')θ and q' » ϕ and a » χ;
iff ρ = (q,τ,q')θ and q' » ϕ.
As usual, a set of logical operators and modalities derived from the basic ones is introduced: false,
ϕ ∨ ϕ', ϕ ⇒ ϕ', Fϕ (eventually), Gϕ (always). Other derived modalities [15] similar to those of
Hennessy-Milner logic with until in [14] are:
• ϕ <a> ϕ'
for ∃(ϕ false U a ϕ'),
• ϕ <ε>ϕ'
for ∃(ϕ false U ϕ'),
5
• <k> ϕ
• [k] ϕ
for
for
true <k> ϕ,
¬ <k>¬ϕ.
The indexed next modalities Xχϕ, Xτϕ say that in the next state of the path, reached respectively
with an action in χ or with a τ, the formula ϕ holds; the meaning of the indexed until modalities
introduced above is better clarified in Fig. 1:
ϕ χ U χ' ϕ'
φ
ϕ χ U ϕ'
φ
τ ∨ b1
τ ∨ b1
φ
τ ∨ b2
φ
τ ∨ b2
φ
φ
length ≥ 0
φ
φ
τ ∨ bn
τ ∨b n
φ
φ′
a
φ′
where b1|= χ, ..., bn |= χ and a |= χ'
Fig. 1 The meaning of the indexed until modalities.
It is worth remarking that both CTL and ACTL are adequate with respect to strong bisimulation
congruence. Moreover, if we consider the subsets of CTL and ACTL without the next operator, we
obtain (see [14]) for CTL - X adequacy with respect to stuttering equivalence [5] and for ACTL X adequacy with respect to branching bisimulation [34].
In [15] it has been proved that every formula in ACTL can be translated in one of CTL. To
define the mapping ' between them, a corresponding translation
between their models, that is
Labelled Transition Systems and Kripke Structures, is introduced. In the next section the complete
definition of the translation functions
and
' is given; these are a variant of the original ones
presented in [15].
3. The Verification Tool
To obtain a general verification environment for verifying bisimulation based equivalences and
ACTL properties on terms of a process algebras, we have chosen to integrate two tools: AUTO
[12] and EMC [10]. AUTO generates a Labelled Transition System from a CCS, Meije or LOTOS
specification, and permits verification of bisimulation based equivalences and minimization of
states. EMC is a model checker for CTL formulae. The model checker for ACTL relies on EMC
and permits verifying validity of an ACTL formula on a Labelled Transition System. The
architecture of our environment is summarized in Fig. 2.
To perform the check of an ACTL formula ϕ on a Labelled Transition System M, the following
steps are needed:
1) Input M and ϕ;
6
2) Translate M into the corresponding Kripke Structure M';
3) Translate ϕ into the corresponding CTL formula ϕ';
4) Perform the Model Checking of ϕ' on M'.
Process
ACTL Formula
AUTO
LTS
Generator
Logic
Translator
EMC
(fc)
Model
Translator
CTL Formula
LTS
Other
AUTO
functions
KS
Results
MODEL CHECKER FOR ACTL
AUTO
Results
existing tools
Fig. 2 Architecture of the verification environment.
3.1. Generating the Labelled Transition System
To build the Labelled Transition System corresponding to a term of a process algebra we use
AUTO. It must be said that the actual construction phase starts only if a finiteness test is passed.
Indeed, some terms might have an infinite number of states and AUTO, before starting the actual
construction of the Labelled Transition System, takes advantage of the sufficient conditions for
finiteness given in [30].
AUTO is able to generate reduced automata, taking into account a given abstraction criterion or
equivalence relation. Since ACTL is consistent with the strong bisimulation congruence only
strong minimization should be used. However, if we are interested only in properties described by
means of ACTL - X, i.e. in more abstract requirements, also minimizations which permit
eliminating invisible transitions from the model can be performed. Care is needed since it is not yet
clear what is the maximal weak equivalence preserved by the minimization implemented in AUTO.
The Labelled Transition System provided by AUTO can be written in a number of different
formats; one of these is called format commun; it has been proposed as standard format for
representing automata. With this format an automaton is defined by means of a series of tables:
atoms, monoms and labels tables that provide state names and arc labels; and a states and
transitions table that keeps information about the state number (and, optionally, the state name and
a property), the labels of the transitions and a list of successor states (see the Appendix B for an
example).
3.2. The Model Translator
The Model Translator transforms the Labelled Transition System produced by AUTO into a
7
suitable input for the EMC, i.e. a Kripke Structure. To provide this functionality we have
implemented the T1 algorithm given below. Since EMC accepts as input a Kripke Structure with
fair paths (that is a Kripke Structure in which all fullpaths are infinite in length), differently from
[15], our translation extends to infinity all finite fullpaths by adding a τ-loop to the last state.
The construction of the Kripke Structure from a Labelled Transition System is obtained by
splitting transitions labelled by visible actions and creating on correspondence of each transition, a
new state that is labelled with the label of the original transition; the generated system has
essentially the same structure of the original one. In Fig. 3, the translations of an observable and of
an unobservable transition are shown:
a
τ
{⊥}
{a}
{⊥}
{⊥}
LTS
{⊥}
KS
Fig. 3 Translations of single transitions
It is worth noting that, due to the kind of input transition system, the translation algorithm
generates only a a particular kind of Kripke Structure, in which the labelling of a state consists of a
single action proposition. In general, a set of propositions can be associated to every state of a
Kripke Structure and this turns out to be useful when process algebras are considered which are
equipped with a multiset (or step) semantics or when other non-interleaving semantics are
considered.
T1 (From LTSs to KSs)
Let
= (Q, Aτ, →, 0Q) be a LTS, Qd the subset of states of Q that have not successors, ⊥ be a
fresh symbol not in Aτ and qf be a fresh state not in Q. The Kripke Structure,
( ), is defined as
(S', AP, , →', 0Q) where:
• S' = Q ∪ {(r, a, q) | a∈A and (r, a, q)∈→ } ∪ N, where N = {qf } if Qd ≠{} and N = {}
otherwise;
• AP = A ∪ {⊥};
• →' = {(r,q) | (r, τ, q)∈→} ∪ {(r,(r,a,q)) | (r, a, q)∈→} ∪ {((r,a,q), q) | (r, a, q)∈→} ∪ D,
where D = {(q, qf) | q ∈ Qd} ∪ {(qf, qf)} if Qd ≠ {} and D = {} otherwise;
• For r, q ∈ Q and a ∈ A: (q) = {⊥}, ((r,a,q)) = {a};
• (qf) = {⊥}.
The translation produces a Kripke Structure with a larger number of states; new states are labelled
with the same label of the corresponding transition while old states are labelled with a fresh
symbol, ⊥, whose meaning is no visible actions occurred. The original translation in [15] has
been modified in order to extend finite fullpaths: if there exist finite fullpaths in the Labelled
Transition System then in the corresponding Kripke Structure a new state qf is created, with label
⊥ and successor qf, and finite fullpaths are extended relating deadlock states with qf.
8
The size of the sets of states and transitions of the Kripke Structure produced by the above
algorithm is given by the following formulae, where n = |Q|, d = |Qd |, m = |→|, and u is the
number of unobservable transitions in →:
|S '| =
n+ m-u
n + m - u +1
if d = 0
if d ≠ 0
and |→ '| =
2m - u
2m - u + 1 + d
if d = 0
if d ≠ 0
3.3 The Logic-Translator
This module transforms an ACTL formula into a suitable input formula for the EMC, i.e. a CTL
formula. This translation step has been implemented by parsing the ACTL formula before giving it
as input to EMC; once an ACTL formula is parsed, its translation into CTL is given according to
the following
function. We have modified the original function presented in [15] in order to
take into account the quantifiers over linear time operators.
The translation of the logic goes hand by hand with the translation of the model; for example, as
suggested by Fig. 3, to translate the ACTL formula ∃Xaϕ we state the existence of a next state s
such that it is labelled with the action proposition a, different from ⊥, and such that it will be
possible, from s, to reach a next state that satisfies the translation of ϕ. These requirements are
translated into the CTL formula ∃X(¬⊥ ∧ a ∧ ∃X( '(ϕ))).
We wish to stress that we do not consider the logic translation interesting in itself but only as a
stepping stone toward proving the satisfaction preserving theorem.
T2 (From ACTL to CTL)
The mapping
: ACTL → CTL is inductively defined by:
• '(true)
= true,
• '(¬ϕ)
= ¬
'(ϕ),
• '(ϕ∧ϕ')
=
'(ϕ) ∧
'(ϕ '),
• '(∃(ϕ χ U χ' ϕ')) = ∃(((⊥ ∧ '(ϕ)) ∨ (¬⊥ ∧χ)) U ((¬⊥ ∧ χ') ∧ ∃X(⊥ ∧
• '(∃(ϕ χ U ϕ'))
= (⊥ ∧ '(ϕ')) ∨ ∃(((⊥ ∧
'(ϕ)) ∨ (¬⊥ ∧χ)) U (⊥ ∧
• '(∃X χ ϕ)
= ∃X(¬⊥ ∧ χ ∧ ∃X( '(ϕ))),
• '(∃X τϕ)
= ⊥ ∧ ∃X(⊥ ∧ '(ϕ)),
•
•
•
•
'(∀(ϕ χ U χ' ϕ'))
'(∀(ϕ χ U ϕ'))
'(∀X χ ϕ)
'(∀X τϕ)
=
=
=
=
∀(((⊥ ∧ '(ϕ)) ∨ (¬⊥ ∧χ)) U ((¬⊥ ∧ χ') ∧ ∀X(⊥ ∧
(⊥ ∧ '(ϕ')) ∨ ∀(((⊥ ∧
'(ϕ)) ∨ (¬⊥ ∧χ)) U (⊥ ∧
∀X(¬⊥ ∧ χ ∧ ∀X( '(ϕ))),
⊥ ∧ ∀X(⊥ ∧ '(ϕ)).
The key result about ' is that it preserves truth, that is if
formula then » j if and only if ( ) »
(j).
Theorem: Let
= (Q, Aτ, →, 0Q) be an LTS,
'(ϕ')))),
'(ϕ'))),
'(ϕ')))),
'(ϕ'))),
is a LTS and ϕ is an ACTL
= (S, AP, , →', 0Q) be
( ) and q∈Q; let
φ an ACTL formula. Then q » φ if and only if q »
(φ).
Sketch of the proof (The complete proof is reported in Appendix A):
The proof goes by induction on the length of the ACTL formulae. It is shown that, for every
formula j, q» j if and only if q»
(j). It is of fundamental importance for the proof the fact
9
that to every state in Q there corresponds a state in S with the same name and that only states
corresponding to existing ones are labelled with ¤. New states in
( ) are labelled with the
action associated to the corresponding transition; then, if the label of the transition satisfies a given
action formula χ we have that the corresponding state satisfies the CTL formula χ.
An interesting property of the T2 algorithm is that the size of
'(ϕ) is linear in the size of ϕ.
3.4. Model Checking
The output of the Model Translation phase is given as input to EMC. ACTL expressions to be
verified can be given as input to the EMC prompt; any time an ACTL formula is given as input,
EMC calls the Logic Translator to get the corresponding CTL formula; then EMC checks the CTL
formula on the Kripke Structure, giving as result true or false.
It is not difficult to see that we can perform model checking for ACTL with time complexity
O((|Q|+|→|) × |ϕ|). Indeed, if we let
be a finite LTS, s be a state of
and ϕ be an ACTL
formula, in order to determine whether q » ϕ it suffices to check whether q »
'(ϕ). We can
compute ( ) in O(|Q|+|→|)-time and the number of states and transitions of ( ) will be of
order |Q|+|→|. The formula '(ϕ) can be computed in O(|ϕ|)-time and its size will be of order |ϕ|.
Model checking of formula ϕ on with the algorithm for CTL of [10] can be therefore performed
in O((|Q|+|→|) × |ϕ|)-time.
3.5. The User Interface
The version of our tool that has been integrated in the LITE environment is equipped with a
window-based user interface. When the tool is invoked a main window appears in which three
areas can be distinguished.
The command buttons area includes a set of buttons:
• the quit button: clicking on it causes exiting from our verification environment;
• the enterspec, enteraut and enterform buttons: clicking on one of them causes a transient
window to appear in which the user can write the name of a file to be loaded which contains
respectively a specification, an automaton to be used as a model and an ACTL formula to be
checked.
• the help button; clicking on it causes a transient window to appear in which an helping text is
displayed.
The second area to be considered is a dialogue box equipped with an enter button, in which the
user can digit and enter on-line commands. Finally, there is an area used to display messages on
the truth of formulae, warnings and error messages.
_________________________________________________________________________
_________________________________________________________________________
Fig. 4 The user interface.
10
4. Two example specifications
In this section, we present the behavioural and logical specifications of two simple systems, which
should give an idea of the functionalities and potentialities of our prototype tool. We will not use
LOTOS to describe our systems but a Meije-like dialect of CCS because of the problems we had in
modifying the input interface of the available version of AUTO to accept LOTOS expressions. With
the forthcoming version of AUTO, LAUTO, we will be able to run directly the examples in Basic
LOTOS. In this session we assume familiarity with the process algebra formalisms and their
operational semantics in terms of Labelled Transition Systems, see e.g. [28].
4.1 Reading and Writing Atomically
We want to model a system consisting of two processes which access a file to read or modify it and
such that, when combined, reading and writing do not overlap.
If we denote by beginr, beginw, endr and endw the starting and final points of reading and
writing respectively, then a high level specification of the system is:
Sys_spec = τ: beginr: endr: Sys_spec + τ: beginw: endw: Sys_spec.
In Fig. 5, the Labelled Transition System and the Kripke Structure corresponding to the
specification Sys_spec are given.
{⊥}
τ
endr
beginr
τ
{⊥}
endw
{⊥}
beginw
{beginr}
{⊥}
{endr}
{beginw}
{⊥}
{endw}
Fig. 5 An LTS and the generated KS.
A more detailed specification, Sys_imp, of the system can be given that combines in parallel a
Reader, a Writer and a Semaphore; the latter controls the accesses to the file. Below, we use a? to
denote the complementary action of a; a:exp to denote sequential composition between a and exp;
exp+exp and exp//exp to denote possible choice and parallel execution respectively. Finally we use
exp\a to denote restriction of action a to exp. In our example, the control actions p and v are
restricted (cannot be seen from outside the system) in order to avoid their asynchronous execution.
Reader
Writer
Semaphore
Sys_imp
=
=
=
=
p?: beginr: endr: v?: Reader;
p?: beginw: endw: v?: Writer;
p: v: Semaphore;
(Reader // Writer // Semaphore) \ p \ v;
11
In Fig. 6, the Labelled Transition System and the Kripke Structure corresponding to the
specification Sys_imp are given.
{⊥}
τ
τ
{⊥}
beginr
{⊥}
beginw
τ
τ
{beginr}
endr
{beginw}
endw
{⊥}
{⊥}
{endr}
{endw}
{⊥}
{⊥}
Fig. 6 Another LTS and the generated KS.
The following high level specification of the reader-writer system, which does not include silent
actions, is a natural one:
Sys_spec1 = beginr: endr: Sys_spec1 + beginw: endw: Sys_spec1
With AUTO it turns out that Sys_spec1 is not bisimulation equivalent to Sys_spec and Sys_imp;
and that Sys_spec is observational equivalent to Sys_imp. The latter equivalence throws light on
the fact that requiring equivalence between specifications and implementation can be too
demanding. Indeed, we have to introduce silent actions in the high level specification. Often it
would be sufficient to prove that Sys_imp shares with both high level specifications the following
property, which states a sort of mutual exclusion between reading and writing:
∀G(([beginr]∀[true (¬beginw ∧ ¬endw)Uendr true]) ∧ ([beginw]∀[true (¬beginr ∧ ¬endr)Uendw true])).
With our verification environment it can be verified that the three behavioural descriptions of the
system satisfy the above formula. In less trivial examples, it might be very difficult to provide an
high-level behavioural description of a system and we might have to rely only on logics to prove its
properties.
4.2. Controlling Trains on a Circular Railways
In this section we describe a circular railway, divided into 6 track sections, from 0 to 5. Two
trains, namely train_a and train_b, can run on this circular railway, with the constraint that it never
happens that both are running on the same track section. The example is inspired by the "Trains
and Tracks" specification in [13].
We can write several specifications of the system, namely rail_i_j, where i and j are
respectively the track section numbers where train_a and train_b enter the circular railway; here we
have chosen the case in which train_a enters section 0 and train_b enters section 4.
12
0
1
A_
2
5
3
4
B_
Fig. 7 The circular railway divided into 6 track sections.
To manage the accesses of trains to sections, a controller, TRACK_i (i = 0 .. 5), is introduced for
every track section, which signals the preceding track that a train has left, and asks the following
track permission to let a train enter (the operation means addition modulo 6):
TRACK_i = enter_i?: leave_i?: free_i: free_i 1?: TRACK_i
Terms A_0 and B_4 below represent the behaviour of train_a and train_b respectively. When specifying these terms we make use of recursive calls to processes TRAIN_k_i (k = a,b and i = 0..5)
which describe the behaviours of train_k in the track section i. The action k_moves_i represents
the access of train_k in section i while enter, leave and free are synchronization actions that
regulate the accesses to the track sections:
A_0 = enter_5: leave_5: free_5?: enter_0: TRAIN_a_0
B_4 = enter_3: leave_3: free_3?: enter_4: TRAIN_b_4
TRAIN_k_i = k_moves_i: leave_i: enter_i 1: TRAIN_k_i 1
The specification of the system, RAIL_0_4, is obtained composing the track controllers in parallel
with the behaviours of the two trains. Restrictions are placed on executable actions, in order to
allow a higher degree of synchronization among the components and to reflect the point of view of
an external observer (the only visible actions of the system are k_moves_i):
RAIL_0_4=(A_0//B_4//TRACK_0//TRACK_1//TRACK_2//TRACK_3//TRACK_4//TRACK_5)
\enter_0\enter_1\enter_2\enter_3\enter_4\enter_5\leave_0\leave_1\leave_2\leave_3
\leave_4\leave_5\free_0\free_1\free_2\free_3\free_4\free_5
We expect that it never happens that both trains are running on the same track section. For instance,
if there is the possibility that train_b moves into section 0 and then train_a moves into section 5
then train_a must wait that train_b moves into section 1 before that it can be possible for it to move
to the next track section, i. e. section 0.
13
0
1 B_
1
B_
0
2
A_
A_
2
5
5
3
3
4
4
Fig. 8 Before moving, train_a waits that train_b moves into section 1.
The desired requirement is expressed by the conjunction of the instances for i = 0 .. 5 of the
following ACTL formula:
∀G([b_moves_i 1][a_moves_i] ∀ [true {¬ a_moves_i 1}U{b_moves_i 2} true])
(1)
The ACTL formula (1) means "For any state, if train_b has moved into section i 1 and train_a into
section i, then train_a cannot move until train_b moves into section i 2".
Actually, the following formula is satisfied also by a railway in which no train is moving; we need
therefore to verify another set of formulae, instances of the ACTL formula (2) below for i = 0 .. 5,
expressing the requirement that trains do actually move:
∃F(<b_moves_i 1><a_moves_i>true),
(2)
i.e. "there exists a state where an observer can see train_b moving to section i 1 and then train_a
moving to section i".
In Appendix B, it is shown how satisfiability of instances of the formulae (1) and (2) is checked.
5. Conclusions
We have presented a uniform environment for the verification of logical and behavioural properties
of systems described by means of process algebras; both classes of properties are interpreted over a
single model, namely Labelled Transition Systems. The verification environment is the result of the
integration of two existing tools, the EMC model checker [10] and AUTO [12], by means of two
translation functions, one from Labelled Transition Systems to Kripke Structures, the other from
the logic ACTL to the logic CTL.
A work similar to ours in this respect is presented in [25]. There CTL is used as a logic for
Labelled Transition Systems but the satisfaction relation is substantially modified; a relativized
satisfaction relation <a, s> » ϕ is introduced instead of the relativized modality Xa ϕ. The
expressive power of the two languages is similar, but the satisfaction relation of ACTL is more
immediate. Besides, in [25] invisible actions are not considered and we have not yet seen a
generalization of their approach to systems with silent steps in a way that would preserve some
behavioural equivalence. Also a different translation from Labelled Transition Systems to Kripke
Structures is used that is not linear with the number of transitions of the original transition system.
14
Another related approach is to interpret the logic over more complex structures, which integrate
the features of Labelled Transition Systems and of Kripke Structures, since they have labels on
both states and transitions [2, 31].
We see our tool as an experiment and as a mean for assessing the expressiveness of the
action based logic. In particular we consider that the approach of reusing existing tools has proven
effective for obtaining a rapid prototype environment. We have made, in this respect, some choices
on the component tools which need some motivations. EMC was chosen since we considered it as
the only established and widely used model checker. AUTO appeared, among the transition
systems generators available [4, 20, 33], as the most general one in terms of the accepted process
algebra (CCS, Meije and LOTOS). In general, we aimed at relying on widely used and
continuously upgraded tools, for which new research is undertaken to deal with unsolved problem,
like that of state explosion and symbolic model checking [6].
Extensions of our environment are currently under study, and integration with other tools
will be considered. The first extension we will provide is the "counterexample" facility provided by
EMC for CTL formula. EMC, whenever a formula ϕ does not hold, produces a path in the model
which falsifies ϕ and generally provides useful information on how to modify the model to have
the formula satisfied. The direct correspondence between the Labelled Transition System and the
generated Kripke Structure, should allow us to easily determine the failing path in a Labelled
Transition System by analyzing the path provided by EMC for the generated Kripke Structure.
Acknowledgements
The first author would like to thank Frits Vaandrager for joint work and discussions on the topics
of the paper.
15
References
[1] D. Austry, G. Boudol: Algèbre de Processus et Synchronization. Theoretical Computer Science,
30, 1, pp. 91-131
[2] P. Azema, J. Lloret, F. Vernadat, Requirement Analysis for Communication Protocols,
Proceedings of the International Workshop on Automatic Verification Methods for Finite State
Systems, Grenoble, June 1989, Lecture Notes in Computer Science 407, pp.286-293.
[3] T. Bolognesi, E. Brinskma: Introduction to the ISO Specification Language LOTOS, Computer
Networks & ISDN Syst., 14, 1987, pp. 25-59.
[4] T. Bolognesi, M. Caneve: Squiggles: a Tool for the Analysis of LOTOS Specifications, in K.
Turner (ed.), Formal Description Techniques (Proceedings FORTE '88), North-Holland, 1989,
pp. 201-216.
[5] M.C. Browne, E.M. Clarke, O. Grümberg: Characterizing Finite Kripke Structures in Propositional
Temporal Logic. Theoretical Computer Science, 59 (1,2), 1988, pp. 115-131.
[6] J. R. Burch, E. M. Clarke, K. L. McMillan, D. L. Dill, J. Hwang: Symbolic Model Checking: 1020
states and beyond. Technical Report, Carnegie Mellon University, 1989.
[7] A. Boujani, S. Graf, J. Sifakis: A Logic for the Description of Behaviours and Properties of
Concurrent Systems. In Linear Time, Branching Time and Partial Order in Logics and Models
for Concurrency, (de Bakker, J., de Roever, P. and Rozenberg, G. eds.) Lecture Notes in
Computer Science 354, Springer-Verlag, 1989, pp. 398-410.
[8] J. Bradfield, C. Stirling: Verifying Temporal Properties of Processes. in Concur 90 (J. C. P.
Baeten, J. W. Klop, eds), Lecture Notes in Computer Science 458, Springer-Verlag, 1990, pp. 115125.
[9] J. C. M. Baeten, W. P. Weijland: Process Algebra. Cambridge University Press, 1990.
[10] E.M. Clarke, E.A. Emerson, A.P. Sistla: Automatic Verification of Finite State Concurrent
Systems using Temporal Logic Specifications. ACM Toplas, 8 (2), 1986, pp. 244-263.
[11] R. Cleaveland, J. Parrow, B. Steffen: The Concurrency Workbench. In Automatic Verification
Methods for Finite State Systems (J. Sifakis, ed.) Lecture Notes in Computer Science 407,
Springer-Verlag, 1990, pp. 24-37.
[12] R. de Simone, D. Vergamini: Aboard AUTO, I.N.R.I.A. Technical Report 111 (1990).
[13] R. De Nicola: Transition Systems and Testing Preorders: an Alternative to Petri Nets for System
Specifications. In Information Processing 86, (H. J. Kugler ed.), Elsevier Science Publishers B. V.
(North-Holland), pp.833-836.
[14] R. De Nicola, F. W. Vaandrager: Three Logics for Branching Bisimulations (Extended Abstract)
in LICS '90, Philadelphia, USA, June 1990, IEEE Computer Society Press, Los Alamitos, CA,
1990, pp. 118-129.
[15] R. De Nicola, F. W. Vaandrager: Action versus State based Logics for Transition Systems. In
Proceedings Ecole de Printemps on Semantics of Concurrency (I. Guessarian ed.), Lecture Notes
in Computer Science 469, 1990, pp. 407-419.
[16] E. A. Emerson, J. Y. Halpern: “Sometimes” and “Not Never” Revisited: on Branching Time
versus Linear Time Temporal Logic. Journal of ACM, 33 (1), 1986, pp. 151-178.
16
[17] E. A. Emerson, C. -L. Lei: Efficient Model Checking in Fragments of the Propositional MuCalculus. LICS, Cambridge, Mass., IEEE, 1986, pp. 267-276.
[18] E. A. Emerson, J. Srinivasan: Branching Time Temporal Logic. In Linear Time, Branching
Time and Partial Order in Logics and Models for Concurrency, (de Bakker, de Roever and
Rozenberg, eds.) Lecture Notes in Computer Science 354, Springer-Verlag, 1989, pp. 123-172.
[19] J. C. Godskesen, K. G. Larsen, M. Zeeberg: TAV Users Manual, Internal Report, Aalborg
University Center, Denmark, (1989).
[20] H. Garavel, J Sifakis: Compilation and Verification of LOTOS Specifications, in Protocol
Specification, Testing and Verification, X, (L. Logrippo, R.L. Probert, H. Ural eds.) North Holland
, 1990, pp. 379-394.
[21] M. Hennessy: An Algebraic Theory of Processes, MIT Press, Cambridge, 1988.
[22] M. Hennessy, R. Milner: Algebraic Laws for Nondeterminism and Concurrency. Journal of
ACM, 32 (1), 1985, pp. 137-161.
[23] C. A. R. Hoare: Communicating Sequential Processes. Prentice Hall International, London
1985.
[24] ISO - Information Processing Systems - Open System Interconnection, LOTOS, a Formal
Description Technique Based on the Temporal Ordering of Observational Behaviour, ISO 8807,
1988.
[25] B. Jonsson, A.H. Khan, J. Parrow: Implementing a model checking algorithm by adapting
existing automated tools. In Automatic Verification Methods for Finite State Systems (J. Sifakis,
ed.) Lecture Notes in Computer Science 407, Springer-Verlag, 1990, pp. 179-188.
[26] D. Kozen: Results on the Propositional µ-calculus, Theoretical Computer Science, 27 (2),1983,
pp.333-354.
[27] K. G. Larsen: Proof Systems for Satisfiability in Hennessy-Milner Logic with Recursion,
Theoretical Computer Science, 72 (2),1990, pp.265-288.
[28] R. Milner: Communication and Concurrency, Prentice Hall,1989.
[29] Z. Manna, A. Pnueli: The Anchored Version of the Temporal Framework, in Linear Time,
Branching Time and Partial Order in Logics and Models for Concurrency, (de Bakker, J., de
Roever, P. and Rozenberg, G. eds.) Lecture Notes in Computer Science 354, Springer-Verlag,
1989, pp.201-284.
[30] E. Madeleine, D. Vergamini: AUTO: A Verification Tool for Distributed Systems Using
Reduction of Finite Automata Networks, in S.T. Vuong (ed.), Formal Description Techniques, II
(Proceedings of FORTE '89), North-Holland, 1990, pp.61-66.
[31] J. L. Richier, C. Rodriguez, J. Sifakis, J. Voiron: AUTO: Verification in Xesar of the sliding
window protocol. In Harry Rudin and Colin H. West (eds.), in Proceedings 7th International
Symposium on Protocol Specification, Testing and Verification, (Zurich), IFIP/TC6, May 1987,
pp.235-250.
[32] C. Stirling: Temporal Logics for CCS, in Linear Time, Branching Time and Partial Order in
Logics and Models for Concurrency, (de Bakker, de Roever and Rozenberg, eds.) Lecture Notes
in Computer Science 354, Springer-Verlag, 1989, pp. 660-672.
[33] P. van Eijk: The Lotosphere Integrated Tool Environment LITE, in Proceedings 4 t h
17
International Conference on Formal Description Techniques (FORTE '91), Sidney, November
1991, North-Holland, pp. 473-476.
[34] R. J. van Glabbeek, W. P. Weijland: Branching Time and Abstraction in Bisimulation Semantics
(extended abstract). In Information Processing ’89 (G.X. Ritter, ed.), Elsevier Science Publishers
B.V. (North Holland), 1989, pp. 613-618.
18
Appendix A: Proof of consistency
Below, we show that the two translations T1 and T2 are in complete agreement, that is if
is a Labelled Transition System and j is an ACTL formula, then »j if and only if ( ) »
(j). We will denote by q» j (q» j)the satisfaction of the ACTL formula (CTL formula) j in
the state q of the LTS (in the state q of the KS ). With the shorter notation ρ < θ and ρ ≤ θ we
indicate that path θ is a proper suffix, respectively a suffix, of path ρ; also, with path (s) and
path (s) we denote the set of paths starting from s in the LTS
and in the KS respectively.
We stress here some facts about the model translation. Let = (Q, A, →, 0Q) be the LTS to
be translated and = (S, AP, , →', 0Q ) be
( ). First, every state in Q has a correspondent
state in S with the same name; moreover, in
only states corresponding to states in Q are labelled
with ¤. New states in
are created in correspondence of every observable transition and are
labelled with the action labelling the transition. It is worth noting that if the label (an action) of a
transition satisfies a given action formula χ then the correspondent state in
satisfies the
proposition χ.
Since ACTL allows the negation of formulae, in order to show that q » φ if and only if
q»
(φ) we only need to show that:
1) q » ¬φ if and only if q»
(¬φ)
and
2) q » φ implies q »
(φ).
Indeed, q » φ implies q »
(φ) and q » ¬φ holds if and only if q»
(¬φ); so we have that
q » ¬φ if and only if q ‰ φ if and only if q ‰
(φ) if and only if q »
(¬φ); then q ‰ φ
implies q‰
(φ).
Theorem: Let
= (Q, Aτ, →, 0Q) be an LTS, = (S, AP, , →', 0Q ) be
φ be an ACTL formula. Then q » φ if and only if q »
(φ).
Proof:
case φ = true
(true) = true.
We have always q » true and q » true.
( ) and q∈Q; let
case φ = ¬ φ'
(¬ φ') = ¬
(φ').
We have that q » ¬ φ ' if and only if q ‰ φ', if and only if, applying the inductive
hypothesis, q ‰
(φ'), if and only if q » ¬
(φ').
case φ = φ1 ∧ φ2
(φ1 ∧ φ2) =
(φ1) ∧
(φ2).
If q » φ1 ∧ φ2 then q » φ1 and q » φ2. Applying the inductive hypothesis, this implies that
q»
(φ1) and q »
(φ2) so q »
(φ1)∧
(φ2).
19
case φ = ∃Xτφ'
(∃Xτφ') = ⊥ ∧
(⊥ ∧
(φ'))
q» ∃Xτφ' means that there exists q'∈Q such that q−τ→q' and q' » φ'.
Following the model translation we have in : (q, q') ∈ →, ¤ ∈ (q) and ¤ ∈ (q'). By the
inductive hypothesis, q'»
(φ'), so q» ⊥∧
(⊥ ∧
(φ')).
case φ = ∃Xχφ'
(∃X χφ') =
(¬⊥ ∧ χ ∧
(
(φ')))
q» ∃Xχφ' if there exists q' ∈ Q such that q−a→q', a»χ and q'» φ'. In this case a new state
(q, a, q') in is created with a∈ ((q, a, q')), (q, (q, a, q')) ∈→' and ((q, a, q'), q')∈→'.
This implies that q »
(¬⊥ ∧ χ ∧
(
(φ'))).
case φ = ∃(φ1 χU φ1)
(∃(φ1 χU φ2))= (⊥ ∧
(φ2)) ∨ (((⊥ ∧
(φ1)) ∨ (¬⊥ ∧ χ)) (⊥ ∧
(φ2)))
q» ∃(φ1 χU φ2) means that q » φ2 or there exist states q0, .. , qn, with n≥1, such that q =
q0−α0→ .. −αn-1→qn, qn » φ2 and, for i = 0 .. n-1, αi = τ and qi » φ1 or αi » χ.
If q » φ2 then, by the inductive hypothesis, q »
(φ2) and so q » ⊥ ∧
(φ2).
Otherwise we have qn »
(φ2) and, for i = 0, .., n-1:
if αi = τ and qi » φ1 then ⊥ ∈ (qi) and, by the inductive hypothesis, qi »
(φ1);
if αi » χ then a new state (qi, αi, qi+1) is created in with αi ∈ ((q i, α i, qi+1 )), (qi, (qi,
α i, qi+1)) ∈ →' and ((qi, α i, qi+1), qi+1) ∈ →'.
Hence, q » (⊥ ∧
(φ2)) ∨ (((⊥ ∧
(φ1)) ∨ (¬⊥ ∧ χ)) (⊥ ∧
(φ2))).
case φ = ∃(φ1 χUχ' φ2)
(∃(φ1 χUχ' φ2)) = (((⊥ ∧
(φ1)) ∨ (¬⊥ ∧χ)) ((¬⊥ ∧ χ') ∧
(⊥ ∧
(φ2))))
q » ∃(φ1 χUχ' φ2) if there exist states q0, .. , qn (with n≥1), such that:
q = q0−α 0→ .. −αn-1→qn, q0 » φ 1, qn » φ 2, α n-1 » χ' and, if n≥2, then for i = 0 .. n-2:
αi » χ and qi+1 » φ1 or αi » χ. Hence, the path from q0 to qn in satisfies ((⊥ ∧ (φ1))
∨ (¬⊥ ∧χ)) ((¬⊥ ∧ χ') ∧
(⊥ ∧
(φ2)))
For the formulae with the ∀ quantificator the proof is similar.
20
Appendix B: An example session
In this section we give an example of the way our prototype tool works. A specification spec of a
system written in CCS/Meije0 is presented as input to AUTO, by means of the file of commands
spec.ec. AUTO produces the file spec.fc that contains the corresponding Labelled Transition
System in the fc-format (format commun). The verification phase starts at this point. Either within
AUTO with a comline command or outside it, our model checker for ACTL is called and given as
input the file spec.fc. The prototype performs the translation of spec.fc into spec.mc, producing
the Kripke Structure corresponding to the Labelled Transition System of spec, and calls EMC with
spec.mc as input file. EMC reads the Kripke Structure of spec.mc then prompts the user for a
logical formula; the ACTL formula given in input is translated by the logic translator into the
corresponding CTL formula before the EMC reads it. Then EMC checks the CTL formula on the
Kripke Structure, produces an answer, true or false, and prompts for another formula.
In the following, we show in more detail a verification session for the Railway example; in particular, we will check formulae (1) and (2) on the given specification, with i = 5. To do this, we
provide AUTO with the following input file, called example.ec that contains commands to parse
the processes component of the system and to build the corresponding Labelled Transition System:
parse track_0 =
let rec {TRACK_0 = enter_0?: leave_0?: free_0: free_1?:
parse track_1 =
let rec {TRACK_1 = enter_1?: leave_1?: free_1: free_2?:
parse track_2 =
let rec {TRACK_2 = enter_2?: leave_2?: free_2: free_3?:
parse track_3 =
let rec {TRACK_3 = enter_3?: leave_3?: free_3: free_4?:
parse track_4 =
let rec {TRACK_4 = enter_4?: leave_4?: free_4: free_5?:
parse track_5 =
let rec {TRACK_5 = enter_5?: leave_5?: free_5: free_0?:
parse train_a_0 =
let rec {
TRAIN_a_0 = a_moves_0: leave_0: enter_1: TRAIN_a_1 and
TRAIN_a_1 = a_moves_1: leave_1: enter_2: TRAIN_a_2 and
TRAIN_a_2 = a_moves_2: leave_2: enter_3: TRAIN_a_3 and
TRAIN_a_3 = a_moves_3: leave_3: enter_4: TRAIN_a_4 and
TRAIN_a_4 = a_moves_4: leave_4: enter_5: TRAIN_a_5 and
TRAIN_a_5 = a_moves_5: leave_5: enter_0: TRAIN_a_0
} in TRAIN_a_0;
parse train_b_4 =
let rec {
TRAIN_b_0 = b_moves_0: leave_0: enter_1: TRAIN_b_1 and
TRAIN_b_1 = b_moves_1: leave_1: enter_2: TRAIN_b_2 and
TRAIN_b_2 = b_moves_2: leave_2: enter_3: TRAIN_b_3 and
TRAIN_b_3 = b_moves_3: leave_3: enter_4: TRAIN_b_4 and
TRAIN_b_4 = b_moves_4: leave_4: enter_5: TRAIN_b_5 and
TRAIN_b_5 = b_moves_5: leave_5: enter_0: TRAIN_b_0
} in TRAIN_b_4;
21
TRACK_0} in TRACK_0;
TRACK_1} in TRACK_1;
TRACK_2} in TRACK_2;
TRACK_3} in TRACK_3;
TRACK_4} in TRACK_4;
TRACK_5} in TRACK_5;
parse a_0 = enter_5: leave_5: free_5?: enter_0: train_a_0;
parse b_4 = enter_3: leave_3: free_3?: enter_4: train_b_4;
parse track = track_0 // track_1 // track_2 // track_3 // track_4 // track_5;
parse rail_0_4 = (a_0 // b_4 // track)\enter_0\enter_1\enter_2
\enter_3\enter_4\enter_5\leave_0\leave_1\leave_2\leave_3
\leave_4\leave_5\free_0\free_1\free_2\free_3\free_4
\free_5;
set rail_aut = tta rail_0_4;
display rail_aut short;
write "rail_0_4" rail_aut fc;
The verification session, in which both AUTO and the model checker for ACTL are used, is
reported below.
ieipisa% auto
# we call AUTO #
AUTO
Version 2.1 (Feb 90)
@ load "flags";
@ load "example";
# "flags" contains commands to sets the variables #
# "example" contains the commands to create the LTS rail_aut #
....
# AUTO creates and analyzes the states of the LTS #
ANALYZING STATE 1348
CREATING STATE 1349
ANALYZING STATE 1349
CCS Parallel <-- (1350 3288 13)
rail_aut : Automaton
time = 89.10s
gc= 16
@ display rail_aut short;
size = 1350 states, 3288 transitions, 13 actions.
time = 0.24s
@ write "rail_0_4" rail_aut fc;
# AUTO writes the LTS in the fc_format #
(gc CONS 128k)
File rail_0_4.fc written.
# the file rail_0_4 contains the LTS in the fc_format #
time = 10.20s
gc= 1
@ file example.ec loaded.
time = 0.06s
@ end;;
# exit from AUTO #
Que Le-Lisp soit avec vous.
ieipisa%
These are the contents of file rail_0_4.fc created by AUTO:
% automate au format commun produit par auto %
automaton "rail_aut"
states 1350
initial 0
22
atoms 1363
0: "g184-g188-TRACK_0-TRACK_1-TRACK_2-TRACK_3-TRACK_4-TRACK_5"
# atoms table #
1: "g184-g187-TRACK_0-TRACK_1-TRACK_2-st1-TRACK_4-TRACK_5"
.....
1361: "b_moves_5"
1362: "tau"
state 0 name a0 trans 1
# states and transitions table #
0: a1362 -> 2 1 2
state 1 name a1 trans 1
0: a1362 -> 2 3 4
.....
state 1295 name a1295 trans 2
0: a1362 -> 1308
1: a1351 -> 1307
# end of file #
The file rail_0_4.mc contains the corresponding Kripke Structure that the model checker for
ACTL (VT) creates automatically when invoked with input rail_0_4.fc (in the implementation of
the translation functions we replace the symbol ⊥ with the string "fresh" for typesetting):
(setq nstates 1951)
# the first line specifies the number of the states #
(store (prop 1)'(fresh))
(store (suc 1)'(2 3))
# the propositions true in the state are specified #
# the successors of the state are specified #
...
(store (prop 1951)'(fresh))
(store (suc 1951)'(1951))
# end of file #
Finally, we show the model checking phase; the syntax of the ACTL formulae is altered for
typesettings problems; so, ~ replaces ¬, A replaces ∀, E replaces ∃, [ ϕ{χ}U{χ'} ϕ'] replaces (ϕ
χ U χ 'ϕ '), X{χ } replaces Xχ .
ieipisa% VT rail_0_4.fc
# VT calls the model translator that produces
the file rail_0_4.mc, then it calls the EMC #
CTL MODEL CHECKER (version A2.5)
Taking input from rail_0_4.mc...
|= AG([b_moves_0][a_moves_5]A[true {~ a_moves_0} U {b_moves_1} true]).
The equation is TRUE.
|= EF(<b_moves_0><a_moves_5>true).
The equation is TRUE.
|= .
# End of Session #
23