[ITS UWLogo]

ITS Research Program, UW

Smart Trek: Transit Watch

[Menu Bar]

The Transit Watch System was created by the ITS Research Program at the UW for King County Metro Transit as part of the Smart Trek project. This project deploys an APTS/ATIS that displays transit vehicle arrival predictions at transit facilities. The goal of the project is to promote the use of transit by reducing the stress inherent in transfers.

To date, Metro has installed computers at the Northgate and Bellevue Transit Centers where Transit Watch has been available to bus riders since July 1998. Transit Watch, as part of the Smart Trek Project, presently supports the following locations. These links provide sample screen shots of the applet. New locations are coming soon!

[Blue Line]

Software Design

Transit Watch, as implemented in Smart Trek, supports five sites (see above) but is designed to be able to support a large number of sites. The Transit Watch design has four main components: (1) the prediction server (Predictor), (2) data distribution server (TWServer), (3) the client display applet (TransitWatch), and (4) a database. These components interact over a network and use the database to serialize the sharing of data. The entire system is built in the object-oriented Java language.

The first component, the Predictor, actually performs the arrival time prediction. There is one Predictor for each location for which Transit Watch provides an arrival prediction. Each Predictor receives the AVL data stream from the ITS Information Backbone and filters it for active trips. Active trips are the bus service trips scheduled to depart the prediction site in a time window around "now." For the Metro deployment, active trips are defined to be the buses scheduled to depart in the next 30 minutes and those that have left in the last 20 minutes (this time period is configurable). When a trip is marked as active, the Predictor creates a TripTracker object for that trip. The AVL data for each active trip is passed to the TripTracker associated with that trip (a single bus). The TripTracker uses a tracking algorithm to combine the current position of the bus with historical data about the trip to predict the arrival time. When new data about a tracked bus arrives, the TripTracker updates a central database with these predictions.

The second component is labeled TWServer, in the design diagram. The TWServer creates a Querier object for each Transit Watch deployment site (e.g., Northgate, Bellevue). The Querier object is responsible for querying the database for relevant data. Like the Predictor, the Querier object uses the notion of active trips to select relevant data to be displayed. The TWServer component also accepts connections from Transit Watch applets and creates a DataServer object for each client. DataServer objects take the latest data from their Querier and send them to the TransitWatch client. The TWServer component supports multiple Transit Watch client displays for a site by creating one DataServer per client. This design makes it possible to have many displays for each of the supported sites, and these displays can reside anywhere on the Internet.

The third component is the database in which the predictions of arrival, the history of all tracked trips, and the configuration of the overall system (e.g., time windows, logging, static schedule information, locations being serviced, messages to be displayed) are stored. Using the central database, each server need store only temporary data and any permanent data is committed to the database. Because all permanent data and configuration are stored in the database, there is a central point to backup the system. This backup provides a clear and complete recovery path for any equipment or software failures.

The Transit Watch design is that of a distributed system which can be scaled up by moving the components onto several computers. This is accomplished by distributing the database, TWServer, and the Predictors. The only constraint is that the TWServer be on the same computer as the web server that serves the Transit Watch client. This is a constraint imposed by the Java applet security model.

As with any large system, monitoring is an important activity. The Predictor components and the TWServer component record error conditions to a log file. These files are then automatically examined by a separate program, LogReader.pl, that notifies operators of errors by email. A graphical database-monitoring tool, TranistWatchMonitor, checks that a prediction update has been made in the past five minutes and it provides immediate aural and visual notification to operators.

To facilitate post mortem verification of correct operation (e.g., accurate predictions and correct operation), the database contains records of the various components' activities. The TripTracker objects record all the received AVL data, as well as the resulting predictions. All data sent to a TransitWatch client are recorded by the TWServer component. These tables are automatically pruned on a periodic basis to keep the logs from growing too large.

To allow multiple agencies to access the history of all data displayed on Transit Watch, a password protected CGI script has been created. In addition, an HTML form, using a CGI script, has been developed to change the messages displayed at the bottom of a TransitWatch client. These last two mechanisms facilitate multi-agency management and evaluation of Transit Watch.


[Blue Line]

ITS UW Home | Contact Page | People | Projects | Publications | Software | Applications | Job Openings | Other ITS Sites
(September 30, 1999)