The Generalized Railroad Crossing: A Case Study in Formal

Verication of Real-Time Systems

Constance Heitmeyer Nancy Lynchy

Abstract
A new solution to the Generalized Railroad Crossing problem, based on timed automata, invariants
and simulation mappings, is presented and evaluated. The solution shows formally the correspondence
between four system descriptions: an axiomatic specication, an operational specication, a discrete
system implementation, and a system implementation that works with a continuous gate model.

1 Introduction
During the last decade, a large collection of formal methods have been invented for specifying,
designing, and analyzing real-time systems. To compare these methods and to better understand
their use in developing practical real-time systems, one of us (Heitmeyer) has dened a benchmark
problem, called the Generalized Railroad (GRC) Crossing [7]. The problem is as follows.
The system to be developed operates a gate at a railroad crossing. The railroad crossing I lies
in a region of interest R, i.e., I  R. A set of trains travel through R on multiple tracks in
both directions. A sensor system determines when each train enters and exits region R. To
describe the system formally, we dene a gate function g(t) 2 [0; 90], where g(t) = 0 means
the gate is down and g(t) = 90 means the gate is up. We also dene a set fi g of occupancy
intervals, where each occupancy interval is a time interval during which one or more trains
are in I . The ith occupancy interval is represented as i = [i; i], where i is the time of the
ith entry of a train into the crossing when no other train is in the crossing and i is the rst
time since i that no train is in the crossing (i.e., the train that entered at i has exited as
have any trains that entered the crossing after i ).
Given two constants 1 and 2, 1 > 0; 2 > 0; the problem is to develop a system to operate
the crossing gate that satises the following two properties:
Safety Property: t 2 [i i ) g (t) = 0 (The gate is down during all occupancy intervals.)
Utility Property: t 62 [i [i , 1 ; i + 2 ] ) g (t) = 90 (The gate is up when no train is in
the crossing.)
To solve the GRC problem, real-time researchers have applied a variety of formal methods,
including process algebraic [9, 3, 1], event-based [10], and logic-based approaches [19, 11]. They

Code 5546, Naval Research Laboratory, Washington, D.C. 20375.
y
Laboratory for Computer Science, Massachusetts Institute of Technology, Cambridge, MA 02139. Supported by
NSF grant 9225124-CCR, ONR contract N00014-91-J-1046, AFOSR contract F49620-94-1-0199, and ARPA contract
N00014-92-J-4033.
have also used various mechanical proof systems, including PVS [18], EVES [11], and FDR [2], to
formally analyze and verify their solutions. Reference [5] describes three early eorts to solve the
GRC problem.
This paper describes a new solution of the GRC based on the Lynch-Vaandrager timed automaton
model [16, 15], using invariant and simulation mapping techniques [12, 15, 14]. To develop the
solution, a \formal methods expert" (Lynch) and an \applications expert" (Heitmeyer) worked closely
together to rene the GRC problem statement and to design and verify an implementation.
Our close collaboration was in sharp contrast to the limited interaction between the Naval Re-
search Laboratory (NRL) group that originated the GRC problem and the formal methods groups
that developed earlier solutions. In the earlier work, the NRL group limited interaction both to en-
courage original solutions and to prevent some groups from having more information and thus unfair
advantage over other groups. While these early eorts produced a variety of solutions and many
insights into the relative strengths and weaknesses of the dierent formalisms, they suered from
two limitations. First, because the original problem statement was somewhat ambiguous, each group
solved a slightly dierent problem, which caused diculties in comparing the solutions. Second, the
limited interaction meant that deciencies in the GRC problem statement went uncorrected. Our
collaboration allowed us quickly to identify and correct these deciencies. It also led us to represent
the problem and its solution in a form that is both understandable to applications experts and usable
by formal methods experts for verication.
The rest of the paper is organized as follows. Section 2 describes our approach: general principles
for applying formal methods to specify and verify real-time systems, our formal model and proof
techniques, and an outline of how we applied the formal methods to the GRC problem. Section 3
presents our highest-level problem specication, intended to be understood by applications experts;
it improves over the original problem statement given above by resolving some ambiguities. Section 4
contains a secondary operational specication, intended to be useful in formal verication. Section 5
contains our system implementation. Section 6 contains the main correctness proof. Section 7
describes extensions to more realistic, continuous models of the real world components. Section 8
evaluates our solution and method. Several appendices provide background on the formal methods
we use, plus two proofs about the high-level specication. A concise version of this report, which
omits the details of the proofs, appears in [8].

2 Our Approach
In this section, we describe our approach to solving the GRC problem. Section 2.1 contains some
general principles for applying formal methods to real-time systems. Section 2.2 contains a descrip-
tion of the timed automaton model and of invariant and simulation mapping proof methods. Section
2.3 contains an overview of how we apply these formal methods to the GRC problem.
2.1 Formal Methods for Real-Time Systems
Applying formal methods to real-time systems involves three steps: system requirements specica-
tion, design of an implementation, and verication that the implementation satises the specication.
This process has feedback loops. Once specied, the requirements must be revised when later steps
expose omissions and errors. The same is true of the designed implementation.

2
 All three steps require close collaboration between the formal methods expert and the applications
