An automatic vehicle monitoring (AVM) system for buses should, at minimum, locate every vehicle in real time, match it to the trip it is actually running, give controllers tools to act on delays, and publish that data as standard GTFS-RT feeds for passengers. In 2026, a serious shortlist also checks contract reporting, open data access, hardware flexibility and cybersecurity, because EU rules now make real-time data an obligation rather than an option.
Vendor feature lists all look alike. This checklist sorts AVM features into three levels: must-have (do not sign without it), should-have (expect it within the first year) and nice-to-have (useful depending on fleet and contract).
It is deliberately feature-level. For the overall approach (fleet coverage, hardware, deployment speed), see our guide on how to choose an AVM system for bus operators.
Which core AVM features are non-negotiable?
Location and trip matching
Position data alone is telematics. AVM knows which trip each vehicle is running and how far off schedule it is.
- Must-have: position updates at short, configurable intervals; automatic matching of each vehicle to its scheduled trip from the imported GTFS timetable; stop arrival and departure detection; schedule deviation calculated per stop.
- Must-have: clear handling of unmatched trips. Ask what share of trips is correctly matched on a real network and what happens when a driver forgets to log in or a vehicle is swapped mid-duty.
- Should-have: headway monitoring for high-frequency lines, where regularity matters more than timetable adherence.
- Nice-to-have: geofenced events (depot exit, school stop) that trigger alerts.
Control and dispatch
- Must-have: a live map and line diagrams showing deviation by vehicle; alerts for early running, late running and missing vehicles; the ability to cancel, add or reassign trips.
- Should-have: detour management that updates stops served and flows straight to passenger information. Detours are where many real-time feeds break, a problem covered in our article on what operators get wrong with GTFS-RT.
- Nice-to-have: decision support for holding or short-turning, suggested by the system but validated by the controller.
Driver app and messaging
- Must-have: simple driver login linked to duty and vehicle; a schedule advance or delay indicator; two-way messaging between drivers and the control room, with predefined messages to limit distraction.
- Should-have: route guidance on unfamiliar lines and detours; incident reporting with location.
- Nice-to-have: voice calls and driver safety alarms.
What passenger information and open data features are now required?
This is the area where regulation has changed the checklist. Commission Delegated Regulation (EU) 2024/490, which revised the MMTIS framework and entered into force on 4 March 2024, requires dynamic data on scheduled transport (disruptions, estimated times, delays, cancellations) to be made available through national access points. The deadline is 1 December 2025 for the comprehensive TEN-T network and 1 December 2028 for the rest of the network. Historic and observed data, including delays and cancellations, was due across the entire network from 1 December 2025.
In practice, a small interurban network that never published real-time data must do so by the end of 2028, and the AVM is the natural source.
- Must-have: GTFS-RT feeds covering trip updates, vehicle positions and service alerts, generated automatically from operations, with a stable public URL.
- Must-have: static GTFS import and consistency between the static timetable and the real-time feed (same trip and stop identifiers).
- Should-have: feeds accepted by major journey planners. In Lisbon, Carris Metropolitana put real-time passing times for more than 1,700 buses and about 12,000 stops into Google Maps in January 2024 (TML). In Belgium, De Lijn publishes a GTFS Realtime feed updated every minute on transportdata.be.
- Should-have: onboard and at-stop displays fed by the same source as the app.
- Nice-to-have: occupancy data. Under Regulation 2024/490, occupancy remains optional, at each Member State's discretion.
Some countries also expect SIRI or NeTEx, so confirm what the supplier actually exports today. The full operational picture is in our complete guide to real-time fleet management for public transport.
Which reporting and integration features matter for contracts?
Reporting and contract KPIs
Authorities pay and penalise operators on as-run data, so reporting is contractual, not cosmetic.
- Must-have: trips operated versus scheduled, with reason codes for missed or partial trips; punctuality with configurable tolerance windows (for example, the exact early and late thresholds written in your contract); commercial and dead-running kilometres.
- Must-have: exports in open formats (CSV, Excel) and historic data retained long enough to cover a full contract year and audits.
- Should-have: punctuality by stop, segment and time band, which is the raw material for revising running times; reports by subcontractor where part of the service is outsourced.
- Nice-to-have: scheduled reports sent to the authority.
Scheduling and duties integration
- Must-have: import of the timetable and of vehicle and driver duties, with a clear process for seasonal changes.
- Should-have: day-of-operations changes (driver swap, vehicle swap) reflected immediately in trip matching.
What about hardware, data ownership and deployment?
Hardware flexibility
- Must-have: equipping the whole fleet, including older and subcontracted vehicles, in the first phase.
- Should-have: support for off-the-shelf smartphones and tablets as onboard units, with replacement that does not need a specialist technician.
- Should-have for integrated fleets: ITxPT compliance. ITxPT, a non-profit association, publishes specifications for open onboard IT architecture and labels compliant products, which limits hardware lock-in.
Data ownership and API
- Must-have: a contract clause stating that operational data belongs to the operator or the authority, with full export at the end of the contract.
- Should-have: a documented API for raw and historic data (positions, trips, punctuality, kilometres), so that your BI tools or the authority can consume it without manual exports.
Deployment and support
- Must-have: cloud hosting with updates included and support hours matching your operating hours, weekends included.
- Should-have: a pilot on one or two lines; training for controllers and drivers included.
Which features are new on the 2026 checklist?
Three topics have moved from "future" to "ask now".
AI-assisted running times. The idea is not new: GIRO's HASTUS-ATP module, documented in 2011 and developed with Transports Metropolitans de Barcelona, calculates run times and layovers from historical vehicle location records (TRID). Machine learning now makes it routine, but any model needs clean as-run data by segment and time band. The AVM checklist item is data quality and access, not an "AI" label.
Electric bus awareness. In 2025, six out of ten new city buses sold in the EU were zero-emission, with battery-electric at 56% and fuel cell at 4% (Transport & Environment, February 2026). Shares exceeded 90% in the Netherlands and Belgium, reached 56% in Spain and 42% in France. With mixed fleets, ask whether the AVM flags electric vehicles, helps controllers avoid assigning a short-range bus to a long duty, and tracks kilometres per vehicle. State-of-charge display depends on access to vehicle data.
Cybersecurity. NIS2 lists operators of intelligent transport systems and road authorities in its transport sector (Annex I), while bus operators as such are not named; whether you are in scope depends on national transposition and your activities. Covered entities must manage supply-chain security, which means questions to the AVM supplier. Separately, the Cyber Resilience Act's vulnerability reporting obligations have applied since 11 September 2026, with main requirements for products with digital elements, such as onboard devices, applying from 11 December 2027. Must-haves regardless of scope: encryption, role-based access, individual accounts, access logs and an incident process.
The checklist table
| Area | Must-have | Should-have | Nice-to-have |
|---|---|---|---|
| Location & trip matching | Real-time positions, automatic trip matching, stop detection, deviation per stop | Headway monitoring | Geofenced events |
| Control & dispatch | Live map, deviation alerts, cancel/add/reassign trips | Detour management linked to passenger info | Holding or short-turn suggestions |
| Driver app & messaging | Login to duty and vehicle, advance/delay indicator, two-way messaging | Route guidance, incident reporting | Voice calls, safety alarms |
| Passenger info & open data | GTFS-RT (trip updates, positions, alerts), GTFS import, consistent IDs | Journey planner acceptance, displays on same source | Occupancy data |
| Reporting & KPIs | Trips operated, punctuality with contract tolerances, kilometres, open exports | Punctuality by segment and time band, subcontractor reports | Scheduled reports to the authority |
| Scheduling & duties | Timetable and duty import | Same-day swaps reflected live | Running-time feedback to scheduling |
| Hardware | Whole fleet coverage | Smartphones and tablets, ITxPT where integrated | Mixed hardware in one system |
| Data & API | Data ownership clause, full export | Documented API | BI connectors |
| Deployment & support | Cloud, updates included, support during operating hours | Pilot, training included | Dedicated customer success |
| 2026 items | Encryption, access control, logs | EV flag and range-aware assignment, NIS2 supply-chain answers | AI running-time analysis |
What this means for an operator preparing a tender or a switch
Use the table as a scoring grid. Ask suppliers to answer each line with "available now", "roadmap with a date" or "not planned", and request a demo on your own GTFS data. A missing must-have disqualifies the offer.
Then run a pilot: compare trips operated, punctuality and kilometres with your own records over several weeks, and check that a journey planner picks up the GTFS-RT feed.
Pysae, for example, is a cloud AVM running on smartphones and tablets, with GTFS and GTFS-RT exports. Whatever the supplier, the goal is the same: real-time data that is accurate, open and yours.
FAQ
What is the most important feature of an AVM system?
Reliable trip matching. Positions are useless for control, reporting or passenger information if the system does not know which trip each vehicle is running. Ask for the matched trip rate on a live network.
Does a small bus network need GTFS-RT in 2026?
Under Delegated Regulation (EU) 2024/490, dynamic data must be available through national access points by 1 December 2028 outside the comprehensive TEN-T network. Starting now leaves time to fix data quality before the deadline.
Should AI features influence the choice of an AVM?
Only indirectly. AI running-time tools depend on clean as-run data by segment and time band. Prioritise data quality, history and API access; analysis tools can be added on top.
Sources: Commission Delegated Regulation (EU) 2024/490, EUR-Lex; Directive (EU) 2022/2555 (NIS2), Annex I, via Advisera; McCann FitzGerald, "Cyber Resilience Act: Reporting Obligations apply from 11 September 2026"; Transport & Environment, "Past the inflection point: electric now clearly dominates the city bus market" (20/02/2026); Transportes Metropolitanos de Lisboa, press release on Carris Metropolitana real-time data in Google Maps (January 2024); transportdata.be, De Lijn GTFS Realtime dataset; TRID, "ATP: Run-time analysis and improved punctuality" (GIRO, 2011); ITxPT, itxpt.org.