What a CAD/AVL system actually does

CAD/AVL, computer-aided dispatch and automatic vehicle location, is the system a transit agency uses to know where every vehicle is and to direct the people driving them. On the bus it is a box behind the dashboard that reports the vehicle’s position over a data radio. In the control room it is a console that shows every vehicle against its schedule and puts the ones in trouble at the top of a list. The arrival time on the app, the countdown on the shelter sign and the agency’s own punctuality report are all downstream of it, and almost everything written about it is written by the companies selling it.

The two halves of the acronym

The two halves were separate products before they were one. Automatic vehicle location is the older idea, and the national architecture still treats it as its own thing. The US reference architecture for intelligent transportation systems gives it a service package of its own, PT01 Transit Vehicle Tracking, which “monitors current transit vehicle location using an Automated Vehicle Location System” and notes that the location data “may be used to determine real-time schedule adherence and update the transit system’s schedule in real-time.”

Computer-aided dispatch is the next package over, PT02 Transit Fixed-Route Operations, which “performs automated dispatch and system monitoring,” covers “the creation of schedules, blocks and runs, as well as operator assignment,” and “monitors the transit vehicle trip performance against the schedule and provides information displays at the Transit Management Center.”

Read those two together and the division of labor is clear enough: AVL answers where a vehicle is, and CAD answers what to do about it. In practice they are bought together, because the dispatch console is worthless without live positions and the positions are just dots until there is a schedule to compare them against.

The onboard half is usually one enclosure under or behind the dashboard, with a positioning receiver, a cellular modem, a small screen and keypad for the operator, and a wiring harness that reaches the door sensors, the destination sign, the announcement speakers, the fare device, and in many fleets the passenger counters over the doors. Agencies call it the mobile data terminal or the vehicle logic unit. What it connects to matters as much as what it tracks, because an agency that wants announcements, sign updates and passenger counts tied to the same trip has to route all of them through that one enclosure.

What a location report actually carries

The message leaving the vehicle is short. The one the public sees is shorter still, because it has been translated into GTFS-Realtime, the format almost every US agency uses to hand its positions to app developers. In the VehiclePosition message, every field except the entity’s identity is optional, so what an agency publishes is a decent proxy for what its CAD/AVL system collects and is willing to share.

A typical report, from SEPTA on the morning of September 18, 2026: bus 3756 on route 1, at a latitude and longitude, heading northeast, working toward stop 27418 on trip 868478, with many seats available, its position measured 36 seconds earlier. Across the 61 publicly available US bus feeds in MobilityData’s Mobility Database that we read that day, carrying 7,853 vehicles, this is how often each field appeared.

Field	Bus feeds using it	Share of vehicles
Vehicle id	61 of 61	100%
Position (latitude and longitude)	61 of 61	100%
Timestamp of the position	61 of 61	96%
Trip assignment	61 of 61	91%
Bearing	57 of 61	76%
Speed	55 of 61	49%
Vehicle label	51 of 61	78%
Occupancy status	41 of 61	41%
Stop id	38 of 61	58%
Current stop sequence	33 of 61	52%
Schedule relationship	28 of 61	30%
Current status, set explicitly	25 of 61	39%
Occupancy percentage	10 of 61	17%
Congestion level	7 of 61	3%
Odometer	6 of 61	12%
License plate	1 of 61	1%
Wheelchair accessibility	0 of 61	0%

That table is the answer to what a location report contains. Identity, place, time and trip are in every feed, and heading is in all but four. Everything below that line is something the agency decided to publish, and most of them decided not to.

Look twice at two of those rows. Occupancy, the field that tells a rider whether there is room on the bus, is present in two thirds of feeds but on fewer than half of vehicles, because agencies that have passenger counters on part of the fleet publish occupancy for part of the fleet. Congestion level, which was meant to let a vehicle report the traffic it is sitting in, has effectively not been adopted: seven feeds carry it at all. Where anyone needs that number, it is easier to derive it from the position history than to ask the bus for it.

