COMPUTER SCIENCE REVIEW

available at www.sciencedirect.com

journal homepage: www.elsevier.com/locate/cosrev

Survey

Linear Temporal Logic Symbolic Model Checking

Kristin Y. Rozier
NASA Ames Research Center, Moffett Field, CA 94035, USA

A R T I C L E

I N F O

A B S T R A C T

Article history:

We are seeing an increased push in the use of formal verification techniques in safety-

Received 11 February 2010

critical software and hardware in practice. Formal verification has been successfully used

Received in revised form

to verify systems such as air traffic control, airplane separation assurance, autopilot,

26 June 2010

CPU designs, life-support systems, medical equipment (such as devices which administer

Accepted 29 June 2010

radiation), and many other systems which ensure human safety. This survey provides a
perspective on the formal verification technique of linear temporal logic (LTL) symbolic

Keywords:

model checking, from its history and evolution leading up to the state-of-the-art. We unify

Linear Temporal Logic (LTL)

research from 1977 to 2009, providing a complete end-to-end analysis embracing a users

Symbolic Model Checking (SMC)

perspective by applying each step to a real-life aerospace example. We include an in-depth

Verification

examination of the algorithms underlying the symbolic model-checking procedure, show

Formal Methods

proofs of important theorems, and point to directions of ongoing research. The primary
focus is on model checking using LTL specifications, though other approaches are briefly
discussed and compared to using LTL.
Published by Elsevier Inc.

1.

Introduction

Verification of a software or hardware system involves

checking whether the system in question behaves as it
was designed to behave. Design Validation involves checking
whether a system design satisfies the system requirements.
(If it does not, it is desirable to find out early in the design
process!) Both of these tasks, system verification and design
validation, can be accomplished thoroughly and reliably
using formal methods, such as model checking. Model checking
is the formal process through which a desired behavioral
property (the specification) is verified to hold for a given
system (the model) via an exhaustive enumeration (either
explicit or symbolic) of all of the reachable system states and
the behaviors that cause the system to transition between
them. If the specification is found not to hold in all system
executions, a counterexample is produced, consisting of a trace
of the model from a start state to an error state in which
E-mail address: Kristin.Y.Rozier@nasa.gov.
1574-0137/$ - see front matter. Published by Elsevier Inc.
doi:10.1016/j.cosrev.2010.06.002

the specification is violated, providing a very helpful tool for

debugging the system design.
The time-honored techniques of simulation and testing,
both of which involve checking the systems behavior on a
large set of expected inputs, also address similar questions
and are extremely useful debugging tools in early stages
of system design and verification. However, as a system is
refined, the remaining bugs become fewer and more subtle
and require more time to uncover. A major gap in the
process of using simulation and/or testing for verification
and validation is that there is no way to tell when these
techniques are finished (i.e. when all of the bugs in the system
have been found). In other words, testing and simulation
can be used to demonstrate the presence of bugs but not
the absence of bugs. There is not even an accurate way of
estimating how many bugs remain. Another open question
is that of coverage, of both the possible system inputs and
the system state space. Quite simply, it has been proven

COMPUTER SCIENCE REVIEW

that testing and simulation cannot be used to guarantee an

ultra-high level of reliability within any realistic period of
time [1]. For some systems, this is an acceptable risk. For
those systems, it is enough to reduce the bug level below
a certain measurable tolerance, for example in terms of
frequency in time. For safety-critical systems, or other systems,
such as financial systems, where reliability is key because
failure is potentially catastrophic, we require an absolute
assurance that the system follows its specification via an
examination of all possible behaviors, including those that
are unexpected or unintended. This assurance is provided by
model checking.
While there are a range of different techniques for
formal verification, model checking is particularly well-suited
for the automated verification of finite-state systems, both
for software and for hardware. Once the system model
and specification have been determined, the performance
of the model checking step is often very fast, frequently
completing within minutes. The counterexample returned
in the case a bug is found provides necessary diagnostic
feedback. Furthermore, iterative refinement and re-checking
of the failed specification can provide a wealth of insight
into the detected faulty system behavior. Model checking
lends itself to integration into industrial design lifecycles as the learning curve is quite shallow and easily
outweighed by the advantages of early fault detection. The
required levels of user interaction and specialized expertise
needed to effectively utilize a model checker are minimal
compared to other methods of formal verification. Moreover,
partial specifications can be checked, allowing verification
steps to occur intermittently throughout system design.
However, there is a trade-off between the high level of
automation provided by model checking and the high level
of expressiveness and control that may be required for
verification in some cases. For this reason, certain systems
benefit from the use of alternative verification techniques,
such as theorem proving, which involves logically deducing
the specification from the formal system description and a
set of axioms and inference rules. Still, model checkings high
level of automation makes it a preferable verification method
where applicable since the performance time and quality of
insight obtained from a negative result when using theorem
proving for verification are highly dependent on the particular
skill-set of the person providing the proof.
Formally, the technique of model checking checks that a
system, starting at a start state, models a specification. Let M
be a state-transition graph (i.e. an automaton) representing
the system with set of states S and let s S be the start
state. Let be the specification in temporal logic. We check
that M, s |H . In other words, we check that M satisfies
(models) . This technique of temporal logic model checking
was developed independently by Clarke and Emerson [2] in
the United States and Quielle and Sifakis [3] in France in 1981.
Thus, 1981 is considered the birth year of model checking.
The primary focus of this paper is on model checking
using Linear Temporal Logic (LTL) specifications. LTL was
first introduced as a vehicle for reasoning about concurrent
programs by Pnueli in 1977 [4]. LTL model checkers follow the
automata-theoretic approach [5], in which the complemented
LTL specification is translated to a Bchi automaton,1

A , which is a finite automaton on infinite words that

accepts exactly all computations that satisfy the formula .
A is then composed with the model M under verification,
forming AM, [6]. Intuitively, any accepting path in AM,
represents a case where the system M allows a behavior
that violates the specification . The model checker then
searches for such a trace of the model that is accepted
by the automaton AM, via a nonemptiness check. If an
accepting trace is found, it is returned as a counterexample.
If no such trace exists (i.e. the language L (AM, ) = ), we
have proven that M, s |H . This process is summarized in
Table 1. The equivalent to the automata-theoretic approach
for branching temporal logics utilizes automata on infinite
trees and relies upon a reduction of satisfiability to the
nonemptiness problem for these automata [7].
LTL model checkers can be classified as explicit or symbolic.
Explicit model checkers, such as SPIN2 [8] and SPOT3 [9],
construct the state-space of the model explicitly and create
the automaton AM, such that L (AM, ) = L (M) L (A ),
and |AM, | = O (|M| |A |), where vertical bars indicate
the size of an automaton in terms of number of states
and transitions. Next, the model checker searches for a
trace falsifying the specification. This search equates to a
nonemptiness check of the automaton AM, . The standard
algorithm for this task is Tarjans depth-first search algorithm
for finding strongly connected components in the statetransition graph, which runs in time linear in the sum of
the number of states and transitions. (In practice slightly
more efficient algorithms are usually implemented [1012].)
However, constructing and searching the state space in this
manner requires a considerable amount of space, even when
utilizing optimization techniques such as on-the-fly state
space construction [1315]. Given that the size of the state
space required for model checking is the largest challenge
to its efficacy as a verification technique, utilizing techniques
that conserve space is vital.
The state explosion problem is widely agreed to be the
most formidable challenge facing the application of model
checking to large and complex real-world systems. In
short, the number of states required to model concurrent
systems grows exponentially with the number of system
components, constituting the main practical limitation of
model checking. Sequential hardware circuits with n input
variables and k registers require 2n+k states to represent.
Even simple systems, like an n-bit binary counter, can
necessitate large state spaces (in this case, 2n states). In
general, a system with n variables over a domain of k
possible values requires at least kn states in the model
and reasoning over real-valued variables, which have infinite
possible values, results in a state-transition model with
infinitely many states. Unfortunately, the state explosion
problem is unavoidable in the worst case. However, a host
of techniques have been developed over the last three
decades that have successfully eased the problem for certain
types of systems. For example, sophisticated data structures,
clever algorithms for representing interleaving of concurrent
components (called partial order reduction [16]), and the use
of bisimulation equivalences [17] and compositional (also
2 http://spinroot.com/.

1 Bchi

automata are formally defined in Section 3.4.

3 http://spot.lip6.fr/.

COMPUTER SCIENCE REVIEW

Table 1 Model checking definition.

Model checking
Description
1. Create a mathematical model of the
system.
2. Encapsulate desired properties in a
formal specification.
3. Check that the model satisfies the
specification.

Implementation
1. Define the system model M containing traces over the set Prop of propositions.
2. Let specification be a formula over the set Prop.
3. Check that M |H :
Translate the specification into a Bchi automaton A and compose it with the
system model M to form AM, .
Check AM, for nonemptiness. That is, search for a trace that is accepted by AM, .
If such a trace exists, return it as a counterexample.
If no such trace exists, return TRUE.

called modular) verification [18] to reason about different

levels of abstraction, all address the state explosion problem.

2.

In order to mitigate the state explosion problem, symbolic

model checkers, such as CadenceSMV [19], NuSMV [20], and
VIS [21], represent the system model symbolically using
sets of states and sets of transitions. They then analyze
the state space symbolically using binary decision diagrams
(BDDs) [22]. In contrast with explicit-state model checking,
states in symbolic model checking, are represented implicitly,
as a solution to a logical equation. This saves space in
memory since syntactically small equations can represent
comparatively large sets of states. All symbolic model
checkers essentially use the symbolic translation for LTL
specifications described in [23] and the analysis algorithm
of [24], though some optimize further. The technique of using
BDDs to reason about Boolean formulas representing the state
space, thereby avoiding building the state graph explicitly,
was invented by McMillan [25] and is considered to be one
of the biggest breakthroughs in the history of model checking
for its impact on the state explosion problem [26].4

While it is sometimes possible to perform verification directly

on a completed system, this approach is undesirable for
two reasons. Firstly, it is significantly more efficient and
cost-effective to perform verification as early as possible in
the system design process, thereby avoiding the possible
discovery of an error in the completed system that requires
a redesign. Secondly, it is simpler and easier to reason about
a model of the system than the system itself because the
model includes only the relevant features of the larger system
and because the model is easier to build and redesign as
necessary.
Surveying the vast array of system modeling techniques
is outside the scope of this paper. Models can be
extracted from automata, code, scripts or other higherlevel specification language descriptions, sets of Boolean
formulas, or other mathematical descriptions. They can be
comprised of sets of models, such as a set of models
of the whole system at different levels of detail, or a
set of models of different independent subsystems plus a
model of the communications protocol between subsystems,
etc. Furthermore, there are many strategies for modeling
to optimize clarity, provide generality for reusability, or
minimize model checking time, either by reducing time or
space complexity during the model checking step. Models
can be designed not only to find bugs in a system design
but also to solve problems from other domains. For example,
model checking is sometimes used for path planning
where the model and the specification property describe
the environment to be traversed and the constraints on
the path; the counterexample returned constitutes a viable
path matching those criteria [28]. Here we simply list the
necessary components of a system model and introduce an
example model of a real-world automated air traffic control
architecture that will be used throughout the rest of the paper
to demonstrate the steps of LTL symbolic model checking as
we introduce them.
Whatever the original form of the system model, we
eventually translate it into some form of state-transition
system that is simply a type of graph called an automaton or
Kripke structure. As the name implies, this state-transition
system minimally must contain some set of system states
(the vertices of the graph) and transitions between states (the
edges of the graph). The system is described by a set of
system variables, also called the systems alphabet. Here, we

We carefully consider each step in the end-to-end process

of linear temporal logic symbolic model checking in order,
giving the big picture before the lower-level details of each
step. Therefore, the structure of this paper is as follows.
Section 2 discusses strategies for symbolically modeling a
system for verification and introduces our running example
of verifying an automated air traffic control architecture.
Next, we discuss specifying behavior properties in temporal
logic and translating them into symbolic automata in
Section 3. We demonstrate how to represent the combined
system model and specification using BDDs in Section 4 and
then show how to perform the nonemptiness check and
produce counterexample traces in Section 5. To facilitate ease
of understanding, formal definitions of each construct are
given upon first use, rather than upon first mention. For
example, while we mention LTL in the title of this paper,
it is not defined until Section 3.1.1, where we first discuss
the process of writing temporal logic specifications in detail.
Finally, we conclude with a discussion in Section 6.
4 Others independently published ideas similar to McMillans
symbolic model-checking algorithm at around the same time.
See [27] for a high-level overview of these techniques.

Modeling the system

COMPUTER SCIENCE REVIEW

define a state as a set of assignments to the system variables.

Therefore, each vertex in the graph is labeled by all of the
system variables and their values in that state. Each unique
variable assignment constitutes a unique state. Since not all
variable assignments may be possible, the lower bound on the
number of states in a system model is 1 and the upper bound
is 2| | , presuming is a set of Boolean variables. We consider
a system to transition from one state to another (i.e. traverse
an edge from one vertex to another) when the values of one
or more system variables change from the values they had in
the originating state to the values they have in the destination
state.
Given that system design and modeling is largely an art
form, we simply list here the chief concerns to keep in mind
when creating the system model:
Defining : What is the minimum set of system variables
required to accurately describe the full set of behaviors of
the system?
Level of abstraction: Which details of the system are
relevant to the verification process and how do we ensure
we have included all of these? Which details serve chiefly
to obscure the former? For example, when modeling
an automated air traffic control architecture, we include
in the model that the controller can request a specific
trajectory. However, details of the graphical user interface
(GUI) used to make this request are left out.
Validation:
system model: Have we modeled the system
correctly?
model system: How will we ensure the resulting
hardware or software system created after verification
matches the model we have verified?

2.1.

Modeling limitations

Not all systems can be modeled in such a way as to undergo

formal verification via symbolic model checking. However the
model is created, there is always the chance of creating more
states than can be reasoned about in computer memory and
having the model checking step halted by the state explosion
problem. This problem can be mitigated during the modeling
phase by being cognizant that, in the worst case, the model
checker will have to explore the entire state space. Keeping
the state space as small as possible by modeling only relevant
aspects of the system, minimizing the set of state variables,
utilizing sophisticated data structures and abstractions [29],
and representing concurrent threads independently to take
maximum advantage of partial order reductions performed
by the model checker, are some strategies for achieving this
goal. (Partial order reduction is a technique that recognizes
cases where multiple different interleavings of concurrent
processes in the system M have the exact same effect on
the property , thus only one such sequence needs to be
checked [30,16].)
In this paper, we presume the system model M to have
a finite state space defined over discretely-valued variables.
Indeed, the termination of this algorithm is guaranteed by
the finite nature of the state space we are exploring [31].
Some systems inherently have an infinite state space
and thus cannot be model checked using the techniques
presented here; instead, these systems must be verified

using specialized techniques for providing weaker assurances

about larger state spaces or using alternative verification
techniques, such as theorem proving. Bounded model checking
(BMC) [32] can be used to reason about some models whose
state spaces exceed the capacity of symbolic model checking.
For a given k, BMC tools search for a counterexample of length
k or shorter. They can prove the presence of errors in the
model but cannot be used to prove the absence of errors,
only the absence of errors reachable within k steps. Real-time
systems with continuous-valued clocks that can be described
in terms of linear constraints on clock values can be analyzed
using timed automata symbolic model checkers such as
UPPAAL [33]. Hybrid automata model checkers like HyTech
can verify some types of hybrid systems, that is, systems
with a mix of discrete and continuous variables [34] but the
infinite nature of the state space means termination of the
model-checking algorithm is not guaranteed. Increasing the
effectiveness of techniques for model checking real-valued
and infinite-state systems is currently a very active area of
research [3540].

2.2.
An example: the automated airspace concept for air
traffic control
Model checking is most frequently used for the formal
verification of safety-critical systems, or systems whose
failure could result in serious injury or death. Examples of
safety-critical systems include air traffic control, airplane
separation assurance algorithms, life support systems,
essential communications systems, hazardous environment
controls, medical equipment systems (such as those that
administer radiation or assist in surgery), train signaling
systems, and automotive control systems. Other types of
systems where model checking is frequently applied include
components of safety-critical systems, such as processor
chip designs, financial systems that could cause catastrophic
failure, missiles and other weapons systems, commercial
products whose malfunctioning would trigger catastrophic
financial costs for the manufacturer, and any other systems
where the cost of a single failure outweighs the cost of formal
verification.
We illustrate the symbolic model-checking algorithm for
LTL on a small example that describes the architecture for the
Automated Airspace Concept for air traffic control in NASAs
Next Generation Air Transportation System (NGATS) [41],
displayed in Fig. 1.
The following rules govern the operation of this air traffic
control architecture:
The auto-resolver is enabled by default and sends flight
commands to the aircraft.
The aircraft may request a specific flight command.
The controller may request a specific flight command.
If a near-term conflict is detected (i.e. a loss of separation
is projected to occur within an amount of time below
the systems threshold), TSAFE (the Tactical Separation
Assisted Flight Environment tool) automatically engages
and sends a flight command to resolve the conflict. TSAFE
commands always override all requests and commands
issued by the auto-resolver.

COMPUTER SCIENCE REVIEW

Fig. 1 Architecture: Automated Airspace Concept for Air

Traffic Control.

Requests (either from the aircraft or from the controller)

may only be made when the airspace is clear of potential
short-term conflicts. Note that in this model, we uphold
the condition that neither of the request variables may be
true at the same time as the TSAFE_clear variable is false
by canceling any standing requests before acknowledging
a short-term conflict.
Only one request may be made at a time. If the aircraft and
the controller both submit requests at the same time, only
one is registered.
LTL model checkers follow the automata-theoretic approach [5], where the relationship between programs and
their specifications is considered as a relationship between
languages [31]. We can model the air traffic control architecture as an automaton whose language consists of the set of all
of the possible computations of the system. A computation is
essentially an infinite sequence of system states, corresponding to the behavior of the system starting and then running
indefinitely. This method allows us to reason about the systems behavior by asking questions about automata. The alphabet, , of our automaton is a set of system variables in the
form of Boolean-valued propositions that describe the current
state of the program. Table 2 enumerates the alphabet and
Fig. 2 shows explicitly the automaton representing this automated air traffic control architecture. For clarity, each state
is labeled with both the variables that are true in that state
and the negations of the variables that are false in that state.
The transitions are labeled by actions that cause the system
to change state. The start state, State 1, is designated by an
incoming, unlabeled arrow not originating at any vertex.
The following is an example traversal of the automaton in
Fig. 2. We start in State 1. If the controller issues a request, we
move to State 4 and then if that request is granted by the autoresolver we move to State 3, where we see an auto-resolver
command has been issued in response to the controllers
request. The detection of a conflict brings us to State 5
where only one action is available: to ignore the auto-resolver
command requested by the controller and move to State 6.
TSAFE issues a command to resolve the conflict, bringing us
to State 7, and the execution of that command returns us to
State 1 and a conflict-free airspace.

We illustrate a real system description for this protocol

using NuSMV [20,42] since it is well-documented [43], opensource,5 and frequently used in industry [4449]. However,
there are several tools available with similar capabilities including CadenceSMV (which has nearly identical syntax) [19],
SAL-SMC [50], VIS [21], and others. The system description is
fairly straightforward: after declaring our set of system variables, we simply list the conditions that determine how each
of their values changes over time. We accomplish this using
an ASSIGN statement describing the value of each state variable in the next state depending on the conditions in the current state. The function next(var) denotes the value of the
variable var in the next state. If it is assigned using a case
statement then the value of var is set to the value on the right
hand side of colon whenever the condition on the left hand
side of the colon is true. (In the case of multiple true conditions in a case statement, the path to follow is chosen nondeterministically.) The function init() is used to specify the
initial values of each of the state variables. Since our example is short and rather simple, with no concurrent processes
or subroutines, we place the entire specification in the main
module, which is where execution of the model begins. In addition to using this system description for model checking,
NuSMV also supports testing and simulation so one model
can be used for the entire process of design, development,
and formal verification of the system design.
Though our system model currently represents only the
automated air traffic control architecture and not yet any
of the specifications we wish to check, we think ahead and
include a statement turning on fairness. Most of the time
when we refer to fairness, we are referring to a type of
liveness property that specifies that something must happen
infinitely often, as discussed in Section 3.5. In that case, we
are asking NuSMV to reason over all fair paths, or paths
that start at an initial state on which all fairness constraints
are true infinitely often. Enabling FAIRNESS in general, as we
have done in Box I, restricts the model checker to considering
execution paths along which our main module is enabled for
execution infinitely often. Intuitively, if there were multiple
modules in our system model instead of just the one we need
to represent our small example, enabling FAIRNESS for the set
of modules would mean that each of them has the chance
to be executed infinitely often over our prospective timeline.
That is, every module has a fair shot at execution. In short,
the use of FAIRNESS in our model guarantees that the model
checker will return a representation of an infinite trace as a
counterexample for any specifications we wish to check hold
in this model. (See Box I.)
Though most systems are initially defined using assignments per the system requirements as shown in Box I, should
the system already be in automaton form, we can specify it by
directly describing the system states and how we transition
between them. In other words, instead of our previous imperative encoding, using assignment statements, we can equivalently employ a declarative schema using logical constraints.
For clarity, we illustrate a direct specification of the automaton in Fig. 2 in Box II. Here, INIT describes the initial state and
the TRANS statement lists all of the transitions in our model.
5 The source code and documentation are available for
download from: http://nusmv.irst.itc.it/.

COMPUTER SCIENCE REVIEW

Table 2 The system alphabet : a set of Boolean-valued system variables.

Variable

Description

AR_command
TSAFE_command
controller_request
aircraft_request
TSAFE_clear

Has a command been issued by the auto-resolver?

Has a command been issued by TSAFE?
Has a request been issued by the controller?
Has a request been issued by the aircraft?
Does TSAFE detect the airspace is clear of conflicts?

Fig. 2 Automaton: Automated Airspace Concept for Air Traffic Control.

This model is equivalent to the one presented in Box I. Both

are working NuSMV models that will be used as the basis for
examples throughout this paper. (See Box II.)

