Illustration of software architecture

Figure 1: High-level illustration of the architecture of our software (click for a larger view).

Client-server architecture

The system is entirely web-based and can be run from anywhere in the world — but only authorized users can sign in.

The bus client is a web page that transmits GPS coordinates and other local bus information to the server. When viewed by a web browser on a mobile device, the client displays messages to the driver and/or passengers.

The bus server is a collection of PHP scripts that execute on the web server. Mostly they read the stream of bus reports from the client buses and react. They may also read requests from a manager to display performance reports.

Bus control

A basic design principle of our system is to assume nothing. Instead, the software watches the stream of reports from buses, infers what is happening and then determines what to do to help. This means our system continues to function even when there are changes in the numbers of passengers, numbers or sequence of buses, or even the route traveled by the buses.

One of most important tasks of the server is to recognize when to issue instructions to a bus. Here is a typical sequence of decisions to support that.

Recognize when a bus arrives at a checkpoint

A checkpoint is any point at which we might ask the bus to pause or send information to the bus. There can be as many or as few as makes sense. We recommend using as few checkpoints as practical so that the system is independent of any road map of the route.

Identify the next Bus

Once a bus is determined to have arrived at a checkpoint, the system, which has been monitoring the movement of buses, figures out which bus is immediately behind.

Estimate the time until the next Bus

Our system tracks historical transit times and uses this information to predict arrival of the following bus.

Compute the appropriate wait-time

This is essentially the computation described in the theoretical paper: The proposed wait-time is set to a certain fraction of the predicted time until the next bus arrival. However, we may adjust this result in any of several ways, to accomplish secondary objectives, such as when it is necessary to guarantee the driver a certain minimum time at the checkpoint.

Recognize when the bus departs from a checkpoint

If sufficiently many consecutive location reports fall outside a geofence, the system concludes that the bus is no longer within that geofence.

Management tools

The bus server saves copies of all communications to assist in evaluating system performance. This enables our system to serve a wide range of reports over the web, including:

Development tools

Development tools include a simulator with which to test the system by feeding it synthetic geolocation reports just as if they had been generated by actual buses. An analyst can then watch how the server responds in different scenarios.


In addition to coördinating buses, our system helps manage drivers and tablets. It also supports the display of useful information during transit, such as events or transit connections at upcoming stops. And we are working on software to accomplish other tasks, such as counting passengers or monitoring performance of the diesel engine.


What are the software requirements?
All standard, plain-vanilla, open-source tools: The bus server can be any web server that supports PHP and MySQL. The bus client can be any modern browser running on almost any mobile device.
What libraries are required?
All open source with very generous licenses
How do you update software on the tablets?
Almost all of the software is on the server and so there is only one copy to maintain and changes can be rolled out instantly. Of the little configuration necessary on the tablet, most can be done remotely.
What sort of hardware is required?
On board the bus: Any modern mobile device with GPS and cellular or wifi connection.
How accurate do the GPS readings have to be?
Not very: Our system relies on GPS readings only at the checkpoints, where the buses pause and so accuracy is better.
But what if GPS readings are very inaccurate, for example because of interference from tall buildings?
Our software can use other types of positional information, such as that obtainable from Bluetooth or wifi beacons.