Foggy Bottom Transit Authority:
a Model Rapid Transportation System with Ada 95 Software Control

Michael B. Feldman
Alden A. Dima
Yair Rajwan

Department of Computer Science
The George Washington University
Washington, D. C. 20052

(202) 994-5919 (voice)
(202) 994-0227 (fax)
mfeldman@seas.gwu.edu
http://www.seas.gwu.edu/faculty/mfeldman

This work is supported in part by AJPO contract #F29601-93-K-0215.

This paper appeared in
Proceedings of the Tenth Annual Ada Software Engineering and Training Symposium (ASEET),
Prescott, AZ, June 1996.

Introduction
Why Metrorail
The FoBTA Model
Phased Implementation
The Real-Time Systems Course
Other Related Student Projects
References

Introduction

Foggy Bottom Transit Authority (FoBTA) is a computer-controlled HO-scale model of an urban rapid transportation system based loosely on Metrorail, the rapid rail network of Washington, D.C. and its suburbs in Maryland and Virginia. The name Foggy Bottom refers to the neighborhood in which The George Washington University is located, near the Potomac River and midway between the White House and Watergate. The area is low-lying and was originally swampy, hence the name Foggy Bottom.

FoBTA models a part of the Metrorail system using off-the-shelf HO model railroad equipment and some additional electronic parts, along with a computer running the GNU Ada 95 compiler (GNAT) under the Linux operating system. This project was inspired by the successful work of John McCormick and his students [McCormick 92]. Our work differs mainly in that we are modeling a rapid transit system instead of a conventional freight railroad.

Associated with the Metrorail model is a new upper-level real-time systems course.

Why Metrorail?

Metrorail was conceived in the 1960s and designed as a 100-route-mile, state-of-the-art urban rail system. Its first 4-mile segment opened twenty years ago and its final segments are scheduled for opening in the next five years or so. Currently, roughly 80 miles--divided between tunnel segments in the central city and open-air lines in the outlying areas--and 70 stations are in service. Figure 1 shows the Metrorail route map.

Figure 1. Metrorail Route Map

Metrorail carries some 500,000 passengers per day, which makes it the second-busiest urban rail system in the U.S., after New York. Passengers are carried in several hundred cars, running at up to 65 mph in trains of up to eight cars. There are no locomotives; all cars are powered by 600 volt DC current, drawn from a third rail mounted alongside the running rails.

Metrorail is an interesting system for us to model because

The FoBTA Model

The FoBTA model is an HO-scale model of a part of the Metrorail system. HO is probably the most popular standard scale used in railroad modeling. Track, trains, power supplies, and so forth are readily available off the shelf; equipment from different manufacturers is generaly interoperable. HO is 1/87 scale: One foot in the model represents 87 feet in real life. The distance between the track rails--56.5" in real life--is about 5/8" in the model; a model of an 85-foot passenger car is just under a foot long. We were pleased to discover that one of the major manufacturers, Walthers, makes a faithful HO-scale model of the Metrorail passenger cars. These plastic cars come in kit form, so each one must be assembled with simple tools and model cement.

HO-scale equipment is solid and of manageable size; on the other hand, a true scale model of a 20-mile Metrorail line would require nearly 1/4 mile of model track. This would require laboratory space well beyond reasonable expectation in an urban university! We have therefore decided to construct a model loosely based on the topology of a section of Metrorail, namely, the Blue Line/Orange Line pair. As can be seen in the route map of Figure 1, Blue and Orange share common trackage in the central area, and each line follows its own eastern and western branches out to their respective endpoints.

A scale drawing of our model is shown in Figure 2. As can be seen in the figure, the critical points in the model--stations, junctions, and crossovers--are reasonably faithful to those in the actual system.

The model is a shortened version of the real Blue/Orange pair, bent into a U shape to fit into the available laboratory space. Each ruled square on the figure represents a 4-foot by 4-foot plywood table; the tables are bolted together to make a stable layout. Each line is roughly 36 feet from end to end. The layout was designed using a model railroad CAD package for Windows called Right Track Software.