The two fields at the bottom of the table are absent for opposite reasons. A license plate is a specific, public identifier of a specific vehicle, and one agency in 61 chose to publish it. Wheelchair accessibility is missing because it is already answered elsewhere: GTFS has a wheelchair_accessible field at the trip level in the schedule feed, so the realtime message has nothing to add unless the lift on a particular bus has failed.

How old the position is when you get it

Cadence is where the change of the last two decades shows up. The reference point is TCRP Synthesis 73, AVL Systems for Bus Transit: Update, published by the Transportation Research Board in 2008. Its survey went to 107 transit agencies and 32 answered. Question 15 asked at what interval location reports were received from any particular vehicle. The average answer was 95 seconds. The shortest was 15 seconds, the longest was 300, and the most common single answer was 120 seconds, given by 11 of the responding agencies. The report notes that a long regular polling interval was typically supplemented by exception reports, sent when a bus crossed a schedule-deviation threshold.

Today’s feeds answer a slightly different question, how old the newest report for each vehicle is when the feed is built, which puts a floor under the reporting interval. Setting aside one feed that served the same frozen message for four minutes, the middle bus feed was publishing positions 7 seconds old. Freshness was under 15 seconds in 46 of the 60 remaining feeds and under 30 seconds in 57 of them. The slowest was serving positions 35 seconds old, which in 2008 would have been at the fast end of what anyone reported.

The closer analog to the 2008 question is how many vehicles get a new measurement within a given window. In the median bus feed, 98 percent of vehicles had a new position timestamp within 45 seconds, and 44 of the 51 feeds we could check renewed at least 90 percent. Whatever the interval is on those fleets, it is comfortably under three quarters of a minute.

A vehicle position without a position

The rail feeds we set aside make a useful point about what the acronym covers. All seven New York City subway feeds and the Staten Island Railway feed carry no latitude or longitude whatsoever, while the Long Island Rail Road feed from the same agency carries one on every train. A subway train entity is a trip identifier, a stop id, a stop sequence, a status of stopped at or in transit to, and a timestamp. Here is a complete A train, exactly as the feed served it:

id: "000002A"
vehicle {
  trip { trip_id: "047000_A..N82R"  start_time: "07:50:15"
         start_date: "20260918"  route_id: "A" }
  current_stop_sequence: 32
  current_status: STOPPED_AT
  timestamp: 1789738722
  stop_id: "A07N"
}

That is not a gap in the feed. A satellite receiver is useless in a tunnel, so an underground railroad locates its trains by where they are in the signal system rather than by coordinate, and the feed reports the result the same way: this train is stopped at this platform, which is the answer a subway rider wants in any case. Bus CAD/AVL and rail train tracking publish into the same message format and are different systems doing different jobs, which is worth remembering before comparing a subway feed to a bus feed on anything.

What the dispatcher is looking at

The console is the part nobody outside the control room ever sees. It is a map of the service area with every vehicle on it, and next to the map a list, sorted by how much trouble each vehicle is in. Trouble means deviation from the schedule, and deviation is computed at timepoints, the subset of stops where the schedule publishes a specific time rather than a passing estimate.

Each agency sets its own definition of late, and the software enforces whichever one it was given. The Rhode Island Public Transit Authority’s service guidelines, published January 2025, put it plainly: RIPTA “measures on-time performance at each timepoint on a route, with on-time defined as no more than one minute early and no more than five minutes late,” and sets a goal that 80 percent of service departs each timepoint inside that window. The asymmetry is deliberate, and RIPTA gives the reason: early service “often impacts passengers more than late departures as the wait for the next bus is almost always longer than the short hold time.” A rider who arrives on time and finds the bus already gone waits a full headway.

The guidelines also describe the operational consequence, which is the clearest statement we found of what CAD/AVL is for: buses running early “hold at timepoints until a scheduled departure time, while those that are running on-time or late operate straight through.” The system computes the deviation, the number appears on the operator’s display, and the bus sits at the curb. No dispatcher has to be involved at all.

Measuring any of this used to mean sending people out to stand at timepoints with clipboards, and agencies were often wrong about their own performance until the location data arrived. Among the open-ended answers TCRP collected in 2008 about what changed after implementation, one agency reported simply: “Before implementation, we believed that our on-time performance was much better than what the system is telling us.”

