How to integrate GTFS-Realtime and SIRI with existing bus fleet hardware

GTFS-Realtime (GTFS-RT) has become the dominant standard for real-time transit data in the English-speaking world and beyond. It powers journey planner apps, stop display systems, and national mobility data platforms. But across Europe, a second standard runs in parallel — SIRI — and any serious integration project needs to account for both.

Two standards, one goal: GTFS-RT and SIRI

GTFS-Realtime (GTFS-RT) was developed by Google and is now maintained as an open standard by MobilityData. It layers real-time updates on top of a static GTFS schedule. There are three feed types:

Trip Updates: delays, cancellations, and estimated arrival times per stop
Vehicle Positions: GPS coordinates of vehicles in service
Service Alerts: disruptions, detours, and messages for passengers

SIRI (Service Interface for Real-Time Information) is a European standard developed under CEN TC278, based on the Transmodel reference data model. Developed initially with participation from France, Germany, Norway, and the UK, SIRI defines functional services for real-time information exchange:

SIRI-SM (Stop Monitoring): real-time departures at a specific stop
SIRI-ET (Estimated Timetable): real-time timetable updates across the network
SIRI-VM (Vehicle Monitoring): vehicle positions
SIRI-SX (Situation Exchange): service disruptions and alerts

In 2025, CEN published CEN/TS 15531-7 (SIRI Part 7), which defines the European Real-Time Passenger Information Profile (EPIP-RT) — a common European profile for cross-border interoperability. SIRI is particularly entrenched in France, the UK, Switzerland, and the Nordic countries. In France, it is a regulatory requirement: transport data holders must publish real-time feeds in SIRI format to the national access point (Point d’Accès National).

Which standard should you target? In practice, most European operators need both. GTFS-RT for downstream app consumption and open data; SIRI for system-to-system exchanges, passenger information displays, and regulatory compliance.

What GTFS-RT and SIRI require from your infrastructure

Both standards are output formats, not tracking systems. To produce a meaningful real-time feed, you first need a system that is tracking your vehicles against their scheduled trips in real time. That is the role of a CAD/AVL or SAEIV platform.

A basic GPS tracker can tell you where a bus is, but it cannot produce a Trip Update feed or a SIRI-ET export unless it knows which trip the bus is running, which stops it has served, and how it compares to the theoretical timetable.

The integration process: step by step

Step 1: Clean, up-to-date static data

Your real-time feed is only as good as your static data. For GTFS-RT, that means a valid GTFS file. For SIRI, it means NeTEx or a compatible reference dataset. Ensure your data is accurate, regularly updated, and validated before attempting any real-time integration.

Step 2: Driver sign-on and trip assignment

For the CAD/AVL system to know which trip a vehicle is running, drivers must sign on to their assigned trip at the start of each service. The quality of your real-time output is directly tied to driver adoption. The sign-on flow must be simple (under 30 seconds), dispatchers need visibility over sign-on rates, and fallback logic should handle missed sign-ons via GPS-based automatic trip matching.

Step 3: Real-time processing and ETA calculation

Once a vehicle is matched to a trip, the system calculates estimated arrival times at each upcoming stop. This requires high-frequency GPS updates (typically every 10–30 seconds), historical travel time data for improved accuracy, and robust handling of edge cases: early departures, held vehicles, short-turnings.

Step 4: Feed publication

For GTFS-RT: the feed is published as a protobuf binary endpoint. Update frequency should be 15–30 seconds for most downstream consumers. Monitor for outages or stale data — a feed that silently stops updating causes downstream disruption.

For SIRI: the feed is XML-based, typically served via request/response or publish/subscribe. SIRI Lite (a simplified REST variant) is increasingly adopted for open data portals. The specific services required depend on your national profile and the systems consuming your data.

What to look for in a CAD/AVL system

Native GTFS-RT output — Trip Updates, Vehicle Positions, and Service Alerts without custom middleware
SIRI output — at minimum SIRI-SM and SIRI-ET for European deployments; check which national profile the system supports
GTFS and NeTEx ingestion — automatic polling via URL so timetable updates propagate without manual intervention
Automatic trip matching — GPS-based fallback for missed driver sign-ons
Feed quality monitoring — dashboards showing real-time feed coverage with alerts for gaps
National Access Point compatibility — support for your country's NAP format requirements

A practical example: how Pysae handles real-time feeds

Pysae's cloud-native architecture was designed around open data standards from the ground up. The platform ingests GTFS and NeTEx files automatically, runs trip matching against driver sign-on data in real time, and produces both GTFS-RT feeds and SIRI outputs for network-level exchanges and passenger information systems.

For networks in France, Pysae supports the national SIRI profile and the data flows required for publication to the Point d'Accès National. For operators targeting international deployments, the same pipeline adapts to country-specific profiles.

Common mistakes to avoid

Treating real-time integration as a one-time project — timetable changes must propagate continuously into your static data
Underestimating driver adoption — no algorithm compensates for a fleet where 30% of drivers are not signing on
Ignoring feed monitoring — silent feed failures cause disruption across every system consuming your data
Conflating vehicle positions with trip updates — GPS coordinates have limited passenger value; per-stop ETAs are what powers useful information
Assuming GTFS-RT is enough in Europe — if your network operates under French, UK, or Nordic regulatory frameworks, SIRI compliance may be mandatory

Need to publish GTFS-RT or SIRI feeds from your fleet? Pysae's team can walk you through the integration requirements for your specific network and regulatory context.