Figure 2. Foggy Bottom Transit Authority Model

Phased Implementation

We are constructing this model in three phases.

Phase 0: Manual Hardware, Software Simulations

In this phase, the rail system model is not connected to the computer, but rather operated manually with standard HO controllers. The purpose of this phase is to familiarize us all with the performance of the trains themselves, while we experiment with Ada 95 software simulations of rail transit systems.

As part of this early prototyping, we discovered that the model Metrorail cars were not powerful enough to climb the abnormally steep grades in our first design. These grades were needed to allow a "fork" (where two lines split from the central trunk) to be implemented with bridges--as the real Metrorail is--to avoid having one track physically intersect another. The grades were very steep because of our short distances between stations. The situation caused a redesign to eliminate the grades altogether. The resulting intersections are less realistic, but actually make the system more interesting because they provide additional critical points requiring physical mutual exclusion.

Phase 1: Smart Tracks, Dumb Trains

Our next phase, which we are constructing at this writing, connects the train layout to the computer via sensors between the rails at critical points. A train passing over a sensor sends an interrupt to the computer. We call this the "smart tracks, dumb trains" model because trains are allowed in, or barred from, track segments simply by turning power to that segment on or off. This is a relatively simple model, requiring no special hardware on the trains beyond a simple device to trigger the sensors.

Phase 2: Smart Trains, Dumb Tracks

In a real rapid transit system, the power rail ("third rail") is continuously energized; it is simply not feasible to switch 600 volt DC current on and off from one track segment to another. Our Phase 1 design is therefore not very realistic, and our long range plan is to build a "smart trains, dumb tracks" model. In this model, each train will carry on-board digital hardware capable of sending and receiving a simple set of signals and controlling the power drawn from the tracks. HO-scale digital control is an emerging technology. Possibly we will be able to buy the on-board hardware ready-made; another approach is to task our computer engineering students with designing and building the hardware.

The Real-Time Systems Course

Computer Science 190, Real-Time Computer Systems, has been offered for the first time during the Spring 1996 semester. This course is intended for seniors and can also be taken for graduate credit. The students are assumed to know sequential Ada, which is taught in our introductory courses. In the Spring 1996 class, the students--half undergraduates, half grad students--knew very little of the Ada 95 extensions, having studied Ada 83 several years ago.

We chose the recent book by Burns and Wellings, Concurrency in Ada [Burns 95], as the main text of the course. This book focuses on Ada 95 concurrency, with some attention in later chapters to the relationship of tasks and protected types to tagged types, and to real-time programming. We supplemented Burns and Wellings with selected chapters from Software Construction and Data Structures with Ada 95 [Feldman 96].

Lectures

Because the metro model itself was still under construction, this first run of the course relied entirely on software simulation. Students were given the files from the Feldman book, and a discussion on tasking and protected types based on the completely coded Dining Philosophers and Bank Simulation examples in Chapter 15 of that book. Those examples show concurrency as a modeling technique, using task objects to simulate animate ones (bank tellers and customers, philosophers) and protected objects to simulate inanimate ones (bank database, chopsticks). The task and protected object interfaces are exposed in package interfaces, so that the active and passive objects communicate directly with one another. Students were encouraged to reuse ideas and code from the examples.

Most of the course lectures focused on the Burns/Wellings material, along with special topics such as rate-monotonic scheduling. We also took a "field trip," riding the Metrorail system from Foggy Bottom to Van Dorn Street and back, to observe the operation and the overall track structure. Metrorail management is rather closed to discussion of its control systems with outsiders--especially since a control-related fatal crash in January. We were fortunate, however, in meeting a train operator who was riding home from his work shift and took much time and effort in chatting with us about the control system as he perceived it.

Student Projects

Essentially the only graded work in the course consisted of a project. The only requirement was that the project had to focus on a Metrorail simulation. Students designed their own projects, proposed them publicly in class, and demonstrated them at the end of the semester. Team work was optional; we had two 2-person teams and ten "solo practitioners."