and unambiguous way that is mathematically rigorous and

thereby enables automation of the verification process.
Propositional Logic:

3.

Specifying the behavior property

Real-world systems are routinely developed from Englishlanguage specifications. Yet, once these systems are built,
there is no way to verify that the resulting systems follow
the English specifications. Consequently, there is also no way
to tell whether following the natural language specifications
is a desirable goal, i.e. whether the set of specifications is
internally consistent, logically sound, or complete. For formal
verification, English is quite simply too imprecise. Consider
the statement by Groucho Marx, I once shot an elephant in
my pajamas. How he got in my pajamas Ill never know, or
the double-meaning of Students hate annoying professors.
In order to check that a system models its specifications,
it is necessary to have a formal, and very precise, notion
of exactly what the specifications say. Therefore, we use
logic for the specification language. Logic has the advantage
of being able to express system specifications in a concise

p
pq
pq
pq

not
and
or
implies

We formalize simple grammatical connections using the

operators of propositional logic: (negation), (conjunction),
(disjunction), (implication). We reason about atomic
propositions, such as the state variables used in the example
of Section 2.2, which are Boolean-valued variables. We refer
to the set of atomic propositions as Prop. A formula is either
an atomic proposition or a sentence comprised of atomic
propositions connected by logical operators. The truth value
of a formula is determined by an assignment A , which is
a mapping of atomic propositions in the domain to truth
values: A : {0, 1}. Thus if there are n atomic propositions
in the domain, there are 2n possible assignments for a given
formula. A formula is satisfied by an assignment A that

COMPUTER SCIENCE REVIEW

Box I.

COMPUTER SCIENCE REVIEW

Box II.

COMPUTER SCIENCE REVIEW

causes the overall formula to evaluate to true. We can think

of our system model M as a set of assignments each state
represents a possible valuation of our state variables.

3.1.

(a) Linear Temporal Logic.

Temporal logics

Continuous systems necessarily involve a notion of time.

Propositional logic is not expressive enough to describe such
real systems. Yet, English descriptions are even less precise
once we involve time. Consider, for example, the following
English sentences:
I said I would see you on Tuesday.
This is the worst disaster in California since I was
elected. [California Governor Pat Brown]
When two trains approach each other at a crossing, both
shall come to a full stop and neither shall start up again
until the other has gone. [Kansas State Legislature, early
1890s]
As a result, Amir Pnueli introduced the notion of
using temporal logics, which were originally developed by
philosophers for investigating how time is used in natural
language arguments, to reason about concurrent systems [4].
(Burstall [51] and Krger [52] independently proposed the
use of weaker forms of temporal reasoning about computer
programs at roughly the same time.) Temporal logics are
modal logics geared toward the description of the temporal
ordering of events. For most safety-critical systems, tying
the system model to an explicit universal clock is overkill;
it exacerbates the state explosion problem without adding
value to the verification process. It is sufficient simply to
guarantee that events happen in a certain partial (or, in some
cases, total) order. Temporal logics were invented for this
purpose. Because they describe the ordering of events in
time without introducing time explicitly, temporal logics are
particularly effective for describing concurrent systems [53].
Temporal logics conceptualize time in one of two ways. Linear
temporal logics consider every moment in time as having
a unique possible future. Essentially, they reason over a
classical timeline. In branching temporal logics, each moment
in time may split into several possible futures. In essence,
these logics view the structure of time as a tree, rooted at the
current time, with any number of branching paths from each
node of the tree (Fig. 3).
Pnuelis historic 1977 paper [4] proposed the logic LTL.
This logic extended propositional logic with the temporal
operators G (for globally) and F (for in the future),
which we also call  and , respectively, and introduced
the concept of fairness, which ensures an infinite-paths
semantics. LTL was subsequently extended to include the U
(until) operator originally introduced by Kamp in 1968 [54]
and the X (next time) operator from the temporal logic
U B (the unified system of branching time) [55]. In 1981, Clarke
and Emerson extended U B, thereby inventing the branching
temporal logic they named Computational Tree Logic (CTL)
and, with it, CTL model checking. Lichtenstein and Pnueli
defined model checking for LTL in 1985 [56]. (For a more
detailed history of the technical developments which lead
from Priors early observations on time and Churchs logical
specification of sequential circuits to LTL and automatatheoretic model checking, see [57].) The combination of LTL

(b) Branching Temporal Logic.

Fig. 3 Two visions of the structure of time.

and CTL, called CTL , was defined by Emerson and Halpern in

1986, though there are currently no industrial model checkers
for this language.6 Since both model checking in general,
and symbolic model checking in particular, were originally
defined for CTL, and since LTL model checking is frequently
defined in the literature in relation to CTL model checking,
we would be remiss not to mention the logic CTL here.
Therefore, we follow the formal definition of LTL below with
a brief description of the logics CTL and CTL along with a
short discussion of the merits and expressibility of LTL that
motivate LTL model checking.

3.1.1.

LTL

Linear Temporal Logic (LTL) reasons over linear traces through

time. At each time instant, there is only one real future
timeline that will occur. Traditionally, that timeline is defined
as starting now, in the current time step, and progressing
infinitely into the future.
Linear Temporal Logic (LTL) formulas are composed of a
finite set Prop of atomic propositions, the Boolean connectives
, , , and , and the temporal connectives U (until), R
(release), X (also called for next time),  (also called G for
globally) and (also called F for in the future). Intuitively,
U states that either is true now or is true now and
remains true until such a time when holds. Dually, R ,
stated releases , signifies that must be true now and
remain true until such a time when is true, thus releasing
. X means that is true in the next time step after the
current one. Finally,  commits to being true in every time
step while designates that must either be true now or at
some future time step. We define LTL formulas inductively:

Definition 1. For every p Prop, p is a formula. If and are

formulas, then so are:

U
R

6 There was one research prototype CTL model checker called

AltMC (Alternating Automata-based Model Checker). Visser and
Barringer created AltMC in 1998 and explained how it could be
integrated into the industrial model checker SPIN [58].

10

COMPUTER SCIENCE REVIEW

Furthermore, we define the closure of LTL formula , cl(),

as the set of all of the subformulas of and their negations
(with redundancies, such as and , consolidated). LTL
formulas describe the behavior of the variables in Prop over a
linear series of time steps starting at time zero and extending
infinitely into the future.7 We satisfy such formulas over
computations, which are functions that assign truth values to
the elements of Prop at each time instant [60]. In essence, a
computation path satisfies a temporal formula if is true
in the zeroth time step of , 0 .
Definition 2. We interpret LTL formulas over computations of
the form : 2Prop , where is used in the standard way
to denote the set of non-negative integers. We also use iff to
abbreviate if and only if. We define , i  (computation
at time instant i satisfies, or models, LTL formula ) as
follows:
, i  p for p Prop iff p (i).
, i  iff , i 2 .
, i  iff , i  and , i  .
, i  iff , i  or , i  .
, i  X iff , i + 1  .
, i  U iff j i, such that , j  and k, i k < j, we
have , k  .
, i  R iff j i, iff , j 2 , then k, i k < j, such that
, k  .
, i   iff j i, , j  .
, i  iff j i, such that , j  .

We take |H to be the set of computations that satisfy at

time 0, i.e., { : , 0  }. We define the prefix of an infinite
computation to be the finite sequence starting from the
zeroth time step, 0 , 1 , . . . , i for some i 0.
We now restate the model-checking problem: program M
satisfies (models) formula iff every path rooted at the
initial state q of M satisfies , denoted M, q |H .

Equivalences. While we have presented the most common

LTL syntax, operator equivalences allow us to reason about
LTL using a reduced set of operators. In particular, the most
common minimum set of LTL operators is , , X, and U.
From propositional logic, we know that ( ) is equivalent
to ( ) by definition and that ( ) is equivalent to
() by DeMorgans law. We can define ( ) as (true U).
Similarly, () (false R ). The expansion laws state that
( U ) = [ X( U )] and ( R ) = [ X( R )].
The operators  and
are logical duals as () is equivalent
to ( ) and ( ) is equivalent to (). Finally, U and
R are also logical duals. Since this last relationship is not
intuitive, we offer proof below. (Incidentally, X is the dual of
itself: (X) (X).)

Informally, U signifies that either is true now (in the

current time step) or is true now and for every following
time step until such a time when is true. Note that this
operator is also referred to as strong until because must be
true at some time. Conversely, weak until, sometimes included
as the operator W , is also satisfied if is true continuously but
is never true. Formally,
, i  W iff either j i, , j  or j i
such that , j  and k, i k < j, we have , k  .

R is the dual of U, so R = ( U ). We say that

releases because must be true now and, in the future,
implies was previously true. Note that at that point in the
past, both and were true at the same time and that may
never be true, as long as is always true. We can define R in
terms of the U-operator using the following lemma, where iff
is used in the standard way to abbreviate if and only if.
Lemma 1. (a U b) = a R b.
Proof. We use the formal semantic definitions of U and R,
given in [61].
, i |H U

iff

, i |H () U ()

iff

, i |H () U ()

iff

, i |H (() U ())

iff
iff
iff
iff

7 Though

we will not discuss them here, some variations of

LTL also consider time steps that have happened in the past.
For example, we could add past-time versions of X and U
called Y (also called for previous time or yesterday) and S
(since), respectively. Past-time LTL was first introduced by Kamp
in 1968 [54] but does not add expressive power to the future-time
LTL defined here [59].

iff
iff

iff

for some j i, we have , j |H

and for all k, i k < j, we have ,
k |H .
for some j i, we have , j |H ()
and for all k, i k < j, we have ,
k |H ().
(( j i : , j |H ())
( k, i k < j : , k |H ())).
(( j i : , j |H ())
( k, i k < j : , k |H ())).
(( j i : , j |H ())
( k, i k < j : , k |H ())).
(( j i : , j |H ())
( k, i k < j : , k |H ())).
( j i : , j |H
k, i k < j : , k |H ).
( j i : , j |H
k, i k < j : , k |H ).
for all j i if , j |H ,
then for some k, i k < j we have
, k |H .
, i |H R . 

COMPUTER SCIENCE REVIEW

3.2.

11

Logical expressiveness of LTL

In a paper on LTL symbolic model checking, inevitably

the question arises: why LTL? What are the alternative
specification logics? Why (and when) should we choose LTL?
In order to put LTL in the proper context, we briefly, but
formally, define the most viable alternatives and discuss
when LTL is (and is not) an appropriate choice.

3.2.1.

CTL

Computational Tree Logic (CTL) is a branching time logic that

reasons over many possible traces through time. Historically,
CTL was the first logic used in model checking [2] and it
remains a popular specification logic. Unlike LTL, for which
every time instance has exactly one immediate successor,
in CTL a time instance has a finite, non-zero number of
immediate successors. A branching timeline starts in the
current time step, and may progress to any one of potentially
many possible infinite futures. In addition to reasoning along
a timeline, as we do for linear time logic, branching time
temporal operators must also reason across the possible
branches. Consequently, the temporal operators in CTL are
all two-part operators with one part specifying, similarly to
LTL, the action to occur along a future timeline and another
part specifying whether this action takes place on at least one
branch or on all branches.
Computational Tree Logic (CTL) formulas are composed of a
finite set Prop of atomic propositions, the Boolean connectives
, , , and , and indivisible quantifier pairings of the
path quantifiers A (always, for all paths), and E (there exists
a path), with the linear temporal connectives of LTL: U
(until), X (also called for next time),  (also called G for
globally) and (also called F for in the future). (See Fig. 4.)
We define CTL formulas inductively:

Definition 3. For every p Prop, p is a formula. If and are

formulas, then so are:

AX

E X

A

E 

A( U ) E ( U )
A 
E 

CTL formulas describe the behavior of the variables in Prop

over a branching series of time steps starting at time zero and
extending infinitely into the future. As for LTL, computations
are functions that assign truth values to the elements of Prop
at each time instant.
Definition 4. We interpret CTL formulas over sets of possible
computations of the form : 2Prop . Due to the branching
nature of the logic, there may be many future paths possible
from any one time step: 0 , 1 , 2 , . . . We will call the set of
all of the possible paths from the current time step . We
define , i  (set of possible computations 0...m at time
instant i satisfies CTL formula ) as follows:

, i  p for p Prop if p (i).

, i  if , i 2 .
, i  if , i  and , i  .
, i  if , i  or , i  .
, i  AX if (n)n , i + 1  .
, i  E X if (n)n , i + 1  .

Fig. 4 Syntax of LTL and CTL.

, i  A( U ) if (n)(j i), such that n , j  and

k, i k < j, we have n , k  .
, i  E ( U ) if (n)(j i), such that n , j  and
k, i k < j, we have n , k  .
, i  A if (n)(j i), n , j  .
, i  E  if (n)(j i), n , j  .
, i  A if (n)(j i), such that n , j  .
, i  E if (n)(j i), such that n , j  .




Equivalences. The path quantifiers A and E , representing

universal and existential quantification over the branching
paths are duals and can be defined in terms of each
other. Similarly,  and
signify universal and existential
quantification over time steps along a single paths and are
therefore also duals. (Again, the U-operator is strong until
because its second argument must be true at some time.)
These realizations lead us to the following set of semantic
equivalences:

(A ) (E ()) (A(true U )).

(A) (E ()) (E (true U )).
(E ) (A()) (E (true U )).
(E ) (A ()) (A(true U )).
(AX) (E X()).
(E X) (AX()).
(A[ U ]) (E [() U( )]) (E ()).

There is an automata-theoretic approach to branching

time model checking, similar to the ideas described in this
paper for LTL. While we do not translate branching temporal
formulas into nondeterministic tree automata due to the
double exponential blow-up inherent in this process, we
can translate them into alternating tree automata in linear
time [7].

3.2.2.

LTL vs CTL

The logical expressiveness of LTL and CTL is incomparable [62]. (See Fig. 5.) Since CTL allows explicit existential quantification over paths, it is more expressive in some cases
where we want to reason about the possibility of the existence of a specific path through the transition system model
M, such as when M is best described as a computation tree.
For example, there are no LTL equivalents of the CTL formulas (E X p) and (AE p) since LTL cannot express the possibility of p happening on some path (but not necessarily all

12

COMPUTER SCIENCE REVIEW

Fig. 5 Venn Diagram: expressiveness of common

temporal logics.

paths) next time, or in the future. LTL describes executions of

the system, not the way in which they can be organized into a
branching tree. Intuitively, it is difficult (or impossible) to express in LTL situations where distinct behaviors occur on distinct branches at the same time. Conversely, it is difficult (or
impossible) to express in CTL some situations where the same
behavior may occur on distinct branches at distinct times, a
circumstance where the ability of LTL to describe individual
paths is quite useful. Realistically, the former rarely happens
and LTL turns out to be more expressive from a practical point
of view than CTL [63].
Model checking time complexity. The model-checking algorithms
for LTL and CTL are different. The major argument in favor
of using a branching time logic, like CTL, instead of LTL for
property specification is that the model-checking problem
for CTL has lower computational complexity than for LTL.
Specifically, let |M| indicate the size of the system model
in terms of state space and || indicate the size of the
specification calculated as the total number of symbols:
propositions, logical connectives, and temporal operators.
Then the model-checking algorithm for CTL runs in time
O (|M|||) [64] and the model-checking algorithm for LTL
runs in time |M| 2O (||) [56]. Intuitively, this is because
CTL is state-based (i.e. reasoning over states in time), and
this set of states is easily converted into an automaton
whereas the succinct path-based model of LTL (where many
possible paths may pass through a single state) must be
expanded. This difference in the computational complexity
of translating the specification into the Bchi automaton
A is solely responsible for the difference in the model
checking computational complexity for an LTL formula
and for a CTL formula . For LTL, this logic-to-automaton
translation step is clearly a bottleneck in the model-checking
algorithm; the problem of checking Bchi automata8 AM,
for nonemptiness is NLOGSPACE-complete [65] and decidable
in linear time [66]. There is no hope of reconciling the
time complexity of the general model-checking problem for
LTL with that of CTL since the model-checking problem for
LTL is PSPACE-complete [67]. The best algorithms for LTL
model checking, which are exponential in the length of the
formula but linear in the size of the model, were proposed
by Lichtenstein and Pnueli [56] and Vardi and Wolper [5], the
latter algorithm being the basis for most LTL model checking
tools today.
However, the comparison of the specification logics LTL
and CTL by time complexity is somewhat misleading and
8 Bchi

automata are formally defined in Section 3.4.

certainly not significant enough to be the sole deciding factor

of which logic to use for specification. Though model checking
can be done in time linear in the size of the specification
for CTL [64,3] the requirement for double-operators means
that CTL formulas tend to be longer and more complicated
than LTL formulas. In fact, it is not entirely clear how much
effect the exponential blow-up for LTL model checking has
in practice given that the size of most LTL specifications is
very small. Furthermore, if we examine specific, practical
variants of the model-checking problem for CTL, we find that
the complexity dominance of this logic does not hold [63].
Performing specification debugging via satisfiability checking
as we describe in Section 3.3 is still PSPACE-complete
for LTL [67] but is EXPTIME-complete for CTL [68,69]. For
the practical model checking applications of compositional
verification, verification of open or reactive systems (i.e. those
systems that interact with an environment), verification
of concurrent systems, and automata-theoretic verification,
LTL-based algorithms either dominate those for CTL or
perform similarly [70].
Since there are fast, efficient tools for LTL model checking,
and it is questionable to what extent this theoretical
difference affects the process of model checking in practice,
we focus on the language that is more suitable for
specification. From a system design point of view, it is more
important to be able to write clear and correct specifications
to input into the model checker.
Usually, we want to describe behavioral, rather than
structural, properties of the model, making LTL the better
choice for specification since such properties are easily
expressed in LTL but may not be expressible in CTL. For
example, we may want to say that p happens within the next
two time steps, (X p XX p), or that if p ever happens, q will
happen too, ( p q), neither of which is expressible in
CTL [71]. Similarly, we cannot state in CTL that if p happens
in the future, q will happen in the next time step after that,
which is simply (p X q) in LTL [72]. Worst of all, it is not
obvious that these useful properties should not be expressible
in CTL. Indeed, a thorough comparison of the two logics
concludes that CTL is unintuitive, hard to use, ill-suited for
compositional reasoning, and fundamentally incompatible
with semi-formal verification while LTL suffers from none
of these inherent limitations and is better suited to model
checking in general [63].
LTL is a fair language whereas CTL is not. That is to say
that LTL can express properties of fairness, including both
strong fairness and weak fairness whereas CTL cannot (though
CTL model checkers generally allow users to specify fairness
statements separately to account for this shortcoming). For
example, the LTL formula ( p q), which expresses the
property that infinitely many ps implies eventually q, is the
form of a common fairness statement: a continuous request
will eventually be acknowledged. Yet this sentiment is not
expressible in CTL. Since fairness properties occur frequently
in the specifications we wish to verify about real-life reactive
systems, this adds to the desirability of LTL as a specification
language.
For another example, the common invariance property
p, meaning at some point, p will hold forever cannot
be expressed in CTL. It is difficult to see why this formula
is not equivalent to the CTL formula A Ap; after all,

COMPUTER SCIENCE REVIEW

13

to be more intuitive, and less error-prone, than using CTL, particularly for verifying concurrent software architectures [74].
The vast majority of CTL specifications used in practice are
equivalent to LTL specifications; it is rare that the added ability to reason over computation tree branches is needed and
it frequently requires engineers to look at their designs in an
unnatural way [63]. The expressiveness, simplicity, and usability of LTL, particularly for practical applications like open
system or compositional verification, and specification debugging, make it a good choice for industrial verification.
Fig. 6 A situation where the LTL formula
the CTL formula (A Ap) does not.

p holds but

3.2.3.

CTL

Emerson and Halpern first invented the logic CTL in

1983 [75]. This logic combines the syntaxes of the two
logics LTL and CTL. It includes all of the logical operators
in LTL and both path quantifiers of CTL but does not have
the CTL restriction that temporal operators must appear in
pairs. Both LTL and CTL are proper subsets of CTL , as are
all combinations of LTL and CTL formulas; CTL is more
expressive than both LTL and CTL combined. For example, the
formulas E( p) and A( p) A(E p) are both in CTL but
in neither LTL nor CTL.
However, this expressive power comes at a great cost. The
model-checking problem for CTL is PSPACE-complete [67],
which the same general complexity as for LTL, though the
algorithm is considerably more complex to implement and
there are currently no model checkers for this logic. Indeed,
for practical model-checking problems such as compositional
verification and verification of open or reactive systems
(i.e. those systems that interact with an environment)
CTL is dominated by LTL [70]. Furthermore, the simple
task of specification debugging via satisfiability checking is
2EXPTIME-complete for CTL [76,77]. Simply translating a
CTL specification into an automaton for model checking
involves a doubly-exponential blow-up [78]. So, despite the
deceptive time complexity for the general model checking
problem, adding branching to LTL is not free. In practice,
should LTL prove to be too limited to express a desired
property, CTL is almost certainly sufficient [73]. However,
the lack of industrial model-checking tools that accept CTL
specifications is a deterrent to the use of this logic.

Fig. 7 A situation where the three equivalent formulas

LTL formula X p, LTL formula X p, and CTL formula
AXA p hold but the CTL formula (A AX p), which is
strictly stronger, does not.

we are basically claiming that on all paths, theres a point

where p holds in all future states. (The standard semantic
interpretation of LTL corresponds to the for all paths syntax
of CTL. For this reason, we consider there to be an implicit A
operator in front of all LTL formulas when we compare them
to CTL formulas.) To illustrate the inequivalence of these two
formulas, we show in Fig. 6 a timeline that satisfies p but
does not satisfy A Ap. Note that A Ap does not hold
along the vertical spine in particular there is never a point
where Ap holds along this path. There is always one child
where p holds forever and one child where p holds.
Another frequently cited example of the unintuitiveness
of CTL is the property that the CTL formula AXA p is not
equivalent to the formula (A AX p). Again, the distinction
is subtle. The former formula states that, as of the next time
step, it is true that p will definitely hold at some point in
the future or, in other words, p holds sometime in the strict
future. This formula is equivalent to the LTL formulas X p
and X p. On the other hand, the meaning of (A AX p)
is the strictly stronger (and actually quite strange) assertion
that on all paths, in the future, there is some point where p
is true in the next time step on all of the branches from that
point. Fig. 7 illustrates this subtlety. Note that in this timeline,
p is true in the strict future along every path but there is not
a point on every path where p is true in the next step on all
branches.
These examples illustrate why LTL is frequently considered a more straightforward language, better suited to specification and more usable for verification engineers and system designers. LTL is the preferred logic of the two for general
property specification and on-the-fly verification [73]. Verification engineers have found expressing specifications in LTL