expert. The role of the formal methods expert is to produce formal descriptions of both the system
requirements and the selected implementation and to prove formally that the latter satises the
former. The role of the applications expert is to work closely with the formal methods expert to
identify the \real" requirements and to ensure that the specied implementation is acceptable. In
our collaboration, much of the dialogue focused on the system requirements. Once the requirements
specication was acceptable, dening and verifying an implementation, while labor-intensive and
time-consuming, was relatively straightforward.
A system requirements specication describes all acceptable system implementations [6]. It has
two parts: (1) A set of formal models describing the computer system at an abstract level, the
environment (here, the trains and the gate), and the interface between them. (2) Formal statements
of the properties that the system must satisfy.
In developing the GRC solution, we applied the following seven software engineering principles.
The rst ve concern the requirements specication. The sixth concerns the implementation and its
verication, and the seventh is applicable to all three steps.
1. Avoid underspecifying system requirements. The original problem statement lacked necessary
information about the various constants. For example, the statement did not constrain the
constant 1. A simple analysis shows that we should assume that 1 > down + 2 , 1 , where
2 is the maximum time and 1 the minimum time that a train requires to travel from entry
into R to the crossing and down is the maximum time needed to lower the gate.
2. Avoid overspecifying system requirements. For example, while the function g is an acceptable
gate model, the GRC problem can be solved using a simpler, discrete model { one that repre-
sents the gate as being in one of four states { up, going-down, down, and going-up. Our solution
uses the simpler model, but we show in Section 7 how to extend our results to the original gate
model.
For another example, the Utility Property stated above does not rule out solutions in which
the last train leaves the crossing at time t but within the interval [t; t + 2] the gate goes rst up
and then down rapidly before the gate is raised for the second (and nal) time. Such solutions,
though not to be encouraged, should not be excluded. The essential system properties are that
the gate must be down when a train is in the crossing and that the gate must be up during the
specied intervals when no train is in the vicinity. During other times, we do not care what
the gate does.
3. Make sure the specied system behavior is reasonable. For example, suppose a train exits the
crossing at time t and another train is scheduled to enter the crossing by time t + up + down .
Then there is insucient time for even one car to travel through the crossing, and thus the
Utility Property fails to achieve its practical purpose. To rule out such useless activity, we
modify the original problem statement to only require the gate to be raised if sucient time,  ,
exists for at least one car to travel through the crossing. A trivial modication of the original
problem statement to include  appears in Appendix D.
4. Specify the system requirements axiomatically rather than operationally. In the original problem
statement, both the Safety Property and the Utility Property are expressed as axioms. Each
axiom describes a relationship that is supposed to hold between the two components of the

3
 system environment, namely, the trains and the crossing gate. Thus the required system prop-
erties are properties of the environment. Neither axiom mentions the computer system. Also,
the two axioms are stated independently, making it easy to modify the individual properties.
In the present study, we initially reformulated the requirements specication operationally, as
a timed automaton. This reformulation incorporated both the Safety and Utility Properties
into a single automaton description, thus losing the advantage of independence. Also, our
reformulation was stronger than the original, specifying some aspects of what the computer
system should do rather than just describing properties that the system needed to guarantee in
the environment. Finally, the operational style of the reformulation was harder for applications
experts to understand. Our nal version of the specication, which appears in Section 3, is
axiomatic. Like the original formulation, it describes the two properties as independent axioms
about the environment.
5. Provide an operational secondary specication plus a formal proof that the operational specica-
tion implements the axiomatic specication. Although it is desirable to start with an axiomatic
specication, the types of proofs we do rest on operational, automaton versions of the speci-
cation and implementation. Therefore, we present a secondary requirements specication in
terms of timed automata and prove that the operational requirements specication implements
the original axiomatic specication.
As in many applications of formal methods, we initially neglected to provide a formal proof of
the correspondence between the original specication and the reformulation within our frame-
work. Without such a proof, there is no assurance that the properties satised by the system
implementation are the ones that are really required. In our case, while it was immediately ob-
vious that the statement of the Safety Property in our operational specication was equivalent
to the original statement of the Safety Property, the correspondence between the two versions
of the Utility Property was not so clear.
6. Provide a formal model for the implementation and a proof that it implements the operational
specication. The implementation should be described using the same model that is used for the
operational specication, or at least one that is compatible. The proof that the implementation
meets the specication can be done using a variety of methods. It might be done by hand, as
in this paper, or with computer assistance.
7. Express the system requirements specication, the implementation, and the formal proofs so
that they are understandable to applications experts. If the requirements specication and the
specication of the implementation are dicult to understand, the applications expert cannot
be condent that the right requirements have been specied and that the implementation
is acceptable. The same holds for the formal proofs: the applications expert must be able
to understand the proofs. This gives him/her a deep understanding of how and why the
system works and how future changes are likely to aect system behavior. To increase their
understandability, both the formal specications and the proofs should be based on standard
models such as automaton models, standard notations, and standard proof techniques such as
invariants and simulation mappings. To the extent feasible, applications experts should not be
required to learn new notations or proof techniques.

4
2.2 The Formal Framework
The formal method we used to specify the GRC problem and to develop and verify a solution
represents both the computer system and the system environment as timed automata, according to
the denitions of Lynch and Vaandrager [16, 15]. A timed automaton is a very general automaton,
i.e., a labeled transition system. It is not nite-state: for example, the state can contain real-
valued information, such as the current time or the position of a train or crossing gate. This makes
timed automata suitable for modeling not only computer systems but also real-world entities such as
trains and gates. We base our work directly on an automaton model rather than on any particular
specication language, programming language, or proof system, so that we may obtain the greatest
exibility in selecting specication and proof methods. The formal denition of a timed automaton
appears in Appendix A.
The timed automaton model supports description of systems as collections of timed automata,
interacting by means of common actions. In our example, we dene separate timed automata for the
trains, the gate, and the computer system; the common actions are sensors reporting the arrival of
trains and actuators controlling the raising and lowering of the gate.
An important special case of the model, describable in a particularly simple way, is the MMT
automaton model [17], developed by Merritt, Modugno and Tuttle. An MMT automaton consists of
a collection of \tasks" (i.e., \processes") sharing common data, where each task has an upper bound
and a lower bound on the time between its events. This special case is sucient for describing several
of our components; in particular, the trains and the discrete version of the gate. Formal denitions
of the MMT model are given in Appendix B. Our other components, e.g., the computer system,
cannot be expressed in the MMT style, so we describe them directly in terms of the general model.
Instead of thinking of the MMT model as a dierent model, we often nd it useful to regard it as
simply a way of describing a large subclass of timed automata.
2.3 Applying Formal Methods to GRC
Our solution contains four system descriptions: AxSpec, the axiomatic requirements specication;
OpSpec, the operational requirements specication; SystImpl, the discrete system implementation;
and SystImpl 0 , a system implementation with a continuous gate model. Figure 1 illustrates the four
specications and how they are related.
The top-level requirements specication, AxSpec, contains timed automata describing the com-
puter system and its environment (the trains and gate), and axioms expressing the Safety and Utility

AxSpec OpSpec SystImpl SystImpl'

Trains Trains Trains Trains
Gate Gate Gate Gate'
CompSpec CompSpec CompImpl CompImpl
Safety Utility OpProps OpProps OpProps

Figure 1: The four system descriptions and how they are related. In OpSpec, OpProps incorporates
the Safety and Utility properties into the automaton that results from composing Trains, Gate, and
CompSpec.

5
Properties. The Safety Property states that any time there is a train in the crossing, the gate must
be down. The Utility Property states that the gate is up unless there is a train in the vicinity.
Formally, these axioms are properties added to the composition of three timed automata: Trains,
Gate, and CompSpec, a trivial specication of the computer system interface. Figure 2 illustrates
AxSpec.
Next, because it is easier to use in proving correctness, we produce a secondary, more opera-
tional requirements specication in the form of a timed automaton OpSpec. We show that OpSpec
implements AxSpec.
Next, we describe our computer system implementation as a timed automaton, CompImpl. Cor-
rectness means that CompImpl, when it interacts with Trains and Gate, guarantees the Safety and
Utility Properties. To show this, we prove that SystImpl, the composition of CompImpl, Trains and
Gate, provides the same view to the environment components, Trains and Gates, as the operational
specication OpSpec. This part of the proof follows well-established, stylized invariant and simu-
lation mapping methods, which is why we moved from the axiomatic style of specication to the
operational style. All of these proofs can be veried using current mechanical proof technology.
In both specication automata, AxSpec and OpSpec, and also in the implementation automaton
SystImpl, time information is built into the state. Timing information consists of the current time
plus some deadline information, such as the earliest and latest times that a train that has entered R
will actually enter the crossing. The correctness proof proceeds by rst proving by induction some
invariants about the reachable states of SystImpl. The main work in the proof of the Safety Property
is done by means of these invariants. An interesting feature of the proofs is that the invariants
involve time deadline information.
Next, we show a \simulation mapping" between the states of SystImpl and OpSpec, again by
induction; this is enough to prove the Utility Property. Appendix C contains formal denitions
for simulation mappings and the correctness properties they guarantee. Like the invariants, the
simulations involve time deadline information, in particular, they include inequalities between time
deadlines.
Finally, we observe that our main proofs yield a weaker result that what we really want. Namely,
we have worked with an abstract, discrete model of the trains and gate rather than with a realistic
model that allows continuous behavior. And we have only shown that the \admissible timed traces",
i.e., the sequences of externally visible actions, together with their times of occurrence, are preserved,
rather than all aspects of the environment's behavior. We conclude by showing that we have not lost
any generality by proving the weaker results. In particular, preservation of admissible timed traces

AxSpec
rI(r)
ente
R(r)
enter raise Safety
Trains ex Gate
it(r) CompSpec lowe
r Utility

Figure 2: AxSpec is the composition of Trains, Gate, and CompSpec, constrained by the Safety and
Utility properties.

6
actually implies preservation of all aspects of the environment's behavior. Further, the results extend
to SystImpl 0, a system implementation with a more realistic environment model. Both extensions are
obtained as corollaries of the results for admissible timed traces of the discrete model, using general
results about composition of timed automata.

3 Axiomatic Specication

We begin with a high level axiomatic specication, AxSpec, describing the problem in terms most
easily understood by application experts. We express the axioms solely in terms of the environment.
We rst dene two timed automata, Trains and Gate, which are abstract representations of the
trains and gate, respectively. These two components do not interact directly. We then dene a
trivial automaton CompSpec, which interacts with both Trains and Gate via actions representing
sensors and actuators. CompSpec describes nothing more than the interface that the computer
system must have with the environment. AxSpec is obtained by composing these three automata
and then imposing the Safety and Utility Properties on the composition; see Figure 2. Formally, the
two properties are restrictions on the executions of the composition. The Safety Property is just a
restriction on the states that occur in the execution, while the Utility Property is a more complex
temporal condition.
3.1 Parameters and Other Notation
We use the notation r, r0 , etc. to denote (railroad) trains. We use I to denote the railroad crossing,
R to denote the region from where a train passes a sensor until it exits the crossing, and P to denote
the portion of R prior to the crossing. We dene some positive real-valued constants:
 1, a lower bound on the time from when a train enters R until it reaches I .
 2, an upper bound on the time from when a train enters R until it reaches I .
 , the minimum useful time for the gate to be up. (For example, this might represent the minimum time for a
car to pass through the crossing safely.)
 down, an upper bound on the time to lower the gate completely.
 up, an upper bound on the time to raise the gate completely.
 1 , an upper bound on the time from the start of lowering the gate until some train is in I .
 2 , an upper bound on the time from when the last train leaves I until the gate is up (unless the raising is
interrupted by another train getting \close" to I ).
  , an arbitrarily small constant used to take care of some technical race conditions.1
We need some restrictions on the values of the various constants:
1. 1  2 .
2. 1 > down. (The time from when a train arrives until it reaches the crossing is suciently large to allow the
gate to be lowered.)
3. 1  down +  + 2 , 1 . (The time allowed between the start of lowering the gate and some train reaching I
is sucient to allow the gate to be lowered in time for the fastest train, and then to accommodate the slowest
train. The time down is needed to lower the gate in time for the fastest train, but the slowest train could take
an additional time 2 , 1. The  is a technicality.)
4. 2  up. (The time allowed for raising the gate is sucient.)
1 These arise because the model allows more than one event to happen at the same real time.

7
3.2 Trains
We model the Trains component as an MMT automaton with no input or internal actions, and three
types of outputs, enterR(r), enterI(r), and exit(r), for each train r.
Actions:
Input:
none
Output:
enterR(r), r a train
enterI(r), r a train
exit(r), r a train
Internal:

The state consists of a status component for each train, just saying where it is.
State:
for each train r:
r:status 2 fnot-here; P; I g, initially not-here
The state transitions are described by specifying the \preconditions" under which each action
can occur and the \eect" of each action. We use s to denote the state before the event occurs
and s0 the state afterwards. We use the convention that if a state component is not mentioned, it
is unchanged (although sometimes, to resolve ambiguities or for emphasis, we say explicitly that a
component is unchanged).
Transitions:
enterR(r) exit(r)
Precondition: Precondition:
s:r:status = not-here s:r:status = I
Eect: Eect:
s0 :r:status = P s0 :r:status = not-here
enterI(r)
Precondition:
s:r:status = P
Eect:
s0 :r:status = I
In this automaton (and for all the other MMT automata in this paper), we make each non-input
action a task by itself. We only specify trivial bounds (that is, [0; 1]) for the enterR(r) and exit(r)
actions. For each enterI(r) action, we use bounds [1; 2 ]. This means that from the time when any
train r has reached R, it is at least time 1 and at most time 2 until the train reaches I .
We use the general construction described in Appendix B to convert this automaton to a timed
automaton. This construction involves adding some components to the state { a current time com-
ponent now, and rst and last components for each task, giving the earliest and latest times at which
an action of each task can occur, once the task is enabled. The transition relation is augmented with
conditions to enforce the bound assumptions, that is, that an event cannot happen before its rst
time, and that time cannot pass beyond any last time. In this case, only the state components now,
and rst(enterI(r)) and last(enterI(r)) for each r contain nontrivial information, so we ignore the

8
other cases. Applying this construction yields the timed automaton with the same actions and the
following states and transitions. (In this automaton description, as well as elsewhere in the paper,
we sometimes omit mention of the state where there is no ambiguity.)
State:
now, a nonnegative real, initially 0
for each train r:
r:status 2 fnot-here; P; I g, initially not-here
rst(enterI(r)), a nonnegative real, initially 0
last(enterI(r)), a nonnegative real or 1, initially 1.
Transitions:
enterR(r) exit(r)
Precondition: Precondition:
s:r:status = not-here s:r:status = I
Eect: Eect:
s0 :r:status = P s0 :r:status = not-here
s0 :rst(enterI(r)) = now + 1
s0 :last(enterI(r)) = now + 2  (
t)
Precondition:
enterI(r) for all r, s:now +
t  s:last(enterI(r))
Precondition: Eect:
s:r:status = P s0 :now = s:now +
t
now  s:rst(enterI(r))
Eect:
s0 :r:status = I
s0 :rst(enterI(r)) = 0
s0 :last(enterI(r)) = 1
Lemma 3.1 In any reachable state of Trains:
For any r such that r:status = P , rst(enterI(r)) + 2 , 1 = last(enterI(r)).
Proof: By induction on the length, i.e., the total number of non-time-passage and time-passage
steps, of an execution. Because 2 , 1 is a constant, we need only consider actions that change
rst(enterI(r)), last(enterI(r)) or make r:status = P , namely, enterR(r) and enterI(r). The actions
exit(r) and  (
t) do not aect the statement.
After 0 steps, the claim is vacuously satised. Assume the claim is true after m steps. We must
prove it is true after m + 1 steps. For enterI(r), the claim is vacuously satised. For enterR(r), the
eect is s0 :r:status = P . Then, s0 :rst(enterI(r)) = now + 1 and s0 :last(enterI(r)) = now + 2 , which
implies that s0 :rst(enterI(r)) + 2 , 1 = s0 :last(enterI(r)) as required.
3.3 Gate
We model the gate as another MMT automaton, this one with inputs lower and raise and outputs
down and up.
Actions:
Input:
lower
raise
Output:

9
 down
up
Internal:

The state consists of a single status component:

State:
status 2 fup; down; going-up; going-downg, initially up
Transitions:
lower down
Eect: Precondition:
if s:status 2 fup; going-upg then s:status = going-down
s0 :status = going-down Eect:
else unchanged status s0 :status = down
raise up
Eect: Precondition:
if s:status 2 fdown; going-downg then s:status = going-up
s0 :status = going-up Eect:
else unchanged status s0 :status = up
The time bounds are down: [0; down], and up: [0; up], where up and down are upper bounds
on the time required for the gate to be raised and lowered. To build time into the state, the state
components now, last(up), and last(down) are added to produce the following states and transitions.
State:
status 2 fup; down; going-up; going-downg, initially up
now, a nonnegative real, initially 0
last(down), a nonnegative real or 1, initially 1
last(up), a nonnegative real or 1, initially 1
Transitions:
lower down
Eect: Precondition:
if s:status 2 fup; going-upg then s:status = going-down
s0 :status = going-down Eect:
s0 :last(down) = now + down s0 :status = down
s0 :last(up) = 1 s0 :last(down) = 1
else unchanged status, last(down), last(up)
up
raise Precondition:
Eect: s:status = going-up
if s:status 2 fdown; going-downg then Eect:
s0 :status = going-up s0 :status = up
s0 :last(up) = now + up s0 :last(up) = 1
s0 :last(down) = 1
else unchanged status, last(down), last(up)  (
t)
Precondition:
s:now +
t  s:last(up)
s:now +
t  s:last(down)
Eect:
s0 :now = s:now +
t

10
3.4 CompSpec
We model the computer system interface as a trivial MMT automaton CompSpec with inputs
enterR(r) and exit(r) for each train r, and outputs lower and raise.
Actions:
Input:
enterR(r), r a train
exit(r), r a train
Output:
lower
raise
Internal:

CompSpec receives sensor information when a train arrives in the region R and when it leaves
the crossing I . Note that CompSpec does not have an input action enterI(r); this expresses the
assumption that there is no sensor that informs the system when a train actually enters the crossing.
CompSpec has just a single state. Inputs and outputs are always enabled, and cause no state change.
There are no timing requirements.
Transitions:
enterR(r) lower
Eect: Precondition:
none true
Eect:
exit(r) none
Eect:
none raise
Precondition:
true
Eect:
none

3.5 AxSpec
To get the full specication, we compose the three MMT automata given above, Trains, Gate and
CompSpec, yielding a new MMT automaton. But this is not enough: we then add constraints to
express the correctness properties in which we are interested. Formally, these constraints are axioms
about an admissible timed execution  of the composition automaton:
1. Safety Property
All the states in  satisfy the following condition:
If Trains:r:status = I for any r, then Gate:status = down.
2. Utility Property
If s is a state in  with s:Gate:status 6= up, then at least one of the following conditions holds.
(a) There exists s0 preceding (or equal to) s in  with s0 :Trains:r:status = I for some r and s0 :now  s:now , 2 .
(b) There exists s0 following (or equal to) s in  with s0 :Trains:r:status = I for some r and s0 :now  s:now + 1 .
(c) There exist two states s0 and s00 in , with s0 preceding or equal to s, s00 following or equal to s,
s0 :Trains:r:status = I for some r, s00 :Trains:r:status = I for some r, and s00 :now , s0 :now  1 + 2 + .

11
 The Safety and Utility properties are stated independently. The Safety Property is an assertion
about all the states reached in , saying that they all satisfy the critical safety property. In contrast,
the Utility Property is a temporal property with a somewhat more complicated structure, which says
that if the gate is not up, then either there is a recent preceding state or an imminent following state
in which a train is in I . The third condition takes care of the special case where there is both a
recent state and an imminent state in which some train is in I ; although these states are not quite
as recent or imminent as required by the rst two cases, there is insucient time for a car to pass
through the crossing. In Appendix D, we show that the above statement of the Safety and Utility
Properties is equivalent to a trivial modication of the original problem statement.
3.6 Implementation Requirements
An implementation of AxSpec uses a new timed automaton, called CompImpl, with the same interface
as CompSpec. CompImpl will be composed with the same Trains and Gate automata given above,
yielding a new system SystImpl. The system SystImpl should produce executions that, when projected
on the environment (Trains composed with Gate), yields behavior that is also produced by the system
specication AxSpec. More precisely, for every admissible timed execution  of SystImpl, there
should be a corresponding admissible timed execution 0 of AxSpec such that 0 jTrains  Gate =
jTrains  Gate. That is, the two executions project identically on the Trains and Gate automata.

4 Operational Spec
In contrast to AxSpec, which consists of a timed automaton together with some axioms that describe
restrictions on the automaton's executions, the secondary operational specication, OpSpec, is simply
a timed automaton { all required properties are built into the automaton itself as restrictions on the
state set and on the actions that are permitted to occur. As a result, OpSpec is probably harder for
an application expert to understand than AxSpec. But it is easier to use in proofs (at least for the
style of verication we are using). Thus we regard OpSpec as an intermediate specication rather
than a true problem specication; we only require that OpSpec implement AxSpec, not necessarily
vice versa, and that all implementations of interest satisfy OpSpec.
The two types of specications are also dierent in another respect: while AxSpec preserves the
independence of the Safety and Utility Properties, OpSpec does not. When a collection of separate
properties are specied by an automaton, the properties usually become intertwined.
4.1 The Specication
To obtain OpSpec, we rst compose Trains, Gate, and CompSpec, and then incorporate the Safety
and Utility Properties into the automaton itself. Formally, the modied automaton is obtained
from the composition by restricting it to a subset of the state set, then adding some additional
state components, and nally modifying the denitions of the steps to describe their dependence on
and their eects on the new state components. Although the composition of the three component
automata is an MMT automaton, the modied version is not { it is a timed automaton.
First, to express the Safety Property, we restrict the states to be those states of the composition
that satisfy the following invariant: \If Trains:r:status = I for any r, then Gate:status = down."

12
 Second, the time-bound restrictions expressed by the Utility Property are encoded as restrictions
on the steps. The strategy is similar to that used in Appendix B to encode MMT time bound
restrictions into the steps of a timed automaton { it involves adding explicit deadline components.
We describe the modications in two pieces:
1. The time from when the gate starts going down until some train enters I is bounded by 1. To
express this restriction formally, we add to the state of the composed system a new deadline
last1 , representing the latest time in the future that a train is guaranteed to enter I . Initially,
this is set to 1, meaning that there is no such scheduled requirement. To add this new
component to OpSpec, we include the following new eects in two of the actions:
Transitions:
lower enterI(r)
Eect: Eect:
if s:Gate:status 2 fup; going-upg s0 :last1 = 1
and s:last1 = 1 then
s0 :last1 = now + 1
else unchanged last1
There is also a new precondition added: the time-passage action cannot cause time to pass
beyond last1 . This means that whenever the gate starts moving down, some train must enter
I within time 1. The new eect being added to the lower action just \schedules" the arrival
of a train in I .
2. From when the crossing becomes empty, either the time until the gate is up is bounded by 2 or
else the time until a train is in I is bounded by 2 +  + 1 . Again, we express the condition by
adding deadlines, only this time the situation is trickier since there are two alternative bounds
rather than just one. We add two new components, last2 (up) and last2(I ), both initially 1.
The rst represents a milestone to be noted { whether or not the gate reaches the up position
by the designated time { rather than an actual deadline. In contrast, the second represents
a real deadline { a time by which a new train must enter I , unless the gate reached the up
position by the milestone time last2(up). To add these new components to OpSpec, we include
the following additional eects in three of the actions:
Transitions:
exit(r) up
Eect: Eect:
if s:Trains:r0 :status 6= I for all r0 6= r then if now  s:last2 (up) then
s0 :last2 (up) = now + 2 s0 :last2 (up) = 1
s0 :last2 (I ) = now + 2 +  + 1 s0 :last2 (I ) = 1
else else
unchanged last2 (up) unchanged last2 (up)
unchanged last2 (I ) unchanged last2 (I )
enterI(r)
Eect:
s0 :last2 (up) = 1
s0 :last2 (I ) = 1
Also, as with last1 , an implicit precondition is placed on the time-passage action, saying that
time cannot pass beyond last2(I ). But no such limitation is imposed for time passing beyond
last2 (up), because this is just a milestone to be recorded, not a time-blockage.

13
4.2 Properties
We make some simple claims about OpSpec:
Lemma 4.1 In all reachable states of OpSpec:
1. If Trains:r:status = I for any r, then Gate:status = down.
2. last2 (up) +  + 1 = last2 (I ).
Proof: The rst property is by denition of OpSpec. The second property is proved by induction.
We need only consider actions that aect last2(up) and last2(I ), namely, up, enterI(r), and exit(r)
for some r.
For the action up, the only case in which the last2 components are aected is where now 
s:last2 (up). In this case, the eect of up is s0 :last2(up) = s0 :last2 (I ) = 1, and the claim is satised.
The eect of enterI(r) is s0 :last2(up) = s0 :last2 (I ) = 1, and thus the claim is satised. For exit(r), the
only case in which the last2 components are aected is where r's exit leaves I empty. Then the eect
is s0 :last2(up) = now + 2 and s0 :last2(I ) = now + 2 +  + 1 , which implies that s0 :last2(up)+  + 1 =
s0:last2 (I ), as needed.
Lemma 4.2 In all reachable states of OpSpec:
1. now  last1.
2. now  last2(I ).
3. If last1 =6 1 then last1  now + 1.
6 1 then last2(I )  now + 2 +  + 1.
4. If last2 (I ) =
5. If last2 (up) =6 1 then last2(up)  now + 2.
Proof: By induction. Note that the only actions that can aect the truth of 1 or 3 are time passage,
lower and enterI actions, and only time passage and lower actions could falsify 1 or 3. Also, the only
actions that can aect the truth of 2, 4, or 5 are time passage, exit, up and enterI actions, and only
time passage actions and exit actions that leave I empty could falsify 2, 4 or 5.
1. The precondition for time passage prevents s0 :now from exceeding s:last1 = s0 :last1 . The eect
of lower is s0 :last1 = now + 1 . By denition of the constants, 1 > 0, which implies that
s0:last1  now.
2. The precondition for time passage prevents s0 :now from exceeding s:last2 (I ) = s0 :last2 (I ). If
r's exit leaves I empty, then an eect of exit(r) is s0 :last2(I ) = now + 2 +  + 1. By denition
of the constants, 2 +  + 1 > 0, which implies that s0 :last2(I )  now.
3. If lower causes a change, then its eect is s0 :last1 = now + 1, which implies s0 :last1  now + 1
as needed. For the time passage action, suppose that s0 :last1 6= 1. Since s:last1 = s0 :last1 , we
have s:last1 6= 1. Then by inductive hypothesis, s:last1  s:now + 1 . But s:now < s0 :now, so
s:now + 1 < s0:now + 1. Therefore, s0:last1  s0 :now + 1 as needed.

14
 4. Time passage causes time to increase, so it cannot cause the claim to be violated. For an exit(r)
action that leaves I empty, an eect is s0 :last2 (I ) = now + 2 +  + 1 , which suces.
5. Similar to 4.

4.3 Relationship Between OpSpec and AxSpec

We show that OpSpec implements AxSpec in the following sense:
Lemma 4.3 For any admissible timed execution  of OpSpec, there is an admissible timed execution
0 of AxSpec such that 0jTrainsGate = jTrainsGate. (This is the same as saying that  satises
the two properties given explicitly for AxSpec.)
We leave the proof of Lemma 4.3 to Appendix E.
Note that the relationship between OpSpec and AxSpec is only one-way: there are admissible
timed executions of AxSpec that have no executions of OpSpec yielding the same projection. Consider,
for example, the following example. Suppose that after I becomes empty, the system does a very
rapid raise, lower, raise. These could conceivably all happen within time 2 after the previous time
there was a train in I , which would make this \waing" behavior legal according to AxSpec. However,
when this lower occurs, there is no following entry of a train into I , which means that this does not
satisfy OpSpec.
4.4 Proof Strategy
The relationship between OpSpec and AxSpec immediately suggests a strategy for showing that
an implementation SystImpl, based on a particular computer system implementation CompImpl,
satises AxSpec. The strategy is to show that every admissible timed execution of SystImpl has a
corresponding admissible timed execution of OpSpec that projects identically on the Trains and Gate
automata. Then use Lemma 4.3.

5 Implementation
To describe our implementation SystImpl, we use the same Trains and Gate automata but replace the
CompSpec component in OpSpec and AxSpec with a new component CompImpl, a computer system
implementation.
5.1 CompImpl
CompImpl is not an MMT automaton but a timed automaton with the same interface as CompSpec.
It keeps track of the trains in R, together with the earliest possible time that each might enter I .
(This time could be in the past.) It also keeps track of the latest operation that it has performed on
the gate and the current time.

15
State:
for each train r:
r:status 2 fnot-here; Rg, initially not-here
r:sched-time, a nonnegative real number or 1, initially 1
gate-status 2 fup; downg, initially up
now, initially 0
Transitions:
enterR(r) raise
Eect: Precondition:
s0 :r:status = R s:gate-status = down
s0 :r:sched-time = now + 1 6 9r : s:r:sched-time  now + up +  + down
Eect:
exit(r) s0 :gate-status = up
Eect:
s0 :r:status = not-here  (
t)
s0 :r:sched-time = 1 Precondition:
t = s:now +
t
lower if s:gate-status = up then
Precondition: t < s:r:sched-time , down for all r
s:gate-status = up if s:gate-status = down then
9r : s:r:sched-time  now + down +  9r : s:r:sched-time  s:now + up +  + down
Eect: Eect:
s0 :gate-status = down s0 :now = t
Observe that the fact that CompImpl:gate-status = up does not mean that Gate:status = up but
just that Gate:status 2 fup; going-upg. A similar remark holds for CompImpl:gate-status = down.
Note that r:sched-time keeps track of the earliest time that train r might enter I . The system
lowers the gate if the gate is currently up (or going up) and some train might soon arrive in I . Here
\soon" means by the time the computer system can lower the gate plus a little bit more { this is
where we consider the technical race condition mentioned earlier. The system raises the gate if the
gate is currently down (or going down) and no train can soon arrive in I . This time, \soon" means
by the time the gate can be raised plus the time for a car to pass through the crossing plus the time
for the system to lower the gate. The system allows time to pass subject to two conditions. First, if
gate-status = up, then real time is not allowed to reach a time at which it is necessary to lower the
gate. Second, if gate-status = down and the gate should be raised, then time cannot increase at all
(until the gate is raised).
5.2 The Full System Implementation, SystImpl
The full system implementation, SystImpl, is just the composition of the Trains, Gate and CompImpl
components.
Here, we give some useful basic invariants about SystImpl; the next two lemmas say that
CompImpl has accurate information about the trains and gate, respectively.
Lemma 5.1 The following are true in any reachable state of SystImpl:
1. CompImpl:r:status = R i Trains:r:status 2 fP; I g.
2. If Trains:r:status = P , then CompImpl:r:sched-time = Trains:rst(enterI(r)).

16
 3. If CompImpl:r:status = R and CompImpl:r:sched-time > now, then Trains:r:status = P .
4. If Trains:r:status = I , then CompImpl:r:sched-time  now.
5. If CompImpl:r:sched-time 6= 1, then Trains:r:status 2 fP; I g.
Proof: By induction.
1. The only actions that can cause a violation are actions that change the truth values of ei-
ther CompImpl:r:status = R or Trains:r:status 2 fP; I g, namely, enterR(r) and exit(r). But,
enterR(r) makes both sides of the equivalence true, and exit(r) makes both sides false. Hence,
the property is true.
2. The only actions that can cause a violation are actions that make Trains:r:status = P , or
else change CompImpl:r:sched-time or Trains:rst(enterI(r)), namely, enterR(r), exit(r), and
enterI(r). But exit(r) and enterI(r) cause Trains:r:status 6= P , so the claim is vacuously
satised. Further, the eect of enterR(r) ensures that s0 :Trains:rst(enterI(r)) = now + 1 , and
s0 :CompImpl:r:sched-time = now + 1 . Hence, s0 :Trains:rst(enterI(r)) =
s0 CompImpl:r:sched-time, as required.
3. The only actions that can cause a violation are those that can make CompImpl:r:status = R,
increase CompImpl:r:sched-time, or make Trains:r:status 6= P , namely, enterR(r), exit(r), and
enterI(r). The eect of exit(r) is CompImpl:r:status 6= R, and thus the claim is vacuously
satised. The eect of enterR(r) is Trains:r:status = P , and thus the claim is satised.
Now consider enterI(r). By the precondition of enterI(r), s:Trains:r:status = P and now 
s:Trains:rst(enterI(r)). Part 2 of this lemma implies that now  s:CompImpl:r:sched-time.
Since s:CompImpl:r:sched-time = s0 :CompImpl:r:sched-time, we have
now  s0 :CompImpl:r:sched-time, and the claim is vacuously satised.
4. Suppose s0 :Trains:r:status = I . Then Part 1 implies that s0 :CompImpl:r:status = R. If
s0:CompImpl:r:sched-time > s0:now, then Part 3 implies that s0 :Trains:r:status = P , a con-
tradiction. So, s0 :CompImpl:r:sched-time  s0 :now as needed.
5. The only action that could cause a violation, enterR(r), sets s0 :CompImpl:r:sched-time 6= 1.
In this case, we have s0 :CompImpl:r:status = R. Then Part 1 implies s0:Trains:r:status 2 fP; I g
as needed.

Lemma 5.2 The following are true in any reachable state of SystImpl:
1. CompImpl:gate-status = up if and only if Gate:status 2 fup; going-upg.
2. CompImpl:gate-status = down if and only if Gate:status 2 fdown; going-downg.
Proof: By induction.

17
 1. We need only consider actions that change the truth values of CompImpl:gate-status = up and
Gate:status 2 fup; going-upg, namely, lower and raise. For a lower action,
s0:CompImpl:gate-status = down and s0 :Gate:status 2 fdown; going-downg, which suces. For
a raise action, s0 :CompImpl:gate-status = up and s0 :Gate:status 2 fup; going-upg, which again
suces.
2. Follows from Part 1.

6 Correctness Proof
The main correctness proof shows that every admissible execution of SystImpl projects on the external
world like some admissible execution of OpSpec.
We rst prove a collection of invariants, leading to a proof of the safety property. All of the
invariants are proved by induction on the length of an execution. Then we give a simulation mapping
to show the Utility Property. Technically speaking, the simulation mapping only preserves timed
traces, not the complete view of the environment components. However, standard composition
techniques for timed automata show that the view is also preserved.
6.1 Invariants
In this section, we prove the main safety invariant, namely: \If Trains:r:status = I for any r, then
Gate:status = down." We do this with the help of two preliminary invariants. The rst invariant
says that if a train is in the region and the gate is either up or going up, then the train must still be
far from the crossing.
Lemma 6.1 In all the reachable states of SystImpl, if Trains:r:status = P and
Gate:status 2 fup; going-upg, then Trains:rst(enterI(r)) > now + down.
Proof: By induction. Fix any particular train r. We need only consider actions that cause
Trains:r:status to become equal to P , cause Gate:status to change to be in fup; going-upg, decrease
Trains:rst(enterI(r)), or increase now, namely enterR(r), raise, and  .
1. enterR(r)
An eect is s0 :Trains:rst(enterI(r)) = now + 1 . Since 1 > down by an assumption on the
constants, we have s0 :Trains:rst(enterI(r)) > now + down , as needed.
2. raise
Assume that s0 :Trains:r:status = P . The precondition implies that s:CompImpl:r:sched-time >
now + up +  + down , so that s:CompImpl:r:sched-time > now + down and therefore
s0:CompImpl:r:sched-time > now + down . By Lemma 5.1, Part 2, s0 :CompImpl:r:sched-time =
s0:Trains:rst(enterI(r)). So s0 :Trains:rst(enterI(r)) > now + down, as needed.

18
 3.  (
t)
Assume s0 :Trains:r:status = P and s0 :Gate:status 2 fup; going-upg. Then, Lemma 5.2 implies
that s0 :CompImpl:gate-status = up, and the precondition for time passage implies that
s0 :now < s:CompImpl:r:sched-time , down . By Lemma 5.1, Part 2,
s:CompImpl:r:sched-time = s:Trains:rst(enterI(r)). So, s:Trains:rst(enterI(r)) > s0 :now +
down, which implies s0:Trains:rst(enterI(r)) > s0 :now + down , as needed.

The second invariant says that if a train is nearing I and the gate is going down, then the gate is
nearing the down position. In particular, the earliest time at which the train might enter I is strictly
after the latest time at which the gate will be down.
Lemma 6.2 In all reachable states of SystImpl, if Trains:r:status = P and
Gate:status = going-down, then Trains:rst(enterI(r)) > Gate:last(down).
Proof: Another inductive argument. Fix any particular train r. We need only consider actions that
make Trains:r:status = P or Gate:status = going-down, decrease Trains:rst(enterI(r)) or increase
Gate:last(down), namely, enterR(r), lower, enterI(r), raise and down.
1. enterI(r), raise, or down.
In each case, the claim is vacuously satised.
2. enterR(r)
Assume s0 :Trains:r:status = P and s0 :Gate:status = going-down. Then, Part 2 of Lemma B.1
implies that s0 :Gate:last(down)  now + down . The eect of enterR(r) is
s0:Trains:rst(enterI(r)) = now + 1 . By an assumption about the constants, 1 > down, and
so now + 1 > now + down . So s0 :Trains:rst(enterI(r)) > s0 :Gate:last(down) as needed.
3. lower
Suppose s0 :Trains:r:status = P . We only need to consider the case where s:Gate:status 2
fup; going-upg, since otherwise the lower doesn't change anything. By Lemma 6.1, this implies
that s:Trains:rst(enterI(r)) > now + down , which implies that s0 :Trains:rst(enterI(r)) >
now + down . Since now + down = s0:Gate:last(down), the needed inequality follows.

These invariants yield the main safety result:

Lemma 6.3 In all reachable states of SystImpl, if Trains:r:status = I for any r, then Gate:status =
down.
Proof: By induction again. This time, the interesting cases are enterI and raise. Fix r.

19
 1. enterI(r)
By the precondition, s:Trains:r:status = P .
If s:Gate:status 2 fup; going-upg, then Lemma 6.1 implies that s:Trains:rst(enterI(r)) > now+
down, so s:Trains:rst(enterI(r)) > now. But, the precondition for enterI(r) is
s:Trains:rst(enterI(r))  now. This means that it is impossible for this action to occur, a
contradiction.
If s:Gate:status = going-down, then Lemma 6.2 implies that
s:Trains:rst(enterI(r)) > s:Gate:last(down). By Lemma B.1, s:Gate:status = going-down
implies s:Gate:last(down)  now. This implies that s:Trains:rst(enterI(r)) > now, which
again means that it is impossible for this action to occur.
The only remaining case is s:Gate:status = down. This implies s0 :Gate:status = down, which
suces.
2. raise
We need to show that the gate doesn't get raised when a train is in I . So suppose that
s:Trains:r:status = I . The precondition of raise states that 6 9r: s:CompImpl:r:sched-time 
now + up +  + down , which implies that, for all r, s:CompImpl:r:sched-time > now. But
Parts 1 and 3 of Lemma 5.1 imply that in this case, s:Trains:r:status = P , a contradiction.

6.2 Simulation Mapping

Now, in order to show the Utility Property, we present the simulation mapping from SystImpl to
OpSpec. Specically, if s and u are states of SystImpl and OpSpec, respectively, then we dene s and
u to be related by relation f provided that:
1. u:now = s:now.
2. u:Trains = s:Trains.2
3. u:Gate = s:Gate.
4. u:last1  minfs:Trains:last(enterI(r))g.
5. Either u:last2 (I )  minfs:Trains:last(enterI (r))g, or
u:last2(up)  now + up and the raise precondition holds in s, or
u:last2(up)  s:Gate:last(up) and s:Gate:status = going-up.
The rst three parts of the denition are self-explanatory. The last two parts provide connections
between the time deadlines in the specication and implementation. In the typical style for this
approach, the connections are expressed as inequalities. The fourth condition bounds the latest time
for some train to enter I , a bound mentioned in the specication, in terms of the actual time it could
take in the implementation, namely, the minimum of the latest times for all the trains in P . The
fth condition is slightly more complicated { it bounds the time for either some train to enter I or
2 By this we mean that the entire state of the Trains automaton, including the time components, is preserved.

20
the gate to reach the up position. There are two cases for the gate reaching the up position { one in
which the gate has not yet begun to rise and the other in which it has.
Theorem 6.4 f is a simulation mapping from SystImpl to OpSpec.
Proof: We must show the three conditions in the denition of a simulation mapping. The three
conditions are dened in Appendix C. The rst condition, preservation of the now value, is immediate
from the denition of f . The second condition is also immediate, because the unique start states of
the two automata satisfy all the relationships in the denition of f . The interesting condition is the
step condition.
Suppose that s ,! 0 0 the invariants of SystImpl, and u 2 f [s] satises
SystImpl s , s and s satisfy
the invariants of OpSpec. We must produce u0 2 f [s0 ] such that there is a timed execution fragment
from u to u0 having the same timed visible actions as the given step. We do this using a case analysis
on  .
For each non-time-passage action  , we rst argue that  is enabled in u and then dene u0 to be
the unique state that results from applying the indicated action from state u. For the time-passage
action, we rst argue that the same amount of time can pass from u, and then dene u0 to be the
unique state that results from allowing that amount of time to pass.
Then in each case, we must check that u0 2 f [s0 ]; in each case, Conditions 1-3 are easy to check,
so we need only consider Conditions 4 and 5. Condition 4 is also easy for all cases except the lower
action, since that is the only action that can decrease last1 . (The only action that can raise the
minimum on the right-hand side of the inequality is enterI, but that sets last1 to 1.) So we omit
mention of Condition 4 in all other cases.
1.  = enterR(r).
Enabling: Since  is enabled in s, we have s:Trains:r:status = not-here. Since u 2 f [s], we have
u:Trains:r:status = not-here. This implies that  is enabled in u.
Condition 5: The only alternative that might be falsied by  is the second, and only if
enterR(r) falsies the raise precondition. So suppose that u:last2(up)  now + up and
the raise precondition holds in s but gets falsied in s0 . Then, there exists r such that
s0 :CompImpl:r:sched-time  now + up +  + down . Since an eect of the action is
s0 :CompImpl:r:sched-time = now + 1 , we have 1  up +  + down .
It suces to show that u0 :last2(I )  s0 :Trains:last(enterI(r)), since that would show that the
action makes the rst alternative of Condition 5 true. We have that u0:last2(I ) = u:last2 (I )
and s0 :Trains:last(enterI(r)) = now + 2 . So it suces to show that u:last2(I )  now + 2 .
Since u:last2 (up)  now+ up , and u:last2 (I ) = u:last2 (up)+ +1 (this by Part 2 of Lemma 4.1),
it is enough to show that now + up +  + 1  now + 2 , or, more simply, that up +  + 1  2 .
But up +   1 , down as noted above. And we have that 1  down + 2 , 1 , by an
assumption about the constants. So, up +  + 1  2 as needed.
2.  = enterI(r).
Enabling: Similar to enterR(r).
Condition 5:  makes last2 (I ) = 1 and last2(up) = 1, which make the condition trivially
true.
21
3.  = exit(r).
Enabling: Similar to enterR(r).
Condition 5:
There are three cases, based on which of the three alternatives becomes falsied.
(a) The rst alternative is falsied.
Then, it must be that  decreases u:last2(I ), and that no train is in I after the step.
We have that u0 :last2 (I ) = now + 2 +  + 1 and u0 :last2 (up) = now + 2 . If the precondition
for raise holds after the step, then it suces to show that u0 :last2 (up)  now + up . That
is, it suces to show that 2  up . But this follows from an assumption about the
constants.
Suppose that the precondition for raise does not hold after the step. Then there is some
r0 such that s0:CompImpl:r0:sched-time  now + up +  + down . (The rst precondition
of raise, gate-status = down, cannot fail after the step because of Lemma 6.3 applied
to s.) The fact that s0 :CompImpl:r0:sched-time 6= 1 and Part 5 of Lemma 7.1 together
imply that s0 :Trains:r0:status 2 fP; I g. However, by assumption, no trains are in I after
the step, so it must be that s0 :Trains:r0:status = P . Then Lemma 5.1, Part 2, implies
that s0 :Trains:rst(enterI(r0))  now + up +  + down , and then Lemma 3.1 implies
that s:Trains:last(enterI(r0))  now + up +  + down + 2 , 1 . It suces to show that
u0:last2(I )  s0:Trains:last(enterI(r0)). To show this, it suces to show that now + 2 +  +
1  now+ up ++ down +2 ,1 , or, more simply, that 2 +1  up + down +2 ,1 . But
this follows from the inequalities 2  up and 1  down +  + 2 , 1 > down + 2 , 1 .
(b) The second alternative is falsied.
Then the raise precondition must be true in s. By the precondition, s:Trains:r:status = I .
Then Lemma 5.1, Part 4, implies that s:CompImpl:r:sched-time  now. But this violates
the raise precondition in s, which is a contradiction.
(c) The third alternative is falsied.
Then s:Gate:status = going-up. By the precondition, we have s:Trains:r:status = I , so by
Lemma 6.3, we have that s:Gate:status = down, a contradiction.
4.  = raise.
Enabling: Clearly  is enabled in u, because OpSpec imposes no preconditions on its perfor-
mance.
Condition 5: The only alternative that can be falsied is the second. Suppose that
u:last2(up)  now + up . We have u0 :last2(up) = u:last2 (up), so u0 :last2(up)  now + up . But,
s0 :Gate:last(up) = now + up and s0 :Gate:status = going-up, which yields the third alternative.
5.  = lower.
Enabling: As for raise.
The precondition for lower in SystImpl implies that s:CompImpl:gate-status = up and that there
is a particular r such that s:CompImpl:r:sched-time  now + down +  . Then Lemma 5.2
implies that s:Gate:status 2 fup; going-upg. If s:Trains:r:status = I , then Lemma 6.3 is violated
22
 in s. Because s:CompImpl:r:sched-time 6= 1, it cannot be that s:Trains:r:status = not-here.
So it must be that s:Trains:r:status = P .
Then Lemma 5.1, Part 2, implies that s:CompImpl:r:sched-time = s:Trains:rst(enterI(r)), and
Lemma 3.1 implies that s:CompImpl:r:sched-time + 2 , 1 = s:Trains:last(enterI(r)). Thus, we
have s:Trains:last(enterI(r)) = s:CompImpl:r:sched-time + 2 , 1 ,  now + down +  + 2 , 1 ,
 now + 1 by an assumption about the constants. That is, now + 1  s:Trains:last(enterI(r)).
Condition 4: By denition of lower in OpSpec, u0 :last1 = now + 1. But as we showed above,
this is at least as great as s:Trains:last(enterI(r)) = s0 :Trains:last(enterI(r)). That is, u0:last1 
s0:Trains:last(enterI(r)), as needed.
Condition 5: The only alternative that  can falsify is the third. So suppose that u:last2 (up) 
s:Gate:last(up) and s:Gate:status = going-up. Lemma B.1 implies that s:Gate:last(up)  now,
so u:last2(up)  now. Since u:last2(up) = u0:last2(up), we have u0:last2 (up)  now.
Then Lemma 4.1 implies that u0:last2 (I ) = u0:last2(up) + 1 +  , which is in turn  now + 1.
Since now + 1  s:Trains:last(enterI(r)), we have u0 :last2 (I )  s:Trains:last(enterI(r)), so
u0:last2(I )  s0:Trains:last(enterI(r)). This suces for alternative 1.
6.  = up.
Enabling: Similar to enterR.
Condition 5: Because  doesn't decrease any of the left sides of the inequalities. it cannot
falsify alternative 1. Alternative 2 can't hold before the step, because the raise precondition
and the up precondition are exclusive. Suppose that  falsies alternative 3. Then u:last2 (up) 
s:Gate:last(up) and s:Gate:status = going-up. Lemma B.1 implies that s:Gate:last(up)  now,
so u:last2 (up)  now. But then the eect of the action implies that u0 :last2(I ) = 1, which
suces to satisfy alternative 1.
7.  = down.
Enabling: Similar to enterR.
Condition 5: Straightforward.
8.  =  (
t).
Enabling: We must show that time
t is allowed to pass in OpSpec. This amounts to showing
that s0 :now  u:last1 and s0 :now  u:last2 (I ).
To show s0 :now  u:last1 , we only need to consider the case where u:last1 6= 1. In this case,
Condition 4 implies that u:last1  s:Trains:last(enterI(r)) for some r. The precondition on
time-passage in CompImpl implies that
s0 :now  s:Trains:last(enterI(r)). So s0 :now  u:last1 , as needed.
To show that s0 :now  u:last2 (I ), we only need to consider the case where u:last2(I ) 6= 1. In
this case, we consider the three alternatives, for s and u. If the rst alternative holds, then the
argument is as for last1 . If the second alternative holds, then the raise precondition holds in s.
But this implies that  cannot be enabled in s, a contradiction. If the third alternative holds,
then s0 :now  s:Gate:last(up)  u:last2(up)  u:last2 (I ), which suces.

23
 Condition 5: The only alternative that the time-passage action might falsify is the second. But
this means that the raise precondition holds in s, which is impossible since then  could not
be enabled in s.

6.3 Putting the Pieces Together

Theorem 6.4 and Theorem C.1 together imply that all admissible timed traces of SystImpl are
admissible timed traces of OpSpec. This is not quite what we need. However, we can obtain the
needed correspondence between SystImpl and OpSpec as a corollary, using general results about
composition of timed automata:
Corollary 6.5 For any admissible timed execution  of SystImpl, there is an admissible timed exe-
cution 0 of OpSpec such that 0jTrains  Gate = jTrains  Gate.
Putting this together with Lemma 4.3, we obtain the main theorem:
Theorem 6.6 For any admissible timed execution  of SystImpl, there is an admissible timed exe-
cution 0 of AxSpec such that 0 jTrains  Gate = jTrains  Gate.

7 Realistic Models of the Real World

The models used above for the trains and gate are rather abstract. An applications expert might
prefer more realistic models, giving, for instance, exact or approximate positions for the trains and
gate. However, a formal methods expert would probably not want to include such details, because
they would complicate the proofs. Fortunately, we can satisfy everyone.
It is possible to dene a pair of models for any real world component, one abstract and one
more realistic. The only constraint is that the realistic model should be an \implementation" of
the abstract model, i.e., its set of admissible timed traces should be included in that of the abstract
model. All the dicult proofs are carried out using the abstract models, as above. Then corollaries
are given to extend the results to the realistic models. This extension is based on general results
about composition of timed automata.
For example, we can dene a new type of gate component, Gate0 , similar to the Gate dened
above, but having a more detailed model of gate position. Gate0 is also a timed automaton. Fix
0
any constant down , 0  down
0  down. Dene gd to be a function mapping [0; down
0 ] to [0; 90].
0
Function gd is dened so that gd (0) = 90, gd ( down) = 0, and gd is monotone nonincreasing and
continuous. gd (t) gives the position of the gate after it has been going down for time t. Similarly, x
0 , 0  0  up , and dene gu to be a function mapping [0; 0 ] to [0; 90]. Function
a constant up up up
0 ) = 90, and gu is monotone nondecreasing and continuous.
gu is dened so that gu(0) = 0, gu( up
The actions of Gate0 are the same as for Gate. The state is also the same, with the addition of
one new component pos 2 [0; 90] to represent the gate position, initially 90:
State:
status in fup; down; going-up; going-downg, initially up
pos 2 [0; 90], initially 90
now, a nonnegative real, initially 0
last(down), a nonnegative real or 1, initially 1

24
 last(up), a nonnegative real or 1, initially 1

The transitions are as follows. The lower and raise transitions are the same as for Gate, except
0
that down 0 are used in place of
and up down and up . The up and down transitions contains
new preconditions stating that the correct position has been reached. The time-passage transitions
adjust pos.
Transitions:
lower up
Eect: Precondition:
if s:status 2 fup; going-upg then s:status = going-up
s0 :status = going-down s:pos = 90
s0 :last(down) = now + down
0 Eect:
s :last(up) = 1
0 s0 :status = up
else unchanged status, last(down), last(up) s0 :last(up) = 1
raise  (
t)
Eect: Precondition:
if s:status 2 fdown; going-downg then t = now +
t
s0 :status = going-up t  s:last(down)
s0 :last(up) = now + up
0 t  s:last(up)
s :last(down) = 1
0 Eect:
else unchanged status, last(down), last(up) s0 :now = t
if s:status = going-up then
down s0 :pos =maxfs:pos; gu (t , (s:last(up) , up
0
))g
Precondition: elseif s:status = going-down then
s:status = going-down s0 :pos =minfs:pos; gd (t , (s:last(down) , down
0
))g
s:pos = 0 else unchanged pos
Eect:
s0 :status = down
s0 :last(down) = 1
Thus, unlike the more abstract automata considered so far, Gate0 allows interesting state changes
to occur in conjunction with time-passage actions. Note that Gate0 contains a rather arbitrary
decision about what happens if a lower event occurs when the gate is in an intermediate position.
It says that the gate stays still for the initial time that it would take for the gate to move down to
its current position if it had started from position 0. Alternative modeling choices would also be
possible. A similar remark holds for raise.
One detail needs mentioning: we need to verify that when we apply the functions gu and gd to
arguments in the time-passage transitions, the arguments are in fact within the specied interval. For
example, consider the application gu (t , (s:last(up) , up0 ))g, which occurs when s:status = going-up.
We must be sure that 0  t , (s:last(up) , up )  up . The rst inequality follows from the facts
0 0
that s:last(up)  s:now + up0 and s:now  t, while the second inequality follows from the fact that
t  s:last(up).
We relate the new gate model to the old one. See Appendix A for the notation.
Lemma 7.1 attraces(Gate0)  attraces(Gate).
Proof: By Theorem C.1, it suces to show the existence of a simulation mapping from Gate0 to
Gate. If s and u are states of Gate0 and Gate, respectively, then we dene s and u to be related by
relation f provided that:
25
 1. u:status = s:status.
2. u:now = s:now.
3. u:last(down)  s:last(down).
4. u:last(up)  s:last(up).
It is straightforward to show that f is a simulation mapping.
Now, let SystImpl 0 be the composition of Trains, Gate0 , and CompImpl, and let AxSpec0 be the
composition of Trains, Gate0 , and CompSpec, with Safety and Utility Properties added as in AxSpec.
Using Theorem 6.6 and general results about composition of timed automata, we obtain:
Theorem 7.2 For any0 admissible timed execution0  of SystImpl 0, 0there is an admissible timed
execution  0 of AxSpec such that 0 jTrains  Gate = jTrains  Gate .
Proof: We dene two0environment automata: let E be the composition0 of Gate and Trains, and E 0
the composition of Gate and Trains. Lemma 7.1 says that attraces(Gate )  attraces(Gate). This and
a basic substitutivity property of composition, Lemma A.1, imply that attraces(E 0)  attraces(E ).
Let 0 be any admissible timed execution of SystImpl 0 , and let  = ttrace(0 ).
Lemma A.2 implies that 0 jE 0 2 atexecs(E 0) and 0 jCompImpl 2 atexecs(CompImpl). Since
attraces(E 0)  attraces(E ), we may obtain 2 atexecs(E ) with ttrace( ) = ttrace(0jE 0) =
ttrace(0)jE 0 =  jE 0 =  .
Now we construct an admissible timed execution  of SystImpl. Since  jE = ttrace( ) and
 jCompImpl = ttrace(0jCompImpl), Lemma A.3 implies that there is an admissible timed execution
 of SystImpl such that jE = and jCompImpl = 0 jCompImpl. We have that ttrace() =
ttrace( ) =  .
Next, by Theorem 6.6 applied to , we obtain an admissible timed execution  of AxSpec such
that  jE = jE . It follows that ttrace( ) = ttrace() =  and that  satises the Safety and Utility
properties.
Now we dene an admissible timed execution  0 of the system composed of E 0 and CompSpec.
Since  jE 0 = ttrace(0jE 0) and  jCompSpec = ttrace( jCompSpec), Lemma A.3 implies that there is
an admissible timed execution  0 of the system composed of E 0 and CompSpec such that  0 jE 0 = 0 jE 0
and  0 jCompSpec =  jCompSpec. Note that ttrace( 0 ) =  .
We claim that  0 satises the required properties. First,  0 is dened to be an admissible timed
execution of the system composed of E 0 and CompSpec; to see that it is an admissible timed execution
of AxSpec0 it suces to show that it satises the Safety and Utility properties. But this follows from
the facts that ttrace( 0) =  = ttrace( ) and that  satises the Safety and Utility properties. (These
properties can be inferred from the timed traces.) Second,  0jE 0 = 0jE 0 by construction. This is as
needed.

8 Discussion
We have applied a formal method based on timed automata, invariants, and simulation mappings
to model and verify the Generalized Railroad Crossing example [7]. Here, we extrapolate from this
experience and attempt to evaluate the method for use in modeling and verifying other real-time
systems. We also describe future work.
26
 Generality. Can the method be used to describe all acceptable implementations? It seems
so. For instance, timed automata can have an innite number of states and both discrete and
continuous variables. Further, they can express the maximum allowable nondeterminism, use
symbolic parameters to represent system constants, and represent asynchronous communica-
tion. Thus the method is signicantly more general than approaches based on model-checking,
which typically require a nite number of states and constant timing parameters.
 Readability. Are the formal descriptions easy to understand? The environment model and
the system implementation model are easy to understand, since it is natural to model these as
automata. The requirements specications do not look so natural when expressed as automata;
an axiomatic form seems easier to understand. However, if one starts with an axiomatic
specication, then one has to rewrite the specication as an automaton. It may be dicult
to determine that the automaton specication is equivalent to (or implements) the axiomatic
specication.
 Power. Can the method be used to verify all implementations? Simulation methods (extended
beyond what is described in this paper, to include \backward" as well as \forward" simulations)
are theoretically complete for showing admissible timed trace inclusion. They also seem to be
powerful in practice, although they might sometimes benet from combination with other
verication methods, such as model-checking, process algebra, temporal logic or partial order
techniques. Model-checking alone is less powerful in practice, since it only checks whether a
subfamily of solutions satisfy some specic properties.
 Ease of Carrying out the Proof. How hard is it to construct a proof using this method?
Can typical engineers learn to do this?
Constructing these proofs, though not dicult, required signicant work. The hardest parts
were getting the details of the models right and nding the right invariants and simulation
mapping. This is an art rather than an automatic procedure. The actual proofs of the invariants
and the simulation were tedious but routine.
Carrying out such a modeling and verication eort requires the ability to do formal proofs,
which most engineers are not trained to do. In contrast, using model-checking, an engineer
can check automatically whether a given \model" satises the properties of interest. (Model
checkers are already being used in practice by engineers to check the correctness of certain
implementations, e.g., of circuits.) On the other hand, the proofs developed using the method
of this paper are amenable to mechanical proof checking. So, automated support can be
provided to engineers attempting to develop formal proofs.
 Information. Does the proof yield information other than just the fact that the implemen-
tation is correct? Does it give any insight into the reasons that the implementation works?
Yes. The invariants and simulations that require considerable eort to produce yield payos
by providing very useful documentation. They express key insights about the behavior of
the implementation. In contrast, model-checking methods yield no such byproducts, only an
assertion that the implementation satises the desired properties.
 Scalability. Does the formalism scale up to handle larger problems? We don't yet know. Just
reasoning about this relatively simple problem was quite complex. A bigger system will mainly

27
 add complexity in the form of more system components and more actions, which leads in turn
to more invariants, more components in the simulation mapping, and more cases in the proofs.
But, in contrast to model-checking, the blowup should not be exponential. Nonetheless, use
of the method for larger problems should be coupled with various methods of decomposing a
problem so one need not reason about an entire complex system at once. Additional levels of
abstraction and use of parallel composition should help.
 Ease of Change. How easy is it to modify the specications and the proofs? Separating
the system model from the environment model and splitting the environment model into the
individual gate model and train model makes it easy to change the descriptions. Should one
want to use a more complex train model (for example, trains move backward as well as forward),
one can easily substitute the revised model for the original. Expressing the required properties
axiomatically and independently makes it easier to change the requirements.
Changes to the specications and implementations require, of course, changes to the proofs.
If the changes are fairly small, however, we expect most of the prior work to survive, and the
stylized form of the proof provides useful structure for managing the modications. Here is a
place where mechanical aid would be most helpful { proofs could be rerun quickly to discover
which parts need to be changed.

Future work includes:

1. Trying this method out on larger examples from real-time process control and timing-based
communication. In the real-time process control area, transportation problems are especially
interesting to us. Some new complications are expected to arise when the continuous quantities
of interest include velocity and acceleration as well as time and position.
2. Developing the appropriate computer assistance for carrying out and checking the proofs. We
plan to try to use the proof systems PVS [18] and Larch [4] to check the proofs and to assess
the utility of mechanical proof systems for such proofs.
3. Trying to systematize the reasoning about the correspondence between the axiomatic and
operational specications.

Acknowledgments
Discussions with R. Jeords of NRL helped identify and clarify software engineering principles useful
in developing the GRC solution and led to improvements in the proofs in Appendix D.

28
References
[1] R. Cleaveland, J. Parrow, and B. Steen. The concurrency workbench: A semantics-based tool
for the verication of concurrent systems. ACM Trans. Prog. Lang. and Sys., 15(1):36{72, Jan.
1993.
[2] Oxford Formal Systems (Europe) Ltd. Failure Divergence Renement, user manual and tutorial,
1992.
[3] R. Gerber and I. Lee. A proof system for communicating shared resources. In Proc. 11th IEEE
Real-Time Systems Symp., pages 288{299, 1990.
[4] J. V. Guttag and J. J. Horning. Larch: Languages and Tools for Formal Specication. Springer-
Verlag, 1993.
[5] C. Heitmeyer and R. Jeords. Formal specication and verication of real-time systems: A
comparison study. Technical report, NRL, Wash., DC, 1994. In preparation.
[6] C. Heitmeyer and J. McLean. Abstract requirements specications: A new approach and its
application. IEEE Trans. Softw. Eng., SE-9(5), September 1983.
[7] C. L. Heitmeyer, R. D. Jeords, and B. G. Labaw. A benchmark for comparing dierent
approaches for specifying and verifying real-time systems. In Proc., 10th Intern. Workshop on
Real-Time Operating Systems and Software, May, 1993.
[8] Constance Heitmeyer and Nancy Lynch. The Generalized Railroad Crossing: A case study in
formal verication of real-time systems. In Proceedings, Real-Time Systems Symposium, San
Juan, Puerto Rico, December 1994. To appear.
[9] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, Englewood Clis, NJ,
1985.
[10] F. Jahanian and A. K. Mok. Safety analysis of timing properties in real-time systems. IEEE
Trans. Softw. Eng., SE-12(9), September 1986.
[11] S. Kromodimoeljo, W. Pase, M. Saaltink, D. Craigen, and I. Meisels. A tutorial on EVES.
Technical report, Odyssey Research Associates, Ottawa, Canada, 1993.
[12] N. Lynch and H. Attiya. Using mappings to prove timing properties. Distrib. Comput., 6:121{
139, 1992.
[13] N. Lynch and M. Tuttle. An introduction to Input/Output automata. CWI-Quarterly, 2(3):219{
246, September 1989. Centrum voor Wiskunde en Informatica, Amsterdam, The Netherlands.
[14] Nancy Lynch. Simulation techniques for proving properties of real-time systems. In REX
Workshop '93, Lecture Notes in Computer Science, Mook, the Netherlands, 1994. Springer-
Verlag. To appear.
[15] Nancy Lynch and Frits Vaandrager. Forward and backward simulations { Part II: Timing-based
systems. Submitted for publication.

29
[16] Nancy Lynch and Frits Vaandrager. Forward and backward simulations for timing-based sys-
tems. In Proceedings of REX Workshop \Real-Time: Theory in Practice", volume 600 of Lecture
Notes in Computer Science, pages 397{446, Mook, The Netherlands, June 1991. Springer-Verlag.
[17] Michael Merritt, Francesmary Modugno, and Mark R. Tuttle. Time constrained automata. In
J. C. M. Baeten and J. F. Goote, editors, CONCUR'91: 2nd International Conference on Con-
currency Theory, volume 527 of Lecture Notes in Computer Science, pages 408{423, Amsterdam,
The Netherlands, August 1991. Springer-Verlag.
[18] S. Owre, N. Shankar, and J. Rushby. User guide for the PVS specication and verication
system (Draft). Technical report, Computer Science Lab, SRI Intl., Menlo Park, CA, 1993.
[19] N. Shankar. Verication of real-time systems using PVS. In Proc. Computer Aided Verication
(CAV '93), pages 280{291. Springer-Verlag, 1993.

30
A The Timed Automaton Model
This section contains the formal denitions for the timed automaton model, taken from [14].
A.1 Timed Automata
A timed automaton A consists of a set states(A) of states, a nonempty set start(A)  states(A) of
start states, a set acts(A) of actions, including a special time-passage action  , a set steps(A) of steps
(transitions), and a mapping nowA : states ! R0. (R0 denotes the nonnegative reals.) The actions
are partitioned into external and internal actions, where  is considered external; the visible actions
are the non- external actions; the visible actions are partitioned into input and output actions.
The set steps(A) is a subset of states(A)  acts(A)  states(A). We write s ,! a s0 as shorthand
A
for (s; ; s0) 2 steps(A), and usually write s:nowA in place of nowA (s). We sometimes suppress the
subscript or argument A.
A timed automaton must satisfy ve axioms: [A1] If s 2 start then s:now = 0. [A2] If s ,!  s0 and
 6=  then s:now = s0:now. [A3] If s ,!  s0 then s:now < s0 :now. [A4] If s ,!
 s00 and s00 ,!
 s0 , then

s ,! s . Axiom [A1] says that the current time is always 0 in a start state. Axiom [A2] says that
0
non-time-passage steps do not change the time; that is, they occur \instantaneously", at a single
point in time. Axiom [A3] says that time-passage steps must cause the time to increase; this is a
convenient technical restriction. Axiom [A4] allows repeated time-passage steps to be combined into
one step.
The statement of [A5] requires the preliminary denition of a trajectory , which describes re-
strictions on the state changes that can occur during time-passage. Namely, if I is any interval of
R0 , then an I -trajectory is a function w : I ! states, such that w(t):now = t for all t 2 I , and
w(t1) ,!  w(t ) for all t ; t 2 I with t < t . That is, w assigns, to each time t in interval I , a state
2 1 2 1 2
having the given time t as its now component. This assignment is done in such a way that time-
passage steps can span between any pair of states in the range of w. If w is an I -trajectory and I is
left-closed, then dene w:ftime = min(I ) and w:fstate = w(w:ftime), while if I is right-closed, then
dene w:ltime = max(I ) and w:lstate = w(w:ltime). If I is a closed interval, then an I -trajectory w
is said to span from state s to state s0 if w:fstate = s and w:lstate = s0 . The nal axiom is: [A5] If
s ,! s0 then there exists a trajectory that spans from s to s0 . Axiom [A5] is a kind of converse to
[A4]; it says that any time-passage step can be \lled in" with states for each intervening time, in a
\consistent" way.
A.2 Timed Executions and Timed Traces
A timed execution fragment is a nite or innite alternating sequence  = w01w1 2w2


, where:
1. Each wj is a trajectory and each j is a non-time-passage action.
2. If  is a nite sequence, then it ends with a trajectory.
3. If wj is not the last trajectory in  then its domain is a closed interval. If wj is the last
trajectory then its domain is left-closed (and either right-open or right-closed).
4. If wj is not the last trajectory then wj :lstate ,!
+1
j
wj+1:fstate.

31
The trajectories describe the changes of state during the time-passage steps. The last item says
that the actions in  span between successive trajectories. A timed execution is a timed execution
fragment for which the rst state of the rst trajectory, w0, is a start state. In this paper, we restrict
attention to the admissible timed executions, i.e., those in which the now values occurring in the
states approach 1. We use the notation atexecs(A) for the set of admissible timed executions of
timed automaton A. A state of a timed automaton is dened to be reachable if it is the nal state
of the nal trajectory in some nite timed execution of the automaton.
In order to describe the problems to be solved by timed automata, we require a denition for their
visible behavior. We use the notion of timed traces , where the timed trace of any timed execution
is just the sequence of visible events that occur in the timed execution, paired with their times of
occurrence. The admissible timed traces of the timed automaton are just the timed traces that arise
from all the admissible timed executions. We use the notation attraces(A) for the set of admissible
timed traces of timed automaton A. Often, we express requirements to be satised by a timed
automaton A as the set of admissible timed traces of another timed automaton B . Then we say
that A implements B if attraces(A)  attraces(B ). If  is any timed execution, we use the notation
ttrace() to denote the timed trace of .
We dene a function time that maps any non-time-passage event in an execution to the real time
at which it occurs. Namely, let  be any non-time-passage event. If  occurs in state s, then dene
time( ) = s:now.
A.3 Composition
We dene a simple binary parallel composition operator for timed automata. Let A and B be
timed automata satisfying the following compatibility conditions: A and B have no output actions
in common, and no internal action of A is an action of B , and vice versa. Then the composition of
A and B , written as A  B , is the timed automaton dened as follows.
 states(A  B) = f(sA; sB ) 2 states(A)  states(B) : sA:nowA = sB :nowB g;
 start(A  B) = start(A)  start(B);
 acts(A  B) = acts(A) [ acts(B); an action is external in A  B exactly if it is external in
either A or B , and likewise for internal actions; a visible action of A  B is an output in A  B
exactly if it is an output in either A or B , and is an input otherwise;
 (sA; sB ) ,!AB (s0A; s0B ) exactly if
1. sA ,! s0 if  2 acts(A), else s = s0 , and
A A A A

2. sB ,!B sB if  2 acts(B ), else sB = s0B ;
0

 (sA; sB ):nowAB = sA:nowA.

Then A  B is a timed automaton. If  is a timed execution of A  B , we write jA and jB for the
projections of  on A and B , respectively. For instance, jA is dened by projecting all states in 
on the state of A, removing actions that do not belong to A, and collapsing consecutive trajectories.
We also use the projection notation for sequences of actions, writing, e.g.,  jA for the subsequence
of  consisting of actions of A.

32
Lemma A.1 (Substitutivity) Let A and B be timed automata with the same input and output ac-
tions, and let C be a timed automaton compatible with both. If attraces(A)  attraces(B ) then
attraces(A  C )  attraces(B  C ).
Lemma A.2 If  2 atexecs(A  B) then jA 2 atexecs(A) and jB 2 atexecs(B).
Lemma A.3 Suppose that A 2 atexecs(A) and B 2 atexecs(B). Suppose  is a sequence of
timed visible actions of A  B such that  jA = ttrace(A ) and  jB = ttrace(B ). Then there exists
 2 atexecs(A  B ) such that jA = A and jB = B .
Since the composition operation is associative, up to isomorphism, we may extend it to an
arbitrary nite number of argument timed automata.

33
B MMT Automata
B.1 Automaton Denition
MMT automata were originally dened by Merritt, Modugno and Tuttle [17]; we use a special
case of their denition from [12, 14]. An MMT automaton is an I/O automaton [13] together
with upper and lower bounds on time. An I/O automaton A consists of a set states(A) of states,
a nonempty set start(A)  states(A) of start states, a set acts(A) of actions, (partitioned into
external and internal actions; the external actions are further partitioned into input and output
actions), a set steps(A) of steps, and a partition part(A) of the locally controlled (i.e., output and
internal) actions into at most countably many equivalence classes. The set steps(A) is a subset of
states(A)  acts(A)  states(A); An action  is said to be enabled in a state s provided that there
 s0 . A set of actions is said to
exists a state s0 such that (s; ; s0) 2 steps(A), i.e., such that s ,! A
be enabled in s provided that at least one action in that set is enabled in s. It is required that
the automaton be input-enabled , by which is meant that  is enabled in s for every state s and
input action  . The nal component, part, is sometimes called the task partition . Each class in this
partition groups together actions that are supposed to be part of the same \task".
An MMT automaton is obtained by augmenting an I/O automaton with certain upper and lower
time bound information. Let A be an I/O automaton with only nitely many partition classes. For
each class C , dene lower and upper time bounds, lower(C ) and upper(C ), where 0  lower(C ) < 1
and 0 < upper(C )  1; that is, the lower bounds cannot be innite and the upper bounds cannot
be 0.
B.2 Timed Executions and Timed Traces
A timed execution of an MMT automaton A is dened to be an alternating sequence of the form
s0 ; (1; t1 ); s1;


where the 's are input, output or internal actions (but not time-passage actions).
For each j , it must be that sj ,!j +1 s . The successive times are nondecreasing, and are required
j+1
to satisfy the given lower and upper bound requirements. More specically, dene j to be an initial
index for a class C provided that C is enabled in sj , and either j = 0, or else C is not enabled in
sj ,1, or else j 2 C ; initial indices are the points at which the bounds for C begin to be measured.
Then for every initial index j for a class C , the following conditions must hold:
1. (Upper bound)
If upper 6= 1, then there exists k > j with tk  tj + upper(C ) such that either k 2 C or C is
not enabled in sk .
2. (Lower bound)
There does not exist k > j with tk < tj + lower(C ) and k 2 C .
Finally, admissibility is required: if the sequence is innite, then the times of actions approach 1.
Each timed execution of an MMT automaton A gives rise to a timed trace , which is just the
subsequence of external actions and their associated times. The admissible timed traces of the MMT
automaton A are just the timed traces that arise from all the timed executions of A.
MMT automata can be composed in much the same way as ordinary I/O automata, using syn-
chronization on common actions. More specically, dene two MMT automata A and B to be
compatible according to the same denition of compatibility for timed automata. Then the com-
position of the two automata is the MMT automaton consisting of the I/O automaton that is the

34
composition of the two component I/O automata (according to the denition of composition in [13]),
together with the bounds arising from the components. This composition operator is substitutive
for the admissible timed trace inclusion ordering on MMT automata.
B.3 MMT Automata and Timed Automata
MMT automata are not exactly a special case of timed automata. This is because the MMT model
uses an \external" way of specifying the time bound restrictions, via the added lower and upper
bounds. Timed automata, in contrast, build the time-bound restrictions explicitly into the time-
passage steps. However, it
is not hard to transform any MMT automaton A into a naturally-corresponding timed automaton
A0 . First, the state of the MMT automaton A is augmented with a now component, plus rst(C )
and last(C ) components for each class of the task partition. The rst(C ) and last(C ) components
represent, respectively, the earliest and latest time in the future that an action in class C is allowed
to occur. The now, rst and last components all take on values that represent absolute times, not
incremental times. The time-passage action  is also added. The rst and last components get
updated in the natural way by the various steps, according to the lower and upper bounds specied
in the MMT automaton A. The time-passage action has explicit preconditions saying that time
cannot pass beyond any of the last(C ) values, since these represent deadlines for the various tasks.
Restrictions are also added on actions in any class C , saying that the current time now must be at
least equal to rst(C ).
In more detail, each state of A0 is a record consisting of a component basic, which is a state
of A, a component now 2 R0 , and, for each class C of A, components rst(C ) and last(C ), each
in R0 [ f1g. Each start state s of A0 has s:basic 2 start(A), and s:now = 0. Also, if C is
enabled in s:basic, then s:rst(C ) = lower(C ) and s:last(C ) = upper(C ); otherwise s:rst(C ) = 0
and s:last(C ) = 1. The actions of A0 are the same as those of A, with the addition of the time-
passage action  . Each non-time-passage action is classied as an input, output or internal action
according to its classication in A.
The steps are dened as follows. If  2 acts(A), then s ,! A s0 exactly if all the following
0

conditions hold:
1. s:now = s0 :now.
2. s:basic ,! s0 :basic.
A
3. For each C 2 part(A):
(a) If  2 C then s:rst(C )  s:now.
(b) If C is enabled in both s and s0 , and  2= C , then s0 :rst(C ) = s:rst(C ) and s0 :last(C ) =
s:last(C ).
(c) If C is enabled in s0 and either C is not enabled in s or  2 C then s0 :rst(C ) = s:now +
lower(C ) and s0 :last(C ) = s:now + upper(C ).
(d) If C is not enabled in s0 then s0 :rst(C ) = 0 and s0 :last(C ) = 1.
On the other hand, if  =  , then s0 ,! A s exactly if all the following conditions hold:
0

1. s0 :now < s:now.

35
 2. s:basic = s0 :basic.
3. For each C 2 part(A):
(a) s:now  s0 :last(C ).
(b) s:rst(C ) = s0 :rst(C ) and s:last(C ) = s0 :last(C ).
The resulting timed automaton A0 has exactly the same admissible timed traces as the MMT
automaton A.
Moreover, this transformation commutes with the operation of composition, up to isomorphism.
We refer to an MMT automaton and to its transformed version interchangeably. Another way of
looking at the preceding construction is as showing exactly how the MMT notation is used to denote
timed automata.
The following is a technical lemma that is useful in some of the invariant and simulation proofs.
Lemma B.1 In all reachable states of a (transformed) MMT automaton, and for all classes C , the
following hold.
1. now  last(C )
2. If last(C ) 6= 1 then last(C )  now + upper(C ).

36
C Invariants and Simulation Mappings
We dene an invariant of a timed automaton to be any property that is true of all reachable states.
The denition of a simulation mapping is paraphrased from [16, 15, 14]. We use the notation
f [s], where f is a binary relation, to denote fu : (s; u) 2 f g. Suppose A and B are timed automata
and IA and IB are invariants of A and B , respectively. Then a simulation mapping from A to B
with respect to IA and IB is a relation f over states(A) and states(B ) that satises:
1. If u 2 f [s] then u:now = s:now.
2. If s 2 start(A) then f [s] \ start(B ) 6= ;.
 s0 , s; s0 2 I , and u 2 f [s] \ I , then there exists u0 2 f [s0] such that there is a timed
3. If s ,! A A B
execution fragment from u to u0 having the same timed visible actions as the given step.
Note that  is allowed to be the time-passage action in the third item of this denition. The most
important fact about these simulations is that they imply admissible timed trace inclusion:
Theorem C.1 If there is a simulation mapping from timed automaton A to timed automaton B,
with respect to any invariants, then attraces(A)  attraces(B ).

37
D Correspondence Between Original Specication and AxSpec
We show how the Utility Property in the original formulation of the GRC [7] relates to the Utility
Property in AxSpec. In the original formulation, the Utility Property is expressed as \If t 62 [i [i ,
1 ; i + 2 ]; then g(t) = 90;" which can be rewritten as \If g (t) 6= 90, then t 2 [i [i , 1 ; i + 2]:"
In the Lynch-Vaandrager model, the Utility Property can be stated as an axiom of any admissible
timed execution : \If s is a state in  with s:Gate:status 6= up, then s:now 2 [i , 1; i + 2] for
some i."
In the description of AxSpec in Section 3.5, the Utility Property is expressed as
If s is a state in  with s:Gate:status 6= up, then at least one of the following conditions holds.
a. There exists s0 preceding (or equal to) s in  with s0 :Trains:r:status = I for some r and s0 :now  s:now , 2 .
b. There exists s0 following (or equal to) s in  with s0 :Trains:r:status = I for some r and s0 :now  s:now + 1 .
c. There exist two states s0 and s00 in , with s0 preceding or equal to s, s00 following or equal to s, s0 :Trains:r:status =
I for some r, s00 :Trains:r:status = I for some r, and s00 :now , s0 :now  1 + 2 + .

Lemmas D.1 and D.2 show that the Lynch-Vaandrager form of the original Utility Property and the
statement of utility in AxSpec (parts a and b only) are equivalent.

Lemma D.1 If s is a state in  and s:now 2 [i , 1; i + 2] for some i, then (a) or (b) holds.
Proof: There are three cases.
1. For s:now 2 [i , 1 ; i], choose s0 to be the last state in  such that s0 :now = i. Then,
s0 :Trains:r:status = I for some r, and s0 follows (or is equal to) s in . Further, i , 1  s:now,
which implies i  s:now + 1. This implies s0 :now  s:now + 1.
2. For s:now 2 [i; i ], choose s0 = s. Then, s0 :Trains:r:status = I for some r, and s:now 
s:now , 2 by assumptions on the constants. This implies s0 :now  s:now , 2 .
3. For s:now 2 [i ; i + 2 ], choose s0 to be the rst state in  such that s0 :now = i . Then,
s0:Trains:r:status = I for some r, and s0 precedes (or is equal to) s in . Further, s:now 
i + 2, which implies s:now , 2  i . This implies s:now , 2  s0:now.

Lemma D.2 If s is a state in  and (a) or (b) holds, then s:now 2 [i , 1; i + 2] for some i.
Proof: Assume (a). Then, s:now , 2  s0:now, which implies s:now  s0:now + 2. Further,
s0:Trains:r:status = I for some r implies i  s0:now  i for some i, which implies s0 :now + 2 
i + 2 . This implies s:now  i + 2 as needed. By assumptions on the constants, i , 1  i . This
implies i , 1  s:now, since s0 precedes or is equal to s.
Assume (b). Then, s0 :Trains:r:status = I for some r implies i  s0 :now  i . Further, s0
follows (or equals) s in  implies s:now  s0 :now. By assumptions on the constants, i  i + 2.
Hence, s:now  i + 2 as needed. Also, i , 1  s0:now , 1 . Then, s0 :now  s:now + 1 implies
s0:now , 1  s:now. This implies i , 1  s:now as needed.

38
 To prevent the gate from being raised and lowered uselessly, we revised the Utility Property so
that the gate is only raised if there is sucient time  ,  > 0, for at least one car to pass through
the crossing. To express this added constraint, the original statement can be rewritten as
If g(t) 6= 90, then at least one of the following holds:
1. t 2 [i [i , 1 ; i + 2 ] or
2. t 2 [i + 2 ; i+1 , 1 ] with i+1 , i  2 +  + 1 for some i.
In the Lynch-Vaandrager model, this is expressed as
If s is is a state in  with s:Gate.status 6= up, then for some i at least one of the following holds:
1. s:now 2 [i , 1 ; i + 2 ] or
2. s:now 2 [i + 2 ; i+1 , 1 ] with i+1 , i  2 +  + 1 :

We show the equivalence between the latter statement of the Utility Property and the statement of
utility (parts a, b, and c) in AxSpec.
Lemma D.3 If there exists a state s in  such that for some i either condition (1) or condition (2)
holds, then at least one of conditions (a), (b), or (c) holds.
Proof: Lemma D.1 shows that if condition (1) holds, either (a) or (b) holds. We show that condition
(2) implies condition (c). Let s0 be some state such that s0 :now = i and s00 be some state such that
s00:now = i+1: Then, by denition, s0:Trains:r:status = I for some r and s00:Trains:r:status = I for
some r. Further, s:now 2 [i , 1 ; i + 2] implies s0 :now < s:now < s00 :now, so s0 precedes s and s00
follows s in . Finally, i+1 , i  2 +  + 1 implies s00:now , s0 :now  1 + 2 +  .

Lemma D.4 If there exists a state s in  such that at least one of conditions (a), (b), or (c) holds,
then for some i condition (1) or condition (2) holds.
Proof: Lemma D.2 shows that if either (a) or (b) holds, then (1) holds. We show that if condition
(c) holds, then either (1) or (2) holds. There are two cases.
1. Suppose s occurs during the interval [i , 1 ; i + 2] for some i. Clearly, (1) holds.
2. Suppose s occurs during the interval [i +2 ; i+1 ,1 ] for some i. Then, s0 :Trains:r:status = I for
some r and s0 precedes or is equal to s implies s0 :now  i . Similarly, s00 :Trains:r:status = I for
some r and s00 follows or is equal to s implies s00 :now  i+1 . Hence, s00 :now , s0 :now  i+1 , i .
This together with s00 :now , s0 :now  1 + 2 +  implies i+1 , i  1 + 2 +  . Therefore, (2)
holds.

39
E Proof of Relationship Between OpSpec and AxSpec
We prove Lemma 4.3. We rst prove an easy property of OpSpec:
Lemma E.1 Let  be any admissible timed execution of OpSpec. Let  be any lower event occurring
in  from a state in which Gate:status 2 fgoing-up; upg. Then there is an enterI event  occurring
after  in , with time()  time( ) + 1 .
Proof: Suppose that  occurs from state s, leading to state s0; then time() = s:now = s0:now. If
s:last1 = 1, then the eect of lower implies that s0 :last1 = s0 :now + 1 . Otherwise, part 3 of Lemma
6.2 implies that s0 :last1  s0 :now + 1 . Thus, in either case, s0 :last1  s0 :now + 1.
By the precondition for the time-passage action and the fact that only enterI actions can increase
last1, real time cannot pass beyond s0 :last1 unless a train enters I at a time  s0:last1  s0 :now + 1.
But  is an admissible execution, so time passes to 1. It follows that there must be an enterI event
 occurring after  in  such that time()  time( ) + 1.
Now for the proof of Lemma 4.3:
Proof: Let  be any admissible timed execution of OpSpec. By assumption,  satises the Safety
Property, i.e., the safety invariant is true in all states of . We show that it also satises the Utility
Property.
Let s be any state occurring in  with s:Gate:status 6= up. If s:Trains:r:status = I for any r, then
the claim is immediate. So assume that s:Trains:r:status 6= I for all r.
Since s:Gate:status 6= up, it must be that there was a previous lower event occurring from a state in
which Gate:status 2 fgoing-up; upg. (Consider the possible transitions in the automaton Gate.) Let
 be the last lower event preceding s that occurs from a state in which Gate:status 2 fgoing-up; upg.
Then Gate:status 6= up in the entire interval from just after  to s. Also, time( )  s:now.
By Lemma E.1, an enterI event occurs within time 1 after  . Let  be the rst such enterI
event. Thus, time()  time( )+ 1  s:now + 1. By the Safety Property, Gate:status = down when
 occurs. We consider two cases.
1.  is after s.
Then take s0 to be the state just after . Then s0 :now = time()  s:now + 1, and so s0
satises the axiomatic Utility Property, part (b).
2.  is before s.
Since (by assumption) there is no train in I in state s, we can nd a latest exit event following
 and preceding s, which must leave I empty. When occurs, the last2 variables are set, which
ensures that either the gate reaches the up position within time 2 after , or some train reaches
I within time 2 +  + 1 after . We consider two subcases.
(a) s:now  time( ) + 2 .
Then take s0 to be the state just prior to . Then s0 :now = time( )  s:now , 2, and so
s0 satises the axiomatic Utility Property, part (a).

40
(b) s:now > time( ) + 2 .
Then the gate cannot reach the up position within time 2 after , because Gate:status 6=
up throughout the interval from  to s. So it must be that some train reaches I within
time 2 +  + 1 after . That is, there must be some enterI event 0 following , with
time( 0)  time( ) + 2 +  + 1 .
We claim that 0 must follow s. For if it did not, the fact that I is empty in s would
imply that there must be an exit event following 0 and preceding s, which contradicts
our choice of . Then take s0 to be the state just before and s00 to be the state just
after 0. Then s00:now , s0 :now = time( 0) , time( )  2 +  + 1. Thus, s0 and s00 satisfy
the axiomatic Utility Property, part (c).

41