scope:

Interfaces specified by this document

Business Context

Real-time information may be exchanged between a number of different organisations, or between different systems belonging to the same organisation. 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.

SIRI 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 6.0, 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.

SIRI 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.

• Vehicle Monitoring (VM) Service: to send real-time information on the movement and predicted movement of vehicles.

• Connection Timetable (CT) Service: to send an operational timetable for a service feeding an interchange, in order to inform departing services of the possible need to wait for connecting passengers.

• Connection Monitoring (CM) Service: to send real-time information on the running of a service inbound to an interchange, in order to advise departing services of the need to wait for connecting passengers. This can also be used to send real-time information to assist passengers in planning their onward journey following a connection.

• General Message (GM) Service: to exchange informative messages between participants.

Two additional functional services, are provided as additional parts:

• Facilities Management (FM) Service: to exchange information on the current status of facilities such as lifts, escalators or ticketing machines (Part 4).

• Situation Exchange (SX) Service: to exchange information messages between identified participants in a standardised structured format suitable for travel information services (Part 5).

Use of the SIRI standard

As a framework standard, it is not necessary for individual systems or specifications to implement the whole of the SIRI standard. Specifically, it is intended that individual national bodies may adopt consistent subsets of the standard. However, it should be possible to describe (for those elements of systems, interfaces and specifications which fall within the scope of SIRI):

• the aspects of SIRI that they have adopted;

• the aspects of SIRI that they have chosen not to adopt.

In other words, there is no global statement of which elements are mandatory and which optional (except for key fields which are clearly always mandatory).

SIRI is a modular and expandable standard, and the modules included in this version are only a subset of what might potentially be included. Specifically, the current issue of the SIRI specification excludes the following:

• interfaces with traffic management systems for traffic light priority;

• control action functions, e.g. instructions to a vehicle to change its running;

• functionality of actual systems - SIRI only specifies the interfaces between servers, not how they choose to implement it.

Since its inception SIRI has been enhanced and extended to meet additional requirements. The potential for SIRI to be expanded to encompass additional services will continue to be reviewed in future.

Guidance on the implementation and use of SIRI is not part of the specification. It is a matter for individual users and national groupings to provide advice and guidance on how SIRI may be used in support of local practices.

Note also that the SIRI communications layer does not specify the communication bearer technologies to be used. SIRI has been specifically developed to be 'technology independent' in this regard, so that local implementations can select the most cost-effective services for their projects.

Of course different technologies have different characteristics, and this may have an impact on the way that SIRI is used in practice. For example, the latency (time delay imposed by the communications network) of a service such as public GPRS is much higher than that on a dedicated, broadband fixed link using DSL. Therefore, systems based on GPRS will need to use a much higher value for some or all of the hysteresis parameters.

Limitations on SIRI and Possible Future Developments

The developers of this standard recognise that there is continual development in the business practice of the public transport industry, and that SIRI must continue to evolve to fulfil its needs. Specifically, there is scope for additional elements to be included in two places:

• Communications (SIRI Part 2). New mechanisms of data communication are constantly becoming available, in particular for areas such as information security and data discovery. SIRI is intended to be in line with prevailing information systems industry practice and Part 2 aims to retain flexibility in use of communications technologies. SIRI 2.0 introduces addition transports in form of the Document Literal WSDL and a RESTful presentation of services.

• Applications (SIRI Part 3, Part 4, Part 5, etc). This standard is based on a specific set of interfaces, representing a subset of practical needs among participant countries. However, new models of business cooperation may arise which necessitate additional application interface specifications. The current functional services are not intended to be a complete set of interfaces and additional modules might be required in future.

• Architectural detail. This standard is based on a very high-level decomposition of public transport operations, and implements only the most common interfaces. This may not fulfil all the needs of an implementer; for example, Scandinavia and the UK both have a relatively high degree of organisational disaggregation, and as a result may need standardisation on what would be 'internal' interfaces elsewhere in Europe.

CEN welcomes input from users of this Standard as to where SIRI needs extension or refinement.