CEN TS 16614-1-2014 Public transport - Network and Timetable Exchange (NeTEx) - Part 1 Public transport network topology exchange format《公共交通 网络和时间表交换（NETEX） 第1部分 公共交通网络拓扑的交换格式》.pdf

《CEN TS 16614-1-2014 Public transport - Network and Timetable Exchange (NeTEx) - Part 1 Public transport network topology exchange format《公共交通 网络和时间表交换（NETEX） 第1部分 公共交通网络拓扑的交换格式》.pdf》由会员分享，可在线阅读，更多相关《CEN TS 16614-1-2014 Public transport - Network and Timetable Exchange (NeTEx) - Part 1 Public transport network topology exchange format《公共交通 网络和时间表交换（NETEX） 第1部分 公共交通网络拓扑的交换格式》.pdf（1006页珍藏版）》请在麦多课文档分享上搜索。

1、BSI Standards PublicationPublic transport Network and Timetable Exchange (NeTEx)Part 1: Public transport network topology exchange formatPD CEN/TS 16614-1:2014National forewordThis Published Document is the UK implementation of CEN/TS 16614-1:2014.The UK participation in its preparation was entruste

2、d to TechnicalCommittee EPL/278, Intelligent transport systems.A list of organizations represented on this committee can be obtained onrequest to its secretary.This publication does not purport to include all the necessary provisions ofa contract. Users are responsible for its correct application. T

3、he British Standards Institution 2014.Published by BSI Standards Limited 2014ISBN 978 0 580 82691 7ICS 35.240.60Compliance with a British Standard cannot confer immunity fromlegal obligations.This Published Document was published under the authority of theStandards Policy and Strategy Committee on 3

4、0 June 2014.Amendments/corrigenda issued since publicationDate Text affectedPUBLISHED DOCUMENTPD CEN/TS 16614-1:2014TECHNICAL SPECIFICATION SPCIFICATION TECHNIQUE TECHNISCHE SPEZIFIKATION CEN/TS 16614-1 May 2014 ICS 35.240.60 English Version Public transport - Network and Timetable Exchange (NeTEx)

5、- Part 1: Public transport network topology exchange format Transport Public - changes des informations planifies (NeTEx) - Partie 1: Topologie du rseau ffentlicher Verkehr - Netzwerk und Fahrplan Austausch (NeTEx) - Teil 1: ffentlicher Verkehr Netzwerk TopologieThis Technical Specification (CEN/TS)

6、 was approved by CEN on 12 November 2013 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 submit their comments, particularly on the question whether the CEN/TS can be converted into a Euro

7、pean 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 available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS) until the fi

8、nal 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, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, I

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

10、Centre: Avenue Marnix 17, B-1000 Brussels 2014 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. CEN/TS 16614-1:2014 EPD CEN/TS 16614-1:2014CEN/TS 16614-1:2014 (E) 2 Contents Foreword 6 Introduction .7 1 Scope 8 1.1 General 8 1.2 Transp

11、ort modes8 1.3 Compatibility with existing standards and recommendations .8 2 Normative references 8 3 Terms and definitions .9 4 Symbols and abbreviations . 61 5 Use Cases for Network Topology Exchange . 62 5.1 Purpose 62 5.2 Actors and Use Case Types 62 5.2.1 Actors . 62 5.2.2 Delivery Use Cases .

12、 63 5.2.3 Content Use Cases . 65 5.2.4 Object Lifecycle Support Use Cases 66 5.2.5 Security Use Cases 66 5.2.6 Excluded Use Cases . 67 5.3 Use Cases 68 5.3.1 Requirements Table . 68 5.3.2 Collection of Use Cases . 74 6 Generic Physical Model and XSD mapping rules 105 6.1 Introduction . 105 6.2 Model

13、 Driven Design 105 6.3 Models levels of abstraction. 107 6.4 Open Implementation and technology use 108 6.5 Models versus Protocols . 109 6.6 Modularisation 109 6.7 Summary of Modelling Approach . 110 6.7.1 Use of packages in NeTEx models . 111 6.8 Model transforms and Traceability . 112 6.8.1 Conce

14、ptual Model UML Package 112 6.8.2 Physical Model UML Container Packages and Mapping from Conceptual model . 112 6.8.3 XSD Model subschemas and Mapping from Physical model 113 6.8.4 Summary of Basic Mapping . 114 6.9 Physical model to XSD schema mapping notes 115 6.10 Uniqueness of reference and Name

