SIST EN 15531-2:2015
(Main)Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications
Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications
Update of CEN/TS 15531 respecting the results of the projects in different countries using the specification and taking into account new demands. The existing standard was developed by CEN TC278 WG3 SG7 starting in 2002 and published in 2007. It facilitates interoperability between information processing systems of the transport operators (Automatic Vehicle monitoring Systems: AVMS) in order to allow a better vehicle management as well as the delivery of real time information to end-users. The main elements of the standard are: - A communication layer, which defines common procedures for requesting and exchanging of data. The communication procedures are the same for all services and with that represent the interface infrastructure (message referencing, error handling, reset behaviour). Reusing it for the various technical services ensures cost-effective implementation and extension of the interface. o Request/Response o Publish/Subscribe Subscriptions define the type and volume of data to be exchanged. - An interface between control centres (AVMS) with the functions o connection protection (time or journey related) o connection information (time related) o real time passenger information (Departure Board, stop centric) o general message service (event and information message service) o time table information and network topology (Planned Data Exchange) o vehicle activity (VIS) - An interface for time table information between control centres (AVMS) and information systems with the functions o real time schedule information o Reference data service for schedule information. The new work item will consider the work of - Other sub-groups pf WG3: * SG4 Data Base Model for Public Transport (TRANSMODEL) * SG9 Network and Timetable Exchange (NeTEx) - National Mirror Groups Justification Since SIRI has been developed demands for information by interested public bodies and especially customers of public transport have risen substantially. Existing national and international ‘standards’ (especially TRIDENT, RTIG and VDV-453/454) being in use already before the time of SIRI have reached a high level of performance. Now that time has come to replace the old systems by SIRI, CEN/TS 15531 has to meet this performance. Therefore it is urgent to enhance and refine SIRI, so it meets the level, real time data management has reached today.
Öffentlicher Verkehr - Serviceschnittstelle für Echtzeitinformationen bezogen auf Operationen im öffentlichen Verkehr - Teil 2: Kommunikationsstruktur
Transport public - Interface de service pour les informations en temps réel relatives aux opérations de transport public - Partie 2 : Infrastructure des communications
La norme SIRI utilise un ensemble cohérent de protocoles de communication généraux pour échanger des informations entre un client et un serveur. Le même schéma d'échange de message peut être utilisé pour mettre en oeuvre différentes interfaces fonctionnelles spécifiques sous la forme d'un ensemble de types de contenus de message concrets.
L'échange de données selon la norme SIRI fait appel à deux schémas spécifiques d'interaction client/serveur bien connus: Demande/Réponse et Edition/Abonnement.
- Le schéma Demande/Réponse permet l'échange ad hoc de données sur demande du client.
- Le schéma Edition/Abonnement permet d'émettre de façon répétée et asynchrone des notifications et des données afin de diffuser des événements et des situations identifiées par un service en temps réel.
L'utilisation du schéma d'interaction Edition/Abonnement est fidèle aux spécifications de la norme « Publish-Subscribe Notification for Web Services » (WS-PubSub); la norme SIRI reprend autant que faire se peut la séparation des problématiques et la terminologie relative aux concepts et aux interfaces d'édition/d'abonnement de la norme WS-PubSub. Cette dernière décompose la partie serveur du schéma Edition/Abonnement en différents rôles et interfaces définis (Abonné, Editeur, Producteur ou Destinataire de notifications par exemple): dans le cadre d'une mise en oeuvre SIRI réelle, une même entité peut associer et fournir certaines de ces interfaces distinctes. Bien qu'aujourd'hui SIRI ne soit pas déployé comme un service web WS-PubSub intégral, l'utilisation d'une architecture WS-PubSub permet de simplifier cette action future.
En général, le schéma Edition/Abonnement n'est pas destiné à prendre en charge un grand nombre d'appareils d'utilisateurs finaux.
En matière de transmission de données en réponse à des demandes et des abonnements, SIRI prend en charge deux schémas communs d'échange de messages, similaires à ceux des systèmes nationaux existants:
- Une Transmission « directe » en une seule étape conformément au paradigme traditionnel client-serveur avec édition et abonnement WS-PubSub ordinaires; et
- Une transmission « fetched » en deux étapes, laquelle configure l'envoi de messages selon une séquence de deux alertes successives, la première visant à informer le client et la seconde à envoyer les données lorsque ce dernier est prêt. La Transmission Fetched constitue à elle seule un schéma connecté.
En fonction des environnements cibles, chaque schéma de transmission implique différents compromis à respecter en vue de garantir l'efficacité du déploiement.
L'un ou l'autre de ces modes de transmission (voire les deux) est applicable à une mise en oeuvre SIRI, l'objectif étant de garantir une utilisation optimale des ressources de calcul et de communication. Soit le mode de transmission peut être préconfiguré et statique de manière à correspondre à un déploiement donné, soit chaque demande ou abonnement peut faire état de ce dernier en fonction des exigences dynamiques du client énoncées dans le cadre de la politique correspondante, le serveur pouvant refuser une demande lorsque celle-ci ne prend pas en charge le mode choisi avant de générer un code d'erreur associé.
Les schémas d'interaction et de transmission constituent des caractéristiques indépendantes du protocole SIRI, et peuvent être utilisés dans différentes mises en oeuvre, et ce quelle que soit la combinaison.
Lorsqu'il s'agit d'un type de Service fonctionnel SIRI spécifique (Connection Monitoring ou Stop Monitoring p. ex.), le contenu des données utiles du message est identique, que les informations soient échangées avec un schéma Demande/Réponse ou Edition/Abonnement, ou que la transmission soit directe ou fetched.
....
Javni prevoz - Vmesnik za informiranje v realnem času za potrebe delovanja javnega prevoza - 2. del: Komunikacije
Posodobitev standarda CEN/TS 15531 ob upoštevanju rezultatov projektov v različnih državah, ki so uporabljale specifikacijo, in ob upoštevanju novih zahtev. Obstoječi standard so začeli razvijati v okviru CEN TC278 WG3 SG7 leta 2002 in ga objavili leta 2007. Olajšuje interoperabilnost med sistemi za obdelavo informacij o izvajalcih prevoza (avtomatski nadzorni sistemi za vozila: AVMS), da se omogoči boljše upravljanje vozil kot tudi zagotavljanje informacij za končne uporabnike v realnem času. Glavni elementi standarda so: - komunikacijska plast, ki določa skupne postopke za povpraševanje po podatkih in njihovo izmenjavo. Komunikacijski postopki so enaki za vse storitve in s tem predstavljajo infrastrukturo vmesnika (povezovanje sporočil, obravnavanje napak, vedenje ob ponastavitvi). Ponovna uporaba infrastrukture vmesnika za razne tehnične storitve zagotavlja stroškovno učinkovito izvajanje in razširitev vmesnika. o Zahteva/odziv o Objava/naročnina Naročnine določajo tip in količino podatkov za izmenjavo. - Vmesnik med kontrolnimi centri (AVMS) s funkcijami o zaščita povezave (v povezavi s časom ali potovanjem) o informacije o povezavi (v povezavi s časom) o informacije o potniku v realnem času (tabela odhodov, postanki) o splošna sporočila (storitev obveščanja o dogodkih in informacije) o informacije o voznem redu in topologija omrežja (načrtovana izmenjava podatkov) o aktivnost vozila (VIS) - vmesnik za informacije o voznem redu med kontrolnimi centri (AVMS) in informacijskimi sistemi s funkcijami o informacije o razporedu v realnem času o storitev referenčnih podatkov za informacije o razporedu. Nova delovna postavka bo obravnavala delo - drugih podskupin pf WG3: * SG4 podatkovni model za javni prevoz (TRANSMODEL) * SG9 omrežje in izmenjava voznega reda (NeTEx) - Obrazložitev nacionalnih zrcalnih odborov; od pojava aplikacije SIRI so se znatno povečale zahteve po informacijah s strani zainteresiranih javnih organov in predvsem odjemalcev javnega potniškega prevoza. Obstoječi nacionalni in mednarodni »standardi« (zlasti TRIDENT, RTIG in VDV-453/454), ki so bili v uporabi še pred pojavom aplikacije SIRI, so dosegli visoko raven izvajanja. Zdaj pa je prišel čas za zamenjavo starih sistemov s SIRI in CEN/TS 15531 se mora prilagoditi novim zmogljivostim. Zato je treba nujno okrepiti in izboljšati SIRI, da bo ustrezala stopnji, ki jo danes dosega upravljanje podatkov v realnem času.
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.GHORYDQMDÖffentlicher Verkehr - Serviceschnittstelle für Echtzeitinformationen bezogen auf Operationen im öffentlichen Verkehr - Teil 2: KommunikationsstrukturTransport public - Interface de service pour les informations en temps réel relatives aux opérations de transport public - Partie 2 : Infrastructure des communicationsPublic transport - Service interface for real-time information relating to public transport operations - Part 2: Communications35.240.60Uporabniške rešitve IT v transportu in trgoviniIT applications in transport and tradeICS:Ta slovenski standard je istoveten z:EN 15531-2:2015SIST EN 15531-2:2015en,fr,de01-december-2015SIST EN 15531-2:2015SLOVENSKI
STANDARDSIST-TS CEN/TS 15531-2:20091DGRPHãþD
SIST EN 15531-2:2015
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 15531-2
August 2015 ICS 35.240.60 Supersedes CEN/TS 15531-2:2007English Version
Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications Transport public - Interface de service pour les informations en temps réel relatives aux opérations de transport public - Partie 2 : Infrastructure des communications
Öffentlicher Verkehr - Serviceschnittstelle für Echtzeitinformationen bezogen auf Operationen im öffentlichen Verkehr - Teil 2: Kommunikationsstruktur This European Standard was approved by CEN on 20 June 2015.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2015 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 15531-2:2015 ESIST EN 15531-2:2015
EN 15531-2:2015 (E) 2 Contents Page European foreword .4 Introduction .5 1 Scope .6 2 Normative references .7 3 Terms and definitions .7 4 Symbols and abbreviations .7 5 Common communication aspects .7 5.1 Data Exchange Patterns of Interaction .7 5.2 Delivery Patterns. 11 5.3 Mediation Behaviour . 16 5.4 Recovery Considerations for Publish Subscribe . 20 5.5 Recovery Considerations for Direct Delivery . 24 5.6 Request Parameters and Interactions . 24 5.7 Error Conditions for Requests . 27 5.8 Versioning . 29 5.9 Access Controls: Security and Authentication . 29 5.10 Service Discovery . 30 5.11 Capability Matrix . 32 6 Request/Response. 33 6.1 Making a Direct Request . 33 6.2 Receiving a Data Delivery . 39 7 Subscriptions . 44 7.1 Setting up Subscriptions . 44 7.2 Subscription Validity . 51 7.3 Terminating Subscriptions . 51 8 Delivering data . 55 8.1 Direct Delivery . 55 8.2 Fetched Delivery . 56 8.3 Delegated Delivery +SIRI 2.0 . 60 9 Recovery from system failure . 60 9.1 Introduction . 60 9.2 Recovery after Client Failure . 60 9.3 Recovery after Server Failure . 61 9.4 Reset after Interruption of Communication . 61 9.5 Alive Handling . 62 9.6 Additional Failure modes for delegated delivery (+SIRI v2.0) . 66 10 Transport of SIRI messages . 66 10.1 Separation of Addressing from Transport Protocol . 66 10.2 Logical Endpoint Addresses . 66 10.3 Parallelism and Endpoint Addresses . 68 10.4 Encoding of XML messages . 69 10.5 Use of SIRI with SOAP / WSDL . 73 11 Capability Discovery Requests . 83 11.1 General . 83 SIST EN 15531-2:2015
EN 15531-2:2015 (E) 3 11.2 Capability Request . 83 11.3 Service Capability Discovery . 85 11.4 Functional Service Capability Permission Matrix . 90 12 SIRI for Simple Web Services – SIRI Lite (+SIRI v2.0) . 94 12.1 Introduction . 94 12.2 Encoding of URL Requests . 96 12.3 Examples . 98 12.4 Mapping of SIRI XML to Alternative encodings. 112 12.5 Recommendations for the use of SIRI Simple Web Services . 113 13 Common SIRI elements & Data Types . 114 13.1 General . 114 13.2 Introduction . 115 13.3 Base Data Types . 115 13.4 Shared Elements & Structures . 116 13.5 Shared groups of elements . 118 13.6 OperationalBlockGroup — Group . 128 13.7 OperationalInfoGroup — Group . 128 Bibliography . 129
SIST EN 15531-2:2015
EN 15531-2:2015 (E) 4 European foreword This document (EN 15531-2:2015) has been prepared by Technical Committee CEN/TC 278 “Intelligent transport systems”, the secretariat of which is held by NEN. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by February 2016 and conflicting national standards shall be withdrawn at the latest by February 2016. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights. This document supersedes CEN/TS 15531-2:2007. This document presents Part 2 of the European Standard known as “SIRI”. SIRI provides a framework for specifying communications and data exchange protocols for organizations wishing to exchange Real-time Information (RTI) relating to public transport operations. The SIRI European Standard 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 PT, ET, ST, SM, VM, CT, CM, GM (Part 3). Two additional parts define additional functional services as CEN Technical Specifications: — additional data structures for additional application interface module FM (Part 4); — additional data structures for additional application interface module SX (Part 5). 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 recognized that SIRI is not complete as it stands, and from time to time may need to continue to be enhanced to add additional capabilities. 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 implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. SIST EN 15531-2:2015
EN 15531-2:2015 (E) 5 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 European Standard 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, as well as between server and end-user devices like smartphones or web browsers. 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 European Standard will improve a number of features of public transport information and service management: — Interoperability – the European Standard 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; (iii) 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 European Standard 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 European Standard 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 European Standard readily extensible in future. SIST EN 15531-2:2015
EN 15531-2:2015 (E) 6 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, 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. Publish/Subscribe will not normally be used to support large numbers of end user devices. 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. Fetched Delivery is a stateful pattern in its own right. Each delivery pattern allows different trade-offs for implementation efficiency to be made as appropriate for different target environments. A SIRI implementation may support either or both delivery methods; in order to make the most efficient use of the available computational and communication resources. The delivery method may either be preconfigured and static for a given implementation, or each request or subscription may indicate the delivery method required by the client dynamically as part of the request policy, and the server may refuse a request if it does not support that method, giving an appropriate error code. The Interaction patterns and the Delivery patterns are independent aspects of the SIRI protocol and may be used in any combination in different implementations. For a given SIRI Functional Service type (Connection Monitoring, Stop Monitoring, etc.), the message payload content is the same regardless of whether information is exchanged with a Request/Response or Publish/Subscribe pattern, or whether it is returned by Direct or Fetched Delivery. The SIRI Publish/Subscribe Protocol prescribes particular mediation behaviour for reducing the number of notifications and the amount of network traffic arising from subscriptions. The mediation groups the various subscriptions from a subscriber into one or more Subscriber Channels, and is able to manage notifications and updates for the aggregate. SIST EN 15531-2:2015
EN 15531-2:2015 (E) 7 Only partial updates to the data set since the last delivery for the subscription need to be sent. The SIRI Communication protocols are designed to fail gracefully. Considerations for resilience and recovery are covered below. 2 Normative references The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. EN 15531-1:2015, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework 3 Terms and definitions For the purposes of this document, the terms and definitions given in EN 15531-1:2015 apply. 4 Symbols and abbreviations For the purposes of this document, the symbols and abbreviations given in EN 15531-1:2015 apply. 5 Common communication aspects 5.1 Data Exchange Patterns of Interaction 5.1.1 Introduction There are two main patterns of interaction for Data Exchange in SIRI: Request/Response and Publish/Subscribe. The patterns are complementary, that is an implementation may support both, and implementers may choose the most efficient pattern according to the nature of their application. NOTE Publish/Subscribe can emulate a Request/Response interaction by use of a short subscription. A partial SIRI implementation that supports only Request/Response is useful for connecting many types of Public Transport Information System applications to AVMS and other Producer System data. 5.1.2 Request/Response Pattern The Request/Response interaction allows for the immediate fulfilment of one-off data supply requests made by a Requestor to a Service. Pairs of Request/Response patterns are also used for the interactions that make up other patterns, such as Publish/Subscribe. In the Request/Response interaction used to get data, the Client sends a request message to a Server that offers the required SIRI Functional Service, and immediately receives a Delivery message in response (Figure 1). A Data Delivery may be made as a one-step Direct Delivery, or as a two-step Fetched Delivery (see later). The Requestor shall give a unique reference to each request, which will be returned in the matching response. SIST EN 15531-2:2015
EN 15531-2:2015 (E) 8 The Requestor expresses its specific interests through Topic and Delivery Policy parameters on the specific SIRI Functional Service Requests. If the request cannot be satisfied an error condition is returned diagnosing the reason.
Figure 1 — Request / Response Interaction Request/response allows for an efficient transmission of data on-demand from the Consumer, and is extremely easy to implement using commodity internet software components. 5.1.3 Publish/Subscribe Pattern The Publish/Subscribe interaction (see Figure 2) allows for the asynchronous detection of real-time events by a producer service, whose role is to generate and send notifications to one or more interested consumers. In the Publish/Subscribe interaction, the Subscriber client sends a request message to the Notification Producer of a SIRI Functional Service to create a Subscription, which may or may not be granted. The Subscriber expresses its specific interests through Topic and Subscription Policy parameters, and receives an acknowledgement that this has been created, or an error condition. Once a Subscription exists, the service, acting as the Notification Producer, uses it to determine when to send a notification to a consumer after a Situation, i.e. event is detected. The incoming event notification to be published is matched against the interests expressed by the Topic and other filter parameters of the Subscription and if satisfied, a notification message is sent to the Consumer. The actual Notification Message Delivery may be made either as a one-step Direct Delivery to a Notification Consumer, or as a two-step SIRI Fetched Delivery, with separate message pairs first to notify and then to deliver the payload. In SIRI, the Subscriber and Consumer roles are normally implemented by the same client service, although they are logically separate. Every Consumer shall know its Subscriber so that they can interact to handle recovery from service failures. Subscriptions for different types of SIRI Functional Service are managed separately. A Subscriber may add different Subscriptions at different times. A Subscription Request includes an Initial Termination Time indicating the desired duration i.e. lease of the individual Subscription. The subscription will only be granted if this can be met, otherwise an error will be returned. Subscriptions have a life span as specified by the Subscriber, and will be terminated by the Notification Producer service when they reach their expiry time. Subscribers may terminate their own existing Subscriptions before their predefined expiry time through a Subscription Manager. The Subscription Manager is subordinate to the Notification Producer, and in SIRI implementations, is normally provided by the same entity, although logically distinct. Each Subscription Manager knows its associated Notification Producer, and vice versa. Although the Notification Producer is the factory for creating new subscriptions, it does not manage them once created; rather this is done by the SIST EN 15531-2:2015
EN 15531-2:2015 (E) 9 Subscription Manager. This design (i.e. the Notification Producer finds the Subscription Manager for the Subscriber, rather than the Subscription Manager finds the Notification Producer for the Subscriber) is required to conform to the WS-PubSub architecture. The WS-PubSub architecture allows for additional Subscription management functions to be added through the Subscription Manager for example renewal, pause/resume, or the dynamic tuning of subscription policies, but SIRI does not specify any of these at present. SIRI does however support a Terminate Subscription and a Terminate All Subscriptions function.
Figure 2 — Simple Publish/Subscribe Interaction Subscriptions are a stateful resource: they need a unique identifier that can be used by Subscriber, Producer and Consumer to refer to the same subscription on different occasions. They will each hold their own representation of the subscription. In SIRI this identifier is issued by the Subscriber. Publish/Subscribe allows for an efficient regular event driven exchange of updates to data. It requires a more elaborate implementation, with the holding of state by both participants and the dedication of computing resources to run the notification production. 5.1.4 Publish/Subscribe with Broker Pattern The WS-PubSub architecture also allows for the logical separation of the concerns of Publishing and Notification Production, and in its fully articulated form, has a separate Publisher role that is a subordinate constituent of the Notification Producer service (see Figure 3). The Publisher produces notifications of any significant situations, i.e. events. For a real-time service, the Publisher monitors the real-time data and if a change has occurred, it produces a notification. The Notification Producer then matches the Notification with the interests and policies expressed by Subscribers and despatches the notification delivery to the Notification Consumer indicated by the Subscription. It is possible to have more than one Notification Producer sitting between the Publisher and the Consumer, either to carry out successive types of filtering and processing of the notifications, or for scalability. WS-PubSub distinguishes between direct notification – where the notification message from the Publisher is delivered unchanged, and brokered notification – where the Notification Producer filters and also possibly transforms the message. Both brokered (e.g. for SIRI Stop Monitoring) and unbrokered (e.g. for SIRI General Message) mediation occurs in different SIRI Functional Services. SIST EN 15531-2:2015
EN 15531-2:2015 (E) 10 The separation of concerns between Publisher and Notification producer is transparent to the Subscriber and Consumer, and so in SIRI is merely an implementation choice – which does not currently explicitly mandate any requirements for the interface between the Notification Producer and Publisher. Every Publisher knows its associated Notification Producer(s), and vice versa.
Figure 3 — Brokered Publish/Subscribe Interaction Further Subscription and Subscriber f
...
SLOVENSKI STANDARD
oSIST prEN 15531-2:2013
01-december-2013
-DYQLSUHYR]9PHVQLN]DLQIRUPLUDQMHYUHDOQHPþDVX]DSRWUHEHGHORYDQMD
MDYQHJDSUHYR]DGHO .RPXQLNDFLMH
Public transport - Service interface for real-time information relating to public transport
operations - Part 2: Communications
Öffentlicher Verkehr - Serviceschnittstelle für Echtzeitinformationen bezogen auf
Operationen im öffentlichen Verkehr - Teil 2: Kommunikationsstruktur
Ta slovenski standard je istoveten z: prEN 15531-2 rev
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
oSIST prEN 15531-2:2013 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 15531-2:2013
---------------------- Page: 2 ----------------------
oSIST prEN 15531-2:2013
EUROPEAN STANDARD
DRAFT
prEN 15531-2 rev
NORME EUROPÉENNE
EUROPÄISCHE NORM
October 2013
ICS 35.240.60 Will supersede CEN/TS 15531-2:2007
English Version
Public transport - Service interface for real-time information
relating to public transport operations - Part 2: Communications
Öffentlicher Verkehr - Serviceschnittstelle für
Echtzeitinformationen bezogen auf Operationen im
öffentlichen Verkehr - Teil 2: Kommunikationsstruktur
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee CEN/TC 278.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations which
stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other language
made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2013 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 15531-2 rev:2013: E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 15531-2:2013
prEN 15531-2:2013 (E)
Contents Page
Foreword .6
1 Scope .7
2 Normative references .8
3 Terms and definitions .9
4 Symbols and abbreviations .9
5 Common communication aspects .9
5.1 Data Exchange Patterns of Interaction .9
5.1.1 Introduction .9
5.1.2 Request/Response Pattern .9
5.1.3 Publish/Subscribe Pattern . 10
5.1.4 Publish/Subscribe with Broker Pattern . 11
5.1.5 Request/Response – Compound Requests . 12
5.1.6 Publish/Subscribe – Compound Subscriptions . 12
5.2 Delivery Patterns. 13
5.2.1 Introduction . 13
5.2.2 Direct Delivery . 13
5.2.3 Fetched Delivery . 14
5.2.4 Data Horizon for Fetched Delivery . 15
5.2.5 Get Current Message . 16
5.2.6 Multipart Despatch of a Delivery . 16
5.2.7 Multipart Despatch of a Fetched Delivery – MoreData. 16
5.3 Mediation Behaviour . 17
5.3.1 Introduction . 17
5.3.2 Mediation Behaviour – Maintaining Subscription Last Updated State . 17
5.3.3 Mediation Behaviour – Subscription Filters . 20
5.4 Recovery Considerations for Publish Subscribe . 22
5.4.1 Introduction . 22
5.4.2 Check Status – Polling . 23
5.4.3 Heartbeat – Pinging . 23
5.4.4 Degrees of Failure. 23
5.4.5 Detecting a Failure of the Producer . 24
5.4.6 Detecting a Failure of the Consumer . 25
5.5 Recovery Considerations for Direct Delivery . 26
5.6 Request Parameters and Interactions . 26
5.7 Error Conditions for Requests . 29
5.8 Versioning . 30
5.8.1 Introduction . 30
5.8.2 The Overall SIRI Framework Version Level . 31
5.8.3 The SIRI Functional Service Type Version Level . 31
5.9 Access Controls: Security and Authentication . 31
5.9.1 Introduction . 31
5.9.2 System Mechanisms External to SIRI Messages . 31
5.10 Service Discovery . 32
5.10.1 Introduction . 32
5.10.2 Discovery of Servers that Support SIRI Services . 32
5.10.3 Discovery of the Capabilities of a SIRI Server . 32
5.10.4 Discovery of the Coverage of a Given SIRI Functional Service . 33
5.11 Capability Matrix . 33
5.11.1 Introduction . 33
2
---------------------- Page: 4 ----------------------
oSIST prEN 15531-2:2013
prEN 15531-2:2013 (E)
5.11.2 SIRI General Capabilities . 34
6 Request/Response . 35
6.1 Making a Direct Request . 35
6.1.1 Introduction . 35
6.1.2 ServiceRequest Message — Element . 36
6.1.3 The ServiceRequestContext — Element . 38
6.1.4 Common Properties of ServiceRequest Messages — Element. 39
6.1.5 ServiceRequest — Example . 40
6.1.6 Access Controls on a Request . 41
6.2 Receiving a Data Delivery . 42
6.2.1 Introduction . 42
6.2.2 ServiceDelivery . 43
7 Subscriptions . 46
7.1 Setting up Subscriptions . 46
7.1.1 Introduction . 46
7.1.2 SubscriptionRequest . 48
7.1.3 SubscriptionResponse . 50
7.2 Subscription Validity . 53
7.3 Terminating Subscriptions . 53
7.3.1 Introduction . 53
7.3.2 The TerminateSubscriptionRequest . 53
7.3.3 TerminateSubscriptionResponse . 55
8 Delivering data . 56
8.1 Direct Delivery . 56
8.1.1 Introduction . 56
8.1.2 Acknowledging Receipt of Data (DataReceivedAcknowledgement) . 56
8.2 Fetched Delivery . 57
8.2.1 Introduction . 57
8.2.2 Signalling Data Availability (DataReadyNotification / DataReadyResponse) . 58
8.2.3 Polling Data (DataSupplyRequest/ServiceDelivery) . 60
8.3 Delegated Delivery +SIRI 2.0 . 61
9 Recovery from system failure . 61
9.1 Introduction . 61
9.2 Recovery after Client Failure . 62
9.3 Recovery after Server Failure . 62
9.4 Reset after Interruption of Communication . 62
9.5 Alive Handling . 63
9.5.1 Introduction . 63
9.5.2 CheckStatusRequest . 63
9.5.3 CheckStatusResponse . 64
9.5.4 HeartbeatNotification . 66
9.6 Additional Failure modes for delegated delivery (+SIRI v2.0) . 67
10 Transport of SIRI messages . 67
10.1 Separation of Addressing from Transport Protocol . 67
10.2 Logical Endpoint Addresses . 68
10.2.1 Endpoint Addresses . 68
10.2.2 Endpoint Address — Examples . 68
10.3 Parallelism and Endpoint Addresses . 70
10.4 Encoding of XML messages . 70
10.4.1 Principles. 70
10.4.2 Encoding of Errors in XML . 70
10.4.3 Character Set . 70
10.4.4 Schema Packages . 71
10.4.5 Siri.XSD – Use of XML Choice . 71
10.4.6 SiriSG.XSD – Use of XML Substitution groups . 73
10.5 Use of SIRI with SOAP / WSDL . 75
10.5.1 Introduction . 75
3
---------------------- Page: 5 ----------------------
oSIST prEN 15531-2:2013
prEN 15531-2:2013 (E)
10.5.2 Web Services . 75
10.5.3 Use of SOAP . 77
10.5.4 SIRI WSDL . 77
10.5.5 SIRI WSDL structure . 78
10.5.6 SIRI RPC WSDL . 80
10.5.7 SIRI Document WSDL (+SIRI v2.0) . 83
10.5.8 SIRI WSDL 2.0 (+SIRI v2.0) . 84
10.5.9 SIRI WSDL Status . 84
11 Capability Discovery Requests . 85
11.1 General . 85
11.2 Capability Request. 85
11.3 Service Capability Discovery . 86
11.3.1 Service Capability Discovery Request — Element . 86
11.3.2 Service Capability Discovery Response — Element . 86
11.3.3 Functional Service Capability Discovery Response — Element . 87
11.3.4 Service Capability Response — Example . 89
11.4 Functional Service Capability Permission Matrix . 91
11.4.1 Introduction . 91
11.4.2 OperatorPermissions — Element . 92
11.4.3 LinePermissions — Element . 92
11.4.4 ConnectionLinkPermissions — Element . 93
11.4.5 StopMonitorPermissions — Element. 93
11.4.6 VehicleMonitorPermissions — Element . 94
11.4.7 InfoChannelPermissions — Element . 94
12 SIRI for Simple Web Services – SIRI Lite (+SIRI v2.0) . 94
12.1 Introduction . 94
12.1.1 Existing Implementations . 95
12.1.2 Using SIRI-LITE services in combination . 96
12.1.3 Alternative Response Encoding . 96
12.1.4 Lossless transforms . 97
12.1.5 Simple transforms . 97
12.2 Encoding of URL Requests . 97
12.2.1 Complete Request Encoding in HTTP URL’s . 97
12.2.2 General format of SIRI Lite request URL . 98
12.2.3 Endpoints and Service Identification . 98
12.2.4 Encoding of Service Parameters on http request . 98
12.2.5 Naming of Request Parameters with Hierarchy . 99
12.2.6 Naming of Parameters with Plural Cardinality . 99
12.2.7 Handling of invalid request combinations . 99
12.2.8 Specifying the encoding of the Response . 99
12.3 Examples . 99
12.3.1 SIRI-SM Simple Stop Monitoring request to fetch stop departures – SIRI LITE Examples . 99
12.3.2 SIRI-VM Simple Vehicle Monitoring request to fetch vehicle positions – SIRI Lite
Examples . 102
12.3.3 SIRI-VM Complex Vehicle Monitoring to obtain journeys – SIRI Lite Examples . 105
12.3.4 SIRI-SM Stop Monitoring failed request with Exception – SIRI LITE Examples . 111
12.4 Mapping of SIRI XML to Alternative encodings . 112
12.4.1 Use of syntactic features of alternative rendering formats . 112
12.4.2 Mapping of SIRI data types to alternative encodings . 112
12.5 Recommendations for the use of SIRI Simple Web Services . 112
12.5.1 Services useful for device Passenger Information Services . 112
12.5.2 Response filtering. 112
12.5.3 Incorporation of reference data in responses . 113
12.5.4 Multiple functional service deliveries in the same response . 113
12.5.5 Support a choice of response encodings . 113
12.5.6 Provide reporting identifiers . 113
13 Common SIRI elements & Data Types . 114
4
---------------------- Page: 6 ----------------------
oSIST prEN 15531-2:2013
prEN 15531-2:2013 (E)
13.1 General . 114
13.2 Introduction . 115
13.3 Base Data Types . 115
13.3.1 W3C Simple Types . 115
13.3.2 SIRI Simple Types . 115
13.3.3 NationalLanguageStringStructure — Element . 116
13.4 Shared Elements & Structures . 116
13.4.1 FramedVehicleJourneyRef — Element . 116
13.4.2 Location — Element . 116
13.4.3 Error — Element . 117
13.5 Shared groups of elements . 118
13.5.1 ServiceInfoGroup — Group . 118
13.5.2 JourneyInfoGroup — Group . 118
13.5.3 VehicleJourneyInfoGroup — Group . 119
13.5.4 JourneyPatternInfoGroup — Group . 121
13.5.5 DisruptionGroup — Group . 122
13.5.6 JourneyProgressGroup — Group . 124
13.6 OperationalBlockGroup — Group .
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.