SIST EN 15531-2:2023
(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
Service Interface for Real Time Information (SIRI) is a specification for an interface that allows systems running computer applications to exchange information about the planned, current or projected performance of the public transport operations.
The scope of this WI is to update CEN/EN 15531-2:2015 which allows pairs of server computers to exchange structured real-time information about schedules, vehicles, and connections, together with general informational messages related to the operation of the services. The information can be used for many different purposes, for example:
• To provide real time-departure from stop information for display on stops, internet and mobile delivery systems;
• To provide real-time progress information about individual vehicles;
• To manage the movement of buses roaming between areas covered by different servers;
• To manage the synchronisation of guaranteed connections between fetcher and feeder services;
• To exchange planned and real-time timetable updates;
• To distribute status messages about the operation of the services;
• To provide performance information to operational history and other management systems.
Implementations SIRI have revealed a number of improvements and some minor enhancements necessary for a successful and uniform usage of the specification in the future.
The main elements out of this work item will be:
o Prepare an updated edition of the TS as a document
o Update the common XSD of SIRI parts 1-5
The new work item will consider the projects of
o PT companies and IT-suppliers especially in Switzerland, Germany, France, Netherlands and Sweden
o Railway traffic
o accessibility in public transport
Ö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 : 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 œuvre 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 Édition/Abonnement.
• Le schéma Demande/Réponse permet l'échange ad hoc de données sur demande du client,
• Le schéma Édition/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 Édition/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 Édition/Abonnement en différents rôles et interfaces définis (Abonné, Éditeur, Producteur ou Destinataire de notifications, par exemple) : dans le cadre d'une mise en œuvre 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 Édition/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.
[...]
Javni prevoz - Vmesnik za informiranje v realnem času za potrebe delovanja javnega prevoza - 2. del: Komunikacijska infrastruktura
Vmesnik za informiranje v realnem času (SIRI) je specifikacija za vmesnik, ki sistemom, v katerih se izvajajo računalniške aplikacije, omogoča izmenjavo informacij o načrtovanem, trenutnem ali predvidenem poteku javnega prevoza.
Področje uporabe tega dokumenta WI je posodobitev standarda CEN/EN 15531-2:2015, ki parom strežniških računalnikov omogoča izmenjavo strukturiranih informacij v realnem času o voznih redih, vozilih in povezavah, skupaj s splošnimi informativnimi sporočili, povezanimi z delovanjem storitev. Podatke je mogoče uporabiti za različne namene, na primer za:
• zagotavljanje informacij o dejanskem času odhoda s postajališča, ki so prikazane na postajališčih, v internetu in mobilnih sistemih za dostavo;
• zagotavljanje informacij o poti posameznih vozil v realnem času;
• upravljanje poti avtobusov med območji, ki jih pokrivajo različni strežniki;
• upravljanje sinhronizacije zajamčenih povezav med storitvami pridobivanja in podajanja;
• izmenjavo načrtovanih in sprotnih posodobitev voznega reda;
• distribucijo statusnih sporočil o delovanju storitev;
• zagotavljanje informacij o učinkovitosti za operativno zgodovino in druge sisteme upravljanja.
Izvedbe vmesnika SIRI razkrivajo številne izboljšave in nekatere podrobnosti, potrebne za uspešno in enotno uporabo specifikacije v prihodnosti.
Glavni elementi teh popravkov bodo:
• priprava posodobljene izdaje tehnične specifikacije kot dokumenta;
• posodobitev skupnega XSD-ja delov vmesnika SIRI 1–5.
Nova delovna postavka bo obravnavala projekte:
• PT-podjetij in IT-dobaviteljev, zlasti v Švici, Nemčiji, Franciji, na Nizozemskem in Švedskem;
• železniškega prometa;
• dostopnosti v javnem prometu.
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST EN 15531-2:2023
01-maj-2023
Nadomešča:
SIST EN 15531-2:2015
Javni prevoz - Vmesnik za informiranje v realnem času za potrebe delovanja
javnega prevoza - 2. del: Komunikacijska infrastruktura
Public transport - Service interface for real-time information relating to public transport
operations - Part 2: Communications infrastructure
Ö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 : Communications
Ta slovenski standard je istoveten z: EN 15531-2:2022
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
SIST EN 15531-2:2023 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST EN 15531-2:2023
---------------------- Page: 2 ----------------------
SIST EN 15531-2:2023
EN 15531-2
EUROPEAN STANDARD
NORME EUROPÉENNE
November 2022
EUROPÄISCHE NORM
ICS 35.240.60 Supersedes EN 15531-2:2015
English Version
Public transport - Service interface for real-time
information relating to public transport operations - Part
2: Communications infrastructure
Transport public - Interface de service pour les Öffentlicher Verkehr - Dienstschnittstelle für
informations en temps réel relatives aux opérations de Echtzeitinformationen bezogen auf Operationen im
transport public - Partie 2 : Communications öffentlichen Verkehr - Teil 2:
Kommunikationsinfrastruktur
This European Standard was approved by CEN on 16 October 2022.
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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 15531-2:2022 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST EN 15531-2:2023
EN 15531-2:2022 (E)
Contents Page
European Foreword . 6
Introduction . 8
1 Scope . 10
2 Normative references . 11
3 Terms and definitions . 11
4 Symbols and abbreviations . 11
5 Common communication aspects . 11
5.1 Data Exchange Patterns of Interaction . 11
5.1.1 Introduction . 11
5.1.2 Request/Response Pattern . 11
5.1.3 Publish/Subscribe Pattern . 12
5.1.4 Publish/Subscribe with Broker Pattern . 13
5.1.5 Request/Response – Compound Requests . 14
5.1.6 Publish/Subscribe – Compound Subscriptions. 15
5.2 Delivery Patterns . 15
5.2.1 Introduction . 15
5.2.2 Direct Delivery . 15
5.2.3 Fetched Delivery . 16
5.2.4 Data Horizon for Fetched Delivery . 17
5.2.5 Get Current Message . 18
5.2.6 Multipart Despatch of a Delivery . 18
5.2.7 Multipart Despatch of a Fetched Delivery – MoreData . 19
5.3 Mediation Behaviour . 20
5.3.1 Introduction . 20
5.3.2 Mediation Behaviour – Maintaining Subscription Last Updated State . 20
5.3.3 Mediation Behaviour – Subscription Filters . 23
5.4 Recovery Considerations for Publish Subscribe . 25
5.4.1 Introduction . 25
5.4.2 Check Status – Polling . 25
5.4.3 Heartbeat – Pinging . 25
5.4.4 Degrees of Failure . 26
5.4.5 Detecting a Failure of the Producer . 26
5.4.6 Detecting a Failure of the Consumer . 28
5.5 Recovery Considerations for Direct Delivery . 29
5.6 Request Parameters and Interactions . 29
5.7 Error Conditions for Requests . 32
5.8 Versioning . 34
5.8.1 Introduction . 34
5.8.2 The Overall SIRI Framework Version Level . 34
5.8.3 The SIRI Functional Service Type Version Level . 34
5.9 Access Controls: Security and Authentication . 34
5.9.1 Introduction . 34
5.9.2 System Mechanisms External to SIRI Messages . 35
5.10 Service Discovery . 36
5.10.1 Introduction . 36
5.10.2 Discovery of Servers that Support SIRI Services . 36
5.10.3 Discovery of the Capabilities of a SIRI Server . 36
5.10.4 Discovery of the Coverage of a Given SIRI Functional Service . 36
2
---------------------- Page: 4 ----------------------
SIST EN 15531-2:2023
EN 15531-2:2022 (E)
5.11 Capability Matrix . 37
5.11.1 Introduction . 37
5.11.2 SIRI General Capabilities . 38
6 Request/Response . 39
6.1 Making a Direct Request . 39
6.1.1 Introduction . 39
6.1.2 ServiceRequest Message — Element . 39
6.1.3 The ServiceRequestContext — Element . 41
6.1.4 Common Properties of ServiceRequest Messages — Element . 43
6.1.5 ServiceRequest — Example . 44
6.1.6 Access Controls on a Request . 44
6.2 Receiving a Data Delivery . 45
6.2.1 Introduction . 45
6.2.2 ServiceDelivery . 46
7 Subscriptions . 50
7.1 Setting up Subscriptions . 50
7.1.1 Introduction . 50
7.1.2 SubscriptionRequest . 51
7.1.3 SubscriptionResponse . 54
7.2 Subscription Validity . 57
7.3 Terminating Subscriptions . 57
7.3.1 Introduction . 57
7.3.2 The TerminateSubscriptionRequest. 57
7.3.3 The TerminateSubscriptionResponse . 58
7.3.4 The SubscriptionTerminatedNotification (+SIRI 2.0) . 60
8 Delivering data . 62
8.1 Direct Delivery . 62
8.1.1 Introduction . 62
8.1.2 Acknowledging Receipt of Data (DataReceivedAcknowledgement) . 62
8.2 Fetched Delivery . 63
8.2.1 Introduction . 63
8.2.2 Signalling Data Availability (DataReadyNotification / DataReadyResponse) . 63
8.2.3 Polling Data (DataSupplyRequest/ServiceDelivery) . 65
8.3 Delegated Delivery +SIRI 2.0 . 67
9 Recovery from system failure . 67
9.1 Introduction . 67
9.2 Recovery after Client Failure . 67
9.3 Recovery after Server Failure. 68
9.4 Reset after Interruption of Communication . 68
9.5 Alive Handling . 69
9.5.1 Introduction . 69
9.5.2 CheckStatusRequest . 69
9.5.3 CheckStatusResponse . 70
9.5.4 HeartbeatNotification. 71
9.6 Additional Failure modes for delegated delivery (+SIRI v2.0) . 72
10 Transport of SIRI messages . 73
10.1 Separation of Addressing from Transport Protocol . 73
10.2 Logical Endpoint Addresses . 73
10.2.1 Endpoint Addresses . 73
10.2.2 Endpoint Address — Examples . 74
10.3 Parallelism and Endpoint Addresses . 75
10.4 Encoding of XML messages . 76
10.4.1 Principles . 76
10.4.2 Encoding of Errors in XML . 76
10.4.3 Character Set . 76
10.4.4 Schema Packages . 76
3
---------------------- Page: 5 ----------------------
SIST EN 15531-2:2023
EN 15531-2:2022 (E)
10.4.5 Siri.XSD – Use of XML Choice . 77
10.4.6 SiriSG.XSD – Use of XML Substitution groups . 78
10.5 Use of SIRI with SOAP / WSDL . 79
10.5.1 Introduction . 79
10.5.2 Web Services . 80
10.5.3 Use of SOAP . 82
10.5.4 SIRI WSDL . 82
10.5.5 SIRI WSDL structure . 83
10.5.6 SIRI RPC WSDL . 86
10.5.7 SIRI Document WSDL (+SIRI v2.0) . 90
10.5.8 SIRI WSDL 2.0 (+SIRI v2.0) . 91
10.5.9 SIRI WSDL Status . 91
11 Capability Discovery Requests . 91
11.1 General . 91
11.2 Capability Request . 91
11.3 Service Capability Discovery . 92
11.3.1 Service Capability Discovery Request — Element . 92
11.3.2 Service Capability Discovery Response — Element . 93
11.3.3 Functional Service Capability Discovery Response — Element . 94
11.3.4 Service Capability Response — Example . 96
11.4 Functional Service Capability Permission Matrix . 98
11.4.1 Introduction . 98
11.4.2 OperatorPermissions — Element . 99
11.4.3 LinePermissions — Element . 99
11.4.4 ConnectionLinkPermissions — Element . 99
11.4.5 StopMonitorPermissions — Element . 100
11.4.6 VehicleMonitorPermissions — Element . 100
11.4.7 InfoChannelPermissions — Element . 101
12 SIRI for Simple Web Services – SIRI Lite (+SIRI v2.0) . 101
12.1 Introduction . 101
12.1.1 Existing Implementations . 102
12.1.2 Using SIRI-LITE services in combination . 102
12.1.3 Alternative Response Encoding . 103
12.1.4 Lossless transforms . 104
12.1.5 Simple transforms . 104
12.2 Encoding of URL Requests . 104
12.2.1 Complete Request Encoding in HTTP URL’s . 104
12.2.2 General format of SIRI Lite request URL . 104
12.2.3 Endpoints and Service Identification . 105
12.2.4 Encoding of Service Parameters on http request . 105
12.2.5 Naming of Request Parameters with Hierarchy . 106
12.2.6 Naming of Parameters with Plural Cardinality . 106
12.2.7 Handling of invalid request combinations . 106
12.2.8 Specifying the encoding of the Response . 106
12.3 Examples . 106
12.3.1 General . 106
12.3.2 SIRI-SM Simple Stop Monitoring request to fetch stop departures – SIRI LITE Examples . 106
12.3.3 SIRI-VM Simple Vehicle Monitoring request to fetch vehicle positions – SIRI Lite examples . 110
12.3.4 SIRI-VM Complex Vehicle Monitoring to obtain journeys – SIRI Lite examples . 113
12.3.5 SIRI-SM Stop Monitoring failed request with Exception – SIRI LITE examples . 120
12.4 Mapping of SIRI XML to Alternative encodings . 121
12.4.
...
SLOVENSKI STANDARD
oSIST prEN 15531-2:2021
01-september-2021
Javni prevoz - Vmesnik za informiranje v realnem času za potrebe delovanja
javnega prevoza - 2. del: Komunikacijska infrastruktura
Public transport - Service interface for real-time information relating to public transport
operations - Part 2: Communications infrastructure
Ö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 : Communications
Ta slovenski standard je istoveten z: prEN 15531-2
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
oSIST prEN 15531-2:2021 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:2021
---------------------- Page: 2 ----------------------
oSIST prEN 15531-2:2021
DRAFT
EUROPEAN STANDARD
prEN 15531-2
NORME EUROPÉENNE
EUROPÄISCHE NORM
July 2021
ICS 35.240.60 Will supersede EN 15531-2:2015
English Version
Public transport - Service interface for real-time
information relating to public transport operations - Part
2: Communications infrastructure
Transport public - Interface de service pour les Öffentlicher Verkehr - Serviceschnittstelle für
informations en temps réel relatives aux opérations de Echtzeitinformationen bezogen auf Operationen im
transport public - Partie 2 : Infrastructure des öffentlichen Verkehr - Teil 2: Kommunikationsstruktur
communications
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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, 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
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2021 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 15531-2:2021 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 15531-2:2021
prEN 15531-3:2021 (E)
Contents Page
European foreword . 4
Introduction . 5
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.2 Delivery Patterns . 12
5.3 Recovery Considerations for Publish Subscribe . 21
5.4 Recovery Considerations for Direct Delivery . 25
5.5 Request Parameters and Interactions . 25
5.6 Error Conditions for Requests . 28
5.7 Versioning . 30
5.8 Access Controls: Security and Authentication . 31
5.9 Service Discovery . 32
5.10 Capability Matrix . 33
6 Request/Response . 35
6.1 Making a Direct Request . 35
6.2 Receiving a Data Delivery . 43
6.3 ServiceDelivery . 44
7 Subscriptions . 49
7.1 Setting up Subscriptions . 49
7.2 Subscription Validity . 56
7.3 Terminating Subscriptions . 57
8 Delivering data . 62
8.1 Direct Delivery . 62
8.2 Fetched Delivery . 63
8.3 Delegated Delivery +SIRI 2.0. 68
9 Recovery from system failure . 68
9.1 Introduction . 68
9.2 Recovery after Client Failure . 68
9.3 Recovery after Server Failure . 68
9.4 Reset after Interruption of Communication . 68
9.5 Alive Handling . 70
9.6 Additional Failure modes for delegated delivery (+SIRI v2.0) . 74
10 Transport of SIRI messages . 74
10.1 Separation of Addressing from Transport Protocol . 74
10.2 Logical Endpoint Addresses . 75
10.3 Parallelism and Endpoint Addresses . 77
10.4 Encoding of XML messages . 78
2
---------------------- Page: 4 ----------------------
oSIST prEN 15531-2:2021
prEN 15531-3:2021 (E)
10.5 Use of SIRI with SOAP / WSDL . 81
11 Capability Discovery Requests . 93
11.1 General . 93
11.2 Capability Request. 93
11.3 Service Capability Discovery . 95
11.4 Functional Service Capability Permission Matrix . 101
12 SIRI for Simple Web Services – SIRI Lite (+SIRI v2.0) . 105
12.1 Introduction. 105
12.2 Encoding of URL Requests . 108
12.3 Examples . 110
12.4 Mapping of SIRI XML to Alternative encodings . 124
12.5 Recommendations for the use of SIRI Simple Web Services . 124
13 Common SIRI elements & Data Types . 126
13.1 General . 126
13.2 Introduction. 127
13.3 Base Data Types . 127
13.4 Shared Elements & Structures . 129
13.5 Shared groups of elements . 145
13.6 OperationalBlockGroup — Group . 157
13.7 OperationalInfoGroup — Group . 157
13.8 TypeOfValueGroup — Group (+SIRI 2.1). 158
13.9 JourneyRelationInfoGroup — Group (+SIRI 2.1) . 158
13.10 JourneyPartViewGroup — Group (+SIRI 2.1) . 160
13.11 VehicleTypeGroup — Group (+SIRI 2.1) . 160
13.12 TrainFormationReferenceGroup — Group (+SIRI 2.1) . 161
13.13 QuayAssignmentGroup — Group (+SIRI 2.1). 162
13.14 BoardingPositionAssignmentGroup — Group (+SIRI 2.1) . 164
13.15 FlexibleStopLocationGroup — Group (+SIRI 2.1) . 164
Bibliography . 167
3
---------------------- Page: 5 ----------------------
oSIST prEN 15531-2:2021
prEN 15531-3:2021 (E)
European foreword
This document (prEN 15531-2:2021) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
This document is currently submitted to the CEN Enquiry.
This document will supersede CEN/TS 15531-2:2015.
SIRI (CEN/TS 15531-2:2006) has been a CEN Technical Specification since 2007 and a European
normative standard since 2013 and has been widely used in Europe and elsewhere and proven its
usefulness. This document proposes a revised version of SIRI as a European Standard, and is currently
submitted to the Formal Vote. The proposed revisions are minor enhancements arising from experience
of the deployment of SIRI in many live systems. This document also clarifies the relationship of SIRI to
NeTEx, the CEN Technical Standard for the XML exchange of Public Transport Reference data based on
the Transmodel CEN European Standard.
This document presents Part 2 of the European Standard 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.
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 https://github.com/SIRI-CEN/SIRI, guidance on its use,
example XML files, and case studies of national and local deployments is located at http://siri-cen.eu/.
It is recognised that SIRI is not complete as it stands, and from time to time will 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.
4
---------------------- Page: 6 ----------------------
oSIST prEN 15531-2:2021
prEN 15531-3:2021 (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 document 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 document will improve a number of features of public transport information and service
management:
• Interoperability – the document 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 document 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 document will assist the economic provision of
improved data by; (i) enabling the gathering and exchange of real-time data between AVMS
systems; (ii) providing standardised, well defined interfaces that can be used to deliver data to a
wide variety of distribution channels. Version 2.0 of SIRI includes a new Simple Web Service
designed to support the widespread, massively scalable use of mobile devices and web browsers
and other applications to display public transport data directly to users.
Technical advantages include the following:
• Reusing a common communication layer for all the various technical services enables cost-effective
implementations and makes the document readily extensible in future.
History
Version 1.0 of SIRI was developed in 2004-2005 and submitted to vote, eventually passing through the
CEN process to become an approved CEN Technical Specification in 2007. As well as the normative
Version 1.0 XSD schema, successive informal working versions of the schema (v 1.1 – 1.4) were released
to allow for fixes and to implement some very minor enhancements agreed by the working group. A
WSDL version was also developed.
5
---------------------- Page: 7 ----------------------
oSIST prEN 15531-2:2021
prEN 15531-3:2021 (E)
Version 2.0 of SIRI was developed in 2012 to coincide with making the SIRI standard a full CEN norm.
SIRI includes a Simple Web Services “SIRI-LITE” as an additional transport method and a WSDL
document literal version and a WSDL2 version;
Version 2.1 of SIRI was developed in 2020/21 to address lessons from the now widespread
implementation of SIRI.
The changes in SIRI version 2.1 include:
• remove the direct relationship with TPEG and other standards to enable support as the other
standards change;
• support for new modes in line with TRANSMODEL and NeTEx;
• support for the Reason / Effect / Advice structure for disruptions in SIRI SX;
• increased granularity for occupancy data and Vehicle structures;
• improved subscription renewal options and filtering options;
• additional options and flexibility for STOP POINTS and relationships between journeys;
• migration of XSD to Github to improve access and change control processes.
Compatibility with previous versions
All changes in version 2.1 are intended to be fully backwards compatible, that is to say, existing
documents that validate against earlier versions of the schema will also validate against the 2.1 schema
without alteration (other than to schema version numbers), and version 2.1 documents that do not use
new features will validate against earlier versions. Version 2.1 documents that use new features will not
be backwards compatible.
6
---------------------- Page: 8 ----------------------
oSIST prEN 15531-2:2021
prEN 15531-3:2021 (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, 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.
7
---------------------- Page: 9 ----------------------
oSIST prEN 15531-2:2021
prEN 15531-3:2021 (E)
• 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.
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, 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 apply.
4 Symbols and abbreviations
For the purposes of this document, the symbols and abbreviations given in EN 15531-1 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.
8
---------------------- Page: 10 ----------------------
oSIST prEN 15531-2:2021
prEN 15531-3:2021 (E)
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
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.