3.2.4.

Industrial logics based on LTL

In several cases, industrial companies have defined extensions of LTL, specialized for their verification needs. Usually
these linear time logics add operators to make the expression of specific properties easier and to extend the specification language to full -regularity. The optimal position in the
trade-off between logical expressiveness and model checking
time complexity remains under discussion.
Definition 5. An -regular expression is an expression of the

form i i (i ) where i is non-zero and finite and and are

regular expressions over the alphabet .
We refer to the standard definition of a regular expression,
comprised of the elements of the alphabet , parentheses,
and the operators +, , and for union, concatenation, and
star-closure, respectively. An -regular expression adds the
exponent that, in some sense, extends the -exponent since
a designates an arbitrary, possibly zero, finite number of
repetitions of a while a designates an infinite number of
repetitions of a.

14

COMPUTER SCIENCE REVIEW

Definition 6. An -regular language is one that can be

described by an -regular expression. Also, a language is
-regular if and only if there exists a Bchi automaton
that accepts it. (We discuss Bchi automata in detail in
Section 3.4.) The family of -regular languages is closed under
union, intersection, and complementation.
LTL can express a strict subset of -regular expressions;
it can describe specifically the -free -regular events. For
example, LTL cannot express the sentiment that a particular
event must occur exactly every n time steps of an infinite
computation and that this event may or may not occur during
any of the other time steps. Wolper first pointed this out and
defined Extended Temporal Logic (ETL), which augmented
LTL with operators corresponding to right-linear grammars,
thus expanding the expressiveness to all properties that
can be described by -regular expressions [79]. Vardi and
Wolper followed this by proposing ETLs where the temporal
operators are defined by finite -automata, which provide
useful tools for hardware specification [65]. However, model
checking with ETL involves a difficult complementation
construction for Bchi automata [80]. Banieqbal and Barringer
and, separately, Vardi created a linear -calculus by
extending LTL with fixpoint operators, which allows for
a more natural description of constructs like recursive
procedures and modules in compositional verification [81,
82]. Sistla, Vardi, and Wolpers Quantified Propositional
Temporal Logic (QPTL) avoids common user difficulties with
fixpoint calculi and achieves -regularity instead by allowing
quantification over propositional variables but at the cost of
a nonelementary time complexity [83]. Emerson and Trefler
proposed dealing with real-time correctness properties while
avoiding the nonelementary time complexity by using Real
Time Propositional LTL (RTPLTL), which adds time bounds to
temporal operators referencing multiple independent clocks
but can be checked in time exponential in the size of the
regular expression [84].
Verification engineers in industry have also extended
LTL to suit their specific needs. After successful verification
efforts from 1995 to 1999 using symbolic model checking
with specifications in FSL, a home-grown linear temporal
logic specialized for hardware checking [85], Intel developed
the formal specification language ForSpec [86]. The temporal
logic underlying ForSpec, called FTL, extends past-time LTL
to add explicit operators for manipulating multiple clocks
and reset signals, expressions for reasoning about regular
events, and time bounds on the temporal operators that
allow users to specify time windows during which an
operator is satisfied. The consequence of the increased
expressivity of FTL is that checking satisfiability is EXPSPACEcomplete. IBM developed their own syntactic sugar [87] in
parallel from the early 1990s. IBMs Sugar extends LTL with
Sugar Extended Regular Expressions (SEREs), the ability to
explicitly reference multiple independent clocks, and limited
Optional Branching Extensions (OBEs) [88]. Motorolas CBV
and Verisitys Temporal e [89] are also linear-time logics
that achieve full -regularity by adding regular expressions
and clock operations. In 2003, the standardization committee
Accellera, considering these four industrial specification
languages, announced the industry standard languages
SystemVerilog Assertion (SVA) language [90] and Property

Specification Language (PSL), which is based chiefly on Sugar

with heavy influence from ForSpec [91,92,57]. It is worth
noting that restricted variants of LTL have also proved useful
for specializing the logic without increasing computational
complexity. For example, Allen Linear Temporal Logic
(ALTL) [93] marries a restricted LTL, without X-, U-, or
R-operators, with Allens temporal intervals [94], but ALTL
satisfiability checking is only NP-complete.
In summary, the industrial languages described in this
section are all based on LTL and use model checking methods
similar to those described in this paper. Thus, insights into
LTL model checking extend to all of these languages.

3.3.

Specification debugging

Just as designing a bug-free system is difficult, causing us to

employ model checking to find the bugs, writing correct specifications to check the system is difficult. Therefore, an important step in between writing specifications and performing
the model checking step is specification debugging. As specifications are usually significantly smaller than the systems
they describe, they are significantly easier to check. The goal
of specification debugging is to answer as best as possible the
question do the specifications say what I meant? Though it
is impossible to answer this question absolutely, it is usually
sufficient to run a series of tests on the set of specifications
meant to flag situations where the specifications as written
clearly cannot match their authors intentions.
When the model does not satisfy the specification, modelchecking tools accompany this negative answer with a
counterexample, which points to an inconsistency between
the system and the desired behaviors. It is often the case
that there is an error in the system model or in the
formal specification. Such errors may not be detected when
the answer of the model-checking tool is positive: while
a positive answer does guarantee that the model satisfies
the specification, the answer to the real question, namely,
whether the system has the intended behavior, may be
different. We need to ask two questions:
1. If there is disagreement between the system model and
the specification, which one has the error?
2. If there is agreement, is this caused by an error? (A positive
model checking result does not mean there is no error. For
example, the specification could have a bug!)
Specification testing can be performed by specification
authors writing small system models that they believe should
or should not satisfy each specification and then verifying
this is the case via model checking. However, this process can
be a time-consuming, tedious, and error-prone one.
The realization of this unfortunate situation has led
to the development of several sanity checks for formal
verification [95]. The goal of these checks is to detect
errors in the system model or the properties. Sanity checks
in industrial tools are typically simple, ad hoc, tests,
such as checking for enabling conditions that are never
enabled [96]. Standard specification testing can also be
preformed more intelligently using concept analysis, which
produces a hierarchical set of clusters of test traces grouped
by similarities [97]. This technique allows the specification
author to inspect a small number of clusters instead of a large

COMPUTER SCIENCE REVIEW

number of individual traces and use the similarities in the

clusters to help determine whether the set of traces in each
cluster points to specification error(s) or not.
Of course, it is extremely desirable to run automated tests
on specifications. Vacuity detection provides a systematic approach for checking whether a subformula of the specification does not affect the satisfaction of the specification in the
model. Intuitively, a specification is satisfied vacuously in a
model if it is satisfied in some non-interesting way. For example, the Linear Temporal Logic (LTL) specification (req
grant) (every request is eventually followed by a grant) is
satisfied vacuously in a model with no requests. While vacuity checking cannot ensure that whenever a model satisfies
a formula, the model is correct, it does identify certain positive results as vacuous, increasing the likelihood of capturing
modeling and specification errors. Several papers on vacuity
checking have been published over the last few years [98105],
and various industrial model-checking tools support vacuity
checking [98100].

At a minimum, it is necessary to employ LTL satisfiability

checking [106]. If the specification is valid, that is, true in
all models, then model checking this specification always
results in a positive answer. Basically, the specification is
irrelevant. Consider for example the specification (b1
b2 ), where b1 and b2 are propositional formulas. If b1
and b2 are logically equivalent, then this specification is
valid and is satisfied by all models. Clearly, if a formal
property is valid, then this is certainly due to an error.
Similarly, if a formal property is unsatisfiable, that is, true
in no model, then this is also certainly due to an error. For
example, if the specification is (b1 b2 ) where b1 and b2
are contradictory, then the specification can never be true.
Even if each individual property written by the specifier is
satisfiable, their conjunction may very well be unsatisfiable.
Recall that a logical formula is valid iff its negation is not
satisfiable. Thus, as a necessary sanity check for debugging
a specification, we must ensure that both the specification
and its negation are satisfiable and that the conjunction of
all specifications is satisfiable.

Fortunately, this check is easily performed using standard

model-checking tools to check the specifications against a
universal model before checking them against the system
model. A basic observation underlying this conclusion is that
LTL satisfiability checking can be reduced to model checking.
Consider a formula over a set Prop of atomic propositions. If
a model M is universal, that is, it contains all possible traces
over Prop, then is satisfiable precisely when the model M
does not satisfy . Thus, it is easy to include satisfiability
checking using LTL model-checking tools as a specification
debugging step in the verification process.9
9 In contrast, for branching-time logics such as CTL or CTL ,
satisfiability checking is significantly harder than model checking.
For LTL, both satisfiability checking and model checking are
PSPACE-complete with respect to formula size [67]. On the
other hand, with respect to formula size, model checking is
NLOGSPACE-complete for CTL [107] and PSPACE-complete for
CTL [66], while satisfiability is EXPTIME-complete for CTL [69,68]
and 2EXPTIME-complete for CTL [77,76]

3.4.

15

Translating the property into a symbolic automaton

In LTL model checking, we check LTL formulas representing

desired behaviors against a formal model of the system
designed to exhibit these behaviors. To accomplish this task,
we employ the automata-theoretic approach, in which the
LTL formulas must be translated into Bchi automata10 [5].
This step is performed automatically by the model checker.
Definition 7. A Bchi Automaton (BA) is a quintuple (Q, , ,
q0 , F) where:
Q is a finite set of states.
is a finite alphabet.
: Q Q is a transition relation.
q0 Q is the initial state.
F Q is a set of final states.
A run of a Bchi automaton over an infinite word w =
w0 , w1 , w2 , . . . is a sequence of states q0 , q1 , q2 , . . . Q
such that i 0, (qi , wi ) = qi+1 . An infinite word w is accepted
by the automaton if the run over w visits at least one state in F
infinitely often. We denote the set of infinite words accepted
by an automaton A by L (A). A Generalized Bchi Automaton
(GBA) is one for which F is a set of acceptance sets such that
an infinite word w is accepted by the automaton if the run
over w visits at least one state in each set in F infinitely often.
We also define the extended transition relation : Q Q,
which takes a string, rather than a single character, as the
second argument and yields the result of reading in that
string. Let represent the empty string. Then we can define
recursively. For all q Q, w , :
(q, ) = q
(q, w) = ( (q, w), ).
A computation satisfying LTL formula is an infinite word
over the alphabet = 2Prop , which is accepted by the Bchi
automaton A corresponding to . For this reason, A is
also called a tester for ; it characterizes all computations
that satisfy . The set of computations of comprise the
language L (A ). Every LTL formula has an equivalent Bchi
automaton. The next theorem relates the expressive power of
LTL to that of Bchi automata.
Theorem 2. 11 Given an LTL formula , we can construct a

nondeterministic Bchi automaton A = Q, , , q0 , F such that

|Q| is in 2O(||) , = 2Prop , and L (A ) is exactly |H .
10 Bchi

automata were introduced by J.R. Bchi in 1962 [108].

proof in this paper was inspired by the direct proof
techniques employed in [56] (which proved a variant of Theorem 2
that reasons more directly over graphs instead of Bchi
automata), [109], and [72]. Other proof strategies include the use of
alternating automata [61,110]. Alternatively, one can consider the
Bchi automaton A to be a combination of two automata, a local
automaton that reasons about consecutive sequences of states
and an eventuality automaton that reasons about eventuality
formulas (U or F -subformulas) [5,65,111,112]. (Note that [65,
111,112] proved a variant of Theorem 2 for types of Extended
Temporal Logic (ETL) that subsume LTL.)
11 The

16

COMPUTER SCIENCE REVIEW

Proof of Theorem 2. For simplicity, presume is in negation

normal form ( appears only preceeding propositions) and
the temporal operators  and have been eliminated via the
equivalences described in Section 3.1.1.
Recall that the closure of LTL formula , cl() is the set
of all of the subformulas of and their negations (with
redundancies such as and consolidated). Specifically,

cl().
cl() cl().
cl() cl().
cl() , cl().
cl() , cl().
X cl() cl().
U cl() , cl().
R cl() , cl().

Recall that the expansion laws state that ( U ) = [

X( U )] and ( R ) = [ X( R )]; we can use
these laws to construct an elementary set of formulas. An
elementary set of formulas with respect to the closure of is
a maximal, consistent subset of cl(). A cover C of a set of

formulas is a set of sets C = C0 , C1 , . . . such that

Ci C Ci . In other words, any computation satisfying the

conjunction of the formulas in the set also satisfies the
conjunction of the formulas in at least one of the cover sets
Ci C. An elementary cover is a cover comprised exclusively of
elementary (maximal, consistent) sets of formulas.
We define each elementary cover set Ci C for the cover C
of formula to have the following properties:
1. Ci cl()
2. Ci is logically consistent (i.e. does not contain any logical
contradictions). Specifically, for all subformulas ,
cl(),
Ci Ci
Ci , Ci .
Ci ( Ci ) or ( Ci ).
3. Ci is temporally consistent (i.e. logically consistent with
respect to temporal operators). We use to denote
subformulas that are syntactically implied by a set Ci .
( U cl()) [( Ci ) ( U Ci )].
[( U Ci ) ( Ci )] ( Ci ).
( R cl()) [( Ci ) ( R Ci )].
4. Ci is maximal. That is, for every subformula cl(), either
Ci or Ci .
We can obtain an elementary cover of by applying
the expansion laws to until is a propositional formula
in terms of only constants (true or false), propositions, or
X-rooted subformulas. Then has no U- or R-formulas
occurring at the top level. We convert this expanded formula
into disjunctive normal form (DNF) to obtain the cover. Each
disjunct is an elementary set and the set of disjuncts is the
elementary cover of . We round out each set Ci with the
formulas in cl() that are syntactically implied by Ci according
to the rules listed above. We define a state in our automaton
A for each cover set Ci in the cover of . We label each such
state with the subformulas in the elementary set to which it
corresponds. (Note that the states in the cover of will be
labeled by .) We will use the X-subformulas of each state to
define the transition relation.
Define q0 as the state or set of states in the cover of
(i.e. those labeled by ). If there is more than one such state

and we do not want to define q0 to be a set of initial states, we

can create a singular start state with outgoing -transitions12
to all such states. That is, for -labeled states s0 , s1 , . . . , we
define (q0 , ) = s0 ; (q0 , ) = s1 ; . . ..
Initially, we set Q = q0 , which is the cover of . For each
state q Q, we apply the expansion laws and compute the
successors of q as a cover of { : X q}. For each computed
successor state q of q, we add a transition in , creating a new
state q Q if necessary. That is, q , : (q, ) = q , X q
q . We iterate in this fashion until all X-subformulas of all
of the states in Q have been covered. The result is a closed set
of elementary covers, such that there is an elementary cover in
the set for each X-subformula of each disjunct of each cover
in the set.13 Constructed in this way, Q is at most the set of
all elementary sets of formulas in the closure of (2cl() ) and
is thus bounded by 2O(||) .
Finally, we define the acceptance conditions, ensuring that
each U-subformula is eventually fulfilled and not simply
promised forever. We do this by creating for every subformula
of of the form U a set F U F containing all states
labeled by , which fulfill the U-subformula, and all states
not labeled by ( U ), which do not promise it. This is the
basic construction by Daniele, Giunchiglia, and Vardi [114].
We prove each direction separately based upon these
definitions.
If: L (A ) |H ()
Presume L (A ). Then there is an accepting run in
A that we will label = q0 , q1 , . . . which, by definition of
Q, corresponds to the sets C0 , C1 , . . .. By the definition of q0
as the cover of , we know that holds in this state. Stated
another way, the atomic propositions that are true in q0 are
true in the first time step of a satisfying computation of ;
0 C0 . It remains to show that the transition relation and
acceptance conditions imply that |H (), or, in other words,
(C0 Prop)(C1 Prop)(C2 Prop) . . . |H . We show by structural
induction on the structure of cl() that C0 |H ().
Base case: || = 1. Then Prop. The claim follows from
the definition of the labeling of states in Q, i.e. that in our
construction, Ci = { cl()|(Ci Prop)(Ci+1 Prop)(Ci+2
Prop) . . . |H }.
Induction step: Presume the claim holds for subformulas
, cl(). Then it holds for:
1. = . The claim follows from the definition of the
labeling of states in Q.
2. = X. From the definition of , X Ci qi+1 , :
(qi , ) = qi+1 , Ci+1 . Therefore, Ci |H ().
3. = . The claim follows from the definition of the
labeling of states in Q.
4. = . The claim follows from 1, 3, and DeMorgans law.
12 We refer to as the empty string. The presence of a
-transition in a nondeterministic automaton indicates that the
automaton may traverse that transition at any time, without
progressing any further along the computation path.
13 Note that any LTL formula has infinitely many elementary
covers and which one is chosen for this construction in
practice can significantly affect the performance of the modelchecking problem. Thus, many researchers study optimizing this
construction [113119,9].

COMPUTER SCIENCE REVIEW

5. = U . If |H then there is some i 0 such

that i , i+1 , . . . |H and j : 0 j < i, j , j+1 , . . . |H .
From our induction hypothesis, we have that Ci and
Cj . By induction we have that U Ci , Ci1 , . . . , C0 .
From our construction, if ( U ) C0 then either i
0 : , X( U ) Ci and Ci or i 0 : Ci and
j : 0 j i, , X( U ) Ci . Since we know that , the
run of in A , is accepting, by the definition of F, only the
latter case is possible. Therefore, C0 |H ().
6. = R. The claim follows from 1, 5, and the definition of
R.
Only if: |H () L (A )
Since q0 is defined by the cover of , there must be a state
q q0 such that 0 |H q. In general, we want to show that
i : i 0, i |H qi , so we show how to choose i+1 . We know
there is a set Ci+1 (Ci , i ) such that i , i+1 , . . . |H Ci , Ci+1 , . . .
since for all i:
The atomic propositions that are true in 0 are true in the
state qi of our run: i Ci .
For every formula of the form X in Ci , we know that
i , i+1 , . . . |H X, which means i+1 , i+2 , . . . |H , so
Ci+1 .
For every formula of the form U in Ci , we know that
i , i+1 , . . . |H U , which means either i , i+1 , . . . |H ,
so Ci , or i , i+1 , . . . |H X( U ), so Ci and
( U ) Ci+1 .
Furthermore, we know from the definition of F that for all
subformulas of the form ( U ) cl(), there is a set F U F
containing all Ci : ( Ci ) (( U ) Ci ). We can choose an
accepting run as follows. Let U be the set of U-subformulas
not fulfilled in the current state, Ci . Then , : (( U )
Ci ) Ci , (X( U ) Ci ). For each such formula in U
in succession, we choose the shortest path from the current
state to a state that contains , thus fulfilling the claim. We
know there must exist such a path for each U-subformula by
the construction of such that X Ci Ci+1 , and by
the definition of F. Note that if some state Ci F U , then
(( U ) Ci ) and ( Ci ) and, also, i , i+1 , . . . |H ( U ) but
i , i+1 , . . . |H . This creates a contradiction since we know
that |H (), by definition of Bchi acceptance, necessitates
that passes through a state in each set F U F infinitely
often. 
This theorem reduces LTL satisfiability checking to
automata-theoretic nonemptiness checking, as is satisfiable
iff models() = iff L (A ) = .14

3.5.

The two types of properties

There are two fundamental properties we can prove about

programs: safety and liveness. These categories were originally
introduced by Leslie Lamport [120]. They are also referred to
as invariance and eventuality, respectively [59]. Distinguishing
between the two types of properties is helpful because
different techniques can be used to prove each type
[121,122]. For example, taking advantage of the structure of
14 For another version of this proof with several illustrative
examples, see [72].

17

safety properties can be used to optimize assume-guarantee

reasoning [122]. Showing a safety property holds involves
an invariance argument while liveness properties require
demonstration of well-foundedness. Here, we adapt the
formal definitions of safety and liveness from Alpern and
Schneider [123]. Kindler [124] provides a complete survey of
historical (and sometimes conflicting) definitions.
Intuition 1. A Safety Property expresses the sentiment that
something bad never happens.
In general, safety properties take the form good, where
good is a temporal logic formula describing a good system
behavior. In other words, the system always stays in some
allowed region of the state space. Recall that LTL properties
are interpreted over computations, which are infinite words
over the alphabet = 2Prop where Prop is the set of atomic
propositions in the formula. Intuitively, something bad only
needs to happen once in a computation for the property to be
violated; what happens after that in the infinite computation
does not affect the outcome of the model checking step.
Therefore, if a safety property is violated, there must
be some finite prefix = 0 , 1 , . . . , i of the computation
in which this violation occurs. Then, for any infinite
computation over the alphabet , the concatenation of
computations cannot satisfy .
Safety properties were first formally defined in [125]. For
property , infinite computation = 0 , 1 , . . . , and alphabet
= 2Prop , we define safety as follows:
(, : |H (i, 0 i : (, : 0...i |H ))),
where is the concatenation operator and denotes the set
of infinite words (or -words) over .
Restated, is a safety property satisfied by computation
if and only if for all lengths of finite prefixes of , that
finite prefix concatenated with some infinite computation
models . This is the contrapositive of the statement that
if |H then there is some finite prefix of in which
something bad happens that cannot be extended into an
infinite computation that will satisfy .
We can also define a safety property in terms of language
closure [123]. In Section 3.4 we translate the LTL formula into a
Bchi automaton. The closure of a reduced Bchi automaton
is obtained by making all states accepting states. (A Bchi
automaton is reduced if there is a path to an accepting state
from every state in the automaton; i.e. there are no dead end
trap states.) A closure of an automaton representing a safety
property must accept all prefixes of the language defined by
that property.
Lemma 3. A reduced Bchi automaton A specifies a safety
property if and only if L (A ) = L (cl(A )).15
Examples of safety properties include invariance, partial
correctness, mutual exclusion, ordering (i.e. first-come-firstserve), deadlock freedom, and reachability. Safety properties
are also called invariance properties because they describe
15 Note that Sistla showed that the problem of determining
whether an LTL formula, or the nondeterministic Bchi
automaton representing it, express a safety property is PSPACEcomplete [126].

