BS EN 15531-2-2015 Public transport Service interface for real-time information relating to public transport operations Communication《公共运输 与公共运输操作相关的实时信息服务接口 通信》.pdf

《BS EN 15531-2-2015 Public transport Service interface for real-time information relating to public transport operations Communication《公共运输 与公共运输操作相关的实时信息服务接口 通信》.pdf》由会员分享，可在线阅读，更多相关《BS EN 15531-2-2015 Public transport Service interface for real-time information relating to public transport operations Communication《公共运输 与公共运输操作相关的实时信息服务接口 通信》.pdf（134页珍藏版）》请在麦多课文档分享上搜索。

1、BSI Standards PublicationBS EN 15531-2:2015Public transport Serviceinterface for real-timeinformation relating to publictransport operationsPart 2: CommunicationsBS EN 15531-2:2015 BRITISH STANDARDNational forewordThis British Standard is the UK implementation of EN 15531-2:2015.It supersedes DD CEN

2、/TS 15531-2:2007 which is withdrawn.The UK participation in its preparation was entrusted to TechnicalCommittee EPL/278, Intelligent transport systems.A list of organizations represented on this committee can beobtained on request to its secretary.This publication does not purport to include all the

3、 necessaryprovisions of a contract. Users are responsible for its correctapplication. The British Standards Institution 2015. Published by BSI StandardsLimited 2015ISBN 978 0 580 83398 4ICS 35.240.60Compliance with a British Standard cannot confer immunity fromlegal obligations.This British Standard

4、 was published under the authority of theStandards Policy and Strategy Committee on 31 August 2015.Amendments issued since publicationDate Text affectedBS EN 15531-2:2015EUROPEAN STANDARD NORME EUROPENNE EUROPISCHE NORM EN 15531-2 August 2015 ICS 35.240.60 Supersedes CEN/TS 15531-2:2007English Versi

5、on Public transport - Service interface for real-time information relating to public transport operations - Part 2: CommunicationsTransport public - Interface de service pour les informations en temps rel relatives aux oprations de transport public - Partie 2 : Infrastructure des communications ffen

6、tlicher Verkehr - Serviceschnittstelle fr 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 co

7、nditions 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 exi

8、sts 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 st

9、andards 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,

10、Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels 2015 CEN All rights of exploitation in any form and by any means rese

11、rved worldwide for CEN national Members. Ref. No. EN 15531-2:2015 EBS EN 15531-2:2015EN 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 Exchang

12、e 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 Cont

13、rols: 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 De

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

15、 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 o

16、f SIRI with SOAP / WSDL 73 11 Capability Discovery Requests . 83 11.1 General . 83 BS EN 15531-2:2015EN 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)

17、. 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 the mechanisms to be adopted for data exchange communications links (Part 2); d

18、ata 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

19、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 sta

20、nds, 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

21、 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, Luxemb

22、ourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. BS EN 15531-2:2015EN 15531-2:2015 (E) 5 Introduction Public transport services rely increasingly on information systems to ensure reliable, efficient operation

23、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 S

24、ervice 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 inclu

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

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

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

28、f 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 o

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

30、le 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

31、-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 dist

32、ribution 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. BS EN 15531-2:2015EN 15531-2:2015 (E) 6 1 Scope SIRI uses a

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

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

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

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

37、hese 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 o

38、f 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 subscri

39、be 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 diffe

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

41、ther 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. Th

42、e 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 o

43、f 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 a

44、rising 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. BS EN 15531-2:2015EN 15531-2:2015 (E) 7 Only partial updates to the data set since the last delivery fo

45、r 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 f

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

47、- 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 asp

48、ects 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 p

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