CEN/TS 16614-1:2014

SLOVENSKI STANDARD
01-september-2014
Javni prevoz - Izmenjava omrežnih in voznorednih podatkov (NeTEx) - 1. del:
Izmenjavni format za topologijo omrežja javnega prevoza
Public transport - Network and Timetable Exchange (NeTEx) - Part 1: Public transport
network topology exchange format
Öffentlicher Verkehr - Netzwerk und Fahrplan Austausch (NeTEx) - Teil 1: Öffentlicher
Verkehr Netzwerk Topologie
Transport Public - Échanges des informations planifiées (NeTEx) - Partie 1: Topologie du
réseau
Ta slovenski standard je istoveten z: CEN/TS 16614-1:2014
ICS:
03.220.01 Transport na splošno Transport in general
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 16614-1
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
May 2014
ICS 35.240.60
English Version
Public transport - Network and Timetable Exchange (NeTEx) -
Part 1: Public transport network topology exchange format
Transport Public - Échanges des informations planifiées Öffentlicher Verkehr - Netzwerk und Fahrplan Austausch
(NeTEx) - Partie 1: Topologie du réseau (NeTEx) - Teil 1: Öffentlicher Verkehr Netzwerk Topologie
This Technical Specification (CEN/TS) 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 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 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 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, 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, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2014 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16614-1:2014 E
worldwide for CEN national Members.

Contents
Foreword .6
Introduction .7
1 Scope .8
1.1 General .8
1.2 Transport modes.8
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 . 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 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 Conceptual 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 Namespaces . 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 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
7.2 Implementing Transmodel framework features in NeTEx . 133
7.3 Versions & Validity . 133
7.3.1 Introduction . 133
7.3.2 Version & Validity – Model Dependencies . 134
7.3.3 Generic Entity . 135
7.3.4 Generic Version . 144
7.3.5 Implementing relationships in NeTEx . 156
7.3.6 Generic Version Frame . 161
7.3.7 Generic Validity . 179
7.4 Responsibility . 186
7.4.1 Introduction . 186
7.4.2 Responsibility – Model Dependencies . 187
7.4.3 Generic Responsibility . 187
7.4.4 Responsibility Role . 202
7.4.5 Generic Organisation . 209
7.5 Generic Frames . 224
7.5.1 Composite Frame . 224
7.5.2 General Frame . 226
7.6 Generic Framework Model. 229
7.6.1 Generic Framework – Model Dependencies . 229
7.6.2 Unit & Utility Base Types . 230
7.6.3 Location Model . 244
7.6.4 Generic Grouping . 249
7.6.5 Generic Point & Link . 258
7.6.6 Common Section . 269
7.6.7 Generic Point & Link Sequence . 274
7.6.8 Generic Zone and Feature . 281
7.6.9 Generic Projection . 292
7.6.10 Generic Place . 311
7.6.11 Accessibility . 321
7.7 Reusable Components . 338
7.7.1 Reusable Components – Model Dependencies . 338
7.7.2 Resource Frame . 340
7.7.3 Transport Mode . 343
7.7.4 Transport SubMode . 349
7.7.5 Service Calendar . 357
7.7.6 Availability Condition . 381
7.7.7 Topographic Place . 385
7.7.8 Transport Organisations . 398
7.7.9 Generic Equipment . 408
7.7.10 Additional Organisations . 423
7.7.11 Vehicle Type . 430
7.7.12 Actual Vehicle Equipment . 445
7.7.13 Vehicle Passenger Equipment . 448
7.7.14 Facility . 454
7.7.15 Access Rights . 490
7.7.16 Train . 493
7.7.17 Schematic Map . 504
7.7.18 Notice . 512
8 Part 1 – The Network Topology . 521
8.1 Network Description – Model dependencies . 522
8.2 Infrastructure Frame . 523
8.2.1 Infrastructure Frame – Conceptual MODEL. 523
8.2.2 Infrastructure Frame– Physical Model . 524
8.3 Service Frame . 526
8.3.1 Service Frame – Conceptual MODEL . 526
8.3.2 Service Frame – Physical Model . 527
8.4 Network Description – Subsystem. 530
8.4.1 Network Infrastructure . 530
8.4.2 Network Restriction . 540
8.4.3 Activation . 549
8.4.4 Vehicle & Crew Point . 555
8.4.5 Lines and Routes . 561
8.4.6 Line Network . 587
8.4.7 Timing Pattern . 595
8.4.8 Flexible Network . 606
8.5 Fixed Object – Subsystem . 619
8.5.1 Fixed Objects – Model Dependencies . 620
8.5.2 Site Frame . 621
8.5.3 Site . 625
8.5.4 Stop Place . 652
8.5.5 Flexible Stop Place . 685
8.5.6 Point Of Interest . 692
8.5.7 Associating Equipment with Places . 708
8.5.8 Equipment Description . 708
8.5.9 Path Links . 795
8.5.10 Navigation Paths . 808
8.5.11 Check Constraint . 831
8.5.12 Parking . 844
8.5.13 Vehicle Stopping . 861
8.5.14 Connections & Transfer times . 865
8.5.15 Passenger Information Equipment . 880
8.5.16 Accessibility Coverage . 889
8.5.17 Accessibility Coverage of Paths . 890
8.6 Tactical Planning Components – Subsystem . 891
8.6.1 Tactical Planning – Model Dependencies . 891
8.6.2 Journey Pattern . 893
8.6.3 Service Pattern . 908
8.6.4 Routing Constraints . 927
8.6.5 Time Demand Type . 934
8.6.6 Passenger Stop Assignment . 941
8.6.7 Train Stop Assignment . 950
8.6.8 Path Assignment. 955
9 NeTEx Service Interface . 958
9.1 Introduction . 958
9.2 Protocols versus payload . 959
9.3 NeTEx Publication XSD schema . 960
9.3.1 NeTEx PublicationDelivery . 960
9.3.2 Publication Request – Service Element . 963
9.3.3 Frame Request Topics Filter . 965
9.3.4 Frame Request Policy . 968
9.4 NeTEx SIRI-NX services XSD schema . 972
9.4.1 Brief overview of SIRI communication layer . 973
9.4.2 SIRI ServiceRequest wrapper . 975
9.4.3 SIRI ServiceDelivery . 977
9.4.4 Data Object Service [SIRI-NX] . 981
9.5 Use of NeTEx with SOAP / WSDL. 986
9.5.1 Web Services . 987
9.5.2 SOAP (Simple Object Access Protocol) . 987
9.5.3 WSDL (Web Services Definition Language) . 987
9.5.4 NeTEx WSDL . 988
Annex A (informative) Mapping with existing standards . 990
A.1 Introduction . 990
A.2 VDV 452 Mapping . 994
A.3 NOPTIS Mapping . 994
A.4 NEPTUNE (Trident /Chouette profile) . 995
A.4.1 Foreword . 995
A.4.2 NEPTUNE. 995
A.4.3 NEPTUNE to NeTEx mapping information . 996
A.5 ERA mapping . 997
A.5.1 Foreword . 997
A.5.2 Explanation of the mapping . 998
A.5.2.1 Structure of mapping excel-file . 998
A.5.2.2 Hierarchy of EDIFACT . 998
A.5.2.2.1 Explanation of the mapping . 998
A.5.3 Limitations. 999
A.6 TransXChange, NaPTAN & NPTG mappings . 1000
A.6.1 Foreword . 1000
A.6.2 TransXChange to NeTEx mapping information . 1000
Bibliography . 1001