18

COMPUTER SCIENCE REVIEW

predicates that do not change under a set of transformations.

Proving partial correctness of a sequential program provides
assurance that the program never halts with a wrong
answer. Mutual exclusion prohibits the simultaneous use of
a common resource by multiple processes (i.e. two processes
cannot write to the same file at the same time). Ordering
of events, such as first-come-first-served, forbids service out
of the established order. Freedom from deadlock ensures
that the system will never reach a standstill from which
no progress can be made, such as when all processes are
simultaneously locked out of, and waiting on, a common
resource. In a sense, reachability is the dual of safety as it
is an assurance that a certain program state can be reached
(i.e. (good)).
In the case of our air traffic control example, a
safety property we want to check is that no conflict
goes unaddressed. More specifically, whenever a conflict
is detected, TSAFE immediately issues a command to
resolve it. In LTL, we would express this safety property
as (TSAFE_clear X(TSAFE_command)). Another safety
property we want to check is the absence of conflicting
commands. That is, both TSAFE and the auto-resolver cannot
issue commands to the aircraft at the same time. In LTL, this
is ((AR_command TSAFE_command)).
Intuition 2. A Liveness Property expresses the sentiment that
something good must eventually happen.

Typically, liveness properties express good, where good

once again is a temporal logic formula describing a good
system behavior. Whereas safety properties reason about
reaching specific states, liveness properties reason about
control flow between states. Liveness is loosely defined as a
programs ability to execute in a timely manner.
Let f inite be the set of all finite computations over . For
property , we define liveness as follows:
(, f inite : (, : |H )),
where is the concatenation operator.
The formal definition of liveness is basically defined
oppositely from safety. In short, there is no finite prefix over
that cannot be extended into an infinite computation that
satisfies . Intuitively, this corresponds to the notion that the
something good that satisfies the property can still happen
after any finite execution.
As with safety, we can also frame the definition of liveness
in terms of language closure of reduced Bchi automata. If A
is a reduced Bchi automaton then a computation is not in
cl(A ) if and only if it attempts to traverse a transition that is
not defined in the transition relation for A .16 Furthermore,
since every finite prefix of liveness property can be extended
into an infinite computation that satisfies , then the closure
of A actually accepts all infinite words over the alphabet .
Lemma 4. A reduced Bchi automaton A specifies a liveness
property if and only if L (cl(A )) = .
16 Bchi

automata and the transition relation are formally

defined in Section 3.4.

Liveness properties are also called eventualities since they

promise that some event will happen, eventually. In other
words, the system will eventually progress through useful
states, even if some stuttering is allowed. Termination is
a liveness property; it asserts the program will eventually
halt instead of hanging forever. Other examples of liveness
properties include total correctness, accessibility/absence
of starvation, fairness (also called justice), compassion
(also called strong fairness), and livelock freedom. Total
correctness extends partial correctness with termination; it
states that not only must the program not terminate in a bad
state, the program must terminate in a good state. Starvation
occurs when a process is unable to make progress due to
insufficient access to shared resources; it is assuaged by
assuring regular accessibility to necessary resources. Fairness
guarantees each process the chance to make progress while
compassion extends fairness to include the existence of
sets of cyclically recurring system states. A fair scheduler
executes a process infinitely often while a compassionate
scheduler ensures that a process that is enabled infinitely
often is executed infinitely often. Freedom from livelock
means that the system will never reach a live standstill, where
the processes in question cannot make progress yet are not
blocked but thrashing indefinitely. An intuitive example of
livelock occurs when two people try to pass each other in the
hallway yet repeatedly step to the same side of the hallway
in an effort to let the other person pass. Both people are still
walking but they are now oscillating side-to-side instead of
making progress forward.
Common examples of liveness properties include: every
request will eventually be granted, a message will eventually reach its destination, and a process will eventually enter
its critical section. In the case of our air traffic control example, a liveness property to check is that all conflicts are eventually resolved: (TSAFE_clear
TSAFE_clear). We may
also want to check that every request, either from the controller or from the aircraft, is addressed by the system, either
granted or ignored. This adds two more liveness properties to
our specification: (controller_request controller_request)
and (aircraf t_request aircraf t_request).

Model checking of safety properties is simpler than

model checking of liveness properties. Due to the temporal
structure of liveness properties, they must be witnessed by
an infinite counterexample in the shape of a lasso. That is,
a counterexample with a finite prefix leading to a bad cycle
that represents an unending run of the system in which
the liveness property is never fulfilled. Safety properties,
on the other hand, are always violated within the finite
prefix, eliminating the need to compute the remainder of
the counterexample corresponding to the loop at the end of
the lasso. Intuitively, a safety property is violated the first
instance the system enters some prohibited state. Though we
provide the full model-checking algorithm for all possible LTL
specifications in Section 5, a simpler check using symbolic
reachability analysis can be used instead to check only safety
properties [122].
With only one exception, safety and liveness properties are
disjoint. The only property that is both a safety and a liveness
property is the property true, which describes all possible

COMPUTER SCIENCE REVIEW

behaviors, or the words in the set (2Prop ) .17 The proof of this
statement follows from the definitions of safety and liveness
above, specifically L (true) = L (cl(true)) = . Remarkably,
while every LTL formula is not strictly either a safety or a
liveness property, Alpern and Schneider [127] proved that
every LTL formula is a combination of a safety and a liveness
property.

19

1. Negate f and declare the set APf of atomic propositions of

f.
2. Build el_list, the list of elementary formulas in f :
el(p) = {p} if p AP.
el(g) = el(g).
el(g h) = el(g) el(h).
el(g h) = el(g) el(h).

3.6.

Specifying the property as an automaton

Instead of using a temporal logic to describe a behavioral property, we can use an automaton directly. Many
model checkers, like NuSMV and CadenceSMV, will accept specifications in either format and some, like Lucents
FormalCheck [128], deal exclusively with automata inputs.
However, complementing a Bchi automaton is quite difficult
(and likely involves the expensive step of determinization)
whereas complementing an LTL formula can be done in constant time by simply preceeding the formula with a negation
symbol. Currently, the best time complexity for complementation of Bchi automata is 2O (n log n) [129] but this is still an
open area of research [130132]. Advantages of this method
include the ability to directly and efficiently construct the
automaton A rather than relying on an LTL-to-Bchi translation, while disadvantages include the unintuitiveness of representing a behavior specification as an automaton.

3.7.

LTL Symbolic GBA

Given an LTL specification , the model checker creates a

generalized Bchi automaton A , that recognizes precisely
the executions that do not satisfy , and is destined
for composition with the model under verification. The
size of A is O (2|| ) in the worse case, which provides
motivation for utilizing a succinct, symbolic representation
instead of explicitly constructing the automaton. Symbolic
model checkers, such as NuSMV [20], CadenceSMV [19], SALSMC [50], and VIS [21], represent and analyze the system
model and specifications symbolically. In the symbolic
representation of automata, states are viewed as truth
assignments to Boolean state variables and the transition
relation is defined as a conjunction of Boolean constraints
on pairs of current and next states [22]. All symbolic model
checkers use the LTL-to-symbolic automaton translation
described in [23], some with minor optimizations. Essentially,
these tools support LTL model checking via the symbolic
translation of LTL to a fair transition system which can be
checked for nonemptiness. Recall that fairness constraints
specify sets of states that must occur infinitely often in any
path. They are necessary to ensure that the subformula
holds in some time step for specifications of the form U
and . We enumerate the steps of the standard LTL-tosymbolic automaton algorithm [23], in detail, below. Bolded
steps are those that produce output that appears in the
symbolic automaton.

el(Xg) = {Xg} el(g).

el(g U h) = {X(g U h)} el(g) el(h).
el(g R h) = {X(g R h)} el(g) el(h).
el(g) = {X(g)} el(g).

el( g) = {X( g)} el(g).

3. Declare a new variable ELXg for each formula Xg in the
list el_list.
4. Define the function sat(g), which associates each elementary subformula g of f with each state that satisfies g:
sat(g) = {q|g q} where g el(f ), q Q.
sat(g) = {q|q sat(g)}.
sat(g h) = sat(g) sat(h).
sat(g h) = sat(g) sat(h).
sat(g U h) = sat(h) (sat(g) sat(X(g U h))).
sat(g R h) = sat(h) (sat(g) sat(X(g R h))).
sat(g) = sat(g) sat(X(g)).

sat( g) = sat(g) sat(X( g)).

5. Add fairness constraints to the SMV input model:
{sat((g U h) h)|g U h occurs in f }.
{sat((

 g) g)| g occurs in f }.

Note that we do not add a fairness constraint for

subformulas of the form g R h. While R is the dual of U, it
is acceptable if h is true infinitely often and g is never true.
6. Construct the characteristic function Sh of sat(h). For each
subformula h in f :
Sh = p
Sh = ELh
Sh
Sh
Sh
Sh

=!Sg
= Sg1 |Sg2
= Sg1 &Sg2
= Sg2 |(Sg1 &SX

(g1 U g2)

Sh = Sg2 &(Sg1 |SX

(g1 R g2)

)
)

if p is an atomic
proposition.
if h is elementary formula
Xg in el_list.
if h = g
if h = g1 g2
if h = g1 g2
if h = g1 U g2
if h = g1 R g2

Sh = Sg &SX(g)

if h = g

Sh = Sg |SX

if h =

g)

g

7. For each subformula rooted at an X, define a TRANS

statement of the form:
TRANS (S_X_g = next(S_g))

Input: An LTL formula f .

8. Print the SMV program. (Since we type code in ASCII

text, the operators  and
are represented in SMV
syntax by their alphabetic character equivalents, G and F ,
respectively.) (See Box III.)

17 Note was originally defined by Cantor to be the lowest

transfinite ordinal number so (2Prop ) designates the set of all
infinite words over the alphabet = 2Prop .

Proof of the correctness of this LTL-to-symbolic-automaton

construction is given in [23].

20

COMPUTER SCIENCE REVIEW

Box III.

3.8.

Air traffic control example: specifications

Specifications are the temporal logic formulas we supply to a

model checker to describe the desirable behaviors the system
we are checking must have. It is usually helpful to keep in
mind the goal of specifications while writing them. In general,
the purpose of the system model to the model checker is
to answer the question What does the system do? The
purpose of the set of specifications is to answer the question
What should the system do? We are basically saying to
the model checker, Heres how the system works; please
verify that it has the list of emergent behaviors described by
our specification set. To that end, we design specifications
such that each specification describes a particular desirable
behavior and the entire set of specifications describes a
coherent pattern of behavior.
We have discussed earlier in this section issues relating
to the set of specifications, such as the necessity of checking
that each specification, and the set of specifications as a
whole, are satisfiable and checking that each specification,
and each part of each specification, contributes to the
behavioral description (vacuity checking). Another concern
when authoring a set of specifications is that of coverage,
or ensuring that behaviors across the entire system state
space are described by the set of specifications. There are
several metrics to determine coverage of the model by the
set of specifications but that is a large and active area of
research beyond the scope of this paper. For this example,
we simply check that we have described different types of
behaviors, specifying both safety and liveness conditions, and
adequately utilized the system variables.
We have already written some specifications for our
automated air traffic control architecture in Section 3.5. Here
they are again, as a set:

Liveness: Every conflict is addressed

(TSAFE_clear TSAFE_command)
Or, we can choose to specify a stricter version of this
property:
Safety: Every conflict is addressed immediately (i.e in one time
step)
(TSAFE_clear X(TSAFE_command))
Safety: The system will never issue conflicting commands
((AR_command TSAFE_command))
Liveness: All conflicts are eventually resolved
(TSAFE_clear TSAFE_clear)
Liveness: All controller requests are eventually addressed
(controller_request controller_request)
Liveness: All aircraft requests are eventually addressed
(aircraf t_request aircraf t_request)

We again use the model checker NuSMV to illustrate the

next step in the symbolic model-checking process. We add
our specifications to the end of the file in which we have
specified the system model, each prefaced with the label
LTLSPEC. (See Box IV.)
We will take the first specification in our set, (
TSAFE_clear
TSAFE_command), as an example of the
processing of specifications under the hood in a symbolic
model checker. Following the steps enumerated in Section 3.7,
NuSMV constructs internally a symbolic automaton that
looks something like the one given in Box V.

4.
Representing the combined system and
property using BDDs
The basis for symbolic model checking is the realization
that both the system model and the specification property
can be represented symbolically, using Boolean equations,

COMPUTER SCIENCE REVIEW

21

Box IV.

Box V.
rather than explicitly, using automata. Furthermore, they
can be manipulated efficiently using operations over Binary
Decision Diagrams (BDDs). Symbolic representation and
manipulation of the intermediate products of model checking
leads to much more succinct structures needing to be
stored in computer memory, thereby directly combating the
state explosion problem. Certainly there are pathological
constructions of systems that do not benefit substantially
from this space reduction, but symbolic model checking
increases the scalability of model checking for a great many
common systems, especially those with regular structure
such as hardware circuits [53,27].
In this section, we will demonstrate how the automaton
AM, can easily grow to a size that cannot be practically
represented in memory and present the most popular
alternative representation, which uses BDDs to mitigate
this problem. The technique of symbolic model checking was
introduced by McMillan [25] in 1992 specifically as a response
to the state explosion problem. The power of symbolic model
checking derives from using equations describing sets of
states and sets of transitions to implicitly define the state
space, thereby using significantly less memory than explicit
representations that may enumerate the entire state space.
Most symbolic model checkers utilize BDDs to accomplish
this task, though other approaches are possible [133].
Boolean equations of the sort used to describe the
transition systems plied by symbolic model checking are

commonly represented in a variety of ways, such as truth

tables and Binary Decision Trees (BDT), which are exponential
in the size of the formulas they represent.
Definition 8. A Binary Decision Tree (BDT) is a rooted,
directed, acyclic graph (DAG) with vertices labeled by the n
variables of the corresponding Boolean formula. Each variable
node has exactly two children representing the two possible
assignments to that variable, 0 and 1, labeled low and high,
respectively. (Note that, except for the root, each node has
exactly one parent.) A path through the BDT represents a
valuation of the represented function given an assignment
of values to the n variables; it starts at the root, follows the
outgoing edge matching the assignment to the variable in the
current vertex, and terminates in a vertex labeled either 0 or
1, corresponding to the value of the formula for that variable
valuation. The BDT representing a formula over n variables
has 2n 1 variable vertices plus 2n terminal vertices in {0, 1},
for a total size of 2n+1 1 nodes.
A BDD is a refinement of a BDT. While in the worst case,
a BDD is only roughly half the size18 of its equivalent BDT,
usually there is more significant improvement gained by the
following construction.
18 Eliminating duplicate terminal nodes from a BDT of size 2n+1
1 with 2n terminal vertices leaves a BDD of size 2n + 1 nodes.

22

COMPUTER SCIENCE REVIEW

Definition 9. A Binary Decision Diagram (BDD) is a rooted,

directed, acyclic graph (DAG) with internal vertices labeled by
some sufficient subset of the n variables of the corresponding
Boolean formula and exactly two terminal vertices, labeled
0 and 1. Each variable node has exactly two children
representing the two possible assignments to that variable, 0
and 1, labeled low and high, respectively. (Note that, except for
the root, each node may have any number of parents.) A path
through the BDD represents a valuation of the represented
formula given an assignment of values to the n variables;
it starts at the root, follows the outgoing edge matching
the assignment to the variable in the current vertex, and
terminates in the vertex corresponding to the value of the
formula for that variable valuation.
A BDD is considered ordered if it follows a given total order
of variables from root to leaves. Note that not all variables
may appear in the tree or along any path in the tree; a
variable only appears along a path if its value influences
the value of the formula, given the assignments to previous
variables along the path. If we are reasoning over multiple
ordered BDDs (OBDDs), they are presumed to all follow the
same variable ordering. A BDD is reduced if it contains no
vertex v such that low(v) = high(v) and no pair of vertices
v1 and v2 such that the subgraphs rooted by v1 and v2 are
isomorphic. That is, if there is a one-to-one function f such
that for any vertex v1 in the subgraph rooted at v1 , for some
vertex v2 in the subgraph rooted at v2 , f (v1 ) = v2 implies
that either v1 and v2 are both terminal vertices with the
same value, or v1 and v2 are both non-terminal vertices with
the same variable label and the property that f (low(v1 )) =
low(v2 ) and f (high(v1 )) = high(v2 ), then either v1 or v2 will
be eliminated. Note that each path realizes a unique set of
variable assignments; each variable valuation corresponds to
exactly one path. Furthermore, every vertex in the graph lies
along at least one path; no part of the graph is unreachable.
In practice, any non-reduced BDD can be easily reduced
by applying two reduction rules. The redundancy elimination
rule removes any non-terminal node v1 where low(v1 ) =
high(v1 ) = v2 and connects all incoming edges of v1 directly to
v2 instead. The isomorphism elimination rule removes vertex v1
wherever there exists a vertex v2 such that var(v1 ) = var(v2 ),
low(v1 ) = low(v2 ), and high(v1 ) = high(v2 ) and redirects all
incoming edges of v1 directly to v2 . (We use var(v) to denote
the variable labeling vertex v.) Note that v1 and v2 may be
either terminal or non-terminal vertices; this rule eliminates
duplicate terminals as well as isomorphic subgraphs. A nonreduced BDD can be reduced in a single pass of the tree by
careful application of these two rules in a bottom-up fashion.
An example of reducing a Binary Decision Tree into a BDD
is given in Fig. 9. All three subfigures represent the formula
x1 x2 x3 with varying degrees of succinctness as each of
the two reduction rules is applied.
When BDDs are both reduced and ordered (also called
ROBDDs), they have many highly desirable properties. In this
paper, we consider all BDDs to be both reduced and ordered;
the algorithms used for symbolic model checking, and for
efficient BDD manipulation in general, all maintain these
properties. Reduced ordered BDDs are closed under the class
of symbolic operations, as outlined in Section 4.3. These
include A PPLY and S ATISFY- ONE, which form the basis for the
symbolic model-checking algorithm.

Using BDDs to reason about Boolean formulas representing the state space offers many advantages over explicit automata representations:
Complexity (both time and space): BDDs provide reasonably
small representations for a large class of the most
interesting, and most commonly-encountered, Boolean
functions. For example, all symmetric functions, including
the popular even and odd parity functions, are easily
represented by BDDs where the number of vertices grows
at most with the square of the number of arguments
to the function. Moreover, since our BDDs are reduced
and ordered, they have the property of minimality. This
means if B is a BDD representing a function f , then
for every BDD B that also represents f and has the
same variable ordering as B, size(B) size(B ). Even
better, we can frequently avoid enumerating the entire
state space. Specifically, we can express tasks in several
problem domains entirely in terms of graph algorithms
over BDDs, describe automata in terms of sets of states
and transitions, or use other techniques along those lines
to express only relevant portions of the state space. Since
all of the algorithms used for symbolic analysis of BDDs
have complexities polynomial in the sizes of the input
BDDs, the total computation remains tractable as long as
the sizes of the input BDDs are reasonable. The sum of
these time-and-space advantages allows us to use BDDs
for solving problems that may scale beyond the limits
of more traditional techniques such as case analysis or
combinatorial search.
Canonicity: There is a unique, canonical BDD representation for every Boolean function, given a total variable ordering. This property yields very simple algorithms for the
most common BDD operations. Testing BDDs for equivalence just involves testing whether their graphs match
exactly. Testing for satisfiability reduces to comparing the
BDD graph to that of the constant function 0. Similarly, a
function is a tautology iff its BDD is the constant function
1. Testing whether a function is independent of a variable
x involves a simple check of whether its BDD contains any
vertices labeled by x. Note that this is an important advantage over explicit automata representations since there
is no canonical automaton representation for any class of
automata.
Efficiency: Besides the benefits that directly follow from
canonicity,
BDD
representation
enables
efficient
algorithms for many basic operations, including intersection, complementation, comparison, subtraction, projection, and testing for implication. The time complexity of
any single operation is bounded by the product of the
graph sizes of the functions being operated on or, for
single-BDD operations like complementation, proportional
to the size of the single function graph. In other words, the
performance of directly manipulating BDDs in a sequence
of operations degrades slowly, if at all.
Simplicity: The BDD data structure and the set of
algorithms for manipulating BDDs are conceptually and
implementationally simple.
Generality: BDDs can be used for reasoning about all kinds
of finite systems, basically any problem that can be stated
in terms of Boolean functions. They are not tied to any
particular family of automata; they are just as useful
for LTL symbolic model checking as they are for the
extensions of LTL described in Section 3.2.4, for example.

COMPUTER SCIENCE REVIEW

The notion of using Binary Decision Diagrams to reason

about Boolean functions was first introduced by Lee in
1959 [134] and later popularized by Akers who evinced the
utility of BDDs for reasoning about large digital systems [135].
Fortune, Hopcroft, and Schmidt [136] restricted the ordering of
the decision variables in the vertices of the graph, creating the
canonical form of Ordered Binary Decision Diagrams (OBDDs)
(though they called them B-schemes), noting the significance
of variable ordering on graph size, and showing the ease
of testing for functional equivalence. Bryant, who coined
the term OBDDs, ameliorated ordered BDDs to symbolic
analysis by demonstrating efficient algorithms for combining
two functions with a binary operation and composing two
functions [137,138].

4.1.

Combining the system and property representations

We directly construct the product, AM, , of the system

