What is SIRI?
SIRI is a European standard that enables real-time information about public transportation to be shared between different computer systems. It is used by many different organisations, including public transportation operators, traffic management agencies, and travel information providers.
SIRI was established as European standard in October 2006. It is a CEN (Comité Européen de Normalisation) norm and Technical Specification.
Overview
- Part 1 describes Context and Framework (EN 15531-1:2015)
- Part 2 describes Communications (EN 15531-2:2015)
- Part 3 describes Functional Service Interfaces (EN 15531-3:2015)
- Part 4 describes Functional Service Interfaces: Facility Monitoring (CEN/TS 15531-4:2011)
- Part 5 describes Functional Service Interfaces: Situation Exchange (CEN/TS 15531-5:2016)
- Part 6 describes Functional Service Interfaces: Control Actions (CEN/TS 15531-6:2024)
- Part 7 describes the European Real Time Passenger SIRI Information Profile (CEN/TS 15531-7:2024) – under approval process
SIRI Implementation
By clicking on the countries in the map, you will get direct access to more information about the national implementations. For additional details on national SIRI profiles, please visit the DATA4PT Wiki.
What sort of information does SIRI exchange?
SIRI allows pairs of server computers to exchange structured real-time information about schedules, vehicles, and connections, together with general informational messages related to the operation of the services.
SIRI is a natural complement to NeTEx, NeTEx providing the scheduled information and SIRI the real time one. Both SIRI and NeTEx shared a common conceptual model provided by Transmodel.
The information provided by SIRI can be used for many different purposes, for example:
- To provide real time-departure from stop information for display on stops, internet and mobile delivery systems;
- To provide real-time progress information about individual vehicles;
- To manage the movement of buses roaming between areas covered by different servers;
- To manage the synchronisation of guaranteed connections between fetcher and feeder services;
- To exchange planned and real-time timetable updates;
- To distribute status messages about the operation of the services;
- To provide performance information to operational history and other management systems.
SIRI Services
SIRI comprises eight different concrete services, each consisting of request and delivery message pairs, and all using a common architecture, terminology, reference data:
- Production Timetable Service: Supports the dynamic exchange of planned schedules for a specific day, including updates (update of a calendar based schedule, most often previously exchanged with NeTEx). These may be used by AVMS systems to predict and monitor vehicle progress.
- Estimated Timetable Service: Supports the exchange of estimated schedules in real time, including updates. These may be used by AVMS systems to predict and monitor vehicle progress.
- Stop Timetable Service: Provides information about schedules for arrivals and departures at a Stop point.
- Stop Monitoring Service: Provides information about arrivals and departures at a Monitoring, i.e. Stop point. It has a similar scope as the Production Timetable service but with a stop centric point of view.
- Vehicle Monitoring Service: Provides information about the movement of a vehicle, and its progress against the target schedule.
- Connection Timetable Service: Provides information about schedules for interchanges at a connection point.
- Connection Monitoring Service: Provides information for interchanges at a connection point to support guaranteed connection services
- General Message Service: Supports the exchange of general text messages (usually related to a stop, a line, etc.)
- Situation Exchange Service: Covers the exchange of information describing an incident, typically an unplanned event such as a disruption, but also planned events that affect public transport or its use, such as engineering works, or major public events that will affect the use or availability of transport. This information is structured in a way that makes it usable by a journey planner in its optimisation algorithm.
- Facility Monitoring Service: Covers the exchange of information concerning the current status of facilities (equipment, sites, etc.). It provides a short description of the facility itself, the availability status and specifically the impact of the availability status for various categories of disabled or incapacitated people.
How is SIRI used?
Each system wishing to exchange information implements the SIRI protocols as XML services (JSON is also available, but mostly targeted for end-user’s devices). SIRI comprises a general communications architecture, and a number of specific services which operate within that architecture. The communications architecture supports two different patterns of interchange:
- A synchronous request/response protocol: each exchange of data consists of a request message from a client consumer, and a response message from a producer server.
- An asynchronous subscribe/publish protocol: the client subscribes to information by sending a message to the server containing both request information, and sensitivity criteria with which to filter messages. The producer server establishes a subscription for the consumer and will send messages back to the consumer whenever the criteria are satisfied, until the subscription ends. This pattern is ‘stateful’, that is to say, both parties in the interaction must manage the use of subscriptions that persist over time through successive interactions.
In both cases messages consist of XML documents, whose tags and content are exactly specified by the SIRI XML Schemas.
SIRI allows implementers to make different tradeoffs as to message size, use of bandwidth, frequency of update, verbosity of data, sensitivity to change, etc. This is reflected in particular in support for two different patterns of message exchange to return data from a producer server to a consumer client:
- A direct delivery protocol: the data returned in response to a request or subscription consists of a single delivery message, sent directly from the producer server to a client consumer.
- A fetched delivery protocol: the data returned in response to a request or subscription is delivered through an exchange of messages, comprising a notification from the producer server to a client consumer, followed by a request / response interaction from the consumer to the client to fetch the actual payload data. This is also a stateful pattern of communication.
SIRI also has services to monitor the system status and to provide basic information on reference data such as stops, lines, etc.
Learn more about local implementations
Open-source tools
Explore our open-source tool for SIRI, featuring a thoughtfully curated set of resources. This tool is designed to enhance data quality and ensure seamless interoperability. Whether you’re a developer, part of a transit agency, or simply interested in the field, this user-friendly tool provides a straightforward way to elevate your SIRI projects. Delve into the simplicity and effectiveness of this tool for a seamless implementation of the SIRI standard.