15、spaces . 115 6.11 Handling of inheritance 115 6.12 NeTEx Notation, presentation and naming conventions 116 6.12.1 Presentation of Element Names 116 6.12.2 Naming conventions 116 6.12.3 Presentation of Diagrams 117 6.12.4 Use of Colour 118 6.13 Mapping between models in NeTEx 118 6.13.1 Common Design

16、 Patterns in NeTEx . 118 6.13.2 Mapping Example Thing Model 118 6.13.3 Mapping Example Handling Inheritance the SubThing Model 127 7 NeTEx Framework - Conceptual and Physical data model 131 7.1 Introduction . 132 PD CEN/TS 16614-1:2014CEN/TS 16614-1:2014 (E) 3 7.2 Implementing Transmodel framework f

17、eatures in NeTEx . 133 7.3 Versions managing vehicle fleets; issuing tickets and receipts; providing real-time information on service running, and so on. This European Technical Specification specifies a Network and Timetable Exchange (NeTEx) standard for Public Transport. It is intended to be used

18、to exchange data relating to scheduled public transport between the systems of PT organisations. It can also be seen as complementary to the SIRI (Service Interface for Real-time Information) standard, as SIRI needs a prior exchange of reference data from NeTExs scope to provide the necessary contex

19、t for the subsequent exchange of a real-time data. 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 ca

20、n 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. Fur

21、thermore, individual functional modules can be replaced or evolved, without unexpected breakages of obscurely dependent function. This standard will improve a number of features of public transport information and service management: Interoperability the standard will facilitate interoperability bet

22、ween 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

23、 each service; and (iv) introducing a consistent approach to data management. Technical advantages include the following: a modular reusing of a common communication layer shared with SIRI for all the various technical services enables cost-effective implementations, and makes the standard readily e

24、xtensible in future. PD CEN/TS 16614-1:2014CEN/TS 16614-1:2014 (E) 8 1 Scope 1.1 General NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information). It is based on Transmodel V5.1 (EN 12896), IFOPT (EN 28701) and SIRI (CEN/TS 15531-4, CEN/TS 15531-5 and prEN 15531

25、-1, prEN 15531-2 and prEN 15531-32) and supports the exchange of information of relevance for passenger information about public transport services and also for running Automated Vehicle Monitoring Systems (AVMS). NOTE Many NeTEx concepts are taken directly from Transmodel and IFOPT; the definitions

26、 and explanation of these concepts are extracted directly from the respective standard and reused in NeTEx, sometimes with adaptions in order to fit the NeTEx context. Although the data exchanges targeted by NeTEx are predominantly oriented towards provisioning passenger information systems and AVMS

27、 with data from transit scheduling systems, it is not restricted to this purpose and NeTEx can also provide an effective solution to many other use cases for transport data exchange. 1.2 Transport modes All mass public transport modes are taken into account by NeTEx, including train, bus, coach, met

28、ro, tramway, ferry, and their submodes. It is possible to describe airports and air journeys, but there has not been any specific consideration of any additional requirements that apply specifically to air transport. 1.3 Compatibility with existing standards and recommendations Concepts covered in N

29、eTEx that relate in particular to long-distance train travel include; rail operators and related organizations; stations and related equipment; journey coupling and journey parts; train composition and facilities; planned passing times; timetable versions and validity conditions. In the case of long

30、 distance train the NeTEx takes into account the requirements formulated by the ERA (European Rail Agency) TAP/TSI (Telematics Applications for Passenger/ Technical Specification for Interoperability, entered into force on 13 May 2011 as the Commission Regulation (EU) No 454/2011), based on UIC dire

31、ctives. As regards the other exchange protocols, a formal compatibility is ensured with TransXChange (UK), VDV 452 (Germany), NEPTUNE (France), UIC Leaflet, BISON (Netherland) and NOPTIS (Nordic Public Transport Interface Standard). The data exchange is possible either through dedicated web services

32、, through data file exchanges, or using the SIRI exchange protocol as described in part 2 of the SIRI documentation. 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

33、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 framework3 2 Under development

34、 3 Under development (WI 00278340) PD CEN/TS 16614-1:2014CEN/TS 16614-1:2014 (E) 9 EN 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure4 EN 15531-3, Public transport - Service interface for real-tim

