A Relational Program Architecture
For
The Bay Area Rapid Transit System
F.B. Bastani, V. Reddy, P. Srigiriraju, and I.-L. Yen
Department of Computer Science
University of Texas at Dallas
M/S EC-31, P.O.Box 830688
Richardson, TX 75083-0688
Abstract
The failure of safety-critical systems, such as aircraft
control systems, railway control systems, and nuclear
power plant control systems, can cause catastrophic
losses of life and property. Hence, it is imperative to
assure the reliability and safety of these systems to a very
high degree of confidence. It is infeasible to perform this
type of ultrahigh reliability analysis by treating the entire
system as one unit. This paper develops an approach that
combines
relational
programs
with
iterative
enhancement. It allows a complex system to be divided
into a series of increments such that each increment is
decomposed into subsystems that can be independently
assessed. An increment is related to the previous
increment via transformations or clearly delineated
enhancements that can be assessed independently. The
subsystems are then automatically composed together to
obtain the system. The approach guarantees that the
reliability and safety of the system can be inferred from
the corresponding properties of the individual
subsystems. It is illustrated using a case study drawn
from the Bay Area Rapid Transit system project.
1. Introduction
Dramatic advances in computer and communication
technologies have greatly reduced hardware costs and
improved their performance and reliability. This has
made it economically feasible to extend the reach of
automation to more and more critical services, such as
banking and financial services, remote patient monitoring
systems, manufacturing systems, transportation, etc.
Meanwhile, software continues to become more and
more complex due to the growing sophistication and
complexity of modern applications. For safety-critical
applications, such as railway control systems, it is
necessary to be able not only to achieve high quality but
also to rigorously demonstrate that high quality has in
fact been achieved.
Advances in software development methods, such as
continuous process improvement methods, sophisticated
tools (code generators, transformation systems), rigorous
techniques (reviews, validation/verification), can reduce
the number of faults injected into the system during the
development process.
Industrial-strength program
transformation systems, such as those from Reasoning,
Inc. [Rea97] and Sandia National Laboratories [Win96],
have the potential to essentially eliminate all coding
faults. This leaves the problem of residual specification
faults. These faults are becoming increasingly likely due
to the growing complexity of software requirements.
One approach that is used to facilitate prevention as well
as detection of specification faults is to decompose the
requirements specification into more manageable
portions. One of the earliest works is reported in [Zav85]
where a requirements specification is decomposed into
multiple views, each of which captures some behavior of
the system. Each view is represented by a sequence
diagram. This decomposition reduces the complexity of
the system, but two different views are not necessarily
independent, e.g. they can interact via aliases in order to
react in a compatible way to a given input. The concept
of multiple views has also been used in StateCharts
[Har87,Har90], Objectcharts [Col92], and other related
methods. It has also been applied to existing languages,
e.g. Z [Jac95a]. The primary motivation for these views
(achieved by grouping multiple states into one super
state) is to reduce the complexity of the underlying Finite
State Machine specification of the system. Interactions
between machines (e.g., via synchronous events) can
introduce dependencies between different machines.
RSML [Lev94] is a significant extension to StateCharts
with the goal of achieving more easily understandable
and reviewable specifications. It also has a more
intuitive step semantics, but the objective is to assure
analyzability of complex specifications rather than to
facilitate reliability assessment.
Decomposition methods that persist over the life-cycle
include separation using rely-guarantee assertions
[Lam94], behavioral inheritance [Atk91], and AspectOriented Programming [Kic97]. These methods result in
distinct pieces of code that are then formally composed
together. The rely-guarantee based approach achieves
separation between different components by using a
common interface language between two components
with a precise specification of rely and guarantee
conditions [Jon83] for each separate component.
However, components are not required to be observable
by the end-user who may not even be aware of some
interfaces, especially interfaces with inner components.
Behavioral inheritance is an elegant way of separating
out synchronization concerns from functional concerns in
object-oriented languages [Atk91].
The approach
proposed in [Atk91] uses multiple inheritance, by
inheriting one functional component and one behavioral
1
component. It satisfies end-user assessability but does
not guarantee an implementation-invariant state space (so
the system properties cannot be inferred from the
component properties). Aspect-Oriented Programming is
a more recent technique [Kic97] that strives for
separation of concerns in implementing object-oriented
programs. Features that can be used for more than one
object, such as error detection, exception handling, and
synchronization code, are separated from the main
functionality of the objects. The code for these features
is written once along with identification of the objects
that will need the code and the positions/situations that
will activate the code. Then, a preprocessor is used to
``weave'' the code for the features with the code for the
objects.
These methods simplify the analysis of software
requirements and also facilitate the assurance of software
quality by identifying components that can be designed
and implemented independently of other components.
However, these methods do not necessarily enable the
demonstration of high quality which is best achieved by
developing methods that enable the properties of the
system to be inferred from those of its components. (The
components are smaller relative to the entire system and,
therefore, easier to evaluate.) However, this inference is
not always possible for arbitrary decompositions.
In [Bas99a], the concept of relational programs has been
introduced to allow the reliability of a process-control
system to be inferred from the reliability of its
components. Relational programs return all possible
outputs for an input rather than just one output. [Bas99b]
presents an approach for assessing the reliability of a
system of relational components from the reliability of
the individual components.
In this paper, we briefly present the concept of relational
programs and then show how it can be applied to the
control of trains in the Bay Area Rapid Transit(BART)
system.
2. System Model
We consider a system that consists of a collection of
autonomous ralational programs.
To illustrate the approach, consider a simplified conveyor
belt control system [Win98] shown in Fig. 1. Our
program is in charge of section B of the system. Its goal
is to move objects from section A to section C such that
(a) there are no accidents (i.e., the belt moves an object
from the right end of belt B to section C only if C is not
occupied), (b) energy is conserved (i.e., the belt moves
only if it is transporting an object, and (c) the transfer
time is minimized.
It may not be possible to
simultaneously satisfy these constraints all the time.
Hence, the safety constraint (a) is given a higher priority
than the optimization constraint (b) which, in turn, is
assigned a higher priority than requirement (c).
The program controls a motor (actuator) by setting it to
either on (which causes the belt to move in the left (L) to
right (R) direction) or off (which stops the belt). It
monitors 4 binary-valued sensors, namely, l_occupied
(true if there is an object at the left end of B, false
otherwise), r_occupied (true if there is an object at the
right end of B, false otherwise), b_occupied (true if there
is at least one object on B, false otherwise), c_occupied
(true if there is an object on section C, false otherwise).
Clearly, l_occupied  r_occupied  b_occupied. The
following is a decomposition of the specification into
three independent portions:
•
•
•
Safety process, P0. It ensures that an object is not
moved to section C when section C is occupied.
Energy conservation process, P1. It ensures that the
belt is moved only when necessary.
Time optimization process, P2. It ensures that
objects are transported as quickly as possible.
The code for each of these components is a relational
program, i.e., it returns the set of all possible output
values for each input.
P0:
if r_occupied  c_occupied  motor:= {off} |
otherwise  motor:= {on,off}
end if
P1:
if b_occupied  motor:= {off} |
b_occupied  motor:= {on,off}
end if
P2:
if b_occupied  motor:= {on} |
b_occupied -> motor:= {on,off}
end if
The code for process P0 (“avoid accidents'”) specifies
that the motor should be off if section C is occupied and
there is an object at the right end of conveyor belt B;
otherwise, P0 does not care whether the motor is on or
off. The code for P1 (“conserve energy”) specifies that
the motor should be off if conveyor belt B has no objects
on it; otherwise, the motor can be on or off. Finally, the
code for process P2 (“minimize transfer time”) specifies
that the motor should be on if there is an object on
conveyor belt B; otherwise, the motor can be either on or
off.
The three programs are composed together using the
specification that priority(P0) > priority(P1) >
priority(P2). The code for the overall system is obtained
by computing P0  P1  P2 which results in the
following program:
if r_occupied  c_occupied  motor:= {off} |
r_occupied  c_occupied 
if b_occupied  motor:= {on} |
b_occupied  motor:= {off}
end if
end if
2
The decomposition of the system into autonomous
relational programs has several significant advantages.
First, it is now possible to test the programs separately
which results in reduced testing effort since each
component has a smaller state space and size than the
overall system. Also, it is now easier to make changes to
the program. For example, to have a stricter energy
conservation algorithm, we only need to modify process
P1 and then redo the composition step. The composition
guarantees that the safety goal will continue to hold.
•
•
•
•
3. System Specification
3.1 Overview
The overall objective of the BART [Win99] is to
construct a system that can control the speed and
acceleration of trains subject to the constraints described
in the specification. This case study concentrates on one
of the most critical functions of the control system,
namely, the calculation of the speed and the acceleration
commands that are to be sent to the trains. The following
is a brief summary of the requirements specifications and
is adapted from [Win99].
Each station controls trains only in its immediate area.
Stations communicate with their neighbors to receive and
hand-off trains. It is assumed that the communication
links, the on-board train control system, and station
computer functions as intended.
The responsibility of the speed and acceleration selection
process is to get trains from one point to another as
quickly and as smoothly as possible, subject to the
following constraints:
•
•
•
A train should not enter a closed gate.
A train should never get so close to a train in front
that if the train in front stopped suddenly (eg.,
derailed ) the (following) train would hit it.
A train should stay below the maximum speed that
segment of track can handle.
The system operates on ½ second cycles. Each ½ second
the station computer receives ranging and speed
information from the trains. It uses this information to
compute an uncertainty envelope for the location of the
each train (mean & standard deviation). This information,
along with the track signal and track layout information,
is used to compute speed and acceleration commands.
The control algorithm receives the following information,
updated every ½ second.
•
•
The outputs of the position algorithm – mean and
standard deviation on both position and velocity for
all trains in the area.
The Message Originating Time Tag (MOTT). This
is the time a given train sent its most recent report.
The control system attaches the same MOTT to
•
•
acceleration and velocity commands that are sent
back out of the train.
Gate information (open, closed) from the
interlocking system.
Any special speed restrictions on either the whole
system or individual track segments.
The following static data is also available of
segments of the track. Segment location (end points
and length).
Grade (less than 4% system-wide). Each track
segment has only one defined grade. Grades can
either be constant or be part of a parabolic change
from one grade to another).
Maximum allowable speed. It is the responsibility of
the control systems to slow down before entering
segments with low allowable speeds.
Locations of gates (and ends of some segments).
The command message should contain the following
safety critical data:
• Commanded acceleration (-2 to –0.45 mphps in
(closed loop) braking, 0 to 3 mphps in propulsion).
• Message Origination Time Tag.
• A fixed four-bit code identifying this as a command
message.
3.2. Problem Characteristics:
In the version developed here, the following changes
have been made:
• The control system is present not only at a station
but also on the trains. This reduces the complexity
of considering the protocols involved in
communication between the station and the train
computers. Also, the time tag does not come into the
picture. As the trains are autonomous, the handoff
between stations is not considered.
• As there is no centralized control system, the control
system of the train needs to know only about the
train ahead. It does not need the details about the
other trains.
• The only limitation of this approach is that, by not
knowing the global positioning of the trains, their
movements, gates and their control lights we cannot
schedule the train movement to obtain the optimum
travel time. It is possible that by knowing the global
state of the system, we can improve the performance
of the system.
3.3. Transformational Development:
To facilitate reliability assessment, we have decomposed
the system into several autonomous components. Also,
we have introduced a series of transformations that allow
the system to be systematically evolved from a basic
version to a full-fledged version. The steps in the
transformation sequence are as follows:
3
1.
2.
Point mass, Flat terrain, Straight track, No delay,
Precise sensor data. The train is assumed to be a
point mass moving on a straight track over a flat
terrain. Also, it is assumed that there is no delay in
processing the sensor data and sending commands to
the actuators. Further, it is assumed that the sensor
data is precise (exact). This step is further divided
into several steps.
(a) Safety and Functional goals. The control
program is designed to assure the safety goals
(i.e., no accidents and satisfaction of speed
limit constraints). It ignores the smoothness
requirement and assumes that the speed limit is
the same throughout the path. The state space
for this program is a very small fraction of the
state space of the final program.
(b) Safety and Functional goals, Varying speed
limits. A component is added to the system to
monitor the speed limit further down the path
and initiate braking actions to ensure that the
speed limit will never be violated. This stage
completes the implementation of all the safety
requirements of the system.
(c) Safety and Functional goals and Smooth stops.
This is achieved by adding look-ahead
components that anticipate potential stopping
situations and initiate smooth braking in
advance. These components operate in parallel
with the components in (a) and at a lower
priority than the safety components, so the
original safety goal is still guaranteed.
(d) Safety and Functional goals, Smooth stops, and
Smooth starts. Delay components are added to
the system to allow smooth acceleration from a
stopped state or a state having a lower speed to
a state having a higher speed. Again, these
components operate in parallel with the
components in (b) and at a lower priority than
the safety components. Hence they do not
affect the safety system. The components
operate at the same priority as the “minimal
time” functional requirements, so this step
affects the performance of the system. This
involves a tradeoff between the smoothness and
the performance requirements and must be
specified by the customer.
(e) Safety and Functional Goals, Smooth Stops,
Smooth Starts, and Reduction in mode changes.
In this step, buffers are added to the distance
and speed margins to prevent the “minimal
time” component and the safety-critical
components from causing repeated mode
changes from propulsion to braking mode and
braking to propulsion mode. The specification
provides a 2mph margin for the speed limit
requirement. A similar margin will be helpful
for the distance requirement.
Flat terrain, Straight track, No delay, Precise sensor
data. The program developed in step (1) is modified
to take the full length of the train into consideration
by assuring that the distance between two trains is
measured from the end of the first train to the front
3.
4.
5.
of the second train. (The first train is ahead of the
second second train.)
Straight track, No delay, Precise data. The terrain is
now considered to be hilly so that the track may
have some slope. The program in step (2) is
modified so that in the calculations, the
accelerations and decelerations produced by the
system are adjusted to account for the natural
acceleration due to the gradient. The adjustment
takes into account the distribution of the mass of the
train over its entire length Once these adjustments
have been verified or validated, the system will
operate correctly.
No delay, Precise data. The tracks can now be
curved rather than straight. A component is added to
calculate the maximum allowable speeds while
negotiating a curve given the speed limit, the length
of the train, and the slope of the track. Alternatively,
the system can be designed to provide this
information statically along the entire path for all the
trains.
Complete system. The delay and precision problems
are handled by taking a conservative approach as
described in the requirements specification. That is,
the position of the train in front of the train being
controlled is taken to be at the lower range of the
sensor readings. Similarly, delays are accounted for
by ensuring that the system will be safe throughout
the next interval. (The specification allows the train
to stop if it does not receive updated commands
within a certain period from the station. This is not
a problem in our case since we are assuming an onboard control system.
4. Requirements Decomposition:
The system is decomposed into Safety-Stop, SafetySpeed, Smoothness and Reach Destination or Time
Optimization components.
S(t)
C(t)
Safety
Stop
A1 = a11 .. a12
V(t)
Vmax
Safety
Speed
A2 = a21 .. a22
S(t) y(t)
Time
Optimiz
ation
A3 = a31 .. a32
S(t+) C(t+)
Smoo
thness
A4 = a41 .. a42

Figure 1. Requirements Decomposition
4
4.1. Safety-Stop:
Simulator
This component makes sure that if a train starts in a safe
zone, it will be in the safe zone throughout its journey.
This component has the highest priority over any other
component.
Simula
tor
C(t)
< s(t)
C(t) =
s(t)
C(t) >
s(t)
Control Module
Safetystop
Safetyvelocity
Reachdestination
Fig. 2. Safety-Stop
Fig 4. Simulation Environment
4.2. Safety-Speed:
5.1. Simulator:
This component ensures that the maximum speed of the
train is well within the limits.
V(t) =
Vmax
V(t) <
Vmax
V(t) >
Vmax
Fig. 3. Safety-Speed
4.3. Reach Destination or Time Optimization:
This component tries to optimize the journey time. This
returns a range of accelerations such that the train can
reach the destination as quickly as possible.
The Simulator simulates the actual movement of train for
the next ½ second. This component updates the position,
velocity, critical distance and remaining distance to be
traveled for every ½ second.
Input and Output to Simulator:
Input: Position1, Velocity1, Acceleration, Critical
distance1, and Remaining distance1.
Output: Position2, Velocity2, Critical distance2,
Remaining distance2, Stopping distance.
The simulator takes in the following input:
Position1: this is the current position of the train.
Velocity1: This is the current velocity of the train.
Acceleration: This is the acceleration of the train in the
next ½ second.
Critical distance1: This is the distance between the train
and the train ahead of it.
Remaining distance1: This is the distance, which the train
has to travel to reach the destination.
The simulator gives the following output:
4.4. Smoothness:
This component looks ahead or introduces delays to
minimize the jerks in the journey. This returns a range of
acceleration aiming at smooth journey.
5. Implementation:
CODE:
Position2: this is the position of the train after ½ second.
Velocity2: This is the velocity of the train after ½ second.
Critical distance2: This is the distance between the train
and the train ahead of it after the ½ second.
Remaining distance 2: This is the distance that the train
has to travel to reach the destination after the ½ second.
Stopping distance: This is the minimum distance at which
the train will be able to stop with maximum possible
braking.
We have written the code for the simulation in JAVA 1.1.
5.2. Safety-stop:
This component always keeps the train in a safe zone
along with keeping the journey as smooth as possible. It
has three functional components. The first functional
component, Safety-stop-main, always keeps the train in
5
the safe-zone. It tries to give the maximum possible safe
acceleration by calling another functional component
Look-safety-stop. This functional component looks ahead
25 seconds and returns the maximum allowable range of
acceleration. This component in turn calls another
functional component Look-safety-stop-smooth. This
component looks ahead for about 50 seconds to make
sure that the train would not have to decelerate sharply at
a later stage, by enforcing the upper functional
components to decelerate linearly if necessary.
Safety-velocity
Velocity-stop
Look-velocity-stop
Safety-stop
Safety-stop-main
Look-safety-stop.
Look-safety-stop-smooth
Fig 5. Safety-Stop
Input & Output of Safety-Stop Component:
Input: Velocity, Acceleration, Remaining Distance,
Critical distance and Stopping distance.
Output: Range of safe acceleration /deceleration.
Fig 6. Safety-velocity
5.4 Reach –Destination:
This component makes sure that the train reaches the
destination as quickly as possible and, stops at the
destination. It has three functional components.
The first one is Reach-destination-main. This component
calls two other functional components, Look-Stopdestination and Look-reach-destination, and composes
the result from the values returned by them. Look-Stopdestination looks ahead 10 seconds and returns the
maximum possible range of accelerations such that the
train would be able to stop safely at the destination.
Look-reach-destination looks ahead 10 seconds and
returns the maximum possible range of accelerations such
that the train moves as fast as possible along with the
condition that the rate of change of acceleration is within
a fixed limit.
Reach Destination
If Critical Distance is less than Stopping Distance then it
indicates that the safety requirement has been violated.
Reach-destination-main
5.3. Safety-Velocity:
This component ensures that the train always maintains a
velocity within the limit.
It has two functional components. The first functional
component, Velocity-stop, ensures that the train does not
exceed the maximum velocity. To make the journey
smooth, it also calls another functional component Lookvelocity-stop. This functional component looks ahead 5
seconds and returns the maximum possible range of
accelerations such that the velocity is lower than the
limit. This component thus serves the purpose of finding
the maximum possible acceleration such that the train
would not have to decelerate drastically later.
Input: Velocity, Acceleration, Remaining Distance,
Critical distance.
Look-Stopdestination
Look-reachdestination
Fig 7. Reach Destination
Reach-destination-main finds the maximum possible
range of accelerations common to the ranges returned by
Look-Stop-destination and Look-reach-destination. If
there are no values common to the values returned by
these two components, the range of Look-Stopdestination is returned.
Input: Velocity, Acceleration, Remaining Distance, and
critical distance, Stopping Distance
Output: Max possible range of accelerations.
Output: Max possible range of accelerations.
6
Control Module:
This component uses the components Safety-critical,
Safety-velocity and Reach destination.
It composes the acceleration ranges given by the three
components and finds a range common to all three of the
components. It then selects the middle of the range as the
acceleration that should be given as the input to the train.
It then passes this acceleration to the simulator, along
with the other parameters, gets the output from the
simulator (which simulates the train) and gives the new
values to the three components.
Fig 9 shows the first 300 readings of the acceleration Vs
time graph. It shows a gradual decrease in the
acceleration as the train comes closer to the maximum
allowed velocity. When the train reaches the maximum
possible velocity, the acceleration becomes zero.
Acce le ration Profile
1.2
1
Output: After every ½ second, Position, Velocity,
Acceleration, Critical distance, Remaining distance,
Stopping distance until the train stops.
0.8
Acceleration
Input: Initial values of Critical Distance, Remaining
Distance.
0.6
0.4
0.2
287
265
243
221
199
177
155
133
111
89
67
45
1
23
0
Simulation Results:
Tim e
We have plotted graphs to test our simulations.
The inputs were:
Critical Distance: 60 miles.
Destination Distance: 100 miles
Fig 9. First 300 Readings of the Acceleration Profile
Acceleration:
Fig 8 shows the acceleration Vs time-interval profile of
the journey.
Acceleration Profile
1.00E-01
Acceleration
1
0.6
5797
5314
4831
4348
3865
3382
2899
2416
1933
-7.00E-01
967
-6.00E-01
0
1450
Tim e
-0.4
-0.6
Fig 10. Last 200 readings of Acceleration Profile
-0.8
Tim e
Fig 8. Graph of Acceleration Profile
In the initial part of the journey, as the critical and
destination distances are large, the train accelerates as
smoothly and quickly as possible. It then reaches the
maximum allowable velocity and remains in coasting
(constant velocity) for most of the journey.
When it approaches the critical point, it decelerates
slowly until it stops before the critical point.
Fig 10 shows the last 200 time intervals of the journey.
The look-ahead of the Reach-Destination component
senses early that the train is nearing the destination point.
Thus it is able to start the deceleration early and come to
a stop smoothly before the critical point.
Velocity:
Fig 11 shows the velocity profile of the train. The
velocity initially increases linearly until it reaches the
limit. It is then constant for a long time. When the train
comes close to the destination it decelerates linearly until
it stops at the destination.
7
331
301
271
241
211
181
151
-4.00E-01
-5.00E-01
1
121
-3.00E-01
0.2
-0.2
91
-2.00E-01
0.4
484
Acceleration
0.8
61
1
-1.00E-01
1.2
31
0.00E+00
Acceleration Profile
Velocity vs TimeIntervals
[Har87] D. Harel, "Statecharts: A visual formalism for
complex systems," Sci. of Comput. Prog., Vol. 8, 1987,
pp. 231-274.
35
Velocity
30
25
20
[Har90] D. Harel, H. Lachover, A. Naamad, A. Pnueli,
M. Politi, R. Sherman, A. Shtull-Trauring, and M.
Trakhtenbrot, "Statemate: A working environment for the
development of complex reactive systems," IEEE Trans.
on Softw. Eng., Vol. 16, No. 4, Apr. 1990, pp. 403-414.
15
10
5
5527
4913
4299
3685
3071
2457
1843
615
1229
1
0
Time Intervals
Fig 11. Velocity Vs Time interval Graph
6.
Acknowledgment
This material is based in part upon work supported by the
National Science Foundation under grant No. CCR9803993.
8.
[Jac95a] D. Jackson, "Structuring Z specifications with
views," ACM trans. Softw. Eng. and Meth., Vol. 4, No. 4,
Oct. 1995, pp. 365-389.
[Jon83] C.B. Jones, "Tentative steps towards a
development method for interfering programs," ACM
Trans. Prog. Lang. ad Sys., Vol. 5, No. 4, Oct. 1983, pp.
596-619.
Summary
In this paper, we have developed an approach for
decomposing a complex system into a series of
increments consisting of relational components. This
approach allows the reliability and safety of the system to
be deduced from the corresponding properties of its
components. Since each component has a substantially
simpler state space than the overall system, the approach
reduces the effort needed in achieving high confidence in
the reliability and safety of the system. The approach
was illustrated in a high-level form using the Bay Area
Rapid Transit system case study.
7.
design," IEEE Trans. on Softw. Eng., Vol. 18,No. 1, Jan.
1992, pp. 9-18.
References
[Atk91] C. Atkinson, Object-Oriented Reuse,
Concurrency and Distribution, Addison-Wesley & ACM
Press, New York, NY, 1991.
[Kic97] G. Kiczales, J. Lamping, A. Mendhekar, C.
Maeda, C.V. Lopes, J.-M. Loigtier, J. Irwin, "AspectOriented Programming," Prof. European Cong. on
Object-Oriented Programming (ECOOP), Finland, June
1997.
[Lam94] S.S. Lam and A.U. Shankar, "A theory of
interfaces and modules: I --- Composition Theorem,"
IEEE Trans. on Softw. Eng., Vol. 20, No. 1, Jan. 1994,
pp. 55-71.
[Lev94] N.G. Leveson, M.P.E. Heimdahl, H. Hildreth,
and J.D. Reese, "Requirements specification for processcontrol systems," IEEE Trans. on Softw. Eng., Vol. 20,
No. 9, Sep. 1994, pp. 684-707.
[Rea97] Reasoning, Inc., Code-Base Management System
(CBMS), Mountain View, CA,1997.
[Win96] V.L. Winter and J.M. Boyle, "Proving
refinement transformations for deriving high-assurance
software," Proceedings of the IEEE High-Assurance
Systems Engineering Workshop, Oct. 1996.
[Win98] V.L. Winter, Private communication, July 1998.
[Bas99a] Farokh B. Bastani. “Relational Programs:
Architecture for Robust Process-Control Programs.” To
appear in Annals of Software Engineering.
[Bas99b] F.B. Bastani, V.L. Winter, and I.-L. Yen,
“Dependability of relational programs,” Proc. Of the
1999 IEEE Intl. Symp. On Software Reliability
Engineering, Boca Raton, FL, Nov. 1999.
[Win99] Victor Winter, Raymond Berg and Jim
Ringland. “Bay Area Rapid Transit District Advanced
automated Train Control System Case Study
Description”, 1999.
[Zav85] P. Zave, "A distributed alternative to FiniteState-Machine specifications," ACM Trans. on Prog.
Lang. and Sys., Vol. 7, No. 1, Jan. 1985, pp. 10-36.
[Col92] D. Coleman, F. Hayes, and S. Bear, "Introducing
Objectcharts or How to use Statecharts in object-oriented
8