Short answer: to integrate GTFS-Realtime and SIRI with existing bus fleet hardware, you do not replace the hardware. You put an AVM platform between the vehicles and the feeds. It tracks each vehicle against its scheduled trip, calculates per-stop arrival estimates, then publishes GTFS-RT (Trip Updates, Vehicle Positions, Service Alerts) and SIRI (SIRI-SM, SIRI-ET, SIRI-VM, SIRI-SX) from the same data. Expect GPS positions every 10 to 30 seconds and feeds refreshed every 15 to 30 seconds.
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, real-time data is published to the national access point (Point d'Accès National): it accepts GTFS-RT, SIRI-Lite or full SIRI, and the choice is often driven by the format the transport authority specifies.
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 an AVM 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 AVM 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 to 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 to 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 an AVM 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'Acces 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
Frequently asked questions
Can I publish GTFS-RT and SIRI feeds from my existing onboard hardware?
Yes, as long as the platform can ingest positions from your existing equipment. A basic GPS tracker tells you where a bus is, but it cannot produce a Trip Update feed or a SIRI-ET export on its own. The AVM adds the missing pieces: trip matching, comparison with the theoretical timetable and per-stop arrival estimates.
Which transit software supports GTFS-RT, SIRI and NeTEx out of the box?
Look for native GTFS-RT output (Trip Updates, Vehicle Positions, Service Alerts), SIRI output with at least SIRI-SM and SIRI-ET, and automatic GTFS and NeTEx ingestion by URL. Pysae ingests GTFS and NeTEx files automatically and produces both GTFS-RT feeds and SIRI outputs from the same real-time pipeline.
Do I need both GTFS-RT and SIRI?
In practice, most European operators do. GTFS-RT feeds journey planner apps and open data. SIRI covers system-to-system exchanges, passenger information displays and authority interfaces.
How often should the feeds update?
GPS positions typically arrive every 10 to 30 seconds, and GTFS-RT feeds should refresh every 15 to 30 seconds for most downstream consumers. Monitor feed freshness: a feed that silently stops updating disrupts every system that consumes it.
What most often degrades the quality of real-time feeds?
Driver sign-on. If drivers do not sign on to their trip, the AVM cannot match the vehicle to the timetable, so keep the sign-on flow under 30 seconds and rely on GPS-based automatic trip matching as a fallback.
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.