Because this was the first run of the course, we were curious as to what the students would come up with if left on their own as to design methods, documentation, and so on, and therefore we did not specify any of this. Some students were also taking the software engineering course, or had workplace experience, and used reasonably formal OOD methods; others invented their own diagrams and other designs. It was very interesting to observe the different styles and approaches.

All projects were implemented using GNAT; most students used the Solaris version on the engineering school server; a few chose to use their home PCs running Linux. We suggested to the students that they try to find simple ways of displaying the state of the simulation. We advised them that trying to use graphics packages to produce elaborate high-resolution displays would probably distract them from the important part of the work, namely, developing a clear model of the system and getting it to run correctly. Most of the students opted to use the simple 24 x 80 ANSI-terminal window manager presented in the Feldman book. That window manager is not concurrency-safe, though, as some discovered when they tried to use it verbatim and produced screens filled with random characters. Naturally they added the necessary mutual exclusion to solve their problem.

One team's window-manager-based display is shown in Figure 3. The upper window gives a simplified Blue/Orange map, indicating individual trains by their 1-digit identifying codes. A dynamic trace of the progress of four trains is given in the four lower windows. This ANSI-terminal display is obviously rather primitive, but a surprising amount of information can be displayed, and the display has the virtues of simplicity and complete portability.

This team developed their project on the Solaris server; after the code was turned in, we downloaded it to a PC and compiled it with the then-new GNAT 3.04 for DOS, the first GNAT DOS release to support tasking. The program compiled and ran the first time! We have since compiled and run the program without change using GNAT under MachTen on a Power Macintosh.

Figure 3. Typical Student Project Display

   5    o   Vienna                       New Carrolton    6    o
   |    |    ^                                       |    |    |
   |    o    |  METRO SYSTEM: ORANGE & BLUE LINES    |    2    |
   5    |    |                                       \/   |    o  ^
   |    o                    <-----                       2    |  |
   |    |                                                 |    |  |
   o    +--o--X-----o---o---o---o---o---o---o---o----+-o--+    o
   |          o                                      |         |
   +------o---+---+-o---o---o---o---o---o---o---oX-o-+----o----+
              o   3                              o   o
     ---->    |   |          ----->              |   o    ---->
              o   3                              o   4
          |   |   |    ^                     |   |   |   ^
          |   o   3    |                     |   o   4   |
   Add Rd \/  o   7    |            VanDorn  \/  o   8   |
  +-----------------++-----------------++-----------------++-----------------+
  |Train 5 @CP# 610 ||Train Resumed520 ||Train 3 @CP# 40 S||Train Resumed    |
  |SSpd 25 RSpd 26  ||Accel To:25      ||Spd 35 RSpd 36   ||Accel To:25      |
  |Adj Speed To 25  ||Adj Speed To 35  ||Adj Speed To 35  ||Adj Speed To 35  |
  |                 ||Got Zone:27  Got ||Got Zone:3       ||Got Zone:12  Got |
  |                 ||Zone:26          ||Rel Zone:2       ||Zone:11          |
  +-----------------++-----------------++-----------------++-----------------+

Other Related Student Projects

In addition to the students in the real-time course, two others worked on related projects. One was a graduate student pursuing an independent directed-research project in real-time software; the other a senior in the two-semester senior project course. The latter course is the capstone course in our computer science and computer engineering curricula. Students design their projects--hardware, software, or both--in the fall and implement them in the spring. Most students work in teams, though individual projects are permitted. The course is characterized by the requirement to produce cost analyses, and--at the usual life-cycle milestones--"industrial-strength" documents and public design reviews.

References

[Burns 95] Burns, A., and A. Wellings, Concurrency in Ada. Cambridge University Press, 1995. (ISBN 0-521-41471-7)

[Feldman 96] Feldman, M. B., Software Construction and Data Structures in Ada 95. Addison Wesley, 1996. (ISBN 0-201-88795-9)

[McCormick 92] McCormick, J. W., "A Model Railroad for Ada and Software Engineering," Communications of the ACM, November 1992, p. 68-70.