A Relational Program Architecture For

The Bay Area Rapid Transit System

F.B. Bastani, V. Reddy, P. Srigiriraju, and I.-L. YenDepartment of Computer Science

University of Texas at DallasM/S EC-31, P.O.Box 830688Richardson, 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 Aspect-Oriented 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

1

inheriting one functional component and one behavioral 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. 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.

2. 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

of the second train. (The first train is ahead of the second second train.)

3. 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.

4. 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.

5. 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 on-board control system.

4. Requirements Decomposition:

The system is decomposed into Safety-Stop, Safety-Speed, Smoothness and Reach Destination or Time Optimization components.

4

SafetyStop

SafetySpeed

Time Optimization

S(t) C(t) V(t) Vmax S(t) y(t)

A1 = a11 .. a12 A2 = a21 .. a22

A3 = a31 .. a32

Smoothness

A4 = a41 .. a42

S(t+) C(t+)

Figure 1. Requirements Decomposition

4.1. Safety-Stop:

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.

4.2. Safety-Speed:

This component ensures that the maximum speed of the train is well within the limits.

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.

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:

We have written the code for the simulation in JAVA 1.1.

5.1. Simulator:

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:

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.

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

C(t) > s(t)

C(t) = s(t)

C(t) < s(t)

Fig. 2. Safety-Stop

V(t) < Vmax

V(t) = Vmax V(t) >

Vmax

Fig. 3. Safety-Speed

Fig 4. Simulation Environment

Simulator

Simulator

Control Module

Safety-stop

Safety- velocity

Reach-destination

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.

Input & Output of Safety-Stop Component:

Input: Velocity, Acceleration, Remaining Distance, Critical distance and Stopping distance.Output: Range of safe acceleration /deceleration.

If Critical Distance is less than Stopping Distance then it indicates that the safety requirement has been violated.

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 Look-velocity-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.

Output: Max possible range of accelerations.

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-Stop-destination and Look-reach-destination, and composes the result from the values returned by them. Look-Stop-destination 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-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-Stop-destination is returned.

Input: Velocity, Acceleration, Remaining Distance, and critical distance, Stopping Distance

Output: Max possible range of accelerations.

6

Safety-stop-main

Look-safety-stop.

Look-safety-stop-smooth

Fig 5. Safety-Stop

Safety-stop

Fig 6. Safety-velocity

Velocity-stop

Look-velocity-stop

Safety-velocity

Reach-destination-main

Look-Stop-destination

Look-reach-destination

Fig 7. Reach Destination

Reach Destination

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.

Input: Initial values of Critical Distance, Remaining Distance.

Output: After every ½ second, Position, Velocity, Acceleration, Critical distance, Remaining distance, Stopping distance until the train stops.

Simulation Results:

We have plotted graphs to test our simulations. The inputs were:Critical Distance: 60 miles.Destination Distance: 100 miles

Acceleration:

Fig 8 shows the acceleration Vs time-interval profile of the journey.

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 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.

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

Acceleration Profile

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

1.2

1

484

967

1450

1933

2416

2899

3382

3865

4348

4831

5314

5797

Time

Acc

eler

atio

n

Fig 8. Graph of Acceleration Profile

Acceleration Profile

0

0.2

0.4

0.6

0.8

1

1.2

1 23 45 67 89 111

133

155

177

199

221

243

265

287

Time

Acc

eler

atio

nFig 9. First 300 Readings of the Acceleration Profile

Acceleration Profile

-7.00E-01

-6.00E-01

-5.00E-01

-4.00E-01

-3.00E-01

-2.00E-01

-1.00E-01

0.00E+00

1.00E-01

1 31 61 91 121

151

181

211

241

271

301

331

Time

Acc

eler

atio

n

Fig 10. Last 200 readings of Acceleration Profile

6. 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. Acknowledgment

This material is based in part upon work supported by the National Science Foundation under grant No. CCR-9803993.

8. References

[Atk91] C. Atkinson, Object-Oriented Reuse, Concurrency and Distribution, Addison-Wesley & ACM Press, New York, NY, 1991.

[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.

[Col92] D. Coleman, F. Hayes, and S. Bear, "Introducing Objectcharts or How to use Statecharts in object-oriented

design," IEEE Trans. on Softw. Eng., Vol. 18,No. 1, Jan. 1992, pp. 9-18.

[Har87] D. Harel, "Statecharts: A visual formalism for complex systems," Sci. of Comput. Prog., Vol. 8, 1987, pp. 231-274.

[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.

[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.

[Kic97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C.V. Lopes, J.-M. Loigtier, J. Irwin, "Aspect-Oriented 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 process-control 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.

[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 Finite-State-Machine specifications," ACM Trans. on Prog. Lang. and Sys., Vol. 7, No. 1, Jan. 1985, pp. 10-36.

8

Velocity vs TimeIntervals

05

101520253035

1

615

1229

1843

2457

3071

3685

4299

4913

5527

Time Intervals

Velo

city

Fig 11. Velocity Vs Time interval Graph