DIN EN 15531-2-2015 Public transport - Service interface for real-time information relating to public transport operations - Part 2 Communications English version EN 15531-2 2015《公.pdf

《DIN EN 15531-2-2015 Public transport - Service interface for real-time information relating to public transport operations - Part 2 Communications English version EN 15531-2 2015《公.pdf》由会员分享，可在线阅读，更多相关《DIN EN 15531-2-2015 Public transport - Service interface for real-time information relating to public transport operations - Part 2 Communications English version EN 15531-2 2015《公.pdf（131页珍藏版）》请在麦多课文档分享上搜索。

1、DEUTSCHE NORM Preisgruppe 33DIN Deutsches Institut fr Normung e. V. Jede Art der Vervielfltigung, auch auszugsweise, nur mit Genehmigung des DIN Deutsches Institut fr Normung e. V., Berlin, gestattet.ICS 35.240.60!%?X“2285388www.din.deDIN EN 15531-2ffentlicher Verkehr Serviceschnittstelle fr Echtzei

2、tinformationen bezogen auf Operationen imffentlichen Verkehr Teil 2: Kommunikationsstruktur;Englische Fassung EN 155312:2015Public transport Service interface for realtime information relating to public transport operations Part 2: Communications;English version EN 155312:2015Transport public Interf

3、ace de service pour les informations en temps rel relatives aux oprations de transport public Partie 2: Infrastructure des communications;Version anglaise EN 155312:2015Alleinverkauf der Normen durch Beuth Verlag GmbH, 10772 BerlinErsatz frDIN CEN/TS 155312(DIN SPEC 70655):201106www.beuth.deGesamtum

4、fang 131 SeitenDDIN-Normenausschuss Automobiltechnik (NAAutomobil)Dezember 2015DIN EN 15531-2:2015-12 2 Nationales Vorwort Dieses Dokument (EN 15531-2:2015) wurde vom technischen Komitee CEN/TC 278 Straentransport und Verkehrstelematik“ ausgearbeitet, dessen Sekretariat vom NEN (Niederlande) gehalte

5、n wird. Das zustndige deutsche Normungsgremium ist der Gemeinschaftsarbeitsausschuss NA 052-00-71 GA Straenverkehrtelematik“ des Normenausschusses Automobiltechnik. Das Prsidium des DIN hat mit seinem Beschluss 1/2004 festgelegt, dass von dem in den Regeln der europischen Normungsarbeit von CEN/CENE

6、LEC verankerten Grundsatz, wonach Europische Normen in den drei offiziellen Sprachen Deutsch, Englisch und Franzsisch verffentlicht werden, in begrndeten Ausnahmefllen abgewichen und auf die deutsche Sprachfassung verzichtet werden kann. Dienste fr den ffentlichen Verkehr verlassen sich zunehmend au

7、f Informationssysteme, welche zuver-lssige, einfach handhabbare und berall zugngliche korrekte Information fr Reisende liefern. Diese Art von Systemen decken folgende spezifischen Nutzungsprofile ab: Laden von Kalendern und Fahrplnen; Kontrolle von Fahrzeugbestnden; Ticket- und Rechnungsausstellung;

8、 Aktuelle Informationen zu laufenden Diensten, usw. Diese Norm spezifiziert eine Serviceschnittstelle fr Echtzeitinformationen (SIRI) zum ffentlichen Verkehr. Sie definiert Austauschinformationen zwischen Servern, welche Echtzeitinformationen zum ffentlichen Verkehr oder Reisedaten bereitstellen. Di

9、es beinhaltet Kontrollzentren von Verkehrsanbietern und Informationssystemen welche Echtzeit Fahrzeuginformationen nutzen, wie zum Beispiel Dienste fr Reiseinformation. nderungen Gegenber DIN CEN/TS 15531-2 (DIN SPEC 70655):2011-06 wurden folgende nderungen vorgenommen: a) das Dokument wurde an vers

10、chiedenen Stellen inhaltlich ergnzt; b) Dokument wurde in den Abschnitten neu strukturiert; c) berfhrung in eine Norm Frhere Ausgaben DIN CEN/TS 15531-2 (DIN SPEC 70655): 2011-06 Nationaler Anhang NA (informativ) Begriffe Fr die Anwendung dieses Dokuments gelten die Begriffe nach EN 15531-1. EUROPEA

11、N STANDARD NORME EUROPENNE EUROPISCHE 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 inf

12、ormations en temps rel relatives aux oprations de transport public Partie 2: Infrastructure des communications ffentlicher Verkehr Serviceschnittstelle fr Echtzeitinformationen bezogen auf Operationen im ffentlichen Verkehr Teil 2: Kommunikationsstruktur This European Standard was approved by CEN on

13、 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 b

14、e 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

15、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, I

16、reland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG CEN-CENELEC Management

17、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 EEN 15531-2:2015 (E) 2 Contents Page European foreword 4 Introduction 5 1 Scope 6 2 Normative references . 7 3 Terms and de

18、finitions . 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 Par

19、ameters 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 .

20、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 . 57 8.3 Delegated Delivery +SIRI 2.0 60 9 Recovery from system failure 61 9.1 Introduction . 61 9.2 Recovery after Client Failure 61

21、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 Addres

22、ses 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 DIN EN 15531-2:2015-12 EN 15531-2:2015 (E) 3 11.1 General 83 11.2 Capability Request 83 11.3 Service Capability Discovery . 85 11.4 Function

23、al 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 Comm

24、on SIRI elements 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:

25、 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

26、 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 t

27、he 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

28、 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. DIN EN 15531-2:2015-12 EN 15531-2:2015 (E) 5 Introduction Public

29、 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

30、; 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 ti

31、me 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 inter

32、faces 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, rathe

33、r 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

34、 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 oper

35、ators 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

36、 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

37、(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) provi

38、ding 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 Europe

39、an Standard readily extensible in future. DIN EN 15531-2:2015-12 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

40、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

41、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 fa

42、r 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, Pu

43、blisher, 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 th

44、is 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

45、 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 cl

46、ient 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

47、 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, an

48、d 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

49、 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