model automaton M and the automaton representing the
complemented specification A . This construction logically
follows from the realization that the product of these
two automata constitutes the intersection of the languages
L (M) and L (A ) [139]. Recall from Section 3.2.4 that
Bchi automata are automata that accept exactly the
class of -regular languages. Furthermore, the class of regular languages corresponds exactly to the languages
that can be described by -regular expressions and is
closed under the operations of union, intersection, and
complementation [140]. Therefore, we can construct a Bchi
automaton AM, such that L (AM, ) = L (M)L (A ) since
L (AM, ) is an -regular language.
Intuitively, AM, simulates running the two multiplicand
automata in parallel, also called the synchronous parallel
composition of M and A . Executing these two automata
simultaneously allows us to use A to continuously monitor
the behavior of M and judge whether M satisfies the desired
property at all times.19
The states of AM, are pairs of states, one each from M
and A , plus a track label t {0, 1}. (For simplicity, we call a
state in MqM and a state in A q .) A run of AM, starts in
the pair of the two start states in track 0: (q0M , q0 , 0). Upon
reading a character , AM, transitions from the current
state, q = (qM , q , t), to a next state, q = (qM , q , t), wherever
M transitions from the M-component of q, qM , to the Mcomponent of q , qM , upon reading and A also transitions
from its associated component, q , to q upon reading . The
value of t remains the same unless either t = 0 and qM FM
or t = 1 and q F , in which case the t-bit flips. In essence,
the two tracks ensure AM, starts in track 0, passes through
a final state in M, switches to track 1, passes through a final
state in A , switches back to track 0, and repeats the pattern.
We assign the set of final states in AM, to essentially match
those of M since the path of any run only returns to track 0 if it
has previously passed through an accepting state of M in track
19 Systems can also be composed asynchronously, where is
defined such that it is possible for either M or to progress
while the other does not transition and the values of any system
variable specific to the non-transitioning system are preserved.
However, this type of composition does not further the modelchecking algorithm presented here.

23

0 and an accepting state of A in track 1. Since the accepting

condition for a Bchi automaton necessitates visiting the set
of final states infinitely often, visiting infinitely often a state
whose M-component is in FM while in track 0 suffices. This
construction is necessarily more complex than the straight
Cartesian product [139] of the two automata, M A , since we
must allow for runs that pass infinitely often through final
states in both M and A , but not necessarily at the same
time. (For an illustrative example, see [110].) Note that since
q0 is defined as the state(s) labeled by , the initial state(s)
our product automaton, AM, must also be labeled by .
We presume that the alphabets of both automata are
the same, a reasonable assumption considering that the
formula describes a behavior of the system M. However,
our construction is unchanged by defining the alphabet of
AM, to be the union of the alphabets of M and A if those
alphabets differ.
Formally, we define AM, as follows.
Definition 10. Let M = (QM , , M , q0M , FM ) and A =
(Q , , , q0 , F ). The intersection automaton AM, with
the property that L (AM, ) = L (M) L (A ) is the automa , ,

(q0M , q0 , 0), F)
ton defined by the quintuple AM, = (Q,
where:
State set Q = QM Q {0, 1} consists of triples (qiM , qj , t).

is the shared alphabet.

Transition relation is defined such that AM, is in state
(qiM , qj , t) whenever M is in state qiM and A is in state

qj . For any ,

iM , qj , t), ) = (qkM , ql , t),

