SIRI stands for CEN TS 15531 Service Interface for Real time Information (SIRI).

SIRI was established as European standard in October 2006. It is a CEN (Comité Européen de Normalisation) and Technical Standard that specifies a European interface standard for exchanging information about the current or projected performance of real-time public transport operations (it also covers late updated of the planned information) between different computer systems.

What is SIRI for?
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 realtime 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.

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.

What Can be Exchanged?
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 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.