← Content
Playbook

Real-Time Fleet Management for Public Transport: The Complete Guide

What real-time fleet management means for bus operators: AVM functions, passenger information, KPIs, hardware, EU data rules and how to choose.

· 10 min read

Real-time fleet management for public transport means knowing, at every moment, where each bus is, which trip it is running and how far it is from its schedule, then acting on that information. For a bus operator, it is delivered by an AVM (Automatic Vehicle Monitoring) system covering five things: vehicle location, schedule adherence, control and dispatch, passenger information, and operating data.

The distinction matters: a delivery company tracks vans, fuel and driver behaviour, while a transit operator must track trips against a published timetable, keep headways regular, inform passengers and report trips operated to the authority. This guide covers what a transit AVM does, the data and standards it produces, what the EU now requires, and how to choose a system.

What is real-time fleet management in public transport?

In public transport, the unit of management is not the vehicle alone but the vehicle running a scheduled trip. A bus parked in the depot with its engine on is a telematics event. The same bus leaving stop 1 of line 12 at 07:42, three minutes late, is an operational event that affects passengers, connections and the contract with the authority.

An AVM system links three layers of information:

  • The plan: the timetable (usually a GTFS or NeTEx file), the vehicle and driver schedules, the stops and route shapes.
  • The reality: GPS positions, door events, the trip the driver is logged on, the actual times at each stop.
  • The response: what controllers do when reality drifts from the plan, and what passengers are told.

Generic telematics vs transit AVM

Fleet telematics platforms such as Geotab or Samsara are built around assets and drivers: location, engine diagnostics, fuel use, driving behaviour, maintenance and safety. These functions are useful for any fleet, including buses.

A transit AVM starts from the timetable. Its core objects are lines, trips, stops and duties. The comparison below is about design focus, not quality: many operators run both kinds of tools side by side.

CriterionGeneric fleet telematicsTransit AVM
Reference objectVehicle, driver, assetScheduled trip, line, stop
Core questionWhere is the vehicle, how is it driven?Is the trip running on time, and what do passengers see?
Schedule dataNot centralGTFS or NeTEx timetable imported and matched
Main outputsFuel, diagnostics, driver scoring, geofencesPunctuality, trips operated, kilometres, GTFS-RT and SIRI feeds
UsersFleet and maintenance managersControllers, drivers, planners, authority, passengers

If your main problem is fuel or maintenance, telematics answers it. If your main problem is service reliability and passenger information, you need an AVM.

Core functions: what an AVM does every minute

Vehicle location and trip matching

GPS location is the easy part. The hard part is trip matching: knowing which scheduled trip a vehicle is running. It can come from the driver logging on to a duty, from automatic detection along the route shape, or from both. Without reliable trip matching, every downstream indicator (punctuality, predictions, trips operated) is wrong.

Schedule and headway adherence

Once the trip is known, the system compares actual and planned times at each stop. Two logics coexist:

  • Schedule adherence for lower-frequency lines, where passengers read the timetable. The indicator is early or late versus the published time.
  • Headway adherence for high-frequency lines, where passengers just turn up. The indicator is the regularity of intervals between buses, since bunching hurts more than a uniform delay.

A good AVM lets the operator choose the logic per line and per time band.

Controller tools

Real time is only valuable if someone can act on it. The usual control actions are:

  • Holding a bus at a timing point to restore a headway or protect a connection.
  • Detours when a street is closed, with the deviation pushed to drivers and to passenger information.
  • Replacements and cancellations when a vehicle breaks down or a driver is missing, so the trip is either reassigned or declared cancelled in the data.
  • Driver messaging, predefined or free text, in both directions, so controllers do not depend on voice radio alone.

Each action should be logged, because these logs explain the gap between planned and operated service when the authority asks for it.

Passenger information: GTFS-RT, SIRI, displays and apps

Passengers judge a network on the accuracy of its waiting times, not on its GPS precision. The AVM produces predictions and disruption messages, then distributes them through several channels.

