In 1958, engineers with the London Transport Executive made the following observations:
Without an overall picture of the location of the buses on a route it is difficult to prescribe what remedial measures are suitable; moreover, such measures may have serious repercussions, since bus crews must be relieved at stated periods, either for meals or at the end of their normal turn of duty, and it is essential that the crews running these reliefs correspond to the garage at which the bus ends its schedule.
There are two other points in the operation of buses which require a constant check. The first is the practice of certain drivers giving their conductors a light run. If a driver on a normal 2 min headway speeds up in the early part of his run, so that he is ½ min before schedule, the bus will average only three-quarters of its normal load and the conductor's work is eased. The following bus, if keeping schedule, will collect some 25% more than its normal quota, and since the time at each stop will be greater, it will become more and more delayed and overloaded. The second point is the passenger who complains that he had an excessive wait for his normal bus on a wet evening. It is most desirable that facts regarding the allegations are available before action is taken.
The solution then was BESI, the bus electronic scanning indicator. BESI was an ingenious solution which used reflectorized plates on buses in combination with scanning heads mounted at particular intersections. By the 1970s, BESI was used routinely (as depicted in this film) by London Transport to improve service regulation. Yet as ingenious as it was, the technology was still crude; it couldn't track a bus on a detour, nor could it relay ancillary information (like passenger loading or mechanical status) along with the position of the bus.
53 years later, the problem hasn't changed much, but the technology absolutely has. The de-activation of Selective Availability combined with the development of smaller, cheaper, and more reliable GPS receivers means that GPS is now the first choice for positioning information. Unlike cumbersome beacon-and-odometer schemes which were prevalent in the 1980s and 1990s, using GPS for AVL requires no fixed infrastructure, and works wherever the bus may go—even off-route. Modern systems also put a lot more intelligence on-board the bus; today it is not unusual for an AVL system to report data from the engine control unit, automatic passenger counters, the farebox, and other bus equipment. In some cases, these systems report data over inexpensive commercial cellular links, while in other cases they tie into an agency's existing trunking radio system.
The point of all of this, then, is that it does not matter how large or how small your transit agency is; there are substantial operational benefits to AVL. The technology has matured to the point that there is simply no excuse for a transit authority to not have an AVL system for its bus fleet. Early schemes like BESI, or beacon-and-odometer systems, were expensive, cumbersome, and had substantial drawbacks. But modern AVL systems are easy to deploy, considerably more reliable, and considerably more flexible. If you're still waiting for the technology to mature, now is the time to act; AVL is no longer just something that would be 'nice to have', but rather a necessity for any bus fleet today.
If you are using AVL for dispatching, but you don't make the information available to passengers, now is the time to do so. In 2011, passengers expect smartphone apps and live displays in bus stops; developers expect an open-standard API.
If the best you can do today is a 1980s-era IVR system, or a box on your Web site that only works in desktop browsers, then you can probably do better.
If you have AVL data available, but not the means for dissemination, then consider an open stack using open-source software like OneBusAway. You may have to modify OneBusAway to consume the data produced by your AVL system, if it does not have an open interface, but in all likelihood, the effort involved in doing so will still pale in comparison to the cost of a commercial real-time passenger information system.
At the same time, you should press your AVL vendor to make greater use of open formats; a few, like INIT, use SIRI, the open standard for real-time passenger information. Many others offer a proprietary XML API, or none at all.
Some transit agencies will surely complain about the cost of deploying an AVL system, or upgrading an existing system to provide information directly to passengers, but those agencies fail to recognize the substantial benefits of an AVL system.
Knowing precisely when the bus will come increases passenger confidence—and when passengers have more confidence in the transit system, they're far more likely to use it. A passenger who has no idea when the bus will come may, after a few minutes' wait, abandon the bus and drive, or take a taxi. The transit agency loses a passenger, and the passenger has lost time. When a transit agency loses a passenger, particularly a discretionary rider, it may take years to regain their trust and get them to try transit again.
Even more importantly, emerging real-time trip planning solutions are able to offer riders trip plans which are based on the actual status of a transit system at the moment they plan their trip; such systems can automatically offer riders an alternative to a late-running route, for example, and adapt to traffic conditions, detours, and service suspensions in real-time, as they happen.
There are operational benefits for dispatchers and supervisors, too; while it's impossible to completely eradicate late running, an AVL system can provide the data necessary to make well-informed decisions, without having to call individual bus operators and ask them where they are along their route. With AVL data available, bus dispatchers can see every bus on the line at once, and deleterious conditions like bunching can be rectified quickly. Statistics like on-time-performance can be calculated and displayed in real-time, providing for more informed decision-making processes. Supervisors at terminals, and on the street, who previously could only see a fraction of the operation at once, can now make use of mobile devices to get the same information as their counterparts in the control center.
It will never be perfectly easy to deploy an AVL system; particularly for large fleets, the costs can be substantial. Bus operators may chafe at what they perceive as a new level of monitoring, and garages may complain about the increased equipment maintenance burden. But once the start-up hurdles are resolved, the end result is a smoother, more efficient operation, with benefits for passengers and the transit agency alike.