SIST-TS CEN/TS 15531-2:2009
(Main)Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure
Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure
SIRI uses a consistent set of general communication protocols to exchange information between client and server. The same pattern of message exchange may be used to implement different specific functional interfaces as sets of concrete message content types.
Two well-known specific patterns of client server interaction are used for data exchange in SIRI: Request/Response and Publish/Subscribe.
- Request/Response allows for the ad hoc exchange of data on demand from the client.
- Publish/Subscribe allows for the repeated asynchronous push of notifications and data to distribute events and Situations detected by a Real-time Service.
The use of the Publish/Subscribe pattern of interaction follows that described in the Publish-Subscribe Notification for Web Services (WS-PubSub) specification, and as far as possible, SIRI uses the same separation of concerns and common terminology for publish/subscribe concepts and interfaces as used in WS-PubSub. WS-PubSub breaks down the server part of the Publish/Subscribe pattern into a number of separate named roles and interfaces (for example, Subscriber, Publisher, Notification Producer, and Notification Consumer): in an actual SIRI implementation, certain of these distinct interfaces may be combined and provided by a single entity. Although SIRI is not currently implemented as a full WS-PubSub web service, the use of a WS-PubSub architecture makes this straightforward to do in future.
For the delivery of data in responses (to both requests and subscriptions), SIRI supports two common patterns of message exchange, as realised in existent national systems:
- A one step ‘Direct Delivery’, as per the classic client-server paradigm, and normal WS-PubSub publish subscribe usage; and;
- A two step ‘Fetched Delivery’ which elaborates the delivery of messages into a sequence of successive messages pairs to first notify the client, and then to send the data when the client is ready.
Öffentlicher Verkehr - Dienstleitungsschnittstelle für zeitnahe Informationen zum Betrieb des öffentlichen Verkehrs - Teil 2: Kommunikationsinfrastruktur
Javni prevoz - Vmesnik za informiranje v realnem času za potrebe delovanja javnega prevoza - 2. del: Komunikacijska infrastruktura
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TS CEN/TS 15531-2:2009
01-februar-2009
-DYQLSUHYR]9PHVQLN]DLQIRUPLUDQMHYUHDOQHPþDVX]DSRWUHEHGHORYDQMD
MDYQHJDSUHYR]DGHO .RPXQLNDFLMVNDLQIUDVWUXNWXUD
Public transport - Service interface for real-time information relating to public transport
operations - Part 2: Communications infrastructure
Öffentlicher Verkehr - Dienstleitungsschnittstelle für zeitnahe Informationen zum Betrieb
des öffentlichen Verkehrs - Teil 2: Kommunikationsinfrastruktur
Ta slovenski standard je istoveten z: CEN/TS 15531-2:2007
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
SIST-TS CEN/TS 15531-2:2009 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST-TS CEN/TS 15531-2:2009
---------------------- Page: 2 ----------------------
SIST-TS CEN/TS 15531-2:2009
TECHNICAL SPECIFICATION
CEN/TS 15531-2
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
July 2007
ICS 35.240.60
English Version
Public transport - Service interface for real-time information
relating to public transport operations - Part 2: Communications
infrastructure
Öffentlicher Verkehr - Dienstleitungsschnittstelle für
zeitnahe Informationen zum Betrieb des öffentlichen
Verkehrs - Teil 2: Kommunikationsinfrastruktur
This Technical Specification (CEN/TS) was approved by CEN on 23 October 2006 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36 B-1050 Brussels
© 2007 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15531-2:2007: E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST-TS CEN/TS 15531-2:2009
CEN/TS 15531-2:2007 (E)
Contents Page
Foreword.5
Introduction .6
1 Scope .7
2 Normative references .8
3 Terms and definitions .8
4 Symbols and abbreviations .8
5 Common communication aspects .8
5.1 Data Exchange Patterns of Interaction.8
5.1.1 General.8
5.1.2 Request/Response Pattern.8
5.1.3 Publish/Subscribe Pattern .9
5.1.4 Publish/Subscribe with Broker Pattern .10
5.1.5 Request/Response – Compound Requests .11
5.1.6 Publish/Subscribe – Compound Subscriptions .11
5.2 Delivery Patterns.12
5.2.1 General.12
5.2.2 Direct Delivery.12
5.2.3 Fetched Delivery .13
5.2.4 Data Horizon for Fetched Delivery.14
5.2.5 Get Current Message.15
5.2.6 Multipart Despatch of a Delivery.15
5.2.7 Multipart Despatch of a Fetched Delivery – MoreData.15
5.3 Mediation Behaviour .16
5.3.1 General.16
5.3.2 Mediation Behaviour – Maintaining Subscription Last Updated State .16
5.3.3 Mediation Behaviour – Subscription Filters .19
5.4 Recovery Considerations for Publish Subscribe.21
5.4.1 General.21
5.4.2 Check Status – Polling .22
5.4.3 Heartbeat – Pinging .22
5.4.4 Degrees of Failure.22
5.4.5 Detecting a Failure of the Producer.23
5.4.6 Detecting a Failure of the Consumer.24
5.5 Recovery Considerations for Direct Delivery .25
5.6 Request Parameters and Interactions .25
5.7 Error Conditions for Requests .27
5.8 Versioning .29
5.8.1 General.29
5.8.2 The Overall SIRI Framework Version Level .29
5.8.3 The SIRI Functional Service Type Version Level .29
5.9 Access Controls: Security and Authentication .30
5.9.1 General.30
5.9.2 System Mechanisms External to SIRI Messages .30
5.9.3 Application Access Controls Reflected in SIRI Processing.30
5.10 Service Discovery.31
5.10.1 General.31
5.10.2 Discovery of Servers that Support SIRI .31
5.10.3 Discovery of the Capabilities of a SIRI Server.31
5.10.4 Discovery of the Coverage of a Given SIRI Functional Service.31
2
---------------------- Page: 4 ----------------------
SIST-TS CEN/TS 15531-2:2009
CEN/TS 15531-2:2007 (E)
5.11 Capability Matrix.32
5.11.1 General .32
5.11.2 SIRI General Capabilities.32
6 Request/response .33
6.1 Making a Direct Request.33
6.1.1 General .33
6.1.2 ServiceRequest Message .34
6.1.3 The ServiceRequestContext.35
6.1.4 Common Properties of ServiceRequest Messages .37
6.1.5 ServiceRequest Example.37
6.1.6 Access Controls on a Request .38
6.2 Receiving a Data Delivery.39
6.2.1 General .39
6.2.2 ServiceDelivery Message.40
7 Subscriptions.44
7.1 Setting up Subscriptions.44
7.1.1 General .44
7.1.2 SubscriptionRequest .45
7.1.3 SubscriptionResponse .48
7.2 Subscription Validity.50
7.3 Terminating Subscriptions.50
7.3.1 General .50
7.3.2 The TerminateSubscriptionRequest.50
7.3.3 TerminateSubscriptionResponse .51
8 Delivering data.53
8.1 Direct Delivery .53
8.1.1 Procedure.53
8.1.2 DataReceivedAcknowledgement Message.53
8.1.3 DataReceivedAcknowledgement Example .53
8.2 Fetched Delivery.54
8.2.1 General .54
8.2.2 Signalling Data Availability (DataReadyNotification / DataReadyResponse) .54
8.2.3 Polling Data (DataSupplyRequest/ServiceDelivery) .56
9 Recovery from system failure .57
9.1 General .57
9.2 Recovery after Client Failure.57
9.3 Recovery after Server Failure .57
9.4 Reset after Interruption of Communication.58
9.5 Alive Handling.58
9.5.1 General .58
9.5.2 CheckStatusRequest.58
9.5.3 CheckStatusResponse.59
9.5.4 HeartbeatNotification .61
10 Transport of SIRI messages.62
10.1 Separation of Addressing from Transport Protocol .62
10.2 Logical Endpoint Addresses.62
10.2.1 Endpoint Addresses.62
10.2.2 Endpoint Address Examples.63
10.3 Parallelism and Endpoint Addresses.64
10.4 Encoding of XML messages.65
10.4.1 Principles.65
10.4.2 Encoding of Errors in XML .65
10.4.3 Character Set .65
10.4.4 Schema Packages .65
10.5 Use of SIRI with SOAP .66
10.5.1 General .66
10.5.2 Web Services .66
3
---------------------- Page: 5 ----------------------
SIST-TS CEN/TS 15531-2:2009
CEN/TS 15531-2:2007 (E)
10.5.3 Use of SOAP.67
10.5.4 SIRI WSDL .68
10.5.5 WSDL Producer Server Operations .69
10.5.6 WSDL Client Operations .70
10.5.7 SIRI WSDL Status .71
11 Capability discovery requests.71
11.1 General.71
11.2 Capability Request.71
11.3 Service Capability Discovery Request .72
11.4 Service Capability Discovery Response .72
11.5 Service Capability Discovery Response .73
11.5.1 General.73
11.5.2 Service Capability Response Example.74
11.6 Functional Service Capability Permission Matrix .76
11.6.1 General.76
11.6.2 OperatorPermissions .77
11.6.3 LinePermissions .77
11.6.4 ConnectionLinkPermissions .78
11.6.5 StopMonitorPermissions .78
11.6.6 VehicleMonitorPermissions.79
11.6.7 InfoChannelPermissions.79
12 Shared groups of elements .79
12.1 General.79
12.2 FramedVehicleJourneyRef .79
12.3 ServiceInfoGroup.80
12.4 VehicleJourneyInfoGroup.80
12.5 JourneyPatternInfoGroup .81
12.6 DisruptionGroup .82
12.7 JourneyProgressGroup .83
12.8 Location .83
12.9 OperationalBlockGroup .84
12.10 OperationalInfoGroup .84
12.11 Error .84
Bibliography .85
4
---------------------- Page: 6 ----------------------
SIST-TS CEN/TS 15531-2:2009
CEN/TS 15531-2:2007 (E)
Foreword
This document (CEN/TS 15531-2:2007) has been prepared by Technical Committee CEN/TC 278 “Road
transport and traffic telematics”, the secretariat of which is held by NEN.
This presents Part 2 of the European Technical Specification known as “SIRI”. SIRI provides a framework for
specifying communications and data exchange protocols for organisations wishing to exchange Real-time
Information (RTI) relating to public transport operations.
SIRI is presented in three parts:
• Context and framework, including background, scope and role, normative references, terms and
definitions, symbols and abbreviations, business context and use cases (Part 1).
• The mechanisms to be adopted for data exchange communications links (Part 2).
• Data structures for a series of individual application interface modules (Part 3).
The XML schema can be downloaded from http://www.siri.org.uk/, along with available guidance on its use,
example XML files, and case studies of national and local deployments.
It is recognised that SIRI is not complete as it stands, and there will be a substantial amount of work required
to continue to develop SIRI over the coming years. It is therefore intended that a SIRI Management Group
should continue to exist, at European level, based on the composition of SG7.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this CEN Technical Specification: Austria, Belgium, Bulgaria, Cyprus, Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and United Kingdom.
5
---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 15531-2:2009
CEN/TS 15531-2:2007 (E)
Introduction
Public transport services rely increasingly on information systems to ensure reliable, efficient operation and
widely accessible, accurate passenger information. These systems are used for a range of specific purposes:
setting schedules and timetables; managing vehicle fleets; issuing tickets and receipts; providing real-time
information on service running, and so on.
This Technical Specification specifies a Service Interface for Real-time Information (SIRI) about Public
Transport. It is intended to be used to exchange information between servers containing real-time public
transport vehicle or journey time data. These include the control centres of transport operators and information
systems that utilise real-time vehicle information, for example, to deliver services such as travel information.
Well-defined, open interfaces have a crucial role in improving the economic and technical viability of Public
Transport Information Systems of all kinds. Using standardised interfaces, systems can be implemented as
discrete pluggable modules that can be chosen from a wide variety of suppliers in a competitive market, rather
than as monolithic proprietary systems from a single supplier. Interfaces also allow the systematic automated
testing of each functional module, vital for managing the complexity of increasing large and dynamic systems.
Furthermore, individual functional modules can be replaced or evolved, without unexpected breakages of
obscurely dependent function.
This Technical Specification will improve a number of features of public transport information and service
management:
• Interoperability – the Technical Specification will facilitate interoperability between information processing
systems of the transport operators by: (i) introducing common architectures for message exchange; (ii)
introducing a modular set of compatible information services for real-time vehicle information; (ii) using
common data models and schemas for the messages exchanged for each service; and (iv) introducing a
consistent approach to data management.
• Improved operations management – the Technical Specification will assist in better vehicle management
by (i) allowing the precise tracking of both local and roaming vehicles; (ii) providing data that can be used
to improve performance, such as the measurement of schedule adherence; and (iii) allowing the
distribution of schedule updates and other messages in real-time.
• Delivery of real-time information to end-users – the Technical Specification will assist the economic
provision of improved data by; (i) enabling the gathering and exchange of real-time data between VAMS
systems; (ii) providing standardised, well defined interfaces that can be used to deliver data to a wide
variety of distribution channels.
Technical advantages include the following:
• Reusing a common communication layer for all the various technical services enables cost-effective
implementations, and makes the Technical Specification readily extensible in future.
6
---------------------- Page: 8 ----------------------
SIST-TS CEN/TS 15531-2:2009
CEN/TS 15531-2:2007 (E)
1 Scope
SIRI uses a consistent set of general communication protocols to exchange information between client and
server. The same pattern of message exchange may be used to implement different specific functional
interfaces as sets of concrete message content types.
Two well-known specific patterns of client server interaction are used for data exchange in SIRI:
Request/Response and Publish/Subscribe.
• Request/Response allows for the ad hoc exchange of data on demand from the client.
• Publish/Subscribe allows for the repeated asynchronous push of notifications and data to distribute events
and Situations detected by a Real-time Service.
The use of the Publish/Subscribe pattern of interaction follows that described in the Publish-Subscribe
Notification for Web Services (WS-PubSub) specification, a
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.