The definition is not settled even now. San Francisco’s Muni has taken its on-time performance report offline entirely, saying that two new reports are in development that “will more accurately reflect the blend of on-time performance and headway adherence that better reflect rider experience.” On a route where a bus comes every six minutes, schedule adherence is close to meaningless and the thing worth measuring is whether the buses are evenly spaced. RIPTA’s guidelines already make that split explicit, measuring its rapid routes on bunching and gapping instead, with bunched defined as less than two minutes between buses.

When a bus leaves the route

The other half of dispatch is exceptions. A fixed-route bus is supposed to trace a known shape, and the CAD/AVL system holds that shape, so a vehicle that is not on it is a detectable event rather than something a dispatcher has to notice. Off-route detection, schedule-deviation alarms above a threshold, missed trips, and the silent alarm an operator can trigger from the keypad are all the same mechanism: a condition evaluated onboard or at the server, and an entry that appears at the top of somebody’s queue.

Exception reporting is also a communications strategy, and it predates cheap cellular data. The 2008 report describes agencies supplementing a long polling interval with reports sent only when a bus crossed a deviation threshold, because radio bandwidth was the constraint. That constraint is gone and the workflow it produced stayed. What a dispatcher uses all day is the ordered list of things that need a decision, plus the record that the decision was made. The map is scenery.

Not every vehicle in a feed is running a trip. Across the bus feeds we read, 9 percent of vehicles carried no trip assignment at all. Some of those are deadheading to or from the garage, some are on a break between blocks, some are logged in without an assignment because the operator has not entered a run number. A dispatcher cares about all of them. A rider-facing app usually drops them on the floor.

Where the data goes after the console

The same box feeds four different consumers, and they get run together constantly in writing about this layer.

The first is the public feed, and it is a lossy translation of the internal record. The second is the prediction engine, which takes the position stream and estimates arrival times downstream. That is a separate job with its own failure modes, covered in our piece on how real-time arrival predictions actually work, and it is where most rider-visible errors, including ghost buses, actually originate. The third is the archive: yesterday’s positions, stored, are what running-time analysis and performance reporting are built on, and there is now an open format for that archive in TIDES. The fourth is the set of onboard subsystems the box drives directly, which is why a fault in the onboard unit tends to take the announcements and the destination sign with it. On a corridor with transit signal priority, the question of whether a bus is late enough to deserve a few more seconds of green is answered from this same location and schedule data, so a priority request inherits whatever that data already got wrong.

Federal reporting sits alongside these rather than inside them. The National Transit Database collects service and ridership counts on its own schedule and with its own rules, and what an agency may use to produce those counts is a separate question from what its dispatch system happens to record.

How many agencies have it

The Mobility Database catalog gives a rough census of who has any of this. It lists 833 live US schedule feeds and 153 vehicle-position feeds attached to them, so fewer than one in five feeds with a published timetable has live positions alongside it. Of those 153, 148 also publish trip updates, which means that at this point an agency that can produce positions can nearly always produce predictions too. Publishing is not the same as owning, in either direction: an agency can run CAD/AVL and keep the output private, and a very small operator can put trackers on five vans and publish without anything resembling a dispatch system. As a floor on how much of US transit has nothing watching the fleet, though, the gap between 833 and 153 is the number to argue with.

What to watch

Cadence has stopped being the interesting variable, on the open feeds at least. When the median bus feed is serving positions seven seconds old, what limits a rider’s experience is everything after the position arrives: whether the trip assignment is right, whether the prediction model handles the layover, whether the operator logged into the correct run.

The fields past the position are where the next differences will show up. Occupancy is published by two thirds of bus feeds and populated on 41 percent of vehicles, and closing that gap is usually a hardware purchase rather than a software one. Schedule relationship, the field that says whether a vehicle is running a scheduled trip or an extra one, is set on 30 percent of vehicles, so a consumer looking at a trip it cannot match to the timetable has no way to tell an added bus from a bad identifier.

All counts here are point-in-time, measured on September 18, 2026, and describe feeds rather than agencies; a single operator can publish several.