CEN/TS 15531-2:2007
(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 - Serviceschnittstelle für Echtzeitinformationen bezogen auf Operationen im öffentlichen Verkehr - Teil 2: Kommunikationsstruktur
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
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
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
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.
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
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
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.