Foreword
This document (CEN/TS 16614-1:2014) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document presents Part 1 of the European Technical Specification known as “NeTEx”. NeTEx provides a
framework for specifying communications and data exchange protocols for organisations wishing to exchange
scheduled Information relating to public transport operations.
This technical specification is made up of three parts defining a single European Standard series, which
provides a complete exchange format for public transport networks, timetable description and fare information.
— Part 1 is the description of the public transport network topology exchange format. It also contains use
cases shared with part 2, and modelling rules and the description of a framework shared by all parts.
— Part 2 is the description of the scheduled timetables exchange format.
— Part 3 is the description of the fare information exchange format.
Part 1 is fully standalone, and part 2 and 3 rely on part 1.
The XML schema can be downloaded from www.netex.org.uk, along with available guidance on its use,
example XML files, and case studies of national and local deployments.
NOTE This document is higly technical, and a special care has been taken on keeping the text readable. This has
been done through a set of editorial rules enhancing usual CEN writing rules:
— To avoid confusion with usual wording, Transmodel terms are in capital letters (JOURNEY PATTERN for
example).
— To avoid confusion with usual wording, attributes names are in bold/italic style and use camelcase style
with no spaces (JourneyPattern for example).
— To avoid confusion with usual wording, attributes types are in italic style and use camelcase style with no
spaces (TypeOfEntity for example).
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this Technical Specification: 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, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

Currently under development
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 European Technical Specification specifies a Network and Timetable Exchange (NeTEx) standard for
Public Transport. It is intended to be used 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 NeTEx’s scope to provide
the necessary context 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 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 standard will improve a number of features of public transport information and service management:
Interoperability – the 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 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.
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 extensible in future.
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-1, prEN 15531-2 and prEN 15531-3 ) 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 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 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, metro,
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 NeTEx 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 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 directives.
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, 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 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

Under development
Under development (WI 00278340)
EN 15531-2, Public transport - Service interface for real-time information relating to public transport
operations - Part 2: Communications infrastructure
EN 15531-3, Public transport - Service interface for real-time information relating to public transport
operations - Part 3: Functional service interfaces
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 transport - 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 transport - 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 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 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
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)

Under development (WI 00278341)
Under development (WI 00278342)
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 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 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 limitation
(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 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 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 related 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)
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 vehicle 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 the entity
3.18
assistance service
(Local Service Equipment MODEL)
specialisation of LOCAL SERVICE for ASSISTANCE providing information like language, accessibility trained
staff, etc.
3.19
authority
(Transport Organisations MODEL)
the organisation under which the responsibility of organising the transport service in a certain area is placed
3.20
availability condition
(Reusable Availability MODEL)
a VALIDITY CONDITION expressed in terms of temporal parameters and referring to DAY TYPEs
3.21
beacon point
(Activation MODEL)
a POINT where a beacon or similar device to support the automatic detection of vehicles passing by is located
3.22
block
(Vehicle Service MODEL)
the work of a vehicle from the time it leaves a PARKING POINT after parking until its next return to park at a
PARKING POINT. Any
...