Model Checking Abstract State Machines
vorgelegt von
Diplom-Informatikerin
Kirsten Winter
aus Uelzen
Von der Fakult¨at IV - Elektrotechnik und Informatik
der Technischen Universit¨at Berlin
zur Erlangung des akademischen Grades
Doktor der Ingenieurwissenschaften
–Dr.-Ing.–
genehmigte Dissertation
Promotionsausschuß:
Vorsitzender: Prof. Dr.-Ing. G. Hommel
Berichter: Prof. Dr.-Ing. S. J¨ahnichen
Berichter: Prof. Dr. W. Reisig
Tag der wissenschaftlichen Aussprache: 17. Juli 2001
Berlin, 2001
D83
Acknowledgements
First of all, I would like to thank my supervisor Stefan J¨ahnichen who employed
me as a PhD student at GMD FIRST. His open and personal approach towards
his group strongly influenced my development from a student to a researcher. I
was given much scope in choosing my own direction for my PhD topic. Moreover,
the opportunity of working on other research projects encouraged me to consider
many areas of related work. My experience at GMD FIRST has provided me with
a broad background in the field of formal methods that will be useful in the future,
Iamsure.
Next, I would like to thank Wolfgang Reisig for spontaneously agreeing to be
my second supervisor. His discussions, often very critical, on drafts of this work
helped improve it alot. I very much appreciated the time he took with me to go
through his comments. Something one must learn when doing a PhD is to defend
their results. I guess, a big part of this I learned on the other side of the road, at
the Humboldt University.
Also, Egon B¨orger’s support has had a great impact on this thesis. He encour-
aged me to write my first publication which is, I believe, the most difficult one and
gave me many helpful corrections and much feedback on my first attempt at this
paper. While developing my ideas on model checking ASM, he encouraged me alot
by showing continuous interest in my results.
What is the use of a fully automatic model checker if it needs a manual trans-
formation of the models? Giuseppe Del Castillo encouraged me to think about
implementation. I was not always happy when fighting with the intricacies of ML
but in the end I am very grateful for this cooperation.
Sofiene Tahar earns my gratitude for his useful comments on my use of MDGs.
I hope to continue this cooperation in the future.
The research group of GMD and the Technical University Berlin in which I
“grew up” provided a nice atmosphere for discussions. I thank Jochen Burghardt,
Carsten S¨uhl, Florian Kamm¨uller, Steffen Helke, Thomas Santen, Matthias Anlauff
and Stephan Herrmann for their helpful comments and their personal support.
Especially, I would like to thank Stephan for his companionship through the first
years of my PhD.
Many thanks to Graeme Smith for fighting with the drafts and, as a consequence,
for giving me “lessons” in English writing. His sometimes differing point of view
led to many useful discussions on formal notations. Apart from this professional
support, I want to thank him for keeping me cheery through these last winter
months and for the bowls of pasta that ensured survival in the late working hours.
Finally, I would also like to thank my mother and my siblings for the love and
the sunshine they bring into my life.
Zusammenfassung
Abstract State Machines (ASM) ist eine formale Spezifikationssprache, die es er-
laubt, auf einem hohen Abstraktionsniveau zu modellieren. Sie ist gut geeignet f¨ur
verschiedenartigste Anwendungen. Computerbasierte Werkzeugunterst¨utzung ist
in Form von Editoren, Typecheckern und Simulatoren vorhanden. ASM ist außer-
dem in die Logiken zweier Theorembeweiser eingebettet worden, die interaktives
Beweisen unterst¨utzen.
Diese Dissertation hat zum Ziel, die vorhandene Werkzeugunterst¨utzung um
einen vollst¨andig automatisierten Ansatz zu erweitern, das sogenannte Modelcheck-
ing. Modelchecking ist die vollst¨andige Suche im Zustandsraum des zu untersuchen-
den Systemmodells. Die Algorithmen arbeiten automatisch und bed¨urfen keiner In-
teraktion mit dem Benutzer oder der Benutzerin. Als zentrale Werkzeugumgebung
wird die ASM Workbench verwendet, in die ein Modelchecker integriert wird. Diese
Werkzeugumgebung wird mit einer allgemeinen Schnittstelle in Form einer Zwis-
chensprache versehen. Diese allgemeine Schnittstelle dient als Grundlage zur An-
bindung verschiedener Modelchecker, die auf einfachen Transitionssystemen basieren.
Mit der Transformation der abstrakten Spezifikationssprache ASM in die sehr ein-
fachen Sprachen von vollautomatischen Werkzeugen schl¨agt diese Arbeit eine Br¨ucke
¨uber den tiefen Graben zwischen Modellierungssprachen, die auf hohem Niveau
beschreiben, und Werkzeugsprachen, die algorithmisch einfach zu behandeln sind.
Auf der Basis der allgemeinen Schnittstelle werden im Rahmen dieser Disserta-
tion zwei konkrete Schnittstellen entwickelt: von der ASM Workbench zum Mod-
elchecker SMV und zum MDG-Paket. Ersteres Werkzeug wird h¨aufig eingesetzt
und implementiert symbolisches Modelchecken f¨ur CTL-Formeln.
Die Anbindung zum Modelchecker SMV ist implementiert und zwei Fallstu-
dien wurden mittels der entwickelten Transformation und dem SMV Werkzeug un-
tersucht. Die Ergebnisse zeigen die Anwendbarkeit aber auch die Grenzen dieses
Ansatzes auf. Diese Grenzen motivieren die Entwicklung der zweiten Schnittstelle
zum MDG-Paket. Dieses Paket umfaßt die Basisfunktionalit¨at f¨ur symbolisches
Modelchecking auf der Grundlage von Multiway Decision Graphs (MDGs). Diese
Graphenstruktur erlaubt die Repr¨asentation von m¨oglicherweise unendlichen Tran-
sitionssystemen mit Hilfe von abstrakten Sorten und Funktionen. Sie bietet daher
ein einfaches Mittel, um die Abstraktion von Modellen zu unterst¨utzen. Außerdem
erlaubt dieser Ansatz, Annahmen ¨uber das zu untersuchende System und seine
Umgebung in temporaler Logik zu spezifizieren. Die resultierende logische Mod-
ellierung wird anschließend mit dem Systemmodell vereinigt und f¨uhrt zu einer
vollst¨andigeren Modellierung. Damit erweitert diese zweite Schnittstelle die Gren-
zen der vollautomatischen Analyse, die Modelchecking zur Verf¨ugung stellt.
Contents
1 Introduction 1
2 Abstract State Machines 7
2.1 Introduction:FormalismandMethodology............... 7
2.1.1 ASimpleExample........................ 8
2.1.2 General Practice for Modelling in ASM . . . . . . . . . . . . 10
2.2 TheASMLanguage ........................... 11
2.2.1 States ............................... 12
2.2.2 LocationsandUpdates...................... 16
2.2.3 TransitionRules ......................... 17
2.3 TheASMWorkbench .......................... 21
3 Model Checking: An Overview 23
3.1 Introduction................................ 23
3.2 TheOverallFramework ......................... 23
3.2.1 TheLogicalApproach...................... 24
3.2.2 ModelCheckingwithAutomata ................ 26
3.3 ModelCheckingforCTL ........................ 28
3.3.1 TheLogicCTL.......................... 28
3.3.2 ModelCheckingCTLFormulas................. 30
3.3.3 SymbolicModelChecking.................... 34
3.3.4 FairnessConstraints ....................... 36
3.4 ModelCheckingforLTL......................... 38
3.4.1 TheLogicLTL.......................... 38
3.4.2 ModelCheckingLTLFormulas................. 39
3.4.3 SymbolicModelCheckingforLTL ............... 44
3.5 Linear-TimeversusBranching-TimeLogic............... 45
3.5.1 ComplexityoftheAlgorithms.................. 45
3.5.2 ExpressivenessofTemporalLogics ............... 45
4 Decision Graphs 51
4.1 BinaryDecisionDiagrams........................ 51
4.1.1 AlgorithmsforROBDDs..................... 53
4.2 MultiwayDecisionGraphs........................ 55
4.2.1 TheLogic............................. 55
4.2.2 MultiwayDecisionGraphs.................... 57
4.2.3 OperationsonMDGs ...................... 58
5 Applying Model Checking to ASM 63
5.1 Modelling with Assumptions . . . . . . . . . . . . . . . . . . . . . . 65
5.1.1 Model Checking without Meeting the Assumptions . . . . . . 66
5.2 TransformationofASM ......................... 68
i
CONTENTS
5.2.1 TheTransformationAlgorithm................. 70
6 The SMV Model Checker 83
6.1 TheSMVTool .............................. 84
6.1.1 TheSMVLanguage ....................... 85
6.1.2 ASMversusSMVLanguage................... 86
6.2 TheTransformationintoSMV ..................... 87
6.2.1 MappingASMintoSMV .................... 87
7 Case Studies 93
7.1 TheFLASHCacheCoherenceProtocol ................ 93
7.1.1 TheProtocol ........................... 93
7.1.2 The ASM Model of the FLASH Protocol . . . . . . . . . . . 94
7.1.3 TheRefinedModeloftheProtocol............... 99
7.1.4 ModelCheckingtheFLASHModel............... 102
7.2 TheProductionCell ........................... 105
7.2.1 TheCaseStudy ......................... 105
7.2.2 The ASM Model of the Production Cell . . . . . . . . . . . . 106
7.2.3 TheEnvironmentAssumptions................. 108
7.2.4 Model Checking the Production Cell Model . . . . . . . . . . 110
7.2.5 Discussion............................. 113
8 The MDG-Package 115
8.1 InterfacingtheMDG-Package...................... 115
8.2 ASMversusMDG ............................ 116
8.3 GeneratingAbstraction ......................... 117
8.3.1 TheNon-TerminationProblem ................. 118
8.3.2 Automatic Support for the Generation . . . . . . . . . . . . . 120
8.3.3 ASimpleExample........................ 121
8.4 The Transformation of ASM into MDG . . . . . . . . . . . . . . . . 124
8.4.1 The Adapted Transformation into ASM-IL+.......... 124
8.4.2 ASM-IL+ModelsasDirectedFormulas ............ 129
8.4.3 Transformation of ASM-IL+intoMDGs............ 132
9 Conclusion 137
9.1 RelatedWork............................... 138
9.1.1 Model Checking Abstract State Machines . . . . . . . . . . . 139
9.1.2 AbstractionTechniques ..................... 139
9.2 DirectionsforFutureWork ....................... 141
A Appendix 143
A.1 FixpointCharacterisation ........................ 144
A.2 FLASHCacheCoherenceProtocol ................... 146
A.2.1 TheASM-SLCode........................ 146
A.2.2 TheCounterexamples ...................... 157
A.3 ProductionCell.............................. 164
A.3.1 TheASM-SLCode........................ 164
A.3.2 TheEnvironmentModel..................... 175
A.3.3 TheSafetyRequirements .................... 179
A.3.4 TheLivenessRequirements ................... 185
Bibliography 195
ii
Chapter 1
Introduction
Why use Formal Methods?
Information technology has had a growing market for many years. Since the situ-
ation in this market is very competitive, the development of computer systems is
forced to maximise productivity. In many cases, this is paid for with a decrease
in quality. Quality, however, is an essential economic factor whenever liability has
to be assumed by the producer. This is the case for hardware production where
a faulty chip that is launched can cause a huge financial loss for the producer, as
well as for safety-critical systems whose reliability has to be certified before use.
Software engineering methods, in general, aim to improve the quality of software
and system development. In particular, formal methods focus on reliability and
correctness of systems by using a mathematical framework.
The benefits of formal methods have been discussed many times in the literature.
Production costs can be decreased greatly if errors can be detected in an early phase
of design. Accidents, involving major damage and even loss of lives, can be avoided
if systems are working correctly. Nevertheless, the use of formal methods is limited
in practice since the tradeoff between productivity and reliability is still too large.
This work aims at improving the applicability of the formal approach.
Reliability of a system can be improved by modelling a design of the system
before implementing the code, validating its appropriateness and verifying its cor-
rectness. Validation is done with respect to given informal requirements of the sys-
tem. The designer or the user inspects if the model properly reflects the expected
behaviour of the system. Verification is done with respect to formal requirements
of the system. A formal requirement is a model of the system in a formal notation
described at some higher level. Being in a formal framework, verification can be
done using mathematical proofs.
Formal methods deal with modelling, validation and verification based on a
formal notation. The research in this area has developed on two different levels:
the language and the tool level, each of them with a particular focus.
The language level provides support for the user when modelling a system.
That is, formal languages aim to bridge the gap between the informal and formal
description. They have a precisely defined semantics in order to prevent ambiguities.
They should be simple to learn and use, should lead to understandable models that
allow inspection, and should be expressive enough for modelling various problems.
To treat large systems, structuring mechanisms should support the design of well-
structured systems. Additionally, abstraction or refinement techniques should be
available to support modelling on different levels of abstraction. At a high level of
abstraction, the model has reduced complexity because technical details of a possible
1
Chapter 1 Introduction
realisation are left open. The notion of high-level languages is used to distinguish
languages, capable of such high-level descriptions, from low-level languages such as
programming languages. Many formal languages exist that fulfil the given criteria
for suitable language support for modelling of large systems. One representative
among them is the notation of Abstract State Machines (ASM) that is introduced
in [Gur95, Gur97].
The tool level aims at tool support for the validation and verification tasks.
Validation can be supported by simulators and animators. Verification is facilitated
by theorem provers, proof checkers, model checkers, satisfiability checkers and so
on. Tool support is recommendable when bringing formal methods into practice
since many tasks can be facilitated by automatisation. Moreover, for the verification
task, a tool-driven proof is usually more reliable. Manual proofs may be less tedious
but they are often more error prone than mechanical proofs. Often, they are not
seen to be fully reliable. Wolper (in [Wol97]) even draws the line between “weak”
and “strong” formal methods according to the tool support provided for a given
language.
At both levels of formal methods development many useful results are avail-
able: there are adequate high-level languages for modelling and manual analysis,
and appropriate tools that facilitate the validation and verification tasks. In most
cases, however, there is a gap between the kinds of support: The more facilities a
language has, the more difficulties arising for the development of tools. The more
automatisation that is available, the lower the level of the corresponding modelling
language. There is a discrepancy between tools that are easy to use and languages
that nicely support the modelling task. In fact, support on both ends of the formal
methods spectrum is needed for them to be of practical relevance in the future. It
is necessary to bridge this gap and relate both issues, language support and tool
support. Basically, this is a transformation task that can be automated to a large
extent due to the formal semantical foundation. This work aims to contribute with
a solution for a particular formal language and a certain kind of tool support for
verification. The title “Model Checking Abstract State Machines” summarises our
goal.
Why use Abstract State Machines?
There are many formal specification languages that could be chosen for this work.
We choose ASM to make preliminary experiences for the following reasons.
ASM is used as a modelling language in a variety of domains, e.g., embedded
systems, protocols, hardware specifications, semantics of programming languages
(a bibliography is given at [Hug]). It has been used both in academic and industry
contexts. The wide group of users shows that there is interest in the language
and, consequently, there is an interest in tool support. In fact, we can point out
at least two research groups that are already using the results of this work (see
[SMT01, GR01]).
A second reason is that ASM models transition systems in a simple and uniform
fashion and give these transition systems an operational semantics. Many model
checkers that are available are based on transition systems. A transformation from
ASM into these transition-system-based model-checker languages can be done with-
out losing properties of the original model. At a first glance, model checking appears
to be a promising approach.
Why use Model Checking?
Verification tools can be classified into interactive and automatic tools. Theorem
provers, at the current state of art, are not fully automatic for their usual tasks.
2
Section 1.0
They are driven through user interaction. As a consequence, experts are needed that
are familiar with logic and the particular proof system that underlies the prover.
The proof task turns out to be very time and cost intensive if it can be completed
at all.
Model checking tools, in contrast, do not provide a proof of correctness but
rather execute an exhaustive search for errors in the state space of a model. It is an
exhaustive test over all possibilities. This search can be done fully automatically.
As a result, the user gets an answer that the checked requirement is either satisfied
in the model or violated and, in this case, an example shows in which situation the
violation may happen.
The process of searching a state space terminates only if this state space is finite.
It will terminate in a reasonable span of time if the state space is finite and also
small enough. Finiteness is a clear attribute. In contrast, the term “small enough”
is very vague. It describes a limit that is not fixed but can be pushed by either
optimising the model checking technique that is used or by “optimising” the model
by reducing the size of the treated state space.
For small systems, model checking is a “press-button” task that provides a result
almost for free: no expertise is needed, no user interaction is requested. This is very
appealing for industry.
What else to use?
At a first glance, the tradeoff between reliability provided by model checkers and
productivity appears acceptable. At a second glance, when actually using model
checking, it becomes more obvious that this technique cannot fully substitute the
technique of provers. Model checking is easy to apply only for systems with a small
state space. Experiences show that model checking is not applicable for usual size
models if complex data structures are involved. This drawback becomes particularly
visible when analysing software systems in contrast to hardware systems.
The verification task for software is two-folded: analysing the control flow and
analysing the data part. Often, the former task can be solved by a model checker
but the latter needs the generality of theorem provers. Therefore, the overall goal
for tool support is to exploit automatic techniques as far as possible and treat re-
maining proof tasks interactively if necessary. This framework of tool support needs
a methodology for separating control from data issues. To apply model checking, a
method is needed for filtering out the complex data parts of a model. One means
of achieving this is abstraction.
It is important to understand that this notion of abstraction aims at a state
space reduction. Modelling on a high level of abstraction, in contrast, aims to
reduce the size of the model in terms of its appearance. Abstract models in the
latter sense that appear simple to the user may actually involve an infinite state
space.
In the context of model checking, abstraction allows the developer to skip in-
formation that is not relevant to a particular requirement that is to be checked.
Abstracting from data that is irrelevant for the requirement results in a model
that is smaller in terms of its state space and a checking process that is less time
and space consuming. The problems are how to find out which information is not
needed for checking a particular requirement, how to derive an abstract model once
we have pointed out the irrelevant data, and how to proof that the abstract model
preserves the properties of the original model. If we get model checking results for
the abstract model what do they imply for the concrete model?
At this point, model checking turns out to be more complicated than a simple
“press-button” facility. Much research is currently investigating how abstraction
can be supported by tools in order to apply model checking to a wider range of
3
Chapter 1 Introduction
problems. The work in this thesis aims at exploiting one suggested approach for
deriving and checking abstract models.
Overview
According to the introduction so far, we want to provide ASM with a model checking
tool and extend the limits of this approach. This work has two foci: a transformation
of the high-level formal notation ASM into a lower-level language suitable for a
model checker, i.e., a general interface, and its extension to provide a means for
abstraction.
The thesis is divided into five parts:
i.) We describe the notation of ASM in Chapter 2. In order to give a first
impression, a small example is given in the beginning that shows what ASM
looks like. This is followed by the full definition of the syntax and semantics
of the formalism. In Section 2.3, we briefly describe the ASM Workbench (see
[Cas00]) which is the tool framework for ASM that we use as a core tool for
our interface.
ii.) We present the field of model checking in Chapter 3. The introduction of
this chapter starts with an overview of various techniques that are developed
in the last decade. Section 3.3 and 3.4 focus on two particular approaches
that we want to use for checking ASM: model checking of branching time
temporal logic and linear time temporal logic. The theory of these two model
checking approaches is recalled in detail here since its understanding allows
us to motivate the design decisions for the current and future development
of this work. In particular, Chapter 4 explains the data structure of decision
diagrams which are the backbone of the model checking tools we use.
iii.) Chapter 5 describes the core of this work: applying model checking to ASM.
In the first place, this chapter gives a general picture of how we think the
approach is useful in practice. This is followed by a discussion about problems
that arise in Section 5.1. Section 5.2 introduces the transformation algorithm
from the ASM specification language into an intermediate language. This
intermediate language provides a general interface to tools that are based on
transition systems. We give a proof of correctness of the transformation on
the basis of the ASM semantics given in Chapter 2.
iv.) The SMV tool ([McM93]) is a model checker that fits well into our framework,
because it is a tool that operates on a transition system. Chapter 6 gives a
short overview of the tool and its input language and presents the transforma-
tion from our intermediate language of ASM into the SMV input language.
In Chapter 7 we describe, with two case studies, how we can model check
ASM models by means of the SMV tool. Section 7.1 summarises our experi-
ences with the FLASH cache coherence protocol (c.f., [Hei95, KOH+94]). It
provides a nice example of a successful debugging process. The second case
study, the Production Cell (c.f., [LL95]), points out the limitations of the
SMV approach. This is described in Section 7.2. It is shown why embedded
systems, such as the Production Cell, cannot be handled properly by SMV.
v.) The experiences with the Production Cell motivate the development of an
interface to Multiway Decision Graphs (MDGs). The foundation of MDGs
and a basic functionality for MDG model checking has been developed at
the University of Montreal and Concordia University, Canada (see [CCL+97,
CZS+97]). MDGs provide a simple means for abstraction that can be nicely
exploited for ASM. Chapter 8 motivates this second interface in detail. In
4
Section 1.0
particular, Section 8.3 describes the notion of abstraction and how this notion
can be easily applied for abstracting ASM models. The central idea is to
introduce abstract sorts into the framework of ASM which can be done on
the syntactical level of the ASM language. This extension of the language
makes it necessary to extend the generic transformation algorithm from the
ASM language into the intermediate language. The extended transformation
is defined in Section 8.4. As a second step, this section describes the mapping
from the extended intermediate language into MDGs.
The outcome of this work is firstly an interface from the ASM Workbench to the
model checker SMV. The implementation is optimised and validated through our use
for the case studies that are described here. [SMT01] describes another application
of this interface for hardware verification. This first interface was developed in
cooperation with Giuseppe Del Castillo who developed the ASM Workbench. His
insights into the internals of the Workbench were essential for implementing the
interface.
Secondly, we provide an interface from the ASM Workbench to the MDG-
Package. Through this second interface we extend the limits of model checking
for ASM. We provide a simple means of generating an abstraction if the ASM
model is too complex. Our implementation generates Prolog code for producing
a representation of the ASM model which is suitable as input to a model checker
based on MDGs. The realisation of an MDG model checker tailored for ASM is
beyond the scope of this thesis but it is planned as future work in cooperation with
Concordia University.
5
Chapter 1 Introduction
6
Chapter 2
Abstract State Machines
2.1 Introduction: Formalism and Methodology
Abstract State Machines (ASM) ([Gur95], [Gur97]) are a means of formalising al-
gorithms or systems in a state-based way. With this notation we can formalise the
possible states and state transitions of the system. That is, we can express a system
structure as well as its dynamics within the same notational framework.
We use many-sorted first-order structures for describing the states of a system.
These structures consist of the universes (or domains), comprising the entities our
systems deals with, and declare functions over these universes (a simple example
is given in Section 2.1.1). Universes and functions comprise the state space.The
evaluation of functions depends on the current state if they are dynamic, i.e., a
current state is determined by its function values.
As the former name Evolving Algebras suggests, states may evolve over time.
That is, function values may change from one state to the next. We get a simple
notion of behaviour in terms of state sequences
A0
δ1
−→ A1
δ2
−→ A2
δ3
−→ ...
We call such a sequence a run of the (abstract state) machine with Aidenoting
possible states and δithe transitions between states.
To specify precisely the way a system may behave, i.e., its possible transitions,
we use the notion of transition rules within our ASM framework. Transition rules
specify possible state changes, i.e., transitions from one state to the next. Thus, a
transition rule specifies a set of pairs (Ai,A
i+1). It restricts the predecessor state
Aiimplicitly through a certain precondition, which is called a guard. If the guard
is satisfied in a state Ai, then the transition rule is applicable and will be fired.
The successor state Ai+1 is given in terms of changes on certain function values
with respect to the predecessor Ai. That is, we denote the change of particular
functions as updates and consider all other function values as unchanged (excluded
are external functions, which may change arbitrarily to model non-determinism or
inputs).
As ASM comprise states and state transitions, they can be viewed as a means
of describing labelled transition systems or temporal structures (i.e., Kripke struc-
tures) in an operational manner.
The description of states by means of many-sorted structures or algebras is used
in several specification methods. However, describing dynamics of a system by
means of a set of transition rules is particular to ASM although we may find similar
approaches in [GR97] and [CH85], where a notion for state transitions is attached
to an algebraic method. In contrast to those approaches, ASM are much easier to
7
Chapter 2 Abstract State Machines
understand and can be used by engineers that are not familiar with algebra and
logic since the overall framework is kept much simpler.
In the following section, we present a very simple example in order to provide
the reader with a basic understanding of ASM. Some remarks about methodology
show how to use ASM for specifying more complex systems. The remainder of this
chapter gives the precise definition of the ASM formalism and describes briefly the
ASM Workbench as a tool framework for ASM in the end.
2.1.1 A Simple Example
The dining philosophers is a short, well-known example for a distributed system
of communicating processes. The situation to be modelled is the following: n
philosophers are sitting at a round table in front of a particular plate. Each of
them wants sometimes to think and sometimes to eat spaghetti. The restricted
resource in this situation is the set of forks: on the table are only as many forks as
philosophers. These forks are placed besides the plates. For eating every philosopher
takes the forks that are placed right and left to his or her plate. If two neighboured
philosophers want to eat they have a conflict over the shared fork (which is placed
left to the plate of one and right to plate of the other). Figure 2.1 sketches the
situation for five philosophers.
Figure 2.1: The table with five dining philosophers
The dining philosophers are an example for a distributed system with a bounded
resource that has to be shared by the contributing processes: the processes are the
philosophers, the bounded resource is the available forks for eating. We can model
the system of dining philosophers by means of a multi-agent ASM.
In multi-agent ASM, an agent describes a process, which is a philosopher in
the given example. Since every philosopher behaves in the same way, it is suitable
to model the behaviour generally by means of a set of transition rules which are
parameterised (see below, Figure 2.3). We use a variable Self as the parameter. In
our example, Self ranges over all philosophers.
Figure 2.2 shows the state space of our ASM model. The entities that may occur
are philosophers,forks,andthestatus of forks. We introduce three domains, where
the domains of philosophers and forks are parameterised by the same constant value
maxPhil indicating the number of contributing entities (e.g., five in Figure 2.1). The
domain BOOLEAN of Boolean values is implicitly included in every ASM specification.
Additionally, we introduce functions for modelling the situation as shown in
Figure 2.2. Some functions are static, i.e., these functions do not change their
values. For instance, each philosopher is associated with a particular left fork and a
particular right fork which cannot be changed. We model the association between
philosophers and forks as a mapping.
8
Introduction: Formalism and Methodology Section 2.1
static function maxPhil =5
PHILOSOPHER ={phil1,phil2,...,philmaxPhil }
FORK ={fork1,fork2,...,forkmaxPhil }
STATUS ={taken, released}
static function left fork :PHILOSOPHER →FORK
={phili7→ forki|1≤i≤maxPhil}
static function right fork :PHILOSOPHER →FORK
={phili7→ forkj|1≤i≤maxPhil,
j=(i+1)mod maxPhil}
dynamic function status :FORK →STATUS
initially {status(f)7→ released |f∈FORK}
dynamic function eating :PHILOSOPHER →BOOLEAN
initially {eating(p)7→ false |p∈PHILOSOPHER}
external function hungry :PHILOSOPHER →BOOLEAN
dependent function forks free(Self ):BOOLEAN
= status(left fork(Self )) = released
∧status(right fork(Self )) = released
Figure 2.2: Dining philosophers as ASM: domains and functions
Others functions are dynamic and can change their value during a run. For
instance, a philosopher may take a fork and start to eat or may release a fork and
stop eating. Thus, he or she will change the status of the corresponding forks and
will be eating or not eating. For the two corresponding dynamic functions status
and eating we define an initial mapping: status is initially released for each fork,
and eating is initially false for each philosopher.
Functions may also be external, i.e., they are a kind of oracle and their values
are determined by the outside world. For instance, whether a philosopher is hungry
or not is not controlled by our model.
A dependent function can be used as an abbreviation for a larger expression. In
our example, we use the functions forks free(Self) to abbreviate a boolean expression
for each philosopher that indicates if their left and right forks are free.
Based on the specified domains and functions, we can now describe the way a
philosopher behaves. The behaviour of each philosopher is given by a collection of
parameterised transition rules. The rules for our example are shown in Figure 2.3.
Whenever a philosopher feels hungry, he or she will check the status of his or her
left and right fork. If they are free then he or she can start to eat (first rule). If the
philosopher is not hungry anymore but still eating (i.e., he or she has taken both
forks) then the philosopher stops eating and should release the forks.
Note that in our model, the notion of the status of forks has to be a global
function, i.e., each philosopher can read and update a fork status. Otherwise a
philosopher could not check if the predicate forks free is true or not, and could not
change the status of a fork. In contrast to the function status, all other functions are
parameterised with the variable Self and are thus local for each philosopher. Local
functions are accessible only for the corresponding philosopher that is determined
by the value of Self. The notion of global functions contradicts the ideal of real
distributed processes. For modelling distributed philosophers that cannot share
9
Chapter 2 Abstract State Machines
if hungry(Self)
then if forks free(Self)
then status(left fork(Self)) : = taken
status(right fork(Self)) : = taken
eating(Self) : = true
if ¬hungry(Self)
then if eating(Self)
then eating(Self) : = false
status(left fork(Self)) : = released
status(right fork(Self)) : = released
Figure 2.3: Dining philosophers as ASM: the transition rules
functions, the ASM model needs to be refined. This refinement is, however, omitted
here.
A run of our system can be simulated by firing both transition rules simultane-
ously in the current state (starting with the initial state) until no state transition
is possible. Whenever the guards hungry and forks free,or¬hungry and eating are
true in a state, the three updates of the corresponding rule will change the function
values in one atomic step (i.e., simultaneously) and thereby define the next state.
In our example, the system runs forever since the values of external functions can
always change, and thus there is no final state. Generally, a run of an ASM is
defined over state changes that are caused by firing updates. The mere testing of
guards is not considered as an action.
In the next section, we explain the methodology of how ASM should be used
for modelling complex systems. In particular, we give a notion for modelling on
different levels of abstraction. This technique involves a stepwise refinement of the
model until the level of programming code is reached.
2.1.2 General Practice for Modelling in ASM
The small example in the last subsection provides a first impression of how ASM
models look. In this subsection, we point out some practical aspects of the ASM
approach in general.
ASM can be seen as a general purpose notation. It is suitable for various kinds
of systems in terms of the problem to be solved and also in terms of size (the broad
range in the literature shows this, see [Hug]). The ASM language is given in terms
of basic mathematic concepts: sets, functions, and some simple rule constructors.
Of course, this basic language can be extended for special purposes, however, the
intention is to keep it small. Also no proof system or calculus is prescribed.
Two major guidelines for using ASM as a specification language are mentioned
here as they have some impact on our work.
1. Model on a natural level of abstraction.
This advice recommends that the user focus on important parts of the system
that is to be modelled. The model should be as simple as possible for doc-
umenting well the speciality of the problem at hand. As a consequence, less
important details may be abstracted in the model for the benefit of conciseness
and readability. The influence of these abstracted details on the overall system
can be stated in a mathematical way by means of (formal or non-formal) as-
sumptions. Abstracting means introducing non-determinism into the model.
10
The ASM Language Section 2.2
Verification
Verification
Validation
Verification
ASM
0
ASM
1
ASM
2
Problem
refinement
steps
Implementation
...
several
Figure 2.4: Different levels of abstraction
In ASM, non-determinism can be introduced in two ways: using external
functions, which serve as oracles in that their value is determined through the
outer world rather than the system, or by using the choose rule, which spec-
ifies that a parameterised transition rule is fired for a non-deterministically
chosen instance of the parameter.
2. Prove the correctness of the system model in several steps.
Proving correctness of a system implementation against its specification, the
system model, usually addresses several features of the system. These features
provide a natural structure for the proof: We model the system on different
levels of abstraction, where each level is an extension or refinement of the
next upper level by means of an additional feature that is specified. We break
up the correctness proof into smaller steps by proving correctness between
models on each two adjacent levels of abstraction.
Both guidelines yield a set of ASM that are modelled on various levels of abstrac-
tion: on the topmost level, the model is close to the (often informal) description
of the system; the lower levels are more concrete, provide more and more informa-
tion about a possible realisation and may lead to an implementation of the system.
Figure 2.4 gives a sketch. The correctness of a resulting implementation can be
verified against the more abstract ASM models: Considering two adjacent models,
it has to be shown that the more concrete model “implements” the more abstract
model. The most abstract model on the topmost level cannot be proved to be
correct if the system description is informal. At this level we have to validate the
model. To support this validation, the model should be modelled in a succinct and
understandable way.
The notion of refinement that is used in the context of other specification lan-
guages is comparable to this approach. However, the ASM approach does not yet
provide a suitable set of refinement rules such as that introduced in [Mor94].
2.2 The Language of Abstract State Machines
After intuitively introducing the formalism and the general practice of ASM, we
now describe the theoretical framework, its syntax and semantics, in more detail.
11
Chapter 2 Abstract State Machines
We will follow the description given in [Gur95], [Gur97], [B¨or95] and [B¨or99], as well
as [LEW96] (as far as common algebra is considered). This section is subdivided
into definitions of states, locations, updates, and transition rules. The semantics of
ASM is based on transition rules. Its definition is given in the end of this section.
2.2.1 States
The states of ASM are given as many-sorted first-order structures (or many-sorted
algebras since we do not use relations in our signature). A structure is given with
respect to a signature, logical names, variables and terms. To these we add an
interpretation and a variable assignment. This allows evaluation of syntactical
entities to semantical values.
Signature, logical names, variables and terms
Firstly, we define the base of structures: signature,logical names,variables,and
terms.
Definition 2.1: Signature and Logical Names
A signature Σ is given as a pair (S, Ω), where S=(Si)i∈Idenotes a
set of sorts and Ω is a finite collection of function symbols, each with a
fixed arity, i.e.,
f:S1×S2×...S
k→Sn
where Si(1 ≤i≤k)andSnare sorts of the set of sorts S.We
call S1,...,S
kthe argument sorts and Snthe target sort of the k-ary
function. If k=0thenfis a nullary function name.
Logical names are semantically related to truth values. They comprise
the equality sign =, the constants true,false and undef ,andthesort
Boolean with its usual operators ¬,∨,∧.
Sorts in a signature are names; these names will be used for addressing sets (see
the definition of an algebra below). In the example of the last section (see Figure 2.2
on page 9) we use the names PHILOSOPHER,FORK,andSTATUS as sorts. They are
(in Figure 2.2) associated with sets. The function symbols are maxPhil,hungry,
left fork,right fork,status,eating,andforks free.
In [Gur97], the notion of vocabulary is used instead of a signature. A vocabulary
defines the same mathematical concept as a signature in a slightly different way:
A vocabulary γhas a finite set of function names corresponding to Ω. Instead of
sorts S, however, relational function names are used for describing sets by means
of characteristic functions. Moreover, the logical names are defined as being part
of the vocabulary.
In this work, we base our definitions on the notion of signature for two reasons:
First, having the notion of sorts (rather than characteristic functions) seems to be
easier to understand. Thinking in terms of sorts works toward the typed version of
ASM, ASM-SL, the language we are using within our tool-framework ASM Work-
bench (see Section 2.3). Secondly, it coincides with the given notion of first-order
logic within the MDG framework (see chapter 4.2). Defining syntax and semantics
with respect to sorts eases the definition of the MDG representation. The price we
have to pay is that we have to refer to sorts whenever functions are involved. For
our concerns, however, this seems to be reasonable to pay.
As common in algebraic specification languages, we use variables and terms over
the signature as mathematical objects of our structure.
12
The ASM Language Section 2.2
In an ASM specification a variable can occur for instance in the definition of
a dependent function, or a universe (defined as a set comprehension), or in the
transition rules. They are a means for parameterisation.
Definition 2.2: Variables
We associate with a signature Σ = (S, Ω) sets of variables of sort Si,
denoted by Vi. The entire set of used variables is V=(Vi)i∈I.
We suppose that each Viis sufficiently large to always provide “fresh” variables that
are different from all others, if necessary. With the definition of variables we can
define the notion of terms over a signature Σ.
Definition 2.3: Terms
Let Σ = (S, Ω) be a signature and V a set of variables for Σ. Terms
over all sorts in S, denoted by TΣ(V)=(TΣ(V),Si)Si∈Sare now defined
recursively, as in first-order logic
•every variable is a term, V⊆TΣ(V)
•if f∈Ω is a function symbol with arity f:S1×...S
k→Snand
t1,...t
kare terms of corresponding sorts, i.e., t1:S1,...,t
k:Sk
then f(t1,...,t
k)isaterm.
A term of sort Boolean is referred to as a boolean term.Weextendthe
definition of terms by first-order terms.
•if v:Viis a variable, and g(v)ands(v) are boolean terms then
(∀v:g(v)) s(v)
and (∃v:g(v)) s(v)
are terms, with head variable v,guard g(v)andbody s(v). As usual
we say that vis a bound variable in the term.
The set of variables occurring in a term tis denoted by Var(t). A ground term
denotes a term containing no variables, i.e., Var(t)=∅.
States
Now we define the notion of states of an ASM in terms of a many-sorted algebra
for Σ (following [Gur97]). We start with the definition of the latter.
Definition 2.4: Algebra
A many sorted algebra for the signature Σ = (S, Ω) is given by
•(carrier) sets SA
ifor each sort Si∈S
•an interpretation for each function symbol f:S1×S2×...×Sk→
Snin Ω given by a total function
fA:SA
1×SA
2×...×SA
k→SA
n
where SA
1×SA
2×...×SA
kis called the domain of the function,
dom(f), and SA
nthe range of the function, ran(f).
In an algebra, we interpret the logical names as distinguished elements. We do
not distinguish between the names and the truth values true and false,and=is
identified with the equality on a carrier set. The sort Boolean is interpreted as the
set of truth values.
13
Chapter 2 Abstract State Machines
Definition 2.5: State
Astate Ais a many sorted algebra as it is defined in (2.4).
In the context of ASM, a carrier set SA
iof a states Ais called a universe.We
denote with SAthe super-universe of a state. It contains the universes SA
iand also
new elements that are not contained in any of the universes; these new elements
comprise the reserve (see below); that is, SA⊃SiSA
i.
A state is implicitly given in an ASM model; it depends on the evaluation
of functions which can change from one state to another. For example, in the
dining philosophers (see Figure 2.2) we associate the sort PHILOSOPHER with the
universe {phil1,...,philmaxPhil }. The functions are declared as mappings over the
universes (e.g., eating :PHILOSOPHER →BOOLEAN). A particular state of the dining
philosophers is given as the current evaluation of all functions (e.g., eating can be
true in the considered state).
As states are mostly described in terms of functions, we distinguish different
kind of functions.
•Dynamic functions may change their interpretation during a run.
•Static functions have a fixed interpretation, they may be considered as con-
stants (of arbitrary but finite arity).
•External functions (or oracles) are a sort of dynamic functions but their in-
terpretation cannot be changed by the system itself but rather by the outer
world (the name ”oracle” indicates this difference quite well). They are a
perfect means to model reactive systems which are influenced by input or
environmental behaviour (as for instance, sensor values to be read by the
system).
•Dependent functions are defined in terms of other functions given in our struc-
ture. They can be seen as macros in order to shorten expressions.
•Relational functions are functions with target sort Boolean. Elsewhere de-
noted as characteristic functions, they are a means to describe sets. Syntac-
tically, however, relational functions are not distinguished from others.
Assignments and evaluation
Given an assignment for the variables, we can evaluate each term to its current
value. Variable assignment, function interpretation (as already given through the
notion of structure) and term evaluation forge links between syntax and semantics,
i.e., between structure and logics.
To provide terms with semantics, we need to assign values to variables first.
This is done by a mapping called variable assignment.
Definition 2.6: Variable Assignment
A variable assignment over a state Ais a function ζ:V→SAsuch that
variables of a particular sort Si∈Sare mapped to the corresponding
universe, ζ:Vi→SA
i.
Accordingly, a boolean variable v∈Vj(where Sj=Boolen)ismappedinto
Boolean ζ(v)∈{true,false}. Given a variable assignment we can define an ex-
panded state.
14
The ASM Language Section 2.2
Definition 2.7: Expanded State
Given a variable assignment ζover state A,wedenotethepairB=
(A, ζ)astheexpanded state.Ifζassigns the value a∈SAto the variable
vin a state Awe denote the partially expanded state as
B(v7→ a)=(A, ζ(v7→ a)).
A state Aand a term tare appropriate for each other if the signature of A
contains all function symbols occurring in tand Var (t) is included in the set of
variables of A.
Definition 2.8: Term Evaluation
Let B=(A, ζ)beanexpandedstateandtrange over terms appropriate
for state A, then the value Val
B(t)oftat state Ais defined as follows
•if the term is a variable t=v,thenVal
B(t)=ζ(v)
•if t=f(s1,...,s
k) then its value is given by induction over the
term structure
Val
B(t)=fA(Val
B(s1),...,Val
B(sk))
If the term tis a ground term, then Val B(t)=Val A(t).
The evaluation of first-order terms depends on the notion of satisfiability on
boolean terms. As logical names are given in algebra Aand the universe Boolean
is identified with the logical truth values, we can speak about evaluation of boolean
terms. If a boolean term evaluates to true in an expanded state B,thenwesayt
holds at Bor Bsatisfies t, denoted as B|=t.
The guard g(v) of a first-order term is a boolean term. Assume v:Vithen we
define the range of the guard as the set of satisfying variable assignments:
Definition 2.9: Range
RangeB(v:g(v)) = {a∈SA
i|B|=g(a)}
where g(a) denotes the term gin which each occurrence of variable vis
substituted by value a.
Now the evaluation of first-order terms can be defined in the following way:
Definition 2.10: Evaluation of first-order terms
Val
B(∀v:g(v)) s(v)=
true if Val
B(v7→a)(s(v)) = true
for all a∈RangeB(v:g(v))
false otherwise
Val
B(∃v:g(v)) s(v)=
true if Val
B(v7→a)(s(v)) = true
for some a∈RangeB(v:g(v))
false otherwise
Reserve
Some systems or programs introduce new elements during a computation. For
instance, new memory space may be allocated by a program. In order to provide a
state with new or fresh elements, we introduce the notion of the reserve of a state.
15
Chapter 2 Abstract State Machines
The reserve is infinite and contains all elements of SAthat are not contained
in any of the universes SA
i. Every function that is defined over Aand its universes
f:S1×...×Sk→Snwill accordingly evaluate to undef if any of its arguments
belongs to the reserve. No function may output an element of the reserve.
For the variable assignment ζ, we require that it does not map the same reserve
element rto different variables: ζ(v1)=ζ(v2)=r⇒v1=v2.
We call an entity aof Anon-reserve if a∈SA
ifor any universe SA
i⊂SA.
2.2.2 Locations and Updates
In ASM, states are described through functions and their current interpretation.
A state may change and transit to the next state by changing its function values
locally, i.e., at particular points. In order to capture this notion, we use locations
and updates of locations.
Definition 2.11: Location and its Value
Alocation of a state Ais a pair loc =(f,a)wherefis a symbol for a
dynamic function in Ω with f:S1×...×Sk→Snand ais a k-tuple
of elements of SAwith a:SA
1×...×SA
k.AnelementfA(a):Snis the
value of the location loc in the state A.
In a state A,eachtermf(t1,...,t
k), where fis dynamic, is associated with
a location f,Val
A(t1),...,Val
A(tk). That is, to determine the value of a lo-
cation we first have to evaluate the argument terms ti(1≤i≤k)tovalues
Val
A(ti)=ai∈SA
i. The resulting location (f,(a1,...,a
k)) is mapped to the value
fA(Val
A(tn)) = fA(an). Thus, we can describe any state by mappings of locations
to their (current) values in A, i.e., the current interpretation of fat ais denoted
as {(f,a)7→ fA(a)}.Thatis, (f,a) equals semantically fA(¯a) in state A.
For example, the model of the dining philosophers, given in the last subsection,
contains among others the locations status(fork1), status(fork2), eating(phil1),
eating(phil2).
For changing values of locations we use the notion of an update.
Definition 2.12: Updates
An update of state Ais a pair α=(loc,val)whereloc is a location of
sort Snand val, denoting the value, is an element of SA
nor undef .To
fire an update αat A,wesetval to be the new value of location loc and
redefine fto map loc to val. This redefinition causes Ato be changed.
The resulting state A0is a successor state of Awith respect to α.All
other locations in A0are unaffected and keep their value as in A.
Within a step from one state to the next state we can fire several updates.
Therefore we say more generally within a step from state Ato A0an update set is
fired at A. Firing an update set ∆ is firing each of its members δ∈∆simultaneously.
If we consider several updates to be fired at the same time, these updates need
to be consistent, that is, they should not affect the same location in a different way.
Definition 2.13: Consistency
For locations lociand locjin a state A, and the values valiand valj
in SAwe say the updates αi=(loci,val
i)andαj=(locj,val
j)are
consistent if and only if (loci=locj)⇒(vali=valj). An update set ∆
is consistent if no inconsistencies between its members occur.
16
The ASM Language Section 2.2
If we fire an inconsistent update set at A, it is defined in [Gur97] that none of
the updates should be fired and the state remains unchanged. Obviously, we cannot
assign two different values to the same location simultaneously.
Update sets are unambiguously determined by their function symbols and non-
reserve elements. Thus, we do not distinguish update sets which differ only in
the names of the contributing reserve elements. Two update sets are said to be
equivalent (and thus indistinguishable) if either both are inconsistent updates sets
or both are consistent and there is an automorphism πon the reserve elements
that maps one update set onto the other. ([Gur97] introduces equivalence classes
of update sets, called actions.)
2.2.3 Transition Rules
Transition rules are a means of specifying the behaviour of our system, i.e., the
possible changes from one state to the next. The syntax is given by atomic rules
for updating and rule constructors that allow for more complex specifications. The
semantics is described denotationally as introduced in the second part of this section.
Syntax of Transition Rules
The skip rule is the simplest transition rule. It is denoted as
skip (2.1)
This rule specifies an “empty step”. No function value is changed.
The update rule plays a central role for “evolving” states. It is an atomic rule
denoted as
f(t1,...,t
n):=t(2.2)
It describes the update, i.e., the change of interpretation of function fat the place
given by (t1,...,t
n) to the current value of t. Function fgiven by signature Σ is
called the head of the update rule with arity n.For1≤i≤n,tiand tare elements
of TΣ(V)and denote terms of the signature.
Aconditional rule is the most common means of specifying a precondition for
updating.
if g
then R1
else R2
endif
(2.3)
The guard gis a boolean term in TΣ(V), which we assume is decidable. R1and R2
denote arbitrary transition rules. If the guard evaluates to true then, obviously, R1
fires at the current state. Otherwise, choosing the else-case, R2is applied. We may
omit the else case in a conditional rule if R2is a skip rule.
Ablock rule groups a set of transition rules
block
R1
R2
...
endblock
(2.4)
17
Chapter 2 Abstract State Machines
The transition rules Rifor i≥1 are to be fired simultaneously. With a block
rule we construct the overall ASM program. All transition rules that specify the
behaviour of the machine are grouped into a block indicating that all of them are
fired simultaneously at each step.
The do-forall rule is a generalisation of a block rule
do forall v:g(v)
R0(v)
enddo
(2.5)
The head variable vdetermines the valuation of the boolean term g(v), the guard of
the rule. If g(v7→ a) is satisfied for some value ain the current state then transition
rule R0depending on afires. This constructor can be seen as a parametrisation of
conditional rules. It allows transition rules that have to be applied to a number of
elements to be shortened.
The choose rule is a rule for modelling non-determinism.
choose v:g(v)
R0(v)
endchoose
(2.6)
The rule R0is applied for some arbitrary value athat satisfies the guard g(v)in
the current state. The choice of the value among several possible elements is non-
deterministic. If no element satisfies the condition, the application of the choose
rule has no impact; it is an “empty step”.
The import rule is a means of extending the signature of our state.
import v
R0(v)
endimport
(2.7)
The variable vis assigned a “fresh” or new element that does not occur in any
of the sorts of the signature. (That is, the element is taken from the reserve, see
Section 2.2.1 on page 15.)
Note that without using an import rule, the state space of an ASM, given by all
universes, is fixed.
Semantics of Transition Rules
The semantics of a transition rule is given as a denotation. Since it depends on
the evaluation of terms at a current state, a denotation is a function that maps a
transition rule and an expanded state to an appropriate set of updates (see Defini-
tion 2.12 on page 16). For any transition rule Rand expanded state B=(A, ζ)the
denotation of Ron state Aand variable assignment ζis an update set denoted as
∆B(R).
We give a definition for ∆B(R) for each of the rule constructors introduced
syntactically above.
Skip rule: The “empty step” affects no updates, we get the empty set.
∆B(skip)={} (2.8)
18
The ASM Language Section 2.2
Update rule: Updating a single location is formalised as a singleton:
for any R≡f(t1,...,t
n):=t
∆B(R)={α}(2.9)
where α=(loc, val)isanupdate,
with loc =(f,(Val
B(t1),...,Val
B(tn)) denoting the location
and val =Val
B(t)itsnewvalue in expanded state B.
Conditional rule: The update set of a conditional rule depends on the evaluation
of the guard in the current state:
for any R≡if gthen R1else R2endif
∆B(R)= ∆B(R1)ifB|=g
∆B(R2) otherwise
(2.10)
Block rule: Within the block rule we are gathering sub-rules that have to be fired
simultaneously. This is formalised as a union of the update sets corresponding to
the sub-rules:
for any R≡block R1... R
nendblock
∆B(R)=∆
B(R1)∪...∪∆B(Rn)
(2.11)
Do-forall rule: Assume that R0(a) is a shorthand for rule R0(v) after substituting
all occurrences of variable vby the element a. The denotation of a do-forall rule is
given as the union of update sets for all sub-rules R0(a) for any value asuch that
g(a) is satisfied in the current state B. Accordingly it is said we apply R0(a)for
each value athat satisfies g(a) in the current state. With RG =RangeB(v:g(v)),
and B(v7→ a)=(A, ζ(v7→ a)) we get the following denotation:
for any R≡do forall v:g(v)R0(v)enddo
∆B(R)= S
a∈RG
∆B(v7→a)(R0(v)) (2.12)
Import rule: The semantics of an import rule with body R0is given by the
update set corresponding to R0(v) after substituting every occurrence of variable
vby some fresh element afrom reserve (i.e., SA\SiSA
i). Let B0=(A0,ζ), and
correspondingly B0(v7→ a)=(A0,ζ(v7→ a)), be the expanded state of a state
A0, where variable vis of sort Si, i.e., v∈Vi,andA0is the state we get from
Aby enlarging one of the universes SA
iwith a fresh element from reserve, i.e.,
SA0
i=SA
i∪{a}. This formalised as follows:
for any R≡import vR
0(v)endimport
∆B0(R)=∆
B0(v7→a)(R0(v))
for some a∈SA\SiSA
i
(2.13)
Since we do not distinguish update sets which differ only in the contributing
reserve elements (see Section 2.2.2 for the notion of equivalence of update sets) the
import rule is not considered to provide non-determinism. It makes no difference
which of the reserve elements ais taken to be imported.
19
Chapter 2 Abstract State Machines
In order to define the semantics for the choose rule we have to introduce a notion
that enables us to capture non-deterministic behaviour. Generally, non-determinism
can be formalised by a set of denotations rather then a single (thus determined)
denotation. If a set of update sets gives the denotational semantics of an ASM then
we can state that each member of this set describes a possible denotation. In order
to provide a common framework, we introduce a non-deterministic semantics for
each rule constructor, and add the denotation for the choose rule.
Non-deterministic Semantics of Transition Rules
The non-deterministic semantics for transition rules is given in terms of sets of
denotations, that is sets of update sets, denoted as NB(R) for an expanded state
B=(A, ζ)andruleR. They are defined for each rule constructor.
Skip rule, update rule: The semantics of skip and update rules is deterministic
and thus a singleton:
for any R≡skip or R≡f(t1,...,t
n):=t
NB(R)={∆B(R)}(2.14)
Conditional rule: The non-deterministic semantics of conditional rule is just
reducible to the semantics of its sub-rules:
for any R≡if gthen R1else R2endif
NB(R)= NB(R1)ifB|=g
NB(R2) otherwise
(2.15)
Block rule: The semantics of block rules is the set of unions of any members of
the non-deterministic denotations of the sub-rules:
for any R≡block R1... R
nendblock
NB(R)={∆B(R1)∪...∪∆B(Rn)|
∀i. 1≤i≤n, ∆B(Ri)∈N
B(Ri)}
(2.16)
Do-forall rule: The non-deterministic semantics of the do-forall rule is similarly
given by the set of unions of the non-deterministic denotations of the sub-rules. We
use R0(a) as a shorthand for rule R0(v) after substituting all occurrences of variable
vby the element aand RG for RangeB(v:g(v)). The non-deterministic semantics
is given as follows:
for any R≡do forall v:g(v)R0(v)enddo
NB(R)=setTuple(t)|t∈N
B(R0(a1)) ×...×N
B(R0(an))(2.17)
where {a1,...,a
n}=RangeB(v:g(v)), and setT uple(s1,...,s
n)=s1∪...∪sn,
i.e., any tuple (s1,...,s
n)ofsetssiis mapped by function setT uple to the union
of the sets si.
Import rule: The non-deterministic semantics of the import rule is similar to
the deterministic semantics. The import rule does not introduce non-determinism
by itself since update sets which differ only in the contributing reserve elements
20
The ASM Workbench Section 2.3
are considered as equivalent (see Section 2.2.2). Only the sub-rule R0may have a
non-deterministic semantics.
for any R≡import vR
0(v)endimport
NB0(R)=NB0(v7→a)(R0(v))
for some a∈SA\SiSA
i
(2.18)
Choose rule: The choose rule demands the non-deterministic choice of an
element a∈Athat satisfies guard g(v). After replacing all occurrences of variable
vin the state by element awe apply the denotation of body R0.
RG =RangeB(v:g(v)) is used as a shorthand:
for any R≡choose v:g(v)R0(v)endchoose
NB(R)= S
a∈RG
NB(v7→a)(R0(v)) (2.19)
Every element of NB(R) is a suitable denotation for R, i.e., acan be cho-
sen non-deterministically.IfRangeB(v:g(v)) = ∅then NB(R)={∅}.
2.3 The ASM Workbench
The ASM Workbench (ASM-WB), developed by Giuseppe Del Castillo (see
[Cas00]), provides a general framework for ASM tools. Due to the benefit of tool
support, Del Castillo extended the ASM language with a type system. The re-
sulting ASM specification language (ASM-SL) allows static analysis by means of
type checking. The kernel of the tool environment comprises basic functionality
for developing ASM-SL models: a parser for providing an internal representation
of the model data in abstract syntax, a type-checker for checking type correctness,
an interpreter for simulating and animating runs of ASM models. Figure 2.5 shows
ASM2SMV
Translator
ASM-SL Parser
Type Checker
Interpreter
ASM-SL
ASM-SL
SMV
Model Checker
Graphical
User Interface
Annotated AST
Abstract Syntax Tree (AST)
ASM-SL Specification
SMV System Specification
CTL Formulae
ASM-WB Kernel
(Code Generator) . . .
. . . . . .
Figure 2.5: The ASM Workbench
21
Chapter 2 Abstract State Machines
the raw architecture of the tool environment1. The grey part depicts the kernel.
Further basic functionality is given by a graphical interface for editing the model
and representing states and state changes.
The ASM-WB is designed as an open tool environment which is extensible. For
integrating other tools, transformation algorithms might be added that serve as
interfaces. Figure 2.5 suggests an interface to the model checker SMV ([McM93]),
called the “ASM2SMV Translator” here, or a possible interface for a code gener-
ator. The development of interfaces is supported by an exchange format given as
annotated abstract syntax trees (AST). The AST format is a textual representation
of the internal data representation that can be used as input for transformation
tools. The ASM-WB parser and its type checker provide a front-end for editing
and syntactically checking ASM models before they are treated by another external
tool.
In this thesis, we use the ASM-WB as a core tool framework. The contribution
of this thesis is two interfaces for supporting ASM with model checking tools: an
interface to the SMV tool, and an interface to the MDG-Package ([CZS+97]). The
former was developed in cooperation with Del Castillo.
In order to give a background to this work, we describe the theoretical framework
for model checking in the next chapter.
1This Figure originally appeared in [Cas00] and is reproduced here with the kind permission of
the author.
22
Chapter 3
Model Checking:
An Overview
3.1 Introduction
Generally, the verification of a program requires proving, in a rigorous or formal way,
that the program satisfies a specification. That is, verification involves comparing
two descriptions of what the program should do.
Traditionally, this is done by using logic as a formal framework for deductive
reasoning, which is, when tool supported, also referred to as theorem proving. First,
a general axiomatisation of the domain of interest (data structures of the program)
within the logic has to be developed. The program needs to be incorporated (or
translated) into the logic. Then we may try to prove the specification to be correct
(with respect to the program) by means of applying the precisely given deduction
rules of the axiomatic framework.
Model checking, in contrast to the traditional approach, is much simpler since it
does not aim at being fully general. It was initially restricted to finite state systems
and, although this limitation is no longer absolute, it is only applicable to system
whose states and state transitions have short and simple descriptions. Typically,
the intricacy of those systems resides more in the control than in the data as,
for example, in hardware descriptions, control systems, or concurrent protocols.
They are generally referred to as reactive systems. Their core functionality can be
described by sequences of possible interactions with the environment.
Due to the restriction to simple and finite systems, model checking is fully
algorithmic. It is an automatic machine-implemented approach that requires no
user interaction. Moreover, model checking provides explicit information about
possible erroneous behaviour of the system for which the checked property fails.
Given this, model checking can be viewed as an excellent debugging tool that checks
every possible behaviour.
3.2 The Overall Framework
Model checking has developed along two different major directions: the logical ap-
proach based on fixpoint computation, and the approach adopted from automata
theory which is based on proving language containment.
In this work we make use of fixpoint-based algorithms. Representative tools for
this direction are SMV ([McM93]), VIS ([Gro96]), SVE ([F+96]), and the MDG-
Package ([CZS+97]). We will start with an introduction of this logical approach.
23
Chapter 3 Model Checking: An Overview
Since some well known tools implement the algorithms of the automata the-
oretical approach (e.g., SPIN ([Hol97]), COSPAN ([HHK96]), and FDR ([For96,
Ros94])1), we will briefly explain the basic ideas behind this approach as well. This
is done in Subsection 3.2.2. The remaining part of this chapter, however, deals with
the logical approach based on fixpoint computations.
3.2.1 The Logical Approach
What we call the logical approach here comprises the algorithms based on fixpoint
computation. The requirements in this framework are given as temporal logic for-
mulas. In the following, the notion of structures and temporal logics is introduced,
and we formalise the model checking problem in most general terms.
The Underlying Principle
In general, a model checker checks that a given logical formula is satisfied on a
specific finite domain. That means, we are checking that the domain is a model of
the formula.
The finite domain is a program or a finite-state transition system. The logic
needs to provide formulas that can be directly evaluated on the transition system.
This is the case for propositional temporal logic. In classical propositional logic, the
truth value of a formula is computed according to the truth value of the involved
propositions, which are boolean variables. In addition to that, the world in temporal
logics has several possible states. Truth values of propositions are given with respect
to the state, and they may change as we move from one state to the next. Also
temporal operators are available that can express properties with respect to some
or all future states. We can identify these states with the system states (of the
finite domain) and the moves with the system’s state transitions. This way, progress
properties of a given system, such as safety and liveness, can be directly represented
in propositional temporal logic. Checking that the system satisfies a given temporal
property involves simply evaluating the temporal formula on the transition system.
The Transition System
The transition system to be model checked is non-deterministic. The non-
determinism may either be caused by an interleaving semantics of concurrent tran-
sitions or by absence of information about the behaviour of a system component or
the environment. If the system has inputs, all possible values of these inputs are
checked during the model checking process.
Most commonly, a transition system is defined as a temporal structure (or Kripke
structure). A temporal structure is given by a set of states, a transition relation
defined as pairs of states, and a function labelling each state with a set of proposi-
tions.
Definition 3.14: Temporal Structure
Atemporal structure M=(S, S0,R,L)comprises
i.) a set of states S
ii.) a set of initial states S0,whereS0⊆S
iii.) a transition relation R⊆S×S,
where ∀s∈S.∃s0∈S.(s, s0)∈R, i.e. Ris total
1The model checker FDR ([For96], [Ros94]) checks CSP processes by proving failures/divergence
refinement. Whilst the CSP processes are compiled into automata, the refinement relation turns
into a language containment relation on these automata.
24
The Overall Framework Section 3.2
iv.) a label function L:S→P(V),
where Vis the set of atomic propositions
(i.e., boolean variables expressing what is observable in a state).
Mis a finite transition system if the set of states Sis a finite set. A path of
a structure Mstarting at an initial state s0∈S0is an infinite sequence of states
s=s0s1s2... such that (si,s
i+1)∈Rfor all i≥0. With sk(given any k≥0), we
denote a suffix of a path sstarting at state sk, i.e., sk=sksk+1 ...
Generally, a temporal structure formalises the notion of branching time be-
haviour. A model of the structure comprises many infinite paths which reflect the
possibilities for the non-deterministic behaviour of the system. Unwinding these
paths, the model can be depicted as an infinite and acyclic computation tree.A
computation tree comprises nodes and edges. Each node is labelled by the label
function Lthat characterises sets of states. That is, each node represents a set
of states. The root node of a computation tree represents the set of initial states.
According to the given transition relation R, each node is connected via edges with
its successor nodes.
The Requirements
The property to be checked—also called the (requirement) specification —is a for-
mula in a temporal logic (branching time temporal logic or linear time temporal
logic) that specifies the required behaviour.
Such a temporal logic does not deal with time values explicitly or time intervals
but rather with the notion of sequences of states which describe possible compu-
tations (or behaviour) of the system. Their semantics is given with respect to a
temporal structure.
Since we want to treat non-deterministic systems (deterministic systems can be
validated by driving a simple test) we are dealing with behaviour that may evolve
in several different ways. That is, either each state may have multiple successors in
terms of a branching time, or behaviour is given as a set of various paths evolving
in linear time.
In branching time temporal logic multiplicity of behaviour can be specified ex-
plicitly by means of considering properties for all or some successor states. For
linear temporal logic this is expressed implicitly. The logic is designed to describe
linear sequences of states. A formula is satisfied in a linear temporal structure if all
paths that are a model of the structure satisfy the formula.
The Model Checking Problem
Let Mbe the given temporal structure, s∈Sa state in M,andϕa temporal logic
formula. Then a general formalisation of the model checking problem is introduced
as
M,s |=ϕ. (3.1)
If we identify swith an initial state s0∈S0we are checking if the system Mis a
model of the requirement ϕ.
The model checking approach depends on the logic used for the specification.
Each approach requires its own algorithm. Within the logic of branching time,
properties are related to sets of states. If we assume that Sis a finite set then
the corresponding domain P(S) (the power set of states) is a complete lattice.
Thus, fixpoint computations can be used as efficient algorithms for a state space
exploration in finite transition systems.
25
Chapter 3 Model Checking: An Overview
Formulas of a linear temporal logic are related to single paths. With a fixpoint
computation, however, only sets of satisfying states may be computed, but not
a path. Instead the notion of semantical tableaus is adapted for linear temporal
logics. Formulas can be represented in terms of a tableau, which is a special temporal
structure.
3.2.2 Model Checking with Automata
Within the automaton approach both the system model and the requirements are
given as finite automaton on words (ω-automaton). That is, both descriptions are
given in the same notation.
An ω-automaton is given as a five tuple (Σ,S,∆,S0,F), where Σ is a finite
alphabet, Sis the set of states, and S0⊂Sthe set of initial states, ∆ ⊆S×Σ×P(S)
the (non-deterministic) transition relation, and Fthe set of final states (see also
Chapter 4 in [vL90]).
Computations (or paths in the structure) can be given in terms of words over
the alphabet, w∈Σ∗. Thus, we can model requirements to be checked as a word.
Arun over a word w=a1a2... is a sequence of states s=s0s1... with s0∈S0
and si∈∆(si−1,a
i) for all 1 ≤i.
Since most reactive systems are designed for endless execution, the computations
have to be modelled as infinite paths. By replacing the set of final states Fwith
asetofaccepting states F0we are able to model infinite behaviour as well. An
infinite run s=s0s1s2... in an automaton Ais an accepting run if there is some
designated state that occurs infinitely often in the run. That is, for some s∈F0
there are infinitely many states siin ssuch that si=s. The infinite word wis
accepted if there is an accepting run of Aover w. The simplest automaton over
infinite words are B¨uchi automaton (see for instance [VW86]). Note that a temporal
structure as well as a temporal logic formula (over branching or linear time) can be
transformed into B¨uchi automaton.
Once both models, system and requirements, are given as automata, Aand A0,
solving the model checking problem can be done by checking language containment
of the automaton. The set of possible behaviours of the system is given as the set of
words accepted by the automaton, i.e., the language of the automaton L(A)⊆Σ∗.
The same holds for the requirement automaton A0.Language containment
L(A)⊆L(A0)
formalises2that every possible behaviour of the system (v∈L(A)) is suitable
according to the requirements (v∈L(A0)). That is, system Asatisfies the require-
ments A0.
If L(A0) denotes the complement of the required behaviour L(A0), then the
model checking problem is given as
L(A)∩L(A0)=∅
We prove that there is no behaviour of Athat is disallowed by A0. Following this
approach, firstly the complement automaton A0has to be constructed that accepts
L(A0). In a second step, Aand A0must be combined such that the resulting au-
tomaton accepts the intersection of L(A)andL(A0). If this intersection is empty,
then the specification A0holds for A. If the intersection is not empty, then the
requirements are violated and the elements of the intersection provide counterex-
amples.
2Note that the language of an automaton is never empty for that it contains at least the empty
word ε.
26
The Overall Framework Section 3.2
Based on this approach, Gerth, Peled, Vardi and Wolper ([GPVW95]) developed
an algorithm for checking path formulas of linear temporal logic. If the requirement
is given as a formula ψ, then the B¨uchi automaton for ¬ψis constructed. As
an example, the model checker SPIN ([Hol97]) processes requirements that are
specified as a temporal logic formula. The negated formula is transformed into the
corresponding automata. SPIN also allows representing requirements as automaton
that specifies the bad behaviour. It corresponds to the automaton A0.Thisway
the construction of the complement automaton can be avoided.
Within this work, the logical approach of fixpoint computation is used. We are
interested in model checking logics for branching as well as linear time, further on
called CTL model checking and LTL model checking, respectively. In Section 3.3
and Section 3.4, we introduce the logics and corresponding solutions for the model
checking problem by means of efficient algorithms. In Section 3.5, we compare both
logics by the complexity of the corresponding algorithms and their expressiveness.
27
Chapter 3 Model Checking: An Overview
3.3 Model Checking for Computation Tree Logic
In this section, the model checking algorithm for computation tree logic (CTL)
is introduced. The logic CTL, which is related to branching-time behaviour, is
defined in terms of its syntax and semantics. Model checking for branching time is
based on a fixpoint characterisation for this logic. We recall some details about the
underlying theory of fixpoints. Based on this theory, we give the characterisation
of CTL formulas and depict the notion for the model checking algorithm using it.
Symbolic model checking is an approach for reducing the necessary effort and
thus extend the limits of the explicit state space exploration. We show how to
adapt the algorithms for this more effective symbolic, i.e., implicit representation of
states. Conditional fairness, although necessary for proving liveness for distributed
systems, cannot be expressed within CTL logic (see Section 3.5.2). Thus, it is a
problem for CTL model checking to deal with fairness. This is addressed in the last
subsection. The results surveyed in this section are taken from the literature. We
refer to [CGL94], [CGP00], and [Kro98].
3.3.1 The Logic CTL
Syntax. We distinguish state formulas, expressing a property of a specific state,
and path formulas, modelling a proposition over a specific path. The set Vdenotes
the set of atomic propositions (i.e., boolean variables for characterising states). The
syntax of a CTL formula is given by the following rules.
Definition 3.15: Syntax of CTL
state formulas:
i.) If ϕ∈V,thenϕis a state formula.
ii.) If ϕand ψare state formulas, then ¬ϕand ϕ∨ψare state formulas.
iii.) If ϕis a path formula, then Eϕis a state formula.
path formulas:
i.) If ϕand ψare state formulas,
then Xϕand ϕUψare path formulas.
ii.) If ϕis a path formula, then ¬ϕis a path formula.
Roughly spoken, Eis an existential quantifier for paths, Xrefers to the next state,
and Uis an until operator for paths: ϕUψstates that ϕis true until ψgets true
which includes that this happens eventually. Some additional operators are used as
abbreviations:
ϕ∧ψ:⇔¬(¬ϕ∨¬ψ) the boolean operator and,
Fϕ:⇔(true Uϕ) the temporal operator for future,
Gϕ:⇔¬F¬ϕthe temporal operator for always,
Aϕ:⇔¬E¬ϕthe temporal path operator for all paths.
(3.2)
Since CTL expresses properties over a computation tree of branching time, we
are dealing with state formulas comprising the whole tree with all its possible paths
rather than dealing with path formulas reflecting properties over single paths (as
we do with LTL formulas). In CTL a state formula is not also a path formula (in
contrast to CTL* which comprises CTL and LTL, see Section 3.5). Thus, we cannot
combine the temporal operators arbitrarily: Eand Aare only allowed for prefixing
path formulas, whereas X,U,Fand Gare only allowed in combination with state
formulas. That is, the given definition of CTL syntax restricts the combination
28
Model Checking for CTL Section 3.3
of temporal operators such that the temporal operators X,U,Fand Gmust be
prefixed with one of the path operators Eor A. Thus, formulas of the form (Xϕ)
or (A(Xϕ∨Fψ)) are not allowed.
We get eight basic temporal operators that can be used in CTL: AX,EX,AG,
EG,AF,EF,AU,andEU. These are expressible with EX,EU,andEG only:
EF ϕ⇐⇒ E(trueUϕ)
AX ϕ⇐⇒ ¬ EX (¬ϕ)
AG ϕ⇐⇒ ¬ EF (¬ϕ)⇐⇒ ¬ (E(trueU¬ϕ))
AF ϕ⇐⇒ ¬ EG (¬ϕ)
A(ϕUψ)⇐⇒ ¬ E(¬ψU¬ϕ∧¬ψ)∧¬EG (¬ψ)
(3.3)
In the following we define the semantics for CTL formulas. In fact, only EX,EG,
and EU are sufficient as base operators if we follow (3.3).
Semantics. The semantics of a CTL formula is related to a temporal structure.
We specify a property of the corresponding computation tree by means of state
formulas that are related to the initial state. (Path formulas occur only as sub-
formulas in this context.) If ϕis a state formula then we say that ϕholds in a state
sof a temporal structure M, more formally: M,s |=ϕ. (The structure Mmight be
omitted if it is clear in a given context.)
Let ϕ,ϕ1and ϕ2be state formulas, and ψbe a path formula. (Recall that L(s)
is the set of labels of state s,andVis the set of atomic propositions.) Then we
define the satisfiability relation |= in the following way:
Definition 3.16: Semantics of CTL
s|=ϕ:⇔ϕ∈L(s),if ϕ∈V
s|=¬ϕ:⇔s6|=ϕ
s|=ϕ1∨ϕ2:⇔s|=ϕ1or s|=ϕ2
s|=EX ϕ:⇔
there is a path s, starting at state s,
such that s1is the next state in sand
s1|=ϕholds
s|=E(ϕ1Uϕ2):⇔
there is a path s, starting at state s,
such that there exists a k≥0, with sk|=ϕ2,
and for all 0 ≤j<k,sj|=ϕ1holds
s|=EG ϕ:⇔there is a path s, starting at state s,
such that for all k≥0, sk|=ϕholds.
We call a CTL state formula ϕvalid in a given temporal structure Mwith initial
state s0if M,s0|=ϕ.Wecallϕsatisfiable if there exists a structure Mwith initial
state s0such that M,s0|=ϕ.EachMthat satisfies ϕis called a model of ϕ.
Example 3.1:
•Safety: In each state, which can be reached, system crash never
holds (the bad thing will never occur).
AG (¬system crash)
•Liveness: All computation paths satisfy that if a request req is
given, then an acknowledgement ack will eventually occur
AG (req →AF ack)
or in each computation path a process is active infinitely often3.
AG (AF process active)
3In fact, this property can be seen as unconditional fairness which can be described in terms
of CTL operators. However, in many applications the fairness property is forced with respect to
some condition that has to be satisfied as well (see Section 3.5.2).
29
Chapter 3 Model Checking: An Overview
•Absence of Livelock: In every state there is a path on which
eventually the system is able to proceed. For instance, proceeding
may be specified as being able to read, i.e., readable is satisfied.
AG (EF readable)
•Inconsistency: Always (on every path in every state) False is
satisfied, i.e., there is no valid path in the given temporal structure.
AG False
3.3.2 Model Checking CTL Formulas
For any CTL formula it is possible to give a fixpoint characterisation. This is due
to the fact that CTL formulas are satisfied by a set of states (rather than paths).
Therefore the domain is P(S), which is a complete lattice. Thus, fixpoint theory
can be exploited for the model checking problem.
A simple recursive algorithm, the fixpoint computation, can be used to determine
all states of a given structure that are reachable by applying iteratively the transition
relation and that also satisfy the given CTL formula. The computation starts with
the set of states that satisfies the (innermost) atomic sub-formula which contains no
state and paths quantifiers. Once the set of satisfying reachable states is computed
it remains to show that the initial state of the structure s0is an element of this set.
If this is true, then the structure is a model of the CTL formula.
We start with some preliminaries of the underlying theory and the description of
the fixpoint characterisation of CTL formulas, and continue with the corresponding
algorithms for searching the state space. In order to improve efficiency of the model
checking procedure, symbolic model checking can be applied. This is a technique
that uses a particular data structure, known as binary decision diagrams, in or-
der to exploit their succint representation and the efficiency of the corresponding
algorithms.
Fixpoint Characterisation
Every temporal operator in CTL can be described as a fixpoint equation. This
characterisation yields the basis for the model checking algorithm used to check
CTL formulas.
Preliminaries. Generally, a fixpoint of a function f:A→Ais an element x∈A
that satisfies f(x)=x.IncaseAis a lattice and fis a monotonic function, then f
has a definite least fixpoint fpmin as well as a definite greatest fixpoint fpmax4.IfA
is a complete lattice (i.e., Ahas a lower and an upper bound) and fis continuous
then both extremal fixpoints can be characterised as the limit of applying fto the
supremum (the least upper bound) of the lattice, or its infimum (the greatest lower
bound). If we start with the supremum, the result will be the greatest fixpoint,
starting with the infimum we get the least fixpoint. In fact, these theoretical results
yield an algorithm for computing the fixpoints. Dealing with a finite lattice with
|A|=n, it can be shown that the procedure will terminate in at least nsteps.
Given the lattice of power sets over S,namelyP(S) with the ordering relation
⊆we get the entire set Sas its supremum, and ∅as its infimum. That is, the lattice
is complete and we can order the elements as ∅⊆S1⊆S2...⊆Swith Si∈P(S)
for all i. We call a function f:P(S)→P(S)
•monotonic if Si⊆Sjimplies f(Si)⊆f(Sj)
4We denote the fixpoints as functions with two arguments fpmin(x, f(x)) and fpmax(x, f(x)),
respectively, to indicate that they satisfy the equation x=f(x).
30
Model Checking for CTL Section 3.3
•∪-continuous if S1⊆S2... implies f(SiSi)=Si(f(Si))
•∩-continuous if S1⊇S2... implies f(TiSi)=Ti(f(Si))
Within a complete lattice, the monotonicity of a function fis equivalent to fbeing
∪-continuous and is also equivalent to fbeing ∩-continuous (see also [CGL94]).
Fixpoint Computation. If P(S) is a complete lattice and f:P(S)→P(S)is
∪-continuous (and therefore monotonic as well) then falways has a least fixpoint
that is computed by applying fiteratively on the infimum ∅, i.e.,
fpmin(Z, f(Z)) = [i(fi(∅)) (3.4)
If fis ∩-continuous it always has a greatest fixpoint that is computed by applying
fiteratively on the supremum S, i.e.,
fpmax(Z, f(Z)) = \i(fi(S)) (3.5)
These equations yield the basis for algorithmic determination. Two simple functions
least_fixpoint and greatest_fixpoint compute the extremal fixpoints:
funct least fixpoint f:P(S)→P(S):P(S);
begin
B:= ∅;
B0:= f(B);
while B6=B0do
begin
B:= B0;
B0:= f(B);
end;
return(B);
end.
The invariant of the while-loop in the body of the function is given by the
assertion [B0=f(B)] ∧[B0⊆fpmin(B,f(B))].
Obviously, at the beginning of the i-th iteration of the loop, B=fi−1(∅), and B0=
fi(∅). We get a sequence of ordered intermediate results ∅⊆f(∅)⊆f2(∅)⊆...
The maximum number of iterations before the while-loop terminates is bounded
by the number of elements in the set S. When the loop terminates we get as a
result B=f(B). In combination with the invariant of the loop, we conclude that
B=fpmin(B,f(B)), i.e., Bis the least fixpoint of function f. Analogously, we can
argue for the function greatest_fixpoint.
funct greatest fixpoint f:P(S)→P(S):P(S);
begin
B:= S;
B0:= f(B);
while B6=B0do
begin
B:= B0;
B0:= f(B);
end;
return(B);
end.
31
Chapter 3 Model Checking: An Overview
Fixpoint Characterisation Given a temporal structure M=(S, S0,R,L), we
identify every set of states Siof Mwith the predicates that are true in Si.Thus,
we get a lattice P(S)ofpredicatesoverSwith the set inclusion ⊆as its ordering
relation. P(S) is complete, the least element is ∅and the greatest element is S.
The basis of fixpoint characterisation is a function that maps sets of states onto set
of states, that is f:P(S)→P(S). We call fapredicate transformer.
For the fixpoint characterisation, we identify a CTL formula ϕwith the set of
those states, in which ϕis satisfied, i.e., {s|M,s |=ϕ}. Thus, we may apply a
temporal logic operator not only to a temporal formula but to a set as well. This
set, when being identified by a predicate, is an element of P(S). We may describe
each CTL operator in terms of a least or greatest fixpoint of an appropriate
predicate transformer over P(S) as follows:
A(ϕUψ)=fpmin(Z, ψ ∨(ϕ∧AX Z))
E(ϕUψ)=fpmin(Z, ψ ∨(ϕ∧EX Z))
AF ϕ=fpmin(Z, ϕ ∨AX Z)
EF ϕ=fpmin(Z, ϕ ∨EX Z)
AG ϕ=fpmax(Z, ϕ ∧AX Z)
EG ϕ=fpmax(Z, ϕ ∧EX Z)
(3.6)
The first parameter Zof fpmin and fpmax, respectively, denotes a set of states
and the second parameters provide the suitable predicate transformer fapplied
to Z, for the corresponding CTL formula. These predicate transformers map the
set Zto the union of the current states satisfying the involved predicates (given
by ψand ϕ) and the satisfying states reachable in the next step (as indicated by
the temporal operators AX and EX). This coincides with the notion of traversing
the transition system and collecting all states along the paths such that the CTL
formula is satisfied. When a fixpoint is found the search for all reachable states is
completed.
In order to prove these fixpoint equations, we show that the predicate trans-
formers are monotonic, and the given CTL formulas are exactly the minimal or
maximal fixpoints for the corresponding transformer. In the appendix, we give the
proof for EG ϕand A(ϕUψ) as examples (see appendix A.1). All other equations
can be proved analogously.
In order to show how the given fixpoint characterisations can be used for deter-
mining all states satisfying a certain CTL formula, we depict the following example.
Example 3.2: Given a temporal structure M(denoted as a graph
in figure 3.1) we want to check whether CTL formula φ=E(pUq)
is satisfied, i.e., M,s0|=E(pUq). E(pUq) is described as the least
fixpoint of the predicate transformer f(Z):=q∨(p∧EX Z). Using
the algorithm least_fixpoint, we can compute the set of states in M
satisfying φstarting the procedure with ∅. In the first iteration, we
get f(∅)=q∨(p∧EX ∅)=q. Thisequationissatisfiedbystates2
only (in figure 3.1 the states that yield a solution to the equation are
filled). In the second iteration, we have to solve f2(∅)=f({s2})=
q∨(p∧EX ({s2})) which obviously equals to the set {s2,s
1}.Inthe
third step, we find that f3(∅)={s2,s
1,s
0}which is the fixpoint since
f4(∅)=f3(∅) yields the last iteration of the loop.
Model Checking Algorithm
If a temporal structure Mand a requirement specification in terms of a CTL formula
ϕis given then model checking involves finding all states in the set of (reachable)
32
Model Checking for CTL Section 3.3
s2
s3
s0
s1p
p
qs2
s3
s0
s1
000
000
000
000
000
000
111
111
111
111
111
111
p
p
q
s2
s3
s0
s1
000
000
000
000
000
000
000
111
111
111
111
111
111
111
0000
0000
0000
0000
0000
0000
0000
1111
1111
1111
1111
1111
1111
1111
p
p
qs2
s3
s0
s1
000
000
000
000
000
000
000
111
111
111
111
111
111
111
000
000
000
000
000
000
000
111
111
111
111
111
111
111
0000
0000
0000
0000
0000
0000
0000
1111
1111
1111
1111
1111
1111
1111
p
p
q
0
temporal structure M, f ( ) 1
first iteration, f ( )
2
second iteration, f ( ) 3
least fixpoint, f ( )
Figure 3.1: Computing the set of states satisfying E(pUq)
states of the structure that satisfy the requirement. The set of satisfying states is
denoted as Sat(ϕ)={s|M,s |=ϕ}. Formally, the model checking problem is
given as
M,s0|=ϕ. (3.7)
That is, for solving the model checking problem, we have to prove that the initial
state s0is an element of Sat(ϕ).
For simple CTL formulas, we showed above how to compute Sat(ϕ)bymeans
of fixpoint computation. For more complex formulas, we rely on their semantical
definition (following the definition 3.16 of |=): We first compute the set Sat(ϕi)for
all sub-formulas ϕi. Then these sets are combined corresponding to the semantics of
the original complex formula. Thus, it suffices to know the definition of Sat applied
to the basic CTL formulas.
We define Sat(ϕ) as the set of states satisfying ϕmore accurately as follows
(recalling that L(s)isthesetoflabelsofstates,andVis the set of atomic propo-
sitions):
Definition 3.17: Satisfying States
Sat(ϕ):={s|ϕ∈L(s)},ifϕ∈V
Sat(¬ϕ):={s|S\Sat(ϕ)}
Sat(ϕi∨ϕj):=Sat(ϕi)∪Sat(ϕj)
Sat(EX ϕ):={s|∃s0.(s0∈Sat(ϕ)) ∧(s, s0)∈R}
Sat(E(ϕiUϕj)) := fpmin(Z, ϕi∨(ϕj∧EX Z))
Sat(EG ϕ):=fpmax(Z, ϕi∧EX Z)
Following this definition, the necessary basic operations for a model checking
algorithm for CTL formulas are:
•evaluation of label L(s) for the variables occurring in ϕ
•set theoretic operations like \or ∪
•evaluation of the transition relation R
•fixpoint computation for the temporal operators EU and EG .
33
Chapter 3 Model Checking: An Overview
According to the equivalences given in (3.3), all other temporal operators can
be expressed in terms of the operators occurring in definition 3.17.
This notion of a checking procedure describes ordinary model checking of CTL
formulas on the basis of temporal branching-time structures. In the following sec-
tion, we introduce the notion of symbolic model checking, which is a special kind
of a checking procedure exploiting the efficiency of algorithms on binary decision
diagrams.
3.3.3 Symbolic Model Checking
The complexity of the ordinary model checking algorithm for CTL is linear in size
of the computation graph of the structure and linear in size of the CTL formula
to be checked. The algorithm is shown to be quite fast in practice. However, the
number of states may explode when dealing with concurrent systems. Often model
checking is not feasible for this reason. In some cases, we can diminish the state
explosion problem by using a symbolic representation. In this approach, the limiting
factor for the model checking problem is not the state space anymore but rather
determined by the size of the implicit or symbolic representation of the computation
graph, which may be much smaller. (Unfortunately, this does not hold for every
problem as, for example, shown in [Bry86]).
For a symbolic representation, a state of the structure is encoded as a bit vector
~s :Bn, and the transition relation as a function over pairs of bit vectors accordingly
R:(Bn×Bn)→B(see [BCM+92]). The atomic propositions of Vgive the boolean
state variables sithat characterise a state. Thus, all variables in Vconstitute a
state vector ~s of length n=|V|. As usual, we identify sets of states Siand the
corresponding characterising function Φ : Bn→BsuchthatΦistrueifandonly
if s∈Si. The boolean functions Rand Φ can be represented by means of reduced
ordered binary decision diagrams (ROBDDs), which yields a concise canonical rep-
resentation (for more details about ROBDDs see Section 4.1).
Thus, the notion of symbolic computation is related to the use of an implicit
representation of states and transitions, as those being characterised by the corre-
sponding evaluation of state variables in V. In order to compute Sat(ϕ)bythemain
steps in definition 3.17, we can use very efficient algorithms for computing boolean
operations on ROBDDs. In the following the adapted model checking algorithms
are introduced.
Again, the goal is to find all those states that satisfy a given CTL formula ϕ,
that is Sat(ϕ). To compute this set of states, we use a procedure Check applied to
parameter ϕ. The resulting set of states is characterised by the boolean function
Φ(~s ) (i.e., Φ is the characteristic function of Sat(ϕ)). We get the following equation:
Sat(ϕ)=Check(ϕ)=Φ(~s ) (3.8)
.
We compute the set inductively over the structure of the formula. Since we
are dealing with characteristic functions, only boolean operators are necessary for
simple formulas:
Check(ϕ):=Φ(~s )
Check(¬ϕ):=¬Check(ϕ)
Check(ϕ∨ψ):=Check(ϕ)∨Check(ψ)
(3.9)
For more complex formulas we introduce special procedures, namely CheckEX,
CheckEU,andCheckEG. Following the equivalences given in (3.3) these are sufficient
for treating every CTL operator.
34
Model Checking for CTL Section 3.3
•For the next operator EX (ϕ) we have to find all those preceding states
for which one of the successor states satisfies ϕ. With Check(EX ϕ)=
CheckEX(Check(ϕ)) = CheckEX(Φ(~s )) we get5
CheckEX(Φ(~s )) := (∃~s 0.(Φ(~s 0)∧R(~s, ~s0))) (3.10)
Since Φ(~s 0)aswellasR(~s, ~s0) are represented as ROBDDs we can exploit
the basic operations on OBDD structures. These are implemented as very
efficient algorithms. For computing the solution of equation (3.10) we use the
algorithm for relational product. This is explained in detail in Section 4.1.1
on page 53.
The procedures CheckEU,andCheckEG use additionally the algorithms for
fixpoint computation as introduced with the functions least fixpoint and
greatest fixpoint. Within both we have to search the entire state space.
•With the fixpoint characterisation in (3.6) and Check(E(ϕ1Uϕ2)) =
CheckEU(Check(ϕ1),Check(ϕ2)) = CheckEU(Φ1(~s ),Φ2(~s )) we get
CheckEU(Φ1(~s ),Φ2(~s )) :=
fpmin(Z(~s ),Φ2(~s )∨(Φ1(~s )∧CheckEX(Z(~s )))) (3.11)
Again, the parameters Φ1(~s )andΦ
2(~s ) are characteristic functions (i.e.,
boolean functions mapping Bn→B) that are internally represented as ROB-
DDs. The algorithm for computing the set CheckEU(Φ1(~s ),Φ2(~s )) is simply
a while loop, using only boolean operations on ROBDDs and the function for
computing CheckEX(Φ(~s )).
funct CheckEU (Φ1(~s ),Φ2(~s )) : Bn→B;
begin
B(~s ):=False;
B0(~s ):=Φ
2(~s );
while B(~s )6=B0(~s )do
begin
B(~s ):=B0(~s );
B0(~s ):=Φ
2(~s )∨(Φ1(~s )∧CheckEX(B(~s )));
end;
return(B(~s ));
end.
The intermediate set B(~s ) is initially False, which is the characteristic func-
tion for ∅.B0(~s ) is initially set to Φ2(~s ) which equals fpmin applied to False
in equation (3.11).
In the j-th iteration of the loop, Bjdetermines the set of states in which
a state sjis reachable in at most jsteps such that Φ2(~sj) is true (i.e., ϕ2
holds in state sj)andforallstatessiwith i<j(i.e., for all states before in
the path) Φ1(~si) is true (i.e., ϕ1holds in states si). This is exactly the set
of states satisfying “there is a path such that ϕ1holds until ϕ2is true” and
matches the semantics of the formula E(ϕ1Uϕ2)tobechecked.
5Usually Φ is not given in terms of primed variables. Therefore, in the literature Φ(~s 0)is
denoted as Φ(~s )|~s:=~s0which represents the term that results from renaming all occurrences of
unprimed variables in Φ(~s ) by their primed counterparts. We choose the different notation here
in order to ease the understanding.
35
Chapter 3 Model Checking: An Overview
•For the CTL operator EG , we get according to the fixpoint characterisation
in (3.6), and with Check(EG (ϕ)) = CheckEG(Check(ϕ)) = CheckEG(Φ(~s )),
the following equation
CheckEG(Φ(~s )) := fpmax(Z(~s ),Φ(~s )∧CheckEX(Z(~s ))) (3.12)
With the parameter Φ(~s ) represented as an ROBDD (as well as the interme-
diate results B(~s )), and the start value True representing the entire set of
states, we adapt the algorithm greatest fixpoint for computing the set of
all satisfying states.
funct CheckEG (Φ(~s )) : Bn→B;
begin
B(~s ):=True;
B0(~s ):=Φ(~s );
while B(~s )6=B0(~s )do
begin
B(~s ):=B0(~s );
B0(~s ):=Φ(~s )∧CheckEx(B(~s ));
end;
return(B(~s ));
end.
After the i-th iteration of the loop the function B(~s ) characterises the set
of states satisfying ϕin all states that are reachable in ior less steps. The
algorithm terminates if with each next step only those states are reachable
that are already part of the set, i.e., a fixpoint is reached.
3.3.4 Fairness Constraints
In concurrent systems, often the requirements are provable only under the assump-
tion of fairness. For example, the mutex-problem is solvable only if we are assuming
that the scheduling of the concurrent processes is fair in that none of the processes
is suspended forever (for a proof see [KW97]). That is, in order to prove liveness,
we have to restrict our attention to the fair behaviour of the scheduler.
Generally, fairness means that some properties, called fairness constraints,hold
infinitely often along all paths. Each path that satisfies these conditions is called a
fair path. (For a more elaborated introduction see 3.5.2). Since fairness itself is not
expressible directly in CTL logic (see also 3.5.2) but only the fairness constraints,
we have to extend the algorithms for CTL model checking. The goal is to filter the
set of all possible computations in order to exclude all unfair paths.
Let Ξ = {ξ1,...,ξ
n}be a set of fairness constraints that are given as CTL
formulas. As the set of states satisfying any constraint ξiis characterised by Sat(ξi),
the set of fair states satisfying the requirement ϕis given by Sat(ϕ, ξ1,...,ξ
n). The
extension of the checking algorithm is based on an extended fixpoint characterisation
for EG (ϕ), EX (ϕ), and E(ϕUψ). The following new procedures CheckEGFair,
CheckEXFair,andCheckEUFair are required.
1. CheckEGFair:
All states in Sat(EG ϕ, Ξ) have to satisfy two conditions:
– all states in Sat(EG ϕ, Ξ) have to satisfy ϕ,
i.e., Sat(EG ϕ, Ξ) ⊆Sat(EG ϕ)
36
Model Checking for CTL Section 3.3
– for all fairness constraints ξiand all states s∈Sat(EG ϕ, Ξ) there is a
path of length n≥1fromsto some state in Sat(EG ϕ, Ξ) satisfying ξi
such that all other states on the path satisfy ϕ, i.e., they are elements of
Sat(ϕ).
As a consequence of these conditions, we extend equation (3.12) to the fol-
lowing fixpoint equation for CheckEGFair:
CheckEGFair(Φ(~s ),Ξ) :=
fpmax Z, Φ(~s )∧Vn
i=1 CheckEXCheckEU(Φ(~s ),Z(~s )∧ξi(~s )) (3.13)
The fixpoint evaluation can be done in the same way as before except that
several nested fixpoint computations are necessary (inside the computation of
the until operator, see function CheckEU, 3.11 on page 35).
Checking EX ϕand E(ϕUψ) under fairness constraints is simpler if we compute
first of all the set of states of structure Mwhich are the initial states for the fair
paths. This can be done with the equation for CheckEGFair introduced above.
Sfair (Ξ) = CheckEGFair(True,Ξ) (3.14)
2. CheckEXFair:
The formula EX ϕunder fairness constraints Ξ is true in state sif and only if
there is a successor state s0with s0|=ϕand s0being the start of a fair path.
If the set of initial states of fair paths Sfair (Ξ) is already computed (given in
terms of the characteristic function), then we can reduce the algorithm to an
equation without fairness constraints:
CheckEXFair(Φ(~s ),Ξ) = CheckEX(Φ(~s )∧Sfair (Ξ)) (3.15)
3. CheckEUFair:
A similar argument holds for checking a formula E(ϕUψ) under fairness
constraints. Ψ(~s ) denotes the characteristic function for the set of states
satisfying ψ. By exploiting the set Sfair (Ξ) we can avoid dealing with the
fairness conditions ξiwhen processing the checking algorithm. We get
CheckEUFair(Φ(~s ),Ψ(~s ),Ξ) = CheckEU(Φ(~s ),Ψ(~s )∧Sfair (Ξ)) (3.16)
This completes the basic theory of model checking for CTL which we want to use
for analysing ASM models. However, our experiments, when treating case studies
(as given in Chapter 7), show the limitations of CTL model checking. We conclude
that the use of the linear time temporal logic LTL would nicely complement the CTL
approach. Therefore, we describe the theoretical background of model checking for
LTL in the next section. We focus here on one particular approach given in the
literature that allows the integration of LTL model checking into the framework of
CTL checking.
37
Chapter 3 Model Checking: An Overview
3.4 Model Checking for Linear-Temporal Logic
In this section, we consider the model checking problem for linear-temporal logic
(LTL). One basic approach for LTL model checking is the construction of a tableau
for the formula to be checked.
A tableau is a temporal structure that represents all models of the formula.
Thus, tableau construction provides a means for testing satisfiability of the formula.
For model checking a system Magainst its (temporal logic) requirements ϕ, we build
the composition of Mand the tableau of the formula Tϕ. The composition of M
and Tϕcontains all paths of the structure that are also paths in the tableau (see
the early work from Lichtenstein and Pnueli [LP85]).
Another approach for model checking LTL formulas was introduce by Vardi and
Wolper et.al.([VW86], [GPVW95]). Instead of constructing a tableau for the LTL
formula, their basic idea was to build an ω-automaton that accepts all models of
the formula. If the system description is given as an automaton as well, then model
checking can be done by checking language containment of both automaton (see
also the introduction in section 3.2.2).
Both approaches suffer from the exponential complexity caused by the con-
struction of the tableau and the ω-automaton, respectively. The construction is
exponential in the size of the formula. Since in many cases the formula for express-
ing the common requirements is not very long, these approaches may provide good
results as well but still, in the competition between CTL and LTL approaches, this
is the major drawback. (The comparison is discussed in more detail in section 3.5.)
Burch et.al.([BCM+92]) developed a symbolic algorithm for LTL model checking.
By slightly modifying the original tableau construction, a symbolic representation
with BDDs is rendered applicable. The approach attains additional reduction in
space and time for the construction and in some cases even for the size of the tableau
itself. This is also exploited in [CGH94] and [CGH97] in order to combine both CTL
and LTL model checking within one framework. The core checking algorithm is the
same as for CTL (as introduced in section 3.3).
In this section, we introduce the linear-temporal logic, its symbolic tableau con-
struction and the symbolic representation of tableaus. The outcome of this pro-
cedure can be treated by a fixpoint-based model checking algorithm. It benefits
from the more efficient representation, and aims at a combination of both logics
being used within one checking tool. We follow the description given in [CGL94],
[CGH97], and [CGP00].
3.4.1 The Logic LTL
Linear-temporal logic (LTL) is related to linear rather than branching time. Thus,
the semantics of the temporal operators is given in terms of a path rather than
a computation tree. Each state in a path has a unique successor state, i.e., the
transition relation of the corresponding temporal structure is a function. We recall
here only the basic operators for LTL, for more details see [Eme90].
Syntax. With Vas the set of atomic propositions (i.e., boolean variables for
characterising states in a structure) the syntax of an LTL formula is given by the
following rules.
Definition 3.18: Syntax of LTL
i.) If ϕ∈V,thenϕis a formula.
ii.) If ϕand ψare formulas, then ¬ϕand ϕ∨ψare formulas.
iii.) If ϕand ψare formulas, then ϕUψand Xϕare formulas.
38
Model Checking for LTL Section 3.4
Given these basic operators, we can create the usual operators of propositional
logic as well as the temporal operators Fand G:
Fϕ:⇔trueUϕ
Gϕ:⇔¬F¬ϕ(3.17)
In LTL logic, we do not distinguish between state and path formulas as in CTL
logic since all formulas are related to paths. This becomes more clear in the next
paragraph when defining the semantics.
Semantics. The semantics of LTL logic is related to a linear-temporal structure.
Each computation is given as a path with each state having a determined succes-
sor. The specified behaviour may comprise a set of those paths instead of being a
computation tree as in branching-time logic.
Given a linear structure Mas in definition 3.14, and a path s:= s0,s
1,s
2,...
in M, we define the relation |= in the following way. Let ϕ,ϕ1and ϕ2be path
formulas, and Lthe labelling function of M.
Definition 3.19: Semantics of LTL
s|=ϕ:⇔sis the first state of sand ϕ∈L(s), if ϕ∈V
s|=¬ϕ:⇔s6|=ϕ
s|=ϕ1∨ϕ2:⇔s|=ϕ1or s|=ϕ2
s|=Xϕ:⇔s1|=ϕ
s|=ϕ1Uϕ2:⇔there exists a k≥0 such that sk|=ϕ2
and for all 0 ≤j<k,sj|=ϕ1
We call an LTL formula ϕvalid in a given linear structure Mwith the path s
if M,s |=ϕ.Wecallϕsatisfiable if there exists a linear structure Mwith path s
such that M,s |=ϕ.EachMthat satisfies ϕis called a model of ϕ.
3.4.2 Model Checking LTL Formulas
We now consider the model checking problem for LTL. In order to check systems
that are given as temporal structures over branching time, we conceive each LTL
formula ϕas quantified over all paths, i.e., we are treating formulas of the form Aϕ.
In general, given a structure Mthe model checking problem is to find all states
s∈Ssuch that M,s |=Aϕ. According to the definition of Athis is equivalent
to M,s |=¬E¬ϕ. That is, it is sufficient to be able to check formulas of the form
Eϕ0. If we can find a witness for ¬ϕ, then obviously Aϕis not satisfied.
Since LTL formulas are paths formulas, the state-based approach of CTL check-
ing cannot be used here. Instead we construct a special temporal structure T, called
the tableau of ϕ.Tincludes every path that satisfies ϕ.BycomposingMand T
in a suitable way, we get a structure Pcomprising all paths that appear in both
structures. A state in Mwill satisfy Eϕif and only if it is the start of a path in
the composition structure P. That is, in order to check Eϕwe can simply apply
the CTL model checking procedure to the composed structure P.
Tableau Construction
Let Vϕbe the set of propositions occurring in ϕ. The tableau associated with
the formula ϕis a structure T=(ST,R
T,L
T), where STis the set of states, RT
the transition relation, and LTthe labelling function. Each state in a tableau T
39
Chapter 3 Model Checking: An Overview
is labelled with sets of elementary formulas el(ϕ). These are obtained from the
sub-formulas of ϕaccording to the following recursive definition.
el(ϕ1)={ϕ1}if ϕ1∈V
ϕ
el(¬ϕ1)=el(ϕ1)
el(ϕ1∨ϕ2)=el(ϕ1)∪el(ϕ2)
el(Xϕ1)=Xϕ1∪el(ϕ1)
el(ϕ1Uϕ2)=X(ϕ1Uϕ2)∪el(ϕ1)∪el(ϕ2)
(3.18)
That is, besides the atomic propositions we get the next-formulas Xϕand
X(ϕ1Uϕ2) as elementary formulas. For a symbolic representation, we simply have
to introduce additional boolean variables for these kind of elementary formulas.
The set of states in the tableau STis given as P(el(ϕ)). The labelling function
LTlabels each state with the set of atomic propositions contained in the state,
i.e., LT:ST→P(Vϕ). Now we have to conceive the transition relation RTsuch
that each elementary formula of a state is satisfied in that state. For this concern
the function SatTis defined that associates with each formula ϕthe set of satis-
fying states, SatT:ϕ→P(ST). This is defined recursively over the contributing
elementary formula ϕi.
SatT(ϕ1)={s|ϕ1∈s}where ϕ1∈el(ϕ)ands∈ST
SatT(¬ϕ1)={s|s/∈SatT(ϕ1)}
SatT(ϕ1∨ϕ2)=SatT(ϕ1)∪SatT(ϕ2)
SatT(ϕ1Uϕ2)=SatT(ϕ2)∪SatT(ϕ1)∩SatT(X(ϕ1Uϕ2))
(3.19)
Since the transition relation should preserve the truth value of the elementary
formulas in each state, the occurrence of next-formulas has to be reflected. That is, if
Xϕiis true in some state sthen all its successors s0should satisfy ϕi.Furthermore,
since we are dealing with LTL formulas (which are implicitly quantified over all
paths), if Xϕiis not in s,then¬Xϕiis in s,andno successor of sshould satisfy
ϕi. Following this intention, RTis defined as
RT(s, s0)= V
Xϕi∈el(ϕ)
s∈SatT(Xϕi)⇔s0∈SatT(ϕi)(3.20)
We give an example in order to illustrate the notion of tableaus.
Example 3.3: Consider the formula ϕ=aUb. The elementary
formulas are el(ϕ)={a, b, X(aUb)}. The states of Tare given as ST=
P(el(ϕ)). We get eight states, each of them labelled with a possible
subset of el(ϕ) as depicted in figure 3.2. Since el(ϕ) contains only one
sub-formula of the kind Xϕithe transition relation is given as
RT={(s, s0)|s∈SatT(X(aUb)) ⇔s0∈SatT(aUb)}with
SatT(X(aUb)) = {s1,s
2,s
3,s
5}and SatT(aUb)={s1,s
2,s
3,s
4,s
6}.
This gives us the first half of the state transitions. The corresponding
complements, the set ST\SatT(X(aUb)) = {s4,s
6,s
7,s
8}and the set
ST\SatT(aUb)={s5,s
7,s
8}provide the remaining transitions.
The given definition of RT(3.20) may lead to a tableau containing paths that
are not a model for the formula. This can happen for two reasons:
•Not every path in Tneeds to satisfy ϕ. If it contains sub-formulas of the form
(aUb)thenRTdoes not guarantee by definition that bwill eventually hold.
In figure 3.2, the path looping forever in state s3provides an example of this.
40
Model Checking for LTL Section 3.4
a b
X
(
a
U
b
)
b
X
(
a
U
b
)
a
X
(
a
U
b
)
a
b
X
(
a
U
b
)
a
b
s
6
s
1
s
2
s
3
s
4
s
5
s
7
s
8
Figure 3.2: Tableau for ϕ=aUb
•Tmay contain dead-end states that have no successor. For instance, there is
no successor for a state labelled with {a, Xa, X¬a}because aand ¬acannot
be satisfied simultaneously in any next state. Since the semantics for LTL
formulas is related to infinite paths, however, we may simply exclude the
finite paths by removing dead-end states without loss of satisfying paths.
For the guarantee that sub-formulas of the form aUbare satisfied, an additional
condition is necessary:
Let Tbe a tableau for the formula ϕ,ands=s0,s
1,s
2,... apathinT
with s0∈SatT(ϕ). Then swill satisfy ϕif and only if for every sub-
formula (aUb)ofϕand for every state siin sthe following condition
holds: if si∈SatT(aUb) then either si∈SatT(b)orthereisalater
state sjon path s(with j>i) such that sj∈SatT(b).
This condition can be re-formulated as the fairness constraint SatT(¬(aUb)∨b).
It specifies the states that either satisfy (aUb)andbas well, or the negation of
(aUb). In order to guarantee that bwill eventually occur, every path has to meet
these states infinitely often. This is the case for all paths that are fair with respect
to this fairness constraint. This will be reflected later in the checking procedure.
A key property of the construction is that for every path in the temporal struc-
ture (which models the system) that satisfies ϕ, there is a corresponding path in the
tableau of ϕ. To make the notion of “corresponding path” precise, a label function
on paths and their restriction is given.
Let s=s0,s
1,s
2,...be a path in the temporal structure Mwith atomic propo-
sitions VMand label function LMon its states. A labelling function on paths is
given by label(s)=LM(s0),L
M(s1),L
M(s2),... We may restrict the path labels
to atomic propositions contained in ϕ, denoted as Vϕ⊆V
M. Thisisdenotedas
label(s)Vϕ=L0
M(s0),L
0
M(s1),L
0
M(s2),... with L0
M(si)=LM(si)∩V
ϕfor every i.
Now, the core issue of tableau construction can be stated in the following way:
41
Chapter 3 Model Checking: An Overview
Theorem 3.1. Let Tbe the tableau for the LTL formula ϕ. Then for every temporal
structure Mand every path sin M,ifM,s |=ϕthen there is a path s0in Tthat
starts in a state s0∈SatT(ϕ)such that label(s)Vϕ=label(s0).
The proof is skipped here but can be found in [CGH97].
The Product Structure
Following theorem 3.1, a product structure of Mand the tableau T, which is con-
structed in a suitable way, will comprise the paths that are in Mand in T.That
is, the paths of Mthat satisfy ϕ.
Let M=(SM,R
M,L
M)andT=(ST,R
T,L
T) be the tableau for formula ϕ,
which contains the atomic propositions Vϕ. The product structure is built according
to the following definition:
Definition 3.20: Product Structure
The product structure P=(SP,R
P,T
P) consists of
•a set of states
SP={(p, q)|p∈ST,q∈SM,and LM(q)∩V
ϕ=LT(p)}
•the transition relation
RT={((p, q),(p0,q0)) |(p, p0)∈RTand (q,q0)∈RM}
•the labelling function
LP((p, q)) = LT(p)
Pmay have dead-end states and thus finite paths, even if the tableau Tcontains
none. On the other hand, Pcontains exactly the infinite paths s00 for which there
are infinite path s0in Tand sin Msuch that label(s00)=label(s0)=label(s)Vϕ.
Thus, with the same argument as for the tableau, we may remove the dead-end
states without losing satisfying paths since all models of ϕhave to be infinite.
We extend the function SatTto SatPsuch that for every state (p, q)∈SP,
(p, q)∈SatP(ϕ) holds if and only if p∈SatT(ϕ). We give an example for a prod-
uct structure.
Example 3.4: Consider the temporal structure given in figure 3.3
a
b
q
2
q
3
a
q
1
b
q
4
Figure 3.3: The structure M
Combining Mwith tableau Tfor ϕ=(aUb), as given in figure
3.2, we get the set of states SP={(s1,q
2),(s2,q
4),(s3,q
1),(s4,q
4),
42
Model Checking for LTL Section 3.4
(s5,q
3),(s6,q
2),(s7,q
1),(s8,q
3)}. The transition relation RPis depicted
in figure 3.4. For the states (s4,q
4)and(s8,q
3)wecanseethatthey
have no outgoing edges. These are dead-end states and can be deleted.
a
b
X
(
a
U
b
)
(
s
1
; q
2
)
a
b
(
s
6
; q
2
)
b
(
s
4
; q
4
)
X
(
a
U
b
)
(
s
5
; q
3
)
a
(
s
7
; q
1
)
(
s
8
; q
3
)
b
X
(
a
U
b
)
(
s
2
; q
4
)
a
X
(
a
U
b
)
(
s
3
; q
1
)
Figure 3.4: Product structure of Mand tableau T
Model Checking the Product Structure
Recall the model checking problem for LTL: Given a branching-time structure M
andanLTLformulaoftheformAψ, the model checking problem is stated as
M,s |=Aψ. For technical reasons, this is re-formulated according to the equiva-
lence (M,s |=Aψ)⇔(M,s |=¬E¬ψ). Thus, formulas of the form Eϕwith
ϕ=¬ψare investigated. If we can find a state that is the start of a path that
satisfies ϕ, then this state and the outgoing path will provide a counterexample for
Aψ. If we construct a product structure Pfrom the branching-time structure M
and the tableau Tϕ, then all path in Pare paths in Mand they also satisfy ϕ(see
definition 3.20).
According to the discussion in the last subsection, we have to consider fairness
constraints. We want to find all states in the product structure Pthat are the start
of an infinite fair path with respect to the fairness constraint below.
{SatP(¬(aUb)∨b)|(aUb) occurs in ϕ}(3.21)
This can be done by applying fair CTL model checking to Pwith the CTL formula
EG true and the fairness constraints as given above. We will get all states of Pthat
are the start of an infinite path with the property that for every sub-formula (aUb)
it is guaranteed that bwill be eventually true. This is summarised in theorem 3.2.
Theorem 3.2. M,s0|=Eϕif and only if there is a state s∈Tsuch that (s, s0)∈
SatP(ϕ)and P, (s, s0)|=EG true under fairness constraints {SatP(¬(aUb)∨b)|
(aUb)occurs in ϕ}.
Again, the proof is skipped here; the reader is referred to [CGH97].
43
Chapter 3 Model Checking: An Overview
In our example above, it is easy to see that in the structure P
(as shown in figure 3.4) the fairness constraint is fulfilled for the states
{(s1,q
2),(s2,q
4),(s3,q
1),(s5,q
3),(s6,q
2),(s7,q
1)}. Thus, every state in P(except
the removed dead-end states that are filled in the figure) satisfies EG true under the
fairness constraint. However, only the states {(s1,q
2),(s2,q
4),(s3,q
1),(s6,q
2)}are
in SatP(ϕ). Therefore, only the states q1,q
2,andq4in Msatisfy Eϕ=E(aUb).
3.4.3 Symbolic Model Checking for LTL
To exploit a more concise symbolic representation for LTL model checking, we have
to define the transition relations of Mand Tin terms of boolean functions which
can be represented as ROBDDs. It is already described in section 3.3.3 how this
can be done for the temporal structure M. In this section, we give a notion of how
to represent a tableau in terms of ROBDDs.
Generally, for each elementary formula ϕi∈el(ϕ), we introduce a boolean
variable vi. Thus, the tuple v=(v1,v
2,...) describes a state in T, and the transition
relation can be given in terms of vand its copy v0(denoting truth values in the
next state).
In order to get distinguishable variables, we denote with p=(p1,p
2,...)the
tuple of boolean variables that represent the atomic propositions ϕi∈V
ϕ. With r=
(r1,r
2,...) we will denote the tuple of boolean variables representing the remaining
elementary formulas el(ϕ)\Vϕ. Within M, we will use qas a boolean vector for
VM\Vϕ.
Then, a state s∈STcan be given as a pair of boolean tuples (p, r). The
transition relation in the tableau RTwill be represented as a boolean formula over
pairs (p, r)and(p0, r0). The transition relation in the temporal structure RMis
given as a boolean function over (p, q)and(p0, q0). The transition relation of the
product structure RPis the conjunct of both boolean functions:
RP(p,q,r,p0,q0,r0)=RR(p,r,p0,r0)∧RM(p,q,p0,q0)(3.22)
Now the symbolic CTL model checking algorithms for treating fairness con-
straints (as described in section 3.3.3) can be used to find all states in Pthat
satisfies (EG true) with respect to the fairness constraint given in 3.21. The states
comprise the fixpoint.
Considering the dead-end states in P, and the corresponding finite paths that
are not a proper model for the LTL formula, it can be shown that these are excluded
by means of the fixpoint computation under fairness constraints: For every state
sthat is in the fixpoint of the predicate transformer for (EG true)weknowthat
there is a path from smeeting infinitely often states s0that satisfy the fairness
constraints. That is, we only get those states, which have infinite paths meeting
all fairness constraints infinitely often. None of the dead-end states can fulfil this
property.
The resulting states are given as boolean vectors (p, r, q). A state (p, q)∈M
satisfies (EG true) if and only if there exists a vector rsuch that (p, r,q)isinthe
fixpoint and (p, r)∈SatT(ϕ).
With this last subsection, we finish the description of a model checking approach
for LTL that can be nicely integrated into symbolic model checking of CTL. This
approach suggests an integration of both logics into one model checking tool. In
the following section, we given a comparison of CTL and LTL that should motivate
the use of a combination of both logics.
44
Linear-Time versus Branching-Time Logic Section 3.5
3.5 Linear-Time versus Branching-Time Logic
Comparing LTL with CTL requires two measurements:
1. The complexity of the checking procedure. This measure depends on both,
the size of the formula and the size of the structure to be checked.
2. The expressiveness of the language given with the logic.
In order to motivate our decision to provide ASM with the checking facility for
both kinds of temporal logic, we gather some remarks concerning complexity and
expressiveness in the following subsections.
3.5.1 Complexity of the Algorithms
Model checking CTL formulas is linear in the size of the temporal structure M
and linear in the size of the temporal formula ϕ. This renders the CTL approach
feasible for quite large systems. However, if the system is of exponential size the
complexity of the checking procedure is exponential, as well (e.g., a switch over a
data domain with nelements has 2ndifferent states).
If symbolic representation is used by means of binary decision diagrams (BDDs),
then the checking algorithm is operating not on the system states (or sets of states)
directly, but rather on BDDs that represent the corresponding characteristic func-
tions for sets of states. That is, the complexity depends on the size of the BDD
instead. In many cases, the BDD size is much smaller than the size of the structure
itself. But this does not hold for every example (see [Bry86]). The BDD structure
may grow to exponential size as well, and in some cases may be even larger than
the explicit representation.
The complexity of the linear-time approach is linear in the size of the structure
but exponential in the size of the logical formula. This is caused by the construc-
tion of the tableau that represents the requirements (i.e., the LTL formula). This
drawback of the linear-time approach, however, is not absolute.
Firstly, the algorithms can be improved. In the traditional approach the con-
struction of the tableau is guided by the appearance of the LTL formula, i.e., by its
logical operators (see [Wol81] or [BAMP81] for example). When adapting the con-
struction principle, however, the benefit of symbolic representation can be exploited.
[BCM+92], [CGH94] and [CGH97] introduce an algorithm for tableau construction
for BDD-based representation. (The description in Section 3.4.2 follows this ap-
proach.) Their complexity results are comparable to those of symbolic CTL model
checking (see the comparative case study in [CGH97]).
Secondly, the length of an LTL formula is much shorter than the comparable
CTL formula in some cases. It can be shown that for some LTL formulas the
corresponding CTL formula has exponential size. Moreover, if it is possible to
generate an LTL formula from a CTL formula it will be in most case shorter, but
never longer then the branching-time version. Thus, the polynomial complexity of
CTL is a relative advantage only.
3.5.2 Expressiveness of Temporal Logics
In [Lam80], Lamport compared the expressiveness of branching-time versus linear-
time logics for the first time. He showed that each logic could express certain
properties that could not be expressed in the other. However, his resulting notion
of expressive equivalence failed because it classified some satisfiable formulas as
equivalent to false. The comparison lacked a suitable framework since formulas
45
Chapter 3 Model Checking: An Overview
of linear time are related to individual paths and formulas of branching-time are
related to states.
Emerson and Halpern [EH86] introduced a uniform logical framework for com-
paring the expressive power of both logics called CTL*. Within CTL* linear-time
as well as branching-time properties can be expressed and the formulas of both
logics are related to states.
The proofs of the inexpressibility results in [EH86] are very long and complicated.
[CD88] introduced instead a simple characterisation of those CTL* formulas that
can be expressed in LTL. Also they gave a necessary condition that a CTL* formula
must satisfy in order to be expressible in CTL.
In the following subsection, we will only sketch the relation between the logics
and will show some differences for the expressiveness by means of examples.
The Extension CTL*
Besides the usual first-order operations, CTL* provides two different kinds of tem-
poral operators. Linear temporal operators stating propositions with respect to a
path. Basically, we may use the next operator Xand the until operator U.Tempo-
ral operators of branching-time referring to several branching paths that start in the
current state. A proposition must hold for some paths E, or for all paths Ain the
computation tree. These operators can be found in the sub-logics as well (compare
Section 3.3.1 and Section 3.4.1). Again we distinguish state and path formulas.
Let Vbe the set of atomic propositions, then the syntax of CTL* is defined in
the following way:
Definition 3.21: Syntax of CTL*
state formulas:
i.) If ϕ∈V,thenϕis a state formula.
ii.) If ϕand ψare state formulas, then ¬ϕand ϕ∨ψare state formulas.
iii.) If ϕis a path formula, then Eϕis a state formula (the same holds
for Aϕ).
path formulas:
i.) If ϕis a state formula, then ϕis also a path formula.
ii.) If ϕand ψare path formulas,
then ¬ϕ,ϕ∨ψ,Xϕand ϕUψare path formulas.
The relation between state and path formula in CTL* is depicted in Figure 3.5.
state formula path formula
V
:
,
_
:
,
_
,
X
,
U
E, A
Figure 3.5: State formulas and path formulas in CTL*
46
Linear-Time versus Branching-Time Logic Section 3.5
CTL versus CTL*
The major difference to CTL is that in CTL* every state formula is a path formula as
well. Thus, in CTL* every formula can be combined with the quantifying operators
over paths (Eand A) which does not hold for CTL. (Recall from definition 3.15
that only if ϕis a path formula then Eϕis syntactically correct.) For example, the
formula E(ϕ∧Xψ) is syntactically correct in CTL* but not in CTL. In CTL every
state formula has to be preceded by a path quantifier.
Compared to CTL* (see Figure 3.5) we get the relation between state and path
formulas within the CTL framework as sketched in Figure 3.6.
state formula path formula
:
,
_
X, U
V
E, A
:
Figure 3.6: State formulas and path formulas in CTL
Fairness. Accordingly, in CTL the sub-formula Gϕneeds to be quantified over
paths. We cannot express FGϕ, for instance. The CTL formula ψ=AF (AG ϕ)
has a different semantics. The structure M, depicted in Figure 3.7, gives an example:
Although the LTL formula ψ0=FGϕholds in M, i.e., M,s0|=A(FGϕ), this is
not the case for the CTL formula ψ=AF (AG ϕ), i.e., M,s0|=/AF (AG ϕ). As
an explanation, one might consider that in the computation tree of M the path for
the computation that stays in state s0has in every node a successor that does not
satisfy ϕ. At every state it is possible to transit to state s1.Thatis,thereisno
point in the future at which ϕis always true in every possible future.
'
'
s
0
s
1
s
2
:
'
Figure 3.7: Branching-time structure M
The same argument holds for conditional fairness which is useful in many appli-
cations. We distinguish weak fairness and strong fairness.
Weak fairness (also known as justice) (which is the most common notion of
fairness) is defined as an LTL formula which has no counterpart in CTL. An infinite
path is weak fair with respect to a set of fairness conditions Ξ = {ξ1,ξ
2,...}and
property ϕif it satisfies the following: if each ξi∈Ξ eventually holds forever then
it follows that ϕholds infinitely often during the path. This can be formalised as
follows:
(Vn
i=1 FGξi)=⇒GFϕ(3.23)
47
Chapter 3 Model Checking: An Overview
Also strong fairness cannot be expressed in CTL. An infinite path is strongly fair
with respect to the fairness conditions in Ξ and property ϕin the following case: if
each ξi∈Ξ holds infinitely often, then it follows that ϕholds infinitely often along
the path.
(Vn
i=1 GFξi)=⇒GFϕ(3.24)
For a proof of these results see [EH86].
LTL versus CTL*
LTL, on the other hand, lacks the path quantifiers Eand A. The semantics of
LTL formulas is given with respect to paths, not to states. State formulas are not
expressible. This is shown in Figure 3.8. In the framework of CTL*, however, every
LTL formula ϕis regarded as implicitly quantified over all paths. We consider only
formulas of the form Aϕ. But an LTL formula cannot express that something is
satisfied along some computation path, which is expressible in branching-time logic.
path formula
V
:
,
_
,
X, U
Figure 3.8: Formulas in LTL
Obviously, fairness is expressible in LTL since there is no restriction for com-
bining the temporal operators (in fact, the formulas given in 3.23 and 3.24 are LTL
formulas).
Besides fairness, we are also interested in using LTL for specifying environment
behaviour. As shown in Section 5.1, specifying assumptions on environment be-
haviour in a constructive way by means of ASM transition rules is quite difficult.
The use of a logical framework for this concern would be helpful. LTL formulas
model a behaviour of a component in an intuitive way by means of particular ex-
ecutions, i.e., state sequences or paths. For instance, “if a request arrives then
eventually it will be acknowledged” can be modelled by (¬req ∧Xreq →Fack).
Such a sequence of changes (e.g., the arrival of a request) and following executions
cannot easily be modelled with CTL.
Intersections of the logics
Comparing the expressiveness of the three different temporal logics CTL*, CTL and
LTL, it can be shown that CTL* comprises both other logics. The intersection of
LTL and CTL is a non empty set of formulas. However, not every LTL formula is
expressible in CTL and vice versa. The overall framework is depicted in Figure 3.9.
Some examples are given for the corresponding sub-sets.
48
Linear-Time versus Branching-Time Logic Section 3.5
CTL*
LTL CTL
AX
'
AF
'
AG
'
A
(
'
U
)
A
(
FG
'
)
AG
(
EF
'
)
A
(
FG
)
_
AG
(
EF
'
)
Figure 3.9: Expressiveness of the three temporal logics
This figure concludes the comparison. It should be clear that both logics, for
branching time and linear time, have their own advantages and disadvantages. In
fact, a combination of both logics appears promising. Model checking for CTL*
that comprises both logics is a very complex task and therefore in many cases not
feasible. It is recommended to restrict the treated logic to the actual needs. One
approach is described in Section 3.4. It combines model checking for CTL with a
treatment for LTL.
In the next chapter, we describe the data structure used for symbolic model
checking: binary decision diagrams and its extension multiway decision graphs.The
latter one provides the target language for our interface from ASM to the MDG-
Package. A basic understanding of this data structure should help to follow the
description of the interface given in Chapter 8.
49
Chapter 3 Model Checking: An Overview
50
Chapter 4
Decision Graphs
The complexity of a model checking algorithm can be reduced by using a symbolic
representation of states and state transitions. This approach is called symbolic model
checking (c.f., section 3.3.3 on page 34). The representation is based on the idea
of describing a system by means of boolean functions. Boolean logic is appropriate
for specifying hardware circuits. Model checking was introduced as an automatic
approach of hardware verification.
Boolean functions can be canonically represented by binary decision diagrams
(BDDs). For this graph structure, very efficient algorithms are available which pro-
vide the basis for model checking (e.g., [Bry86] or [DB98a]). For more complex
systems, involving higher-level data structures (not only boolean values), a cod-
ing is necessary that maps these data onto boolean values. To avoid this coding,
alot of research is being done in order to lift the boolean graphs to more complex
data domains depending on the application domain that is considered; for instance
“multi-values” for modelling arbitrary sets, real numbers for coding time, intervals,
etc. For specifying hardware systems, the notion of “word-level” is used to name a
higher level of abstraction for the system specification (e.g., multiplication modules
are easier to describe on the word-level rather than the boolean level). [DB98b]
gives an overview of various types of decision diagrams and develops their common
theory.
In this Chapter, we give a short overview of the notion of BDDs (Section 4.1),
which are the most common symbolic representation used for model checking. In
Section 4.2 we introduce a special sort of lifting of this simple structure, called
multiway decision graphs (MDGs). MDGs are a kind of superset of BDDs which
provide a higher level for the representation. For our work, both data structures
are relevant since they are internally used in the model checking tools we want to
apply to ASM.
4.1 Binary Decision Diagrams
Syntactically, a decision diagram (DD) is defined as a finite, connected, directed
acyclic graph G=(V,E) over a set of Boolean variables Xnandanonempty
terminal set T;Vdenotes the set of vertices (nodes) and Ethe set of edges. The non-
terminal nodes in Vare labelled with variables from Xn. They have two successor
nodes and the two edges leading to them are labelled with 0 (low)and1(high),
respectively. The successor node of vthat is connected via the “low” edge is denoted
as low(v), and the successor node connected via the “high” edge is denoted as
high(v). The terminal nodes are labelled with values from terminal set T.The
topmost node is called the root of the graph. Such a DD Gmay have the following
51
Chapter 4 Decision Graphs
properties:
•Gis complete, if each variable in Xnis encountered exactly once on each path
in Gfrom the root to the terminal node.
•Gis free, if each variable in Xnis encountered at most once in each path.
•Gis ordered, if it is free and the variables on each path are encountered in the
same order.
Abinary decision diagram (BDD) is a DD with the terminal set T={0,1}which
represents the truth values of boolean logic. Accordingly, a BDD represents a
boolean function. We distinguish two cases for a diagram B:
•If Bconsists of a single terminal node, then it represents the truth value the
node is labelled with, i.e., 0 or 1.
•If Bhas a root vlabelled with a variable xi∈Xn,the low edge leads to
a subgraph that represents the formula flow(v)and the high edge leads to
a subgraph that represents fhigh(v)then Brepresents the formula fvover
variables in Xn
fv(x1,...,x
n)=(¯xi∧flow(v)(x1,...,x
n)) ∨(xi∧fhigh(v)(x1,...,x
n)) (4.1)
This definition of the semantics of a BDD is also known as the Shannon decompo-
sition (c.f., [DB98a]).
Figure 4.1 gives an example. The BDD represents the function
fv(x1,y
1,x
2,y
2)=(x1⇔y1)∧(x2⇔y2). The dashed lines denote the low edges
and the solid lines denote the high edges. The label of each terminal nodes repre-
sents the evaluation of the path that leads to it, i.e., either 0 or 1. This graph is
complete and ordered.
x
1
y
1
x
2
y
2
y
1
y
2
0 00
1
0
1
0
y
2
1
0
y
2
x
2
1
x
2
x
2
y
2
y
2
Figure 4.1: Complete OBDD that represents the function (x1⇔y1)∧(x2⇔y2)
52
Binary Decision Diagrams Section 4.1
Ordered BDDs (OBDDs) can be reduced if they con-
tain (a) redundant nodes whose edges lead to the same
successor node or (b) isomorphic subgraphs. The OBDD
in Figure 4.1, for instance, contains redundant nodes la-
belled with x2and y2(these nodes are shaded in the
figure). Their evaluation does not change the value of
the function since both edges lead to the same successor.
Furthermore, the two subgraphs with root x2(marked by
a patterned background) are isomorphic. We can reduce
a complete OBDD by erasing the redundant nodes and
merging the isomorphic subgraphs. Figure 4.2 shows the
reduced OBDD (ROBDD) after applying the reduction
algorithm. Note that the order of the variables, here
x1<y
1<x
2<y
2, essentially influences the size of the
ROBDD. A changed order of x1<x
2<y
1<y
2would
lead to an ROBDD with nine nodes. The problem of
finding the optimal order for an arbitrary graph is NP
x
1
y
1
y
2
x
2
1
0
y
1
y
2
Figure 4.2: Reduced OBDD
hard ([Bry86]). However, heuristics are available that provide in most cases an ap-
propriate solution. Only in some cases, the ROBDD representation of a function
grows larger than other representations of the same function. The most famous ex-
ample is the function of an integer multiplier (see [Bry86]) which grows exponentially
for any variable order. Since an ROBDD is a canonical representation, satisfiability
and equivalence are easy to check: A function is satisfiable if the corresponding
graph is not the terminal node labelled with 0. Two functions are equivalent if they
are represented by the same ROBDD.
The importance of ROBDD for model checking is given through the fact that
sets and relations can be modelled by boolean characteristic functions. That is,
transition systems, comprising a set of initial states and a state transition relation,
can be represented by ROBDDs. This symbolic representation is in most cases
much smaller than other state representations. The complexity of symbolic model
checking algorithm depend on the size of the ROBDD rather than the actual state
space, and is therefore more efficient in cases where the symbolic representation by
ROBDDs is smaller than the explicit representation.
4.1.1 Algorithms for ROBDDs
Very efficient algorithms were developed that realise the boolean operation for ROB-
DDs (see [Bry86] or [DB98a]). For symbolic model checking of CTL formulas (see
Section 3.3 on page 28) another algorithm for ROBDDs is central, called the rela-
tional product (introduced in [BCL+94]). In the following we describe this algorithm
in more detail to aid understanding of the further development based on MDGs.
The algorithm for relational product implements the computation of CheckEX
(equation 3.10 in Section 3.3.3 on page 34):
CheckEX(Φ(~s )) := (∃~s 0.(Φ(~s 0)∧R(~s, ~s0)))
Accordingly, the algorithm realises the existential quantification over primed state
variables ~s 0and the conjunction of two ROBDDs that represent the boolean for-
mulas Φ(~s )andR(~s, ~s0).
We illustrate the algorithm in Figure 4.3. The input parameters Band Gdenote
the BDDs that represents Φ(~s 0)andR(~s, ~s0). The set of variables Var corresponds
to the primed variables in ~s 0as given above in the formula for CheckEX.Theyare
existentially quantified.
The algorithm is defined recursively on the structure of the BDDs. That is, we
choose among the root node labels of both graphs the one that comes first in the
53
Chapter 4 Decision Graphs
Bin RelP (B,G :ROBDD,Var : set of variables) =
if B=false or G=false
then return false
else if B=true and G=true
then return true
else if Bin RelP(B,G,Var )=Ris already computed
then return R
else
let xbe the root label of B
let ybe the root label of G
let zbe the topmost of xand y
R0:= Bin RelP(B|z=0,G|z=0,Var )
R1:= Bin RelP(B|z=1,G|z=1,Var )
if z∈Var
R:= Or(R0,R
1)
else
R:= (z=1 ∧R1)∨(z=0 ∧R0)
endif
insert (B,G,Var ,R) in the result cache
return R
endif
end Bin RelP
Figure 4.3: The algorithm for relational product on ROBDDs
order of variables, denoted by zin the figure. Two cases may occur: (a) zappears
in both graphs as the root node label; (b) only one graph contains zand the other
graph does not. The subgraphs of a BDD are computed by substituting zwith the
values 0 and 1; we get F|z=0 and F|z=1,whereF∈{B,G}.IfFdoes not contain
the root label zthen the subgraphs are equal to F, i.e., F|z=0=F|z=1=F.
We apply the relational product algorithm, Bin RelP, to these subgraphs. The
resulting graphs, called R0and R1in Figure 4.3, are used as parameters when
computing the relational product at the level of root node z:
•If zis an element of the quantified set of variables, i.e., z∈Var ,thenwe
disjoin both subgraphs R0and R1by applying the Or algorithm on BDDs
where disjunction realises the existential quantification (c.f., the definition of
CheckEX above). Due to the quantification, zdoes not occur in the resulting
graph Rany more.
•If z/∈Var we build a BDD Rthat represents the formula (z=1∧R1)∨(z=
0∧R0) by keeping zas the root node label and using R1and R0as high
and low subgraphs.
Besides the relational product, we use algorithms for conjunction and disjunction
of ROBDDs. A more general algorithm Apply, which takes the boolean operation
to be applied as a parameter, is described in detail in the literature (see [DB98a]).
These simple algorithms together with fixpoint algorithms are sufficient for the
symbolic model checking approach (c.f., Section 3.3).
54
Multiway Decision Graphs Section 4.2
4.2 Multiway Decision Graphs
Multiway decision graphs (MDGs) are a generalisation of ROBDDs. They allow
symbolic representation of sets of states and transition relations in the same way
as the binary graphs. Additionally, they incorporate variables of any enumerated
sort and even abstract sorts. This essentially lifts the level of abstraction of the
model coding. Firstly, the binary coding of (finite) data types, which yields more
complex representations, can be avoided. Secondly, even infinite data types can be
represented and by means of abstract sorts and uninterpreted functions incorporated
into the model checking process.
Lifting the low-level coding of BDDs is also used elsewhere. For example, mul-
tiway decision diagrams (MDDs), used as an internal data structure in the model
checker VIS ([Gro96]), allow for variables of enumerated sort as well. However, they
do not include abstract data types.
MDGs are introduced in the literature in [CZS+97] and [CCL+97]. Several
examples show that model checking based on MDGs is successfully used for verifying
hardware circuits (see for example [ZST+96], [BT98], or [LTZ+96]). We want to
use this approach for model checking ASM (see Chapter 8) and therefore recall here
the basic notion of this graph structure and the logic it is based on.
4.2.1 The Logic
In the same way that BDDs represent formulas of boolean logic, MDGs are a canonic
representation of formulas of a special many-sorted first-order logic. The logic
comprises various sorts, constants, variables, and function symbols. Constants and
variables have a sort, and a function symbol of arity nhas a type α1×...×αn→
αn+1 where the αiare sorts.
In contrast to ordinary many-sorted first-order logic, this logic distinguishes be-
tween concrete sorts and abstract sorts. Concrete sorts have enumerations, abstract
sorts do not. This leads to the distinction between three kinds of functions: Assume
that fis of type α1×...×αn→αn+1,then
•fis an abstract function symbol,ifαn+1 is an abstract sort;
•fis a concrete function symbol,ifallαiare concrete sorts;
•fis a cross operator,ifαn+1 is a concrete sort and at least one of α1,...,α
n
is an abstract sort.
The elements of an enumeration are called individual constants. Constants of ab-
stract sort are denoted as generic constants.
Semantics
An interpretation is a mapping ψthat assigns a denotation to each sort, constant
and function symbol. It satisfies the following conditions:
1. The denotation of an abstract sort αis a non-empty set ψ(α).
2. For each concrete sort α={a1,...,a
n}the denotation is given as
ψ(α)={ψ(a1),...,ψ(an)}.
3. If fis a function symbol of type α1×...×αn→αn+1 then ψ(f) is a function
of type ψ(α1)×...×ψ(αn)→ψ(αn+1).
55
Chapter 4 Decision Graphs
Avariable assignment is a mapping that assigns a constant value to each variable
in X, the set of variables. A variable assignment φis called ψ-compatible if it maps
each variable x∈Xof sort αto value φ(x)∈ψ(α). Φψ
Xdenotes the set of ψ-
compatible variable assignments for the variable set X.AformulaPis true (or
false) with respect to the interpretation and the variable assignment. We write
ψ,φ |=Pif Pdenotes truth under interpretation ψand ψ-compatible variable
assignment φ. Abstract function symbols and cross-operators are uninterpreted.
Atomic formulas are the truth values, true and false, and equations. A well
typed equation is an expression A1=A2where the left hand side (LHS) and the
right hand side (RHS) are of the same sort. Formulas are built from atomic formulas
using logical connectives (∨,∧,¬,...) and quantifiers. This logic is similar to the
logic that is used to describe the states of an ASM (c.f., Section 2.2), except for
abstract sorts and uninterpreted functions.
MDGs represent a subset of all formulas which is sufficient for encoding transi-
tion systems. [CCL+97] introduces the notion of directed formulas to capture this
subset of formulas.
Directed Formulas
Adirected formula (DF) is given in terms of two disjoint sets of variables Uand V.
Set Vcan be seen as the set of dependent variables and Uas the set of independent
variables. Both sets comprise variables of concrete and abstract sort, i.e., U=
Uconc ∪Uabs and V=Vconc ∪Vabs where the set index indicates the kind of sorts
of its elements. In a DF, the variables in Vabs may only appear as a left hand side
(LHS) of an equation. Every abstract variable occurring on the right hand side
(RHS) of an equation or as a parameter of a cross-term is an element of Uabs.The
LHS of an equation of concrete sort (if not a cross-term) may be variables of either
sets Uor V.Uand Vdetermine the type of a DF, which is denoted as U→V.
ADFoftypeU→Vis a formula in disjunctive normal form (DNF) that satisfies
the following three conditions:
(i.) Each disjunct is a conjunct of equations of one of the following forms
f(B1,...,B
n)=a
where fis of concrete sort αand at least one of the terms Biis of
abstract sort (i.e., fis a cross-operator), and all variables in any term
Biare elements of U;ais an individual constant in the enumeration of
sort α;
w=a
with w∈(U∪V) is a variable of concrete sort αand ais an individual
constant of the same sort;
v=A
with v∈Vis a variable of abstract sort αand Ais a term of sort α
containing only variables that are elements of U.
(ii.) In each disjunct, the LHSs of the equations are pairwise distinct.
(iii.) Every abstract variable v∈Vappears as the LHS of an equation v=Ain
each of the disjuncts.
ADFissaidtobeconcretely reduced if and only if every term Ain an equation
v=Ais a concretely reduced term. A term is called concretely reduced if it contains
no concrete terms other than individual constants. That is, in a concretely reduced
56
Multiway Decision Graphs Section 4.2
term every concrete variable and every function of concrete sort (this includes cross-
terms) has to be substituted by its value.
A variable has primary occurrence in a DF if it occurs as the LHS of an equation
in the DF. A variable has secondary occurrence in a DF if it occurs either in a cross-
term on the LHS of an equation, or it occurs in a concretely reduced term on the
RHS of an equation.
4.2.2 Multiway Decision Graphs
An MDG is a finite graph G=(V,E), whose non-terminal nodes are labelled by
terms and whose edges, starting from a non-terminal node, are labelled by terms of
the same sort as the node. Terminal nodes are labelled by formulas. Generally, a
graph Grepresents a formula in the following way:
•If Gconsists of a single terminal node, then it represents the formula the node
is labelled with.
•If Ghas a root node labelled with term Aand edges labelled with
terms B1,...,B
nleading to subgraphs G1,...,G
nthat represent formulas
P1,...,P
n,thenGrepresents the formula
(A=B1∧P1)∨(A=B2∧P2)∨...∨(A=Bn∧Pn).(4.2)
This definition is similar to the def-
inition of BDD representation given by
Equation (4.1). In contrast, however,
the number of edges of an MDG is
not restricted to two and the labels
of nodes and edges do not have to be
boolean variables or values. In Figure
4.4 we depict Formula (4.2) as a graph
G.
To be a canonical representation, an
A
B
1
B
2
B
n
G
n
G
2
G
1
...
Figure 4.4: The MDG G
MDG has to satisfy certain well-formedness conditions. These conditions involve
two kinds of orders: (a) The standard term order is a total order on the set of
all terms of the logic. (b) The custom symbol order is a total order on the set of
symbols Cwhich includes all cross-operators, all concrete variables, and some of
the abstract variables. It is given by the user and need not be compatible with the
standard term order. The custom symbol order is a generalisation of the variable
order for ROBDDs.
MDG Well-formedness Conditions
Assume Uand Vare disjoint sets of variables such that all abstract variables in
Vparticipate in the custom symbol order. An MDG of type U→Vis a directed
acyclic graph with one root and ordered edges, that represents a concretely reduced
DF. The following well-formedness conditions have to be satisfied:
1. Every leaf node is labelled with the formula true, except when Gconsists of
only one terminal node which may be labelled with true or false.
2. Every node-edge pair (N,E), where Nis an internal node, represents an
equation of the DF, such that Nis labelled by its LHS and Eby the RHS.
The LHS and RHS follow the definition of DFs formulated above. Each path
in the graph describes one of the conjuncts of equations of the represented
DF. The whole graph represents the disjunction of all conjuncts of the DF.
57
Chapter 4 Decision Graphs
3. The graph is ordered. All edge labels of one node are ordered according to
the standard term order1. Along each path, all variables and cross-operators
of cross-terms that label the nodes, are ordered by the custom symbol order.
If cross-operators appear more than once among the labels of one path, the
order of the corresponding cross-terms is given through the standard term
order. The order of nodes and edges must be total; repeated labels are not
allowed.
4. The MDG must be minimal. Analogously to the reduction for OBDDs, MDGs
can be reduced by merging isomorphic subgraphs, and deleting redundant
nodes. In the case of MDGs, a node is redundant if it is labelled by a con-
crete variable or cross-term, the labels of the outgoing edges comprise the
enumeration of its sort entirely, and all edges lead to the same subgraph.
5. No variable should have both, primary and secondary occurrences in the same
graph. This is guaranteed if Uand Vare disjoint sets and the MDG is of
type U→Vand satisfies condition 2.
6. The set of abstract variables having primary occurrences along a path is the
same for all paths in a given graph. This is satisfied if the graph represents a
DF according to condition 2.
7. The order of abstract variables must consider the dependencies. Dependent
abstract variables must have a lower order than those abstract variables they
depend on. Two cases can occur: (a) if the node-edge pair represents the
equation w=A(v)wherewis an abstract variable and Aa term that contains
the abstract variable v∈V, then the custom symbol order must satisfy v<w;
(b) if a node is labelled by the cross-term f(B1,...,B
n) and the abstract
variable v∈Voccurs in one of the parameter terms Biand participates in
the custom symbol order, then the custom symbol order has to satisfy v<f.
This condition is due to the fact that in both cases the abstract variable v∈V
must be substituted during the computation on the graph.
Given a custom symbol order and a standard term order, it can be proven for
two well-formed MDGs Gand G0representing formulas Pand P0, respectively, that
if |=P⇔P0,thenGand G0are isomorphic (for a proof see [CZS+97]). That is,
MDGs are a canonical representation for DFs. Throughout this work we use the
notion MDG for denoting a well-formed MDG.
4.2.3 Operations on MDGs
Similar to ROBDDs, operations on MDGS can be implemented in a very efficient
way. The MDG-package yields a library of the basic functions implemented proto-
typically in Prolog. This implementation lacks the efficiency of C/C++ code (due
to the extensive use of memory space in Prolog which influences the runtime). How-
ever, the algorithms are in principle as efficient as the corresponding algorithms on
ROBDDs (see [ZST+96] for a comparison of different tools). [Zho96] provides a
very helpful documentation of this package, which allows to develop more complex
algorithms based on MDGs, as for instance algorithms for model checking temporal
logic formulas (see [XCS+98, Xu99]).
In the following subsection, we explain the basic functions on MDGs that are
useful for model checking. All functions process lists of MDGs. For the application,
we have to follow particular restrictions in order to preserve the well-formedness
conditions for the resulting graph.
1In fact, edge labels and corresponding subgraphs are encoded as lists. These lists are ordered.
58
Multiway Decision Graphs Section 4.2
Disjunction
The disjunction of two graphs can be easily computed in terms of the disjunction
of the subgraphs if both graphs have the same root label. Figure 4.5 sketches the
situation for a root label A(of abstract or concrete sort). In the result, the subgraph
G0represents the disjunction (G2∨G4)andG00 stands for (G3∨G5).
A
B
1
B
2
G
2
G
1
G
3
B
3
A
B
2
B
3
G
5
G
4
G
6
B
4
A
B
1
B
3
G
00
G
1
G
6
B
4
G
0
B
2
=
_
Figure 4.5: Disjunction of two MDGs with the same root label
If the graphs have different root labels, however, it is not always possible to
compute the disjunction. For instance, if the root labels are abstract variables vand
u, and the graphs represent the logical formulas (v=a)and(u=b), then there is no
well-formed MDG that represents their disjunction. The formula (v=a)∨(u=b)
does not satisfy the condition (iii.) on DFs since not every abstract variable appears
as an LHS of an equation in every path.
If node label vis of concrete sort and it comes before uin the order of nodes,
then we may add a redundant node on top of the second MDG and thus get the
situation for identical root labels. This redundant node must comprise all values of
its enumeration as labels of outgoing edges, and these edges must lead to the same
subgraph.
In order to apply disjunction, we must assure that both MDGs must have the
same set of primary abstract variables, and, therefore, if the root labels are abstract
they are the same variables (c.f., condition (iii.) on DFs). This restriction also
motivates the well-formedness condition 6. on MDGs given in the list above.
The disjunction algorithm of the MDG-package is n-ary. It takes a list of
MDGs Piof type Ui→Vas input and produces the disjunct (W1≤i≤nPi)oftype
(S1≤i≤nUi)→V.
Relational Product
The relational product computes the conjunct of MDGs and existentially quantifies
over a given set of variables, similar to the relational product on ROBDDs (see
function Bin relP in Figure 4.3). As an extension the algorithm on MDGs processes
lists of MDGs rather than two graphs only. This allows partitioning of the transition
relation (i.e., the relation is represented by a set of smaller MDGs rather than by a
single big graph) and therefore the algorithm benefits from early quantification of
variables (for more details see [BCL+94]).
However, the application on MDGs is restricted in the following sense: Generally,
two MDGs with roots that are labelled with the same abstract variable can not be
conjoined. For instance, let ube an abstract variables, and aand bbe two distinct
abstract generic constants, then we cannot compute the conjunction (u=a)∧(u=
b). It is undecidable if this formula is true or false, since the abstract generic
constants are uninterpreted; they can be equal or not. Thus, the relational product
can be computed only if the sets of primary abstract variables of the MDGs to be
conjoined are disjoint.
The algorithm for computing the relational product on MDGs combines con-
junction, existential quantification, and renaming. It takes as input ngraphs Pi
59
Chapter 4 Decision Graphs
of type Ui→Vi, the set of variables Eto be quantified, and a substitution func-
tion ηfor renaming and yields as the result the graph that represents the formula
(∃v∈E)(V1≤i≤nPi)·η.For1≤i<j≤n,thevariablesetsViand Vjmust
not have any abstract variable in common. The type of the resulting subgraph is
(S1≤i≤nUi)\(S1≤i≤nVi)→((S1≤i≤nVi)\E)·η. The algorithm is documented
in detail in the appendix of [CZS+97].
Pruning by Subsumption
The algorithm for pruning by subsumption is useful for approximating the difference
of two graphs. The input is two graphs Pand Qof types U→V1and U→V2,
where Ucontains only abstract variables that do not participate in the custom
symbol order. The result graph is of type U→V1and is derivable from Pby
pruning.
Pruning means removing those paths from Pthat are subsumed by graph Q.A
path in Pis subsumed if there is a substitution on variables in Usuch that applied
to a path in Qthis new path contains all node-edge pairs of the subsumed path in
P. The resulting graph Rsatisfies the following condition
P∧¬(∃u∈U)Q⇒R(4.3)
Since Ris computed by pruning of Pthe paths of Rrepresent a subset of
disjuncts represented by the paths in P, i.e., R⇒P. Together with the logical
implication in (4.3) we can view Ras approximating the logical difference between
Pand (∃u∈U)Q. An equivalent form of this formula cannot be found in general.
If Ris false, it follows that P⇒(∃u∈U)Q.
Negation
The negation of an MDG can be computed only if it contains no primary abstract
variables. If uis an abstract variable and ais a generic abstract constant, then we
cannot evaluate the formula ¬(u=a),sincewehavenointerpretationforuand a.
In contrast to the negation, the equation (u=a) implicitly represents the existential
quantification of a, i.e., there exists a value asuch that uequals a. However, this
does not include the knowledge of a witness that satisfies this equation. Therefore,
we cannot express that uis not equal the generic abstract constant a.
For MDGs with all primary variables of concrete sort, we can compute the
negation.
x
1
3
G
2
G
1
G
3
4
x
1
3
:
G
2
:
G
1
:
G
3
4
true
2
=
Figure 4.6: Negation of MDG with node label of concrete sort
See for an example Figure 4.6. We assume x∈Xand X={1,2,3,4}.Theleft
MDG in the figure represents the formula
¬(x=1∧G1)∨(x=3∧G2)∨(x=4∧G3)
60
Multiway Decision Graphs Section 4.2
=¬(x=1∧G1)∧¬(x=3∧G2)∧¬(x=4∧G3)
=(x6=1)∨(x=1∧¬G1)
∧(x6=3)∨(x=3∧¬G2)∧(x6=4)∨(x=4∧¬G3)
=(x6=1∧x6=3∧x6=4)∨(x=1∧¬G1)∨(x=3∧¬G2)∨(x=4∧¬G3)
=(x=2)∨(x=1∧¬G1)∨(x=3∧¬G2)∨(x=4∧¬G3)
The result formula is represented by the right MDG in Figure 4.6. This example
provides a general approach to computing the negation of any MDG that contains
only primary variables of a concrete sort which can be enumerated.
In this thesis, we implement an algorithm for negation, which is not given in the
MDG-package.
With this chapter, we finish the second part of the thesis which presents the
theory of model checking and the underlying data structure that is exploited for
symbolic model checking. In the next chapter, we introduce our approach for model
checking ASM. Technically, the central task of this approach is a transformation
between languages. Apart from this transformation, the application of model check-
ing needs some insights into treating the models. The next chapter discusses the
intricacies of applying model checking to ASM and introduces the core transforma-
tion algorithm. The correctness proof of the transformation algorithm completes
the chapter.
61
Chapter 4 Decision Graphs
62
Chapter 5
Applying Model Checking to
Abstract State Machines
An ASM model of a system comprises the state space, defined by means of universes
and functions, and the state transition behaviour, defined by means of transition
rules. Thus, an ASM model is basically a transition system as used within the model
checking approach (c.f., Section 3.2.1 on page 24). In principle, model checking can
be applied.
We understand model checking as tool sup-
port for debugging an ASM model. Debugging
is a cyclic process of repeatedly reworking the
model according to errors that might be found.
A debugging cycle for ASM models that involves
model checking is depicted in Figure 5.1: For ap-
plying model checking, the ASM model has to be
transformed into the input language of the cho-
sen model checker. In Figure 5.1, the model in
input language of the model checker is denoted
as MC model. Once a model is transformed, we
benefit from fully automatically checking safety
and liveness properties which we call the require-
ments. If the model checker outputs a coun-
terexample the user has to inspect the erroneous
behaviour and correct the ASM model corre-
spondingly. For complex systems, a counterex-
ample yields a good insight into the behaviour
of the model. It is given as a sequence of states
that lead to a state in which the given require-
ment is violated. This sequence of states can be
fed into the simulation tool for ASM and thus
triggers a simulation run that shows the erro-
neous behaviour of the model (see discussion in
Section 6). The simulation of the counterexam-
ple is depicted by dotted lines reflecting that this
Transformation
Tool
Simulation Tool
debugging
Counterexample
ASM model
Model
Checker
MC model
Figure 5.1: The debugging process
interface is not yet implemented.
The transformation and checking procedure is implemented and runs fully automat-
ically. When the ASM model is changed in order to correct an error, the process can
be repeated. This repetitive debugging process works nicely if the transformation
is fast, and the checking procedure provides results in a reasonable span of time,
63
Chapter 5 Applying Model Checking to ASM
where the term “reasonable” depends on the personal taste of the user.
Making use of this approach, practical experience points out the limitations when
using particular checking tools. We also gain further insight of what has to be
considered when applying model checking to ASM models.
Limitations in the size of the state space. Firstly, the state space of the
model has to be finite and small enough. Although it might be easy to transform
ASM models with a huge state space, the resulting model might be too big for the
model checker. If the user has to wait for a response of the checker over several
days, the debugging process can hardly be followed. (Sometimes, even waiting for
some hours can be too long.) Thus, it is prudent to keep the model small enough.
A means of keeping a model small is abstraction.
In our first approach (see Chapter 6 on page 83), we use the SMV model checker
([McM93]), which gives no support for abstraction. We simply rely on finding a
suitable ASM model. In Section 2.1.2 on page 10, we introduced the practice of
modelling ASM on different levels of abstraction. Among those different layers we
might find a model that is small enough for being model checked – but on the other
hand big enough (in terms of being concrete) for expressing the properties we want
to check. However, this solution is not convincing. The process of modelling should
not be influenced by the later process of model checking. A level of abstraction
should not be chosen with respect to the resulting state space. Instead, modelling
should focus on a clear and succinct specification of the problem at hand. Models
that are succinct in terms of their textual representation and easy to understand do
not necessarily have a small state space; they may even have infinite state spaces.
In our second approach (see Chapter 4.2), we interface the ASM Workbench
with the MDG package ([CZS+97], [CCL+97]). This tool set supports abstraction
by means of its internal data structure that comprises abstract data types. We show
how to treat infinite models by introducing abstract types and functions into the
ASM specification language. The resulting abstract models can be seen as infinite
models. They can be checked within the MDG framework.
The state space has to be fixed. We call the state space of the model fixed
if the universes are not extended during a run. For model checkers, we have to
declare the domains of the state space before running the checking procedure. If we
would consider domains to be extendible they would be regarded as possibly infinite.
Thus, the state space can not be fully explored. It is generally impossible to treat
“open” domains that can be extended. In ASM, dynamic extension of universes
(or domains) can be modelled using the import rule (c.f., rule 2.7 on page 18 and
2.13). Therefore, the import rule is not treated by our transformation.
A different situation is given by introducing the notion of abstract types into
the ASM language when using the MDG approach. Domains of abstract type do
not require an interpretation, and thus they must not be enumerated. It might
be possible to treat import rules that introduce new constants into a domain of
abstract type. However, this case is not considered in the current implementation;
it is left as a task for future work.
With these restrictions, the model checking approach for ASM works not only
in principle, it works in practice too, as examples show (see for instance chapter
7.1 and 7.2). In most cases, however, we have to adapt the model at hand in
order to fit it to the model checking process. The following section summarises our
experiences and its consequences for model checking ASM. In Section 5.2, we give
an insight into the transformation algorithm that transforms ASM models into a
model checker language.
64
Modelling with Assumptions Section 5.1
5.1 Modelling with Assumptions
Most ASM — on a certain level of abstraction — not only comprise the specification
of state and state transitions, but have some additional assumptions. This is due
to the fact that modelling on an abstract level provides concise and understandable
models at the price of abstracting details that may influence the systems behaviour.
Often assumptions on these abstracted details are necessary for proving correctness
of the system. Figure 5.2 shows the layers of different abstraction levels, a modelling
practice that is already introduced in Section 2.1.2. The abstracted information that
is essential for the system’s behaviour is kept in assumptions that accompany the
structure and transition specification of an ASM (denoted in the figure as ASM0,
ASM1, etc). These assumptions may concern system inherent details or the external
world, i.e., the environment of the system.
1
2
0
ASM
ASM
.
.
.
.
.
.
ASM
Implementation
assumptions
assumptions
assumptions
Figure 5.2: Different Layers of Abstraction
Assumptions related to system inherent behaviour may be implemented in some
lower layer, at which the model is more concrete. We say the model is refined.
Refinement is depicted in Figure 5.2 by means of dotted arrows that lead from one
layer to the next. For the assumptions, the dotted lines indicate that through a
refinement step some assumptions are absorbed by the ASM model on the lower
level, others are kept as assumptions. Eventually the refinement leads ideally to
an implementation that can be executed on a machine. The ground ASM model,
the model at the topmost layer (ASM0in Figure 5.2), yields a basis for specifying
the details of the assumptions explicitly later on. Generally, we can use the ASM
language if we want to add the (otherwise lost) information to the ASM model.
Assumptions on the external environment of the system do not become part
of the system specification. They are rather stated in a declarative way. This is
common practice for the development of embedded systems that are not regarded
to be robust against arbitrary — possibly faulty — environment behaviour. That
is, we have to restrict the environmental behaviour the system is able to cope
with. However, we cannot specify the entire environment explicitly. If we want to
add this information about environment, the ASM language is not suitable. The
operational semantics of ASM forces us to explicitly describe what happens, but a
particular restriction to a certain kind of behaviour is hard to express. It is much
more convenient to use a kind of logic for keeping this information.
65
Chapter 5 Applying Model Checking to ASM
We give some simple examples for abstracted information that is given within
assumptions:
•In the ASM model of the bakery algorithm ([BGR94]) the ticket function T
that maps to each new customer a new ticket is abstract in the ground model.
It is specified as an external function. As an assumption over this function we
need to assure that the number of a newly given ticket is greater than that
of all other tickets that are already in the system. This way we guarantee a
sensible order for serving the customers. This information is formalised by a
logical formula. We assume that our external function Tsatisfies this logical
property. In the more concrete ASM model, the function Tis “implemented”,
i.e., it is explicitly modelled how Tis updated during a run of the model. The
external function becomes an “internal” one.
•Also within the ASM model of the bakery algorithm, we find that a fairness
assumption is necessary for proving correctness of the algorithm ([BGR94]).
At the moment there is no feature in the ASM language for expressing fairness
assumptions. Instead the fair behaviour of processes is stated informally in
the proof part.
•For embedded systems like the production cell ([Mea96] describes an ASM
model of this case study), the specification of the environment is abstract
and not part of the ordinary transition system. The behaviour of sensors is
formalised by means of oracles or external functions. However, it is necessary
to assume that the behaviour of the environment is “reasonable” in order to
guarantee correctness of the ASM model. In [Mea96] most assumptions are
given in terms of logical formulas that remain external also for the concrete
ASM model.
•For the specification of protocols, we might abstract away the underlying com-
munication model governing the transfer of messages, like in the ASM model
of the FLASH cache coherence protocol in [Dur98]. But for the proofs we have
to assume that the messages are transfered according to a particular strategy
(e.g. the FIFO-strategy, so that the ordering of messages is preserved). At
some lower level in the ASM hierarchy a proper message passing behaviour
has to be specified that implements the assumption made on the order of
transfered messages (cf. Section 7.1.3).
Obviously, only states, state transitions, and assumptions on the model together
give the complete specification of the problem at hand. This view is sketched in
Figure 5.2: the dashed box comprises all parts of a model at a particular level of
abstraction. Our transformation algorithm for ASM models treats the structure
and the transition rules of an ASM model. Additional information in the proof
part or in the textual part, including logical formulas, is not considered. Thus, this
information is lost after the transformation.
5.1.1 Model Checking without Meeting the Assumptions
Abstract behaviour is specified by oracles which are not influenced by the system
itself but by some outside world. They introduce non-determinism. In ASM terms
oracles are called external functions. External functions – in the case of finite
domains – can simply be transformed into corresponding functions or variables that
are not restricted, i.e., neither their initialisation nor their updating is specified.
Since model checking is “input-less” it is a complete test over the whole state space.
Any “loose” or non-restricted specification leads to a complete case distinction over
66
Modelling with Assumptions Section 5.1
all possibilities. The problems arising with this are not only a matter of the well-
known state explosion problem, but also of getting useless counterexamples: If we
fail to meet the additional assumptions on external functions, then the transformed
model that is model checked, comprises behaviour that is excluded in the complete
ordinary ASM model.
On the other hand, if we refine the model such that the assumptions are specified
in terms of transition rules, it is essential to prove that the refinement is correct.
Especially, we have to make sure that the refined model is not too restrictive. An
environmental behaviour that has a high degree of freedom cannot be modelled
properly in an operational way by using transition rules. Usually, it is too complex
to be fully specified and only some of the actually allowed behaviour is given. Model
checking a refined model that is too restrictive will potentially miss counterexamples
that would arise from behaviour that is not specified and thus excluded.
The situation can be formalised as follows. Let MASM be the set of ASM models,
MMC be the set of models that are input to the model checker, and RUN be the
set of runs of an ordinary temporal structure over branching time. The latter
provides a semantics that both kinds of model have in common. To give a more
precise notion of adding assumptions, we introduce mod and mod as two functions
that yields the semantics of a model such that mod :MASM →RUNand
mod :MMC →RUN. Problems may arise in two cases:
mod(MASM)⊂mod(MMC) (5.1)
mod(MASM)⊃mod(MMC) (5.2)
In the first case, relation (5.1) expresses that the transformed MC model is strictly
greater than the ASM model because of a loose specification of assumptions. The
set mod(MMC)\mod(MASM) may contain runs, that violate the property to be
checked. One of these will produce a counterexample that is not a proper run of
the ASM model. We can make no proposition on the model under investigation
since only one counterexample will be given. We call it a wrong counterexample;it
obstructs the overall debugging process.
In the second case, relation (5.2), we may fail to detect errors that occur only
in those runs of the ASM model that are excluded for the MC model. The runs in
mod(MASM)\mod(MMC) will not be checked by the model checker.
We treat the problem of missing assumptions within the case studies that we
examined (see Section 7.1 and 7.2). The solutions which we suggest depend on the
model checking tool in use. In the first approach, using the model checker SMV, we
model some assumptions explicitly by means of transition rules and conclude with
some restrictions for embedded systems (c.f., chapter 6). For fairness assumptions
the tool offers a special language construct.
In the second approach, using the MDG-package, we aim to include logical
parts which formalise the assumptions into the model that is input to the model
checker. This can be done by using linear temporal logic (LTL) for specifying the
assumptions. As described in Section 3.4 on page 38, we can construct a tableau
(which is a kind of transition system) from LTL formulas. The product automaton
of the ASM model under investigation and the tableau of the LTL formula precisely
specifies the ASM model plus the assumptions. The treatment of LTL with MDGs
is already investigated in [Xu99]. For further discussion see Chapter 8.
In the next section, we introduce the algorithm that transforms ASM transition
rules.
67
Chapter 5 Applying Model Checking to ASM
5.2 Transformation of Abstract State Machines
For the transformation, we assume that the ASM model is given in terms of domains,
functions and transition rules. That is, either we use a correctly refined model that
contains all additional assumptions, or the assumptions may be added later to the
model that is input for the model checker.
The development of the transformation depends naturally on the choice of the
tool we want to interface and its input language. For the sake of an efficient transfor-
mation, and a resulting model that is as simple as possible, we choose a tool among
those model checkers that are based on transition systems (e.g., SMV [McM93], VIS
[Gro96], SVE [F+96]), rather than model checkers that are treating process algebras
(e.g., FDR [For96] for CSP, the Concurrency Workbench [MS] for CCS, or CADP
[FGM+92] for LOTOS) or Petri nets for instance (e.g., the PEP-tool [GB96]). Our
choice does not imply that using these model checkers of a different kind is generally
impossible; only that the transformation would not be as straightforward and close
as in our case since ASM are basically transition systems. Therefore, we relate the
following considerations to the set of model checkers for transition systems among
all others.
ASM-IL model
SMV Tool MDG Tool
TRANSFORMATION
ALGORITHM
(first step)
TRANSFORMATION
into MDG
(second step)
TRANSFORMATION
to SMV
(second step)
MDG modelSMV model
ASM-SL model
ASM-WB
Figure 5.3: A generic Interface for ASM-WB
Since different model checkers (for transition systems) have different qualities, we
are interested in having more than one interface to one particular tool. Therefore, we
develop a more generic interface for the ASM-WB. Figure 5.3 shows the framework
of algorithms that link the ASM-WB to two model checkers. The generic interface
68
Transformation of ASM Section 5.2
is realised by splitting the transformation into two major steps:
1. In the first step, the ASM model is transformed into a flat, simple transition
system (in Figure 5.3 the ASM-IL model). The adjective “flat” indicates that
there are no nested rule structures left, and “simple” means that all complex
data structures are unfolded. This is a common representation for many
analysis tools treating transitions systems and it is tool independent.
2. The second step for any interface depends on the tool. It provides a transfor-
mation from the simple transition system into the syntax of the input language
of the chosen tool (in Figure 5.3 denoted as the SMV model and the MDG
model). In most cases, this can be done easily.
We use the ASM-WB ([Cas99]) as a core tool for editing, parsing, type-checking
and simulating models that are given in ASM-SL, a typed version of the ASM
notation. In our work, we suggest the use of the SMV model checker ([McM93])
and the MDG-package ([CZS+97]) (cf. Figure 5.3). Obviously, this choice is not
exhaustive. Within the workbench, a model is represented in an abstract syntax,
called ASM-AST. The transformation algorithm transforms, in the first step, a
model that is given in ASM-AST into the intermediate language, called ASM-IL.
An ASM-IL model provides a general interface for transition-system-based tools.
An interface from an ASM-IL representation to SMV for instance, which computes
the second step of the transformation, compiles an ASM-IL model into the syntax
of the SMV language.
The decoupling of the transformation into two steps provides the following ad-
vantages:
•The underlying schema for the transformation into a particular tool language
can easily be changed by tailoring the second transformation step only. For
this concern no insight into the ASM-WB and its internal representation
(ASM-AST) is necessary but rather a mere understanding of the transfor-
mation from ASM-IL into the language of the considered tool is sufficient.
This task is much less complex.
•The interface can be reused for other tools by replacing the transformation
from ASM-IL to the target language and by replacing the mapping from the
counterexample into the simulator of the ASM-WB.
The disadvantage of this generic interface is given by the fact that with apply-
ing the first step of the transformation, we lose all information about the model
structure. The ASM-IL format provides no means for expressing modularisation or
hierarchical structure. For the approaches we use so far, however, we cannot benefit
from structural information anyway. This claim is justified further in Chapter 6.
A similar approach for the use of a generic interface language can be found in
many tool frameworks. A very high-level intermediate language is given by SAL
(“the common intermediate language”, introduced in [BGL+00] and [Sha00]), for
instance. It is a formal language for which interfaces to various tools and algorithms
are already available. In contrast to our work, the focus for the development of SAL
was more tool-oriented: several tools were available and a common language was
built on top of them. A transformation of the ASM language into SAL would
be interesting in order to exploit the wide range of tool-interfaces. However, the
transformation would not be as close as the transformation to the ASM-specific
interface language ASM-IL.
A brief history of the development. In our first approach, we use the model
checker SMV for model checking ASM. In [Win97] a first transformation schema
69
Chapter 5 Applying Model Checking to ASM
from ASM into the SMV language is introduced. This schema is later used for
developing the interface from the ASM-WB to SMV. The results are published as
joint work with Giuseppe Del Castillo in [CW00]. [Win00] suggests, among other
results, optimisations to the original algorithm in order to make the transformation
feasible for large ASM models. For the use of MDGs, we extend the interface
further. This extension is introduced in [Win01].
In the following subsection, we give a definition of the mapping from ASM models
into the intermediate language. We point out in which way the transformation is
optimised in order to be feasible for large ASM models. The section ends with the
proof of correctness of the transformation.
5.2.1 The Transformation Algorithm
Simple transition systems treated by a model checker are specified in terms of a
set of states Sand a transition relation R:S→Sdefined over states. A state is
defined in terms of state variables si,1≤i≤n. For each state variable si,weuse
the primed variable s0
ito denote the state variable in the next state. Rdefines a set
of pairs (pre(s),post (s0)) with pre(s) as a pre-state of a transition given in terms
of (unprimed) state variables and post (s0) as a post-state of a transition given in
terms of next state variables s0.
Many model checker languages describe the transition relation with respect to
changes on each state variable individually (e.g., the SMV language, [McM93]), i.e.,
we get a set of pairs of the form (pre(s),post (s1,...,s
i−1,s
0
i,s
i+1,...,s
n)). The
post-state depends on the state variables that remain unchanged, and a single next
state variable that is changed, s0
i.
In ASM, the same information can be given as simple guarded updates of the
form
if gthen loci:= val.(5.3)
Following Section 2, the semantics of this guarded update is given with respect
to an expanded state B=(A, ζ), ∆B(loci:= val)ifB|=g. That is, the guard
gspecifies the set of states in which the transition fires. This is denoted above as
the pre-state of the transition, pre(loc), where loc =(loc1,...,locn) is the tuple of
locations of the ASM.
The semantics of the update ∆B(loci:= val) is given as a singleton {(loci,val)}.
Implicitly, each other location keeps its value. This specifies the set of post-states,
i.e., post (loc1,...,loci−1,loc0
i,loci+1,...,locn).
The identification of the notations, pre- and post-states and ASM updates, re-
quires the following two conditions:
1. We can identify the notion of locations with state variables, i.e., loci≡si.
Following the definition (2.11), a location is a pair loc =(f,a), where ais a
tuple of elements of SA. That is, a location is a function applied to particular
parameter values. Thus, each location can be identified with a state variable.
A renaming function maps each location pair (f,a) to a unique variable name.
2. The guard is a simple boolean term that depends only on unprimed locations,
i.e., g(loc).
Any ASM (with some restrictions as shown below) can be transformed into a set of
guarded updates of form of (5.3) that satisfies these requirements. We use simple
guarded updates as in (5.3) as our intermediate language (ASM-IL) for representing
ASM models. A shorter representation is given through the triple (loci,guard,val).
Since each location can be affected by different transition rules, each lociis, in fact,
70
Transformation of ASM Section 5.2
attached with a set of guarded updates, (loci,{guardj,valj|1≤j≤n}). If the
set of locations of an ASM model is given as {loc1,...,locm}then the behaviour
of the model can be represented as a set of guarded updates over all locations
{(loci,{guardj,valj|1≤j≤n})|1≤i≤m}. For the transformation of ASM
transition rules into the ASM-IL notation, we have to unfold the dynamic functions
into locations and simplify the rule structure.
Unfolding dynamic functions. The transformation into ASM-IL requires un-
folding of all dynamic and external functions occurring in the transition rules of a
model into locations.
Assume
f
:
S
1
:::
S
k
!
S
n
and
t
= (
t
1
;:::;t
k
)then
f
(
t
1
;:::;t
k
)
(
f;
a
1
)
(
f;
a
2
)
(
f;
a
m
)
...
where
8
i;
1
i
m
a
i
2
S
A
1
:::S
A
k
and
Val
A
(
t
)
2 f
a
i
j
1
i
m
g
.
Figure 5.4: Unfolding dynamic functions
Usually, the left hand side (LHS) of an update in an ASM transition rule is
given as a term f(t1,...,t
k), where fis a dynamic function symbol. The parameter
terms tican be dynamic or external functions as well, i.e., their evaluation is state
dependent. For generating a model for the model checker the locations have to
be evaluated (and declared) before rather than during the state exploration of the
checking process. Therefore, we have to unfold the terms into every possible value
that might occur during a run (see Figure 5.4). Recall that f:S1×...×Sk→Sn
specifies the type of the function symbol f.SA
iis a universe or domain (of sort Si),
i.e., a set of entities, in a particular state A.Val A(t) is the evaluation of a term t
in state A.
It is easy to see that the use of dynamic functions of large arity kincreases the
effort of unfolding exponentially. The number of locations unfolded from a function
fof type S1×...×Sk→Snis given with respect to a state Aby the product
card (SA
1)·...·card (SA
k), where function card gives the cardinality of the parameter
domains.1Lists of parameters for dynamic functions should be used with care when
modelling with ASM. Moreover, it is obvious that the domains SA
iin Figure 5.4
have to be finite. Otherwise the number of locations would be infinite theoretically,
and in practice the unfolding would not terminate.
The actual application of unfolding non-static terms is spread over two functions,
the term simplification [[ .]]andtherule unfolding Ewhich we introduce below. The
term simplification is inductively defined over rules and terms.
1Note that for any universe SA
i,card (SA
i) is constant for all states Asince we exclude expanding
universes. Universes have to be fixed.
71
Chapter 5 Applying Model Checking to ASM
Simplification function
For transforming an ASM model into ASM-IL format, we have to map each transi-
tion rule into a set of simple updates. That is, nested rules have to be flattened and
other rule constructs have to be mapped into guarded updates. We describe this
mapping as a function [[.]] ζ, called simplification function, that maps ASM-rules
into the simple guarded update notation of ASM-IL and also simplifies unfolded
ASM-IL rules further (see rule unfolding function Ebelow). It is defined in terms
of a variable assignment ζ:V→SA, which maps each free variable to a value (c.f.,
definition 2.6). This definition coincides with the elaboration in [Cas00]. Firstly,
we give a definition of the simplification function [[.]] ζfor terms and for transition
rules. At the end of this section, we prove for each rule Rthat the simplification
function preserves the semantics of R.
Simplifying terms. The simplification mapping [[.]] ζmaps all terms that occur in
the ASM rules, for instance, the LHS and the right hand side (RHS) of an update
rule, or guards in conditional or do-for-all rules. Mapping terms provides the
inductive base of the simplification function and ensures that the application of
[[ .]] ζto any rule over finite domains terminates.
We distinguish three base terms: constant values,locations that can be identified
with state variables, and variables that occur free. The simplification of a term
terminates if the result consists of only these base terms. All other terms have to
be simplified further. This is captured in the following points.
•Values (or constants) of any sort a∈SA
i(they are constant in any state A)are
not affected by the simplification2. (For convenience from now on we denote
values with a.)
[[ a]] ζ=a
•Locations loc =(f,a) are not affected by the simplification either3:
[[ loc ]] ζ=loc
•Variables are mapped to values by the variable assignment ζif they are in its
domain.
[[ v]] ζ=a=ζ(v)ifv∈dom(ζ)
votherwise
•For function applications we distinguish two cases: either all parameters of the
function are values or some of the parameters have to be simplified further.
a.) Function applications which comprise only values as parameters are sim-
plified to values if the function symbol is static and can be evaluated
independently of the state. If the function symbol is dynamic or ex-
ternal, i.e., its evaluation is state-dependent, the term is mapped to a
location (f,a).
[[ ti]] ζ=aifor each i∈{1,...,n}⇒
[[ f(t1,...,t
n)]]ζ=(a=fA(a1,...,a
n)iffis a static function name
loc =(f,(a1,...,a
n)) if fis a dynamic/external
function name
2Note that constants do not occur in an ASM but in ASM-IL. The simplification function can
be applied to ain the second simplification step (after unfolding a rule by E).
3For locations holds the same, they do not occur in ASM but in ASM-IL. A second application
of [[.]] ζis possible after rule unfolding.
72
Transformation of ASM Section 5.2
where fAdenotes the interpretation of a static function symbol fin any
state A.
b.) For terms which comprise non-values, i.e., locations or not yet evaluated
functions, the term simplification is applied to the parameters.
[[ ti]] ζ=loc or [[ti]] ζ=f0(t)forsomei∈{1,...,n}⇒
[[ f(t1,...,t
n)]]ζ=f([[t1]] ζ,..., [[ tn]] ζ)
•First order terms (∃v:g(v))s(v)and(∀v:g(v))s(v) can be simplified if we
assume that the guard of the first order term g(v) has a finite range, i.e.,
RangeA(v:g(v)) = {a∈SA
i|A|=g(a)}={a1,...,a
n}is a finite set. In this
case, the variable assignment ζis refined to a mapping that maps the head
variable vto values of RangeA(v:g(v)), i.e., ζ[v7→ ai]for1≤i≤n.The
body s(v) is further simplified with respect to this refined variable assignment.
Existential quantification naturally leads to a disjunction over all assignments
of v, and universal quantification to a conjunction.
[[((∃v:g(v)) s(v)) ]]ζ=[[ s(v)]]ζ[v7→a1]∨...∨[[ s(v)]]ζ[v7→an]
[[((∀v:g(v)) s(v)) ]]ζ=[[ s(v)]]ζ[v7→a1]∧...∧[[ s(v)]]ζ[v7→an]
Simplifying transition rules Once the inductive base of the simplification func-
tion [[.]] ζis defined, we can continue with the simplification of transition rules.
1. The skip rule is not effected by the simplification:
[[ skip ]] ζ=skip
2. An update rule is simplified by the unfolding of the LHS as described above.
The RHS might depend on dynamic functions as well and is therefore treated
in the same way. As a default guard we introduce true to indicate that the
precondition is not restricted:
[[ f(t):=t]] ζ=if true then [[ f(t)]]ζ:= [[ t]] ζ
3. A block-rule is simplified by means of simplifying each of its sub-rules:
[[ block R1... R
nendblock]] ζ=[[R1]] ζ... [[ R2]] ζ
4. Simple conditional rules give a collection of guarded updates. The update
of each location in the then-case or in the else-case is considered separately
with respect to the guard and its negation respectively:
[[ if g
then f1(t1):=v1
...
fn(tn):=vn
else g1(s1):=w1
...
gm(sm):=wm
endif ]] ζ
=
if [[ g]] ζthen [[ f1(t1)]]ζ:= [[ v1]] ζ
...
if [[ g]] ζthen [[ fn(tn)]]ζ:= [[ vn]] ζ
if ¬[[ g]] ζthen [[ g1(s1)]]ζ:= [[ w1]] ζ
...
if ¬[[ g]] ζthen [[ gm(sm)]]ζ:= [[ wm]] ζ
73
Chapter 5 Applying Model Checking to ASM
For nested conditional rules we have to collect, for each internal update, all
influencing guards or their corresponding negation:
[[ if g1then
if g2then f1(t1):=v1
... endif
else
if g3then h1(p1):=r1
... endif
endif]] ζ
=
if [[ g1]] ζ∧[[ g2]] ζthen [[ f1(t1)]]ζ:= [[ v1]] ζ
...
if ¬[[ g1]] ζ∧[[ g3]] ζthen [[ h1(p1)]]ζ:= [[ r1]] ζ
...
Note that the guards have to be simplified as well since in the intermedi-
ate representation they should depend only on locations and not on n-ary
functions.
This schema is inductively captured for all possible inner rules as
[[ if gthen R1else R2]] ζ=if [[ g]] ζthen [[ R1]] ζ
if ¬[[ g]] ζthen [[ R2]] ζ
5. do-for-all rules can be mapped into a collection of rules that are instantiated
for each possible value of the head variable. For a rule as given below, the
value of the head variable vis chosen among values in its range RangeB(v:
g(v)) = {a∈SA
i|B|=g(a)}. We assume that the sort SA
iis a finite
set {a1,...,a
m}. The guard g(v) in the head of the rule is used – after
instantiating the parameter vwith its value – as a guard for the simple guarded
update.
[[ do forall v:g(v)
R0(v)
enddo]] ζ
=
if [[ g(a1)]]ζthen [[ R0(a1)]]ζ
...
if [[ g(am)]]ζthen [[ R0(am)]]ζ
6. A choose-rule is not treated by our transformation but it can be “simulated”
by means of an external function ext that is element of RangeB(v:g(v)) (see
Definition 2.9). This external function ext is non-deterministically evaluated
totheparametervaluetobechosen:
choose v:g(v)
R0(v)
endchoose
⇔if [[ g(ext)]]ζthen [[ R0(ext)]]ζ
where the range of the head variable vis RangeB(v:g(v)) = {a∈SA
i|B|=
g(a)}and ext is an external nullary function of the same type as v, i.e., SA
i.
7. import-rules are not treated by the transformation since they extend the
domains of the model. Model with non-fixed state space can not be treated
by the model checkers we investigated since this requires the declaration of
infinite domains in general.
Rule unfolding
Simplified rules and terms may still contain functional terms with locations as pa-
rameters, e.g., f(...,locj,...). These terms have to be unfolded such that each
location in the parameter list is substituted with a possible value of its domain
(c.f., Figure 5.4). For each of these substitutions, we generate a new instance of the
rule in which the location occurs as a parameter. This procedure is given as the
unfolding function which is described below.
74
Transformation of ASM Section 5.2
Unfolding of rules. When we unfold transition rules we replace all locations
that appear as parameters of functions with their possible evaluation. Locations
that occur on the LHS of an update are left unchanged. We define the function E
that maps rules to unfolded rules.
•A rule that contains only simple updates of locations, i.e., no location occurs
on the RHS of an update, remains unchanged by the rule unfolding function.
E(R)=Rif R=(loc1:= a1... locn:= an)
•A rule where loc is the first location occurring in Rbut not as an LHS of an
update rule is unfolded into ninstances when the range of the location loc is
{a1,...,a
n}. The generated rules instances are simplified further by means
of applying function [[.]] ζ.
E(R(loc)) =
if loc =a1then E([[R[loc/a1]]]ζ)
...
if loc =anthen E([[R[loc/an]]]ζ)
The notation R[loc/ai] denotes an instance of rule Rin which every occurrence
of loc is substituted by value ai.
For every possible value aiof a location, a new rule instance has to be generated
which is guarded by the equation loc =ai. This causes alot of code to be duplicated
and the resulting model can grow very big. This problem is address below.
Optimisation. The unfolding of rules may generate of lot of ASM-IL code due
to the fact of duplicating rules while instantiating locations. Since unfolding and
simplification are interleaved in our implementation, a large part of the ASM-IL
rules can be simplified. In particular, the simplification of guards reduces the code
significantly. (Note that guards are boolean terms that can be evaluated.) For
instance, the (unfolded) guard (time = 10) ∧(time >20), of course, evaluates to
false.
More often occurs the case in which an equation over a simple location is un-
folded. For example let mode be a simple location that may evaluate to stop,run,
and wait. A guard of the form (mode =stop) is firstly unfolded into three instances
of the guard: (mode =stop)∧(stop =stop), (mode =run)∧(run =stop), and
(mode =wait)∧(wait =stop). The second and the third instance are simplified
to false and the resulting instance of the guard is (mode =stop)∧true,whichis
obviously correct.
Still the effort of unfolding and simplifying is significant. A first implementation
without any optimisation led to a bottleneck that obstructed, in some cases, the
whole model checking approach.
The crucial point for a successful optimisation of the algorithm is that the func-
tional terms to be unfolded should be chosen with care. Unnecessary unfolding
has to be avoided. For instance (this probably caused the major problem; com-
pare the example above), a simple equation in a guard loc =ais internally (i.e.,
in ASM-AST) represented as a function application with a location as parameter,
i.e., =(loc,a
i). Thus, this term is unfolded and nrule instantiations are generated
if loc ranges between a1,...,a
n(see Figure 5.5). All unfolded guard terms are sim-
plified again to false except the one that evaluates to true when the simplification is
applied. The result will be one rule instance only. However, this unnecessary unfold-
ing and simplifying is very complex, especially since these kind of equations occur
quite often in ASM rules. Therefore unfolding of equational terms, for instance, has
to be avoided.
75
Chapter 5 Applying Model Checking to ASM
if (
loc
=
a
i
) then
R
(
loc
)
if (
a
1
=
a
i
) then
R
(
a
1
)
...
if (
a
2
=
a
i
) then
R
(
a
2
)
if (
a
n
=
a
i
) then
R
(
a
n
)
if
true
then
R
(
a
i
)
1.unfolding 2.simplification
Figure 5.5: Unnecessary unfolding of equations
Based on this preliminary understanding, we conclude with the following more
general solution. All symbolic model checkers are able to treat at least simple
boolean operations for equality, conjunction and disjunction since these can be
represented by decision diagrams. In the input language of SMV model checker,
also simple arithmetic operations are defined (see [McM93]). We define the set of
operations that are treated by the model checker as primary operations.Termsthat
denote these operations must not be unfolded even if they contain locations. They
are simply mapped into the proper model checker syntax later on (i.e., in the second
step of the transformation). That is, for any term f(t1,...,t
n)wheresomeofthe
parameters tiare locations we test if fis a function symbol that denotes a primary
operation. If it is, then we keep it, otherwise we unfold the location.
Multi-Agent ASM We treat multi-agent ASM, which models concurrent or dis-
tributed systems, by means of an interleaving semantics.
The basic idea of multi-agent ASM is that the system consists of several agents
identified with the elements of a finite set AGENT (which are actually a sort
of “agent identifiers”). Each agent a∈AGENT executes its own parameterised
program prog(a). As a general parameter, we use a special nullary function
Self :AGENT .
To map a multi-agent ASM model with agents ai∈AGENT into ASM-IL
notation, we consider parameter Self as an external function which determines the
active agent. We assume that there is one program P, shared by all agents, possibly
performing different actions for different agents. The FLASH model presented in
Section 7.1 is an example of this style of modelling in which all agents execute
exactly the same program, but on different data.
Due to the external function Self , which is treated as a location that has to be
unfolded, a multi-agent model is mapped into a collection of ASM-IL rules that are
guarded by the evaluation of Self , e.g.,:
if Self =a1then prog(a1)
...
if Self =anthen prog(an)
where {a1,...,a
n}are the agents and prog(ai) is the rule to be executed by agent
ai, i.e., the “program” of ai.SinceSelf is an external function its value is chosen
non-deterministically and denotes the agent that is currently active. This results in
a model with an interleaving semantics which allows any order for the sequence of
76
Transformation of ASM Section 5.2
active agents.
Based on the representation of models in ASM-IL which is provided by per-
forming the first step of the transformation, the second step of the transformation
generates a model in the proper syntax of the chosen model checker. The second
step is thus tool dependent and is introduced in the corresponding Chapters 6 and
8 for the interface to SMV and the MDG-package, respectively.
Correctness of the simplification function
Simplification and unfolding as given above transform an ASM model into an ASM-
IL model. This transformation is not a mere syntactical mapping since terms are
partly evaluated: static terms are evaluated by [[.]] ζ, and locations are unfolded to
values by E. Due to this fact, the semantics of ASM (see the definition in Chapter
2) is slightly different to the semantics of ASM-IL. We define ∆0
Bas deterministic
semantics and N0
Bas non-deterministic semantics for ASM-IL as follows:
Definition 5.22: Semantics for ASM-IL
For any ASM-IL rule R≡loc := val ,whereloc is a location and
val is a value, the deterministic semantics is given as
∆0
B(R)={(loc,val)}
and the non-deterministic semantics is given as
N0
B(R)={∆0
B(R)}.
For any other ASM-IL rule R0∆0
B(R0)=∆
B(R0); N0
B(R0)isequalto
the definition of NB(R0) with every occurrence of ∆B(.) replaced by
∆0
B(.). Note that N0
Bcan be applied to several rules:
N0
B(R1,...,R
n)={setT uple(t)|t∈N0
B(R1)×...×N0
B(Rn)}
where setTuple(s1,...,s
n)=s1∪...∪sn.
Following the definition above, the only difference between these semantics is
given by the evaluation of terms in update rules. Terms in ASM-IL are already
evaluated. Apart from that, the semantics is the same for both languages.
We now prove the correctness of the simplification of terms and of transition
rules. Note that [[.]] ζapplied to a constant aor a location loc (which are ASM-IL
terms) has no effect.
Terms. When applied to static functions or variables, the simplification function
[[ .]] ζis identical to the evaluation function Val Bon terms (see Definition 2.8). Both
functions are defined with respect to ζ, which evaluates variables, and both functions
map static functions to their value. If the term is an application of a dynamic or
external function then the simplification does not evaluate this term but maps it to
alocation.
The difference between the functions Val Band [[.]] ζis that [[.]] ζmaps terms
independently of a state and Val Bmaps terms with respect to a state. In fact,
the term evaluation Val Bis defined with respect to an expanded state B,B=
(A, ζ). Simplification [[.]] ζmaps terms whose evaluation depends on a state (i.e.,
applications of dynamic or eternal functions) to locations (see Definition 2.11). We
give the proof of correctness of the simplification function [[.]] ζin two steps:
77
Chapter 5 Applying Model Checking to ASM
a.) [[.]] ζtransforms, where possible, a term into Val B(t); for this case we distin-
guish the following:
- a nullary static function fis mapped to its interpretation, i.e., [[f]] ζ=
fA=Val B(f);
-avariablevis mapped to its variable assignment, i.e., [[v]] ζ=ζ(v)=
Val B(v);
-iffis a static function name and ¯ais a tuple of values then f(¯a)is
simplified to fA(¯a) which is equal to Val B(f(¯a));
-iffis a static function name and tiare static terms (for 1 ≤i≤n)
then f(t1,...,t
n) is simplified to fA([[t1]] ζ,..., [[ tn]] ζ) which is equal to
fA(Val (t1),...,Val B(tn)) = Val B(f(t1,...,t
n)) by Definition 2.8.
b.) [[.]] ζtransforms dynamic/external terms tthat cannot be evaluated inde-
pendently of the state into locations (i.e., state variables) i.e., [[t]] ζ=loct.
We prove that this location has the value Val B(t)atanystateA,where
B=(A, ζ). Assume in the following that fis a dynamic or external function
symbol, B=(A, ζ), ¯a=(a1,...,a
n), and loci=(f,(¯a)):
-Iffis a nullary function, it is mapped to its location, i.e., [[f]] ζ=locf.
According to Definitions (2.11) and (2.8), this location has the value
fA=Val B(f)inanystateA.
-Iffis a n-ary function and ¯aa tuple of values then f(¯a) is simplified
to the location loci=(f,(¯a)). According to Definitions (2.11) and (2.8),
locihas the value fA(¯a)=Val B(f(¯a)).
- It remains to prove that the semantics is also preserved for functions with
dynamic parameters that are given in terms of dynamic parameters, i.e.,
if we have a nested application of dynamic functions. This can be done
by induction over the depth nof nested dynamic function application in
the term.
Assume gi,for1≤i≤n, are dynamic functions. Without loss of
generality, let all gibe unary functions. Furthermore, we assume that
the nesting of dynamic function application is finite. That is, for any
term gn+1(gn(...(g1(g0(¯
t))) ...)), g0is a dynamic or static function that
is applied to only values.
Induction base: We proved already that [[g0(¯
t)]]ζequals to Val B(g0(¯
t)).
Induction step: Assume t=gn(...(g0(¯
t)) ...)and [[t]] ζis simplified into a
location locgn.Wehavetoprovethat[[gn+1(t)]]ζ=Val B(g(t)): Accord-
ing to the definition of [[.]] ζ,[[gn+1(t)]]ζ=gn+1([[t]] ζ). With the induction
hypothesis we get gn+1(locgn).
The location locgn is unfolded by the rule unfolding Eto any possible
value since it is not an LHS of an update. Thus, gn+1(locgn) is simplified
and unfolded into a set of locations; for each value of locgn we get a new
location. Analogously to the proof given above, we can state that this set
of locations is equal to the locations that are defined by gn+1(t). Their
state-dependent interpretation is preserved.
c.) First order terms of the form (∃v:g(v)) s(v)or(∀v:g(v)) s(v)aresim-
plified to their value. Assume t=(∃v:g(v))s(v)andRangeB(v:g(v)) =
{a1,...,a
n}(note that the range has to be finite for applying the simplifica-
78
Transformation of ASM Section 5.2
tion function, see the definition of [[.]] ζ). Then
[[ t]] ζ
(according to the definition of [[.]] ζ)
=[[s(v)]]ζ[v7→a1]∨... ∨[[ s(v)]]ζ[v7→an]
(according to the correctness proof above and Definition (2.7))
=Val B(v7→a1)(s(v)) ∨... ∨Val B(v7→an)(s(v))
=true,if Val B(v7→a1)(s(v)) for some a∈{a1,...,a
n}
(according to first order term evaluation, Def. (2.10))
=Val B(t).
Similarly, it follows that [[(∀v:g(v)) s(v)]]ζ=Val B((∀v:g(v)) s(v)).
Transition Rules. In ASM, the semantics of deterministic transition rules is
defined through the operator ∆Band that of non-deterministic transition rules
through the operator NB(see Chapter 2). Analogously, we defined the semantics
for ASM-IL rules (see Definition (5.22)), ∆0
Band N0
B. Since the transformation
treats choose-rules as well, we have to use the semantics for non-deterministic
transition rules to prove the correctness of the transformation of rules. We have to
show that for any rule R,NB(R)=N0
B([[R]] ζ).
1. skip rules:
Following the definition of [[.]] ζ, the skip rule is not affected by the simplifica-
tion:
N0
B([[skip ]] ζ)=N0
B(skip)={{}} =NB(skip)
2. update rules:
Assume ¯
t=(t1,...,t
n), ¯a=(a1,...,a
n)andVal B(ti)=ai
for every i,1≤i≤n.
N0
B([[f(¯
t):=t]] ζ)
=N0
B(if true then [[ f(¯
t)]]ζ:= [[ t]] ζ) (according to the definition of [[.]] ζ)
=N0
B([[f(¯
t)]]ζ:= [[ t]] ζ)(foranystateAsince A|=true,
i.e., the guard is always satisfied)
=N0
B((f,(¯a)) := Val B(t) ) (according to the definition of [[.]] ζ
and the proof of correctness above)
={∆0
B((f,(¯a)) := Val B(t))}(according to the definition of N0
B)
={{((f,(¯a)),Val B(t))}} (according to the definition of ∆0
B)
={∆B(f(¯
t):=t)}(according to the definition of ∆B)
=NB(f(¯
t):=t) (according to the definition of NB)
3. conditional rules:
N0
B([[if gthen R1else R2]] ζ)
={setTuple(t)|t∈N0
B(if [[ g]] ζthen [[ R1]] ζ)×N0
B(if ¬[[ g]] ζthen [[ R2]] ζ)}
(according to definition of [[.]] ζand Definition (5.22) )
•If B|=[[g]] ζ,thisevaluatesto
{setTuple(t)|t∈N0
B([[R1]] ζ)×N0
B([[skip ]] ζ)}
={setTuple(t)|t∈N0
B([[R1]] ζ)× {{}}}
=N0
B([[R1]] ζ) (according to Definition (5.22))
79
Chapter 5 Applying Model Checking to ASM
•If B|=¬[[ g]] ζ,thisevaluatesto
{setTuple(t)|t∈N0
B([[R2]] ζ)×N0
B([[skip ]] ζ)}
={setTuple(t)|t∈N0
B([[R2]] ζ)× {{}}}
=N0
B([[R2]] ζ) (according to Definition (5.22))
If we assume that N0
B([[Ri]] ζ)=NB(Ri)fori∈{1,2}, it remains to prove
that in any expanded state B
B|=[[g]] ζ⇔B|=g.
With the proof of the correctness of term simplification given above, we get
[[ g]] ζ=Val B(g) for any boolean term or any first order term g. It follows that
gand [[g]] ζare satisfied in the same states and thus
N0
B([[if gthen R1else R2]] ζ)=NB(if gthen R1else R2).
4. do-forall rules:
Assume that ai∈RangeB(v:g(v)), where 1 ≤i≤n.
N0
B([[do forall v:g(v)R0(v)enddo ]] ζ)
={setTuple(t)|t∈N0
B(if [[ g(a1)]]ζthen [[ R0(a1)]]ζ)
×...×N0
B(if [[ g(an)]]ζthen [[ R0(an)]]ζ)}
(according to the definition of [[.]] ζand Definition (5.22))
Assuming without loss of generality that RangeB(v:g(v)) = {a1,...,a
i},
where i≤n,weget
{setTuple(t)|t∈N0
B([[R0(a1)]]ζ)×...×N
0
B([[R0(ai)]]ζ)
×N
0
B([[skip ]] ζ)×...×N
0
B([[skip ]] ζ)}
where the expression N0
B([[skip ]] ζ) occurs (n−i) times. These expressions
represent the else-cases where the guard is not satisfied. According to the
definition of setTuple and the semantics of skip rules, this equals
{setTuple(t)|t∈N0
B([[R0(a1)]]ζ)×...×N0
B([[R0(ai)]]ζ)}
If we assume that N0
B([[R0(ai)]]ζ)=NB(R0(ai)) for any ai, this equals the se-
mantics of the non-deterministic do-forall rule (see Definition (2.17)). Thus,
we get
N0
B([[do forall v:g(v)R0(v)enddo ]] ζ)
=NB(do forall v:g(v)R0(v)enddo).
80
Transformation of ASM Section 5.2
5. choose rules:
N0
B([[choose v:g(v)R0(v)endchoose]] ζ)
=N0
B(if [[ g(e)]]ζthen [[ R0(e)]]ζ) (according to definition of [[.]] ζ)
where eis a nullary external function whose value is chosen non-
deterministically from the set {ai∈SA
i|B|=[[g(ai)]]ζ}.SinceB|=[[g(e)]]ζ,
this evaluates to
{setTuple(t)|t∈N0
B([[R0(e)]]ζ)×N0
B([[skip ]] ζ)}
={setTuple(t)|t∈N0
B([[R0(e)]]ζ)× {{}}}
=N0
B([[R0(e)]]ζ) (according to Definition (5.22))
Since e’s value is chosen non-deterministically, this expression is equal to the
set
S
a∈RG
N0
B(e7→a)([[R0(e)]]ζ)whereRG ={ai∈SA
i|B|=[[g(ai)]]ζ}.
If we assume that N0
B([[R0(e)]]ζ)=NB(R0(e)) for any R0, it remains to prove
that in any expanded state B, for any value ai
B|=[[g(ai)]]ζ⇔B|=g(ai).
With the proof of the correctness of term simplification given above, we get
[[ g(ai)]]ζ=Val B(g(ai)) for any boolean term or any first order term g(ai). It
follows that g(ai)and [[g(ai)]]ζare satisfied in the same states and thus
N0
B([[choose v:g(v)R0(v)endchoose]] ζ)
=NB(choose v:g(v)R0(v)endchoose).
This completes the correctness proof of the transformation algorithm from ASM
transition rules into ASM-IL. Due to the simplicity of ASM-IL, the transformation
from ASM-IL into the model checker language is very easy.
The next chapters introduce two applications for this general interface: We build
on top of ASM-IL an interface to the SMV model checker and an interface to the
MDG-package. The former is described in the next chapter. Chapter 7 illustrates
this approach using two case studies.
81
Chapter 5 Applying Model Checking to ASM
82
Chapter 6
The SMV Model Checker
Model checking is a powerful means of supporting the analysis of system models
in an early stage of development and design. As we discussed in the last chapter,
model checking is applicable to ASM models. By means of an interface between an
ASM tool framework for developing ASM models and a given model checker, we
can provide automatic tool support for analysing ASM.
In the last chapter, we introduced our general interface language ASM-IL for
the ASM Workbench (ASM-WB, c.f., [Cas00] and see also Section 2.3) which is
a framework for editing, parsing, type-checking, and simulating ASM-SL models.
Given the ASM-IL format, this chapter shows how we build a transformation to
the input language of the model checker SMV ([McM93]) on top of it. This work
completes the interface between the ASM-WB and the model checker SMV. SMV
has been chosen as a typical representative of a class of model checkers based on
transition systems. It could be easily replaced by another model checker that is
based on a similar approach, e.g., SVE [F+96] or VIS [Gro96].
Our transformation tool also supplies SMV with a higher-level modelling lan-
guage, namely ASM-SL. This facilitates the modelling task by allowing the use of
more complex data types, in particular n-ary functions. Functions generalise the
classical notion of state variables and allow parameterisation. Therefore, ASM mod-
els, in comparison with similar SMV models, are more concise yet more general by
means of using parameters. Also, ASM models can be scaled up more easily than
SMV models.
The process of transforming an ASM model into the corresponding SMV model
is fully automatic. The implementation of the algorithms introduced in this work
is available for the ASM-WB, Version 0.99 (University of Paderborn, 1997-99) and
SMV 2.5.3.1b (Carnegie Mellon University, November 1998).
In the following section, we give an overview of the SMV tool with its features
and describe the SMV input language. This language is the target language of
the transformation. Based on this, we compare ASM and the SMV language. In
the next section, we introduce how to extend the generic interface (as described in
Chapter 5.2) to complete the transformation algorithm from ASM into the SMV
language.
We evaluate the use of SMV for checking ASM models by means of two case
studies: the FLASH cache coherence protocol as a distributed architecture of com-
municating processes, and the Production Cell as an embedded system. Both case
studies have their own special intricacies and involve a particular solution. These
are introduced in the next chapter.
83
Chapter 6 The SMV Model Checker
6.1 The SMV Tool
SMV is a tool for symbolic model checking of CTL formulas (see Section 3.3.3). It
was introduced by McMillan in [McM93]. Since this time, the original implemen-
tation has been reworked and further developed in various directions: McMillan
has developed his own version known as Cadence SMV (see [Mil]); at the Carnegie
Mellon University the original version of SMV has been maintained and as a re-
implementation and extension the model checker NuSMV ([CCGR99]) is launched.
The CMU furthermore promotes the framework SyMP, which is a combination of
the model checker SMV and some decision procedures for satisfiability (SAT solvers)
([Ber99]). SMV can be seen as the dinosaur of the family of symbolic CTL model
checkers. As visible through the literature, the tool is widely used and often com-
pared with other tools.
The SMV tool takes a sys-
tem specification and a require-
ment specification as input (see
Figure 6.1). Based on this,
it checks if the system satis-
fies the requirements (c.f., the
introduction given in Section
3.3). The system specification
has to be formalised as a tran-
sition system in the SMV lan-
guage. The requirements have
to be formalised in CTL. If the
system model violates the re-
quirements, the SMV tool com-
putes a counterexample. A
System
Specification Requirement
Specification
SMV Tool
Counterexample Resource
Information
Figure 6.1: The SMV model checker
counterexample is a possible run of the system which is given as a sequence of
states. These states are specified by means of the particular evaluation of the state
variables. This depiction is shortened such that only those state variable evaluations
that are changed in the last step are listed. State variables which are not listed have
not changed their value. A counterexample is very useful for debugging the system
model under investigation. As a further output, SMV provides information about
resources that are used: the size of the internally computed BDD structure and
the computational effort of the checking procedure in time and space. This allows
the user to compare the effort used for different modelling approaches and also to
compare the resources used by the SMV tool with resources needed by other model
checkers for checking a similar model.
Simulating the Counterexample
In order to support the debugging process, we aim at a bidirectional interface
between the ASM-WB and the SMV tool. That is, the counterexample that is
output by the SMV tool should be re-transformed into the ASM-WB. This re-
transformation allows for simulating runs of the investigated ASM model.
Although this facility is not yet implemented, it is conceptually easy to realise:
The simulator of the ASM-WB computes in each step the next state of a run
according to the transition rules. If the model behaves non-deterministically by
means of external functions, the simulator asks the user for input. As a response,
the user has to determine the behaviour of the external functions in the next step.
Since a counterexample given by the SMV tool specifies the evaluation of each
state variable, we can use the counterexample as input for the simulator. By means
of a filter mechanism, we choose those state variables that result from transforming
84
The SMV Tool Section 6.1
the external functions. The evaluation of these (former external) state variables
can be used to trigger the simulation run. As a consequence, this run leads to the
erroneous state that is indicated by the counterexample. The simulation of the
counterexample in the ASM-WB could be executed automatically.
6.1.1 The SMV Language
The SMV tool provides the user with its own specification language, the SMV
language. Its syntax and semantics is defined in [McM93]. We recall here the basic
features only1. Basically, this language facilitates the specification of the system
model and its requirements.
The system model. The system model is a transition system with a set of states,
a subset of initial states, and a transition relation that specifies the behaviour. A
system is defined as a module (beginning with the keyword MODULE) that may consist
of several submodules.
A module describes a synchronous or asynchronous process. It is an encap-
sulated collection of declarations (given as VAR,INIT,ASSIGN,FAIRNESS or SPEC
declarations, see below) that may depend on specific parameters. These parameters
have to be instantiated within the calling module (i.e., the parent). In particular,
each process has an implicit parameter running, a boolean variable that indicates
if the process is active or not.
The state (or the state space) of a module is given by declaring state variables
of a certain type. This declaration is headed by the keyword VAR. Suitable types
that can be used in the declaration part are the set of Boolean values (where false
is represented as 0 and and true as 1), an enumeration of constants, or modules
that specify synchronous or asynchronous sub-processes (for the latter, the keyword
process is used).
The set of initial states can be specified as a conjunction of equations that
specify the initial evaluation of state variables. This boolean formula is headed by
the keyword INIT. If the initial value of a state variable is not specified, any value
(of its declared type) is a suitable initial evaluation. The result is a set of initial
states rather than a single initial state.
The transition relation of a module is specified in the section headed by the
keyword ASSIGN. It contains a list of value assignments to the state variables. The
semantics of assignments is given as a next-step evaluation: all assignments are
applied simultaneously in one step and thus define the next state by means of a
new evaluation of state variables. The state variables on the left-hand side of an
assignment are wrapped by the function next to specify the corresponding next
state variable. The right-hand side of an assignment is an expression. Expressions
comprise operators of boolean logic, some operators for integer arithmetic (e.g.,
addition, subtraction, or multiplication), and a case construct which lists various
cases for an assignment guarded by a condition. Each case comprise a condition and
a value or an expression that should be assigned in case the condition is satisfied.
In every run of the model, only the first case in the case expression whose condition
is satisfied is applied and the state variable is assigned with the corresponding value
or expression.
The requirements. For specifying the requirements to be checked, the SMV
language provides the syntax for CTL. It comprises boolean operator for negation
(!), conjunction (&), disjunction (|), logical implication (->), and logical equivalence
1Our description is not exhaustive but restricted to the features that are interesting in our
context.
85
Chapter 6 The SMV Model Checker
(<->) of simple formulas. The temporal operator X,F,G,andUare defined
as well as the path quantifiers Eand A(c.f., Definition 3.16 on page 29). The
requirements are declared under the heading SPEC.
Fairness. As another basic feature, the SMV language provides a means for spec-
ifying fairness constraints (see Section 3.5) (keyword FAIRNESS). A fairness con-
straint is a CTL formula. It allows the designer to restrict the investigated runs
of a module to those which are fair with respect to the given fairness constraints.
That is, these constraints are true infinitely often during each run of the fair system
module.
6.1.2 ASM versus SMV Language
A comparison of ASM and the SMV language leads to the following points:
•Both notations have in common that a next state in a computation is reached
by simultaneous assignment of new values.
•Both languages have a notion for modules (or processes). In ASM, these are
called agents. We can model processes that run simultaneously (all processes
are active concurrently) or specify an interleaving behaviour (only one process
is active at each time). In the SMV language, interleaving semantics is forced
by using the keyword process when declaring a module component. In ASM,
an interleaving semantics can be modelled by means of external functions: If
in a multi-agent ASM the parameter Self that indicates the currently active
agent is declared as an external function, it evaluates to a particular value at
each state. That is, no two processes are active at the same time.
•Both languages do not provide a particular model for communication between
concurrent modules.
•ASM allows the designer to model in terms of n-ary functions instead of
simple state variables. This supports modelling on a high level of abstraction.
The data structure in the SMV language is much simpler and leads to more
low-level models.
•In ASM, non-determinism is introduce by means of external functions or the
choose rule. In SMV, non-deterministic behaviour can be modelled through
“under-specification”: Any state variable without a specified transition be-
haviour can behave arbitrarily. In this case, the checking algorithm investi-
gates every possible behaviour.2
•Fairness assumptions can be stated in the SMV language but not in ASM.
After this general overview of the SMV tool and its input language, we introduce
the interface between the intermediate language ASM-IL and the SMV language in
the next section. This second transformation step completes the interface from the
ASM Workbench to the SMV model checker.
2Another means to model non-deterministic behaviour is given through the TRANS construct
which is not used in our approach.
86
The Transformation into SMV Section 6.2
6.2 From ASM-IL into SMV Language
In this section, we introduce a general schema for an effective coding of ASM rules in
the SMV language that preserves the semantics. This result is published in [Win97].
The schema yields the basis for a transformation algorithm that is implemented.
6.2.1 Mapping ASM into SMV
The semantics of the SMV language is defined in [McM93]. We use this definition in
order to show that the chosen transformation schema is semantically correct. Since
the schema is only applied to the intermediate language ASM-IL (we are discussing
the second step of the transformation), it suffices to show correctness for simple
guarded update rules (introduced in Section 5.2) of the form
if guardij then loci:= valij
where each location lociis attached with a list of the guard-update pairs contribut-
ing in the model (assuming the model contains mguarded-updates for locithen
1≤j≤m). Note that every valij is a constant value or an expression that contains
only primary operators (see Section 5.2.1 on page 75). These primary operators are
exactly those that are also supported by the SMV language. Analogously, guardij
is a boolean expression that contains primary operators only. All other operators
are unfolded and simplified during the first transformation step.
We argue in two steps: Firstly, we show that the transformation of a simple
update is correctly transformed. Secondly, we show the correctness of the transfor-
mation of a list of simple guarded updates.
Transformation schema for a simple update The SMV language deals with
variables over finite domains. In ASM, we can identify the notion of locations
with these state variables (see Section 5.2). A location is a pair loc =(f,Val B(¯
t))
consisting of a function symbol fand a list of parameter values Val B(¯
t) with respect
to the expanded state B=(A, ζ) (see Definition 2.11 on page 16).
In SMV, we model the updating of a variable by an assignment via the next op-
erator next(·), which specifies the value of the variable in the next state. We choose
the following schema for transforming a simple ASM update into SMV syntax:
f(¯
t):=t0
⇓
ASSIGN next(loc):=val
with the location loc =(f,ValB(¯
t)) and the value val =ValB(t0)
In [McM93], the semantics for SMV programs is defined as a function [[.]] smv
that maps a program fragment to its denotation. The denotation is a set. This set is
either a singleton containing a boolean value or given by a special boolean function
that yields code for an OBDD, the internal data structure of the SMV tool. This
function is represented by →,theif-then-else operator which defines the Shannon
decomposition of an OBDD (see Section 4.1, equation (4.1)). The semantics of an
expression a→(b, c) is given as “if athen belse c”.
The semantics of an expression in SMV is denoted by itself 3:[[e]] smv =e.The
semantics of an assignment containing a next operator is given as follows:
[[ ASSIGN next(loc):=val ]] smv =(loc0∈(running →([[val ]] smv ,loc)) )
3Internally, expressions containing non-boolean operators are mapped into a boolean expression
by using the if-then-else operator and a given set of axioms. Non-boolean values are encoded
similarly (for more detail see [McM93], page 80).
87
Chapter 6 The SMV Model Checker
where loc0is the value of the location loc in the next state, and running is the
internal variable that is attached to each SMV module and indicates if the module
is currently active. We can read the semantics of assignments as follows: If the
module to which the statement belongs is active then loc0evaluates to an element
of the set of possible values of the expression val =[[val ]] smv , otherwise it remains
as it is.
In the semantics of ASM, every transition rule can fire in every state (if it is not
guarded), i.e., running is always true. If a transition rule fires then the value of
the location in the next state is evaluated to val =ValB(t0). Therefore, the schema
for transforming ASM updates into SMV assignments is semantically correct.
Transformation schema for a list of guarded update rules The transfor-
mation schema for a list of guarded update rules for a particular location lociuses
the case construct of the SMV language. Each of the simple rules results in one
case: the guard is mapped into the leading condition, and the corresponding value
(or the expression) is mapped into to corresponding right hand side of the case.
In SMV, a variable behaves non-deterministically if no update is specified. To
ensure that a variable will not be changed if none of the guarded update rules fires,
we have to state this explicitly since otherwise the variable can take any value from
its range. This is done automatically by adding a default case which is guarded by
the condition true (represented by 1 in the SMV language). If none of the guards
is satisfied, the location evaluates in the next state to the same value.
if guardi1then loci:= vali1,
.
.
.
if guardim then loci:= valim
⇒
ASSIGN
next (loci):=
case
guardi1:vali1;
.
.
.
guardim :valim ;
1:loci;
esac ;
Similar to the simple assignment, the semantics of an assignment containing a
case block is given as a nested application of if-then-else operators. The semantics
is shown below:
ASSIGN next (loci):=
case
guardi1:vali1;
.
.
.
guardim :valim ;
1:loci;
esac ;
smv
=
=[[guardi1]] smv →((loc0
i∈(running →([[vali1]] smv ,loci))),
[[ guardi2]] smv →((loc0
i∈(running →([[vali2]] smv ,loci))),
.
.
.
[[ guardim ]] smv →((loc0
i∈(running →([[valim ]] smv ,loci))),
(loc0
i=loci))...)
88
The Transformation into SMV Section 6.2
If guardij is the first condition in the case block that evaluates to true then the
value of loc0
iis a member of the set of possible values of [[valij ]] smv whenever the
module is active, i.e., running is true. Given modules that are permanently active,
loc0
iis evaluated to [[ valij ]] smv =valij whenever [[guardij ]] smv =guardij is true. If
none of the guards is satisfied the default case is evaluated. Since the condition of
the default case is always true, the location keeps its old values in this case.
With the same argument as in the case above, we can state that this correctly
reflects the semantics of ASM in the general case. However, we have to exclude
the case in which the ASM model contains inconsistent updates, i.e., updates that
address the same location and can be fired in the same state.
With our transformation, inconsistent updates lead to a case block that contains
cases with leading conditions that do not exclude each other. That is, two guards
guardij and guardik (j6=k) may be satisfied in the same state. According to
the semantics of the SMV language, the tool will always choose the first case for
which the condition is satisfied and apply the corresponding assignment. This does
not coincide with the ASM semantics. Therefore, inconsistent update should be
excluded.
The proposed transformation schema provides a set of assignments of the form
shown above. Each of them assigns a new value to one location only. We can see
that this set has exactly the same semantics as the initially given ASM rule if we
assume that the rule does not contain inconsistent updates.
Modules
In our transformation, we assemble the set of assignments in a module behaviour.
The declaration part for the state variables (i.e., the contributing locations) is gath-
ered in a separate module state. This module contains also the INIT declaration,
which is a conjunction of all initial evaluations that are specified in the ASM model.
The overall module main, which describes the whole system, declares both modules
where the module state is used as a parameter for the module behaviour. It also
contains the specification of the requirements in CTL logic (see discussion below).
Module main has the following appearance:
MODULE state
VAR
... (declaration of locations)
INIT
... (initialisation of locations)
MODULE behaviour (s)
ASSIGN
... (assignments of locations)
MODULE main
VAR s:state;
tr :behaviour (s)
SPEC
... (requirements as CTL formula)
89
Chapter 6 The SMV Model Checker
The same module schema is also used by Havelund and Shankar in [HS95]. We
choose this schema for the following reason: If we want to treat ASM that consist
of several modules or agents, this schema allows us to separate globally and locally
accessible state variables. Only the global variables are declared in the module
state, the local variables are declared in the sub-modules. This enables us to
simulate communication via global variables that can be accessed by each module.
We do not map the module concept of ASM into modules of SMV. A multi-
agent ASM that uses the parameter Self for parameterising the transition rules
is mapped into a flat structure of simultaneously applied assignments. We use
an interleaving semantics for the concurrent behaviour of the agents. For this
approach, the parameter Self has to be modelled as an external function in the
ASM model. This external function is transformed into an ordinary state variable
in the SMV code that changes its value non-deterministically. The parameterised
ASM rules are unfolded (according to the transformation algorithm introduced in
Section 5.2) in such a way that the evaluation of Self turns into a guard for applying
a particular assignment: if Self equals agent aithen apply assignments for ai.
Since Self has only one value at a time, the resulting SMV model represents an
interleaving semantics.
As a consequence, the transformation algorithm is very simple and straightfor-
ward. We choose this simple mapping due to the fact that the SMV code is not
visible to the user anyway. It becomes an intermediate format. That is, modulari-
sation on the level of SMV code is not helpful for validating the model.
Still, to maintain the modularisation could be useful if we want to decompose
the problem at hand into smaller independent components. This way, the model
checking task could be split into smaller sub-tasks by checking each component
separately. In the investigated case studies, however, decomposition was not help-
ful: In both cases, there are too many interdependencies between the modules (or
agents). Almost every state variable that belongs to one module is used in some
other modules as well. Therefore, the effort that would be necessary to resolve these
interdependencies would lead to components being as large as the entire model.
Another reason for keeping modularity might be given through the size of the
resulting OBDD representation of the model. In the case of the FLASH protocol
(see Section 7.1), we investigated the behaviour of the SMV tool for both cases,
with and without modules. Prototypically, we transformed the multi-agent ASM
model into an SMV model of several processes with an interleaving semantics (i.e.,
we declared the modules as process). Comparing the statistics of used resources
during the checking process, we find that mapping agents into separate processes
leads to a larger OBDD representation. Thus, the implemented transformation,
which expects the parameter Self to be specified as an external function that is
unfolded, is more effective and the resulting SMV model with a flat structure yields
a better coding of this example.
Requirements and Fairness
Requirements, i.e., the properties of the system that we want to check, as well as
fairness assumptions, have to be specified as CTL formulas. ASM-SL does not yet
comprise a proper syntax for specifying in CTL but as future work we are planning
to extend the language with the necessary operators.
Currently, requirements and fairness assumptions have to be added manually
into the code by using the SMV language.
Apart from the requirement specification and fairness assumptions, the trans-
formation from ASM models into SMV models operates fully automatically. An
implementation of the algorithms is available. In the next chapter, we describe
90
The Transformation into SMV Section 6.2
our experiences when applying the transformation and running the SMV tool for
analysing ASM models. We show in Section 7.1 through the first case study, the
FLASH cache coherence protocol, how model checking can nicely support the de-
bugging process. The second case study, the Production Cell, yields some insights
into the limitation of this approach. This is discussed in Section 7.2.
91
Chapter 6 The SMV Model Checker
92
Chapter 7
Case Studies
7.1 The FLASH Cache Coherence Protocol
As one case study for model checking ASM by using SMV, we chose the FLASH
protocol [KOH+94]. Our ASM model of the protocol is based on the work of Durand
[Dur98]. For this model, some refinements are necessary in order to fit the model
for the model checking process. After a short introduction to the FLASH protocol,
we describe the ASM model that is derived from the model given in [Dur98] and
motivate our refinements. In the last subsection, we sketch the debugging process
that is supported by transforming the model and model checking with the SMV
tool.
7.1.1 The Protocol
The Stanford FLASH multiprocessor (cf. [KOH+94]) is an architecture for a large
number of distributed processor nodes that share memory. The memory is dis-
tributed over the contributing processors nodes, each of which holds some part of
the memory. In the architecture, the processor nodes are interconnected so that the
distributed memory parts are accessible to every node in order that they may read
or write data.
The protocol that organises the communication between the nodes includes sup-
port for cache coherence of the shared memory. Since the access to data is realised
by means of holding a copy of the data, this copy becomes invalid as soon as there
is writing access to the original data the copy is made from. Cache coherence is
satisfied if the protocol guarantees that none of the nodes hold a copy of data that
has changed in the meanwhile.
The distributed memory is partitioned into lines, i.e., small pieces of memory
content. Each line is associated with a home-node which hosts the part of the
physical memory where the line resides. Whenever a processor node wants to access
a particular line of which it has no valid copy, a read- or write-miss occurs. As a
consequence the node sends a request to the line’s home-node.
Every request should be fulfilled as soon as possible by means of sending a valid
copy of the requested line. A node has shared access if it holds a copy only for
reading purposes. A node with shared access to a line is called a sharer of the line.
Whenever a node wants to write (i.e., change) data, it needs exclusive access.A
node with exclusive access to a line is called the owner of the line.
Any request that is caused by a read-miss can be satisfied if the line is not
exclusively accessed by another node. If a write-miss occurs the request can be
serviced only after some preparations:
93
Chapter 7 Case Studies
•Any other node that has shared access to the same line must be informed
about the requested exclusive access.
•Subsequently, every sharer must invalidate its copy.
•Every sharer of the line that is informed and has invalidated its copy has to
send an acknowledgement to the home-node of the line.
Only if an acknowledgement from every sharer has arrived the home-node can grant
exclusive access to the line and sends a copy to the requesting node. This node
becomes the owner of the line.
Being interconnected, the nodes are able to communicate with each other as
described above: They can send messages to request a remote line or send a copy
of the needed data to service a request. To provide coherence of the data, addi-
tional book-keeping is necessary to prevent simultaneous reading and writing on
the same line. Message passing and book-keeping of shared and exclusive access is
the responsibility of the protocol that we consider in our ASM model.
7.1.2 The ASM Model of the FLASH Protocol
The ASM model of the protocol in [Dur98] is based on agents. Each agent models
one processor node that holds certain memory lines. A set of parameterised transi-
tion rules describes the behaviour of a single agent. Its behaviour is determined by
the incoming messages, which can be requests, acknowledgements or grants. That
is, each rule describes the behaviour for one possible kind of message that can be
received. This modelling idea yields a clear structure. (A complete model in ASM-
SL syntax that includes also our refinements is given in the appendix, see Section
A.2.)
In this subsection, we describe the ASM model of the FLASH protocol as given
in [Dur98] with only one minor change that is motivated and explained (see below).
This description should help to understand the necessary refinements of the model
(given in Section 7.1.3) and the counterexamples that were found by the SMV tool
(given in Section 7.1.4). We start with a summary of the domains and functions
that describe the state of an agent. We explain the structure of messages and based
on this the behaviour of a communicating agent as specified through the ASM
transition rules.
Domains and state functions. The domains of the model are given by the
following sets:
-Agent models the contributing processor-nodes.
-Line models the lines of the memory.
-Type ={get,put,fwdget,swb,nack,nackc,getx,putx,fwdgetx,inv,invAck,
fwdAck,rpl,wb}models the type of messages.
-ReqType ={cc.get,cc.getx,cc.rpl ,cc.wb}models the type of newly generated
request messages.
-Phase ={ready,wait,invalidPhase}models the current phase of a request.
-Status ={excl,shared,invalid}models the status of the access to a line of
memory from the view of each agent, i.e., the access status of the copy of the
data content the agent holds.
The agent’s behaviour depends on several state functions:
94
The FLASH Cache Coherence Protocol Section 7.1
-CurPhase :Agent ×Line →Phase
models for each agent the phase of a request to a particular line. If a request
is started the current phase of the line is wait. If the request is serviced, the
phase is reset to ready. The current phase is invalidPhase if the copy has to
be invalidated because of an exclusive access.
•State :Agent ×Line →Status
models for each agent the access status of a line copy in use.
•Pending :Line →Boolean
is a flag indicating a current request for a line. Whenever a request is sent
this flag is true. It becomes false when the request is serviced in some way.
•Owner : Line →Agent ∪{undef }
models the agent that currently has exclusive access to a line. If none of the
agents has exclusive access to a line the function equals undef.
•Sharer :Line ×Agent →Boolean
models if a particular Agent has shared access to a particular line, i.e., holds
a copy of the line. Thus, Sharer models the characteristic function of the set
of sharers of a line.
Message Structure. In [Dur98], a message is modelled as a six-tuple consisting
of the type of the message, the addressed agent, the sender agent, the agent initiating
the request (this must not be the same as the sender), the requested line, and the
copy of the requested data.
For applying model checking, we have to abstract this model since the requested
data has an infinite domain. In our abstraction, a variable data of the original ASM
model which models the copy of the data in a message is eliminated. This variable
does not influence the control flow of the protocol behaviour since it does not control
any of the guards in the transition rules. Also, the variable does not appear in the
properties to be checked. Thus, data is irrelevant and by discarding it we do not
lose expressiveness of the model and our checking results. Eliminating irrelevant
variables is an abstraction technique that is also suggested in [BH99] (see also the
discussion of related work in Section 9.1).
Each component of a message can be addressed by a special selector function.
The most relevant information is given with the type of a message, MessType,which
is an element of Type or ReqType.
For shared access, we distinguish the following message types:
get : requesting a line from its home
put : granting a line to the requester (source of the request)
fwdget : forwarding a request to an exclusive owner of the line
swb : requesting a write-back of an owned line that is to be shared
nack, nackc : negatively acknowledging the request or forwarded
request (nackc), if it cannot be performed now.
In analogy, message types related to exclusive access are:
getx : requesting a line for exclusive access from its home
putx : granting a line for exclusive access to the requester
fwdgetx : forwarding a request for exclusive access the owner of the line
inv :requestingacurrentsharer of the line to invalidate its local copy
invAck : acknowledging the invalidation of the line
fwdAck : owner’s granting according to a forwarded shared request.
95
Chapter 7 Case Studies
Incoming messages are requests from remote nodes or from the receiving node
itself. In order to simplify the model, we do not distinguish between a requesting
node that is also the home-node of the line and other nodes. The special case of
requestingalinethatislocatedonthesamenodeiscalledintra-node communica-
tion.
Read- and write-miss. A read- or write-miss that causes a request to be sent is
arbitrarily generated by means of an external function produce :Agent →ReqType×
Line. For each agent, this function maps to a pair (t, l) which causes a message of
type tto be sent to the home-node of the line l.
The agents’ behaviour. The transition rules given in Figures 7.1 and 7.2 specify
the behaviour of an agent. Note that in the figures the parameter lmodels a line.
Moreover, sending of a message is specified as a macro. In Figures 7.1 and 7.2, it
is denoted as SendMsg. This macro is defined as an import-rule that imports a
new element, which is a message, into the set of messages in transit, MessInTransit.
The parameters of SendMsg specify the components of the new message.
An arbitrarily generated read- or write miss generates a message of a special
type with the prefix “cc.”. Whenever an agent receives such a message, it sends the
corresponding request and enters a waiting mode. Releasing an access is handled in
the same way: a message of type cc.rpl or cc.wb indicates that a memory line is
not needed any more. If the agent sends a request for releasing a line, the state of
the line is invalidated, i.e., the node has no reliable copy of the line any more. The
transition rules for sending a request when a read- or write-miss occurs are shown
in Figure 7.1 in the upper part.
The transition rules that are related to requests for shared access are given in
Figure 7.1 in the lower part. A get-request initiates a sequence of message transfers
for granting shared access. The responding behaviour is modelled by the transition
rule that is guarded by (MessType =get) in the following way:
(a) The request is negatively acknowledged if another request on the line is already
processing, i.e., Pending(l) is true.
(b) The request is forwarded to the current owner if there is already an exclusive
access, i.e., if Owner(l) is not undefined.
(c) The request is granted to the requester if no owner is noted; this is modelled
in the else-case.
If there is an owner (case (b) above), the grant for shared access is given by the
agent who “believes” itself to be an owner. Moreover, the owner has to release its
exclusive copy.
If an agent gets a forward get-request, i.e., (MessType =fwdget)istrue,and
does not agree to be the owner of the line (State(l) is not exclusive) then the request
has to be negatively acknowledged. Otherwise, the owner changes its exclusive
access into a shared access, sends a put-message to the requester, that gives shared
access to the line under request, and sends a message to the home-node which has
to write back the exclusive access and add it to the list of sharers, i.e., a swb-request
is sent.
The negative acknowledgement, indicating that an access cannot be granted,
has to be sent to the requester and to the home-node. The requester gets a message
of type nack. It resets its current phase to ready again which enables it for sending
new requests. The home-node gets a message of type nackc.Therequestfora
96
The FLASH Cache Coherence Protocol Section 7.1
if MessT ype =cc.get ∧CurPhase(Self ,l)=ready
then SendMsg(get,home(l),Self ,Self ,l)
CurPhase(Self ,l):=wait
if MessT ype =cc.getx ∧CurPhase(Self ,l)=ready
then SendMsg(getx,home(l),Self ,Self ,l)
CurPhase(Self ,l):=wait
if MessT ype =cc.rpl ∧CurPhase(Self ,l)=ready ∧State(Self ,l)=shared
then SendMsg(rpl,home(l),Self ,Self ,l)
State(Self ,l):=invalid
if MessT ype =cc.wb ∧CurPhase(Self ,l)=ready ∧State(Self ,l)=excl
then SendMsg(wb,home(l),Self ,Self ,l)
State(Self ,l):=invalid
if MessT ype =get
then if Pending(l)then SendMsg(nack,source,Self ,source,l)
else if Owner(l)6=undef
then SendMsg(fwdget,Owner(l),Self ,source,l)
Pending(l):=true
else SendMsg(put,source,Self ,source,l)
Sharer(l,source):=true
if MessT ype =fwdget
then if State(Self ,l)=excl then SendMsg(put,source,Self ,source,l)
SendMsg(swb,home(l),Self ,source,l)
State(Self ,l):=shared
else SendMsg(nack,source,Self ,source,l)
SendMsg(nackc,home(l),Self ,source,l)
if MessT ype =put
then CurPhase(Self ,l):=ready
if CurPhase(Self ,l)6=invalid
then State(Self ,l):=shared
if MessT ype =swb
then Sharer(l,source):=true
Sharer(Owner(l),l):=true
Owner(l):=undef
Pending(l):=false
if MessT ype =nack
then CurPhase(Self ,l):=ready
if MessT ype =nackc
then Pending(l):=false
Figure 7.1: Responding to a request for shared access
97
Chapter 7 Case Studies
if MessT ype =getx
then if Pending(l)
then SendMsg(nack,source,Self ,source,l)
else if Owner(l)6=undef
then SendMsg(fwdgetx,Owner(l),Self ,source,l)
Pending(l):=true
else if (∃u:Agents)Sharer(l,u)
then doforall u:Sharer(l,u)
SendMsg(inv,u,Self ,source,l)
Pending(l):=true
else SendMsg(putx,source,Self ,source,l)
Owner(l):=source
if MessT ype =fwdgetx
then if State(Self ,l)=excl
then SendMsg(putx,source,Self ,source,l)
SendMsg(fwdAck,home(l),Self ,source,l)
State(Self ,l):=invalid
else SendMsg(nack,source,Self ,source,l)
SendMsg(nackc,home(l),Self ,source,l)
if MessT ype =putx
then State(Self ,l):=excl
CurPhase(Self ,l):=ready
if MessT ype =fwdAck
then if Owner(l)6=undef
then Owner(l):=source
Pending(l):=true
if MessT ype =inv
then SendMsg(invAck,home(l),Self ,source,l)
if State(Self ,l)=shared
then State(Self ,l):=invalid
else if CurPhase(Self ,l)=wait
then CurPhase(Self ,l):=invalidPhase
if MessT ype =invAck
then Sharer(l, MessSender):=false
if ((∀a:Agents)(a6=MessSender ∧Sharer(l,a)=false))
then SendMsg(putx,source,Self ,source,l)
Pending(l):=false
if MessT ype =rpl
then if ((∃u:Agents)Sharer(l,u))
∧¬Pending(l)
then Sharer(l,u):=undef
if MessT ype =wb
then if Owner(l)6=undef
then Owner(l):=undef
Figure 7.2: Responding to a request for exclusive access
98
The FLASH Cache Coherence Protocol Section 7.1
particular line is not pending anymore, the function Pending must be reset to false.
As a consequence, new requests to this line can be treated.
The behaviour for treating a request of exclusive access is modelled by the
transition rules that are shown in Figure 7.2 in the upper part. A getx-request
initiates a sequence of message transfers for exclusive access. Analogously to a get-
request described above, an exclusive request (when MessType =getx)istreated
in the following way:
(a) The request is negatively acknowledged if another request is in process already
(by sending a nack-message).
(b) If the line has already an owner, the request is forwarded to this owner (by
sending an fwdgetx-message). If this notified node is truly the owner (i.e., its
state of the line is exclusive), it has to invalidate its copy and give exclusive
access to the requesting node (by sending a putx-message). Otherwise, the
request is negatively acknowledged.
(c) If the line has no owners but a number of sharers that hold a copy, these
sharers have to be informed about the request for exclusive access (by sending
an inv-message). When getting an inv-message, a sharer has to invalidate its
copy of the line and must respond with an acknowledgement of invalidation
(sending invAck-message). When each of the sharers has sent its invalidation
acknowledgement the home-node can grant the exclusive access. It sends a
putx-message to the requester. That is, the putx-message is delayed until all
invAck-messages are received (c.f., transition rule for (MessType =invAck)).
(d) If no sharer is listed for the line under request, the exclusive access can be
granted immediately (by sending a putx-message to the requester).
For releasing a shared or exclusive copy from its cache, an agent sends a
write back (wb) or a replace message (rpl)tohome. The agent has to be deleted
from the list of sharers or must be declared as not being owner anymore (whichever
is appropriate). The corresponding transition rules are given in Figure 7.2 in the
lower part.
In the next subsection, we describe our refinements of the model that were
necessary for applying model checking.
7.1.3 The Refined Model of the Protocol
In the model given in [Dur98], the macro SendMsg adds a message to a (possibly
infinite) set of messages in transit. The strategy for receiving a message from this
set is not specified. For the proof, it is assumed in [Dur98] that the messages are
received in the right order.
In order to formalise this assumption and to keep the model finite, we have to
refine the model. By this refinement, we restrict the model to exclude those runs
in which a message is sent but never received or sent but overwritten by a message
that is sent later. That is, we want to exclude messages being received in a different
order than they are sent.
Without our refinements, the model is either infinite (in [Dur98] the set of mes-
sages in transit is not restricted at all) or yields a wrong counterexample if we restrict
the set to be finite. We cannot guarantee liveness if messages may be received in a
wrong order.
In order to avoid loss of messages and to guarantee that the order of sending
and receiving messages is proper, we add a strategy of synchronisation:
99
Chapter 7 Case Studies
- We introduce a queue for messages in transit for each agent.
- A message can be sent to an agent only if its queue for messages in transit is
not full.
- We interleave the protocol behaviour with synchronisation steps.
Each step of protocol communication (specified by the rules given in Figures 7.1
and 7.2) is followed by one step of message transfer. Our refinement introduces
an inconsistency in the intra-node communication, i.e., if the home-node sends
a request to itself. We solve this problem by extending the specification. The
refinement and necessary changes are described in the following subsections. The
full specification of the refined model is given in the appendix (see Section A.2).
Queue for Messages in Transit
Instead of handling messages as tuples, we decide to model the components of a
message via functions. This avoids unnecessary complexity caused by the unfolding
of tuples in the transformation algorithm (see also the discussion in Section 5.2).
The infinite universe MessInTransit of [Dur98] is replaced by finite queues, one
for each message component. Consequently, a message has only four components
because each queue is attached to the agent that is addressed. This agent becomes
a parameter for the message components in our model and QLength is an index for
the queue (see below).
MessInTr: QLength * Agent -> Type,
SenderInTr: QLength * Agent -> Agent,
SourceInTr: QLength * Agent -> Agent,and
LineInTr: QLength * Agent -> Line.
The universes QLength,Agent,andLine are sets that are finitely restricted by
a maximal index: maxQ,maxAgent,ormaxLine. These constants can easily be
adjusted in order to scale up the model under investigation.
Sending a message (SendMsg) is now specified as appending the message compo-
nents to the corresponding functions: If niis the smallest index for which the queue
for messages in transit is empty, we update all message-component functions at this
index. We indicate emptiness of a particular cell in a queue by means of a new
message type noMess for the message type component. That is, if (MessInTr(ni,
ai)=noMess) is satisfied and for all indices nj<n
iit is not, then nimarks the
index for writing the message to be appended. This is specified by means of the
following macro:
transition AppendToTransit(agent_,(sender_,mess_,source_,line_)) ==
if MessInTr(1,agent_)=noMess
then SenderInTr(1,agent_) := sender_
MessInTr(1,agent_) := mess_
SourceInTr(1,agent_):= source_
LineInTr(1,agent_) := line_
else do forall i in { 2..maxQ }
if MessInTr((i-1),agent_)!=noMess and MessInTr(i,agent_)=noMess
then SenderInTr(i,agent_) := sender_
MessInTr(i,agent_) := mess_
SourceInTr(i,agent_):= source_
LineInTr(i,agent_) := line_
endif
enddo
endif
100
The FLASH Cache Coherence Protocol Section 7.1
For requests (i.e. message type is cc.get,cc.getx,cc.wb,orcc.rpl), we
introduce an extra queue for request in transit MessInTrR. Analogously, we define
dynamic functions that hold one of the components of a request. Sending of a
request message is specified by means of the macro AppendRequestToTransit that
looks similar to the macro shown above.
Transfer of Messages in Transit
Sending of a message by means of appending it to the queue of messages in transit,
is only one half of the message exchange. As a second step, we have to specify how
the messages in transit are read by the addressed agents, i.e., how messages are
transfered (c.f., Figure 7.3).
Each agent processes a current message (which is empty if its type equals
noMess). Again, we model the current message by means of its components: InMess,
InSender,InSource,andInLine are dynamic functions over domain Agent.The
current message is delivered by transferring the first element of the transit queues
MessInTr and MessInTrR (see Figure 7.3). Note that requests have lower priority
than messages, i.e. a request is passed through only if there is no message in transit
left.
InMess
message_passing
...
123maxQ
MessInTr
SendMsg
...
12maxR
MessInTrR SendRequest
message_passing
Figure 7.3: Transfer of messages in transit
Processing the current message and delivering a new message involve the same
dynamic functions of the model. In order to avoid inconsistencies between the
transition rules, we have to interleave both steps: message processing of the agents
and transferring of a message. We extend the overall behaviour by means of a sub-
step for synchronisation. In the synchronisation step, the messages are transferred
to the addressed agent in the proper order.
In an ASM model, introducing a sub-step (to be processed after each state
transition) is done in a compositional way: in addition to the ASM for message
processing we specify an ASM for the message transfer. That is, we do not have to
spread the specification for transferring messages throughout the ordinary transition
rules of the agents’ behaviour (c.f., Figures 7.1 and 7.2). An overall ASM main
invokes both “sub-ASM” agent behaviour and message passing in turn:
transition main ==
if toggle = behave
then agent_behaviour
toggle := sync
else (* if toggle = sync *)
message_passing
toggle := behave
endif
101
Chapter 7 Case Studies
Using this, we maintain the benefits of the clear and understandable structure
of the abstract model that is given by [Dur98].
Inconsistencies for Intra-Node-Communication
Inconsistencies between the transition rules of two agents (i.e., if two agents at-
tempting to update the same location simultaneously) are excluded since we apply
an interleaving semantics to the agents’ behaviour, and introduce sub-steps for
message transfer (as described above). However, inconsistencies may be caused by
intra-node communication: To keep the ASM model small, we do not distinguish
whether the requesting node is also home of the line under request or not. That is,
if the home-node of a line wants to have shared or exclusive access to its own line,
it has to proceed in the same way as all other nodes, i.e., by sending a get/getx-
message to itself.
If the requester is also the home-node of the line, it may happen that two
messages are to be sent simultaneously to the same address. Inconsistent updates
occur and one of the messages (the first of two updates) will be lost. (In Figures 7.1
and 7.2 the reader may find such situations in the fwdget-rule and the fwdgetx-
rule.)
In order to avoid inconsistency, we introduce three new message types that
combine two messages: put swb,putx fwdAck,andnack nackc. Whenever the
source of the message (i.e. the requester) is equal to the home-node of the line
under request, we send one of the combined messages instead of sending two single
messages. According to the new message types, we introduce new transition rules
that combine the behaviour specified in both of the rules that have to be fired when
receiving such messages.
7.1.4 Model Checking the FLASH Model
We use model checking of the transformed ASM model as an evolutionary process of
debugging: We edit the ASM model, transform it automatically into an SMV model,
run the SMV to check the properties under investigation, simulate the resulting
counterexample (if any) with the ASM Workbench, and edit the ASM model again.
Since the debugging process is more efficient if the model checking terminates in
a reasonable span of time, we keep our model, in the beginning, as small as possible.
We find that even if the model is restricted to two communicating agents and one
line of memory, we detect errors in the abstract model as well as in our refinement.
In the following, we describe some of the detected errors as examples. The errors
arise when checking the model for safety and liveness:
•No two agents have exclusive access to the same line simultaneously.
•Each request will eventually be acknowledged.
•Whenever an agent gets shared access to a line, the line’s home will note it as
a sharer.
We formalise these requirements in CTL as follows1:
1Although the third specification is rather weak, it yields helpful counterexamples. The dis-
junction is necessary due to the fact that the sequence, in which the corresponding updates (noting
a state to be shared and adding a sharer) occur, may change for different scenarios.
102
The FLASH Cache Coherence Protocol Section 7.1
Vi6=j[AG (!(State(a(i),l)=exclusive & State(a(j),l)=exclusive))]
Vi[AG (CurPhase(a(i),l) = wait -> AF (CurPhase(a(i),l) = ready))]
Vi[AG ( State(a(i),l)=shared -> AX (Sharer(l,a(i)) = true)
| Sharer(l,a(i)) = true -> AX (State(a(i),l)=shared)) ]
Our first counterexample shows simultaneous exclusive access. We simulate the
ASM model and run into an error that can also be found in the abstract ASM
model of [Dur98]:
Whenever a putx-message is sent to grant exclusive access, the addressed
requester has to be noted as owner of the line. This is specified for the
getx-rule but it is missing for the invAck-rule that might also cause a
putx-message to be sent (see also Figure 7.2). The protocol is unsafe
since simultaneous exclusive access may occur, and written data may be
lost. (The corresponding counterexample is given in the appendix, see
Section A.2.2).
Other counterexamples involve the problem of inconsistency (i.e., conflicts caused
by attempted simultaneous updates) on the finite message queue. Although our
data space is restricted to very short queues, we can derive more general remarks
for message passing via queues that concern the finite limitation of a queue itself
(which, in fact, is characteristic for each possible realisation of a queue):
Each sharer of a requested line has to process the rule for invalidation
(inv-rule). It sends an invAck-message to the home-node to acknowl-
edge the invalidation. When receiving an invAck-message, the home-
node deletes the sender from the list of sharers. If the home-node is a
sharer too2, a deadlock may occur if the number of sharers is greater
than or equal to the length of the message queue: The home-node may
fail to complete processing the inv-rule (see Figure 7.2) when the queue
is full and sending of a new message to it is not possible (since every
other sharer may have sent before). The home-node stays busy and can
not process the incoming invAck-rule to clear the queue. In general,
we found that the size of the message queue must be greater than or
equal to the number of contributing agents since, in the worst case, each
agent is a sharer and will simultaneously send an invAck-message to
the home-node. (This scenario is shown by the second counterexample
given in the appendix, see Section A.2.2).
When queueing messages, we should take into account that sending and processing
a request is not possible in the same instance of time. Independent of the length of
a queue, we should be aware of the following scenario:
Producing a request for releasing an exclusive access to a line is guarded
by the condition that the current status shows exclusive access (see
cc.wb-rule in Figure 7.1). When the releasing request is processed, the
current owner (e.g.,agent 1) of the line is reset. Since message passing
may take time, many things can happen in the mean-time (i.e. after
appending the request to the queue for requests in transit (MessInTrR)
and before the home-node receives the request). For instance the follow-
ing scenario can occur: The current owner, agent 1, asks for exclusive
access for a second time. This may be processed and agent 1becomes
the owner again. In the next step, it may happen that another agent
(agent 2) asks for exclusive access and agent 1invalidates its copy and
2This is possible if we allow intra-node communication (see Section 7.1.3).
103
Chapter 7 Case Studies
sets its status to shared (see inv-rule). The other agent gets exclusive
access on the line and becomes the owner (see invAck-rule). If the
releasing request of agent 1is now transfered then the current owner
(agent 2) is reset although it is not the same owner that asked for re-
lease. (The precise scenario is given by the third counterexample in the
appendix, see Section A.2.2).
We correct our ASM model in that we repeat the guards of the request-rules (i.e.,
rules for cc.get,cc.getx,cc.wb,andcc.rpl) when the home-node of the re-
quested line receives the requests in transit.
The examples show that helpful borderline cases can be detected more easily
by a model checker than by pure simulation. The computational effort for the
automated transformation of the ASM model ranges from three to five seconds. The
size of the resulting SMV models is given below where the different columns yield
the comparing results when scaling up the parameters for the number of agents and
lines. The experiments were carried out on an UltraSPARC-II station with 296MHz
and 2048 Mb memory, the operating system is Solaris 2.6:
resources used: 2 agents, 1 line 3 agents, 1 line 2 agents, 2 lines
user time/system time: 4.69 s/0.13 s 5687.52 s/0.6 s 17263.2 s/0.86 s
BDD nodes allocated: 70587 1612740 2975127
Bytes allocated: 4849664 37748736 54657024
BDD nodes representing
the transition relation: 19261 + 78 288986 + 82 78365 + 96
The output of the SMV tool shows the user time and the system time that is
used by the model checking process. The former indicates the time in which the
model checking algorithm terminated, the latter shows the time that was spent
on system calls. The number of BDD nodes that represent the transition relation
is given as a sum because the transition relation is internally represented by the
transition and an invariant (e.g., a fairness constraint). The first number in the
sum gives the size of the BDD for the transition, the second number specifies the
size of the BDD for the invariant. In this example, the second BDD represents the
fairness constraint on “fair” evaluation of the variable Self.
The variable ordering is determined by the automatic reordering facility that is
given by the SMV. Resources used when checking CTL requirements are also listed
in the appendix (see Section A.2).
Although checking our model of the FLASH protocol is only feasible for a small
number of agents and lines, the results show that the counterexamples yield ex-
tremely helpful scenarios for locating errors.
In the next section, we discuss the second case study that we investigated with
the SMV tool: the Production Cell. The Production Cell represents an embedded
system that, in contrast to the protocol that is discussed in this section, comprises
assumptions about the environment behaviour. This allows us to show the limita-
tions of the SMV tool.
104
The Production Cell Section 7.2
7.2 The Production Cell
The Production Cell was introduced in the literature as a case study for compar-
ing different formal notations (see [LL95]). An ASM model of the case study is
introduced by Mearelli in [Mea96] (see also [BM97]). Mearelli developed an ab-
stract model and a refined model. Both models describe finite systems since the
domains are regarded as sets of discrete, rather than continuous, values. Therefore,
the models are suitable for applying model checking. In the first of the following
subsections, we describe the case study and the ASM model.
Since the Production Cell is an embedded system, the environment heavily influ-
ences the control flow. In order to exclude unexpected or non-reasonable behaviour,
additional assumptions on the environment are necessary. These assumptions have
to be added to the model we want to treat by the model checker. In the second
subsection, we describe in which way we model the environment assumptions and
discuss the consequences of our experiences for modelling environment assumptions
in general.
The third subsection summarises the model checking procedure and its results
with respect to the additional environment model.
7.2.1 The Case Study
The case study was launched by the Forschungszentrum Informatik in Karlsruhe. It
describes a model that represents an actual industrial facility of a metal-processing
plant, called the Production Cell.
The Production Cell is a system for controlling a plant for processing metal
blanks. Figure 7.4 illustrates the Cell with its contributing components: feed belt,
deposit belt, press, robot, elevating rotary table, and a crane. The blanks to be
processed by the press are conveyed by the feed belt. A robot takes each blank from
the feed belt and places it into the press. The arm has to withdraw from the press
in order to avoid crashing when the press starts to form the blank. After processing,
the press opens again and the robot takes the forged blank from the press and put
it on the deposit belt.
deposit belt
feed belt
crane
press
robot
elevating
rotary table
arm 1
arm 2
Figure 7.4: The Production Cell
To optimise the process, the robot has two arms, arm 1and arm 2(see Figure
105
Chapter 7 Case Studies
7.4). arm 1rotates counterclockwise to load the press with a new blank. arm 2is
responsible for unloading the press after forging a blank. It also rotates counter-
clockwise when unloading. Robot and press are active simultaneously. While the
press is forging a blank, arm 1picks up another blank that should be processed next.
Since arm 1is not placed on the same vertical level as the feed belt, the elevating
rotary table has to compensate for the difference by means of vertical movement.
Similarly, the press has to work on different levels as well. In the model, three states
are distinguished for the press: open for loading by arm 1(the upper arm), open for
unloading by arm 2(the lower arm) and closed (i.e., forging the blank). In order
to avoid user interaction, the Production Cell is described as a cyclic process. Each
blank is taken by the crane from the deposit belt (after being processed) to the feed
belt again. A photo-electric cell informs the crane when a blank arrives at the end
of the deposit belt. A similar cell is also installed at the end of the feed belt so that
the arrival of each blank is detected.
The Production Cell describes an embedded system.Anembeddedsystemcon-
sists of a physical process and a controller which can be a piece of software or
hardware. The physical process is called the environment. It comprises sensors
which measure the behaviour of components of the plant (e.g., the photo-electric
cell that recognise a blank approaching on the belt) and actuators that trigger the
movement of mechanical parts of the plant (e.g., starting or stopping the motor of
the press or the feed belt).
The controller reacts on the given situation in the environment by reading the
sensor values. It controls the plant by writing output to the actuators. Figure 7.5
sketches a typical architecture of an embedded system such as the Production Cell.
Sensor values are input for the controller and actuator values are its output.
controller
plant
sensor
values actuator
values
Figure 7.5: Architecture for Embedded Systems
Between the controller software and the physical environment, a compile step
is needed that translates the physical signals into the data structures that can be
interpreted by the software and vice versa. In most cases, formal specifications
have to abstract from these interface issues as well as from a precise description of
the environment (i.e., the physical plant). Instead, the model of the environment
(including the interface issues) is reduced to a set of (logical) assumptions about its
behaviour.
7.2.2 The ASM Model of the Production Cell
The ASM model of the Production Cell is described in detail in [Mea96]. In this
section, we present a fragment of the Production Cell only. The full model in
ASM-SL syntax is given in the appendix (see Section A.3).
106
The Production Cell Section 7.2
The Production Cell is modelled on two levels of abstraction: the ground model
and the concrete model. The former models the behaviour of the components by
means of states. Whenever it is in a particular state, the system executes the
corresponding action. That is, the current state guards the transition rule that is
to be fired. In the refined model, the possible states are specified more precisely.
Each state is determined by the evaluation of the contributing sensor variables.
These sensor variables are modelled as external unary functions. The output values
for the actuators are given through the actuator variables. In the ASM model, these
are modelled as unary dynamic functions.
The correctness of the ground model is based on a number of abstract assumption
on the behaviour of the environment. We choose the concrete model (which is still
small enough to be treated by a model checker, see below) which implements some
of the necessary assumptions as the model to work with.
Domains. All domains of the ASM models are finite. We distinguish two different
kinds of enumerations:
- Switching of motors: Different domains are introduced for modelling how
particular motors in the cell are controlled (called SWITCH 1to SWITCH 6in
Section A.3); for instance, the motor for the feed belt is simply turned on or
off; the motor of the robot, in contrast, is either idle or running clockwise or
counterclockwise.
- Sensor values: Two domains are used to describe the position of the two
robot arms in an abstract way: the model distinguishes five positions for
arm 1(SENSOR 1) and only four for arm 2(SENSOR 2). A third domain for
sensor values is used to model the position of the vertical gripper of the crane
(SENSOR 3).
Most of the dynamic and external functions, however, model boolean variables,
i.e., simple flags (e.g., the sensor value of the photo-electric cell that is mentioned
earlier).
Accordingly, the ASM model is finite on both levels of abstraction. In fact, the
models can be transformed automatically into the corresponding SMV model even
without unfolding of n-ary functions (see Section 5.2) since all functions are unary,
i.e., they have the form of variables already.
Modules. The components of the Production Cell are modelled in [Mea96] as
modules that run in parallel. A module consists of a set of transition rules that
describe the component’s behaviour. However, there is no distinction between func-
tions that are only accessible within a module (i.e., functions that are local), and
functions that are accessible by other modules as well (global functions). Thus, the
module structure turns out to be a flat structure of transition rules without local
name spaces, i.e., every function is globally known. The transition rules, according
to the ASM semantics, fire simultaneously.
Every component in the Production Cell executes a sequence of actions depend-
ing on the situation in the cell. This can be easily modelled by simple conditional
update rules: in a particular situation (modelled by the guard of the rule) the
component does something (modelled by the corresponding set of updates).
To give an example, we describe the transition rules of the concrete model that
describe the behaviour of the feed belt (see Figure 7.6). The rules specify the be-
haviour of the belt in three different states: NormalRun,Stopped,andCriticalRun.
These states are specified through the status of the feed belt motor (being on or
off) and the flag Delivering indicating if a blank is delivered to the table.
107
Chapter 7 Case Studies
FB NORMAL
if NormalRun∧PieceInF eedBeltLightBarrier
then FeedBeltFree := true
if TableReadyForLoading
then Delivering := true
else FeedBeltMot := off
FB STOPPED
if Stopped ∧TableReadyForLoading
then FeedBeltMot := on
Delivering := true
FB CRITICAL
if CriticalRun ∧¬PieceInFeedBeltLightBarrier
then Delivering := false
TableLoaded := true
where NormalRun ≡FeedBeltMot =on ∧¬Delivering
CriticalRun ≡FeedBeltMot =on ∧Delivering
Stopped ≡FeedBeltMot =off
TableReadyForLoading ≡T ableInLoadP osition ∧¬TableLoaded
T ableInLoadP osition ≡BottomPosition ∧MinRotation
∧TableElevationMot=idle
∧T ableRotationMot =idle
Figure 7.6: Transition Rules for the Feed Belt
The original model heavily uses macro definitions, like TableReadyForLoading
for instance (see Figure 7.6). For transforming the model into the SMV language,
we expand these macro definitions and replace the appearance of the macros in the
rules with the equivalent expressions. In the given fragment of the model (in Figure
7.6), it is not visible that some functions are accessed in more than one module
(e.g.,TableElevationMot or TableRotationMot). The function TableLoaded is even
updated in two different modules, the feed belt and the robot.
Although the behaviour of each component appears to be quite simple, the be-
haviour of the whole system is not so easily validated. Since all transition rules
fire simultaneously, the possible interference is difficult to analyse. Model check-
ing appears to be a helpful means for checking if the concurrent behaviour of the
components is correct. However, in order to apply model checking, we have to spec-
ify the behaviour of the environment. This is discussed in the next section. Our
investigations with the SMV tool are summarised in Section 7.2.4.
7.2.3 The Environment Assumptions
In the given ASM model of the Production Cell, the environment is represented
by a list of external functions (see Figure 7.7, and also the ASM-SL model in the
appendix in Section A.3). Each of the external functions represents a sensor variable
that influences the behaviour of the Production Cell.
During the transformation from ASM into the SMV language, external functions
are mapped into state variables. Since these state variable are not controlled by
108
The Production Cell Section 7.2
external function PieceInFeedBeltLightBarrier :BOOL
external function MaxRotation :BOOL
external function MinRotation :BOOL
external function TopPosition :BOOL
external function BottomPosition :BOOL
external function Arm1Ext :SENSOR_1
external function Arm2Ext :SENSOR_1
external function Angle :SENSOR_2
external function TopPositionPress :BOOL
external function MiddlePositionPress :BOOL
external function BottomPositionPress :BOOL
external function ForgingComplete :BOOL
external function PieceInDepositBeltLightBarrier :BOOL
external function GripperOverDepBelt :BOOL
external function GripperOverFeedBelt :BOOL
external function GripperVerticalPos :SENSOR_3
Figure 7.7: External functions that model sensor variables
the system, their behaviour is unspecified in the resulting SMV model. The model
checker has to check each possible behaviour. This leads to counterexamples that
show not intended behaviour of the environment. We call such an output a wrong
counterexample (see also the discussion in Section 5.1).
In order to avoid wrong counterexamples in the case of embedded systems, we
have to model assumptions that are stated on the environment. For the Production
Cell, these assumptions concern the length of the belts (they have to be finite)
and the mechanical behaviour of the motors: They are not distorted by mechanical
faults and perform at a constant speed which is reached instantaneously after being
switched on.
These assumptions are fairly minimal, and yield only a small restriction on the
behaviour of the sensor values. In particular, they do not provide any hints about
the duration of an environment reaction. For instance, the duration for transporting
a blank on the belts can be arbitrary. We only assume that if a blank is put onto
the belt then eventually it will reach the end of the belt if the motor is not stopped
for ever. To model this assumption properly, we need a temporal logic.
Since the SMV tool does not support temporal logic for modelling system prop-
erties, the environment assumptions have to become a part of the system model.
Therefore, we have to model the environment in terms of ASM transition rules3.
For instance, the behaviour of the sensor variable P ieceInFeedBeltLightBarrier
may toggle in one step if the feed belt motor is running, the feed belt is not free,
and the piece is not yet delivered (see the ASM transition rule in Figure 7.8).
A full model of an environment specification is given in the appendix (see Section
A.3.2). The model checking results must always be interpreted with respect to
the added environment model. If the model checker indicates that the checked
properties are satisfied, they still might be violated for a different environment.
Errors can be overlooked that appear only in cases that do not match the chosen
environment model.
3Note that through adding these rules the external functions turn into dynamic functions since
they are now controlled by the ASM model.
109
Chapter 7 Case Studies
if FeedBeltMotor =on ∧¬(FeedBeltFree)∧¬(Delivering)
then PieceInFeedBeltLightBarrier := true
else if FeedBeltMotor =on ∧Delivering
then PieceInFeedBeltLightBarrier := false
Figure 7.8: ASM model for the sensor variable PieceInFeedBeltLightBarrier
Alternative approaches for the environment model
Our chosen environment model is deterministic since we fix the duration of reactions.
As a result, we get a system model that is too restrictive. Alternatively, we could
have modelled non-determinism by means of introducing an external function that
determines the number of steps for modelling a non-fixed duration of reactions. This
approach would provide unbounded non-determinism for the environment behaviour
if the external function is modelled as an integer value. However, an external
function over an infinite domain cannot be treated by the model checker.
Therefore, we have to restrict the number of choices. For example, a piece on the
feed belt may reach the end of the belt in one, two or three steps (c.f., Figure 7.8).
However, this model does not completely catch the unbounded non-deterministic
behaviour either, which was originally assumed. We cannot guarantee that the
critical cases are included in the chosen subset. A crash may occur if the feed belt
needs four or five steps for transporting a blank.
7.2.4 Model Checking the Production Cell Model
For model checking the ASM model of the Production Cell, we investigate the safety
requirements of the system as they are listed in [LL95] and [Mea96]. Also, we argue
that the liveness property can be formalised and checked in an abstract way.
The Safety Requirements of the Production Cell
The safety requirements of the Production Cell are given as properties of its com-
ponents, but the simplicity of the system allows us to check the system as a whole.
We specify each property as a single formula and form the conjunction of this set of
formulas in order to get the requirement specification. By means of an example, we
show how to formalise the requirements in CTL. The full CTL specification of all
requirements of the Production Cell is given in the appendix (see Section A.3.3).
Safety of the Press As an example, we describe the formalisation of the safety re-
quirements for the press. These requirements are informally given in [LL95] through
the following two points:
1. “The press is not moved downward if it is in the bottom position; it is not
moved upward if it is in the top position.”
This is easily described using the state variables that model the motion of the
press motor and the oracle functions for the position of the press: if the bottom
position is reached, the press motor should not move downward; similarly, if
the top position is reached, the press motor should not move upward.
We have to bear in mind that the condition of reaching the top or bottom
position is also a condition for switching the motor to idle. Therefore, we
profit by the next step quantification of CTL stipulating that whenever the
boundary is reached in all possible next states, the motor should not move the
110
The Production Cell Section 7.2
press in this direction4.Weget:
AG (bottomPositionPress ⇒AX (PressMot 6=down))
∧AG (topPositionPress ⇒AX (PressMot 6=up))
2. “The press only closes when there is no robot arm inside it.”
The press is closing when the motor is running up. In this case, neither arm 1
nor arm 2should ever be in the press. In terms of the ASM press model, the
arms are in the press if the angle has the value Arm1ToPress or Arm2ToPress
and the arm is completely extended. This leads to the following formula:
AG (PressMot =up
⇒¬(Arm1Ext =Arm1IntoPress ∧Angle =Arm1ToPress)
∧¬(Arm2Ext =Arm2IntoPress ∧Angle =Arm2ToPress))
Similar to the example of the press, we formalise the safety requirements for the
other components (see the appendix, Section A.3.3, for a full listing).
The behaviour of the external functions which model the environment has to be
specified as well in order to reflect the Cell Assumption (see [Mea96]) that requires
a reasonable system environment.
The model checker concluded that the conjunction of all safety formulas is
satisfied by the SMV model of the Production Cell with respect to the environment
model that is added. The output shows the resources used:
resources used:
user time: 3.8 s, system time: 1.03333 s
BDD nodes allocated: 43529
Bytes allocated: 18087936
BDD nodes representing transition relation: 25718 + 1
The Liveness Property of the Production Cell
Liveness of the Production Cell is formulated as “Every blank inserted into the
system via the feed belt will eventually be dropped by the crane on the feed belt again
and will have been forged”. Mearelli proved in [Mea96] the liveness property with
reasoning about the blanks that are being passed the system. For applying model
checking, however, this approach is not feasible since blanks are not represented in
our model. We cannot express the liveness properties in terms of blanks. Therefore,
we base our approach on a different proof idea.
Liveness, in the most general sense, means that eventually something good will
happen (see e.g. [CMP92]). The good thing that should happen in our case is that
every blank will return to the feed belt and will have been forged. Since the overall
process is a cycle which consists of a sequence of steps, we have to check that it is
always true that the next step in the process cycle will eventually be executable. If
this requirement is satisfied no deadlock will occur.
We split the cyclic process into a sequence of actions for processing one blank.
For the liveness property, it suffices to show that a blank is treated by every com-
ponent of the cell in this sequence of actions: It should be transported by the feed
belt to the elevating rotary table, should be moved by the robot to the press, and
from there to the deposit belt, where the travelling crane puts it back to the feed
belt. Then the cycle of the process is closed.
4In the real-life system, we have to require that the boundary be set with a sufficient margin
in order to be able to stop the motor at a safe distance to prevent a collision.
111
Chapter 7 Case Studies
Treating a blank is described in an abstract manner: e.g. a blank is transported
by the feed belt if the feed belt changes from NormalRun to CriticalRun. In Figure
7.9, we identify the pairs of actions which are control-critical moments in the process
cycle of the Production Cell.
FeedBelt is in NormalRun FeedBelt is in CriticalRun
FeedBelt is in CriticalRun Table is stopped in load position
Table is stopped in load position Table is stopped in unload position
Table is stopped in unload position Robot has unloaded Table
Robot has unloaded Table Press is OpenForLoading
Press is OpenForLoading Robot has loaded the press
Robot has loaded the press Press is ClosedForForging
Press is ClosedForForging Press is OpenF orUnloading
Press is OpenForUnloading Robot has unloaded the press
Robot has unloaded the press Robot has loaded DepositBelt
Robot has loaded DepositBelt DepositBelt is in NormalRun
DepositBelt is in NormalRun DepositBelt is in CriticalRun
DepositBelt is in CriticalRun Crane has unloaded DepositBelt
Crane has unloaded DepositBelt Crane has loaded FeedBelt
Crane has loaded FeedBelt FeedBelt is in NormalRun
Figure 7.9: Pairs of actions that describe progress
We formalise progress in terms of these pairs of actions by means of CTL for-
mulas of the form
AG (action executable ⇒AF (next action executable))
Following the semantics of CTL, this is satisfied if it is always (in every path in ev-
ery state) the case that once action is executable then eventually next action will
be executable. We consider all pairs of actions and their successor actions as given
above and get a set of CTL-formulas of this form. The liveness property is consid-
ered to be the conjunction of all these progress formulas. (The full specification of
the liveness property is given in the appendix in Section A.3.4.)
Moreover, to ensure that action executable will be reached at all, we have to
verify that eventually the action will be executable:(AF action executable)hasto
be checked for every first action in the set of action pairs.
We checked our specification of liveness against the SMV model of the concrete
system of the Production Cell. We found that the system satisfies the property if
(and only if) the initial condition guarantees that there are at least two blanks in
the system. Otherwise, the robot cannot operate properly. Due to the optimised
design of the Production Cell, the robot, whenever it puts a blank into the press
with one arm, it also takes a forged blank from the press by means of the other arm.
Since we do not model an operator that puts new blanks on the feed belt, we have to
change the initial condition in order to get more than one blank within the system
(see the Insertion Priority Assumption and the proof of the Strong Performance
Property in [BM97]). We specify the initial states5as given in Figure 7.10. This
initial condition models the situation that seven blanks are in the Production Cell
(where two blanks are lying on each belt). If we add more blanks (e.g., by setting
Arm1Mag to on), the model checker finds a deadlock.
5With respect to the model given in [Mea96], we only keep the initial values for Angle,Arm1Ext,
Arm2Ext,Arm1Mag,Arm2Mag,andPressLoaded. For every other function in Figure 7.10, we
change the initialisation.
112
The Production Cell Section 7.2
FeedBeltMot =idle
FeedBeltFree =false
PieceInFeedBeltLightBarrier =true
Angle =Arm1ToTable
Arm1Ext =retracted
Arm2Ext =retracted
Arm1Mag =off
Arm2Mag =off
TableLoaded =true
PressLoaded =true
DepBeltMot =idle
DepositBeltIsReadyForLoading =false
PieceAtDepBeltEnd =true
CraneMagnet =on
Figure 7.10: Liveness condition for initial states
With respect to the changes listed above and the given model of the environment
no error could be found. The SMV tool returns the following output:
resources used:
user time: 10.1333 s, system time: 0.95 s
BDD nodes allocated: 56832
Bytes allocated: 18350080
BDD nodes representing transition relation: 25718 + 1
We conclude that the system model with respect to the given environment model
satisfies the liveness property as required in the problem definition.
The Agent Progress Lemma B¨orger and Mearelli [BM97] introduce the Agent
Progress Lemma in order to prove the liveness of the system. The proof of this
lemma requires inspection of the rules. We suggest supporting the user with the
model checker in order to check the interactive behaviour of the overall system.
The Agent Progress Lemma is split into six parts. Each part describes the
progress of one of the agents with respect to the values of the interface functions.
We formalise each of the parts in one CTL formula. The conjunct of these formulas
gives the formalisation of the progress requirement of the agents.
Model checking the formulas of progress verifies that the SMV model satisfies
the progress requirements if we choose the same initial condition as described in
the last section. We conclude that the Agent Progress Lemma holds for the given
system model with respect to the given environment model.
7.2.5 Discussion
The Production Cell model was chosen as a preliminary example of our approach
of model checking ASM. It shows that in principle the SMV tool can be used to
analyse ASM models. At the same time, however, this case study reveals a major
drawback of this approach.
As an embedded system, the Production Cell involves a high degree of non-
determinism due to the external functions that model sensor variables. We are not
able to treat this kind of system properly by means of the SMV tool. Since additional
assumptions on the behaviour of the environment (i.e., the sensor variables) must
be modelled when doing model checking, we are forced to do so in a state-based
113
Chapter 7 Case Studies
way with a bounded number of choices. Such a state-based model, in contrast
to a model based on temporal logic, restricts the unbounded non-determinism for
possible behaviour. As a consequence, model checking decreases to a non-exhaustive
test since not every possible behaviour is modelled.
However, the behaviour of the sensor variable PieceInFeedBeltLightBarrier, e.g.,
is nicely expressed in LTL by
¬(FeedBeltFree)⇒F(PieceInF eedBeltLightBarrier)∨FG(FeedBeltMot =off )
This formula states that eventually the blank will arrive at the end of the belt or
the feed belt motor will remain turned off. A similar model of the belt behaviour
is not finitely expressible in a state-based way.
Using a deterministic environment or an environment model that is too restric-
tive may help to find some errors but it does not provide a reliable analysis method.
In [Plo00], Plonka investigated the ASM model of the Production Cell by means of
the model checker SVE ([F+96]). SVE is a model checker for CTL model check-
ing that allows LTL formulas to be integrated into the system model. The tool is
designed according to the work of Clarke, Grumberg, and Hamaguchi ([CGH97])
which is described in Section 3.4.2. Due to this extension, the environment model
can be given in terms of LTL. Plonka found an error in the model of the Production
Cell by means of increasing the choices of behaviour in the environment model.
This error was not detected in our approach. This increasing of choices for the
environment behaviour, however, may cause state explosion. For this reason, it was
not possible to check liveness of the model with the approach given in [Plo00].
We conclude from this experience that a combined approach for CTL and LTL
model checking would be helpful for analysing embedded systems. However, as the
results in [Plo00] show, we need additional support for reducing complexity of the
model checking task. This nicely motivates the work that is introduced in the next
chapter: the interface from ASM to the MDG-Package.
Within the framework of MDGs, model checking algorithms are available that
provide the same benefits as symbolic model checking for LTL discussed in Section
3.4: It is a symbolic model checking approach based on decision graphs and it allows
the user to introduce logical assumptions into the system model. Furthermore,
MDGs support abstraction. As the discussion above shows, it is crucial for most
applications to reduce the complexity of the model’s state space. Abstraction is a
suitable means for this reduction.
114
Chapter 8
The MDG-Package
8.1 Interfacing the MDG-Package
In Chapter 6, the interface from the ASM Workbench (ASM-WB) to the SMV
model checker is described. In this chapter, we focus on our second approach, the
interface to the MDG-Package. This interface provides another means for analysing
ASM models and supports abstraction.
The data structure that the MDG approach is based on are multiway decision
graphs (MDGs) ([CZS+97], [CCL+97]). They are described in chapter 4 on page 51
as a generalisation of BDDs. The basic algorithms for MDGs (e.g., those described
in Section 4.2.3) are prototypically implemented in Prolog by Zhou and others;
[Zho96] is a recommendable documentation of this package.
In the literature, the MDG approach is introduced as a method for analysing
hardware models given in a hardware description language called MDG-HDL. In-
variant checking and reachability analysis is introduced in [CZS+97, CCL+97]. Ap-
plications of these approaches are described, for instance, in [ZST+96, LTZ+96].
Model checking of MDG-HDL specifications using a linear temporal logic is intro-
duced in [Xu99, XCS+98]. MDG-HDL defines the front-end of the tool. To use it
for model checking ASM, we would have to map ASM transition rules into MDG-
HDL. However, this does not seem be the closest mapping since any ASM model
must be “simulated” (or re-modelled) in terms of a hardware description. Instead,
it appears to be more reasonable to map ASM to MDGs directly. Doing so, we
cannot use the checking framework of the MDG group as a black box tool with a
language front-end as with SMV, for instance. Instead, we consider the underlying
basic functionality of MDGs and tailor a checking tool for our own needs. That
is, we provide an “interface” to the MDG-Package rather than to the “MDG-tool”.
This interface is realised by representing the ASM models through MDGs.
Our choice to extend our tool framework with an interface to the MDG-Package
is mainly guided by three interests:
1. Since both notions, ASM and MDGs, are closely related to each other, the
transformation from ASM into the MDG structure is easier and more concise
than the treatment of the syntax of another input language (for instance, the
SMV language) would be.
2. MDGs as a data structure for representing transition systems provide a pow-
erful means for abstraction in order to fit large models into the model checking
process.
3. Since the MDG-Package (cf. [Zho96]) is a well documented collection of basic
functions that are sufficient to implement various types of model checking
115
Chapter 8 The MDG-Package
algorithms, we are able to tailor a new checking tool according to our needs
(in contrast to a black box tool for which either the code is not available or
utterly undocumented). The basics for model checking LMDG formulas1are
given in [Xu99] for another input language. If we adapt these algorithms to
our notation, the resulting tool will be an LMDG model checker for ASM. This
tool will nicely complement the facilities for checking CTL formulas given by
the SMV tool (see the discussion in Section 9.2).
In the following, we go into detail about the three points for choosing MDGs as
an appropriate data structure for supporting ASM analysis.
To start with the first claim, Section 8.2 compares ASM and MDGs. In Section
8.3, we describe our notion for supporting abstraction for ASM models based on
MDGs. This should serve as a motivation for using MDGs for model checking ASM.
We give an example in order to show how to use our approach. In Section 8.4, we
introduce the transformation from ASM into MDG. Since we want to make use of
abstract data that can be treated within the MDG approach, we have to extend
the ASM language with syntax for abstract sorts. As a consequence, we have to
extend the transformation algorithm that is described in Section 5.2. Subsection
8.4.1 introduces the extended transformation from ASM to ASM-IL. We can show
that the extended transformation maps ASM models into an extended intermediate
language ASM-IL+that satisfies the conditions for being a directed formula (see
Section 4.2.1). These formulas can be represented by MDGs. Section 8.4.3 intro-
duces the second step of the transformation that completes the interface from the
ASM-WB to the MDG-Package.
8.2 ASM versus MDG
In order to justify the claim that is made in the first point above, we start with a
comparison of the two notations. Although one is a specification language and the
other one is a basic graph structure, they have a common base.
Many-sorted first-order logic. Both notations, ASM and MDGs, are based on
many-sorted first-order logic: Gurevich uses the notion of many-sorted first-order
structures to describe states of a system and adds transition rules for modelling the
system behaviour during a run (see e.g., [Gur97] or Chapter 2). The MDG approach
uses so called “Abstract State Machines” too in order to identify the system that
is to be analysed. Its (sets of) states, transition and output relation are described
by means of directed formulas (DF) which are a certain class of formulas of many-
sorted first-order logic (see e.g., [CCL+97]). This coincidence of the identical naming
“Abstract State Machine” is understandable in that both constructs describe the
same thing. However, Gurevich’s ASM is a formal, high-level language for modelling
where, in the MDG approach, the MDG-HDL language is used for modelling rather
than their concept of abstract state machines.2
Abstract sorts. The difference between the languages, however, is given through
the lack of abstract sorts in ASM language. To overcome this difference, we intro-
duce this notion into ASM-SL as a kind of “syntactic sugar”. Given this, we are
able to indicate that a certain sort (or type) is abstract and thus every function that
is applied to parameters of this type is either a cross-term or an abstract function
1LMDG is a sub-language of Abstract CTL* which is the universal fragment of first-order CTL*
with abstract sorts.
2Note, that throughout this chapter we use the term ASM to denote the specification language
and not the mathematical construct.
116
Generating Abstraction Section 8.3
and has to be left uninterpreted. This distinct treatment of abstract sorts and the
involved functions can be handled fully automatically and is implemented in our
extended transformation algorithm.
ASM-IL+as MDG. The intermediate language for ASM (ASM-IL) that is intro-
duced as a general interface language for the ASM-WB (see Section 5.2) is extended
to a language ASM-IL+in order to treat abstract terms. ASM-IL+thus provides
an interface to the MDG-Package. This format is similar to the notion of directed
formulas (DFs) (see Section 4.2). DFs can be represented by MDGs in order to
utilise the succinct representation and efficient algorithms defined on them (com-
parable to the OBDD algorithms that are used in other symbolic model checkers).
The representation is canonic as shown in the literature (see [CZS+97] for a proof).
The similarity of guarded updates in ASM-IL+and DFs is given through the
fact that both describe simple state transition system. In ASM-IL+,thetransi-
tion relation is given as a set of tuples over locations and their guarded update set
{loc0
i,{guardij ,valij |1≤j≤m}|1≤i≤n}. This set automatically provides a
proper partitioning of the transition relation which helps to decrease the complex-
ity of a model representation by decision diagrams (see discussion in Section 8.4.2).
Moreover, the term unfolding (on concrete terms) that is implemented in the trans-
formation algorithm ensures that all terms in our ASM-IL+model are concretely
reduced. This condition is necessary to preserve the well-formedness of the resulting
graph.
In Section 8.4.2, we show in more detail that an ASM model after applying our
transformation (i.e., ASM-IL+models) preserves all of the well-formedness con-
ditions on DFs and MDGs. Thus, ASM models can be represented by a set of
well-formed MDGs.
In the next section, we discuss the support for abstraction that is provided
through the MDG framework. Since model checking is introduced as a fully auto-
matic tool support for analysis, it is important to provide support for the necessary
abstraction task as well. We illustrate our notion of automatically generating ab-
stract models once the data that should be abstracted are chosen. This is a very
simple approach that still needs to be tested in practice.
8.3 Generating Abstraction
The MDG approach supports the distinction between concrete and abstract sorts.
As a consequence various kinds of functions are relevant: concrete functions, ab-
stract functions (with an abstract range), and so called cross-terms (functions with
a concrete range but abstract parameters). Introducing the notion of abstract sorts
and the facility for determining and distinguishing the kinds of functions provides
a basis for automatically generating abstract models.
Applying abstraction to any given model is a useful means for reducing the size of
the model. We strip off information that is not directly referred to in the properties
to be checked. The abstracted terms and values can still be accessed within guards
that influence the control flow of the system since any kind of boolean operator can
be applied in order to compare their current evaluation in a state. These boolean
operators yield a simple case distinction that can be explored exhaustively.
As a simple example, see the specification of a generic timer in Figure 8.1. The
system gets as an input value any natural number max that specifies the number
the timer has to count to. The timer has two states, COUNT and RING.Aslongas
the system is in state COUNT it increments the state variable tin every step. Once
thas reached the limit max the system changes into state RING; a bell might ring
117
Chapter 8 The MDG-Package
to give a signal. In the next step, tis reset and the timer starts again counting to
max.
max
reset(t)
if (t<max)
then incr(t)
if (t=max)
RING
COUNT
reset(t)
Figure 8.1: Example of a simple timer specification
This system specification can easily be abstracted by treating the natural num-
bers Nas abstract sort Nabs. We replace the equality relation on natural number by
a new predicate isEq that compares two abstract values of sort Nabs;isEq(t, max)
may evaluate to true if the (abstract) arguments are equal, otherwise it evaluates
to false. The functions incr and reset turn into abstract functions that map any
value of sort Nabs into a value of the same sort.
In the MDG approach, predicates like isEq are cross-term symbols; they are
applied to abstract terms and evaluate to a value of concrete sort (in our example,
boolean values). When model checking, we can use cross-terms since their range
is a concrete type that can be enumerated. Without any knowledge of the value
of the abstract parameter, we simply unfold the different (enumerate-able) cases
and explore them when model checking. This may lead to exploring states that do
not occur in the concrete model and hence may yield wrong counterexamples. We
address this problem in the next section.
8.3.1 The Non-Termination Problem
Abstract functions and variables are treated as being uninterpreted, i.e., every in-
terpretation is possible. We may describe the step of abstraction as stripping off
semantics by giving up information about interpretation. Thus, the abstract speci-
fication is a model for all structures with the same signature. That is, an abstract
model describes a set of concrete models with suitable (with respect to the signa-
ture) interpretations for abstract sorts, functions, variables, and cross-terms. Figure
8.2 depicts the abstraction step: We consider the sort Qin our concrete model as
abstract and change all its occurrences into Dataabs. As a result, we get an abstract
model of the same signature. For this abstract specification, all those interpreta-
tions are suitable that have a sort, a 2-ary function that maps arguments of the
given sort to a value of the same sort, and a boolean predicate over the sort. In the
figure, we give some examples for different interpretations for the sort Dataabs and
the functions that are possible.
The purpose of this abstraction step is to substitute infinite sorts, and functions
over them, since these cannot be exhaustively explored. The use of cross-terms on
abstract sorts and their complete case distinction naturally provides a partitioning
of the infinite sorts into finitely many equivalence classes. The state space of the
abstract model is smaller in most cases. It can be canonically represented by MDGs
and the corresponding model checking algorithm can be applied to check certain
properties.
In some cases, however, we run into the problem of non-termination or false
negatives (see [CZS+97], [CCL+97], [MSC97]). The abstract model may allow an
interpretation that includes cases that are excluded for the concrete model that we
118
Generating Abstraction Section 8.3
abstract model
concrete model
stripping off
interpretation:
a
ppend
:
Q
Q
!
Q
is empty
:
Q
!
B ool
g
abs
:
Data
abs
Data
abs
!
Data
abs
f
abs
:
Data
abs
!
Bool
other concrete models as instances
mult
:
Int
Int
!
Int
is even
:
Int
!
B ool
op
:
Word
Word
!
Word
is int
:
Word
!
Bool
model checking MDG representation
Q
:
Data
abs
Figure 8.2: Lifting a concrete model to an abstract model
want to investigate. For instance, in the concrete model over the sort of queues,
denoted as Qin Figure 8.2, it is obviously the case that if we append two queues
that are not both empty the resulting queue is not empty either:
(¬(is empty(q1)) ∨¬(is empty(q2)) ⇒¬(is empty(append(q1,q
2))).
However, in another interpretation, e.g., over integers Int, the same rule might be
violated:
(¬(is even(q1)) ∨¬(is even(q2)) ⇒/¬(is even(mult(q1,q
2))).
If the value of the predicate is empty is determining the control flow, the ab-
stract model may include behaviour that is not intended in the original model. This
unintended behaviour may cause false negatives (we called them wrong counterex-
amples in Section 5.1) or may lead to a reachability analysis that does not terminate
although the intended concrete model satisfies the termination criteria.
One means to overcome the problem
caused by unintended interpretations is to
add axioms over the abstract functions and
cross-terms of our (partly abstract) signa-
ture. Adding axioms to the abstract model
can be seen as a refinement step: some in-
formation that was lost because of the ab-
straction step is introduced into the model
again (see Figure 8.3). These axioms can
be formulated as rewrite-rules (denoted as
rr(...) in the figure) which are fed into
the Prolog system that computes the MDGs
and runs the model checking procedures. Ba-
sically, rewriting in Prolog causes a substitu-
tion of any term that matches the pattern in
+ rr(isEq...)
+ rr(append...)
concrete
model
abstract
model
abstract
refine
Figure 8.3: Adding axioms for refinement
the rewrite rule. Adding rewrite rules into the system is supported by a function
that is available in the MDG-Package (see [Zho96]).
Obviously, it has to be proved that the rewrite rules that are added to the
abstract model are correct for the concrete model we want to check. For instance,
in the example in Figure 8.2, we have to proof that the axiom (to be modelled in
119
Chapter 8 The MDG-Package
terms of the abstract model)
∀q1,q
2∈Dataabs :(¬(fabs (q1)) ∨¬(fabs (q2))) ⇒¬(fabs (gabs(q1,q
2)))
is satisfied for the interpretation ψthat maps the abstract sort and function symbols
to the sort and functions of the concrete model, i.e., ψ(Dataabs)=Q,ψ(fabs )=
is empty and ψ(gabs )=append.
If the system developer who uses the MDG approach fails to add all rewrite rules
that are necessary for avoiding the non-termination problem, it is still guaranteed
that the model checking algorithm is correct since it never gives a false positive
result. That is, if the result of the checking procedure states that the model satisfies
the properties to be checked then this holds for any interpretation of our model.
In the worst case, the MDG checking is either not applicable because it does not
terminate, or it yields a counterexample that is not a proper run for the concrete
system at hand. In the latter case, the user will identify this as a false negative
when investigating its interpretation in the concrete model.
Other approaches for generating an abstraction of a model prove that the chosen
abstraction function is property preserving (see Section 9.1). This proof would be
comparable with a proof that the set of added rewrite rules exhaustively reflects the
properties on abstract functions and cross-terms and, therefore, no false negatives
could occur. This is a much more complex proof task than the one that is intended
in our approach (c.f., [SS99, LGS+95]).
8.3.2 Automatic Support for the Generation
Lifting a model to a higher level of abstraction can be done automatically within
our transformation step from ASM to MDG provided the developer has chosen the
domains of the ASM that should be considered as abstract sorts. Functions in the
ASM model that involve abstract data are automatically treated as abstract func-
tions or cross-terms. In contrast to any other approach of generating abstraction,
there is no extra effort necessary to change the model under investigation other
than the change of the data type definition.
•Any function symbol that maps into an abstract sort is treated as an ab-
stract function (e.g., function fabs in Figure 8.2). These functions are left
uninterpreted.
•Any function that applies to some arguments of abstract sort but maps into
a concrete sort are treated as cross-terms (e.g., function gabs in Figure 8.2).
Abstract functions are not unfolded by our transformation algorithm. We say
that abstract functions are left uninterpreted since unfolding involves the evaluation
of a term (see Section 5.2 and in particular Figure 5.4 on page 71). Obviously,
abstraction simplifies the transformation (less terms have to be unfolded) and also
reduces the size of the resulting model to be checked (unfolding of terms causes
the generation of many rules instances). (See Section 8.4.1 for more details of our
extended transformation that can handle abstract sorts and functions.)
Operators that are built-in in the target language, the primary operators (see
Section 5.2.1 on page 75), are not unfolded in our transformation algorithm, i.e.,
we keep the corresponding terms as they are. These operators have to be renamed
when they become abstract in order to avoid name clashing between the abstract
and the concrete function symbol. In particular, boolean predicates over a domain
that might be abstracted (e.g., numbers) are renamed in order to denote the “lifted”
cross-term. The following renaming mapping for predicates is implemented in our
120
Generating Abstraction Section 8.3
transformation algorithm and thus automatically applied during the transformation:
(a=b)⇒isEq(a, b)
(a6=b)⇒isNeq(a, b)
(a<b)⇒le(a, b)
(a<=b)⇒leq(a, b)
(a>b)⇒ge(a, b)
(a>=b)⇒geq(a, b)
(8.1)
To give an example, we consider the term x=Min a guard. In the original
model both terms xand Mare of some concrete but possibly infinite type. We may
change the model by editing the sorts of xand Mto be abstract. Correspondingly,
the equation will be transformed into the cross-term isEq(x, M). To complete the
expression for building an MDG (c.f., the well-formedness conditions on MDG in
Section 4.2), we add the concrete equality: isEq(x, M)=true.
For the most common boolean predicates, new cross-operators are pre-defined as
shown in the mapping in (8.1). These cross-operators provide a natural partitioning
on concrete sorts such as integers, real numbers, ordered sets, etc. The mapping
may be extended according to a particular problem domain that involves other
predicates. Any other function symbol that is applied or mapped to a term that is
turned into an abstract term is left unchanged.
Our transformation (see Section 8.4.1) is a useful means for supporting abstrac-
tion of models that are not treatable by the checking algorithm. The generation
of the abstract model is done automatically according to the different treatment of
concrete and abstract functions or cross-terms. New function symbols for boolean
functions that turn into cross-terms are introduced automatically. In the following
section, we give a simple example of abstracting an ASM model.
8.3.3 A Simple Example
We use the simple example of the timer given in the last subsection in order to
illustrate how to generate an abstract model. Figure 8.4 shows a concrete model of
the timer that counts to some number max which is given as input.
The transition rules of our timer model reflect the behaviour of the state machine
in Figure 8.1 on page 118. We can check this model for correctness for a particular
input value (max <n), e.g., for an input 10 the timer should never exceed this
limit.
Assume that we want to check the correct behaviour of the timer not only for
any maximum that is less than a particular nbut for an arbitrary n.Wecanuse
abstraction to do this. As described in the last subsection, the abstraction step
affects only the definition of the domains and the declaration of functions, i.e., the
state space definition. Therefore, Figure 8.5 which depicts the abstract model of the
timer, only shows the state space definition; the transition rules remain unchanged.
Note that in the given example the benefit of our abstraction support is less obvious
since the model consists of only four rules, which are very simple. Other models,
however, may have a large amount of very complex rules. The effort required to
remodel these rules by hand can be significant.
When abstracting a concrete model, we define some domains as being abstract.
In Figure 8.5 the domain TIME turns into an abstract domain. The notation for
an abstract sort is a singleton that contains a string that starts with the substring
“abstract”. This is a workaround for we lack a proper keyword in ASM-SL, the input
language of the ASM-WB. However, it still allows using the internal type-checker
121
Chapter 8 The MDG-Package
MODE ={count,ring}
TIME ={1..n}
external function max :TIME
static function reset :TIME →TIME == {t7→ 0|t∈TIME}
static function incr :TIME →TIME == {t7→ (t+1)|t∈TIME}
dynamic function mode :MODE
dynamic function timer :TIME
if (mode = count)∧(timer <max)
then timer : = incr(timer)
if (mode = count)∧(timer = max)
then mode : = ring
if (mode = ring)
then mode : = count
timer : = reset(timer)
Figure 8.4: The concrete ASM model for the timer
of the ASM-WB3. Since the type-system of ASM-SL allows only a strongly typed
signature (i.e., each term has a unique sort), the strings that indicate abstract sorts
must differ in the substring that follows the prefix “abstract”. In our automatic
treatment of abstracted models, we recognise an abstract sort by matching only the
initial substring of this string. This way, we can introduce more than one abstract
sort.
Static functions that turn into abstract functions map an abstract value to an
abstract value. For example, the functions reset and incr are defined in Figure 8.5
by the mapping abstractTime →abstractTime. These functions are not evaluated
in our transformation since they are of abstract sort.
Applying the extended transformation algorithm the ASM model is simplified
and flattened to a set of guarded updates for every primed location. We get a list
of tuples of the form {loci,[(guardij ,valij )]}:
{(timer’,[((mode = count )∧(le(timer, max) = true)),incr(timer),
(mode = ring),reset(timer)])
(mode’,[((mode = count)∧(isEq(timer, max) = true)),ring,
(mode = ring),count ])}
Note that the “values” in the guarded update pairs need not be values anymore.
We may have abstract functions as well (incr(timer) and reset(timer) in our
example). These guarded updates can be represented in an MDG as shown later.
In order to avoid non-termination or even to reduce the state space of the model,
axioms can be added by means of rewrite rules. These additional rewrite rules
provide a means for refining the abstract model successively (c.f., Figure 8.3). In
3Since we do not evaluate abstract terms, this notation for abstract sorts (that models them
as being enumerated rather than infinite) has no impact on our approach.
122
Generating Abstraction Section 8.3
MODE ={count,ring}
TIME ={abstractTime}
external function max :TIME
static function reset :TIME →TIME == {abstractTime 7→ abstractTime}
static function incr :TIME →TIME == {abstractTime 7→ abstractTime}
dynamic function mode :MODE
dynamic function timer :TIME
Figure 8.5: The abstract ASM model for the timer: the state space
the given example, we add rewrite rules over the cross-terms isEq() and le() in
order to exclude not-intended interpretations of the function symbols. For instance
∀a, b :
isEq(a, b)⇒¬(le(a, b))
le(a, b)⇒¬(isEq(a, b))
le(a, b)⇒¬(le(b, a))
isEq(a, b)⇒isEq(b, a)
These rewrite rules can be expressed as rewrite rules in the MDG-Package. A
rewriting function removes every path in the reachability graph that contains a
contradictory conjunct. That is, no path will comprise node-edge pairs of the form
(isEq(a, b),true)and(le(a, b),true) at the same time. Accordingly, the graph that
represents the reachable states becomes smaller. For a better support, we add a set
of ordinary rewrite rules over equality, <,≤,>,and≥automatically during our
transformation.
In the next section, we introduce the adaption of the transformation algorithm
in order to treat abstract sorts and functions as we suggested above. In a second
step, the guarded updates of the extended ASM interface language (ASM-IL+)are
transformed into MDGs. This completes the interface from the ASM-WB to the
MDG-Package.
123
Chapter 8 The MDG-Package
8.4 The Transformation of ASM into MDG
In order to benefit from the notion of abstract sorts for supporting abstraction, we
have to extend the ASM language with a syntactic feature that allows a sort to be
marked as abstract. This extension requires an extension of the basic transformation
algorithm as well: We have to adapt the first step of the transformation (simplifying
and unfolding of ASM terms and rules, see Section 5.2 on page 68) to the treatment
of abstract functions. These functions are left uninterpreted.
This section is split into two parts: Firstly, we detail the adaption of the basic
transformation algorithm that transforms ASM models into the extended interme-
diate language ASM-IL+. Secondly, we develop a transformation from ASM-IL+
models into MDGs. We have to justify that ASM-IL+rules represent directed for-
mulas of a many-sorted first-order logic (DF) (see Section 4.2 on page 55). These
formulas can be canonically represented by MDGs. The second transformation step
completes the interface from the ASM Workbench to the MDG-Package.
8.4.1 The Adapted Transformation into ASM-IL+
The original transformation algorithm maps all occurrences of dynamic and external
functional terms f(t1,...,t
n)intolocationsf(a1,...,a
n),whichcanberenamedto
simple state variables. This is done by simplifying and unfolding: The evaluation of
parameter terms tito elements aimay be state dependent. Each possible evaluation
of these terms leads to a different location. The result of the unfolding procedure is
a set of locations that are given by all possible evaluations of the dynamic parameter
terms.
Functions and terms of abstract sort cannot be similarly evaluated since their
interpretation is not specified. Unfolding a term involves evaluating it, i.e., adding
the state dependent interpretation to a term. Therefore, an uninterpreted function
cannot be unfolded in any term in which it appears. In order to implement this
special treatment for abstract functions, we have to restrict the unfolding procedure
to functions that are concrete.
Adapted simplification function. The transformation algorithm for simplifi-
cation and unfolding follows an inductive schema. The term simplification [[.]] ζ
is defined in Section 5.2 on page 68. The treatment of abstract functions and
cross-terms is easily introduced into this inductive schema by adding some case dis-
tinctions to the term simplification: abstract terms should not be unfolded to any
evaluation. The modified definition for term simplification is summarised in Table
8.1.
The simplification function [[.]] ζis related to the variable assignment4ζ:V→
SAsince all concrete variables in Vare mapped to the values of the corresponding
concrete sort.
The base of the induction schema is given by simple terms. We distinguish
constant values a,locations loc, that may change their values at a transition step,
and variables v, which can be evaluated to values aif they are concrete (according
to ζ) or left as uninterpreted variables vabs if they are abstract5. Applying the
unfolding function to simple terms changes the term only in the case of a concrete
variable that can be evaluated. Constants, locations, and abstract variables remain
unchanged.
We extend this base by functional terms: Functional terms are abstract func-
tions applied to terms tithat can be abstract terms or concrete values. In Table
4Recall that SAdenotes the universe (or carrier set) of the sort Sin state A.
5The index abs is used in Table 8.1 for indicating that a variable or term is of abstract sort or
is a cross-term.
124
The Transformation of ASM into MDG Section 8.4
Adapted Term Unfolding
for simple terms we distinguish
[[ a]] ζ=avalues and [[loc ]] ζ=loc locations
for variables we get
[[ v]] ζ=a=ζ(v)ifv∈dom(ζ)andofconcrete sort
vabs otherwise
for applied functions we distinguish
[[ ti]] ζ=aifor each i∈{1,...,n}⇒
[[ f(t1,...,t
n)]]ζ=
a=fA(a1,...,a
n)iffis a static
function name of concrete sort
loc =(f,(a1,...,a
n)) if fis a dynamic/external
function name of concrete sort
fabs (a1,...,a
n)iffis a static
function name of abstract sort
locabs =
(fabs ,(a1,...,a
n))
if fis a dynamic/external
function name of abstract sort
if all arguments are of constant sort and
[[ ti]] ζ=loc or [[ti]] ζ=f0(¯
t0)forsomei∈{1,...,n}⇒
[[ f(t1,...,t
n)]]ζ=f([[t1]] ζ,..., [[ tn]] ζ)
if some arguments tiare of abstract sort and [[ti]] ζ=tabs ⇒
if fis a cross-term operator or a static function name:
[[ f(t1,...,t
n)]]ζ=f([[t1]] ζ,..., [[ tn]] ζ)
if fis an abstract dynamic/external function name:
[[ f(t1,...,t
n)]]ζ=(fabs ,([[t1]] ζ,..., [[ tn]] ζ))
Table 8.1: Adapted Term Transformations
8.1, we denote these abstract functional terms as fabs(t1,...,t
n). They cannot be
unfolded further and the simplification terminates.
Any dynamic or external function turns into a locational term.Locationalterms
can be simple, i.e., concrete locations loc, abstract functional terms locabs , or cross-
terms f(t1,...,t
n). External cross-terms can be fully explored since their range is
finite and thus can be enumerated.
Locational terms that are abstract functions (and not cross-terms) are mapped
into simple variables by merging function symbol and parameter symbols into one
new variable name. This is indicated through the pair (fabs ,(t1,...,t
n)). In con-
trast, any static functional term, and also any cross-term, is kept as a function
application: f(t1,...,t
n) (c.f., the notation in Table 8.1).
The term simplification [[.]] ζ(shown in Table 8.1) works inductively over ar-
bitrary function application f(t1,...,t
n). We distinguish between terms whose
parameters are all concrete values, terms whose parameters are concrete but have
125
Chapter 8 The MDG-Package
to be unfolded further, and terms that have some parameters of abstract sort:
1. If all parameters are (unfolded to) values, we distinguish between
- static functions that are concrete; these have to be evaluated by means
of applying the function interpretation fA(which is the same in any state
A) to the parameter values;
- dynamic or external functions that are concrete; these turn into a loca-
tion loc by means of merging function symbol and parameter symbols;
any location loc is thus equivalent to a simple state variable;
- static functions of abstract sort; these are left as uninterpreted func-
tions fabs which are not applied; they are denoted as functional terms
fabs (a1,...a
n).
- dynamic or external functions of abstract sort; we denote these terms as
locabs , a locational term that can change its value, and proceed similar
to concrete locations: we merge the function symbol and the parameter
symbols and get an abstract state variable.
2. If all parameters are of concrete sort but some of them are non-values, i.e.,
locations loc or other function applications f0(¯
t0) that have to be unfolded
further, we apply the unfolding function to the parameters first.
3. If some parameters are abstract terms tabs , i.e., abstract variables vabs or
abstract functions fabs(t1,...,t
n), we simplify the parameters by [[.]] ζfirst;
two cases may occur:
- the function is a cross-operator or an abstract static function; in this
case we keep the function;
- the function is an abstract dynamic/external function; we merge the
function symbol and the parameter symbols into one abstract variable.
Adapted Term Unfolding (cont.)
quantified terms over finite ranges
{a∈SA
i|B|=g(a)}where SA
iis a concrete sort:
[[((∃v:g(v)) s(v)) ]]ζ=[[s(v)]]ζ[v7→a1]∨...∨[[ s(v)]]ζ[v7→an]
[[((∀v:g(v)) s(v)) ]]ζ=[[s(v)]]ζ[v7→a1]∧...∧[[ s(v)]]ζ[v7→an]
quantified terms over abstract ranges
{a∈SA
i|B|=g(a)}where SA
iis an abstract sort:
[[((∀v:g(v)) s(v)) ]]ζ=[[s(v)]]ζ
([[((∃v:g(v)) s(v)) ]]ζis not defined; see remark below )
Table 8.2: Adapted Term Transformation of first-order Terms
First-order terms of the form (∃v:g(v)) s(v)or(∀v:g(v)) s(v) are simplified
as in the original transformation as long as their range is a concrete and finite set
{a∈SA
i|B|=g(a)}(see Definition (2.10)). If the range of a first-order term
turns into an abstract range by means of applying abstraction to the domain SA
i
126
The Transformation of ASM into MDG Section 8.4
then the range is not enumeratable any more. The simplification keeps the head
variable vas an abstract variable and treats the body s(v) as a cross-term. This
is shown in Table 8.2 by applying [[.]] ζto the body. For abstract head variables v,
[[ s(v)]]ζimplicitly models universal quantification over every a∈SA
i.Existential
quantification over an abstract variable is logically not expressible.
Note that uninterpreted, abstract functional terms fabs (t1,...t
n), where fabs is
an abstract static function and tiis a value or another abstract term, or f(t1,...t
n)
where fis a cross-term operator, are not mapped into a state variable name. In
contrast to the SMV approach, these functional terms may appear as labels in the
MDG structure. It is easy to see that abstraction saves alot of unfolding effort. The
resulting set of guarded updates is much smaller.
Rule Simplification
[[ skip ]] ζ=skip
[[ f(t):=t]] ζ=if true then [[ f(t)]]ζ:= [[t]] ζ
[[ block R1... R
nendblock]] ζ=[[R1]] ζ... [[ Rn]] ζ
[[ if gthen R1else R2]] ζ=if [[ g]] ζthen [[ R1]] ζ
if ¬[[ g]] ζthen [[ R2]] ζ
Table 8.3: Rule Simplifications
Table 8.3 summarises the rule simplification that applies the simplification func-
tion [[.]] ζ(c.f., Table 8.1) to the terms in the rules. This rule simplification is not
changed. We recall the definition here for the readers’ convenience.
Adapted rule unfolding. Table 8.4 defines the extended rule unfolding. In this
rule unfolding, simple update rules are left unchanged. More complex rules are
unfolded according to the evaluation of concrete locations that can be found in
the rule. For every possible evaluation aiwe introduce an instantiation of the rule
R[loc/ai] that is guarded by the equation (loc =ai), where loc is the first concrete
location occurring in the rule R. The substitution R[loc/ai] formalises that every
occurrence of loc is substituted by the value ai.Notethatabstract locations are
not unfolded; they are left uninterpreted.
Also, all locations that appear as a left-hand side (LHS) of an update or that are
parameters of the primary operators (e.g., equality, conjunction, disjunction, and
negation) are excluded from the unfolding procedure. This is due to optimisation
issues and already discussed in Section 5.2.1 on page 75.6
ASM-IL+representation. As a result of the adapted term simplification and
rule unfolding we get a list of pairs over locations and their guarded updates, which
is the ASM-IL+representation for the ASM model. In contrast to ASM-IL repre-
sentations of an ASM model, these pairs may contain abstract variables and cross-
terms as LHSs and RHSs, as well as abstract functions as RHSs of equations or
updates. To summarise the result of the adapted transformation algorithm, we give
the following definition.
6Note that in the MDG approach, we do not consider arithmetic operations as being primary.
127
Chapter 8 The MDG-Package
Adapted Rule Unfolding
If R=loc1:= a1... locn:= an:
E(R)=R
Otherwise:
E(R)=
if loc =a1then E([[R[loc/a1]]]ζ)
...
if loc =anthen E([[R[loc/an]]]ζ)
where
loc is the first location of concrete sort occurring in Rbut not as an
LHS of an update rule and not as a parameter of a primary operation;
{a1,...,a
n}is the range of location loc.
Table 8.4: Unfolding of concrete Locations in a Rule
Definition 8.23: Location-update pair
Alocation-update pair is a tuple of the following form:
(loc termi,[(guardi1,upd termi1),(guardi2,upd termi2),...])
A locational term loc termican be either a concrete location loc,an
abstract location locabs or a dynamic/external cross-term f(¯
t). Any
concrete parameter is unfolded and the abstract parameters are kept.
Any guard guardimay consist of conjunction, disjunction and equa-
tion as primary (not simplified) operations, where operands can be (un-
primed) locational terms, variables and abstract functions (these only
as a RHS of an equation).
The right-hand side (RHS) of an update upd termij can be a concrete
value a,alocationloc, an abstract functional term fabs (¯
t), or a cross-
term f(¯
t).
We call a pair (guardij ,upd termij) in a location-update pair a guarded-update
pair.
Limitations of the adapted term simplification
We identify two cases in which the adapted term simplification does not provide
proper results and thus is not applicable:
1. Any dynamic or external abstract function is mapped into an abstract state
variable. For any concrete parameter (that can be unfolded) we create sev-
eral instances of this state variable. However, abstract parameters are not
unfolded; instead of multiple instances we get only one state variable. For
example, assume that in the concrete ASM we have a sort A={a, b, c}and
a dynamic function f:A→B.Thelocationf(x) is simplified into three
state variables fa,f b,andf c. Abstracting this model we may change the
sorts Aand Binto abstract sorts. The same location f(x) is now simplified
into one variable fx. The resulting abstract ASM-IL+model is not a correct
abstraction of the concrete model. Note that the same problem does not occur
for cross-terms: any function g:A→C,whereCis not an abstract sort, is
kept as a function application rather than being mapped into a state variable.
128
The Transformation of ASM into MDG Section 8.4
2. Existentially quantified first-order terms (∃v:g(v)) s(v)wherethesortof
variable vturns into an abstract sort cannot be simplified properly. The
existence of a witness (necessary to evaluate existential quantification) is not
decidable since an abstract sort has no concrete (interpreted) entities.
A similar problem does not occur for universally quantified terms.
As a consequence of these limitations, we get guidance as to where abstraction
should not be applied in our approach: Any sort that is used as a domain (or part
of a cross-product of domains) of an n-ary dynamic or external function should
not be abstracted. For example, we may not abstract the set of agents in a multi-
agent ASM since a variable Self , ranging over agents, is used as parameter for any
function that is local to an agent. Also ranges of head variables in first-order terms
should be left enumeratable. These restrictions, however, appear reasonable.
Correctness
Since the adapted transformation algorithm is identical to the original transforma-
tion algorithm for terms without abstract sorts, its correctness is based on the proof
in Section 5.2. In the case of terms with abstract sorts, the adapted transformation
algorithm itself defines the semantics of these terms and therefore no correctness
proof is required.
A set of location-update pairs represents an abstract transition system, which
can be treated by a tool that is based on MDGs. In the next subsection, we show
that each location-update pair represents a directed formula (DF) in terms of the
MDG approach.
8.4.2 ASM-IL+Models as Directed Formulas
When we apply the simplification and unfolding algorithms to ASM models with
abstract sorts and functions, we get an ASM-IL+representation: the location-
update pairs. If we want to map a set of location-update pairs into MDGs, we
have to justify that the well-formedness conditions of MDGs are satisfied. In this
subsection, we show that our transformation provides directed formulas (DFs) that
can be canonically represented by well-formed MDGs (we follow the description of
DFs and MDGs in Section 4.2 on page 55).
Concretely reduced terms. Concretely reduced DFs can be represented by
well-formed MDGs. All concrete terms on the RHS of an update or equation in
such formulas are individual constants. As introduced in the last section, the sim-
plification function [[.]] ζunfolds all concrete terms that appear in ASM rules. This
way, all terms in location-update pairs are already concretely reduced in the sense
of the well-formedness conditions of MDGs (c.f., Section 4.2 on page 55), i.e., all
concrete functions and variables are mapped into their values.
Partitioned transition relation. In model checking approaches that are based
on decision diagrams (e.g., BDDs), the transition relation of a transition system that
is to be checked should be partitioned and represented by smaller graphs rather than
represented and treated as one large graph. The notion of a partitioned transition
relation is introduced in [BCMD90] and [BCL91] (see also [BCL+94]). For graph-
based approaches, partitioning helps prevent the (single) representing graph growing
too big. Instead of working with one graph for representing the whole transition
relation, the algorithms work on a set of smaller graphs, each representing a part of
129
Chapter 8 The MDG-Package
the transition relation only. This technique is adapted for the MDG approach as well
(see [ZSC+95]). All algorithms (e.g., relational product, pruning by subsumption,
etc.) expect lists of MDGs as input to operate on.
Since in ASM-IL+every location has an attached list of guarded-update pairs,
this representation naturally provides a partitioning of the overall transition rela-
tion. Moreover, our partitioning naturally yields MDGs with disjoint sets of primary
abstract variables (see below).
Correctness of the mapping
The correctness of mapping location-updates pairs into MDGs is based on the follow-
ing lemma (recall that MDGs are a canonical representation for directed formulas).
Lemma 8.24:
Each location-update pair (loc termi,[(guardi1,upd termi1),...]) repre-
sents a directed formula of many-sorted first-order logic.
Proof: We can prove Lemma 8.24 by relating the well-formedness conditions that
are given for DFs (see Section 4.2) to the location-update pairs that may occur in
an ASM-IL+representation. As introduced in [CCL+97], a directed formula is a
formula in disjunctive normal form (DNF) such that each disjunct is a conjunct of
equations. A similar formula is given by our ASM-IL+pairs:
(loc termi,[(guardi1,upd termi1),...]) ⇔
Wj(loc term0
i=upd termij ∧guardij )
∨loc term0
i=loc termi∧Vj¬guardij
(8.2)
where loc term0
idenotes the locational term loc termiin the next state. The first
part of the disjunction conjoins all guards and corresponding updates. The second
part specifies the “else-case”, i.e., if none of the guards are true then the location
should keep its old value. According to the adapted transformation algorithm that
is introduced in the last subsection, this DNF may contain the following:
•loc term0
iis
–a location of concrete sort loc =(f,(a1,...,a
n)) which we identify with
a state variable: any tuple of the form (f,(a1,a
2...,a
n)) will be merged
into a state variable identifier fa1a2... an;
–a locational term of abstract sort locabs =(fabs ,(t1,...,t
n)), where
tican be a value a, an abstract variable vabs or a concrete/abstract
locational term (h, (t0
1,...,t
0
m)); function symbol and parameter symbols
are merged into one state variable name similar to concrete locations;
–or a cross-term g(t1,...,t
n) which is treated as a functional term rather
than a variable; the cross-operator and the parameters are not merged
into one name; each parameter tican be a value a, an abstract variable
vabs or a concrete/abstract locational term (h, (t0
1,...,t
0
m));
130
The Transformation of ASM into MDG Section 8.4
•upd termiis
–avaluea, i.e., an individual constant of concrete sort
–a concrete or abstract (unprimed) location loc term (this includes con-
cretely reduced cross-terms);
–an abstract variable vabs
–atermg(t1,...,t
n) of abstract sort containing no (primed) next state
variables.
•guardiis a boolean expression over equations that do not contain primed
locational terms loc term0
i. Their LHS and RHS can be a concrete location
or value, or a cross-term. Any equation with an abstract variable or function,
e.g., a=b, is transformed into an equation involving a new cross-term, e.g.,
isEq(a, b)=true (for more details see Section 8.3.2 on page 120).
•The only abstract locational term that may appear as an LHS of an equation
is loc term0
i. At the same time this abstract location appears in every disjunct
of the DNF in (8.2).
•Any conjunct of equations with the same LHS is simplified during the trans-
formation; equations appear only among the guards in location-update pairs
since the only other LHS is the primed locational term (which does not occur
in the guards); according to the rule simplification given in Table 8.3 every
guard is simplified by [[ .]] ζ. As a consequence, all remaining LHSs in a disjunct
are pairwise distinct.
Given this, any location-update pair is a DF of type U→Vaccording to the
definition in Section 4.2. The set of “independent” variables Uis the set of unprimed
locational terms Loc of concrete or abstract sort, including the cross-operators that
are dynamic. These occur in the guards and thus characterise the current state in
which the update can be fired. Also, the set of abstract variables Vabs belongs to
the set of independent variables U. Abstract variables may occur as not-unfolded
parameters in (universally) quantified terms. That is U=Loc ∪Vabs .
The set of “dependent” variables Vis the set of primed locational terms which
is a singleton for each location-update pair: Loc0={loc term0
i}. It defines the
transitions to possible next states if any of the updates fire. Thus, every location-
update pair is a DF of type (Loc ∪Vabs )→Loc0.
The above has shown that location-update pairs are DFs. Each of these DFs has
at most one primary abstract variable: loc term0
i. As a consequence each location-
update pair can be represented as an MDG. These MDGs have pairwise disjoint sets
of primary abstract variables. This property is a necessary precondition for applying
the algorithms for computing the relational product or the conjunction (see Section
4.2). In the next section, we introduce our algorithm that interfaces ASM-IL+with
the MDG-Package by means of generating MDGs from the location-update pairs.
131
Chapter 8 The MDG-Package
8.4.3 Transformation of ASM-IL+into MDGs
In the second step of our transformation, an algorithm maps an ASM-IL+model
into a set of MDGs (c.f., Figure 5.3 on page 68). An ASM-IL+model is given
as a list of location-update pairs which describe the set of transition rules of the
ASM model. Each pair describes the possible updates of one location. It will be
transformed into an MDG. In order to do this, we have to treat the updates, the
guards of the updates, and the else cases, which specify that the location is not
changed if none of the guards are satisfied. In order to fully represent an ASM
model, we also have to specify the domains of the locations and the initial state of
the ASM. Moreover, a variable ordering that satisfies the well-formedness conditions
should be suggested. This is described in this section.
Transforming updates of one location. Representing a location-update pair7
(loci,[(guardi1,vali1),...]) as an MDG is straightforward if we consider the equiv-
alence (8.2). The next state variable loc0
ilabels the root node of the graph. Each
edge starting at the root is labelled with one of the specified values in the next state
valij and leads to the subgraph Gij that represents the corresponding guard of the
update guardij. Figure 8.6 sketches a graph for a location-update pair.
loc
0
i
val
i
1
val
i
2
val
i
3
loc
i
G
i
1
G
i
2
G
i
3
G
el se
Figure 8.6: Location-update pair represented as MDG
Transforming the else-case. Figure 8.6 shows also that one edge of the MDG
is labelled by the current value of the location lociand leads to a graph Gelse .This
branch specifies the else-case of the location-update pair: If none of the guards
guardij are satisfied, and therefore none of the updates can fire, the location should
keep its value in the next state. For model checking, the semantics of the else-case
has to be specified explicitly. Otherwise, the behaviour in this case is arbitrarily
and the checker investigates every possible case.
For generating a branch that represents this else-case behaviour, we need to
keep in mind that an edge cannot be labelled with a concrete variable. If loci
is of abstract sort, then we may simply use the abstract state variable locias an
edge label. However, if lociis of concrete sort, then it has to be substituted by
its current value valloci. In this case, we have to generate a graph that comprises
branches for all possible evaluations for the state variable loci. Thus, each branch
represents the formula loc0i=vali∧loci=vali, which obviously specifies that the
location keeps its value. Figure 8.7 depicts an MDG that represents the else-case
for a concrete location that ranges over three values, {val1,val2,val3}. This (sub-)
graph is disjoined with the MDG that represents the location-update pair (without
else-case).
7For the readers’ convenience we denote locational terms with loc and value terms as val.
132
The Transformation of ASM into MDG Section 8.4
loc
0
i
val
i
1
val
i
2
val
i
3
val
i
1
val
i
2
val
i
3
loc
i
loc
i
loc
i
True
Figure 8.7: Representing the else-case for concrete locations
Transforming a guard. For generating the MDG Gij that represents a guard, we
use four basic functions (and,or,negation,andequality) as basic boolean operators
that may appear in the guard (referred to as primary operators in the last section).
Every other boolean operator can be mapped to these basic predicates.
•and(opd1,opd2) is transformed into the conjunct of opd1and opd2, assuming
that both operands are given as MDGs.
•or(opd1,opd2) is transformed into the disjunct of opd1and opd2,ifboth
operands are given as MDGs.
•not(opd) is transformed into the negation of opd, if the operand is given as
an MDG that does not contain node labels of abstract sort.
•eq(lhs,rhs) assembles a new MDG. Its root is labelled by lhs, and it has a
single edge labelled with rhs which leads to the leaf True.
Except for equations, the boolean operations take MDGs as operands. Thus, we
recursively call the guard transformation function for the operands. The base of
this recursion is the equality operator which operates on simple terms and constants
and yields a simple graph.
Note that in most cases, the parameters of eq cannot be complex terms. Any
parameter tiof concrete sort will be simplified into a simple term [[ti]] ζduring
the first step of the transformation that is introduced in the last section. These
simple terms can be treated as labels. If one parameter is of abstract sort, the
equation is mapped into a cross-term isEq(lhs,rhs) and does not cause problems
either (cross-terms can be used as labels as well).
The only terms that are not simplified by [[.]] ζare the primary operators for
equality, conjunction and disjunction. If the operands of an equation are boolean ex-
pressions with non-simplified operators, we have to replace the equation eq (lhs,rhs)
with the expression (lhs ∧rhs)∨(¬lhs ∧¬rhs) which is logically equivalent8.
Basic functions for conjoining and disjoining MDGs are given in the MDG-
Package (see [Zho96]). Additionally, we implemented the algorithm for negation.
This negation of an MDG is possible if no abstract variable appears as an lhs in
any involved equations. As argued above, this is the case for guards guardij .
8Since guard expressions do not contain abstract variables on a LHS of an equation, negation
is applicable.
133
Chapter 8 The MDG-Package
Negation. Our algorithm for negation of an MDG Massumes that the root is
not labelled by a variable of abstract sort (otherwise an error will be output). It
works inductively on the structure of MDGs:
•if M=true then not(true)=false
•if M=Wj∈J(loc =valj∧Gj)
where dom(loc)={vali|i∈I}, and the index set I, and the in-
dex subsets Jand ¯
Jof occurring and non-occurring indices are such that
J⊆I, ¯
J⊆I,J∩¯
J=∅,andJ∪¯
J=Ithen the negation of Mcan be reduced
to
not(M)= Wk∈¯
J(loc =valk∧true)∨Wj∈J(loc =valj∧not(Gj)).
Figure 8.8 shows the sketch of the corresponding graphs for I=
{val1,val2,val3}.
loc
0
val
1
val
2
val
3
G
1
G
2
loc
0
val
1
val
2
not
(
G
1
)
not
(
G
2
)
True
neg
Figure 8.8: Computing negation
Initial state, domains and variable ordering. The initial state of an ASM
model is defined together with the declaration of functions and their domains. Every
dynamic or external function may have a defined initial value. For our transforma-
tion we gather all initialisation information and put it into a formula that determines
the set of initial states: init state =Vi(loci=init vali). This conjunction need not
be exhaustive since initialisation for some functions may be omitted. This formula
is transformed into a simple MDG that consists of a single branch comprising all
conjuncts.
The domains of an ASM model are defined as enumerations or by set compre-
hensions in the case of concrete sorts. Set comprehensions are unfolded by our
transformation algorithm into enumerated sorts. When transforming the enumera-
tion into an enumerated set for MDGs, we have to order the elements alphabetically.
Otherwise, the internal substitution function will not work properly. For abstract
sorts, we introduce a keyword that indicates a sort as being abstract.
Each location and each cross-term operator has an attached number in order to
define a variable ordering. This ordering determines the shape of the corresponding
MDG later on and heavily influences the graph size. We do not have a proper
heuristic for a good ordering implemented yet9. Our implementation so far orders
the locations and cross-term operators such that cross-term operators have a greater
number than locations (in most cases the former depend on some of the latter and
thus must have a greater ordering number). To support the user, we automatically
generate a function which prints the list of locations and cross-term operators that
are contributing to the current model. The order of this variable list can changed
manually. Another function takes the newly ordered variable list as its input and
adds a proper order-relation to the database that is used by the MDG algorithms.
Given this interface from ASM-IL+to the MDG-Package, and with respect to
9There is some ongoing work at the University of Montreal investigating heuristics for a good
variable ordering for MDGs. The results are not published yet.
134
The Transformation of ASM into MDG Section 8.4
certain limitations for applying abstraction (as discussed in the last section), we are
able to represent ASM models with abstract sorts by means of MDGs. This MDG
representation of our model is thus treatable by MDG-based checking algorithms.
The work that is introduced in this chapter provides an interface from the ASM
Workbench to the MDG-Package. An implementation of the algorithms is available.
The code is given in standard ML in order to ease the interface to the ASM Work-
bench which is also implemented in ML. The program outputs a set of Prolog rules
for generating MDGs that represent the ASM model. This includes apart from the
initial state and the transition rules, the definition of sorts, variables and functions.
These Prolog rules can easily be used as input for checking algorithms based on the
MDG-Package that is also encoded in Prolog.
Our interface is tested only by using our own re-implementation of the reacha-
bility algorithm based on the MDG library of Prolog functions which is suggested in
[CZS+97]. A complete model checking tool for MDGs is not available yet. However,
we hope to get inspirations from the MDG-HDL model checker that is introduced
in [Xu99, XCS+98] for our future development (see the discussion in Section 9.2).
135
Chapter 8 The MDG-Package
136
Chapter 9
Conclusion
To summarise this thesis, we recall our initial intention: We aimed to provide tool
support for analysing Abstract State Machines by means of model checking.
For the sake of a self-contained thesis, we recalled in the beginning the foundation
of the formalism and the techniques that are used throughout this thesis: The
syntax and semantics of Abstract State Machines (ASM) was given in Chapter 2.
As a tool framework for editing, type-checking and simulating a typed version of
ASM, called ASM-SL, we used the ASM Workbench. A brief description of this
workbench completed this chapter. Chapter 3 gave an overview of model checking.
In particular, we focused on symbolic model checking for the branching time logic
CTL and the linear time logic LTL since these approaches appeared useful for the
analysis of ASM. In Chapter 4, we described the data structure of decision diagrams
that is the backbone of symbolic model checking.
Chapter 5, the centre of the thesis, illustrated how we think model checking can
be useful for the development of complex systems. Basically, we did not aim to
provide full verification support – model checking is much too restricted for such an
ambitious enterprise – but support for debugging that is fully automatic and that
nicely fits into a cyclic development process: We automatically transform the ASM
model into the model checker language, specify the requirements to be checked, run
the model checker, and simulate the counterexample that is output by the checking
tool in case of an error. The simulation (or mere inspection) helps to get a better
understanding of the behaviour of the ASM model and facilitates the correction of
errors.
The second part of Chapter 5 described the interface between ASM and a check-
ing tool. Facilitating ASM with model checking involves a language transformation:
ASM have to be mapped into the input language of the model checker that is used.
Since a variety of model checkers are available, of which each has its own strength
for a particular application, it seems reasonable to provide more than one interface
to one particular tool. Therefore, we intended to develop a general interface that
can be used for many tools. Based on this design decision, we introduced an in-
termediate language, called ASM-IL, and split the transformation into two steps:
In the first step, the transformation maps ASM-SL into ASM-IL. In a second step,
ASM-IL is mapped to a particular model checker language. Since ASM-IL is a very
simple formalism for describing transition systems, it can be easily transformed into
many low-level tool languages. In Section 5.2, we introduced the technical details
of the transformation from ASM into ASM-IL. We completed this section with a
correctness proof based on the ASM semantics as given in Chapter 2.
Based on our general intermediate language, we provided interfaces to two
model checking frameworks: We interfaced the ASM Workbench with the SMV
tool ([McM93]) and with the MDG-Package ([CZS+97, CCL+97]).
137
Chapter 9 Conclusion
Chapter 6 presented the interface to the SMV tool. We gave an overview of the
tool and its input language as far as it is relevant for our approach. In Section 6.2, we
described the transformation from ASM-IL into the SMV language. This interface
is implemented in standard ML. It automatically transforms ASM-SL models into
SMV code. In Chapter 7, we reported our experiences of using this interface for
analysing two case studies: the FLASH cache coherence protocol ([KOH+94, Hei95])
and the Production Cell ([LL95]). While the former case study nicely showed the
benefit of model checking, the latter one displayed its limitations.
The ASM model of the Production Cell that is investigated in this work is
fairly simple because the system is modelled on a very abstract level: all domains
of the model are finite. However, due to the fact that the Production Cell is an
embedded system that strongly depends on the environment’s behaviour, the model
becomes much more complex if it is analysed with respect to its environment. Since
model checking is an exhaustive search in the state space, the tool checks every
possible behaviour. This includes also the possible behaviour of the sensor variables
that define the environment. We needed to restrict the behaviour of the sensor
variables in order to treat the model by the SMV tool, i.e., we added a model
of the assumptions made on the environment. Choosing an environment model
that is too restrictive, however, entails the danger of missing possible errors. This
experience, it is discussed in detail in Section 7.2, nicely motivated support towards
two directions: Firstly, modelling assumptions on the environment can be nicely
done in a temporal logic. We need to provide a model checker that allows the user
to add temporal logic formulas to the system model. As described in Section 3.4,
this can be done in the framework of LTL model checking which is based on tableau
construction. Secondly, we need a means to reduce complexity. Abstraction is one
technique for extending the limits of model checking towards the treatment of more
complex models.
The last chapter, Chapter 8, treated both issues. It described the interface
from ASM to multiway decision graphs (MDGs). MDGs, as described in Section
4.2, support abstract sorts and functions. Moreover, model checking algorithms
for checking a subset of first order ACTL* (the universal fragment of CTL*) are
already provided in the literature (see [Xu99, XCS+98]). These algorithms involve
a tableau construction similar to the approach for LTL checking. For these reasons,
we developed an interface to the MDG framework. In Section 8.3, we explained how
the transformation allows the user to automatically generate abstract models once
the abstract sorts are distinguished. This support takes the burden of manually
re-modelling the system model from the user if the model is too complex and must
be abstracted. A transformation from ASM into MDGs was described in Section
8.4. Since MDGs provide a means for modelling abstract sorts, we had to extend
the first step of the transformation with a feature for treating abstract functions
that are left uninterpreted.
Our second interface from ASM to MDGs is implemented. However, an MDG
model checker for our needs is not yet developed. This is discussed as future work
in Section 9.2.
9.1 Related Work
We discuss the work that is related to ours from two different viewpoints: On one
hand, we discuss other approaches for model checking Abstract State Machines.
On the other hand, we reflect on other techniques for supporting abstraction. This
section is divided into two corresponding subsections.
138
Related Work Section 9.1
9.1.1 Model Checking Abstract State Machines
Extending tool environments for high-level specification languages with an interface
to a model checker is an upcoming topic. One can find approaches that are quite
similar to ours but work on a different language: [Day93] suggests a transformation
from Statecharts into SMV; in [LR98], controller specifications, modelled in the
language CSL, are transformed and model checked by SVE ([F+96]); the work that
is introduced in [MMP98] equips the multi-language environment Synchronie with
an interface to the VIS model checker, and so on.
Closer to our approach from the language point of view is the work by Spiel-
mann. In [Spi99], he investigates automatic verification of ASM with unbounded
input. This is done by representing an ASM model “symbolically” by means of
a logic for computation graphs (called CGL*). The resulting formula is combined
with a CTL*-like formula which specifies properties and checked by means of de-
ciding its finite validity. This approach addresses the problem of checking systems
with infinitely many inputs but it is only applicable to ASM with 0-ary dynamic
functions and input that is restricted to relations1. Spielmann proves that the
decision procedure is Pspace-complete and optimal. In his framework, the verifica-
tion of generalised nullary programs which have functions in their input (instead of
relations only) becomes undecidable.
From the theoretical point of view, this work provides very interesting results
that could help to support the analysis of embedded systems that involve unbounded
non-determinism. We hope for further development of this approach that extends
its limitations. The conclusion of [Spi99] already suggests the use of fragments of
the logic CGL* in order to provide decidability of the algorithms that can check
validity for a broader range of ASM models.
As a more practical approach, Plonka develops in his diploma thesis ([Plo00])
an interface from ASM to the model checker SVE ([F+96]). The transformation
schema that is used to map Abstract State Machines into the interchange format,
called RSM, is quite similar to the transformation that is introduced in this work.
This strengthens our claim that our interface language ASM-IL provides generality
and can be used for interfacing many tools. As far as we know, the transformation
algorithm is not yet implemented. The results of [Plo00], however, could be used to
build a third interface from ASM-IL to the model checker SVE. This model checker
implements the LTL model checking approach that is described in Section 3.4. It
allows the user to introduce temporal logic assumptions into the system model to
be checked. However, the tool does not provide support for abstraction.
9.1.2 Abstraction Techniques
Abstraction is sometimes referred to as the key methodology for combining deduc-
tive and algorithmic techniques. The basic idea behind abstraction is to reduce the
size of a possibly infinite model. When successful, abstraction provides an abstract
version of the concrete model which eases the verification task. Due to the limi-
tation of automatic approaches for supporting verification, e.g., model checkers or
validity checkers, a successful abstraction technique can be crucial to the success of
algorithmic verification.
Often in the literature, the process of abstracting is described in terms of sepa-
rating the control flow of a model from the data part and neglecting the latter. This
viewpoint is introduced in the context of hardware verification. The basic problem
is that this separation is not obvious whenever data influences the control flow.
1In contrast to ASM as described in Chapter 2, Spielmann allows relation as well as function
symbols in his signature.
139
Chapter 9 Conclusion
As a suitable solution for a certain application domain, Hojati, Dill and Brayton
introduce in [HDB97] an approach for checking integer-based circuit models. In
certain models, integer variables can be replaced by enumeratable variables. Thus,
the model turns into a finite instance and can be treated by a BDD-based model
checker. This technique, however, is not applicable for abstracting arbitrary data:
Instead of building a finite instance, a BDD-based reachability procedure checks
the first nsteps of the circuit behaviour against a given invariant. A full state
exploration, however, is not applicable.
Clarke, Grumberg and Long ([CGL92, Lon93]) introduce a technique for ab-
stracting data in a complex circuit design. The width of the data path is reduced
and thus the abstract model is much smaller. BDD-based model checking becomes
applicable. To apply this technique, an abstraction function αhas to be defined by
the designer. Moreover, the correctness of the abstract model with respect to the
original model is not always obvious. It has to be proven mechanically. Both tasks,
providing an αand proving correctness are quite complex and cannot be supported
by fully algorithmic tools.
Inthesamecontext,Sa¨ıdi, Graf, and Shankar ([GS97, SS99]) propose a frame-
work for supporting the computation of the abstract model and the abstract prop-
erty to be checked, once the abstraction function αis defined, and for proving
correctness of the abstract model by means of the theorem prover PVS ([ORS92]).
The theoretical foundation is introduced in [LGS+95] as a property preserving ab-
straction technique.
Hungar, Grumberg and Damm in [HGD95] introduce the notion of “truly sym-
bolic” representation in contrast to symbolic representation introduced in [McM93].
This approach separates the control part of the system from its data part and refines
the resulting model into an intermediate description that contains sufficient infor-
mation about the property to be checked. The enrichment of the control flow model
introduces additional proof obligations, so called verification conditions.Theseveri-
fication conditions can be generated automatically. The requirements to be checked
are modelled in first-order ACTL, the universal fragment of CTL2. Data values and
operations can be modelled in this logic by means of first-order predicates. If a
given requirement does not contain predicates on data, then BDD model checking
is applicable. Otherwise, all first-order predicates are substituted by true.Ifthe
model checking procedure reports a failure, this failure will be part of the control
flow and occurs in the concrete model as well. If no failure can be found, correct-
ness is not guaranteed in the original model since failure in the abstracted data
part cannot be detected. Therefore, the generated verification conditions have to
be proven. This is done by means of a theorem prover. In contrast to other ap-
proaches, no abstraction function has to be defined; only the control variables have
to be identified. However, the verification conditions have to be proven manually.
Moreover, this approach is restricted to circuits with terminating data loops and a
clear separation between data and control part.
Bharadwaj and Heitmeyer suggest in [BH99] algorithmic support for deriving
an abstract model from the requirements to be checked. They analyse the abstract
model (with respect to the abstracted requirements) by means of model checkers and
translate, if an error is detected, the counterexample back into the concrete model.
Their approach is derived from techniques that are used in practice when a model
is manually abstracted in an ad hoc way. (The common practice for abstracting
manually is also described in [WVF97].) They describe two methods for deriving
abstraction. The first method simply eliminates irrelevant variables, i.e., variable
that have no influence for the requirements to be checked. For example, in the
2That is, ACTL is a restricted sub-logic of CTL that does not comprise existential quantification
over paths denoted by the Eoperator.
140
Directions for Future Work Section 9.2
FLASH case study that is described in Section 7.1, the variable data has no influence
on the protocol and can be eliminated. The second method allows a monitored
variable3vto be removed if it does not occur in the requirement qbut influences
a variable v0that occurs in q. In the abstract model, v0is treated as a monitored
variable. In order to reduce the domain of monitored variable v0, a mapping is
introduced that partitions the original domain of vinto equivalence classes. The
resulting abstract model is thus smaller.
The second method is partly comparable with the techniques we use when trans-
forming ASM into MDG (see Section 8.4.1). However, it is more restricted since it
is applicable only if v0is the only variable that depends on that eliminated. Further-
more, a mapping has to be defined that yields appropriate equivalence classes. A
similar partitioning is given automatically by our transformation when introducing
new cross-terms.
Bharadwaj and Heitmeyer show that their abstraction techniques are sound and
complete. In contrast to that, our approach is sound but not complete. Complete-
ness assures that every counterexample that can be found in the abstract model is
also a counterexample in the concrete model. That is, wrong counterexamples (as
discussed in Section 8.3) do not occur.
In contrast to problem reduction by means of computing an abstract model,
other approaches suggest tools that are based on different structures for representing
a system. These approaches are more closely related to the MDG approach that
is used in this thesis. Uninterpreted functions and predicates are introduced into
various frameworks.
Burch and Dill ([BD94]) investigated the pipelined DLX architecture by means
of modelling data values and operations with functions that are left uninterpreted
during the checking process. Similar to the MDG approach, this technique allows
systems that can be arbitrarily large in their data parts to be treated. In contrast
to the MDG approach, however, they support verification by means of validity
checking procedures. As a consequence, no temporal properties, such as liveness,
can be checked. This is possible with the model checking algorithm for MDGs
introduced in [Xu99, XCS+98].
In [CN94], Cyrluk and Narendran introduce a new logic, called ground tempo-
ral logic (GTL). This logic also allows uninterpreted function symbols. They show
that a decidable fragment of GTL can be treated by an automatic validity checker
(based on PVS). The thesis of Xu ([Xu99]) that introduces the logic LMDG and
the corresponding model checking algorithm based on MDGs shows that the decid-
able fragment of GTL is a subset of LMDG. Moreover, the MDG model checking
approach goes beyond validity checking.
9.2 Directions for Future Work
As one future direction, we intend to complete the implementation of the interface
from the ASM Workbench to the SMV tool. Two tasks are left to do:
1. The re-transformation from the counterexample that is output by the SMV
tool into the simulator of the workbench has to be implemented. In principle,
this interface is easily realised as discussed in Section 6.
2. Modelling of the requirements that are to be checked should be supported.
For the use of SMV, the requirements must be specified in the temporal logic
CTL. The user interface of the ASM Workbench should be extended to allow
support for the user to generate these CTL specifications. For many safety
3These monitored variables are comparable with external functions in ASM.
141
Chapter 9 Conclusion
and liveness properties, a schema for the corresponding CTL formula might
be automatically suggested by the tool.
As another future direction, we plan the further development of a model checker
based on MDGs that is tailored for our needs. For this development, we can use
results that are given in the literature. [Xu99, XCS+98] introduces a model checker
based on MDGs. In this work, Xu, Cerny, Song and Corella invented an extension
for CTL*, called Abstract CTL*. This logic allows the use of abstract sorts and
first-order quantification. In her thesis ([Xu99]), Xu introduces a logical language
called LMDG which is a subset of Abstract CTL*. This language is restricted to
universal path quantification and a limited nesting of temporal operators. This
restriction allows the development of model checking algorithms.
Similar to the approach described in Section 3.4, model checking of LMDG is
based on a tableau construction of the formula that is to be checked. In contrast to
the LTL model checking approach in Section 3.4, the “tableaus” that are constructed
in [Xu99] are not given as simple transition systems but as circuit models specified
in MDG-HDL. These circuits derived from formulas are conjoined with the circuit
specification to be checked which is also given in MDG-HDL. The composed circuit
is analysed by the MDG-HDL model checker.
In our case, when model checking ASM, we need to develop a tableau con-
struction that yields a tableau as a simple transition system rather than a piece
of hardware description. This development of a model checker based on MDGs
and tableau construction for simple transition systems is planned as future work in
cooperation with Concordia University in Montreal.
142
Appendix A
Appendix
143
Chapter A Appendix
A.1 Fixpoint Characterisation
Lemma A.1. f(Z):=ϕ∧EX Zis monotonic, i.e., for sets of states Siand Sj
with Si⊆Sjit follows that f(Si)⊆f(Sj).
Proof: Consider s∈f(Si), using the definition of fwe get s|=ϕand there is
some other state s0with (s, s0)∈Rthat is also an element of Si,sos0∈Si.Since
Si⊆Sjwe have s0∈Sjand so sis in the set characterised by ϕ∧EX Sj,thatis
s∈f(Sj).
Lemma A.2. EG ϕis a fixpoint for the predicate transformer f(Z):=ϕ∧EX Z.
Proof: Assume s0|=EG ϕ. By definition of |=andtheEG operator there must
be a path s0,s
1,s
2,... in structure Msuch that for all k≥0, sk|=ϕ. It follows
that s0|=ϕas well as s1|=EG ϕ. This implies s0|=ϕand s0|=EX EG ϕ,
thus EG ϕ⊆ϕ∧EX EG ϕ. On the other hand, with s0|=ϕ∧EX EG ϕwe get
s0|=EG ϕ,andsoEG ϕ⊇ϕ∧EX EG ϕ. We conclude that EG ϕ=ϕ∧EX EG ϕ.
Proving that EG ϕis the greatest fixpoint we need an additional lemma for the
predicate transformer f(Z)=ϕ∧EX Z.
Lemma A.3. Let f(Z)=ϕ∧EX Zand f∞(S)be the limit of the sequence S⊇
f(S)⊇f2(S)⊇... (i.e., the value after infinitely many iterations of applying f).
Then for every s∈S,s∈f∞(S)implies s|=ϕ,andthereisastates0∈Swith
(s, s0)∈Rand s0∈f∞(S).
Proof: Because of Lemma A.1 we know that fhas a fixpoint. This is given by the
limit f∞,sothatf∞(S)=f(f∞(S)). By definition of fwe get that s|=ϕ,and
there is a state s0∈Swith (s, s0)∈Rand s0∈f∞(S).
Lemma A.4. EG ϕis the greatest fixpoint for predicate transformer f(Z):=ϕ∧
EX Z, i.e., EG ϕ=fpmax(Z, ϕ ∧EX Z).
Proof: Since we are dealing with a complete lattice and fif monotonic (following
Lemma A.1), fis ∩-continuous as well. It suffices to prove EG ϕ=Tifi(S)where
Sis the supremum of our lattice P(S).
We first show that EG ϕ⊆Tifi(S). By induction on iwe establish EG ϕ⊆
fi(S) for all i. Obviously, EG ϕ⊆S. For arbitrary n,letEG ϕ⊆fn(S). Since fis
monotonic it follows that f(EG ϕ)⊆fn+1(S). By Lemma A.2, f(EG ϕ)=EG ϕ,
and hence EG ϕ⊆fn+1(S).
To show EG ϕ⊇Tifi(S) we assume state s∈Tifi(S). This state is included
in all fi(S). Hence it is also included in the fixpoint f∞(S). With Lemma A.3, sis
the start of an infinite sequence of states in Min which each state is related to the
previous state by relation R. Furthermore, each of these states satisfies ϕ.Thus,
s|=EG ϕ.
The proof for the fixpoint characterisation of A(ϕUψ) follows the same steps.
We first show the monotonicity of the transformer, then proving that the A(ϕUψ)
is a fixpoint and for the last step it remains to show that it is the least fixpoint.
Lemma A.5. f(Z):=ψ∨(ϕ∧AX Z)is monotonic, i.e., for sets of states Siand
Sjwith Si⊆Sj,f(Si)⊆f(Sj)follows.
Proof: Assume Si⊆Sj.Ifs∈f(Si), then using the definition of f,s|=ψor
s|=ϕand for all state s0with (s, s0)∈R,s0|=A(ϕUψ), i.e., also s0∈Siand
because of the subset relation s0∈Sj.Thus,s|=ψ∨(ϕ∧AX Sj) as well, that is
s∈f(Sj).
144
Fixpoint Characterisation Section A.1
Lemma A.6. A (ϕUψ)is a fixpoint for the predicate transformer
f(Z):=ψ∨(ϕ∧AX Z).
Proof: We prove the lemma in two steps: A(ϕUψ)⊆ψ∨(ϕ∧AX (A(ϕUψ)))
and A(ϕUψ)⊇ψ∨(ϕ∧AX (A(ϕUψ))).
Assume s0|=A(ϕUψ). According to the semantics given in definition 3.16 it
follows that for all path s0,s
1,s
2,...there is a k≥0 with sk|=ψand for all jwith
0≤j<k,sj|=ϕ.Thus,s0|=ψor s0|=ϕand for all path s1,s
2,... (that is, all
paths starting at a successor of s0) there is a k≥1 with sk|=ψand for all jwith
1≤j<k,sj|=ϕ. In terms of CTL this means s0|=ψ∨(ϕ∧AX (A(ϕUψ))).
We get A(ϕUψ)⊆f(A(ϕUψ)).
For proving A(ϕUψ)⊇ψ∨(ϕ∧AX (A(ϕUψ))) we assume that s0|=
ψ∨(ϕ∧AX (A(ϕUψ))). This means that s0|=ψor s0|=ϕand for s1with
(s0,s
1)∈R(i.e., all next states) s1|=A(ϕUψ). This is equivalent with the
statement that s0|=ψor s0|=ϕand for all paths s0,s
1,s
2,... there is a k≥1,
sk|=ψand for all 1 ≤j<k,sj|=ϕ. Both cases can be conjoined: for all path
s0,s
1,s
2,... there is a k≥0, sk|=ψand for all 0 ≤j<k,sj|=ϕ,whichis
equivalent to s0|=A(ϕUψ).
Lemma A.7. A (ϕUψ)is the least fixpoint for predicate transformer
f(Z):=ψ∨(ϕ∧AX Z), i.e., A(ϕUψ)=fpmin(Z, ψ ∨(ϕ∧AX Z).
Proof: Since we are dealing with a complete lattice and fis monotonic (following
Lemma A.5), fis ∪-continuous as well. Following equation (3.4) it suffices to prove
A(ϕUψ)=Sifi(∅)where∅is the infimum of our lattice P(S).
It is easy to see that fi(∅)⊆A(ϕUψ) for all iwhen looking at the results of
iteratively applied f:
f0(∅)=∅
f1(∅)=ψ∨(ϕ∧AX ∅)=ψ
f2(∅)=ψ∨(ϕ∧AX (f1(∅)) = ψ∨(ϕ∧AX ψ)
f3(∅)=ψ∨(ϕ∧AX (f2(∅)) = ψ∨(ϕ∧AX (ψ∨(ϕ∧AX ψ)))
f4(∅)=ψ∨(ϕ∧AX (f3(∅)) = ψ∨(ϕ∧AX (ψ∨(ϕ∧AX (ψ∨(ϕ∧AX ψ))))
f5(∅)=...
We can see that the iterated application enlarges the length of the maximal prefix
of the paths satisfying ϕuntil ψis satisfied, which is given by the upper bound for
parameter kin the semantic definition. For A(ϕUψ), however, kis unbound.
Thus, fi(∅)⊆A(ϕUψ) for all i,andsoisSifi(∅)⊆A(ϕUψ).
A(ϕUψ)⊆Sifi(∅) can be proved by induction over parameter kin the
semantical definition. The induction basis s0|=A(ϕUψ)forak= 0 implies s0|=
ψso that s0∈f1(∅). As the induction hypothesis we assume that s0|=A(ϕUψ)
and 0 ≤k≤(n−1) implies that s0∈fn(∅). For the inductive step let kbe bound
to n:s0|=A(ϕUψ)andthereisakwith 0 ≤k≤nsuch that sk|=ψand
for all 0 ≤j<k,sj|=ϕ. Considering now s0|=ϕand all paths s1,s
2,... with
(s0,s
1)∈R(i.e., all paths starting at a successor of s0). These are the suffixes
of length (n−1) satisfying ϕuntil ψis satisfied. With the induction hypothesis
it follows that s1∈fn(∅). Since (s0,s
1)∈Rand s0|=A(ϕUψ) it follows that
s0|=ψ∨(ϕ∧AX (fn(∅)). Thus, s0∈f(fn(∅)) = fn+1(∅). We conclude that
A(ϕUψ)⊆fi(∅) for all i, and since fis ∪-continuous A(ϕUψ)⊆Sifi(∅).
145
Chapter A Appendix
A.2 FLASH Cache Coherence Protocol
A.2.1 The ASM-SL Code
(*------------------------------------------------------------------*)
freetype TYPE == { noMess, get, getx, inv, wb, rpl, fwdack, swb,
invack, nack, nackc, fwdget, fwdgetx, put,
putx, nackc2, put_swb, putx_fwdack }
freetype CCTYPE == { ccget, ccgetx, ccrpl, ccwb }
freetype AGENT == { agent :INT, none }
freetype LINE == { lines :INT }
typealias MESSAGE == AGENT * TYPE * AGENT * LINE
freetype PHASE == { ready, wait, invalidPhase }
freetype STATE == { exclusive, shared, invalid }
freetype LENGTH == { n :INT }
(*------------------------------------------ *)
static function max_agent == 2
static function max_line == 2
static function maxQ == 2
static function Agent == {agent(i)| i in {1..max_agent}} union {none}
static function Agent_without_none == {agent(i)| i in {1..max_agent}}
static function Line == { lines(i) | i in {1..max_line} }
static function QLength == { n(i) | i in {1..maxQ} }
(*-------------------------------------------*)
static function Type == { noMess, get, getx, inv, wb, rpl, fwdack,
swb, invack, nack, nackc, fwdget,
fwdgetx, put, putx, nackc2, put_swb,
putx_fwdack }
static function CCType == { ccget, ccgetx, ccrpl, ccwb }
static function ReqType == { noMess, get, getx, rpl, wb }
static function Home ==
MAP_TO_FUN { lines(1) -> agent(1), lines(4) -> agent(1),
lines(2) -> agent(1), lines(5) -> agent(2),
lines(3) -> agent(3), lines(6) -> agent(3) }
(*------------------------------------------*)
dynamic function MessInTr : LENGTH * AGENT -> TYPE
with MessInTr(i,a) in Type
initially MAP_TO_FUN {(i,a) -> noMess | (i,a) in
Union({ {(i,a) | i in QLength } | a in Agent\{none}}) }
146
FLASH Cache Coherence Protocol Section A.2
dynamic function SenderInTr : LENGTH * AGENT -> AGENT
with SenderInTr(i,a) in Agent \ { none }
initially MAP_TO_FUN { (i,a) -> agent(1) | (i,a) in
Union({ { (i,a) | i in QLength } | a in Agent \ { none }}) }
dynamic function SourceInTr : LENGTH * AGENT -> AGENT
with SourceInTr(i,a) in Agent \ { none }
initially MAP_TO_FUN { (i,a) -> agent(1) | (i,a) in
Union({ { (i,a) | i in QLength } | a in Agent \ { none }}) }
dynamic function LineInTr : LENGTH * AGENT -> LINE
with LineInTr(i,a) in Line
initially MAP_TO_FUN { (i,a) -> lines(1) | (i,a) in
Union({ { (i,a) | i in QLength } | a in Agent \ { none }}) }
(*------------------------------------------*)
dynamic function SenderInTrR : AGENT -> AGENT
with SenderInTrR(a) in Agent \ { none }
initially MAP_TO_FUN { a -> agent(2) | a in Agent \ { none } }
dynamic function SourceInTrR : AGENT -> AGENT
with SourceInTrR(a) in Agent \ { none }
initially MAP_TO_FUN { a -> agent(1) | a in Agent \ { none } }
dynamic function MessInTrR : AGENT -> TYPE
with MessInTrR(a) in ReqType
initially MAP_TO_FUN { a -> noMess | a in Agent \ { none } }
dynamic function LineInTrR : AGENT -> LINE
with LineInTrR(a) in Line
initially MAP_TO_FUN { a -> lines(1) | a in Agent \ { none } }
(*------------------------------------------*)
dynamic function InSender : AGENT -> AGENT
with InSender(a) in Agent \ { none }
initially MAP_TO_FUN { a -> agent(2) | a in Agent \ { none } }
dynamic function InSource : AGENT -> AGENT
with InSource(a) in Agent \ { none }
initially MAP_TO_FUN { a -> agent(2) | a in Agent \ { none } }
dynamic function InMess : AGENT -> TYPE
with InMess(a) in Type
initially MAP_TO_FUN { a -> noMess | a in Agent \ { none } }
dynamic function InLine : AGENT -> LINE
with InLine(a) in Line
initially MAP_TO_FUN { a -> lines(1) | a in Agent \ { none } }
(*------------------------------------------*)
147
Chapter A Appendix
dynamic function CurPhase :AGENT * LINE -> PHASE
initially MAP_TO_FUN
{ (a,l) -> ready | (a,l) in Union ({ { (a,l) |
a in Agent \ { none }}|linLine} )}
dynamic function CCState :AGENT * LINE -> STATE
initially MAP_TO_FUN { (a,l) -> invalid | (a,l) in
Union ({ { (a,l) | a in Agent \ { none }}|linLine} )}
dynamic relation Pending :LINE
initially SET_TO_REL {}
dynamic function Owner :LINE -> AGENT
with Owner (l) in Agent
initially MAP_TO_FUN { l -> none | l in Line }
dynamic relation Sharer :LINE * AGENT
initially SET_TO_REL {}
(*------------------------------------------*)
(*-- synchronization -----------------------*)
freetype MODE == { behave, sync }
dynamic function toggle : MODE
initially behave
(*------------------------------------------*)
external function Self :AGENT
with Self in Agent \ { none }
external function produce :AGENT -> (CCTYPE * LINE)
with produce(a) in
Union({{(cctype_, line_) | cctype_ in CCType } | line_ in Line})
(*-----------------------------------------------------------------*)
transition AppendToTransit (agent_, (sender_,mess_,source_,line_)) ==
if MessInTr(n(1),agent_)=noMess
then SenderInTr(n(1),agent_) := sender_
MessInTr(n(1),agent_) := mess_
SourceInTr(n(1),agent_):= source_
LineInTr(n(1),agent_) := line_
else do forall i in { 2..maxQ } (* the first empty Queue-entry *)
if MessInTr(n(i-1),agent_)!=noMess
and MessInTr(n(i),agent_)=noMess
then SenderInTr(n(i),agent_) := sender_
MessInTr(n(i),agent_) := mess_
SourceInTr(n(i),agent_):= source_
LineInTr(n(i),agent_) := line_
endif
148
FLASH Cache Coherence Protocol Section A.2
enddo
endif
transition AppendRequestToTransit (agent_,
(sender_,mess_,source_,line_)) ==
if MessInTrR (agent_)=noMess
then SenderInTrR(agent_) := sender_
MessInTrR (agent_) := mess_
SourceInTrR (agent_):= source_
LineInTrR (agent_) := line_
endif
(*-----------------------------------------------------------------*)
transition R_Requests ==
if MessInTrR(agent(1)) = noMess
then
case produce(Self) of
(ccget, l) :
if CurPhase(Self, l)=ready
then AppendRequestToTransit (Home(l),(Self,get,Self,l))
endif;
(ccgetx,l) :
if CurPhase(Self, l)=ready
then AppendRequestToTransit (Home(l), (Self,getx,Self,l))
endif;
(ccrpl,l) :
if CurPhase(Self, l)=ready and CCState(Self,l)=shared
then AppendRequestToTransit (Home(l),(Self,rpl,Self,l))
endif;
(ccwb,l) :
if CurPhase(Self, l)=ready and CCState(Self,l)=exclusive
then AppendRequestToTransit (Home(l),(Self,wb,Self,l))
endif;
_ : skip
endcase
endif
(*-----------------------------------------------------------------*)
transition R5 ==
if (InMess(Self)=get and Home(InLine(Self)) = Self)
then
if Pending (InLine(Self))
then if MessInTr(n(maxQ),InSource(Self))=noMess
then AppendToTransit (InSource(Self),
(Self,nack,InSource(Self),InLine(Self)))
InMess(Self):=noMess
endif
else if Owner (InLine(Self)) != none
then if MessInTr(n(maxQ),Owner(InLine(Self)))=noMess
then AppendToTransit (Owner (InLine(Self)),
149
Chapter A Appendix
(Self,fwdget,InSource(Self),InLine(Self)))
Pending (InLine(Self)) := true
InMess(Self):=noMess
endif
else if MessInTr(n(maxQ),InSource(Self))=noMess
then AppendToTransit (InSource(Self),
(Self,put,InSource(Self),InLine(Self)))
InMess(Self):=noMess
Sharer (InLine(Self), InSource(Self)) := true
endif
endif
endif
endif
transition R6 ==
if InMess(Self) = fwdget
then if CCState (Self,InLine(Self)) = exclusive
then if (Home(InLine(Self))=InSource(Self))
then if MessInTr(n(maxQ),Home(InLine(Self))) = noMess
then AppendToTransit ( Home(InLine(Self)),
(Self,put_swb,InSource(Self),InLine(Self)))
CCState(Self,InLine(Self)):=shared
InMess(Self):=noMess
endif
else if MessInTr(n(maxQ),InSource(Self)) = noMess
and MessInTr(n(maxQ),Home(InLine(Self))) = noMess
then AppendToTransit (InSource(Self),
(Self,put,InSource(Self),InLine(Self)))
AppendToTransit ( Home(InLine(Self)),
(Self,swb,InSource(Self),InLine(Self)))
CCState(Self,InLine(Self)):=shared
InMess(Self):=noMess
endif
endif
else if (Home(InLine(Self))=InSource(Self))
then if MessInTr(n(maxQ),Home(InLine(Self))) = noMess
then AppendToTransit (Home(InLine(Self)),
(Self,nackc2,InSource(Self),InLine(Self)))
InMess(Self):=noMess
endif
else if MessInTr(n(maxQ),InSource(Self)) = noMess
and MessInTr(n(maxQ),Home(InLine(Self))) = noMess
then AppendToTransit (InSource(Self),
(Self,nack,InSource(Self),InLine(Self)))
AppendToTransit (Home(InLine(Self)),
(Self,nackc,InSource(Self),InLine(Self)))
InMess(Self):=noMess
endif
endif
endif
endif
transition R7 ==
150
FLASH Cache Coherence Protocol Section A.2
if InMess(Self) = put
then if CurPhase(Self,InLine(Self)) != invalidPhase
then CCState(Self,InLine(Self)) := shared
endif
CurPhase(Self,InLine(Self)) := ready
InMess(Self) := noMess
endif
transition R8 ==
if (InMess(Self) = swb and Home(InLine(Self)) = Self)
then
Sharer(InLine(Self), InSource(Self)) := true
if Owner(InLine(Self)) != none
then Sharer(InLine(Self), Owner(InLine(Self))) := true
endif
Owner(InLine(Self)) := none
Pending(InLine(Self)) := false
InMess(Self) := noMess
endif
(*-----------------------------------------------------------------*)
transition R7_R8 ==
if InMess(Self) = put_swb
then if CurPhase(Self,InLine(Self)) != invalidPhase
then CCState(Self,InLine(Self)) := shared
endif
CurPhase(Self,InLine(Self)) := ready
Sharer(InLine(Self), InSource(Self)) := true
if Owner(InLine(Self)) != none
then Sharer(InLine(Self), Owner(InLine(Self))) := true
endif
Owner(InLine(Self)) := none
Pending(InLine(Self)) := false
InMess(Self) := noMess
endif
(*-----------------------------------------------------------------*)
transition R9 ==
if InMess(Self) = nack
then
CurPhase(Self, InLine(Self)) := ready
InMess(Self) := noMess
endif
transition R10 ==
if (InMess(Self) = nackc and Home(InLine(Self)) = Self)
then
Pending(InLine(Self)) := false
InMess(Self) := noMess
endif
(*-----------------------------------------------------------------*)
151
Chapter A Appendix
transition R9_R10 ==
if InMess(Self) = nackc2
then
CurPhase(Self, InLine(Self)) := ready
Pending(InLine(Self)) := false
InMess(Self) := noMess
endif
(*-----------------------------------------------------------------*)
transition R11 ==
if (InMess(Self) = getx and Home(InLine(Self)) = Self)
then
if Pending(InLine(Self)) = true
then if MessInTr(n(maxQ),InSource(Self)) = noMess
then AppendToTransit (InSource(Self),
(Self,nack,InSource(Self),InLine(Self)))
InMess(Self):=noMess
endif
else if Owner(InLine(Self)) != none
then if MessInTr(n(maxQ),Owner(InLine(Self))) = noMess
then AppendToTransit (Owner(InLine(Self)),
(Self,fwdgetx,InSource(Self),InLine(Self)))
Pending(InLine(Self)) := true
InMess(Self):=noMess
endif
else if ( forall agent_ in Agent_without_none :
not(Sharer(InLine(Self),agent_)) )
then if MessInTr(n(maxQ),InSource(Self)) = noMess
then AppendToTransit (InSource(Self),
(Self,putx,InSource(Self),InLine(Self)))
Owner(InLine(Self)) := InSource(Self)
InMess(Self):=noMess
endif
else if (forall agent_ in Agent_without_none :
not(Sharer(InLine(Self),agent_))
or MessInTr(n(maxQ),agent_) = noMess )
then do forall agent_ in Agent_without_none
with Sharer(InLine(Self),agent_)
AppendToTransit (agent_,
(Self,inv,InSource(Self),InLine(Self)))
Pending(InLine(Self)):=true
enddo
InMess(Self):=noMess
endif
endif
endif
endif
endif
(*-----------------------------------------------------------------*)
152
FLASH Cache Coherence Protocol Section A.2
transition R12 ==
if InMess(Self) = fwdgetx
then
if CCState(Self,InLine(Self)) = exclusive
then if (Home(InLine(Self))=InSource(Self))
then if MessInTr(n(maxQ),Home(InLine(Self))) = noMess
then AppendToTransit (Home(InLine(Self)),
(Self,putx_fwdack,InSource(Self),InLine(Self)))
CCState(Self,InLine(Self)):=invalid
InMess(Self):=noMess
endif
else if MessInTr(n(maxQ),InSource(Self)) = noMess
and MessInTr(n(maxQ),Home(InLine(Self))) = noMess
then AppendToTransit (InSource(Self),
(Self,putx,InSource(Self),InLine(Self)))
AppendToTransit (Home(InLine(Self)),
(Self,fwdack,InSource(Self),InLine(Self)))
CCState(Self,InLine(Self)):=invalid
InMess(Self):=noMess
endif
endif
else if (Home(InLine(Self))=InSource(Self))
then if MessInTr(n(maxQ),Home(InLine(Self))) = noMess
then AppendToTransit (InSource(Self),
(Self,nackc2,InSource(Self),InLine(Self)))
InMess(Self):=noMess
endif
else if MessInTr(n(maxQ),InSource(Self)) = noMess
and MessInTr(n(maxQ),Home(InLine(Self))) = noMess
then AppendToTransit (InSource(Self),
(Self,nack,InSource(Self),InLine(Self)))
AppendToTransit (Home(InLine(Self)),
(Self,nackc,InSource(Self),InLine(Self)))
InMess(Self):=noMess
endif
endif
endif
endif
transition R13 ==
if InMess(Self) = putx
then
CCState(Self,InLine(Self)) := exclusive
CurPhase(Self, InLine(Self)) := ready
InMess(Self) := noMess
endif
transition R14 ==
if (InMess(Self) = fwdack and Home(InLine(Self)) = Self)
then
Owner(InLine(Self)) := InSource(Self)
Pending(InLine(Self)) := false
153
Chapter A Appendix
InMess(Self) := noMess
endif
(*-----------------------------------------------------------------*)
transition R13_R14 ==
if InMess(Self) = putx_fwdack
then
CCState(Self,InLine(Self)) := exclusive
CurPhase(Self, InLine(Self)) := ready
Owner(InLine(Self)) := InSource(Self)
Pending(InLine(Self)) := false
InMess(Self) := noMess
endif
(*-----------------------------------------------------------------*)
transition R15 ==
if InMess(Self) = inv
then
if MessInTr(n(maxQ),Home(InLine(Self))) = noMess
then AppendToTransit (Home(InLine(Self)),
(Self,invack,InSource(Self),InLine(Self)))
InMess(Self):=noMess
if CCState(Self,InLine(Self)) = shared
then CCState(Self,InLine(Self)) := invalid
else if CurPhase(Self, InLine(Self)) = wait
then CurPhase(Self, InLine(Self)) := invalidPhase
endif
endif
endif
endif
transition R16 ==
if (InMess(Self) = invack and Home(InLine(Self)) = Self)
then do forall agent_ in Agent_without_none with true
if InSender(Self)=agent_
then Sharer(InLine(Self),agent_) := false
if ( forall other_agent_ in (Agent_without_none\{agent_})
: Sharer(InLine(Self), other_agent_)=false )
then if MessInTr(n(maxQ),InSource(Self)) = noMess
then AppendToTransit (InSource(Self),
(Self,putx,InSource(Self),InLine(Self)))
Pending(InLine(Self)):=false
Owner(InLine(Self)) := InSource(Self)
InMess(Self):=noMess
endif
else InMess(Self):=noMess
endif
endif
enddo
154
FLASH Cache Coherence Protocol Section A.2
endif
(*-----------------------------------------------------------------*)
transition R17 ==
if (InMess(Self) = rpl and Home(InLine(Self)) = Self)
then if Sharer(InLine(Self),InSender(Self)) = true
and Pending(InLine(Self)) = false
then Sharer(InLine(Self),InSender(Self)) := false
CCState(Self,InLine(Self)) := invalid
endif
InMess(Self) := noMess
endif
transition R18 ==
if (InMess(Self) = wb and Home(InLine(Self)) = Self)
then if Owner(InLine(Self)) != none
then Owner(InLine(Self)) := none
CCState(Self,InLine(Self)) := invalid
endif
InMess(Self) := noMess
endif
(*-----------------------------------------------------------------*)
transition behavior ==
block
R_Requests
R5
R6
R7
R8
R7_R8
R9
R10
R9_R10
R11
R12
R13
R14
R13_R14
R15
R16
R17
R18
endblock
(*-----------------------------------------------------------------*)
transition ClearMessInTr(agent_) ==
block
155
Chapter A Appendix
MessInTr(n(maxQ),agent_):=noMess
if MessInTr(n(2),agent_)=noMess
then MessInTr(n(1),agent_):=noMess
else do forall i in {2..maxQ}
if MessInTr(n(i), agent_)!=noMess
then MessInTr (n(i-1), agent_):=MessInTr(n(i), agent_)
SenderInTr (n(i-1), agent_):=SenderInTr(n(i), agent_)
SourceInTr (n(i-1), agent_):=SourceInTr(n(i), agent_)
LineInTr (n(i-1), agent_):=LineInTr(n(i), agent_)
else MessInTr(n(i-1), agent_):=noMess
endif
enddo
endif
endblock
transition SendMess(agent_) ==
block
InSender(agent_):= SenderInTr(n(1), agent_)
InMess(agent_) := MessInTr(n(1), agent_)
InSource(agent_):= SourceInTr(n(1), agent_)
InLine(agent_) := LineInTr(n(1), agent_)
ClearMessInTr(agent_)
endblock
transition SendR(agent_) ==
block
InSender(agent_) := SenderInTrR(agent_)
InMess(agent_) := MessInTrR (agent_)
InSource(agent_) := SourceInTrR (agent_)
InLine(agent_) := LineInTrR (agent_)
MessInTrR(agent_) := noMess
endblock
transition SendRequest (agent_) ==
if MessInTrR (agent_) = get
and CurPhase(SenderInTrR(agent_), LineInTrR (agent_)) = ready
and CCState(SenderInTrR(agent_), LineInTrR (agent_)) = invalid
then SendR(agent_)
CurPhase(SenderInTrR(agent_), LineInTrR (agent_)) := wait
else if MessInTrR (agent_) = getx
and CurPhase(SenderInTrR(agent_),LineInTrR(agent_))=ready
and CCState(SenderInTrR(agent_),LineInTrR(agent_))=invalid
then SendR(agent_)
CurPhase(SenderInTrR(agent_),LineInTrR (agent_)) := wait
else if MessInTrR (agent_) = rpl
and CurPhase(SenderInTrR(agent_),
LineInTrR (agent_)) = ready
and CCState(SenderInTrR(agent_),
LineInTrR(agent_)) = shared
then SendR(agent_)
CCState(SenderInTrR(agent_),
156
FLASH Cache Coherence Protocol Section A.2
LineInTrR(agent_)) := invalid
else if MessInTrR (agent_) = wb
and CurPhase(SenderInTrR(agent_),
LineInTrR(agent_)) = ready
and CCState(SenderInTrR(agent_),
LineInTrR(agent_)) = exclusive
then SendR(agent_)
CCState(SenderInTrR(agent_),
LineInTrR (agent_)) := invalid
endif
endif
endif
endif
(*----------------------------------------------------------------*)
transition synchronize ==
block
do forall agent_ in Agent_without_none with true
if InMess(agent_)=noMess
then if MessInTr(n(1),agent_) != noMess
then SendMess(agent_)
else if MessInTrR(agent_) != noMess
and InMess(agent_)=noMess
then SendRequest(agent_)
endif
endif
endif
enddo
endblock
(*----------------------------------------------------------------*)
transition main ==
if toggle=behave
then
behavior
toggle:=sync
else
synchronize
toggle:=behave
endif
(*-----------------------------------------------------------------*)
A.2.2 The Counterexamples
Counterexample 1
Scenario: agent_2 has shared access to line_1 when agent_1 ask for exclusive
access (state 1.6). home (i.e. agent_1) sends an invalidation message to agent_2
(state 1.10 – state 1.11) that is responsed with an invalidation acknowledgement
by agent_2. Now the exclusive access is granted to agent_1 by sending a
157
Chapter A Appendix
putx-message but without noting the new owner of line_1 (state 1.14 – state
1.15). Although the state of agent_1 is exclusive with respect to line_1,
agent_2, when asking for in the next step (state 1.17), gets exclusive access, too
(state 1.19). Mutual exclusion for exclusive access is violated (state 1.16, state 1.20).
Checked requirement specification is safety:
AG (!(State(agent_1, line_1) = exclusive
& State(agent_2, line_1)=exclusive))
-- specification AG (!(State(agent_1, line_1... is false
-- as demonstrated by the following execution sequence
state 1.1:
State(agent_1, line_1) = invalid
State(agent_2, line_1) = invalid
CurPhase(agent_1, line_1) = ready
CurPhase(agent_2, line_1) = ready
InLine(agent_1) = line_1
InLine(agent_2) = line_1
InMess(agent_1) = noMess
InMess(agent_2) = noMess
InSender(agent_1) = agent_2
InSender(agent_2) = agent_2
InSource(agent_1) = agent_2
InSource(agent_2) = agent_2
LineInTr(agent_1) = line_1
LineInTr(agent_2) = line_1
LineInTrR(agent_1) = line_1
MessInTr(agent_1) = noMess
MessInTr(agent_2) = noMess
MessInTrR(agent_1) = noMess
Owner(line_1) = none
Pending(line_1) = 0
Self = agent_2
SenderInTr(agent_1) = agent_2
SenderInTr(agent_2) = agent_2
SenderInTrR(agent_1) = agent_2
Sharer(line_1, agent_1) = 0
Sharer(line_1, agent_2) = 0
SourceInTr(agent_1) = agent_2
SourceInTr(agent_2) = agent_2
SourceInTrR(agent_1) = agent_1
produce(agent_1) = (ccwb, line_1)
produce(agent_2) = (ccwb, line_1)
toggle = behave
state 1.2:
toggle = sync
state 1.3:
produce(agent_2) = (ccget, line_1)
toggle = behave
state 1.4:
CurPhase(agent_2, line_1) = wait
MessInTrR(agent_1) = get
SourceInTrR(agent_1) = agent_2
produce(agent_2) = (ccwb, line_1)
toggle = sync
state 1.5:
InMess(agent_1) = get
MessInTrR(agent_1) = noMess
Self = agent_1
produce(agent_1) = (ccgetx, line_1)
toggle = behave
state 1.6:
CurPhase(agent_1, line_1) = wait
MessInTr(agent_2) = put
MessInTrR(agent_1) = getx
Self = agent_2
SenderInTr(agent_2) = agent_1
SenderInTrR(agent_1) = agent_1
Sharer(line_1, agent_2) = 1
SourceInTrR(agent_1) = agent_1
produce(agent_1) = (ccwb, line_1)
toggle = sync
state 1.7:
InMess(agent_1) = noMess
InMess(agent_2) = put
InSender(agent_2) = agent_1
MessInTr(agent_2) = noMess
toggle = behave
state 1.8:
State(agent_2, line_1) = shared
CurPhase(agent_2, line_1) = ready
InMess(agent_2) = noMess
toggle = sync
state 1.9:
InMess(agent_1) = getx
InSender(agent_1) = agent_1
InSource(agent_1) = agent_1
MessInTrR(agent_1) = noMess
Self = agent_1
toggle = behave
state 1.10:
MessInTr(agent_2) = inv
Pending(line_1) = 1
Self = agent_2
158
FLASH Cache Coherence Protocol Section A.2
SourceInTr(agent_2) = agent_1
toggle = sync
state 1.11:
InMess(agent_1) = noMess
InMess(agent_2) = inv
InSource(agent_2) = agent_1
MessInTr(agent_2) = noMess
produce(agent_2) = (ccgetx, line_1)
toggle = behave
state 1.12:
State(agent_2, line_1) = invalid
CurPhase(agent_2, line_1) = wait
MessInTr(agent_1) = invack
MessInTrR(agent_1) = getx
SenderInTrR(agent_1) = agent_2
SourceInTr(agent_1) = agent_1
SourceInTrR(agent_1) = agent_2
produce(agent_2) = (ccwb, line_1)
toggle = sync
state 1.13:
InMess(agent_1) = invack
InMess(agent_2) = noMess
InSender(agent_1) = agent_2
MessInTr(agent_1) = noMess
Self = agent_1
toggle = behave
state 1.14:
MessInTr(agent_1) = putx
Pending(line_1) = 0
Self = agent_2
SenderInTr(agent_1) = agent_1
Sharer(line_1, agent_1) = 0
toggle = sync
state 1.15:
InMess(agent_1) = putx
InSender(agent_1) = agent_1
MessInTr(agent_1) = noMess
Self = agent_1
toggle = behave
state 1.16:
State(agent_1, line_1) = exclusive
CurPhase(agent_1, line_1) = ready
InMess(agent_1) = noMess
Self = agent_2
toggle = sync
state 1.17:
InMess(agent_1) = getx
InSender(agent_1) = agent_2
InSource(agent_1) = agent_2
MessInTrR(agent_1) = noMess
Self = agent_1
produce(agent_1) = (ccget, line_1)
toggle = behave
state 1.18:
CurPhase(agent_1, line_1) = wait
MessInTr(agent_2) = putx
MessInTrR(agent_1) = get
Owner(line_1) = agent_2
Self = agent_2
SenderInTrR(agent_1) = agent_1
SourceInTr(agent_2) = agent_2
SourceInTrR(agent_1) = agent_1
produce(agent_1) = (ccwb, line_1)
toggle = sync
state 1.19:
InMess(agent_1) = noMess
InMess(agent_2) = putx
InSource(agent_2) = agent_2
MessInTr(agent_2) = noMess
MessInTrR(agent_1) = noMess
toggle = behave
state 1.20:
State(agent_2, line_1) = exclusive
CurPhase(agent_2, line_1) = ready
InMess(agent_2) = noMess
toggle = sync
resources used:
user time: 1910.14 s, system time: 0.51 s
BDD nodes allocated: 1755356
Bytes allocated: 33161216
BDD nodes representing transition relation: 832699 + 54
Counterexample 2
Scenario: The length of the queue of messages in transit equals one and two agents
are involved in communication. Both agents, agent_1 and agent_2,aresharersof
line_1 (state 1.6, state 1.12). agent_2 sends an invalidation acknowledgement to
home (i.e. agent_1). Then agent_1 tries to send its inv-message but it is blocked
because the queue is full (state 1.20 and following). As being blocked, agent_1 as
the home of the line cannot process the message of agent_2 in order to free the
159
Chapter A Appendix
queue. In this situation a deadlock occurs.
Checked requirement specification is liveness:
AG AF (curPhase(agent_1, line_1) = ready)
& AG AF (curPhase(agent_2, line_1) = ready)
-- specification AG AF CurPhase(agent_1, line_1... is false
-- as demonstrated by the following execution sequence
state 1.1:
State(agent_1, line_1) = invalid
State(agent_2, line_1) = invalid
CurPhase(agent_1, lines_1) = ready
CurPhase(agent_2, line_1) = ready
InLine(agent_1) = line_1
InLine(agent_2)= line_1
InMess(agent_1) = noMess
InMess(agent_2)= noMess
InSender(agent_1) = agent_2
InSender(agent_2)= agent_2
InSource(agent_1) = agent_2
InSource(agent_2)= agent_2
LineInTr(agent_1) = line_1
LineInTr(agent_2)= line_1
LineInTrR(agent_1) = line_1
MessInTr(agent_1) = noMess
MessInTr(agent_2)= noMess
MessInTrR(agent_1) = noMess
Owner(lines_1) = none
Pending(line_1) = 0
Self = agent_2
SenderInTr(agent_1) = agent_2
SenderInTr(agent_2) = agent_2
SenderInTrR(agent_1) = agent_2
Sharer(line_1, agent_1) = 0
Sharer(line_1,agent_2) = 0
SourceInTr(agent_1) = agent_2
SourceInTr(agent_2) = agent_2
SourceInTrR(agent_1) = agent_1
produce(agent_1) = (ccwb, line_1)
produce(agent_2) = (ccwb, line_1)
toggle = behave
state 1.2:
toggle = sync
state 1.3:
Self = agent_1
produce(agent_1) = (ccget, line_1)
toggle = behave
state 1.4:
CurPhase(agent_1, line_1) = wait
MessInTrR(agent_1) = get
Self = agent_2
SenderInTrR(agent_1) = agent_1
produce(agent_1) = (ccwb, line_1)
toggle = sync
state 1.5:
InMess(agent_1) = get
InSender(agent_1) = agent_1
InSource(agent_1) = agent_1
MessInTrR(agent_1) = noMess
Self = agent_1
toggle = behave
state 1.6:
MessInTr(agent_1) = put
Self = agent_2
SenderInTr(agent_1) = agent_1
Sharer(line_1, agent_1) = 1
SourceInTr(agent_1) = agent_1
toggle = sync
state 1.7:
InMess(agent_1) = put
MessInTr(agent_1) = noMess
Self = agent_1
toggle = behave
state 1.8:
State(agent_1, line_1) = shared
CurPhase(agent_1, line_1) = ready
InMess(agent_1) = noMess
Self = agent_2
toggle = sync
state 1.9:
produce(agent_2) = (ccget, line_1)
toggle = behave
state 1.10:
CurPhase(agent_2, line_1) = wait
MessInTrR(agent_1) = get
SenderInTrR(agent_1) = agent_2
SourceInTrR(agent_1) = agent_2
produce(agent_2) = (ccwb, line_1)
toggle = sync
state 1.11:
InMess(agent_1) = get
InSender(agent_1) = agent_2
InSource(agent_1) = agent_2
MessInTrR(agent_1) = noMess
Self = agent_1
produce(agent_1) = (ccgetx, line_1)
toggle = behave
160
FLASH Cache Coherence Protocol Section A.2
state 1.12:
CurPhase(agent_1, line_1) = wait
MessInTr(agent_2) = put
MessInTrR(agent_1) = getx
Self = agent_2
SenderInTr(agent_2) = agent_1
SenderInTrR(agent_1) = agent_1
Sharer(line_1, agent_2) = 1
SourceInTrR(agent_1) = agent_1
produce(agent_1) = (ccwb, line_1)
toggle = sync
state 1.13:
InMess(agent_1) = noMess
InMess(agent_2) = put
InSender(agent_2) = agent_1
MessInTr(agent_2) = noMess
Self = agent_1
toggle = behave
state 1.14:
Self = agent_2
toggle = sync
state 1.15:
InMess(agent_1) = getx
InSender(agent_1) = agent_1
InSource(agent_1) = agent_1
MessInTrR(agent_1) = noMess
toggle = behave
state 1.16:
State(agent_2, line_1) = shared
CurPhase(agent_2, line_1) = ready
InMess(agent_2) = noMess
toggle = sync
state 1.17:
Self = agent_1
toggle = behave
state 1.18:
MessInTr(agent_1) = inv
MessInTr(agent_2) = inv
Pending(line_1) = 1
Self = agent_2
SourceInTr(agent_2) = agent_1
toggle = sync
state 1.19:
InMess(agent_1) = inv
InMess(agent_2) = inv
InSource(agent_2) = agent_1
MessInTr(agent_1) = noMess
MessInTr(agent_2) = noMess
toggle = behave
-- loop starts here --
state 1.20:
State(agent_2, line_1) = invalid
MessInTr(agent_1) = invack
SenderInTr(agent_1) = agent_2
toggle = sync
state 1.21:
Self = agent_1
toggle = behave
-- loop starts here --
state 1.22:
Self = agent_2
toggle = sync
state 1.23:
toggle = behave
state 1.24:
toggle = sync
resources used:
user time: 2391.1 s, system time: 0.64 s
BDD nodes allocated: 1754532
Bytes allocated: 33161216
BDD nodes representing transition relation: 658216 + 54
Counterexample 3
Scenario: The oracle produce(agent_1,line_1) produces a write back request
wb, the corresponding request is sent to the queue for request messages in transit
MessInTrR (state 1.1). This request message is not passed through to the home
but has to wait in the queue. In the meanwhile, agent_1 generates a new request
for exclusive access and gets the owner of the line (state 1.8). Then agent_2
requests for exclusive access and as a consequence agent_1 invalidates its status of
exclusive access to line_1 and agent_2 becomes owner of the line (state 1.14 and
state 1.15). Then the late wb-request of agent_1 is transfered and owner(line_1)
is set to none (state 1.18), although agent_2 was the current owner of to the line
(state 1.16) and not agent_1. Now its possible for agent_1 to get exclusive access
161
Chapter A Appendix
to the line too (state 1.20, state 1.22).
Checked requirement specification is safety:
AG (!(State(agent_1, line_1) = exclusive
& State(agent_2, line_1)=exclusive))
-- specification AG (!(State(agent_1, line_1... is false
-- as demonstrated by the following execution sequence
state 1.1:
State(agent_1, line_1) = invalid
State(agent_2, line_1) = invalid
CurPhase(agent_1, line_1) = ready
CurPhase(agent_2, line_1) = ready
InLine(agent_1) = line_1
InLine(agent_2) = line_1
InMess(agent_1) = noMess
InMess(agent_2) = noMess
InSender(agent_1) = agent_2
InSender(agent_2) = agent_2
InSource(agent_1) = agent_2
InSource(agent_2) = agent_2
LineInTr(agent_1) = line_1
LineInTr(agent_2) = line_1
LineInTrR(agent_1) = line_1
MessInTr(agent_1) = noMess
MessInTr(agent_2) = noMess
MessInTrR(agent_1) = noMess
Owner(line_1) = none
Pending(line_1) = 0
Self = agent_2
SenderInTr(agent_1) = agent_2
SenderInTr(agent_2) = agent_2
SenderInTrR(agent_1) = agent_2
Sharer(line_1, agent_1) = 0
Sharer(line_1, agent_2) = 0
SourceInTr(agent_1) = agent_2
SourceInTr(agent_2) = agent_2
SourceInTrR(agent_1) = agent_1
produce(agent_1) = (ccwb, line_1)
produce(agent_2) = (ccwb, line_1)
toggle = behave
state 1.2:
toggle = sync
state 1.3:
Self = agent_1
produce(agent_1) = (ccgetx, line_1)
toggle = behave
state 1.4:
CurPhase(agent_1, line_1) = wait
MessInTrR(agent_1) = getx
Self = agent_2
SenderInTrR(agent_1) = agent_1
produce(agent_1) = (ccwb, line_1)
toggle = sync
state 1.5:
InMess(agent_1) = getx
InSender(agent_1) = agent_1
InSource(agent_1) = agent_1
MessInTrR(agent_1) = noMess
Self = agent_1
toggle = behave
state 1.6:
MessInTr(agent_1) = putx
Owner(line_1) = agent_1
Self = agent_2
SenderInTr(agent_1) = agent_1
SourceInTr(agent_1) = agent_1
toggle = sync
state 1.7:
InMess(agent_1) = putx
MessInTr(agent_1) = noMess
Self = agent_1
toggle = behave
state 1.8:
State(agent_1, line_1) = exclusive
CurPhase(agent_1, line_1) = ready
InMess(agent_1) = noMess
Self = agent_2
toggle = sync
state 1.9:
produce(agent_2) = (ccgetx, line_1)
toggle = behave
state 1.10:
CurPhase(agent_2, line_1) = wait
MessInTrR(agent_1) = getx
SenderInTrR(agent_1) = agent_2
SourceInTrR(agent_1) = agent_2
produce(agent_2) = (ccwb, line_1)
toggle = sync
state 1.11:
InMess(agent_1) = getx
InSender(agent_1) = agent_2
InSource(agent_1) = agent_2
MessInTrR(agent_1) = noMess
Self = agent_1
produce(agent_1) = undef
toggle = behave
162
FLASH Cache Coherence Protocol Section A.2
state 1.12:
MessInTr(agent_1) = fwdgetx
Pending(line_1) = 1
Self = agent_2
SourceInTr(agent_1) = agent_2
produce(agent_1) = (ccwb, line_1)
toggle = sync
state 1.13:
InMess(agent_1) = fwdgetx
InSender(agent_1) = agent_1
MessInTr(agent_1) = noMess
Self = agent_1
toggle = behave
state 1.14:
State(agent_1, line_1) = invalid
MessInTr(agent_1) = fwdack
MessInTr(agent_2) = putx
MessInTrR(agent_1) = wb
Self = agent_2
SenderInTr(agent_2) = agent_1
SenderInTrR(agent_1) = agent_1
SourceInTrR(agent_1) = agent_1
toggle = sync
state 1.15:
InMess(agent_1) = fwdack
InMess(agent_2) = putx
InSender(agent_2) = agent_1
MessInTr(agent_1) = noMess
MessInTr(agent_2) = noMess
Self = agent_1
toggle = behave
state 1.16:
InMess(agent_1) = noMess
Owner(line_1) = agent_2
Pending(line_1) = 0
Self = agent_2
toggle = sync
state 1.17:
InMess(agent_1) = wb
InSource(agent_1) = agent_1
MessInTrR(agent_1) = noMess
Self = agent_1
produce(agent_1) = (ccgetx, line_1)
toggle = behave
state 1.18:
CurPhase(agent_1, line_1) = wait
InMess(agent_1) = noMess
MessInTrR(agent_1) = getx
Owne(line_1) = none
Self = agent_2
produce(agent_1) = (ccwb, line_1)
toggle = sync
state 1.19:
InMess(agent_1) = getx
MessInTrR(agent_1) = noMess
Self = agent_1
toggle = behave
state 1.20:
MessInTr(agent_1) = putx
Owner(line_1) = agent_1
Self = agent_2
SourceInTr(agent_1) = agent_1
toggle = sync
state 1.21:
InMess(agent_1) = putx
MessInTr(agent_1) = noMess
Self = agent_1
toggle = behave
state 1.22:
State(agent_1, line_1) = exclusive
CurPhase(agent_1, line_1) = ready
InMess(agent_1) = noMess
Self = agent_2
toggle = sync
state 1.23:
toggle = behave
state 1.24:
State(agent_2, line_1) = exclusive
CurPhase(agent_2, line_1) = ready
InMess(agent_2) = noMess
toggle = sync
resources used:
user time: 1244.76 s, system time: 0.4 s
BDD nodes allocated: 1754532
Bytes allocated: 33161216
BDD nodes representing transition relation: 658216 + 54
163
Chapter A Appendix
A.3 Production Cell
A.3.1 The ASM-SL Code
(*-----------------------------------------------------------------*)
(* Datatypes *)
datatype SWITCH_1 == {on, off}
datatype SWITCH_2 == {up, down, idle}
datatype SWITCH_3 == {clockwise, counterClockwise, idle2}
datatype SWITCH_4 == {extending, retract, idle3}
datatype SWITCH_5 == {run, idle4}
datatype SWITCH_6 == {toFeedBelt, toDepBelt, idle5}
datatype SENSOR_1 == {Arm1IntoPress, OverTable, retracted,
Arm2IntoPress, OverDepBelt}
datatype SENSOR_2 == {Arm1ToTable, Arm2ToPress, Arm2ToDepBelt,
Arm1ToPress}
datatype SENSOR_3 == {OnDepBelt, OnFeedBelt, SafeDistanceFromFeedBelt}
(*-----------------------------------------------------------------*)
(* Dynamic functions *)
(* Module FeedBelt: *)
dynamic function FeedBeltMot :SWITCH_1
initially on
dynamic function Delivering :BOOL
initially false
dynamic function FeedBeltFree :BOOL
initially true
(*Module Table *)
dynamic function TableLoaded :BOOL
initially false
dynamic function TableElevationMot :SWITCH_2
initially idle
dynamic function TableRotationMot :SWITCH_3
initially idle2
(* MODULE Robot *)
dynamic function Arm1Mot :SWITCH_4
164
Production Cell Section A.3
initially idle3
dynamic function Arm2Mot :SWITCH_4
initially idle3
dynamic function RobotRotationMot :SWITCH_3
initially idle2
dynamic function Arm1Mag :SWITCH_1
initially off
dynamic function Arm2Mag :SWITCH_1
initially off
(* Module Press *)
dynamic function PressMot :SWITCH_2
initially idle
dynamic function PressLoaded :BOOL
initially true
(* Module DepositBelt *)
dynamic function DepBeltMot :SWITCH_5
initially run
dynamic function Critical :BOOL
initially false
dynamic function PieceAtDepositBeltEnd :BOOL
initially false
dynamic function DepositBeltReadyForLoading :BOOL
initially true
(* Module Crane *)
dynamic function CraneHorizontalMot :SWITCH_6
initially idle5
dynamic function CraneVerticalMot :SWITCH_2
initially idle
dynamic function CraneMagnet :SWITCH_1
initially off
(*------------------------------------*)
(* Sensorvariables or Orakelfunctions *)
external function PieceInFeedBeltLightBarrier :BOOL
external function MaxRotation :BOOL
external function MinRotation :BOOL
external function TopPosition :BOOL
165
Chapter A Appendix
external function BottomPosition :BOOL
external function Arm1Ext :SENSOR_1
external function Arm2Ext :SENSOR_1
external function Angle :SENSOR_2
external function TopPositionPress :BOOL
external function MiddlePositionPress :BOOL
external function BottomPositionPress :BOOL
external function ForgingComplete :BOOL
external function PieceInDepositBeltLightBarrier :BOOL
external function GripperOverDepBelt :BOOL
external function GripperOverFeedBelt :BOOL
external function GripperVerticalPos :SENSOR_3
(*------------------------------------------------------------*)
(* MODULE FeedBelt *)
transition FB_NORMAL ==
if (FeedBeltMot = on) and not(Delivering) and
(PieceInFeedBeltLightBarrier = true)
then
block
FeedBeltFree := true
if ((BottomPosition=true) and (MinRotation=true)
and (TableElevationMot=idle)
and (TableRotationMot=idle2))
and not(TableLoaded)
then Delivering := true
else FeedBeltMot := off
endif
endblock
endif
transition FB_STOPPED ==
if (FeedBeltMot = off)
and ((BottomPosition=true) and (MinRotation=true)
and (TableElevationMot=idle) and (TableRotationMot=idle2))
and not(TableLoaded)
then FeedBeltMot := on
Delivering := true
endif
transition FB_CRITICAL ==
if (FeedBeltMot = on) and Delivering
and not(PieceInFeedBeltLightBarrier)
then Delivering := false
TableLoaded := true
endif
(*------------------------------------------------------------*)
(* MODULE Table *)
166
Production Cell Section A.3
transition WAITING_LOAD ==
if ((BottomPosition = true) and (MinRotation = true)
and (TableElevationMot = idle)
and (TableRotationMot = idle2) and (TableLoaded = true)
then TableElevationMot := up
TableRotationMot := clockwise
endif
transition MOVING_UNLOAD_A ==
if (TableElevationMot = up) and (TopPosition = true)
then TableElevationMot := idle
endif
transition MOVING_UNLOAD_B ==
if (TableRotationMot = clockwise) and (MaxRotation = true)
then TableRotationMot := idle2
endif
transition WAITING_UNLOAD ==
if ((TopPosition = true) and (MaxRotation = true)
and (TableElevationMot = idle)
and (TableRotationMot = idle2))
and (TableLoaded = true)
then TableElevationMot := down
TableRotationMot := counterClockwise
endif
transition MOVING_LOAD_A ==
if (TableElevationMot = down) and (BottomPosition = true)
then TableElevationMot := idle
endif
transition MOVING_LOAD_B ==
if (TableRotationMot = counterClockwise)
and (MinRotation = true)
then TableRotationMot := idle2
endif
(*------------------------------------------------------------*)
(* MODULE Robot *)
transition WAITING1 ==
if (Angle=Arm1ToTable) and (Arm1Ext=retracted)
and (Arm2Ext=retracted) and (RobotRotationMot=idle2)
and (Arm1Mot=idle3) and (Arm2Mot=idle3) and (Arm1Mag=off)
and (Arm2Mag=off) and TopPosition and MaxRotation
and TableLoaded
then Arm1Mot:=extending
endif
transition WAITING2 ==
if(Angle=Arm2ToPress) and (Arm1Ext=retracted)
167
Chapter A Appendix
and (Arm2Ext=retracted) and (RobotRotationMot=idle2)
and (Arm1Mot=idle3) and (Arm2Mot=idle3) and (Arm1Mag=on)
and (Arm2Mag=off) and BottomPosition and (PressMot=idle)
and PressLoaded
then Arm2Mot:=extending
endif
transition WAITING3 ==
if (Angle=Arm2ToDepBelt) and (Arm1Ext=retracted)
and (Arm2Ext=retracted) and (RobotRotationMot=idle2)
and (Arm1Mot=idle3) and (Arm2Mot=idle3) and (Arm1Mag=on)
and (Arm2Mag=on) and DepositBeltReadyForLoading
then Arm2Mot:=extending
endif
transition WAITING4 ==
if (Angle=Arm2ToDepBelt) and (Arm1Ext=retracted)
and (Arm2Ext=retracted) and (RobotRotationMot=idle2)
and (Arm1Mot=idle3) and (Arm2Mot=idle3) and (Arm1Mag=on)
and (Arm2Mag=on) and MiddlePositionPress and (PressMot=idle)
and not(PressLoaded)
then Arm1Mot:=extending
endif
transition ACTION_extension1 ==
if (Angle=Arm1ToTable) and (Arm1Mot=extending)
and (Arm1Ext=OverTable)
then
block
Arm1Mot:=idle3
Arm1Mag:=on
endblock
endif
transition ACTION_extension2 ==
if (Angle=Arm2ToPress) and (Arm2Mot=extending)
and (Arm2Ext=Arm2IntoPress)
then
block
Arm2Mot:=idle3
Arm2Mag:=on
endblock
endif
transition ACTION_extension3 ==
if (Angle=Arm2ToDepBelt) and (Arm2Mot=extending)
and (Arm2Ext=OverDepBelt)
then
block
Arm2Mot:=idle3
Arm2Mag:=off
endblock
endif
168
Production Cell Section A.3
transition ACTION_extension4 ==
if (Angle=Arm1ToPress) and (Arm1Mot=extending)
and (Arm1Ext=Arm1IntoPress)
then
block
Arm1Mot:=idle3
Arm1Mag:=off
endblock
endif
(*----------------------------*)
transition ACTION_proper1 ==
if (Angle=Arm1ToTable) and (Arm1Ext=OverTable)
and (Arm1Mot=idle3) and (Arm1Mag=on)
then
Arm1Mot:=retract
endif
transition ACTION_proper2 ==
if (Angle=Arm2ToPress) and (Arm2Ext=Arm2IntoPress)
and (Arm2Mot=idle3) and (Arm2Mag=on)
then
Arm2Mot:=retract
endif
transition ACTION_proper3 ==
if (Angle=Arm2ToDepBelt) and (Arm2Ext=OverDepBelt)
and (Arm2Mot=idle3) and (Arm2Mag=off)
then
Arm2Mot:=retract
endif
transition ACTION_proper4 ==
if (Angle=Arm1ToPress) and (Arm1Ext=Arm1IntoPress)
and (Arm1Mot=idle3) and (Arm1Mag=off)
then
Arm1Mot:=retract
endif
(*----------------------------*)
transition ACTION_retraction1 ==
if (Angle=Arm1ToTable) and (Arm1Mot=retract)
and (Arm1Ext=retracted)
then
block
RobotRotationMot:=counterClockwise
TableLoaded:=false
endblock
endif
transition ACTION_retraction2 ==
169
Chapter A Appendix
if (Angle=Arm2ToPress) and (Arm2Mot=retract)
and (Arm2Ext=retracted)
then
block
RobotRotationMot:=counterClockwise
PressLoaded:=false
endblock
endif
transition ACTION_retraction3 ==
if (Angle=Arm2ToDepBelt) and (Arm2Mot=retract)
and (Arm2Ext=retracted)
then
block
RobotRotationMot:=counterClockwise
DepositBeltReadyForLoading:=false
endblock
endif
transition ACTION_retraction4 ==
if (Angle=Arm1ToPress) and (Arm1Mot=retract)
and (Arm1Ext=retracted)
then
block
RobotRotationMot:=clockwise
PressLoaded:=true
endblock
endif
(*----------------------------*)
transition MOVING1 ==
if (Arm1Ext=retracted) and (Arm2Ext=retracted)
and (Arm1Mot=idle3) and (Arm2Mot=idle3)
and (RobotRotationMot=counterClockwise)
and (Arm1Mag=on) and (Arm2Mag=off)
and (Angle=Arm2ToPress)
then
RobotRotationMot:=idle2
endif
transition MOVING2 ==
if (Arm1Ext=retracted) and (Arm2Ext=retracted)
and (Arm1Mot=idle3) and (Arm2Mot=idle3)
and (RobotRotationMot=counterClockwise)
and (Arm1Mag=on) and (Arm2Mag=on)
and (Angle=Arm2ToDepBelt)
then
RobotRotationMot:=idle2
endif
transition MOVING3 ==
if (Arm1Ext=retracted) and (Arm2Ext=retracted)
170
Production Cell Section A.3
and (Arm1Mot=idle3) and (Arm2Mot=idle3)
and (RobotRotationMot=counterClockwise)
and (Arm1Mag=on) and (Arm2Mag=off)
and (Angle=Arm1ToPress)
then
RobotRotationMot:=idle2
endif
transition MOVING4 ==
if (Arm1Ext=retracted) and (Arm2Ext=retracted)
and (Arm1Mot=idle3) and (Arm2Mot=idle3)
and (RobotRotationMot=clockwise)
and (Arm1Mag=off) and (Arm2Mag=off)
and (Angle=Arm1ToTable)
then
RobotRotationMot:=idle2
endif
(*------------------------------------------------------*)
(* Module Press *)
transition WAITING_UNLOAD_PRESS ==
if BottomPositionPress and (PressMot=idle)
and (PressLoaded=false)
then
PressMot:=up
endif
transition MOVING_TO_MIDDLE_PRESS ==
if not(PressLoaded) and (PressMot=up)
and MiddlePositionPress
then
PressMot:=idle
endif
transition WAITING_LOAD_PRESS ==
if MiddlePositionPress and (PressMot=idle)
and PressLoaded
then
PressMot:=up
endif
transition MOVING_TO_UPPER_PRESS ==
if PressLoaded and (PressMot=up)
then
PressMot:=idle
endif
transition CLOSED_PRESS ==
if TopPositionPress and (PressMot=idle)
then
PressMot:=down
endif
171
Chapter A Appendix
transition MOVING_TO_LOWER_PRESS ==
if (PressMot=down) and BottomPositionPress
then
PressMot:=idle
endif
(*-----------------------------------------------------------*)
(* Module Deposit Belt *)
transition DB_NORMAL ==
if (DepBeltMot=run) and not(Critical)
and PieceInDepositBeltLightBarrier
then
Critical:=true
endif
transition DB_CRITICAL ==
if (DepBeltMot=run) and Critical
and not(PieceInDepositBeltLightBarrier)
then
block
DepBeltMot:=idle4
Critical:=false
PieceAtDepositBeltEnd:=true
endblock
endif
transition DB_STOPPED ==
if (DepBeltMot=idle4) and not(PieceAtDepositBeltEnd)
then
DepBeltMot:=run
endif
(*-----------------------------------------------------------*)
(* Module Crane *)
transition WAITING_DB ==
if GripperOverDepBelt and (GripperVerticalPos=OnDepBelt) and
(CraneHorizontalMot=idle5) and (CraneVerticalMot=idle) and
(CraneMagnet=off)
and PieceAtDepositBeltEnd
then
CraneMagnet:=on
endif
transition UNLOADING_DBa ==
if (CraneVerticalMot=idle) and (GripperVerticalPos=OnDepBelt)
and (CraneMagnet=on)
then
CraneVerticalMot:=up
172
Production Cell Section A.3
endif
transition UNLOADING_DBb ==
if (CraneVerticalMot=up)
and (GripperVerticalPos=SafeDistanceFromFeedBelt)
then
block
CraneVerticalMot:=idle
CraneHorizontalMot:=toFeedBelt
DepositBeltReadyForLoading:=true
PieceAtDepositBeltEnd:=false
endblock
endif
transition MOVING_FB ==
if (CraneHorizontalMot=toFeedBelt) and GripperOverFeedBelt
then
CraneHorizontalMot:=idle5
endif
transition WAITING_FB ==
if GripperOverFeedBelt
and (GripperVerticalPos=SafeDistanceFromFeedBelt)
and (CraneHorizontalMot=idle5) and (CraneVerticalMot=idle)
and (CraneMagnet=on) and FeedBeltFree
then
CraneVerticalMot:=down
endif
transition LOADING_FBa ==
if (CraneVerticalMot=down) and (GripperVerticalPos=OnFeedBelt)
and GripperOverFeedBelt
then
block
CraneVerticalMot:=idle
CraneMagnet:=off
endblock
endif
transition LOADING_FBb ==
if (CraneVerticalMot=idle) and (GripperVerticalPos=OnFeedBelt)
and GripperOverFeedBelt and (CraneHorizontalMot=idle5)
and (CraneMagnet=off)
then
block
CraneHorizontalMot:=toDepBelt
FeedBeltFree:=false
endblock
endif
transition MOVING_DBa ==
if (CraneHorizontalMot=toDepBelt) and GripperOverDepBelt
173
Chapter A Appendix
then
block
CraneHorizontalMot:=idle5
CraneVerticalMot:=down
endblock
endif
transition MOVING_DBb ==
if GripperOverDepBelt and (CraneVerticalMot=down)
and (GripperVerticalPos=OnDepBelt)
then
CraneVerticalMot:=idle
endif
(*-----------------------------------------------------------------*)
transition productionCell ==
block
FB_NORMAL
FB_STOPPED
FB_CRITICAL
WAITING_LOAD
MOVING_UNLOAD_A
MOVING_UNLOAD_B
WAITING_UNLOAD
MOVING_LOAD_A
MOVING_LOAD_B
WAITING1
WAITING2
WAITING3
WAITING4
ACTION_extension1
ACTION_extension2
ACTION_extension3
ACTION_extension4
ACTION_proper1
ACTION_proper2
ACTION_proper3
ACTION_proper4
ACTION_retraction1
ACTION_retraction2
ACTION_retraction3
ACTION_retraction4
MOVING1 MOVING2
MOVING3 MOVING4
WAITING_UNLOAD_PRESS
MOVING_TO_MIDDLE_PRESS
WAITING_LOAD_PRESS
MOVING_TO_UPPER_PRESS
CLOSED_PRESS
MOVING_TO_LOWER_PRESS
DB_NORMAL DB_CRITICAL
DB_STOPPED WAITING_DB
UNLOADING_DBa
174
Production Cell Section A.3
UNLOADING_DBb
MOVING_FB
WAITING_FB
LOADING_FBa
LOADING_FBb
MOVING_DBa
MOVING_DBb
endblock
(*-----------------------------------------------------------------*)
A.3.2 The Environment Model
When modelling the behaviour of the environment, we add the following transition
rule to the system model. Additionally, we have to change the external functions
into dynamic functions. In order to express that a mechanical device should halt in
a position for at least one step, we also introduce three status functions (see below).
(*---------------------------------------------------------------*)
datatype AngleStatus == { arm1stoppedattable, arm2stoppedatpress,
arm2stoppedatbelt, arm1stoppedatpress }
datatype PressStatus == { pressattop, pressatmid, pressatbot }
datatype GripperStatus == { gripperstoppedat_ovb, gripperstoppedat_ovf,
gripperstoppedat_sd}
dynamic function angle_status : AngleStatus
dynamic function press_status : PressStatus
dynamic function gripper_status : GripperStatus
(*-------------------------------------------------*)
transition environment ==
block
if (FeedBeltMot=on) and not(FeedBeltFree) and not(Delivering)
then
PieceInFeedBeltLightBarrier := true
else if (FeedBeltMot=on) and Delivering
then
PieceInFeedBeltLightBarrier := false
endif
endif
(*--------------------------------------*)
if (TableElevationMot=up)
then
TopPosition := true
BottomPosition := false
else if (TableElevationMot=down)
then
TopPosition := false
BottomPosition := true
endif
endif
(*--------------------------------------*)
175
Chapter A Appendix
if (TableRotationMot=clockwise)
then
MaxRotation := true
MinRotation := false
else if (TableRotationMot=counterClockwise)
then
MaxRotation := false
MinRotation := true
endif
endif
(*--------------------------------------*)
if (Arm1Mot=extending) and (Angle=Arm1ToTable)
then
Arm1Ext := OverTable
else if (Arm1Mot=extending) and (Angle=Arm1ToPress)
then
Arm1Ext := Arm1IntoPress
else if (Arm1Mot=retract)
then
Arm1Ext := retracted
endif
endif
endif
(*--------------------------------------*)
if (Arm2Mot=extending) and (Angle=Arm2ToPress)
then
Arm2Ext := Arm2IntoPress
else if (Arm2Mot=extending) and (Angle=Arm2ToDeptBelt)
then
Arm2Ext := OverDepBelt
else if (Arm2Mot=retract)
then
Arm2Ext := retracted
endif
endif
endif
(*--------------------------------------*)
if (Angle=arm1totable) and (RobotRotationMot=idle2)
then
angle_status := arm1stoppedattable
endif
if (Angle=Arm2ToPress) and (RobotRotationMot=idle2)
then
angle_status := arm2stoppedatpress
endif
if (Angle=Arm2ToDepBelt) and (RobotRotationMot=idle2)
then
angle_status := arm2stoppedatbelt
endif
if (Angle=Arm1ToPress) and (RobotRotationMot=idle2)
then
176
Production Cell Section A.3
angle_status := arm1stoppedatpress
endif
(*--------------------------------------*)
if (Angle=Arm1ToTable) and (RobotRotationMot=counterClockwise)
and (angle_status=arm1stoppedattable)
then
Angle := Arm2ToPress
endif
if (Angle=Arm2ToPress) and (RobotRotationMot=counterClockwise)
and (angle_status=arm2stoppedatpress)
then
Angle := Arm2ToDepBelt
endif
if (Angle=Arm2ToDepBelt) and (RobotRotationMot=counterClockwise)
and (angle_status=arm2stoppedatbelt)
then
Angle := Arm1ToPress
endif
if (Angle=Arm1ToPress) and (RobotRotationMot=clockwise)
and (angle_status=arm1stoppedatpress)
then
Angle := Arm1ToTable
endif
(*--------------------------------------*)
if (PressMot=idle)
then if (TopPositionPress=true)
then
press_status := pressattop
if (PressLoaded=true)
then
ForgingComplete := true
endif
else if (MiddlePositionPress=true)
then
press_status := pressatmid
else if (BottomPositionPress=true)
then
press_status := pressatbot
endif
endif
endif
endif
if (PressLoaded=false)
then
ForgingComplete := false
endif
(*--------------------------------------*)
if (TopPositionPress=true) and (PressMot=down)
then
TopPositionPress := false
177
Chapter A Appendix
BottomPositionPress := true
endif
if (MiddlePositionPress=true) and (PressMot=up)
and (press_status=pressatmid)
then
TopPositionPress := true
MiddlePositionPress := false
endif
if (BottomPositionPress=true) and (PressMot=up)
then
MiddlePositionPress := true
BottomPositionPress := false
endif
(*--------------------------------------*)
if (DepBeltMot=run)
then if (DepositBeltReadyForLoading=false)
and (PieceInDepositBeltLightBarrier=false)
then
PieceInDepositBeltLightBarrier := true
else if (Critical=true)
and (PieceInDepositBeltLightBarrier=true)
then
PieceInDepositBeltLightBarrier := false
endif
endif
endif
(*--------------------------------------*)
if (CraneHorizontalMot=toDepBelt)
then
GripperOverDepBelt := true
GripperOverFeedBelt := false
endif
if (CraneHorizontalMot=toFeedBelt)
then
GripperOverDepBelt := false
GripperOverFeedBelt := true
endif
(*--------------------------------------*)
if (CraneVerticalMot=idle)
then if (GripperVerticalPos=OnDepositBelt)
then
gripper_status := gripperstoppedat_ovb
else if (GripperVerticalPos=OnFeedBelt)
then
gripper_status := gripperstoppedat_ovf
else if (GripperVerticalPos=SafeDistanceFromFeedBelt)
then
gripper_status := gripperstoppedat_sd
endif
endif
endif
178
Production Cell Section A.3
endif
(*--------------------------------------*)
if (GripperVerticalPos=OnFeedBelt) and (CraneVerticalMot=up)
and (gripper_status=gripperstoppedat_ovb)
then
GripperVerticalPos := SafeDistanceFromFeedBelt
endif
if (GripperVerticalPos=SafeDistanceFromFeedBelt)
and (CraneVerticalMot=down)
and (gripper_status=gripperstoppedat_sd)
then
GripperVerticalPos := OnFeedBelt
endif
if (GripperVerticalPos=OnFeedBelt) and (CraneVerticalMot=down)
and (gripper_status=gripperstoppedat_ovf)
then
GripperVerticalPos := OnDepositBelt
endif
if (GripperVerticalPos=OnDepositBelt) and (CraneVerticalMot=up)
and (gripper_status=gripperstoppedat_ovf)
then
GripperVerticalPos := SafeDistanceFromFeedBelt
endif
endblock
(*---------------------------------------------------------------*)
A.3.3 The Safety Requirements
The safety requirements of the Production Cell are given as properties of its com-
ponents, but the simplicity of the system allows us to check the system as a whole.
We specify each property as a single formula and form the conjunction of this set
of formulas in order to get the requirement specification. The formalisation of the
requirements in CTL is given in the following.
Safety of the Feed Belt The safety of the feed belt requires, that the feed belt
does not put metal blanks on the table if the latter is already loaded or not stopped
in load position.
We express this property in terms of the abstract ASM model as follows: The
module FeedBelt is not in the critical section unless the table is ready for loading.
The critical section is when the motor of the feed belt is running and the boolean
variable Delivering is true, and no blank is in the light barrier section of the belt
anymore (since the blank is being moved from the belt to the table). This is specified
by a conjunction of three conditions on state variables:
FeedBeltMot =on ∧Delivering =true
∧¬PieceInF eedBeltLightBarrier
The macro TableReadyForLoading in the abstract model substitutes a combined
condition as follows: the table is not loaded (¬TableLoaded), the table is in bot-
tom position (BottomPosition), the rotation of the table is at its minimal position
(MinRotation), and the elevation motor and the rotation motor of the table are
179
Chapter A Appendix
idle (TableElevationMot =idle,T ableRotationMot =idle). Therefore, the for-
malisation of the feed belt safety property has the following form:
AG (FeedBeltMot =on ∧Delivering =true
∧¬PieceInFeedBeltLightBarrier
⇒¬TableLoaded ∧BottomPosition ∧MinRotation ∧
TableElevationMot=idle ∧T ableRotationMot =idle)
Safety of the Elevating Rotary Table The safety property of the table pos-
tulates that the table never moves over its bounds. These bounds are represented
by the top and the bottom positions, and by the minimal and maximal rotation.
This property can be modelled as a conjunction of the requirements that none
of the four bounds is crossed. In the model of the cell, however, the fact that the
table has reached a bound and the motor is on is a guard in the transition rule
for switching the motor off. Therefore, we can only require that whenever a bound
is reached the motor should be switched off in the following state. It should be
pointed out that, for the real-life system, the sensor indicating that a bound is
reached should react soon enough to assure safety for the table.
The following CTL formula models the safety requirement for the table.
AG (TopPosition ⇒AX (TableElevationMot6=up))
∧AG (BottomPosition ⇒AX (TableElevationMot6=down))
∧AG (MaxRotation ⇒AX (T ableRotationMot 6=clockwise))
∧AG (MinRotation ⇒AX (T ableRotationMot 6=counterClockwise))
Safety of the Robot The safety property of the robot is split into several sub-
requirements, so we acquire a conjunct of several CTL sub-formula.
1. The robot never rotates over its bounds.
Similar to the requirements of the table, we have to determine what the crit-
ical bounds are and which kind of motor behaviour should be considered.
The rotation bounds are determined by the angle. The rightmost position is
Arm1ToPress; if this position is reached the rotation motor should not rotate
counterclockwise anymore. The leftmost value is Arm1ToTable;inordernot
to cross this boundary the rotation motor should stop rotating clockwise.
AG (angle =Arm1ToPress⇒AX (RobotRotationMot 6=counterClockwise))
∧AG (angle =Arm1ToTable⇒AX (RobotRotationMot 6=clockwise))
2. The robot never crashes with the press.
A crash with the press can be caused if either one of the robot arm motors
or the rotation motor of the robot is running. In the former case, we have to
ensure that, in the unloading phase, the press is in the right position (unload-
ing position); similarly we have to ensure that, in the loading phase, the press
has to be in load position.
For unloading the press, arm 2is used and for loading the press, arm 1.That
is, the motor Arm2Mot or Arm1Mot respectively, is extending and the angle
of the robot has the right value. The unload position (load position) of the
press is satisfied if the rotation motor of the robot and the motor of the press
are both idle, the press is loaded (not loaded), and the press has reached the
180
Production Cell Section A.3
bottom position (middle position). The two cases are conjoined:
AG (Arm1Mot =extend ∧Angle =Arm1ToPress
⇒RobotRotationMot =idle ∧PressMot =idle
∧¬P ressLoaded ∧MiddlePositionPress)
∧AG (Arm2Mot =extend ∧Angle =Arm2ToPress
⇒RobotRotationMot =idle ∧PressMot =idle
∧PressLoaded ∧BottomPositionPress)
If the rotation motor works, we have to assure that the arms are retracted.
Otherwise, the arms might be pushed into the press. The geometry of the
production cell yields the following formula:
AG (Angle =Arm2ToDepBelt ∧RobotRotationMot =clockwise
⇒Arm2Ext =retracted)
∧AG (Angle =Arm1ToTable ∧RobotRotationMot =counterClockwise
⇒Arm2Ext =retracted)
∧AG (Angle =Arm2ToDepBelt ∧RobotRotationMot =counterClockwise
⇒Arm1Ext =retracted)
3. The loaded first arm (arm 1) is never moved over the loaded table if the latter
is in unload position.
That is, whenever the table is in its unload position, arm 1, responsible for
loading, is not moving towards the table. The table is in unload position if it
is in the top position and is maximally rotated. Additionally, we have to state
that it is loaded. The fact that arm 1is loaded is described in terms of the
angle of the robot, the motion of arm 1’s extending motor and the magnet of
arm 1.arm 1is moved to the table if the external function Angle has the value
Arm1ToTable, and the motor is extending arm 1. Furthermore, the arm is
loaded if the magnet is on. We get the following CTL-formula:
AG (TopPosition ∧MaxRotation ∧TableLoaded
⇒¬(Angle =Arm1ToTable ∧Arm1Mot =extend
∧Arm1Magnet =on)
4. The loaded second arm (arm 2) is never moved over the loaded deposit belt.
Similar to the last property, we use the same arguments: whenever the
depositbeltisloaded,arm 2, responsible for loading the belt, should
not be moved to it. The deposit belt is loaded if the state variable
DepositBeltReadyF orLoading is false. To describe the motion of arm 2,we
have to consider the angle of the robot, the behaviour of arm 2’s extending
motor, and the magnet of arm 2.arm 2is moved to the belt if the external
function Angle has the value Arm2ToDepBelt, and the motor is extending
arm 2. We model that the arm is loaded by the magnet of the arm being on.
We get the following formula:
AG (¬DepositBeltReadyForLoading
⇒¬(Angle =Arm2ToDepBelt ∧Arm2Mot =extend
Arm2Mag =on))
5. The robot never drops pieces outside safe areas.
That is, pieces should only be dropped when the arm is in a safe area: arm 1
should put every piece that it grabbed into the press, arm 2should deposit the
pieces on the belt. Consequently, we distinguish two cases: whenever arm 1
181
Chapter A Appendix
drops a piece, it has be in the press and whenever arm 2drops a piece, it has
to be over the belt.
Dropping a piece is modelled through the magnet of an arm: if the magnet
is on, and in the next state the magnet is off then the piece is dropped. It
is sufficient to express the existence of such a next state using the existential
quantifier for paths E.
arm 1is in the press if its extension is appropriate and the angle of rotation
has the right value. Similarly, we can express that arm 2is over the deposit
belt. The following formula models the requirements:
AG (Arm1Mag =on ∧(EX Arm1Mag =off )
⇒Arm1Ext =Arm1IntoPress ∧Angle =Arm1ToPress)
and
AG (Arm2Mag =on ∧(EX Arm2Mag =off )
⇒Arm2Ext =OverDepBelt ∧Angle =Arm2ToDepBelt)
6. A new blank will be put on the deposit belt only if there is enough space on the
belt itself.
arm 2puts a new blank on the belt if it is in the right position (right extension
and right angle of the robot) and there is a next state where the magnet of
arm 2is switched off. Moreover, there is enough space on the belt if the belt
is ready for loading.
AG (Arm2Mag =on ∧Angle =Arm2ToDepBelt
∧Arm2Ext =OverDepBelt ∧(EX Arm2Mag =off )
⇒DepositBeltReadyF orLoading)
7. The robot doesn’t put blanks on the press if it is already loaded.
The press is already loaded if the variable PressLoaded is true. Whenever
arm 1is in the right position (i.e.,Angle equals Arm1IntoPress and arm 1is
extended) and its magnet is on, a blank is put into the press if in a next
state (at least one possible next state) the magnet switches off. We get the
following implication:
AG (Arm1Mag =on ∧Angle =Arm1ToPress
∧Arm1Ext =Arm1IntoPress ∧(EX Arm1Mag =off )
⇒¬P ressLoaded)
Safety of the Press The safety requirements for the press consist of the following
two points:
1. The press is not moved downward if it is in the bottom position; it is not
moved upward if it is in the top position
This is easily described using the state variables that model the motion of the
press motor and the oracle functions for the position of the press: if the bottom
position is reached, the press motor should not move downward; similarly, if
the top position is reached, the press motor should not move upward.
We have to bear in mind that the condition of reaching the top or bottom
position is also a condition for switching the motor to idle. Therefore, we
profit by the next step quantification of CTL stipulating that whenever the
182
Production Cell Section A.3
boundary is reached in all possible next states, the motor should not move the
press in this direction1.Weget:
AG (bottomPositionPress ⇒AX (PressMot 6=down))
∧AG (topPositionPress ⇒AX (PressMot 6=up))
2. The press only closes when there is no robot arm inside it.
The press is closing when the motor is running up. In this case, neither arm 1
nor arm 2should ever be in the press. In terms of the ASM press model, the
arms are in the press if the angle has the value Arm1ToPress or Arm2ToPress
and the arm is completely extended. This leads to the following formula:
AG (PressMot =up
⇒¬(Arm1Ext =Arm1IntoPress ∧Angle =Arm1ToPress)
∧¬(Arm2Ext =Arm2IntoPress ∧Angle =Arm2ToPress))
Safety of the Deposit Belt For the safety of the deposit belt it suffices to show
that the deposit belt is stopped when a blank reaches the end section of the belt itself
and is not re-started until the travelling crane has picked up the piece.
Whenever a piece reaches the end of the deposit belt, the deposit belt motor
should stop running. This must happen in every next state2. For this we get the
formula:
AG (PieceAtDepBeltEnd ⇒AX (DepBeltMot =idle))
Safety of the Travelling Crane To show the safety of the travelling crane we
have to state four safety properties.
1. The gripper always remains between the two (un)loading positions over the
feed belt (loading position) and over the deposit belt (unloading position).
To express this safe behaviour of the crane, we regard the horizontal movement
of the mechanics. Whenever the boundary of horizontal position is reached the
CraneHorizontalMot should stop or move the gripper in the other direction.
The boundaries are modelled by GripperOverFeedBelt and GripperOverDep-
Belt. We require that, when at these boundaries, in every possible next state,
the horizontal motor does not move toFeedBelt and toDepBelt respectively.
We get
AG (GripperOverFeedBelt
⇒AX (CraneHorizontalMot 6=toFeedBelt))
and
AG (GripperOverDepBelt
⇒AX (CraneHorizontalMot 6=toDepBelt))
2. The gripper never crashes with the belts or the fixed part of the travelling
crane.
Now we consider the vertical motion of the mechanics. Whenever a vertical
boundary is reached, the motor should stop or move in the other direction in
all reachable next states. We get four cases:
1In the real-life system, we have to require that the boundary be set with a sufficient margin
in order to be able to stop the motor at a safe distance to prevent a collision.
2Again, in the real-life system, we have to require that the boundary be set with a sufficient
margin in order to be able to stop the motor at a safe distance to prevent a collision.
183
Chapter A Appendix
•If the gripper’s vertical position is a safe distance from the feed belt, then
the motor should not move up in order not to push the gripper against
the crane.
AG (GripperV erticalPos =SafeDistanceFromFeedBelt
⇒AX (CraneV erticalMot 6=up))
•If the gripper’s vertical position is OnDepositBelt which is the lowest
vertical position that is allowed then the crane should not move down
any more.
AG (GripperV erticalPos =OnDepositBelt
⇒AX (CraneV erticalMot 6=down))
•If the gripper is over the feed belt then its lowest vertical position should
be OnFeedBelt.
AG (GripperV erticalPos =OnFeedBelt ∧GripperOverFeedBelt
⇒AX (CraneV erticalMot 6=down))
•If the vertical position is at its lowest point (i.e. OnDepositBelt)the
horizontal motor should be idle in order to avoid pushing the gripper
against the belt3.
AG (GripperV erticalPos =OnDepositBelt
⇒CraneHorizontalMot =idle)
3. Thecranedoesnotdroppiecesoutsidethesafeareaoverthefeedbelt.
The crane magnet drops a piece if it is on in a state and off in a next state.
So we claim, if the magnet is on (i.e., gripper holds a piece) and the gripper
is not in the right position (i.e., not over the feed belt with the right vertical
position) then the magnet should not be switched off in the next state.
AG (CraneMagnet =on
∧¬(GripperOverFeedBelt ∧GripperV erticalP os =OnF eedBelt)
⇒AX (CraneMagnet 6=off ))
4. A new blank is put on the feed belt only if there is enough space on the latter
to deposit the blank safely.
To put a piece on the feed belt requires that the gripper is in the right position
(vertically and horizontally) and the magnet is on. Furthermore, the ASM
transition rule requires in its guard that the crane’s vertical motor is moving
down. If this is the case then the feed belt has to be free (i.e., FeedBeltFree is
true).
AG (GripperOverFeedBelt ∧GripperV erticalP os =OnFeedBelt
∧CraneV erticalMot =down ∧CraneMagnet =on
⇒FeedBeltFree)
The behaviour of the external functions (modelling the sensor values) which
determine the behaviour of the modules has to be specified to reflect a reasonable
system environment.
The model checker concluded that the conjunction of all safety formulas is
satisfied by the SMV model of the Production Cell. The output shows the resources
3Since this condition is not a guard for stopping the horizontal motor, we can require this for
the same state instead of all next states.
184
Production Cell Section A.3
used:
resources used:
user time: 3.8 s, system time: 1.03333 s
BDD nodes allocated: 43529
Bytes allocated: 18087936
BDD nodes representing transition relation: 25718 + 1
A.3.4 The Liveness Requirements
Treating a blank is described in an abstract manner: e.g., a blank is transported by
the feed belt if the feed belt changes from NormalRun to CriticalRun. We formalise
the progress by means of CTL formulas of the following form
AG (action executable ⇒AF (next action executable))
Following the semantics of CTL, this is satisfied if it is always (in every path in
every state) the case that once action is executable then eventually next action
will be executable. We consider all pairs of actions and their successor actions, that
are relevant to get the closed sequence of steps for the whole process, and get a set
of CTL-formulas of the form discussed above. The liveness property is considered
to be the conjunction of all progress formulas.
We suggest the following action/next action pairs with their respective formulas:
•Whenever FeedBelt is in NormalRun then eventually FeedBelt will reach
CriticalRun (in the concrete model NormalRun and CriticalRun are
introduced as macros whose expansions we use below):
AG ((FeedBeltMot =on ∧¬Delivering)
⇒AF (FeedBeltMot =on ∧Delivering))
•whenever FeedBelt is in CriticalRun then eventually Table will be stopped
in load position:
AG ((FeedBeltMot =on ∧Delivering)
⇒AF (BottomPosition ∧MinRotation ∧
TableElevationMot=idle ∧T ableRotationMot =idle))
•whenever Table is stopped in load position then eventually Table will be
stopped in unload position:
AG ((BottomPosition ∧MinRotation ∧
TableElevationMot=idle ∧T ableRotationMot =idle)
⇒AF (TopPosition ∧MaxRotation ∧
TableElevationMot=idle ∧T ableRotationMot =idle))
•whenever Table is stopped in unload position then eventually Robot will un-
load the table; unloading the table is executed when Arm1Mag is switched to
on, therefore, we use the guard of the respective transition rule as a condition
for execution:
AG ((TopPosition ∧MaxRotation ∧
TableElevationMot=idle ∧T ableRotationMot =idle)
⇒AF (Angle =Arm1ToTable ∧Arm1Mot =extend
∧Arm1Ext =OverTable))
185
Chapter A Appendix
•whenever Robot has unloaded the table then eventually Robot will load the
press; as above we we use the guard of the transition rule that has the effect
that Arm1Mag is switched off :
AG ((Angle =Arm1ToTable ∧Arm1Mot =extend
∧Arm1Ext =OverTable)
⇒AF (Angle =Arm1ToPress ∧Arm1Mot =extend
∧Arm1Ext =Arm1IntoPress))
•whenever Robot has loaded the press then eventually Press will be
OpenForLoading;OpenForLoading is defined to be a macros, here we use
the macro definition4:
AG ((Angle =Arm1ToPress ∧Arm1Mot =extend
∧Arm1Ext =Arm1IntoPress)
⇒AF (MiddlePositionPress ∧PressMot =idle))
•whenever Press is OpenForLoading then eventually Press will be
ClosedF orF orging;ClosedForF orging is defined as a macro, we unfold the
definition:
AG ((MiddlePositionPress ∧PressMot =idle)
⇒AF (TopPositionPress ∧PressMot =idle))
•whenever Press is ClosedForForging then eventually Press will be
OpenForUnloading:
AG ((TopPositionPress ∧PressMot =idle)
⇒AF (BottomPositionPress ∧PressMot =idle))
•whenever Press is OpenForUnloading then eventually Robot will unload the
press; the press is unloaded if Arm2Mag is switched to on, we consider the
guard of the respective transition rule;
AG ((BottomPositionPress ∧PressMot =idle)
⇒AF (Angle =Arm2ToPress ∧Arm2Mot =extend
∧Arm2Ext =Arm2IntoPress))
•whenever Robot has unloaded the press then eventually Robot will unload
the DepositBelt; the DepositBelt is unloaded if Arm2Mag is switched to off ,
again we consider the guard of the respective transition rule;
AG ((Angle =Arm2ToPress ∧Arm2Mot =extend
∧Arm2Ext =Arm2IntoPress)
⇒AF (Angle =Arm2ToDepBelt ∧Arm2Mot =extend
∧Arm2Ext =OverDepBelt))
•whenever Robot has unloaded the DepositBelt then eventually DepositBelt
will be in NormalRun (which is defined to be a macro):
AG ((Angle =Arm2ToDepBelt ∧Arm2Mot =extend
∧Arm2Ext =OverDepBelt)
⇒AF (DepBeltMot =run ∧¬Critical))
4In the following, we change the identifiers for the press position in order to distinguish them
from the variables for the position of the table.
186
Production Cell Section A.3
•whenever DepositBelt is in NormalRun then eventually DepositBelt will be
in CriticalRun (which is defined to be a macro as well):
AG ((DepBeltMot =run ∧¬Critical)
⇒AF (DepBeltMot =run ∧Critical))
•whenever DepositBelt is in CriticalRun then eventually Crane will unload
the DepositBelt; the DepositBelt is unloaded if CraneMagnet is switched to
on, we regard the respective transition condition:
AG ((DepBeltMot =run ∧Critical)
⇒AF (GripperOverDepositBelt
∧GripperV erticalPos =OnDepositBelt
∧CraneHorizontalMot =idle ∧CraneV erticalMot =idle
∧CraneMagnet =off ))
•whenever Crane has unloaded the DepositBelt then eventually the Crane will
load the FeedBelt; the FeedBelt is loaded when the CraneMagnet is switched
to off , we regard the respective transition condition:
AG ((GripperOverDepositBelt ∧GripperV erticalPos =OnDepositBelt
∧CraneHorizontalMot =idle ∧CraneV erticalMot =idle
∧CraneMagnet =off )
⇒AF (CraneV erticalMot =down
∧GripperV erticalPos =OnFeedBelt ∧GripperOverFeedBelt))
•whenever the Crane has loaded the FeedBelt then eventually FeedBelt will
be in NormalRun;
AG ((CraneV erticalMot =down
∧GripperV erticalPos =OnFeedBelt ∧GripperOverFeedBelt)
⇒AF (FeedBeltMot =on ∧¬Delivering))
Results for the Liveness Property We checked the requirement specification,
as it is shown above, against the concrete model of the Production Cell. As a result
we found that the system satisfies the property if (and only if) the initial condition
is changed5. This is due to the fact, that the system is optimised in such a way
that the robot can act only if at least two blanks are in the system: one to take out
of the press and an another to be loaded into the press. We change the following
initial values:
variable old initial value new initial value
PressLoaded false true
Arm1Mag off on
Angle Arm1ToTable Arm2ToPress
Also we take as an additional condition that initially the variable
PieceInDepBeltLightBarrier is false.
Moreover, the system environment and its behaviour must be modelled. Oth-
erwise, the result will be a failure where the given counterexample is an irrelevant
case.
5As Mearelli ([Mea96]) remarked, the initial condition chosen in his thesis is not suitable to
start a simulation of a run. Therefore, the liveness property will fail in the initial state!
187
Chapter A Appendix
With respect of the changes listed above, we get the output
resources used:
user time: 10.1333 s, system time: 0.95 s
BDD nodes allocated: 56832
Bytes allocated: 18350080
BDD nodes representing transition relation: 25718 + 1
We conclude that the system model with respect to the modelled assumptions
satisfies the liveness property as it was claimed in the setting of task.
188
Bibliography
[BAMP81] M. Ben-Ari, Z. Manna, and A. Pnueli. The temporal logic of branching
time. In Proc. of 8th Annual Symposium on Principles of Programming
Languages, 1981.
[BCL91] J. Burch, E. Clarke, and D. Long. Symbolic model checking with par-
titioned transition relations. In Int. Conf. on Very Large Scale Integra-
tion, 1991.
[BCL+94] J. Burch, E. Clarke, D. Long, K. McMillan, and D. Dill. Symbolic
model checking for sequential circuit verification. IEEE Transactions on
Computer Aided Design of Integrated Circuits and Systems, 13(4):401–
424, April 1994.
[BCM+92] J.R. Burch, E.M. Clarke, K.L. McMillan, D.L. Dill, and L.J. Hwang.
Symbolic model checking 1020 states and beyond. Information and
Computation, 98(2):142–170, June 1992.
[BCMD90] J. Burch, E. Clarke, K. McMillan, and D. Dill. Sequential circuits
verification using symbolic model checking. In Proc. of 27th ASM/IEEE
Design Autiomation Conference, 1990.
[BD94] J. Burch and D. Dill. Automatic verification of pipelined microprocessor
control. In D.L. Dill, editor, Proc. of Int. Conf. on Computer Aided Ver-
ification, CAV’94, volume 818 of LNCS, pages 68–80. Springer-Verlag,
1994.
[Ber99] S. Berezin. Combining Model Checking and Theorem Proving in Har-
ware Verification. PhD thesis, Carnegie Mellon University, 1999.
[BGL+00] S. Bensalem, V. Ganesh, Y. Lakhneck, C. Munoz, S. Owre, H. Rueß,
J. Rushby, V. Rusu, H. Sa¨ıdi, N. Shankar, E. Singerman, and A. Tiwari.
An Overview of SAL. In Proc. of the Fifth Langley Formal Methods
Workshop, 2000.
[BGR94] E. B¨orger, Y. Gurevich, and D. Rosenzweig. The Bakery Algorithm:
Yet Another Specification and Verification. In E. B¨orger, editor, Spec-
ification and Validation Methods. Oxford University Press, 1994.
[BH99] R. Bharadwaj and C. Heitmeyer. Model checking complete require-
ments specifications using abstraction. Automated Software Engineer-
ing, 6(1):37–68, 1999.
[BM97] E. B¨orger and L. Mearelli. Integrating ASMs into the software develop-
ment life cycle. J.UCS Journal for Universal Computer Science (special
issue), 3(5):689–702, 1997.
189
BIBLIOGRAPHY
[B¨or95] E. B¨orger. Why Use Evolving Algebras for Hardware and Software
Engineering? In M. Bartosek, J. Staudek, and J. Wiederman, editors,
Proceedings of SOFSEM’95, 22nd Seminar on Current Trends in The-
ory and Practice of Informatics, volume 1012 of LNCS, pages 236–271.
Springer, 1995.
[B¨or99] E. B¨orger. High Level System Design and Analysis using Abstract
State Machines. In D. Hutter and W. Stephan and P. Traverso and
M. Ullmann, editor, Current Trends in Applied Formal Methods (FM-
Trends 98), volume 1641 of LNCS, pages 1–43. Springer-Verlag, 1999.
[Bry86] R. E. Bryant. Graph-based algorithms for boolean function manipula-
tion. IEEE Transactions On Computers, C-35(8), August 1986.
[BT98] S. Balakrishnan and S. Tahar. Modeling and Formal Verification
of a Commercial Microcontroller for Embedded System Applications.
In Proc. IEEE 10th International Conference on Microelectronics
(ICM’98), pages 107–110, 1998.
[Cas99] G. Del Castillo. Towards comprehensive tool support for Abstract State
Machines: The ASM Workbench tool environment and architecture. In
D. Hutter et al., editors, Current Trends in Applied Formal Methods
(FM-Trends 98), volume 1641 of LNCS, pages 311–325, 1999.
[Cas00] G. Del Castillo. The ASM Workbench. PhD thesis, Department of
Mathematics and Computer Science of Paderborn University, 2000.
[CCGR99] A. Cimatti, E. Clarke, F. Giunchiglia, and M. Roveri. NuSMV: A new
symbolic model verifier. In Proc. of Int. Conf. on Computer Aided
Verfication, CAV’99, volume 1633 of LNCS, pages 495–499. Springer-
Verlag, 1999.
[CCL+97] E. Cerny, F. Corella, M. Langevin, X. Song, S. Tahar, and Z. Zhou.
Automated verification with abstract state machines using Multiway
Decision Graphs. In T. Kropf, editor, Formal Hardware Verification:
Methods and Systems in Comparison, volume 1287 of LNCS, pages 79–
113. Springer Verlag, 1997.
[CD88] E. Clarke and I. A. Draghicescu. Expressibility results for linear-time
and branching-time logics. In J. W. de Bakker, editor, Linear Time,
Branching Time, and Partial Order in Logics and Models for Concur-
rency, volume 354 of LNCS, pages 428–437. Springer-Verlag, 1988.
[CGH94] E. Clarke, O. Grumberg, and K. Hamaguchi. Another Look at LTL
Model Checking. In D.L. Dill, editor, Proc.of6thInt.Conf.onCom-
puter Aided Verification, CAV’94, volume 818 of LNCS, pages 415–427.
Springer-Verlag, 1994.
[CGH97] E. Clarke, O. Grumberg, and H. Hamaguchi. Another Look at LTL
Model Checking. Formal Methods in System Design, 10(1), February
1997.
[CGL92] E. Clarke, O. Grumberg, and D. Long. Model-checking and abstraction.
In Proc. of the 19th ACM Symposium on Principles of Programming
Languages, pages 343–354. ACM Press, 1992.
[CGL94] E. Clarke, O. Grumberg, and D. Long. Verification tools for finite-
state concurrent systems. In A Decade of Concurrency - Reflections
and Perspectives, volume 803 of LNCS. Springer-Verlag, 1994.
190
BIBLIOGRAPHY
[CGP00] E. Clarke, O. Grumberg, and D. Peled. Model Checking. MIT Press,
2000.
[CH85] A. B. Cremers and T. N. Hibbard. VLSI and Modern Signal Processing,
chapter Executable Specification of Concurrent Algorithms in Terms of
Applicative Data Space Notation, pages 201–223. Prentice-Hall, 1985.
[CMP92] E. Chang, Z Manna, and A. Pnueli. The safety-progress classification.
Technical Report STAN-CS-92-1408, Department of Computer Science,
Stanford University, 1992.
[CN94] D Cyrluk and P. Narendran. Ground temporal logic: A logic for
hardware verification. In D. Dill, editor, Proc.ofInt.Conf.onCom-
puter Aided Verification, CAV’94, volume 818 of LNCS, pages 247–259.
Springer-Verlag, 1994.
[CW00] G. Del Castillo and K. Winter. Model checking support for the ASM
high-level language. In S. Graf and M. Schwartzbach, editors, Proc.
of 6th Int. Conference for Tools and Algorithms for the Construction
and Analysis of Systems, TACAS 2000, volume 1785 of LNCS, pages
331–346. Springer-Verlag, 2000.
[CZS+97] F. Corella, Z. Zhou, X. Song, M. Langevin, and E. Cerny. Multiway
Decision Graphs for automated hardware verification. Formal Methods
in System Design, 10(1), 1997.
[Day93] N. Day. A model checker for statecharts (linking case tools with formal
methods). Technical Report 93 - 35, Dep. of Computer Science, Univ.
of British Columbia, Vancouver, B.C., Canada, October 1993.
[DB98a] R. Drechsler and B. Becker. Binary Decision Diagrams. Kluwer Aca-
demic Publishers, 1998.
[DB98b] R. Drechsler and B. Becker. Graphenbasierte Funktionsdarstellung.
Teubner, 1998.
[Dur98] A. Durand. Modeling cache coherence protocol - a case study with
FLASH. In U. Gl¨asser and P. Schmitt, editors, Proc. of the 28th An-
nual Conference of the German Society of Computer Science, Technical
Report, Magdeburg University, Germany, 1998.
[EH86] E. Allen Emerson and Joseph Y. Halpern. “Sometimes” and “Not
Never” revisited: On branching versus linear time temporal logic. Jour-
nal of the ACM, 33(1):151–178, January 1986.
[Eme90] E. Allen Emerson. Temporal and modal logic. In J. van Leeuwen,
editor, Handbook of Theoretical Coomputer Science, volume B, pages
996–1072. Elsevier Science Publishers, Amsterdam, 1990.
[F+96] T. Filkorn et al. SVE Users’ Guide. Siemens AG, M¨unchen, 1996.
[FGM+92] J.-C. Fernandez, H. Garavel, L. Mounier, A. Rasse, C. Rodrguez, and
J. Sifakis. A toolbox for the verification of LOTOS programs. In Proc.
of the 14th Int. Conf. on Software Engineering, (ICSE’14), pages 246–
259. ACM, 1992.
[For96] Formal Systems (Europe) Ltd. Failure Divergence Refinement, FDR
2.0, User Manual, August 1996.
191
BIBLIOGRAPHY
[GB96] B. Grahlmann and E. Best. Pep – more than a petri net tool. In
T. Magaria and B. Steffen, editors, Proc. of the 2th Int. Conference for
Tools and Algorithms for the Construction and Analysis of Systems,
TACAS’96, volume 1055 of LNCS, pages 397–401. Springer-Verlag,
1996.
[GPVW95] Rob Gerth, Doron Peled, Moshe Y. Vardi, and Pierre Wolper. Simple
On-the-fly Automatic Verification of Linear Temporal Logic. In Proc. of
the 15th Work. Protocol Specification, Testing, and Verification,War-
saw, June 1995. North-Holland.
[GR97] M. Große-Rhode. Transition specifications for dynamic abstract data
types. Applied Categorical Structures, 5:265–308, 1997.
[GR01] A. Gargantini and E. Ricobene. ASM-based testing: Coverage crite-
ria and automatic tests generation. In Proc. of ASM Workshop 2001,
LNCS. Springer-Verlag, 2001. To appear.
[Gro96] The VIS Group. VIS: A System for Verification and Synthesis. In
R. Alur and T. Henzinger, editors, Proc. of the 8th Int. Conf. on Com-
puter Aided Verifaction, CAV’96, volume 1102 of LNCS, pages 428–432.
Springer-Verlag, 1996.
[GS97] S. Graf and H. Sa¨ıdi. Construction of abstract state graphs with PVS.
In O. Grumberg, editor, Proc. of Int. Conf. on Computer Aided Veri-
fication, CAV’97, volume 1254 of LNCS, pages 72–83. Springer-Verlag,
1997.
[Gur95] Y. Gurevich. Evolving Algebras 1993: Lipari Guide. In E. B¨orger,
editor, Specification and Validation Methods. Oxford University Press,
1995.
[Gur97] Y. Gurevich. May 1997 Draft of the ASM Guide. Technical report,
University of Michigan EECS Department, 1997.
[HDB97] R. Hojati, D. Dill, and R. Brayton. Verifying linear temporal properties
of data insensitive controllers using finite instantiations. In Proc.ofInt.
Conf. on Hardware Description Languages, CHDL’97, IFIP, pages 60–
73. Chapman & Hall, 1997.
[Hei95] M. Heinrich. The FLASH protocol - version: 1.4. Technical report,
Stanford University FLASH Group, 1995.
[HGD95] H. Hungar, O. Grumberg, and W. Damm. What if model checking must
be truly symbolic? In E. Brinksma, editor, Workshop on Tools and
Algorithms for the Construction and Analysis of Systems, TACAS’95,
volume 1019 of LNCS. Springer-Verlag, 1995.
[HHK96] R.H. Hardin, Z. Har’El, and R.P. Kurshan. COSPAN. In T. Henzinger
R. Alur, editor, Proc. of the 8th Int. Conf. on Computer Aided Verifac-
tion, CAV’96, volume 1102 of LNCS, pages 423–427. Springer-Verlag,
1996.
[Hol97] Gerard J. Holzmann. The SPIN Model Checker. IEEE Transactions
on Software Engineering, 23(5):279–295, May 1997.
[HS95] K. Havelund and N. Shankar. Experiments in theorem proving and
model checking for protocol verification. Technical report, SRI Inter-
national Menlo Park, USA, 1995.
192
BIBLIOGRAPHY
[Hug] J.K. Huggins. Abstract state machines home page. EECS Department,
University of Michigan. http://www.eecs.umich.edu/gasm/.
[KOH+94] J. Kuskin, D. Ofelt, M. Heinrich, J. Heinlein, R. Simoni, K. Ghara-
chorloo, J. Chapin, D. Nakahira, J. Baxter, M. Horowitz, A. Gupta,
M. Rosenblum, and J. Hennessy. The stanford FLASH multiprocessor.
In 21th Int. Symp. on Computer Architecture, Computer Archtiecture
News, pages 302–312, 1994.
[Kro98] T. Kropf. Hardware verifikation. Vorlesungsskript, WS 98/99, 1998.
[KW97] E. Kindler and R. Walter. Mutex needs fairness. Information Processing
Letters, 62, 1997.
[Lam80] Leslie Lamport. “Sometimes” is sometimes “Not Never”. In Proc.ofthe
7th Annual ACM Symposium on Principles of Programming Languages,
pages 174–185. ACM, 1980.
[LEW96] J. Loeckx, H.-D. Ehrich, and M. Wolf. Specifiaction of Abstract Data
Types. Wiley, Teubner, 1996.
[LGS+95] C. Loiseaux, S. Graf, J. Sifakis, A. Bouajjani, and S. Bensalem. Prop-
erty preserving abstractions for the verification of concurrent systems.
Formal Methods in System Design, 6(1), 1995.
[LL95] C. Lewerentz and T. Lindner. Formal Developement Of Reactive Sys-
tems. Case Study “Production Cell”, volume 891 of LNCS. Springer-
Verlag, 1995.
[Lon93] David E. Long. Model Checking, Abstraction and Compositional Veri-
fication. PhD thesis, Carnegie Mellon University, 1993.
[LP85] O. Lichtenstein and A. Pnueli. Checking that finite state concurrent
programs satisfy their linear specification. In Proc. of the 12th Annual
ACM Symposium on Principles of Programming Languages. ACM, New
York, January 1985.
[LR98] P. Liggesmeyer and M. Rothfelder. Towards automated proof of fail-safe
behavior. In W. Ehrenberger, editor, Proc.ofInt.Conf.onComputer
Safety, Reliablity and Security, SAFECOMP’98, volume 1516 of LNCS,
pages 169–184. Springer-Verlag, 1998.
[LTZ+96] M. Langevin, S. Tahar, Z. Zhou, X. Song, and E. Cerny. Behavioral
verification of an ATM switch fabric using implicit abstract state enu-
meration. In Proc. of IEEE Int. Conf. on Computer Design (ICCD’96),
pages 20–26. IEEE Computer Society Press, 1996.
[McM93] K. McMillan. Symbolic Model Checking. Kluwer Academic Publishers,
1993.
[Mea96] L. Mearelli. An Evolving Algebra Model Of The Production Cell. Mas-
ter’s thesis, Universita di Pisa, 1996.
[Mil] K. Mc Millan. Ken McMillan’s home page at UCB. http://www-
cad.eecs.berkeley.edu/∼kenmcmil.
193
BIBLIOGRAPHY
[MMP98] A. Merceron, M. M¨ullerburg, and G.M. Pinna. Verifying a time-
triggered protocol in a multi-language environment. In W. Ehrenberger,
editor, Proc. of Int. Conf. on Computer Safety, Reliablity and Secu-
rity, SAFECOMP’98, volume 1516 of LNCS, pages 185–195. Springer-
Verlag, 1998.
[Mor94] C. Morgan. Programming from Specifications. Prentice Hall, 1994.
[MS] Faron Moller and Perdita Stevens. Edinburgh Concur-
rency Workbench user manual (version 7.1). Available from
http://www.dcs.ed.ac.uk/home/cwb/.
[MSC97] O. Ait Mohamed, X. Song, and E. Cerny. On the Non-Termination
of MDG-based abstract state enumeration. In Proc. of the IFIP Ad-
vanced Research Working Conference on Correct Hardware Design and
Verification Methods (Charme’97), pages 218–235, 1997.
[ORS92] S. Owre, J.M. Rushby, and N. Shankar. PVS: A prototype verification
system. In D. Kapur, editor, Proc. of Int. Conf. on Automated Deduc-
tion, CADE 11, volume 607 of LNAI, pages 748–752. Springer-Verlag,
1992.
[Plo00] C. Plonka. Model checking for the design with abstract state machines.
Master’s thesis, University of Ulm, Department of Applied Information
Processing, 2000.
[Ros94] A. W. Roscoe. Model-Checking CSP. In A classical Mind, Essays in
Honour of C.A.R. Hoare. Prentice Hall, 1994.
[Sha00] N. Shankar. Symbolic Analysis of Transition Systems. In Y. Gurevich,
P. Kutter, M. Odersky, and L. Thiele, editors, Abstract State Machines,
Theory and Applications, ASM 2000, volume 1912 of LNCS, pages 287–
302. Springer-Verlag, 2000.
[SMT01] M. Shirazipour, Y. Mokhtari, and S. Tahar. Model checking and refine-
ment of ASM models using SMV. Technical report, Concordia Univer-
sity, Faculty of Engineering and Computer Science, 2001.
[Spi99] M. Spielmann. Automatic verification of abstract state machines. In
N. Halbwachs and D. Peled, editors, Proc. of Int. Conf. on Computer
Aided Verification, CAV ’99, volume 1633 of LNCS, pages 431–442.
Springer-Verlag, 1999.
[SS99] H. Sa¨ıdi and N. Shankar. Abstract and model check while you prove.
In N. Halbwachs and D. Peled, editors, Proc.ofInt.Conf.onCom-
puter Aided Verification, CAV’99, volume 1633 of LNCS, pages 443–
453. Springer-Verlag, 1999.
[vL90] Jan van Leeuwen, editor. Formal Models and Semantics,volumeB.
Elsevier, 1990.
[VW86] M. Y. Vardi and P. Wolper. An automata-theoretic approach to au-
tomatic program verification. In Proc. of the First Annual Symposium
on Logic in Computer Science, pages 322–331. IEEE Computer Society
Press, 1986.
[Win97] K. Winter. Model Checking for Abstract State Machines. J.UCS Jour-
nal for Universal Computer Science (special issue), 3(5):689–702, 1997.
194
BIBLIOGRAPHY
[Win00] K. Winter. Towards a Methodology for Model Checking ASM: Lessons
learned from the FLASH Case Study. In Y. Gurevich, P. Kutter,
M. Odersky, and L. Thiele, editors, Abstract State Machines - Theory
and Applications, Int. Workshop ASM’2000, Selected papers,volume
1912 of LNCS, pages 341–360. Springer-Verlag, 2000.
[Win01] K. Winter. Model Checking ASM: the MDG approach. In Proc. of
ASM Workshop 2001, LNCS. Springer-Verlag, 2001. To appear.
[Wol81] P. Wolper. Temporal logic can be more expressive. In Proc.ofthe
22nd Annual Symposium on Foundations of Computer Sciences, pages
340–348. IEEE, 1981.
[Wol97] Pierre Wolper. The meaning of formal: from weak to strong formal
methods. Springer International Journal on Software Tools for Tech-
nology Transfer, 1(1-2):6–8, 1997.
[WVF97] Jeannette M. Wing and Mandana Vaziri-Farahani. A case study in
model checking software systems. Science of Computer Programming,
28:273–299, 1997.
[XCS+98] Y. Xu, E. Cerny, X. Song, F. Corella, and O. Ait Mohamed. Model
checking for a first-order temporal logic using Multiway Decision
Graphs. In Proc. of Int. Conf. on Computer Aided Verification
(CAV’98), volume 1427 of LNCS, pages 219–231. Springer-Verlag, 1998.
[Xu99] Y. Xu. Model Checking for a First-order Temporal Logic Using Multi-
way Decision Graphs. PhD thesis, University of Montreal, 1999.
[Zho96] Z. Zhou. MDG Tools (V1.0) Developer’s Manual.IROUniversityof
Montreal, Montreal, Canada, June 1996.
[ZSC+95] Z. Zhou, X. Song, F. Corella, E. Cerny, and M. Langevin. Partitioning
transition relations automatically and efficiently. In IEEE Proceedings
of Fifth Great Lakes Symposium on VLSI (GLSVLSI’95), March 1995.
[ZST+96] Z. Zhou, X. Song, S. Tahar, F. Corella E. Cerny, and M. Langevin.
Verification of the island tunnel controller using Multiway Decision
Graphs. In M. Srivas and A. Camilleri, editors, Proc.ofInt.Conf.
on Formal Methods in Computer-Aided Design (FMCAD’96),volume
1166 of LNCS, pages 233–246. Springer-Verlag, 1996.
195
