1、 Collection of SANS standards in electronic format (PDF) 1. Copyright This standard is available to staff members of companies that have subscribed to the complete collection of SANS standards in accordance with a formal copyright agreement. This document may reside on a CENTRAL FILE SERVER or INTRA
2、NET SYSTEM only. Unless specific permission has been granted, this document MAY NOT be sent or given to staff members from other companies or organizations. Doing so would constitute a VIOLATION of SABS copyright rules. 2. Indemnity The South African Bureau of Standards accepts no liability for any
3、damage whatsoever than may result from the use of this material or the information contain therein, irrespective of the cause and quantum thereof. ISBN 978-0-626-21611-5 SANS 55531-2:2008Edition 1CEN/TS 15531-2:2007Edition 1SOUTH AFRICAN NATIONAL STANDARD Public transport Service interface for real-
4、time information relating to public transport operations Part 2: Communications infrastructure This national standard is the identical implementation of CEN/TS 15531-2:2007 and is adopted with the permission of CEN, rue de Stassart 36, B-1050 Brussels. Published by Standards South Africa 1 dr latega
5、n road groenkloof private bag x191 pretoria 0001 tel: 012 428 7911 fax: 012 344 1568 international code + 27 12 www.stansa.co.za Standards South Africa SANS 55531-2:2008 Edition 1 CEN/TS 15531-2:2007 Edition 1 Table of changes Change No. Date Scope National foreword This South African standard was a
6、pproved by National Committee StanSA SC 71H, Information technology Intelligent transport systems, in accordance with procedures of Standards South Africa, in compliance with annex 3 of the WTO/TBT agreement. This SANS document was published in July 2008. TECHNICAL SPECIFICATIONSPCIFICATION TECHNIQU
7、ETECHNISCHE SPEZIFIKATIONCEN/TS 15531-2July 2007ICS 35.240.60English VersionPublic transport - Service interface for real-time informationrelating to public transport operations - Part 2: Communicationsinfrastructureffentlicher Verkehr - Dienstleitungsschnittstelle frzeitnahe Informationen zum Betri
8、eb des ffentlichenVerkehrs - Teil 2: KommunikationsinfrastrukturThis Technical Specification (CEN/TS) was approved by CEN on 23 October 2006 for provisional application.The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
9、submit theircomments, particularly on the question whether the CEN/TS can be converted into a European Standard.CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS availablepromptly at national level in an appropriate form. It is perm
10、issible to keep conflicting national standards in force (in parallel to the CEN/TS)until the final decision about the possible conversion of the CEN/TS into an EN is reached.CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland
11、,France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMIT EUROPEN DE NORMALISATIONEUROPISCHES KOMITEE F
12、R NORMUNGManagement Centre: rue de Stassart, 36 B-1050 Brussels 2007 CEN All rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. CEN/TS 15531-2:2007: ESANS 55531-2:2008This s tandard may only be used and printed by approved subscription and freemai
13、ling clients of the SABS .CEN/TS 15531-2:2007 (E) 2 Contents Page Foreword5 Introduction .6 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 Interaction8 5.1.1 General8 5.1.2 Request/Response P
14、attern.8 5.1.3 Publish/Subscribe Pattern 9 5.1.4 Publish/Subscribe with Broker Pattern .10 5.1.5 Request/Response Compound Requests 11 5.1.6 Publish/Subscribe Compound Subscriptions .11 5.2 Delivery Patterns12 5.2.1 General12 5.2.2 Direct Delivery12 5.2.3 Fetched Delivery 13 5.2.4 Data Horizon for F
15、etched Delivery.14 5.2.5 Get Current Message.15 5.2.6 Multipart Despatch of a Delivery15 5.2.7 Multipart Despatch of a Fetched Delivery MoreData.15 5.3 Mediation Behaviour .16 5.3.1 General16 5.3.2 Mediation Behaviour Maintaining Subscription Last Updated State 16 5.3.3 Mediation Behaviour Subscript
16、ion Filters .19 5.4 Recovery Considerations for Publish Subscribe.21 5.4.1 General21 5.4.2 Check Status Polling 22 5.4.3 Heartbeat Pinging .22 5.4.4 Degrees of Failure22 5.4.5 Detecting a Failure of the Producer.23 5.4.6 Detecting a Failure of the Consumer.24 5.5 Recovery Considerations for Direct D
17、elivery .25 5.6 Request Parameters and Interactions .25 5.7 Error Conditions for Requests .27 5.8 Versioning 29 5.8.1 General29 5.8.2 The Overall SIRI Framework Version Level 29 5.8.3 The SIRI Functional Service Type Version Level .29 5.9 Access Controls: Security and Authentication 30 5.9.1 General
18、30 5.9.2 System Mechanisms External to SIRI Messages .30 5.9.3 Application Access Controls Reflected in SIRI Processing30 5.10 Service Discovery31 5.10.1 General31 5.10.2 Discovery of Servers that Support SIRI 31 5.10.3 Discovery of the Capabilities of a SIRI Server31 5.10.4 Discovery of the Coverag
19、e of a Given SIRI Functional Service31 SANS 55531-2:2008This s tandard may only be used and printed by approved subscription and freemailing clients of the SABS .CEN/TS 15531-2:2007 (E) 3 5.11 Capability Matrix32 5.11.1 General .32 5.11.2 SIRI General Capabilities32 6 Request/response .33 6.1 Making
20、 a Direct Request.33 6.1.1 General .33 6.1.2 ServiceRequest Message .34 6.1.3 The ServiceRequestContext.35 6.1.4 Common Properties of ServiceRequest Messages .37 6.1.5 ServiceRequest Example37 6.1.6 Access Controls on a Request 38 6.2 Receiving a Data Delivery.39 6.2.1 General .39 6.2.2 ServiceDeliv
21、ery Message40 7 Subscriptions.44 7.1 Setting up Subscriptions44 7.1.1 General .44 7.1.2 SubscriptionRequest 45 7.1.3 SubscriptionResponse .48 7.2 Subscription Validity.50 7.3 Terminating Subscriptions.50 7.3.1 General .50 7.3.2 The TerminateSubscriptionRequest50 7.3.3 TerminateSubscriptionResponse 5
22、1 8 Delivering data.53 8.1 Direct Delivery .53 8.1.1 Procedure.53 8.1.2 DataReceivedAcknowledgement Message.53 8.1.3 DataReceivedAcknowledgement Example .53 8.2 Fetched Delivery54 8.2.1 General .54 8.2.2 Signalling Data Availability (DataReadyNotification / DataReadyResponse) .54 8.2.3 Polling Data
23、(DataSupplyRequest/ServiceDelivery) 56 9 Recovery from system failure 57 9.1 General .57 9.2 Recovery after Client Failure57 9.3 Recovery after Server Failure 57 9.4 Reset after Interruption of Communication58 9.5 Alive Handling58 9.5.1 General .58 9.5.2 CheckStatusRequest.58 9.5.3 CheckStatusRespon
24、se59 9.5.4 HeartbeatNotification 61 10 Transport of SIRI messages.62 10.1 Separation of Addressing from Transport Protocol 62 10.2 Logical Endpoint Addresses62 10.2.1 Endpoint Addresses62 10.2.2 Endpoint Address Examples63 10.3 Parallelism and Endpoint Addresses 64 10.4 Encoding of XML messages.65 1
25、0.4.1 Principles65 10.4.2 Encoding of Errors in XML .65 10.4.3 Character Set .65 10.4.4 Schema Packages .65 10.5 Use of SIRI with SOAP 66 10.5.1 General .66 10.5.2 Web Services .66 SANS 55531-2:2008This s tandard may only be used and printed by approved subscription and freemailing clients of the SA
26、BS .CEN/TS 15531-2:2007 (E) 4 10.5.3 Use of SOAP.67 10.5.4 SIRI WSDL 68 10.5.5 WSDL Producer Server Operations .69 10.5.6 WSDL Client Operations .70 10.5.7 SIRI WSDL Status 71 11 Capability discovery requests71 11.1 General71 11.2 Capability Request.71 11.3 Service Capability Discovery Request 72 11
27、.4 Service Capability Discovery Response .72 11.5 Service Capability Discovery Response .73 11.5.1 General73 11.5.2 Service Capability Response Example74 11.6 Functional Service Capability Permission Matrix 76 11.6.1 General76 11.6.2 OperatorPermissions 77 11.6.3 LinePermissions 77 11.6.4 Connection
28、LinkPermissions 78 11.6.5 StopMonitorPermissions 78 11.6.6 VehicleMonitorPermissions79 11.6.7 InfoChannelPermissions.79 12 Shared groups of elements 79 12.1 General79 12.2 FramedVehicleJourneyRef .79 12.3 ServiceInfoGroup.80 12.4 VehicleJourneyInfoGroup.80 12.5 JourneyPatternInfoGroup .81 12.6 Disru
29、ptionGroup 82 12.7 JourneyProgressGroup 83 12.8 Location 83 12.9 OperationalBlockGroup 84 12.10 OperationalInfoGroup .84 12.11 Error 84 Bibliography 85 SANS 55531-2:2008This s tandard may only be used and printed by approved subscription and freemailing clients of the SABS .CEN/TS 15531-2:2007 (E) 5
30、 Foreword This document (CEN/TS 15531-2:2007) has been prepared by Technical Committee CEN/TC 278 “Road transport and traffic telematics”, the secretariat of which is held by NEN. This presents Part 2 of the European Technical Specification known as “SIRI”. SIRI provides a framework for specifying c
31、ommunications and data exchange protocols for organisations wishing to exchange Real-time Information (RTI) relating to public transport operations. SIRI is presented in three parts: Context and framework, including background, scope and role, normative references, terms and definitions, symbols and
32、 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 (Part 3). The XML schema can be downloaded from http:/www.siri.org.uk/, along with available
33、 guidance on its use, example XML files, and case studies of national and local deployments. It is recognised that SIRI is not complete as it stands, and there will be a substantial amount of work required to continue to develop SIRI over the coming years. It is therefore intended that a SIRI Manage
34、ment 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 announce this CEN Technical Specification: Austria, Belgium, Bulgaria, Cyprus, Czec
35、h Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. SANS 55531-2:2008This s tandard may only be used
36、and printed by approved subscription and freemailing clients of the SABS .CEN/TS 15531-2:2007 (E) 6 Introduction Public transport services rely increasingly on information systems to ensure reliable, efficient operation and widely accessible, accurate passenger information. These systems are used fo
37、r 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 Technical Specification specifies a Service Interface for Real-time Information (SIRI) about Public Transport.
38、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
39、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
40、 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
41、 modules can be replaced or evolved, without unexpected breakages of obscurely dependent function. This Technical Specification will improve a number of features of public transport information and service management: Interoperability the Technical Specification will facilitate interoperability betw
42、een 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; (ii) using common data models and schemas for the messages exchanged for e
43、ach service; and (iv) introducing a consistent approach to data management. Improved operations management the Technical Specification 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 per
44、formance, 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 Technical Specification will assist the economic provision of improved data by; (i) enabling the gather
45、ing 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 se
46、rvices enables cost-effective implementations, and makes the Technical Specification readily extensible in future. SANS 55531-2:2008This s tandard may only be used and printed by approved subscription and freemailing clients of the SABS .CEN/TS 15531-2:2007 (E) 7 1 Scope SIRI uses a consistent set o
47、f 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 use
48、d 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 Se
49、rvice. 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 a