Standards: GTFS-RT and SIRI

  • GTFS-RT (GTFS Realtime) is the format consumed by journey planners such as Google Maps, Moovit or Citymapper. It has three feed types: trip updates (predicted times, cancellations), vehicle positions and service alerts.
  • SIRI (Service Interface for Real Time Information) is the European CEN standard for real-time exchange between systems, widely used by authorities and national access points.

Exporting both is now a baseline requirement in Europe. In France, the national access point transport.data.gouv.fr lists 221 GTFS-RT datasets and 43 SIRI datasets (statistics page consulted in October 2026). Of the GTFS-RT datasets, 200 provide trip updates, 146 vehicle positions and 78 service alerts, which shows that predicted times are more widespread than alerts.

Displays and apps

The same data feeds stop displays, on-board screens and announcements, the network's own app and website, and third-party apps. The rule is one source of truth: if the stop display and the app disagree, passengers stop trusting both.

Data and KPIs: what to measure

Real-time fleet management also produces a historical record, which is often the most valuable output for management and for contract reporting. The core indicators:

KPIWhat it measuresCommon pitfall
PunctualityShare of departures within a tolerance window (for example, 1 minute early to 5 minutes late)Tolerance not defined in the contract, or measured at terminus only
Headway regularityVariation of intervals on frequent linesAveraged over the day, hiding peak bunching
Trips operatedPlanned vs run trips, with reason for each gapPartial trips counted as complete
Commercial kilometresDistance run in service, per line and vehicleMixing dead runs and service kilometres
Running timesActual travel time by section and time bandNot fed back into timetable revisions

Running times by section and time band are the raw material for any timetable redesign, whether done by planners or with AI tools. We explain why in our article on AI bus network planning: no model can plan better than the operated data it receives.

Onboard hardware: dedicated boxes vs smartphones and tablets

The onboard unit is often the largest cost and the slowest part of an AVM rollout. There are two main approaches.

Dedicated onboard computers are installed in the vehicle, connected to the vehicle network, door sensors, ticketing, passenger counters and displays. They suit large urban fleets with many integrated subsystems. Installation requires vehicle downtime and specialist work.

Smartphones and tablets in a cradle run a driver app that handles login, trip matching, messaging and navigation. Deployment is fast, hardware is replaceable off the shelf, and the same device can serve school, interurban and urban services. Limits appear when many onboard systems must be wired together.

ITxPT is the reference for the integrated approach. It is a non-profit association that publishes technical specifications for open, interoperable onboard IT architecture and runs a label confirming that equipment or software complies with them. Asking for ITxPT compliance in a tender protects the operator from being locked into one hardware supplier.

Many networks combine both, provided all vehicles report into the same AVM and data model.

EU data obligations: Delegated Regulation 2024/490

Commission Delegated Regulation (EU) 2024/490 revised the MMTIS framework (multimodal travel information services, originally Regulation 2017/1926). It entered into force on 4 March 2024 and sets dates by which data must be made available through each Member State's national access point.

For dynamic data on scheduled transport, the text lists disruptions (closures, diversions and, when possible, their reason) and real-time status such as estimated departure and arrival times, delays and cancellations. The deadlines:

DataComprehensive TEN-T networkOther parts of the Union network
Dynamic data, service level 1 (point 2.1: disruptions, real-time status)1 December 20251 December 2028
Dynamic data, service level 2 (point 2.2)1 December 20261 December 2028
Historic and observed data (point 1.4, including delays and cancellations)1 December 2025, entire network1 December 2025, entire network

Occupancy data (point 2.3) is optional, at the discretion of each Member State.

The practical consequence: by 1 December 2028, a local bus network outside the comprehensive TEN-T must be able to publish real-time predictions, delays, cancellations and disruptions in a standard format. Delays and cancellations as observed data are already due everywhere. For many small and medium networks, this is the first time real-time data becomes an obligation rather than a passenger service. Our article on the Eastern Europe bus boom and its data layer shows the same pressure on fleets being renewed with EU funding.