35、e information relating to public transport operations - Part 3: Functional service interfaces5 CEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring CEN/TS 15531-5, Public tr

36、ansport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange EN 12896, Road transport and traffic telematics - Public transport - Reference data model EN 28701, Intelligent transport systems - Public transp

37、ort - Identification of Fixed Objects in Public Transport (IFOPT) 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. NOTE A lot of definitions are shared with Transmodel (EN 12896) and IFOPT (EN 28701): special attention was paid to the consistency

38、of definitions, keeping exactly the same wording. The italic bracket name at the beginning of the definition is a package name that will help the reader to find the related concept in the UML data model. 3.1 access (Generic Place MODEL) the physical (spatial) possibility for a passenger to access or

39、 leave the public transport system. This link may be used during a trip for the walking movement of a passenger from a PLACE (origin of the trip) to a STOP POINT (origin of the PT TRIP), or- the walking movement from a STOP POINT (destination of the PT TRIP) to a PLACE (destination of the trip) 3.2

40、access end (Generic Place MODEL) origin or destination end of an ACCESS link. May indicate a MODE, POINT and PLACE 3.3 access mode (Reusable Transport Mode MODEL) a characterisation of the passenger movement according to the means of transport different from public transport (e.g. walk, bicycle, etc

41、) 4 Under development (WI 00278341) 5 Under development (WI 00278342) PD CEN/TS 16614-1:2014CEN/TS 16614-1:2014 (E) 10 3.4 access space (Stop Place MODEL) a passenger area within a STOP PLACE such as a concourse or booking hall, immigration hall or security area that is accessible by passengers, but

42、 without a direct access to vehicles. Direct access to a VEHICLE is always from a QUAY and/or BOARDING POSITION. An ACCESS SPACE may be a Room, Hall, Concourse, Corridor, or bounded open space within a STOP PLACE 3.5 access zone (Site MODEL) A ZONE for which the duration to cover any ACCESS LINK to

43、a particular STOP POINT is the same. 3.6 accessibility assessment (Accessibility MODEL) the accessibility characteristics of an entity used by passengers such as a STOP PLACE, or a STOP PLACE COMPONENT. Described by ACCESSIBILITY LIMITATIONs, and/or a set of SUITABILITies 3.7 accessibility limitatio

44、n (Accessibility MODEL) a categorisation of the accessibility characteristics of a SITE, e.g. a STOP PLACE or a STOP PLACE COMPONENT to indicate its usability by passengers with specific needs, for example, those needing wheelchair access, step-free access or wanting to avoid confined spaces such as

45、 lifts. A small number of well-defined categories are used that are chosen to allow the consistent capture of data and the efficient computation of routes for different classes of user 3.8 accomodation (Facility MODEL) a combination of accommodation characteristics available on a service, e.g. First

46、 Class Couchette with shower and 2 bunks 3.9 activated equipment (Activation MODEL) an equipment activated by the passage of a vehicle at an ACTIVATION POINT or on an ACTIVATION LINK 3.10 activation assignment (Activation MODEL) an assignment of an ACTIVATION POINT/LINK to an ACTIVATED EQUIPMENT rel

47、ated on its turn to a TRAFFIC CONTROL POINT. The considered ACTIVATION POINT/LINK will be used to influence the control process for that TRAFFIC CONTROL POINT (e.g. to fix priorities as regards the processing of competing requests from different ACTIVATION POINTs/LINKs) PD CEN/TS 16614-1:2014CEN/TS

48、16614-1:2014 (E) 11 3.11 activation link (Activation MODEL) a LINK where a control process is activated when a vehicle passes it 3.12 activation point (Activation MODEL) a POINT where a control process is activated when a vehicle passes it. Equipment may be needed for the activation 3.13 actual vehi

49、cle equipment (Actual Vehicle Equipment MODEL) an item of equipment of a particular type in an individual VEHICLE 3.14 address (Topographic MODEL) an address of a PLACE 3.15 administrative zone (Generic Organisation MODEL) the area of a district, a region, a city, a municipality, or other area with which an ORGANIZATION has a RESPONSIBILITY ROLE 3.16 allowed line direction (Route MODEL) an allowed DIRECTION that can be used on a given ROUTE. This can be used to validate the selection of allowed values 3.17 alternative name (Site MODEL) alternative name for t