((q

whenever
M (qiM , ) = qkM
and
(qj , ) = ql

unless
t=0

and

qiM FM ,

or
t=1

and

qj F

in which case
iM , qj , t), ) = (qkM , ql , t).
((q

The initial state is (q0M , q0 , 0).

The set of final states F is the set of all states (qiM , qj , 0)
such that qiM FM and qj Q .

Theorem 5. Bchi automata are closed under complementation.

Let A = (Q, , , q0 , F) be a Bchi automaton that accepts
the language L. The construction of the Bchi automaton A
that accepts the complement language L is rather involved.
It does not suffice to simply complement the accepting set
F (i.e. let A = (Q, , , q0 , Q F)) because a run not passing
through any state in F infinitely often is different from a
run passing through some state in Q F infinitely often. For
example, an accepting run of A on the word w might pass
through both states in F and in Q F infinitely often, so both
A and A would accept w. Thus, L (A ) = L (A). The
complex construction proving Theorem 5 is given in [108],
which yields a doubly exponential construction for A and

24

COMPUTER SCIENCE REVIEW

in [83], which reduces the construction to singly exponential

with a quadratic exponent. Specifically, for Bchi automaton
A, over the alphabet , there is a Bchi automaton A with
2O (|Q| log |Q|) states such that L (A) = L (A) [129]. Michel
proved that this is an optimal bound [141].
As an important aside, since Bchi automata are not
closed under determinization and nondeterministic Bchi
automata are more expressive than deterministic Bchi
automata, the complement automaton A produced by these
algorithms for some deterministic Bchi automaton A
may be a nondeterministic Bchi automaton that cannot
be determinized. Efficient methods for constructing and
reasoning about complemented Bchi automata remain
an area of interest. For example, we can check A
for nonuniversality (i.e. L (A) = ) in polynomial
space by constructing A on the fly and checking for
nonemptiness [110].
Theorem 6. L (AM, ) is an -regular language and AM, is a
Bchi automaton.
Proof of Theorem 6. Recall that LM = L (M) is an -regular
language since it is the language accepted by a Bchi
automaton and that L = L (A ) is also an -regular
language since is an LTL formula, which describes a
(-free) -regular expression. We know that L (AM, ) = LM
L is an -regular language, and, therefore, that AM, is
a Bchi automaton because -regular languages are closed
under intersection. First, we offer proof of closure under
union; closure under intersection follows from closure under
union and complementation.
By definition of -regular languages, there exist -regular
expressions rM and r that describe the languages LM and L ,
respectively. That is, LM = L (rM ) and L = L (r ). By definition
of -regular expressions, rM + r is an -regular expression
denoting the language LM L , which demonstrates closure
under union.
Closure under intersection now follows from DeMorgans
Law:
LM L = LM L .
By closure under complementation, LM and L are both regular languages. By closure under union, LM L is an regular language. Again by closure under complementation,
LM L = LM L
is an -regular language. By definition of -regular languages,
it follows that AM, is a Bchi automaton. 
Theorem 7. Let LM = L (M) and L = L (A ). Given an infinite
word w = w0 , w1 , w2 , . . . , w LM L if and only if it is
accepted by AM, .
Proof of Theorem 7.
If-direction: w LM L w is accepted by AM, .
An infinite word w is in the language LM L if w LM and
w L . By definition, w LM iff w represents an accepting
execution of the Bchi automaton M. Symmetrically, w L
iff w is accepted by the automaton A corresponding to the
LTL formula . Then we know that
M (q0M , w) transitions
through some final state qiM FM infinitely often and that

(q0 , w) similarly transitions through some accepting state

qj

AM, is in state
F infinitely often. By definition of ,

(qiM , qj ) exclusively when M is in state qiM and A is in state

qj upon reading the same word. That is, for any w,

((qiM , qj ), w) = (qkM , ql ),

whenever
and

M (qiM , w) = qkM

(qj , w) = ql .

w is
Since whenever qiM FM and qj F , (qiM , qj ) F,

accepted by AM, .
Only-if direction: w is accepted by AM, w LM L .
By definition, an infinite word w is accepted by AM,
if the run over w in AM, visits at least one state in F
infinitely often. That is, ((q0M , q0 ), w) transitions infinitely
By construction,
often through some state (q , q ) F.
iM

for any w, ((q0M , q0 ), w) = (

M (q0M , w), (q0 , w)). By
(q , q ) iff q FM and q F . Therefore,
definition of F,
iM
j
iM j
(q
,
w)
transitions
through qiM FM infinitely often and

M 0M
w LM . Symmetrically,
(q0 , w) transitions through qj F

infinitely often and w L . Ergo, w LM L .

The product automaton AM, has size O (|M| |A |) in

the worst case. (Though the product can be much smaller;
in the best case, it has size 0 [8].) Due to this size blowup, representing the automaton as succinctly as possible
becomes vital to palliate the state explosion problem and
ensure AM, can be stored in computer memory. It is easy
to see that even small differences in the sizes of both M and
A can have a significant impact on our ability to store, and
to reason about, AM, . We must choose a representation of
AM, that minimizes the storage memory requirement while
maximizing the efficiency of the nonemptiness check. We
accomplish this task by representing AM, using BDDs.

4.2.

Representing automata using BDDs

Recall that AM, is a Bchi Automaton with finite set of

states Q, defined by assignments to the variables in the
alphabet , and transition relation : Q Q. We

consider state qi Q as a tuple qi , 0 , 1 , . . . containing the

name of the state and the assignments to each of the system
variables, in order, in that state. In this paper, we presume
that the set of system variables consists of Boolean-valued
atomic propositions, which can each be represented by a
single bit. However, this representation is easily extended
to other data types by utilizing more bits to represent each
system variable. For example, an integer variable with a range
of [0, 255] would be represented using 8 bits. (Unbounded
variables cannot be encoded in this fashion as they cause the
representation of AM, to have an infinite number of states
and thereby to be immune to the model-checking algorithm
presented here. Infinite state model checking requires the
use of alternative techniques, e.g. [142]). Choosing a Boolean
encoding for an automaton is a bit of an art; there are several
encoding variations to choose from. When reasoning about a
single automaton, for instance, there may be an advantage
to encoding the state numbers in the representation along
with the values of the variables in each state. In our air

COMPUTER SCIENCE REVIEW

traffic control example, we have 7 states and thus need 4

bits to represent this range of state labels. The Boolean tuple
representation of State 6, where all 5 system variables are
false, would be 011000000. (The first 4 bits are the binary
representation of the label 6 and the last 5 bits give the 5 false
values of the system variables.) In practice, the state label is
optional and can be included or not in the Boolean tuple for
optimization purposes. This sort of encoding with state labels
is not advantageous when reasoning about combinations of
automata, as in symbolic model checking, as the state labels
become meaningless. Also, we would rather avoid this kind of
explicit enumeration of the states in the BDD representation
since this does not offer a space-saving advantage over
explicit-state model checking.
We represent symbolic automata using BDDs by encoding the transition relations directly. Basically, a transition
is a pair of states: an origin state and a terminal state.
A simple way to represent a transition
from state qi to

state qi+1 is via the tuple qi , qi , which is encoded using

1
twice the number of bits as a single state. For instance,
the transition from State 6 to State 7 in our air traffic
control example automaton, presuming the variable ordering {AR_command, TSAFE_command, controller_request, aircraf t_
request, TSAFE_clear}, would be 0000001000. (The first 5 bits
give the 5 false values of the system variables in State 6; the
next 5 bits represent the values of the system variables in
State 7, with the value of TSAFE_command changed to True.)

Our BDD is constructed using 2| | variables: two copies

of each variable represent its value in the originating state
and in the target state. The variables 1 , 2 , . . . , n represent
the values of the atomic propositions in the current state and
the primed variables 1 , 2 , . . . , n represent the values of the
atomic propositions in the next state. Finding an optimal BDD
variable ordering is NP-complete and, for any constant c > 1,
it is NP-hard to compute a variable ordering to make a BDD
at most c times larger than optimal [169]. Though finding an
optimal variable ordering is a tall order, a good rule of thumb
is to group the most closely-related variables together in the
ordering and some order involving interleaving the current
and next time variants of the variable set together (as in
1 , 1 , 2 , 2 , . . . , n , n ) has been shown to have some nice
advantages for model checking [72].
Alternative encodings include breaking a larger BDD
representation into combinations of smaller BDDs to take
advantage of natural logical separations and minimize the
size of intermediate constructions [138]. Variations on the
basic BDD structure can also be helpful. For example,
shared BDDs, or BDDs with multiple root nodes, one for
each function represented, save memory by overlapping
BDD representations and adding a pair of hash tables for
bookkeeping [143]. Oppositely, BDDs with expanded sets
of terminal nodes (i.e. terminals other than 0 and 1),
such as Multi-Terminal BDDs, offer unique advantages,
especially for extensions of model checking that deal with
uncertainty [144,145]. Examining memory-saving refinements
on the basic BDD structure that sustain or enhance the
efficient manipulation of automata by reasoning over sets of
states and sets of transitions is an ongoing area of research.

4.2.1.

25

The impact of variable ordering

The first decision we make when forming a BDD is the

variable ordering. This is also the most important decision
since the size of the graph representing any particular
function may be highly sensitive to the chosen variable
ordering. Many common functions, such as integer addition,
have BDD representations that are linear for the best variable
orderings and exponential for the worst. Unfortunately,
computing an optimal ordering is an NP-complete problem.
Even if we take the time to compute the optimal ordering,
not all functions have reasonably-sized representations. For
some systems, even a reasonably-sized BDD representation is
too large to reason about practically, and for others, the BDD
representation will grow exponentially with the size of the
input function regardless of variable ordering [137]. Therefore,
the best course we can take is to utilize a set of comparatively
simple heuristics to choose an adequate ordering, avoiding
orderings that would cause the BDD to grow exponentially
whenever possible. A classic example of a function with both
linear and exponential BDD representations, depending on
variable ordering, is displayed in Fig. 10.

4.3.

BDD operations

We introduce the algorithms underlying the symbolic modelchecking procedure, as defined by Bryant [137] and reviewed
by Andersen [146]. The full model-checking algorithm
presented in Section 5 builds upon these basic operations.
If is purely propositional (i.e. contains no temporal
operators) then we can easily construct a (reduced) BDD
directly from using a straightforward algorithm like B UILD,
which simply loops through the variable ordering, recursively
constructing each variables low and high subtrees20 [146].
(See Box VI.) Otherwise, we translate into a symbolic
automaton and then encode the result, A as a BDD, as
described in Section 4.2.
Once we have built BDDs representing each of M and
A , we need to compute their product, as described
in Section 4.1. Let BDD be the set of BDD variables
encoding . The application of all binary operators over
BDDs, including conjunction, disjunction, union, intersection,
complementation (via xor with 1), and testing for implication,
is implemented in a streamlined fashion utilizing a singular
universal function. (See Box VII.) A PPLY takes as input a binary
operator and BDDs representing two functions f1 and f2 , both
over the alphabet = (1 , . . . , n ) and produces a reduced
graph representing the function f1 < op > f2 defined as:
[f1 < op > f2 ](1 , . . . , n ) = f1 (1 , . . . , n ) < op > f2 (1 , . . . , n ).
A PPLY begins by comparing the root vertices of the two
BDDs and proceeds downward. There are four cases. If
vertices v1 and v2 are both terminal vertices, the result
is simply the terminal vertex representing the result of
value(v1 ) < op > value(v2 ). If the variable labels of v1 and
v2 are the same, we create a vertex in the result BDD with
that variable label and operate on the pair of low subtrees,
low(v1 ) and low(v2 ), and the pair of high subtrees, high(v1 )
20 Unfortunately, this simple algorithm requires exponential (2n )
time.

26

COMPUTER SCIENCE REVIEW

Box VI.

Box VII.
and high(v2 ), to create the low and high subtrees of our new
vertex, respectively. Otherwise, one of the variables, var(v1 )
or var(v2 ) is before the other in the total variable ordering.
Note that this later vertex may or may not be a terminal
vertex; either way, the algorithm is the same. If v1 is the
earlier vertex, then the function represented by the subtree
with root v2 is independent of the variable var(v1 ). (If this
were not true, we would encounter the variable in both
graphs.) In this case, we create a vertex in the result BDD
labeled var(v1 ) and recur on the pair of subtrees {low(v1 ), v2 }
to construct this new nodes low subtree and on the pair
of subtrees {high(v1 ), v2 } to construct this new nodes high
subtree. The last case, where var(v2 ) occurs before var(v1 )
in the total variable ordering, is symmetric. We presume

new_vertex() is some function that creates a new vertex iff no

isometric vertex exists, thus maintaining the reduced nature
of the BDD under construction. Bryant [137] and Wegener
and Sieling [147] describe implementation optimizations that
yield a time complexity for this algorithm of O (|G1 ||G2 |) where
|G1 | and |G2 | are the sizes of the two graphs being operated
upon.
Recall that finding a counterexample trace equates to
finding a word in the language L (AM, ), which is essentially
a satisfying assignment to the variables in through time.
The model checker uses a BDD-based fixpoint algorithm to
find a fair path in the model-automaton product [24]. The
basic algorithm underlying this process is Bryants S ATISFYONE [137]. (See Box VII.) This algorithm is a simple recognition

COMPUTER SCIENCE REVIEW

27

Box VIII.
of the BDD principle that every non-terminal vertex has the
terminal vertex labeled 1 as a descendant. Thus, a classic
depth-first search with backtracking upon visiting the 0
terminal is guaranteed to find a satisfying path from the
root to the terminal 1 in linear time21 . Starting from the
root, S ATISFY- ONE arbitrarily guesses the low branch of each
non-terminal vertex first, and stores a satisfying assignment
(aka counterexample trace) of length n = |BDD |, in an array
as it traverses the graph. It returns false if the function is
unsatisfiable, and true otherwise. (See Box VIII.)
Note that the reason we check for the existence of a single
satisfying set and not for the whole set SM, of satisfying
sets is because enumerating the entire set requires time
proportional to the length of the counterexamples times the
number of elements in SM, . (For a propositional formula
with n = |BDD |, the time complexity is O (n |SM, |).)
Considering the counterexample traces may be quite lengthy
(i.e. n may be large), and there may be many of them, this
is a highly inefficient check, unlikely to be performed in any
reasonable timeframe. Furthermore, the utility of performing
such a check is questionable: a single bug may generate
any number of counterexamples. For verification purposes,
where counterexamples may trace through many time steps,
it is much more efficient to use the model checker to find
a bug, then fix that bug before searching for additional
counterexamples.
By changing the domain of the model-checking problem to
reasoning over BDD operations from explicit manipulations of
automata, we increase the size of the system we can reason
about. Combining concepts from Boolean algebra and graph
theory allows us to achieve such a high level of algorithmic
efficiency that the performance of symbolic model checking
using these techniques is limited mostly by the sizes of the
BDDs involved. Table 3 compares the two methods for each
step in the model-checking problem.

4.4.

Air traffic control example: a BDD

We now revisit our example of the automated airspace

concept for air traffic control. Using the methods presented
in Section 4.2 for encoding automata as BDDs, and ordering
the variables as we presented them, we arrive at the BDD
representation of the automaton introduced in Section 2.2,
displayed in Fig. 11.
21 One of the reasons maintaining a reduced BDD is important is
that this algorithm can require exponential time if not [137].

The variable ordering used in Fig. 11 is {AR_command,

AR_command, TSAFE_command, TSAFE_command, controller_
request, controller_request, aircraft_request, aircraft_
request, TSAFE_clear, TSAFE_clear}. Note that this variable ordering was chosen for our example to be easy to read,
not to be optimal. Nevertheless, the binary decision tree for
this ten-variable model would have 2n+1 1 = 210+1 1 = 2047
total nodes while the BDD we picture here has only 47. Note
also that this BDD is easily constructed from either of the
NuSMV models we presented in Section 2.2, Boxes I and II,
since it simply encodes the changes in variables that are possible in a single time step.
Returning to our example liveness specification, we
want to check that whenever a near-term conflict is
detected (i.e. whenever TSAFE_clear is false) that the conflict
is addressed (i.e. a correcting command from TSAFE is
issued). In order to do that, we check the LTL formula
(TSAFE_clear TSAFE_command).
In Section 3.8, Box V, we saw the symbolic automaton
created by the model checker for this formula. In Fig. 12,
we present the BDD representation of that symbolic automaton, which encodes the current and next-time versions of the four variables and the transition relation in
that representation. Note in particular how small this collection of Boolean variables and pointers is in comparison
to what we would need to store to explicitly enumerate all
states of the automaton. This is an example of the concept
of reasoning about states and transitions more succinctly,
as sets of states and sets of transitions. We need only a
few of the system variables for this representation, though
the paths through this BDD encode sets of states where
the values of the system variables not present in the BDD
vary. We use the variable ordering of Fig. 11 with the current and next-time versions of the specifications elementary variables EL_X_G__TSAFE_clear_OR_F_TSAFE_command and
EL_X_F_TSAFE_command tacked onto the end, which will allow
us to combine these BDDs for the model checking step.

5.

Checking for counterexamples

We construct the automaton AM, as the composition

of the system automaton M, and the automaton for the
complimented LTL specification A . The model checking
question, does M, q0 |H , then reduces to asking is the
language L (AM, ) empty? The follow-up to this question
is if not, what word(s) does AM, accept? Any such word
represents a computation of M that violates , constituting a

28

COMPUTER SCIENCE REVIEW

Table 3 Table comparing explicit and symbolic model-checking algorithms. Recall that el() is the set of elementary
formulas of as defined in Section 3.7. We presume the ROBDDs for M and are created using the appropriate variants
of the B UILD algorithm [146]. The ROBDD for AM, is created by an extension of the algorithm A PPLY(, ROBDDM ,
ROBDD ) [146], implementing the dynamic programming optimizations that result in lower time-complexities. Finally,
the algorithm used for finding a counterexample given an ROBDD is based on A NYS AT [146]. Note that, for both explicit
and symbolic model checking, multiple steps below are performed at once, using on-the-fly techniques, which increases
the efficiency of the process and may avoid constructing all of AM, . We separate out the steps here for simplicity only.
Operation
Translate M from a
higher-level language
Translate from LTL
to A
Create AM,
Check AM, for
nonemptiness

Construct a
counterexample

Explicit method
Construct a Bchi
automaton
Construct a Bchi
automaton
Construct automaton for
L (M) L (A )
Search for an accepting
path via iterative
depth-first search of the
strongly connected
components
Compute an accepting
cycle through the SCC
graph

Time
complexity
Depends on
M
2O (||)

O (|M|
|A |)
O (|AM, |)

O (|trace|)

Symbolic method

Time complexity

Construct an ROBDD

O (2| | )

Construct an ROBDD

O (2|el()| )

Compute (ROBDDM ROBDD )

O (|ROBDDM ||ROBDD |) =
O (2| | 2|el()| )
O (|BDDrepresentation|)a

Compute the fixpoint of the

combined BDD with the spec
E  true

Find a path leading to the terminal

node 1 by a depth-first traversal of
ROBDDM,

Linear in the length of the

counterexample found:
O (|trace|)

a Here, the time complexity depends upon the size of the symbolic (BDD) representation in terms of the distances between states in the

automaton graph, the number and arrangement of the strongly connected components in this graph, and the number of fairness conditions
asserted.

counterexample to the check M, q0 |H and providing a valuable

debugging tool for locating the bug. Thus, in practice, the
model-checking step is performed in two parts: an emptiness
check on the language L (AM, ) and the construction of the
(preferably shortest) counterexample witness if L (AM, ) =
.
The earliest complete symbolic model-checking algorithm
was designed in 1992 by Burch, Clarke, McMillan, Dill, and
Hwang to take advantage of regularity in the state graph
of the system and utilize the intuitive complexity of the
state space rather than the explicit size of the space [22].
We present an updated algorithm here, better suited to
symbolic LTL model checking specifically [148], which takes
full advantage of our automata-theoretic approach, allowing
very naturally for extensions to the basic algorithm [5].
An issue with using the original symbolic model checking
algorithm, and later variants thereof, for LTL model checking
is that they operated via a translation to the type of fair
transition system also used for CTL model checking with
fairness constraints [23], which itself involved a conversion
to the mu-calculus [22,149]. This method is indirect, complex,
and does not account for the full expressibility of LTL
such as full fairness, also called strong fairness or compassion.
Recall from Section 3.5 that compassion extends justice
to include the existence of sets of cyclically recurring
system states. Compassion can be particularly useful when
specifying special types of coordination, such as semaphores
or synchronous communication protocols. In Section 3.5 we
showed that compassion requirements can be included via
specifications. We can also include compassion natively in
the system model.
The classical automata-theoretic approach to model
checking using justice corresponds to reasoning over
generalized Bchi automata whereas adding compassion

extends this to reasoning over Streett automata [150]. Streett

automata are essentially the same as Bchi automata but
with more general acceptance conditions, enabling the direct
encoding of stronger notions of fairness [112]. Instead of
specifying F, the set of final states that must be visited
infinitely often in Bchi acceptance, Streett acceptance takes
the form of a set of pairs of sets of states, (Li , Ui ) such that if a
run visits a state in Li infinitely often, it must also visit a state
in Ui infinitely often [112]. The pairs of sets of states in Streett
acceptance conditions correspond nicely to the definition of
generalized fairness [151]. Of course, since Street automata
are expressively equivalent to Bchi automata and there is
a straightforward conversion between the two [112], adding
compassion at the algorithmic level does not substantially
change our nonemptiness check [5].
Recall from Fig. 8 that a counterexample witness takes
the shape of a lasso: a finite prefix starting from the initial
state, q0 , and leading to an accepting cycle of the automaton
AM, . For LTL model checking, fairness requirements are
captured by the automata acceptance conditions, so each
justice requirement and compassion requirement constitutes
an additional acceptance condition. The challenge, then, is
to find a reachable fair cycle, or a cycle that passes through
at least one state satisfying each acceptance condition. Such
a cycle is often referred to as a bad cycle because it is a
cycle on which all acceptance conditions are satisfied yet our
specification, , is violated, which is certainly an undesirable
outcome considering our goal is to prove that the system M
never violates . We return as the counterexample, the list of
states comprising the finite stem from q0 to some state in this
fair cycle, followed by a listing of the states visited in the cycle.
See Section 5.4 for a counterexample returned from NuSMV
for our air traffic control example.
We want to find the shortest counterexample because that
facilitates debugging and, in some cases, returning a shorter

COMPUTER SCIENCE REVIEW

29

Fig. 8 A counterexample trace takes the form of an accepting lasso. Again, the start state is designated by an incoming,
unlabeled arrow not originating at any vertex. Here, F1 . . . F4 represent final states satisfying four acceptance conditions.

(a) Binary Decision Tree.

(b) Isomorphism
elimination rule.

(c) Redundancy
elimination rule.

Fig. 9 Conversion of a Binary Decision Tree for x1 x2 x3 into a Binary Decision Diagram.

(a) Variable order = {x1 , x2 , x3 , y1 , y2 , y3 }.

(b) Variable order = {x1 , y1 , x2 , y2 , x3 , y3 }.

Fig. 10 BDDs for the function (x1 y1 ) (x2 y2 ) (x3 y3 ).

counterexample can save time and memory. However, this

step in the model-checking process needs to be fast and
finding the shortest counterexample is NP-complete [152], so
we depend instead on reliable heuristics to efficiently find
a (hopefully) short counterexample quickly.22 Furthermore,
we want to construct this counterexample directly from our
symbolic automaton, AM, for maximum efficiency. For this
reason, there has been a concentration on finding efficient
symbolic cycle-detection algorithms. The first such effort, by
Emerson and Lei [24], produced an algorithm that operates
in quadratic time due to the presence of a doubly-nested
fixpoint operator, but is still a standard to which all later
algorithms are compared. All of these algorithms perform
22 For

an algorithm that always returns the shortest counterexample, see [153].

some iterative computation over the reachable states in the

automaton AM, to find paths to fair cycles. In order to
accomplish this, it is necessary for us to treat this automaton
as a graph and employ some classic techniques from graph
theory.

5.1.

Automata as graphs

Formally, a predicate over the set of states Q is any subset

P Q. A binary relation over Q is any set of pairs R Q Q
such that, for predicates P1 and P2 :
P1 P2 = {(q1 , q2 ) Q 2 |q1 P1 , q2 P2 }.
Recall that a Bchi automaton can be viewed as a special
case of a directed graph G = (V, E) where V is the finite set
of vertices, or the states of the automaton such that V = Q,

30

COMPUTER SCIENCE REVIEW

Fig. 11 BDD representing the automaton in Fig. 1.

Fig. 12 BDD representing the symbolic automaton in Section 3.8, Box V, for the formula
(TSAFE_clear TSAFE_command). (The variable EL_X_G__TSAFE_clear_OR_F_TSAFE_command is abbreviated EL_X_G_....)

and E V V is the set of edges, or the binary relation

encapsulating the transitions of the automaton such that
(q, q ) E whenever (q, ) = q for two states q and q and
any alphabet character . A path through the graph
that corresponds to a computation of the automaton, from
some state qj to state qk is a sequence qj , qj+1 , qj+2 , . . . qk of
vertices such that (qi1 , qi ) E for i = j + 1, j + 2, . . . , k. Along
such a path, we call vertex qi1 a predecessor of state qi and
vertex qi+1 a successor of qi . Note that a path must contain
at least one edge but the presence of self-loops means that
a state can be its own predecessor or successor. If there is a
path from qj to qk , we say that qk is reachable from qj or that
qj qk . Let R represent the binary relation corresponding

to the transition relation of AM, . We can extend this

relationship for a predicate P and the relation R using preand post-composition as follows:
R P = {q Q|(q, q ) R for some q P},
q) R for q P}.
P R = {q Q|(q,
In other words, R P is the set of all predecessors of states
in the set P. Conversely, P R is the set of all successors of
states in the set P, or the set of all states reachable in a single
transition from P in the graph of AM, , which we call GAM, .
We can employ the -operator to define R P, the set of
all states that can reach a P-state within a finite number (0
or more) steps. Similarly, we designate the set of all states

COMPUTER SCIENCE REVIEW

reachable in a finite number of steps from a P-state as P R .

Expanded, we have:
R P = P R P R (R P) R (R (R P)) ,
P R = P P R (P R) R ((P R) R) R .
Since AM, is finite, it is clear that both R P and P R
converge in a finite number of steps. Because P R consists of
the set {q Q|q q }, it is also called the forward set of state
q. In the same vein, R P comprises the backward set of state q
or {q Q|q q}. We define the diameter d of a graph to be the
length of the longest minimal path between any two states
(qj , qk ) G such that qj qk . In other words, for all pairs of
connected vertices (qj , qk ) G, setting the distance from qj
to qk to the smallest number of states on any path between
them, d is the longest such distance in G.
A connected component, is a maximal connected subgraph
such that two vertices are in the same connected component
if and only if there is some path between them. Meanwhile,
a strongly connected component (SCC) is a maximal subgraph
such that every vertex in the component is reachable from
every other vertex in the component. That is, for any strongly
connected component S, for all vertices qj , qk such that qj S
and qk S, qj qk and qk qj . For example, the graph
of our automated air traffic control architecture in Fig. 2
consists of one SCC since every state in that graph has a
path to every other state in the graph. An individual vertex,
not connected to itself, comprises a singular or trivial SCC.
A path qj , qj+1 , qj+2 , . . . qk forms a cycle if qj = qk and the
path contains at least one edge. Thus, a strongly connected
component is essentially a set of vertices such that every pair
of vertices in the set is contained in some cycle. Algorithms
for finding SCCs in symbolic graphs take advantage of the
following property:
Theorem 8. The intersection of a nodes forward and backward
sets is either empty or a strongly connected component (SCC).
Proof of Theorem 8. Let q be a vertex in directed graph G. Let
F(q) represent the forward set of q and B(q) represent the
backward set of q. First, presume q is in an SCC S. By definition
of an SCC, all nodes are reachable from, and can reach, all
other nodes in the SCC. Therefore, all of the nodes in the
SCC containing q would have to be in both qs forward and
backward sets, or S F(q) B(q). Furthermore, no additional
nodes not in the SCC containing q can be in the set F(q) B(q).
Let q be a node in F(q) B(q). Then q q and q q. Since
every node q S has a path to and can be reached from q,
then it must be the case that q and q are strongly connected
by some path through q. In other words, q q q and
q q q . Therefore, we know that F(q) B(q) S. Together,
we have S F(q) B(q) F(q) B(q) S F(q) B(q) = S. It
logically follows that the node q is not in a non-trivial SCC iff
F(q) B(q) = . 
A terminal SCC is an SCC with no edges leading out to
nodes outside the SCC. Symmetrically, an initial SCC is one
with no edges leading in from nodes outside the SCC. In
Theorem 8 above, we take the intersection of node qs forward
and backward sets because a node q in an SCC can still have
a transition to another node outside that SCC, so if the node q
is in an SCC that is not terminal, there may be many more
nodes in its forward set that are reachable from that SCC.

31

Symmetrically, a node q in an SCC can still have a transition

in from another node outside that SCC so if the node q is in an
SCC that is not initial, there may be many more nodes in its
backward set that can reach that SCC. All of the algorithms
for symbolic cycle detection utilize some combination of
computing forward sets (successors) while looking for initial
SCCs, backward sets (predecessors) while looking for terminal
SCCs, or some intermingling of both strategies.
Recall that the acceptance condition for a generalized
Bchi automaton requires cycling through a state in each
set in F (the set of sets of states where each acceptance
condition holds) infinitely often. Recall also that an accepting
run of a generalized Bchi automaton resembles a lasso with
a path from the start state to an accepting cycle. Thus, finding
an accepting run of a generalized Bchi automaton comes
down to finding a path to a strongly connected component
in the graph of AM, , GAM, , that contains at least one state
satisfying each acceptance condition.
Strong Fairness. In LTL model checking, we may place
these conditions on acceptance: that the counterexample
found must be just and that it must be compassionate. For
each justice requirement J in the set of justice requirements
J over AM, , we define a set of J-states (states that satisfy
J). We call a subgraph just if it contains a J-state for every
justice requirement J J . Similarly, for each compassion
requirement over AM, , we define a pair of sets (y, z) C
that constitute that requirement where C is the set of all
such pairs. We call a subgraph compassionate if, for every
compassion requirement (y, z) C the subgraph either
contains a z-state or else does not contain any y-state.
Combining these, we have that a subgraph is fair if it is a
non-singular strongly connected component that is both just
and compassionate, in that it intersects each accepting set
of states in both J and C . Therefore, a counterexample lasso
must be reachable from q0 and cycle infinitely often through
at least one state satisfying each acceptance condition, which
involves visiting a minimum set of states satisfying any
justice or compassion requirements we have asserted over
AM, .
Theorem 9 ([154]). An infinite initialized path is a computation
of AM, iff the set S of states that appear infinitely often in
comprises a fair SCC of the graph representing AM, , GAM, .
Proof of Theorem 9.
If-direction: is a computation of AM, S is a fair SCC in
GAM, .
Presume AM, has a computation = 0 , 1 , . . .. By
definition, carves out an infinite path, starting in state
q0 that passes infinitely often through at least one state
satisfying each acceptance condition (justice or compassion
requirement) of AM, . Since AM, is finite, takes the
shape of a lasso with a finite prefix of states starting from q0
leading to a cycle containing all of the states visits infinitely
often. We define S to be the set of all states along that cycle.
Then, S must be fair since is an accepting run of AM, .
Furthermore, S must be strongly connected since for all pairs
of states s, s S, both s and s appear infinitely often in , so
s s and s s.
Only-if direction: S is a fair SCC in GAM,
computation of AM, .

is a

32

COMPUTER SCIENCE REVIEW

Presume S is a fair SCC in GAM, . Consider some path

, originating in q0 such that the set of states visited by
infinitely often is defined to be S. We can construct such a
path by connecting every pair of states s, s S such that
(s, s ) E, which is equivalent to saying (s, ) = s for some
character . That is, we traverse every edge between
states in S. In this way, we form the cycle such that there
are infinitely many positions j such that j = s and j+1 =
s . By definition of a fair SCC, we know S intersects each
accepting set of states in GAM, . Therefore, by definition,
is a computation of AM, . 

5.2.

Symbolic methods for graph traversal

The standard algorithm for finding strongly connected

components in a directed graph is depth-first search. Indeed,
this is the algorithm used in explicit-state model checking for
finding and returning counterexamples. However, in symbolic
model checking we are not using an explicit automaton
graph; our graph is instead encapsulated succinctly using
BDDs. We have encoded the graph in terms of sets of states
and sets of transitions, altering the problem of traversing
the graph. Due to the nature of this encoding, depth-first
approaches, while optimal for examining individual states,
are not suitable for symbolic cycle detection. Rather, we
employ breadth-first, set-based cycle-detection algorithms
better suited to searching over the characteristic function, Sh ,
as defined in Section 3.7.
Our goal is to locate a fair subgraph of GAM, because,
as we know from Theorem 9, this will allow us to
construct a counterexample, which is a computation of
AM, . This search is an iterative process. Essentially, we will
compute some part of the transitive closure of the transition
relation of AM, , i.e. R P or P R , preferably without
incurring the computational expense of computing the entire
transitive closure. To accomplish this, symbolic algorithms
take advantage of meta-strategies for dealing with the setbased encoding of graphs such as intelligently partitioning
GAM, and reasoning over the SCC quotient graph of GAM, .
The SCC quotient graph is a directed, acyclic graph Gquotient =
(Vquotient , Equotient ) such that the set of vertices Vquotient is
the set of SCCs in GAM, . Again, let R represent the binary
relation corresponding to the transition relation of AM, .
For two vertices V1 , V2 Vquotient , there is an edge (V1 , V2 )
Equotient iff V1 = V2 (so there are no self-loops) and (v1
V1 , v2 V2 ) : (v1 , v2 ) R. Restated, there is an edge in
Gquotient whenever there is an edge in GAM, from a state
in one SCC to a state in a different SCC. Note that it is easy
to prove that Gquotient is acyclic since if there were a cycle in
this graph, then all of the states in all of the SCCs on such a
cycle would be reachable from each other, which contradicts
their status as separate SCCs. Gquotient defines a partial order
over the SCCs in GAM, such that v1 v2 for any states
v1 V1 , v2 V2 iff v1 v2 . Using Gquotient , we can identify
the initial SCCs of GAM, as the sources of the graph and the
terminal SCCs as the sinks. It is easier to reason about sets of
predecessors and successors and partition the graph GAM,
to limit our search. Symbolic algorithms utilize these types of
tools to reduce the fair subgraph search problem to a smaller
set of nodes than the entire graph GAM, .

Whereas the time required for the depth-first exploration

of the graph of AM, performed in explicit-state modelchecking is directly dependent on the size of AM, , this is not
the case for symbolic model checking algorithms. After all,
symbolic algorithms derive their efficiency by representing
compact characteristic functions instead of large numbers of
individual states. In practice, the number of states in AM,
is not nearly as accurate a predictor of the time required
for symbolic model checking as the graph diameter d, the
length of the longest path in the SCC quotient graph, the
number of justice and compassion requirements, the number
of reachable SCCs (and how many of those are trivial), and
the total number and size of the set of SCCs [155]. Basically,
the number of states is frequently very large but some
shapes of AM, are much easier to model check than others.
This is an advantage of utilizing symbolic algorithms since
many very large graphs can be reduced to very succinct
symbolic representations. The trade-off between the size
of the representation of AM, and the search complexity
is necessary for practical verification. As the number of
states in AM, grows, considering every state individually
quickly becomes infeasible so symbolic examination of the
state space, while more difficult, is necessary to achieve
scalability. Generally, the length of the counterexample found
also depends heavily on the structure of the graph and the
size of the symbolic representation.
There are many variations of this algorithm that
have been created to provide better time-complexities,
better performance times, and shorter counterexamples.23
Optimizing fair cycle detection for symbolic model checking
remains an active area of research [156,153,157159,155,160
162].
There are two general classes of symbolic cycle-detection
algorithms:
SCC-hull algorithms: Most symbolic cycle-detection algorithms [24,156,144,157,148,161] sequester an SCC-hull, or a
set of states that contains all fair SCCs, without specifically enumerating the SCCs within. This set computation
is not tight; if there are fair SCCs in the graph, the SCChull algorithms may return extra states besides those in
the fair SCCs.24 Basically, these algorithms maintain an
approximation set, or a conservative overapproximation of
the SCCs. The approximation set is iteratively refined by
pruning, or locating and removing states that cannot lead
to a bad cycle utilizing the property that any state on a
bad cycle must have a successor and a predecessor that
are both on the same cycle, in the same SCC, and, therefore, in the approximation set. In the case that there are
no fair SCCs, these algorithms return the empty set. These
algorithms locate the SCC-hull using a fixpoint algorithm
that either computes the set of all states with a path to a
fair SCC [24], from a fair SCC [156], or some combination
of both [157] since both of these sets include the states
contained in a fair SCC, if one exists. Counterexamples are
23 Note that the problem of finding the shortest counterexample
is NP-complete [152].
24 We can compile a tighter set of fair SCCs by directly computing
the exact transitive closure of the transition relation rather
than an overapproximation but this method is comparatively
inefficient for reasoning over BDDs [155].

COMPUTER SCIENCE REVIEW

generated by searching for a path from the initial state q0

to a state in a fair cycle then iterating through the set of acceptance conditions using breadth-first-search to find the
shortest path to a state in the next fair set until the cycle is
completed. Depending on the specific SCC-hull algorithm,
varying amounts of additional work may be required to
isolate the fair SCC to be returned in a counterexample.
Symbolic SCC-enumeration algorithms: Alternatively, SCCenumeration algorithms [153,158160] enumerate the
SCCs of the state graph while taking advantage of the
symbolic representation to avoid explicitly manipulating
the states. Rather than extracting the (terminal or
initial) SCCs from the set of all SCCs in a hull, these
algorithms aim to compute reachability sets (either
forward or backward) for fewer nodes by isolating SCCs
sequentially. This is accomplished, for example, by
recursively partitioning GAM, and iteratively applying
reachability analysis to the subgraphs. The motivation is
that many systems have only a limited number of fair
SCCs so these algorithms can achieve a better worstcase complexity than SCC-hull algorithms [160], but in
practice, their performance has been inferior [155]. Like
with SCC-hull algorithms, these algorithms utilize some
combination of forward and backward search, possibly
in an interleaved manner. Pruning helps to reduce the
number of trivial SCCs examined. After each SCC is
identified, it is checked for fairness. The algorithm
terminates as soon as the first fair SCC is located and
may end up either enumerating all SCCs or paying
additional computation cost for early elimination of unfair
SCCs in the case that no fair SCC exists. Consequently,
these algorithms tend to perform worse than SCC-hull
algorithms when there are no fair SCCs or a large number
of unfair SCCs present in AM, [155]. Counterexamples
are constructed similarly to, but possibly more efficiently
than, SCC-hull algorithms since it is theoretically easier to
locate a counterexample given that the enumerated fair
SCC in question is tight. The length of the counterexample
depends on which fair SCC is enumerated first, which
is determined by the starting state of the algorithm, so
optimizations include heuristics for choosing seed states
in short counterexample traces.

5.3.

SCC-hull algorithm for compassionate model checking

Here we present the full algorithm for symbolic LTL model

checking, including for the sake of completeness, support for
compassion at the algorithmic level, as opposed to adding
it to the specification set or allowing only weaker forms of
fairness. All symbolic LTL model checkers support justice but
not all support compassion. For example, at the time of this
writing, NuSMV supports compassion [43] but CadenceSMV
does not [163]. Currently, compassion requirements are rarely
used in industrial practice. The algorithm discussed in this
section was first published in 1998 by Kesten, Pnueli, and
Raviv [148] and is exactly the under-the-hood implementation
in NuSMV today [43]. It is presented in a straightforward
manner using standard set theory since set operations
on the languages accepted by finite automata translate
transparently to logical operations on Boolean functions, as
we discussed in Section 4.

33

We call an automaton feasible if it has at least one

computation. The corollary to Theorem 9 is that AM,
is feasible iff GAM, contains a fair subgraph (a nonsingular strongly connected component that is both just and
compassionate). Therefore, we first check for the presence of
a fair subgraph and determine the feasibility of our combined
automaton. The model-checking problem reduces to M |H
iff AM, is not feasible. If AM, is not feasible, then our
verification is complete; we can conclude that M |H . If
AM, is feasible, we will need to construct a (preferably short)
counterexample.
Indeed, the algorithm for checking whether an automaton
is feasible is essentially a specialization of the standard iterative algorithm for finding strongly connected components in
a graph. The original cycle-detection algorithms for explicitstate model checking recursively mapped strongly connected
subgraphs, computing closures under both successors and
predecessors [56,66]. Later it was proved that the requirement of bi-directional closure is too strong [148]. The algorithm, FEASIBLE (), presented below, requires only closure
under successor states while looking for initial components
of the graph [148].25 Proofs of soundness, completeness, and
termination of this algorithm are provided in [148,154].
Let denote the predicate consisting of all states that
satisfy , for some formula , and denote the relation
consisting of all state pairs q, q such that (q, ) = q for any
alphabet character . Then we have the subroutine given
in Box IX.
The algorithm FEASIBLE () takes as input a synchronous
parallel composition of the system and specification, which
in our case is AM, . Recall that in this construction, is
essentially serving as a tester of M, continuously monitoring
the behavior of the system and making sure the system
satisfies the desired property. Our subroutine starts by
computing the set of all successors of the initial state, q0
in the predicate new. Because any run of AM, will satisfy
the initial condition and obey the transition relation but not
necessarily satisfy the justice and compassion requirements,
we need to check for this characteristic additionally. We
loop through each justice and compassion requirement,
subtracting states from new that are not reachable in a finite
number of steps from states satisfying that requirement.
Then we remove from new all states that do not also have
a predecessor in new since such states cannot be part of
a strongly connected component. We repeat this process
until we reach a fixpoint; looping through every fairness
requirement, checking for predecessors, and reducing new
accordingly does not change the size of new. At this point,
if new is empty, we return the emptyset and conclude that
AM, is not feasible and, therefore, M |H . If new is not
empty, then it contains a fair strongly connected component
of GAM, from which we must extract a counterexample
witness.
To aid in our quest to efficiently find a short counterexample, if possible, we require a subroutine to find the shortest
path between two states in GAM, . Let represent the empty
list. We use the -operator to denote list fusion such that if
25 An equivalent algorithm would be to check for closure under
predecessor states while looking for terminal components in the
state-transition graph.

34

COMPUTER SCIENCE REVIEW

Box IX.

Box X.
L1 = (1 , 2 , . . . i ) and L2 = (i , i+1 , . . .) are standard list data
structures such that the last element of L1 is the same as the
first element of L2 , then L1 L2 = (1 , 2 , . . . i , i+1 , . . .) represents their concatenation, overlapping this shared element,
or simply concatenating the lists if there is no overlap. We
define the function choose(P) to consistently choose one element of a predicate P. Then we have the subroutine given in
Box X.
We are now ready to present the full counterexample
extraction algorithm. For completeness, we show the step
of checking AM, for feasibility in context. We define the
function last(L1 ) to return the last element in the list L1 in
the algorithm given in Box XI.
After checking AM, for feasibility, we exit if M |H . If
not, we know that the set returned by feasible(), which we
save in f inal, contains all of the states in fair SCCs that are
reachable from q0 . We look at the set of successors of states
in the set f inal. We pick a state from this set and iterate,

replacing our chosen state s with one of its predecessors

until the set of predecessors of s is a subset of the set of
successors of s. Basically, we are attempting to move to an
initial SCC in the quotient graph of GAM, . Termination of
this step is guaranteed by the finite nature of GAM, and the
structure of the quotient graph. Next, we compute the precise
SCC containing s, restrict our attention to transitions between
states in this SCC, and utilize our shortest path algorithm to
find the prefix of our counterexample, or the path from q0 to
our fair SCC. Then we construct the fair cycle through our SCC
that satisfies all fairness requirements. In order to do this, we
loop through each justice requirement, adding to our cycle a
path to a state that satisfies that requirement if there is not
one in the cycle already. We do the same for each compassion
requirement. Finally, we complete the cycle with the shortest
path back to the state we started the cycle from and we are
ready to return our counterexample.

COMPUTER SCIENCE REVIEW

35

Box XI.

5.4.

Air traffic control example: model checking

In this final installment of our automated air traffic

control architecture verification example, we demonstrate
the complete model-checking process for this real-world
system from the users perspective. We have shown in detail
how the model checker negates the input specification, ,
symbolically compiles into A , and conjoins A with
the symbolic automaton system model M, forming AM, . If
the automaton AM, is not empty, then the model checker
finds a fair path that satisfies the formula and returns
a counterexample, allowing the user to correct the error
in the system design. While knowledge of how each of
these steps is accomplished internally to the model checker
is beneficial, in practice the model-checking process from
the users perspective is simple. Familiarity with the model
checker under the hood is useful chiefly to help the user make
smarter choices when interacting with the model checker,
improving verification performance and user experience. For
example, some intelligent choices made in the process of
modeling M or utilizing counterexamples to narrow in on a
bug can help skirt the state explosion problem and make
debugging easier and more efficient.
We continue to demonstrate model checking using the
tool NuSMV. The input file AAC.smv contains one of the
NuSMV models from Section 2.2 concatenated with the
specifications from Section 3.8. As with any model checker,
we could supply our own variable order, designate which of
the model checkers available heuristics we wish to use, or
let the model checker choose for us. Most model checkers
incorporate sufficiently optimized variable heuristics by
default so, in practice, we usually choose to let the tool
automatically find an appropriate ordering. In Box XII,
we show the output from NuSMV generated by checking

our example liveness specification that whenever a nearterm conflict is detected (i.e. whenever TSAFE_clear is false)
that the conflict is addressed (i.e. a correcting command
from TSAFE is issued), which we wrote in LTL as LTLSPEC
(G (controller_request ->(F (! controller_request)))). In
this case, the specification holds, and we can conclude that
M |H .
Now let us try another specification: we want to
ensure the human in the loop can always override the
software algorithms. In other words, we check that the
corrective trajectory requests from the controller are always
granted. Since, in our simple model, controller requests are
fulfilled by transferring the request into a corresponding
command by the auto-resolver, in LTL we write this as
(controller_request
(AR_command&controller_request)).
The result of checking that specification using NuSMV is given
in Box XIII.
Our specification has failed! The counterexample returned
guides us along a path through our system where the
specification does not hold. Notice the path starts in our
system models initial state, which NuSMV names State 1.1,
where all of the variables but TSAFE_clear are false. In the next
state along our path, the only variable that changes value is
controller_request, which becomes true. (This corresponds
to a transition to State 4 in the automaton in Fig. 2.) Next,
we transition to a state where controller_request is 0 and
all of the other variables values are the same as they were
in the last state. (We are now in State 1 in Fig. 2.) Finally,
we transition again but none of the values of the variables
change. (This represents the transition from State 1 to itself
where the airspace is clear and there are no commands or
requests.) Notice the occurrence of Loop starts here just
before the description of NuSMV State 1.3 designates that
we loop from State 1 to State 1 forever, thus completing the
description of our infinite accepting run.

36

COMPUTER SCIENCE REVIEW

Box XII.

Box XIII.

6.

Discussion

While the complete algorithm presented here serves as the

basis for LTL symbolic model checking performed in industry,
in practice, extensions to this algorithm are much more
commonly used. We present the foundation upon which
more specialized and scalable variations are built. Industrial
applications frequently necessitate the use of extensions
that provide additional scalability such as compositional
verification [74], in which subunits of the system M and
the interactions between these subunits are model checked
separately, each in the manner presented here. Since the
entire automated airspace concept for air traffic control
is extremely large, the full-scale version of our running
example involves verifying components such as TSAFE and
the auto-resolver as separate subunits, then verifying their
interactions, i.e. via the high-level architecture we have
shown. Also, bounded model checking [133] depends upon
a propositional SAT solver to replace the BDD operations of

classical symbolic model checking and bounds the length of

any possible counterexample to be less than some constant
k. While this variation no longer provides the guarantee
that no counterexample of any length exists, it vastly
increases the size of systems we are able to verify, providing
better guarantees of termination in a reasonable timeframe.
Allowances for adding operators to LTL, as described in
Section 3.2.4, are also implemented through adjustments to
the algorithm for translating standard LTL.
Our running example of verifying an automated air traffic
control architecture serves both to illustrate the concepts
discussed throughout this paper and also as a standalone introduction to the application of LTL symbolic model
checking to an, admittedly very simple, real-world system.
That said, several full-scale air traffic control systems in
a similar vein have been successfully verified using model
checking techniques stemming from those we discussed
here. For example, symbolic model checking in SMV was
used to verify the Traffic Alert and Collision Avoidance

COMPUTER SCIENCE REVIEW

System (TCAS II), an air traffic guidance system required

on-board large commercial aircraft [164]. Properties checked
included the absence of undesirable non-determinism,
mutual exclusion, termination, absence of references to
undefined parameters, and elimination of inconsistencies in
the protocol specification. SMV also enabled verification of
the A-7E aircraft software requirements to ensure internal
aircraft modes were consistently enabled so that procedures
for monitoring, for example, the aircrafts windspeed,
velocity, and alignment, accurately contributed to the
aircrafts calculated relative position [165]. The Small Aircraft
Transportation System (SATS), which is an approach to air
traffic management for non-towered non-radar airports in the
United States, was model checked to verify the absence of
deadlocks, that aircraft separation is maintained, and that the
system is robust in the face of unexpected rare events such
as equipment failures or aircraft deviating off-course [166].
An early specification for the TSAFE component of our air
traffic control example was also model checked to verify the
absence of synchronization faults, employing compositional
verification techniques [167].
LTL symbolic model checking is ideal for the verification
of reactive systems, or those systems that operate within
a dynamic environment such as concurrent programs,
embedded and process control programs, and operating
systems. LTL allows us to naturally and organically specify
reactive systems in terms of their ongoing behavior. By
shifting the focus of the state explosion problem from the
size of the state space (as in explicit-state model checking) to
the size of the BDD representation, symbolic model checking
can be used to verify much larger systems. Though the time
complexity bottleneck of the LTL symbolic model checking
algorithm is arguably the translation step from to A , there
are numerous facets of the algorithm worth optimizing, not
all of which were mentioned above. Given the promise of this
method of formal verification and the real-world verification
successes so far, optimization of virtually every segment of
this algorithm is a possible subject for future research.
Arguably the most pressing challenge in model checking
today is scalability. We must make model-checking tools
more efficient, in terms of the size of the models they can
reason about and the time and space they require, in order
to scale our verification ability to handle real-world safetycritical systems. Currently, LTL symbolic model checking is
best used for systems whose state sets have short and easily
manipulated descriptions [168]. However, we have previously
mentioned that there are some functions with unavoidably
exponential symbolic representations.26 In the future, we
expect even more specialized variants of this algorithm to
branch out from the common framework we have presented
here in order to provide a greater array of options for
practical LTL symbolic model checking of real-world systems,
including those with characteristics we are currently unable
to accommodate.
In the coming years, we expect to see more refined
techniques for adding uncertainty in the model such
as inaccurate sensor data or models of humans in
26 See [137] for a proof that a BDD representation of a
function describing the outputs of an integer multiplier grows
exponentially regardless of the variable ordering.

37

the loop, abstractions for representing real-valued and

infinite-range variables, algorithms that include probabilistic
randomization, other extensions that allow probabilistic
reasoning similar to rare-event simulation, and more tools
for efficient model checking for extensions of LTL such as
the industrial logics overviewed in Section 3.2.4. Furthermore,
increasing the level of automation in the application of more
scalable techniques will be necessary in order to complete
large-scale verification efforts in reasonable time-frames. For
example, increased automation of the process of partitioning
our entire example automated air traffic control architecture
for compositional verification would significantly contribute
to the success of such a large task.

Acknowledgements
Thanks to Moshe Y. Vardi, Eric W. D. Rozier, and Misty
D. Davies for insightful comments on earlier drafts of this
paper. Thanks also to Heinz Erzberger for enlightening
conversations on the automated airspace concept for air
traffic control, which made a wonderful running example.
REFERENCES

[1] R.W. Butler, G.B. Finelli, The infeasibility of quantifying the

reliability of life-critical real-time software, IEEE TSE 19 (1)
(1993) 312.
[2] E.M. Clarke, E.A. Emerson, Design and synthesis of
synchronization skeletons using branching time temporal
logic, in: Proc. Workshop on Logic of Programs, in: LNCS, vol.
131, Springer, 1981, pp. 5271.
[3] J.P. Queille, J. Sifakis, Specification and verification of
concurrent systems in Cesar, in: Proc. 5th Intl Symp. on
Programming, in: LNCS, vol. 137, Springer, 1982, pp. 337351.
[4] A. Pnueli, The temporal logic of programs, in: FOCS, Proc.
18th IEEE Symp., 1977, pp. 4657.
[5] M.Y. Vardi, P. Wolper, An automata-theoretic approach
to automatic program verification, in: Proc. 1st LICS,
Cambridge, 1986, pp. 332344.
[6] M.Y. Vardi, Automata-theoretic model checking revisited,
in: VMCAI, Proc. 7th Intl Conf., in: LNCS, vol. 4349, Springer,
2007, pp. 137150.
[7] O. Bernholtz, M.Y. Vardi, P. Wolper, An automata-theoretic
approach to branching-time model checking, in: D.L. Dill
(Ed.), CAV, Proc. 6th Intl Conf., in: LNCS, vol. 818, Springer,
Berlin, 1994, pp. 142155.
[8] G.J. Holzmann, The model checker SPIN, in: Formal Methods
in Software Practice, IEEE TSE 23 (5) (1997) 279295 (special
issue).
[9] A. Duret-Lutz, D. Poitrenaud, SPOT: an extensible model
checking library using transition-based generalized Bchi
automata, in: MASCOTS, Proc. 12th Intl Workshop, IEEE,
2004, pp. 7683.
[10] C. Courcoubetis, M.Y. Vardi, P. Wolper, M. Yannakakis,
Memory efficient algorithms for the verification of temporal
properties, Form. Methods Syst. Des. 1 (1992) 275288.
[11] G.J. Holzmann, D. Peled, M. Yannakakis, On nested depthfirst search, in: Proc. 2nd SPIN Workshop, American Math.
Soc., 1996, pp. 2332.
[12] T.H. Cormen, C.E. Leiserson, R.L. Rivest, C. Stein, Introduction to Algorithms, McGraw-Hill Higher Education, 2001.
[13] J.-C. Fernandez, L. Mounier, C. Jard, T. Jeron, On-the-fly
verification of finite transition systems, Form. Methods Syst.
Des. 1 (1992) 251273.

38

COMPUTER SCIENCE REVIEW

[14] J. Geldenhuys, H. Hansen, Larger automata and less work for

LTL model checking, in: 13th Intl SPIN, in: LNCS, vol. 3925,
Springer, 2006, pp. 5370.
[15] X. Thirioux, Simple and efficient translation from LTL
formulas to Bchi automata, Electron. Notes Theor. Comput.
Sci. 66 (2) (2002) 145159.
[16] D. Peled, All from one, one for all: on model checking using
representatives, in: CAV, Proc. 5th Conf., in: LNCS, Springer,
Elounda, 1993.
[17] R. Milner, An algebraic definition of simulation between
programs, in: Proc. 2nd Intl Joint Conf. on Artificial
Intelligence, British Computer Society, 1971, pp. 481489.
[18] C.B. Jones, Specification and design of (parallel) programs,
in: R.E.A. Mason (Ed.), Information Processing 83: Proc. IFIP
9th World Congress, IFIP, North-Holland, 1983, pp. 321332.
[19] K. McMillan, The SMV language. Technical report, Cadence
Berkeley Lab, 1999.
[20] A. Cimatti, E.M. Clarke, F. Giunchiglia, M. Roveri, NuSMV:
A new symbolic model checker, STTT Int. J. 2 (4) (2000)
410425.
[21] R.K. Brayton, G.D. Hachtel, A. Sangiovanni-Vincentelli,
F. Somenzi, A. Aziz, S.-T. Cheng, S. Edwards, S. Khatri, T.
Kukimoto, A. Pardo, S. Qadeer, R.K. Ranjan, S. Sarwary,
T.R. Shiple, G. Swamy, T. Villa, VIS: a system for verification
and synthesis, in: CAV, Proc. 8th Intl Conf, in: LNCS, vol.
1102, Springer, 1996, pp. 428432.
[22] J.R. Burch, E.M. Clarke, K.L. McMillan, D.L. Dill,
L.J. Hwang, Symbolic model checking: 1020 states and
beyond, Inform. Comput. 98 (2) (1992) 142170.
[23] E.M. Clarke, O. Grumberg, K. Hamaguchi, Another look at
LTL model checking, Form. Methods Syst. Des. 10 (1) (1997)
4771.
[24] E.A. Emerson, C.L. Lei, Efficient model checking in fragments
of the propositional -calculus, in: LICS, 1st Symp.,
Cambridge, Jun 1986, pp. 267278.
[25] K.L. McMillan, Symbolic model checking: an approach to the
state explosion problem, Ph.D. thesis, CMU, Pittsburgh, PA,
USA, 1992.
[26] E.M. Clarke, The birth of model checking, in: 25 Years
of Model Checking, 2008, pp. 126. doi:10.1007/978-3-54069850-0_1.
[27] J.R. Burch, E.M. Clarke, D.E. Long, K.L. Mcmillan, D.L. Dill,
Symbolic model checking for sequential circuit verification,
IEEE TCAD 13 (1993) 401424.
[28] A. Cimatti, F. Giunchiglia, E. Giunchiglia, P. Traverso,
Planning via model checking: A decision procedure for AR,
in: ECP, pp. 130142, 1997.
[29] E.M. Clarke, O. Grumberg, D.E. Long, Model checking and
abstraction, in: POPL, Proc. 19th ACM Symp., Albuquerque,
New Mexico, Jan 1992, pp. 343354.
[30] A. Valmari, A stubborn attack on state explosion, in: CAV,
Proc. 2nd Conf., in: LNCS, vol. 531, Springer, Rutgers, 1990,
pp. 156165.
[31] P. Wolper, M.Y. Vardi, A.P. Sistla, Reasoning about infinite
computation paths, in: FOCS, Proc. 24th IEEE Symp., Tucson,
1983, pp. 185194.
[32] A. Biere, A. Cimatti, E.M. Clarke, Y. Zhu, Symbolic model
checking without BDDs, in: TACAS, in: LNCS, vol. 1579,
Springer, 1999.
[33] K.G. Larsen, P. Petterson, W. Yi, UPPAAL: status &
developments, in: CAV, Proc. 9th Intl Conf., in: LNCS, vol.
1254, Springer, 1997, pp. 456459.
[34] T.A. Henzinger, P-H. Ho, H. Wong-Toi, HYTECH: a model
checker for hybrid systems, STTT 1 (12) (1997) 110122.
[35] O. Kupferman, M.Y. Vardi, An automata-theoretic approach
to reasoning about infinite-state systems, in: CAV, Proc. 12th
Intl Conf., in: LNCS, vol. 1855, Springer, 2000, pp. 3652.

[36] M. Chechik, B. Devereux, A. Gurfinkel, Model-checking

infinite state-space systems with fine-grained abstractions
using SPIN, in: Proc. 8th SPIN, in: LNCS, vol. 2057, Springer,
2001, pp. 1636.
[37] L. Pike, Real-time system verification by k-induction,
Technical Report TM-2005-213751, NASA Langley Research
Center, 2005.
[38] L. Lamport, Real-time model checking is really simple, in:
CHARME, 2005, pp. 162175.
[39] G. Lindstrom, P.C. Mehlitz, W. Visser, Model checking
real time java using java pathfinder, in: ATVA, vol. 3707,
Springer, 2005, pp. 444456.
[40] V. Schuppan, A. Biere, Liveness checking as safety checking
for infinite state spaces, Electron. Notes Theor. Comput. Sci.
149 (1) (2006) 7996.
[41] H. Erzberger, The automated airspace concept, in: 4th
USA/Europe Air Traffic Management R&D Seminar, Santa Fe,
New Mexico, USA, Dec. 2001.
[42] A. Cimatti, E.M. Clarke, E. Giunchiglia, F. Giunchiglia,
M. Pistore, M. Roveri, R. Sebastiani, A. Tacchella, Nusmv 2:
An opensource tool for symbolic model checking, in: CAV,
Proc. 14th Intl Conf., in: LNCS, vol. 2404, Springer, 2002,
pp. 359364.
[43] A. Cimatti, R. Cavada, C. Jochim, G. Keighren, E. Olivetti,
M. Pistore, M. Roveri, A. Tchaltsev, NuSMV 2.4 user manual.
Technical report, CMU and ITC-irst, 2005.
[44] F. Raimondi, A. Lomuscio, M.J. Sergot, Towards model
checking interpreted systems, in: Proc. of 2nd NASA
Workshop on Formal Approaches to Agent-Based Systems,
FAABS02, in: LNAI, vol. 2699, Springer, 2002, pp. 115125.
[45] M. Gribaudo, A. Horvath, A. Bobbio, E. Tronci, E. Ciancamerla, M. Minichino, Model-checking based on fluid petri
nets for the temperature control system of the icaro cogenerative plant. Technical report, Proc. SAFECOMP, vol.
2434, LNCS, 2002.
[46] A.C. Tribble, S.P. Miller, Software safety analysis of a flight
management system vertical navigation function - a status
report, in: DASC, 22nd, vol. 1, Oct. 2003, pp. 1.B.11.19, vol.1.
[47] Y. Choi, M. Heimdahl, Model checking software requirement
specifications using domain reduction abstraction, in: ASE,
Proc. 18th IEEE Intl Conf., Oct. 2003, pp. 314317.
[48] S.P. Miller, A.C. Tribble, M.W. Whalen, M. Per, E. Heimdahl,
Proving the shalls, STTT 8 (45) (2006) 303319.
[49] S. Miller, Will this be formal?, in: Theorem Proving in Higher
Order Logics, vol. 5170, Springer, 2008, pp. 611.
[50] L. de Moura, S. Owre, H. Rue, J. Rushby, N. Shankar,
M. Sorea, A. Tiwari, SAL 2, in: R. Alur, D. Peled (Eds.), CAV,
in: LNCS, vol. 3114, Springer, Boston, MA, 2004, pp. 496500.
[51] R.M. Burstall, Program proving as hand simulation with
a little induction, in: Information Processing 74, NorthHolland, Stockholm, Sweden, 1974, pp. 308312. Intl Fed. for
Information Processing.
[52] F Kroger, LAR: a logic of algorithmic reasoning, Acta Inform.
8 (1977) 243266.
[53] E.M. Clarke, O. Grumberg, D. Long, Verification tools
for finite-state concurrent systems, in: J.W. de Bakker,
W.-P. de Roever, G. Rozenberg (Eds.), Decade of Concurrency
Reflections and Perspectives (Proc. of REX School),
in: LNCS, vol. 803, Springer, 1993, pp. 124175.
[54] J.A.W. Kamp, Tense Logic and the Theory of Order, Ph.D.
Thesis, UCLA, 1968.
[55] M. Ben-Ari, Z. Manna, A. Pnueli, The temporal logic of
branching time, in: POPL, Proc. of 8th ACM SIGPLAN-SIGACT
Symp., ACM, New York, NY, USA, 1981, pp. 164176.
[56] O. Lichtenstein, A. Pnueli, Checking that finite state
concurrent programs satisfy their linear specification, in:
POPL, Proc. 12th ACM Symp., New Orleans, Jan 1985,
pp. 97107.
[57] M.Y. Vardi, From Church and Prior to PSL, in: Proc. of
Workshop on 25 Years of Model Checking, 2006.

COMPUTER SCIENCE REVIEW

[58] W. Visser, H. Barringer, Practical CTL model checking:

Should SPIN be extended? STTT 2 (4) (2000) 350365.
[59] D. Gabbay, A. Pnueli, S. Shelah, J. Stavi, On the temporal
analysis of fairness, POPL, Proc. 7th ACM Symp., 1980, pp.
163173.
[60] E.A. Emerson, Temporal and modal logic, in: J. Van Leeuwen
(Ed.), Handbook of Theoretical Computer Science, vol. B,
Elsevier, MIT Press, 1990, pp. 9971072 (chapter 16).
[61] M.Y. Vardi, Automata-theoretic techniques for temporal
reasoning, in: Frank Wolter, Patrick Blackburn, Johan van
Benthem (Eds.), Handbook of Modal Logic, Elsevier, 2006.
[62] L. Lamport, sometimes is sometimes not never on the
temporal logic of programs, in: POPL. Proc. 7th ACM Symp.,
Jan 1980, pp. 174185.
[63] M.Y. Vardi, Branching vs. linear time: Final showdown,
in: TACAS, Proc. 7th Intl Conf., in: LNCS, vol. 2031, Springer,
2001, pp. 122.
[64] E.M. Clarke, E.A. Emerson, A.P. Sistla, Automatic verification
of finite-state concurrent systems using temporal logic
specifications, ACM TOPLAS 8 (2) (1986) 244263.
[65] M.Y. Vardi, P. Wolper, Reasoning about infinite computations, Inform. and Comput. 115 (1) (1994) 137.
[66] E.A. Emerson, C.-L. Lei, Modalities for model checking:
branching time logic strikes back, in: POPL, 20th ACM Symp.,
New Orleans, Jan 1985, pp. 8496.
[67] A.P. Sistla, E.M. Clarke, The complexity of propositional
linear temporal logic, J. ACM 32 (1985) 733749.
[68] M.J. Fischer, R.E. Ladner, Propositional dynamic logic of
regular programs, J. Comput. Syst. Sci. 18 (1979) 194211.
[69] E.A. Emerson, J.Y. Halpern, Decision procedures and
expressiveness in the temporal logic of branching time, J.
Comput. Syst. Sci. 30 (1985) 124.
[70] M.Y. Vardi, Linear vs. branching time: a complexitytheoretic perspective, in: LICS, Proc. 13th IEEE Symp., 1998,
pp. 394405.
[71] M. Huth, M. Ryan, Logic in Computer Science: Modelling and
Reasoning about Systems, Cambridge U. Press, New York,
NY, USA, 2004.
[72] C. Baier, J.-P. Katoen, Principles of Model Checking, MIT
Press, 2008.
[73] B. Berard, M. Bidoit, A. Finkel, F. Laroussinie, A. Petit, L.
Petrucci, Ph. Schnoebelen, Systems and Software Verification: Model-Checking Techniques and Tools, Springer, 2001.
[74] D. Giannakopoulou, Model Checking for Concurrent Software Architectures. Ph.D. Thesis, Imperial College of Science, Technology, and Medicine, U. of London, Jan 1999.
[75] E.A. Emerson, J.Y. Halpern, Sometimes and not never
revisited: on branching versus linear time, J. ACM 33 (1)
(1986) 151178.
[76] M.Y. Vardi, L. Stockmeyer, Improved upper and lower
bounds for modal logics of programs, in: STOC, Proc. 17
ACM, 1985, pp. 240251.
[77] E.A. Emerson, C. Jutla, The complexity of tree automata and
logics of programs, in: FOCS, 29th IEEE Symp., White Plains,
Oct 1988, pp. 328337.
[78] E.A. Emerson, A.P. Sistla, Deciding branching time logic, in:
STOC, Proc. 16th ACM, Washington, Apr 1984, pp. 1424.
[79] P. Wolper, Temporal logic can be more expressive, Inf.
Control 56 (12) (1983) 7299.
[80] J.-M. Couvreur, Un point de vue symbolique sur la logique
temporelle linaire, in: Pub. du LaCIM, in: Actes du Colloque
LaCIM 2000, Univ. du Qubec Montral, Aug 2000, vol. 27,
pp. 131140.
[81] B. Banieqbal, H. Barringer, Temporal logic with fixed points,
in: B. Banieqbal, H. Barringer, A. Pnueli (Eds.), Temporal
Logic in Specification, in: LNCS, vol. 398, Springer, 1987,
pp. 6274.
[82] M.Y. Vardi, A temporal fixpoint calculus, in: POPL, Proc. 15th
ACM Symp., San Diego, 1988, pp. 250259.

39

[83] A.P. Sistla, M.Y. Vardi, P. Wolper, The complementation

problem for Bchi automata with applications to temporal
logic, Theoret. Comput. Sci. 49 (1987) 217237.
[84] E.A. Emerson, R.J. Trefler, Generalized quantitative temporal
reasoning: An automata theoretic approach, in: TAPSOFT,
Proc., in: LNCS, vol. 1214, Springer, 1997, pp. 189200.
[85] L. Fix, Fifteen years of formal property verification at intel.
This Volume, 2007.
[86] R. Armoni, L. Fix, A. Flaisher, R. Gerth, B. Ginsburg, T. Kanza,
A. Landver, S. Mador-Haim, E. Singerman, A. Tiemeyer,
M.Y. Vardi, Y. Zbar, The ForSpec temporal logic: A new
temporal property-specification logic, in: TACAS, Proc. 8th
Intl, in: LNCS, vol. 2280, Springer, 2002, pp. 296311.
[87] I. Beer, S. Ben-David, C. Eisner, D. Fisman, A. Gringauze, Y.
Rodeh, The temporal logic Sugar, in: CAV, Proc. 13th Intl
Conf., Paris, France, July 2001, in: LNCS, vol. 2102, Springer,
2001, pp. 363367.
[88] C. Eisner, D. Fisman, Sugar 2.0 proposal presented to the
accellera formal verification technical committee, 2002.
[89] M.J. Morley, Semantics of temporal e, in: T.F. Melham,
F.G. Moller (Eds.), BANFF Higher Order Workshop. U. of
Glasgow, Dept. of Computing Sci. Tech. Report, 1999.
[90] S. Vijayaraghavan, M. Ramanathan, A practical guide for
SystemVerilog assertions, 2005.
[91] J. Havlicek, Y. Wolfsthal, PSL and SVA: Two standard
assertion languages addressing complimentary engineering
needs, in: Proc. Design Verification Conf., Feb. 2005.
[92] M.Y. Vardi, From monadic logic to PSL, in: Arnon Avron,
Nachum Dershowitz, Alexander Rabinovich (Eds.), Pillars of
Comp. Sci., in: LNCS, vol. 4800, Springer, 2008, pp. 656681.
[93] G. Rosu, S. Bensalem, Allen Linear (interval) Temporal Logic
translation to LTL and monitor synthesis, in: CAV, 2006,
pp. 263277.
[94] J.F. Allen, Towards a general theory of action and time, Artif.
Intell. 23 (2) (1984) 123154.
[95] O. Kupferman, Sanity checks in formal verification,
in: CONCUR, Proc. 17th Intl Conf., in: LNCS, vol. 4137,
Springer, 2006, pp. 3751.
[96] R.P. Kurshan, FormalCheck Users Manual, Cadence Design,
Inc., 1998.
[97] G. Ammons, D. Mandelin, R. Bodik, J.R. Larus, Debugging
temporal specifications with concept analysis, PLDI, Proc.
ACM Conf. (2003) 182195.
[98] R. Armoni, L. Fix, A. Flaisher, O. Grumberg, N. Piterman, A.
Tiemeyer, M.Y. Vardi, Enhanced vacuity detection for linear
temporal logic, in: CAV, Proc 15th Intl Conf, Springer, 2003.
[99] I. Beer, S. Ben-David, C. Eisner, Y. Rodeh, Efficient detection
of vacuity in ACTL formulas, Form. Methods Syst. Des. 18 (2)
(2001) 141162.
[100] D. Bustan, A. Flaisher, O. Grumberg, O. Kupferman,
M.Y. Vardi, Regular vacuity, in: CHARME, in: LNCS, vol. 3725,
Springer, 2005, pp. 191206.
[101] A. Gurfinkel, M. Chechik, How vacuous is vacuous,
in: TACAS, 10th Intl Conf, in: LNCS, vol. 2988, Springer, 2004,
pp. 451466.
[102] A. Gurfinkel, M. Chechik, Extending extended vacuity,
in: FMCAD, 5th Intl Conf, in: LNCS, vol. 3312, Springer, 2004,
pp. 306321.
[103] O. Kupferman, M.Y. Vardi, Vacuity detection in temporal
model checking, STTT 4 (2) (2003) 224233.
[104] K.S. Namjoshi, An efficiently checkable, proof-based formulation of vacuity in model checking, in: 16th CAV, in: LNCS,
vol. 3114, Springer, 2004, pp. 5769.
[105] M. Purandare, F. Somenzi, Vacuum cleaning CTL formulae,
in: CAV, Proc. 14th Conf., in: LNCS, Springer, 2002,
pp. 485499.
[106] K.Y. Rozier, M.Y. Vardi, LTL satisfiability checking, in: Proc.
14th SPIN, in: LNCS, vol. 4595, Springer, 2007, pp. 149167.

40

COMPUTER SCIENCE REVIEW

[107] O. Kupferman, M.Y. Vardi, P. Wolper, An automata-theoretic

approach to branching-time model checking, J. ACM 47 (2)
(2000) 312360.
[108] J.R. Bchi, On a decision method in restricted second order
arithmetic, in: Proc. Intl Congress on Logic, Method, and
Philosophy of Sci. 1960, Stanford U. Press, Stanford, 1962,
pp. 112.
[109] J.-M. Couvreur, On-the-fly verification of linear temporal
logic, in Proc. FM, 1999, pp. 253271.
[110] M.Y. Vardi, An automata-theoretic approach to linear
temporal logic, in: F. Moller, G. Birtwistle (Eds.), Logics for
Concurrency: Structure versus Automata, in: LNCS, vol.
1043, Springer, Berlin, 1996, pp. 238266.
[111] A.P. Sistla, M.Y. Vardi, P. Wolper, The complementation
problem for Bchi automata with applications to temporal
logic, in: ICALP, Proc. 10th, in: LNCS, vol. 194, Springer,
Nafplion, 1985, pp. 465474.
[112] S. Safra, M.Y. Vardi, On -automata and temporal logic, in:
STOC, Proc. 21st ACM, Seattle, May 1989, pp. 127137.
[113] R. Gerth, D. Peled, M.Y. Vardi, P. Wolper, Simple onthe-fly automatic verification of linear temporal logic,
in: P. Dembiski, M. Sredniawa (Eds.), PSTV, Chapman & Hall,
1995.
[114] N. Daniele, F. Guinchiglia, M.Y. Vardi, Improved automata
generation for linear temporal logic, in: CAV, Proc. 11th Intl
Conf, in: LNCS, vol. 1633, Springer, 1999, pp. 249260.
[115] F. Somenzi, R. Bloem, Efficient Bchi automata from LTL
formulae, in: CAV, Proc. 12th Intl Conf, in: LNCS, vol. 1855,
Springer, 2000, pp. 248263.
[116] P. Gastin, D. Oddoux, Fast LTL to Bchi automata translation,
in: CAV, Proc. 13th Intl Conf, in: LNCS, vol. 2102, Springer,
2001, pp. 5365.
[117] D. Giannakopoulou, F. Lerda, From states to transitions:
improving translation of LTL formulae to Bchi automata,
in: FORTE, Proc of 22 IFIP Intl Conf, Nov 2002.
[118] R. Sebastiani, S. Tonetta, More deterministic vs. smaller
Bchi automata for efficient LTL model checking,
in: CHARME, Springer, 2003, pp. 126140.
[119] C. Fritz, Concepts of automata construction from LTL,
in: LPAR, Proc. 12th Intl Conf., in: LNCS, vol. 3835, Springer,
2005, pp. 728742.
[120] L. Lamport, Proving the correctness of multiprocess
programs, IEEE TSE 3 (2) (1977) 125143.
[121] S. Owicki, L. Lamport, Proving liveness properties of
concurrent programs, ACM TOPLAS 4 (3) (1982) 455495.
[122] O. Kupferman, M.Y. Vardi, Model checking of safety
properties, in: CAV, Proc. 11th Intl Conf., in: LNCS, vol. 1633,
Springer, 1999, pp. 172183.
[123] B. Alpern, F.B. Schneider, Recognizing safety and liveness,
Distrib. Comput. 2 (1987) 117126.
[124] E. Kindler, Safety and liveness properties: a survey, Bull.
EATCS 53 (1994) 268272.
[125] M.W. Alford, J.P. Ansart, G. Hommel, L. Lamport, B. Liskov,
G.P. Mullery, F.B. Schneider, Dist. Systems: Methods and
Tools for Specification. An Advanced Course, Springer, NY,
USA, 1985.
[126] A.P. Sistla, Safety, liveness, and fairness in temporal logic,
Form. Asp. Comput. 6 (1994) 495511.
[127] B. Alpern, F.B. Schneider, Defining liveness, Inform. Process.
Lett. 21 (1985) 181185.
[128] R.P. Kurshan, CAV of Coordinating Processes, Princeton Univ.
Press, 1994.
[129] S. Safra, On the complexity of -automata, in: FOCS, Proc.
29th IEEE Symp., White Plains, 1988, pp. 319327.
[130] O. Kupferman, M.Y. Vardi, Weak alternating automata are
not that weak, in: ISTCS, Proc. 5th, IEEE Press, 1997,
pp. 147158.
[131] L. Doyen, J.-F. Raskin, Improved algorithms for the
automata-based approach to model-checking, in: TACAS,
in: LNCS, vol. 4424, Springer, 2007, pp. 451465.

[132] S. Fogarty, M.Y. Vardi, Bchi complementation and sizechange termination, in: TACAS, Proc. of 15th Intl Conf.,
Springer, Berlin, Heidelberg, 2009, pp. 1630.
[133] A. Biere, A. Cimatti, E. Clarke, O. Strichman, Y. Zhu, Bounded
model checking, Adv. Comput. 58 (2003).
[134] C. Lee, Representation of switching circuits by binary
decision programs, Bell Syst. Tech. J. 38 (1959) 985999.
[135] S.B. Akers, Binary decision diagrams, IEEE TC C-27 (6) (1978)
509516.
[136] S. Fortune, J.E. Hopcroft, E.M. Schmidt, The complexity
of equivalence and containment for free single variable
program schemes, in: ICALP, Proc. 5th, Springer, London, UK,
1978, pp. 227240.
[137] R.E. Bryant, Graph-based algorithms for Boolean-function
manipulation, IEEE TC C-35 (8) (1986) 677691.
[138] R.E. Bryant, Symbolic Boolean manipulation with Ordered
Binary-Decision Diagrams, ACM Comput. Surv. 24 (3) (1992)
293318.
[139] P. Linz, An Introduction to Formal Languages and Automata,
2nd ed., D. C. Heath and Company, Lexington, MA, USA,
1996 (Chapter 14).
[140] P Gribomont, P Wolper, in: A. Thayse (Ed.), Temporal logic,
in from modal logic to deductive databases, 1989.
[141] M. Michel, Complementation is more difficult with automata on infinite words, in: CNET, Paris, 1988.
[142] J. Esparza, Decidability of model checking for infinite-state
concurrent systems, Acta Inform. 34 (1997) 85107.
[143] S. Minato, N. Ishiura, S. Yajima, Shared binary decision
diagram with attributed edges for efficient Boolean function
manipulation, in: DAC, Proc. 27th ACM/IEEE Conf., 1990,
pp. 5257.
[144] G.D. Hachtel, E. Macii, A. Pardo, F. Somenzi, Markovian
analysis of large finite state machines, IEEE Trans. Comput.
Aided. Des. 15 (1996) 14791493.
[145] M. Chechik, S. Easterbrook, B. Devereux, Model checking
with multi-valued temporal logics, in: ISMVL, 2000, pp.
187192.
[146] Henrik Reif Andersen, An Introduction to Binary Decision
Diagrams, Internet, Sept 1996.
[147] D. Sieling, I. Wegener, Reduction of OBDDs in linear time,
Inform. Process. Lett. 48 (3) (1993) 139144.
[148] Y. Kesten, A. Pnueli, L. Raviv, Algorithmic verification of
linear temporal logic specifications, in: ICALP, Proc. 25th,
in: LNCS, vol. 1443, Springer, 1998, pp. 116.
[149] E.M. Clarke, O. Grumberg, D. Peled, Model Checking, MIT
Press, 1999 (Chapter 16, 89).
[150] R.S. Streett, Propositional dynamic logic of looping and
converse, Inf. Control 54 (1982) 121141.
[151] N. Francez, D. Kozen, Generalized fair termination, in: POPL,
1984, pp. 4653.
[152] E.M. Clarke, O. Grumberg, K.L. McMillan, X. Zhao, Efficient
generation of counterexamples and witnesses in symbolic
model checking, in: DAC, Proc. 32nd, IEEE, 1995, pp. 427432.
[153] R. Hojati, R.K. Brayton, R.P. Kurshan, BDD-based debugging
of design using language containment and fair CTL, in: CAV,
Springer-Verlag, London, UK, 1993, pp. 4158.
[154] Z. Manna, A. Pnueli, The Temporal Logic of Reactive and
Concurrent Systems: Safety, Springer, New York, 1995.
[155] K. Ravi, R. Bloem, F. Somenzi, A comparative study of
symbolic algorithms for the computation of fair cycles,
in: FMCAD, Proc. Intl. Conf., in: LNCS, vol. 1954, Springer,
2000, pp. 143160.
[156] R. Hojati, H. Touati, R. Kurshan, R. Brayton, Efficient regular language containment, in: CAV, Proc. 4th Intl Conf.,
in: LNCS, vol. 663, Springer, 1992.
[157] R.H. Hardin, R.P. Kurshan, S.K. Shukla, M.Y. Vardi, A new
heuristic for bad cycle detection using BDDs, in: CAV,
Proc. 9th Intl Conf., in: LNCS, vol. 1254, Springer, 1997,
pp. 268278.

COMPUTER SCIENCE REVIEW

[158] A. Xie, P. Beerel, Implicit enumeration of strongly connected

components, in: ICCAD, ACM, IEEE Press, San Jose, CA, USA,
1999, pp. 3740.
[159] A. Xie, P.A. Beerel, Implicit enumeration of strongly
connected components and an application to formal
verification, IEEE Trans. Comput. Aided. Des. 19 (10) (2000)
12251230.
[160] R. Bloem, H.N. Gabow, F. Somenzi, An algorithm for strongly
connected component analysis in n log n symbolic steps,
in: FMCAD, in: LNCS, vol. 1954, Springer, 2000, pp. 3754.
[161] K. Fisler, R. Fraer, G. Kamhi, M.Y. Vardi, Z. Yang, Is there a
best symbolic cycle-detection algorithm? in: TACAS, 7th Intl
Conf., in: LNCS, vol. 2031, Springer, 2001, pp. 420434.
[162] S. Ben-David, J. Pound, R.J. Trefler, D. Tsarkov, G.E. Weddell,
Fair cycle detection using description logic reasoning, in:
Description Logics, 2009.
[163] Cadence.
SMV.
http://www.cadence.com/company/
cadence_labs_research.html.
[164] R. Anderson, P. Beame, S. Burns, W. Chan, F. Modugno,
D. Notkin, J.D. Reese, Model checking large software
specifications, IEEE TSE 24 (1996) 156166.
[165] T. Sreemani, J.M. Atlee, Feasibility of model checking
software requirements: a case study, in: COMPASS, IEEE,
1996, pp. 7788.
[166] C. Muoz, V. Carreo, G. Dowek, Formal analysis of the
operational concept for the small aircraft transportation

41

system, in: Rigorous Engineering of Fault-Tolerant Systems,

in: LNCS, vol. 4157, 2006, pp. 306325.
[167] A. Betin Can, T. Bultan, M. Lindvall, B. Lux, S. Topp,
Eliminating synchronization faults in air traffic control
software via design for verification with concurrency
controllers, Autom. Softw. Eng. 14 (2) (2007) 129178.
[168] P. Wolper, An introduction to model checking, in: Proc. of
Software Quality Week, SQW95, San Francisco, CA, 1995.
[169] D. Sieling, The nonapproximability of OBDD minimization,
Inform. and Comput. 172 (1998) 103138.

Kristin Y. Rozier is a Research Computer

Scientist at NASA Ames Research Center.
Kristin has been a member of the
Robust Software Engineering (RSE) team
since September, 2008, a member of the
NASA Formal Methods (NFM) research
group since November, 2003, and a NASA
employee since May, 2001. She holds a B.S.
and an M.S. from the College of William
and Mary and is a Ph.D. candidate at Rice University under
the advisement of Moshe Y. Vardi. Kristin is a member of PBK,
ACM, IEEE, SWE, Systers, and AIAA, where she serves on the
Intelligent Systems Technical Committee.