How it works in practice: examples from Western Europe

  • Spain: EMT Madrid sends bus locations and estimated arrival times to Google Maps through GTFS-RT for all its lines (eSmartCity, March 2025). At national level, the Spanish NAP (nap.transportes.gob.es) held 116 datasets in December 2025, static GTFS only at that point, with dynamic data being added to meet the EU regulation (datos.gob.es).
  • Portugal: Carris Metropolitana, the Lisbon metropolitan bus brand of TML covering 18 municipalities, put real-time passing times for more than 1,700 buses and about 12,000 stops into Google Maps in January 2024, in an open public format also used by Moovit and Citymapper (TML press release).
  • France: the national access point centralises GTFS-RT and SIRI feeds from networks of all sizes, with 221 GTFS-RT datasets listed.
  • Belgium: De Lijn publishes a GTFS Realtime feed for bus and tram on transportdata.be, updated every minute, covering estimated times, vehicle details and disruptions, with published API usage limits.
  • Netherlands: real-time vehicle data from operators is pooled through the national NDOV access points and redistributed to journey planners, a model built long before the EU deadlines.

How to choose a real-time fleet management system

Use these criteria rather than feature lists:

  1. Trip matching quality. Ask for the share of trips correctly matched on a real network, and how unmatched trips are handled.
  2. Standard exports. GTFS-RT (trip updates, vehicle positions, alerts) and SIRI, without paid add-ons per feed, plus GTFS or NeTEx import.
  3. Controller workflow. Holding, detours, replacements and cancellations should take a few clicks and flow automatically to passenger information.
  4. Hardware flexibility. Can it run on dedicated units, on smartphones and tablets, or both? Is ITxPT supported where you need integration?
  5. Data ownership and access. API access to raw and historical data, with exports in open formats.
  6. Reporting fit. Punctuality tolerance, trips operated and kilometres calculated the way your contract defines them.
  7. Deployment model and time. Cloud SaaS versus on-premises, number of weeks to go live, and who maintains the servers.
  8. Pricing transparency. Understand what drives the cost: vehicles, modules, hardware, integration.

Pysae is one example of the cloud approach: a SaaS AVM designed mobile-first, running on smartphones and tablets, with open GTFS and GTFS-RT exports. Whatever the supplier, run a pilot on one or two lines, compare the AVM's operated data with your own records, and only then scale.

FAQ

What is the difference between AVM and fleet telematics?

Fleet telematics tracks vehicles and drivers (location, fuel, diagnostics, driving style). An AVM tracks scheduled trips: it matches each vehicle to its trip, measures punctuality, supports controllers and feeds passenger information.

Do small bus networks need real-time data under EU rules?

Yes, in time. Under Delegated Regulation (EU) 2024/490, dynamic data such as delays, cancellations and disruptions must be available through national access points for the whole Union transport network by 1 December 2028, and earlier on the comprehensive TEN-T.

Can smartphones replace onboard computers for AVM?

For location, trip matching, driver messaging and passenger information, yes, and many networks use them. Dedicated units remain relevant when the bus must integrate ticketing, counters, displays and vehicle data on one onboard network, ideally to ITxPT specifications.

Which real-time formats should a bus operator publish?

GTFS-RT for journey planners (trip updates, vehicle positions, service alerts) and SIRI for exchange with authorities and national access points. Publishing both covers most European requirements.

Sources: Commission Delegated Regulation (EU) 2024/490, EUR-Lex; transportdata.be, information for data providers and De Lijn GTFS Realtime dataset; transport.data.gouv.fr statistics page (October 2026); datos.gob.es, podcast on transport open data (11/12/2025); Transportes Metropolitanos de Lisboa, press release "Tempo real da Carris Metropolitana já chegou ao Google Maps" (January 2024); eSmartCity, "La ubicación en tiempo real de los autobuses de EMT Madrid se puede consultar en Google Maps" (20/03/2025); ITxPT, itxpt.org; GOVI / NDOV access point, govi.nu.