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
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.
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.
Ö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 .
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.