EN 15531-1:2015

1.1Interfaces specified by this standard

1.1.1Business context

Real-time information may be exchanged between a number of different organizations, or between different systems belonging to the same organization. Key interfaces include the following:

-Between public transport vehicle control centres – generally, for fleet and network management.

-Between a control centre and an information provision system – generally, to provide operational information for presentation to the public.

-Between information provision systems – generally, sharing information to ensure that publicly available information is complete and comprehensive.

-Between information provision systems – and data aggregation systems that collect and integrate data from many different sources and different types of data supplier and then distribute it onwards.

-Between information provision systems and passenger information devices such as mobile phones, web browsers, etc.

Annex B describes the business context for SIRI in more detail.

SIRI is intended for wide scale, distributed deployment by a wide variety of installations. In such circumstances it is often not practical to upgrade all the systems at the same time. SIRI therefore includes a formal versioning system that allows for the concurrent operation of different levels at the same time and a disciplined upgrade process.

In this general framework, SIRI defines a specific set of concrete functional services. The services separate the communication protocols from the message content (‘functional services’). This allows the same functional content to be exchanged using different transport mechanisms, and different patterns of exchange. Figure 1 below shows this diagrammatically.

1.1.2SIRI communications

SIRI provides a coherent set of functional services for exchanging data for different aspects of PT operation. A common data model, based on Transmodel 5.1, is used across all services.

A communication layer defines common procedures for the requesting and exchanging of data. Within SIRI, the same general communication protocols are used for all the different concrete functional interfaces, and specify a common infrastructure for message referencing, error handling, reset behaviour and so forth. The communications layer is defined in Part 2 of the SIRI document set.

To allow the most efficient use to be made of bandwidth and processing capacity, the SIRI communications architecture supports several different patterns of interaction. SIRI supports both request/response and publish/subscribe protocols between servers, allowing applications both to pull or to push data.

The SIRI publish/subscribe pattern of interaction follows the paradigm described in the W3C candidate standard ‘Publish-Subscribe Notification for Web Services (WS-PubSub)’. SIRI uses the same separation of concerns, and a similar terminology for Publish/Subscribe concepts as is used in WS-PubSub.

For the delivery of data in response to both requests and subscriptions, SIRI supports two common patterns of message exchange as realised in existent national systems:

-one-step ‘direct’ delivery: allowing the simple rapid delivery of data;

-two-step ‘fetched’ delivery: allowing a more optimised use of limited resources.

1.1.3SIRI functional services

SIRI provides specific protocols for the following functional services, defined in Part 3 of the SIRI document set:

-Production Timetable (PT) Service: to send daily information on the operational timetable and associated vehicle running information.

-Estimated Timetable (ET) Service: to send real-time information on timetable, including changes based on the production service and on actual running conditions.

-Stop Timetable (ST) Service: to provide a stop-centric view of timetabled vehicle arrivals and departures at a designated stop.

-Stop Monitoring (SM) Service: to send real-time arrival & departure information relating to a specific stop.