CEN/TS 16614-2:2014

SLOVENSKI STANDARD
01-december-2014
Javni prevoz - Izmenjava omrežnih in voznorednih podatkov (NeTEx) - 2. del:
Izmenjavni format za vozne rede rednega javnega prevoza
Public transport - Network and Timetable Exchange (NeTEx) - Part 2: Public transport
scheduled timetables exchange format
Öffentlicher Verkehr - Netzwerk und Fahrplan Austausch (NeTEx) - Teil 2: Fahrpläne
Transport Public - Échanges des informations planifiées (NeTEx) - Partie 2: Description
de l'offre de transport
Ta slovenski standard je istoveten z: CEN/TS 16614-2: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-2
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
May 2014
ICS 35.240.60
English Version
Public transport - Network and Timetable Exchange (NeTEx) -
Part 2: Public transport scheduled timetables exchange format
Transport Public - Échanges des informations planifiées Öffentlicher Verkehr - Netzwerk und Fahrplan Austausch
(NeTEx) - Partie 2: Description de l'offre de transport (NeTEx) - Teil 2: Fahrpläne
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-2:2014 E
worldwide for CEN national Members.

Contents Page
Foreword . 4
Introduction . 5
1 Scope . 6
1.1 General . 6
1.2 Transport modes . 6
1.3 Compatibility with existing standards and recommendations . 6
2 Normative references . 6
3 Terms and definitions . 7
4 Symbols and abbreviations . 7
5 Use Cases for Journey & Journey Time Exchange . 7
6 Generic Physical Model and XSD mapping rules . 7
7 Timing Information – Conceptual and physical data model . 7
7.1 Introducion . 7
7.1.1 Journey and Journey Times – Model dependencies . 8
7.2 Journey and Journey Times . 16
7.2.1 Vehicle Journey . 16
7.2.2 Service Journey. 33
7.2.3 Time Demand Times . 49
7.2.4 Journey Timing . 58
7.2.5 Journey Pattern Times . 66
7.2.6 Vehicle Journey Times . 74
7.2.7 Interchange . 92
7.2.8 Interchange Rule . 110
7.2.9 Coupled Journey . 118
7.2.10 Flexible Service . 137
7.2.11 Journey Accounting . 145
7.2.12 Dated Journey . 150
7.2.13 Passing Times . 155
7.2.14 Call . 162
7.2.15 Dated Call . 178
8 Vehicle Scheduling . 180
8.1 Vehicle Scheduling – Model dependencies . 180
8.2 Vehicle Scheduling . 181
8.2.1 Vehicle Schedule Frame . 181
8.2.2 Vehicle Service . 184
8.2.3 Train Service . 199
Annex A (informative) Monitoring & Control . 203
A.1 Introduction . 203
A.2 Monitoring & Control . 203
A.2.1 Monitored Vehicle Journey . 203
A.2.1.1 Monitored Vehicle Journey – Conceptual MODEL . 203
A.2.1.1.1 Monitored Passing Times . 204
A.2.1.2 Monitored Vehicle Journey – Physical Model . 205
A.2.1.3 Monitored JourneyModel – Attributes and XSD . 207
A.2.1.3.1 MonitoredVehicleJourney – Model Element . 207
A.2.1.3.2 MonitoredSpecialService – Model Element . 207
A.2.1.3.3 MonitoredCall – Model Element . 207
A.2.1.3.4 PreviousCall – Model Element . 208
A.2.1.3.5 OnwardCall – Model Element . 209
A.2.2 Dated Passing Times – Physical Model . 210
A.2.2.1 Passing times – Attributes and XSD . 211
A.2.2.1.1 EstimatedPassingTime – Model Element . 211
A.2.2.1.2 ObservedPassingTime – Model Element. 212
A.2.2.1.3 TargetPassingTime – Model Element . 213
Annex B (informative) Driver Scheduling . 215
B.1 Introduction . 215
B.2 Driver Scheduling . 215
B.2.1 Driver Schedule Frame . 215
B.2.1.1 DRIVER SCHEDULE FRAME – Conceptual MODEL . 215
B.2.1.2 Driver Schedule Frame – Physical Model . 216
B.2.1.3 Driver Schedule Frame — XSD and attributes . 218
B.2.1.3.1 DriverScheduleFrame – Model Element . 218
B.2.2 Duty . 219
B.2.2.1 DUTY – Conceptual MODEL . 219
B.2.2.1.1 Duty – Physical Model . 220
B.2.2.1.2 Duty – Attributes and XSD . 221
B.2.2.1.2.1 Duty – Model Element . 221
B.2.2.1.2.2 AccountableElement – Model Element . 222
B.2.2.1.2.3 DutyPart – Model Element . 223
B.2.2.1.2.4 DriverTrip – Model Element . 225
B.2.2.1.2.5 DriverTripTime – Model Element . 226
B.2.3 Duty Stretch . 227
B.2.3.1 DUTY STRETCH – Conceptual MODEL . 227
B.2.3.2 Duty Stretch – Physical Model . 228
Bibliography . 230

Foreword
This document (CEN/TS 16614-2: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 2 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, 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
case 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 parts 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.
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.
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) about public
transport. It is intended to be used to exchange information between PT organisations systems containing
scheduled public transport data. It can also be seen as a complement to the SIRI (Service Interface for
Real-time Information) standard, as SIRI needs reference data exchange in the scope of NeTEx before any
possible real-time exchange.
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; (ii) 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: reusing 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) based on
Transmodel V5.1 (EN 12896), IFOPT (EN 28701) and SIRI (CEN/TS 15531-4 and CEN/TS 15531-5 and
prEN 15531-1, prEN 15531-2 and prEN 15531-3) and supports information exchange of relevance to public
transport services for passenger information and AVMS systems.
NOTE Many NeTEx concepts are taken directly from Transmodel and IFOPT; the definitions and explanation of
these concepts are extracted directly from the respective standards and reused in NeTEx, sometimes with further
adaptions in order to fit the NETEx context.
The data exchanges targeted by NeTEx are predominantly oriented towards passenger information and
also for data exchange between transit scheduling systems and AVMS (Automated Vehicle Monitoring
Systems). However it is not restricted to these purposes, and NeTEx can provide an effective solution to
many other use cases for transport exchange.
1.2 Transport modes
Most 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 provisions that apply especially to air transport.
1.3 Compatibility with existing standards and recommendations
The 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.
prEN 15531-1:2013, Public transport - Service interface for real-time information relating to public transport
operations - Part 1: Context and framework
prEN 15531-2:2013, Public transport - Service interface for real-time information relating to public transport
operations - Part 2: Communications infrastructure
prEN 15531-3:2013, 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
CEN/TS 16614-1:2014, Public transport - Network and Timetable Exchange (NeTEx) - Part 1: Public
transport network topology exchange format
3 Terms and definitions
For the purposes of this document, the terms and definitions given in CEN/TS 16614-1:2014 apply.
4 Symbols and abbreviations
For the purposes of this document, the symbols and abbreviations given in CEN/TS 16614-1:2014 apply.
5 Use Cases for Journey & Journey Time Exchange
NeTEx Part 2 shares its use cases with NeTEx Part 1 since many use cases involve both part 1 and part 2
entities. Please refer to NeTEx Part 1 for a detailed use case description.
6 Generic Physical Model and XSD mapping rules
For consistency, the mapping rules for transforming a Conceptual Model to Physical Model and then to
XSD are shared between all parts of NeTEx.
Please refer to NeTEx Part 1 for a detailed description of the Physical Model and XSD mapping rules.
7 Timing Information – Conceptual and physical data model
7.1 Introducion
NeTEx Part 2 timing information model is splited into four main submodels defined as UML packages.

Figure 1 – NeTEx Part 2 main packages
— The Journey and Journey Times model: describes the model planned services and dead runs and
their timings
Figure 2 – JourneyAndJourneyTimes packages
— The dated journey model: describes the services for a single operating day
— The passing time model: describes all the different types of passing times
— The vehicle service model: describes the informations related to vehicles and their services
7.1.1 Journey and Journey Times – Model dependencies
The JOURNEY AND JOURNEY TIMES Model describes the VEHICLE JOURNEYs and other components
making up a timetable and is itself divided into a number of separate submodels covering different aspects
of VEHICLE JOURNEYs. For ease of understanding, the submodels are presented one at a time, each
describing only a small set of related concepts.
The submodels depend on a number of general NeTEx framework models and reusable components
described elsewhere (for example, the GENERIC POINT AND LINK model, NOTICE model, etc.,) – See
NeTEx Part 1 for further details.
The following figure shows the dependencies between the JOURNEY AND JOURNEY TIMES physical
submodels. The terminal packages contain the SERVICE FRAME and the TIMETABLE FRAME. These
two VERSION FRAMEs are containers that organise the other payload elements into a coherent set of
elements suitable for exchange as a serialised file. The payload elements are contained in the following
packages:
TIMETABLE FRAME
— VEHICLE JOURNEY: models journeys that vehicles make.
— SERVICE JOURNEY: additionally models the properties of journeys that carry passengers.
— TIME DEMAND TIMEs: models the times of the different demand levels found during a day.
— PASSING TIMEs: describes the times of vehicles at points in their journey.
— JOURNEY TIMINGs: describes the common timing properties for journeys.
— JOURNEY PATTERN TIMEs: describes the timings of JOURNEY PATTERNs.
— VEHICLE JOURNEY TIMEs: describes the timings of VEHICLE JOURNEYs.
— INTERCHANGE: describes interchanges between journeys.
— COUPLED JOURNEY: describes multipart journeys which join and split.
— FLEXIBLE SERVICE: additional describes demand responsive transport services.
— JOURNEY ACCOUNTING: assigns a cost basis for journeys.

Figure 3 — Journey – Model Dependencies
7.1.1.1 Timetable Frame
7.1.1.1.1 TIMETABLE FRAME – Conceptual MODEL
The elements of the JOURNEY & JOURNEY TIMES model can be grouped with a TIMETABLE FRAME
which holds a coherent set of timetable related elements for data exchange (see VERSION FRAME in the
NeTEx Framework section for general concepts relating to version frames).
The primary component exchanged by a TIMETABLE FRAME is a SERVICE JOURNEY, which describes
an individual journey. This and other components of a TIMETABLE FRAME are described in detail in the
following sections.
class NeTEx EF Timetable Frame MODEL
Name: NeTEx EF Timetable Frame MODEL
+defined for Generic Version
Generic Validity
Author: Kasia
MODEL::VERSION
MODEL::VALIDITY
Version: 1.0
* 1 FRAME
CONDITION
Created: 23/05/2011 16:16:28
+restricted to
Updated: 05/01/2012 17:29:38
Serv ice Coupled Journey MODEL:: Coupled Journey
Service Calendar Frame May 2011
Journey PURPOSE OF JOURNEY MODEL::TYPE OF
Reusable Availability MODEL:: MODEL::SERVICE TIMETABLE VERSION
MODEL:: PARTITION COUPLING
AVAILABILITY CONDITION CALENDAR FRAME FRAME renamed to
TYPE OF
TIMETABLE FRAME
+take use of
SERVICE
0.1
0.* +dated by
TIMETABLE FRAME
Coupled Journey
Generic Point &
MODEL::TRAIN
Service Journey
Notice
Link MODEL::
NUMBER
MODEL::GROUP
MODEL::
GROUP OF LINKS
OF SERVICES
0.*
NOTICE
0.*
0.1
0.1
Vehicle Journey Times
Coupled Journey MODEL::
Journey Accounting
MODEL::JOURNEY
JOURNEY PART COUPLE
MODEL::JOURNEY
FREQUENCY GROUP
ACCOUNTING
0.*
*
0.1
+runs on 0.1 +valid for
0.1
JOURNEY
+including as
+including as
+composed of Vehicle Journey
1.*
main part
joining part
MODEL::VEHICLE
JOURNEY
+used by default by
INTERCHANGE
Time Demand Type *
Interchange MODEL::
MODEL::TIME * SERVICE JOURNEY
+made using
DEMAND TYPE INTERCHANGE
INTERCHANGE
+subdivided in
+for 1 Interchange MODEL::
SERVICE JOURNEY
Serv ice
+joining 1
PATTERN
Journey
INTERCHANGE
0.*
MODEL:: +part of
SERVICE +used as main part in
*
JOURNEY Coupled Journey
+used to define *
MODEL::JOURNEY
PART
Time Demand Type
Vehicle Journey Interchange
MODEL::TIME DEMAND
MODEL::DEAD RUN MODEL::
TYPE ASSIGNMENT
JOURNEY
Vehicle Journey Times MEETING
MODEL::TEMPLATE
VEHICLE JOURNEY
Figure 4 — Timetable Frame – Conceptual MODEL (UML)
7.1.1.1.2 Timetable Frame – Physical Model
The following diagram shows the Physical model for a TIMETABLE FRAME.
class XSD NeTEx TP Timetable Frame Intro
defriened fstricorted to
DataManagedObject
DataManagedObject produced by source of
TypeOfValue
* 1
belongs tcoomprising
ValidityCondition VersionFrame
DataSource
0.1
*
0.*
TypeOfValue
TypeOfValue
PurposeOfJourneyPartition
TimingAlgorithm
Av ailabilityCondition
TypeOfEntity
TypeOfValue
Serv iceCalendarFrame
booking times TypeOfServ ice
TypeOfCoupling
dated by 0.1
uses 0.*
TimetableFrame
DataManagedObject
GroupOfEntities GroupOfEntities
DataManagedObject
GroupOfLinks GroupOfServ ices TrainNumber
Notice
0.* 0.1
made up of identified by
identified by
DataManagedObject
identifies
in 0.* 0.*
JourneyAccounting
identifies 0.*
Journey
Interchange
DataManagedObject
VehicleJourney
Serv iceJourneyInterchange
JourneyPartCouple
1.*
0.1
runs on 0.1 subdivided in 1
composed of
including as joining part
Interchange
{ordered}
Serv iceJourneyPatternInterchange
GroupOfEntities joining
part of * 0.*
JourneyFrequencyGroup
DataManagedObject
DataManagedObject
DeadRun
JourneyPart
runs on defines 1.*
JourneyMeeting
0.*
flexible properties
Serv iceJourney
VersionedChild
DataManagedObject
0.1
TimeDemandType FlexibleServ iceProperties
is defined by
1.*
for 1
TemplateVehicleJourney
used to defused tineo defi1ne 1
TemplateServ iceJourney
Name: XSD NeTEx TP Timetable Frame Intro
associated with *
associated with *
Author: nickk
JourneyWaitTime
Version: 1.0
JourneyRunTime
Created: 10/12/2010 17:19:28
JourneyPatternWaitTime
JourneyPatternRunTime
Updated: 11/04/2012 14:53:22
used to define *
DataManagedObject
TimeDemandTypeAssignment
Figure 5 — Timetable Frame Contents – Physical Model (UML)
class XSD NeTEx TP Timetable Frame Model
VersionFrame TypeOfEntity
DataManagedObject
Serv iceCalendarFrameModel::Serv iceCalendarFrame VehicleJourneyModel::
Serv iceCalendarModel::
days valid
0.*
for DayType TypeOfServ ice
ValidityCondition
dated by 0.1
booking times
0.*
Av ailabilityConditionModel::Av ailabilityCondition
0day.1 type
uses
0.*
for 1
DataManagedObject
VersionFrame
TypeOfValue
TimeDemandTypeModel::TimeDemandTypeAssignment
TimetableFrameModel::TimetableFrame
«ImplementAsEnum»
used to define *
CoupledJourneyModel::TypeOfCoupling
VehicleModes :VehicleModeEnum [0.*]
for 1
HeadwayService :boolean [0.1]
DataManagedObject Monitored :boolean [0.1]
GroupOfEntities
TimeDemandTypeModel::TimeDemandType
«PK»
PointAndLinkModel::
id :TimetableFrameIdType
GroupOfLinks
used by default by us0ed by.1 0.* 0.*
runs on
«EV»
on
NetworkView :NetworkView [0.1]
GroupOfEntities
LineView :LineView [0.1] DerivedView
default
0.* VehicleJourneyFrequencyModel::
OperatorView :OrganisationView [0.1]
«TM_VIEW»
JourneyFrequencyGroup
ServiceCalendarFrameRef :ServiceCalendarFrameRef* [0.1]
LineAndRouteViews::NetworkView
composed of DefaultMode :VehicleModeEnum [0.1]
worked on * made using * uses 0.*
«contained»
0.1
DataManagedObject
Journey valid for runs on comprising bookingTimes :AvailabilityCondition [0.*]
1.*
timeDemandTypes :TimeDemandType [0.*]
JourneyAccountingModel::
VehicleJourneyModel::VehicleJourney
*
timeDemandTypeAssignments :TimeDemandTypeAssignment [0.*]
JourneyAccounting
timingLinkGroups :GroupOfLinks [0.*]
comcbiomnesbi fned irom n 1 1
0.*
0.1
DerivedView default
0.* vehicleJourneys :Journey [0.*]
subdivided in
OrganisationView::
1 frequencyGroups :Interchange [0.*]
VersionedChild
OrganisationView
{ordered} groupsOfServices :GroupOfServices [0.*]
trainNumbers :TrainNumbers [0.*] FlexibleServ iceModel::FlexibleServ iceProperties
in
journeyPartCouples :JourneyPartCouple [0.*]
typesOfService :TypeOfService [0.*]
Serv iceJourneyModel::
identifies flexibleServiceProperties :FlexibleServiceProperties [0.*]
Serv iceJourney
notices :Notice [0.*]
DerivedView
noticeAssignments :NoticeAssignment [0.*]
journeyMeetings :JourneyMeeting [0.*] «TM_VIEW»
journeyInterchanges :Interchange [0.*] LineAndRouteViews::DirectionView
default
VehicleJourneyModel:: interchangeRules :InterchangeRule [0.*]
DataManagedObject
0.1
DeadRun journeyAccounting :JourneyAccounting [0.*]
DerivedView
NoticeModel::Notice
defaultInterchanges :Interchange [0.*]
«TM_VIEW»
«FK»
LineAndRouteViews::LineView
JourneyAccountingRef :JourneyAccounting [0.1]
made up of
GroupOfEntities
runs
identified by Serv iceJourneyModel::GroupOfServ ices
0.*
applies to
DataManagedObject
note 0.*
VehicleJourneyModel::
identifies
TrainNumber DerivedView
Interchange
DataManagedObject
part of * 0.1 0.* «TM_VIEW»
InterchangeModel::
CoupledJourneyModel:: Interchange NoticeAssignmentView::
identified
Serv iceJourneyInterchange
DataManagedObject
by JourneyPartCouple NoticeAssignmentView
InterchangeModel::
CoupledJourneyModel::
joining
Serv iceJourneyPatternInterchange
0.1
JourneyPart Name: XSD NeTEx TP Timetable Frame Model
0.* Author: nickk
including as joining part
0.*
Version: 1.0
DataManagedObject
Created: 25/03/2011 10:05:23
0.*
combining InterchangeModel::JourneyMeeting Updated: 11/04/2012 14:53:22
Figure 6 — Timetable Frame – Physical Model Detail (UML)
7.1.1.1.3 Timetable Frame — XSD and attributes
7.1.1.1.3.1 TimetableFrame – Model Element
A set of timetable data (VEHICLE JOURNEYs, etc.) to which the same VALIDITY CONDITIONs have been
assigned.
Table 1 – TimetableFrame – Element
Classif Name Type Cardin Description
ication ality
::> ::> VersionFrame ::>
TIMETABLE FRAME inherits from
VERSION FRAME.
«PK» id TimetableFrameIdT 1:1 Identifier of TIMETABLE FRAME.
ype
VehicleModes VehicleModeEnum 0:* Reference to vehicle transport MODEs
TIMETABLE
HeadwayService xsd:xsd:boolean 0:1 Whether services of TIMETABLE are
operated a headway services.
xsd:xsd:boolean
Monitored 0:1 Whether services of TIMETABLE are
monitored in real time.
«EV» NetworkView NetworkView 0:1 Reference to default NETWORK for
TIMETABLE and derived values of
NETWORK.
«EV» LineView LineView 0:1 Reference to default LINE for TIMETABLE
and derived values of LINE.
«EV» OperatorView OrganisationView 0:1 Reference to default OPERATOR for
TIMETABLE and derived values of
OPERATOR.
«EV» ServiceCalendarFra ServiceCalendarFra 0:1 Reference to default Service CALENDAR
meRef meRef for TIMETABLE.
«EV» DefaultMode VehicleModeEnum 0:1 Reference to default Transport MODE for
TIMETABLE.
«cntd» JourneyAccounting JourneyAccounting 0:1* Default JOURNEY ACCOUNTING values
Ref Ref for JOURNEYs in frame.
«cntd» bookingTimes AvailabilityCondition 0:* Times at which bookings can be made for
the services in the Timetable.
«cntd» timeDemandTypes TimeDemandType 0:* TIME DEMAND TYPEs in the frame.
«cntd» timeDemandTypeA TimeDemandTypeA 0:* TIME DEMAND TYPE ASSIGNMENTS in
ssignment
ssignments the frame.
«cntd» timingLinkGroups GroupOfLinks 0:* TIMING LINK GROUPs in the frame.
«cntd» vehicleJourneys Journey 0:* VEHICLE JOURNEYs & SERVICE
JOURNEYS s in the frame.
«cntd» frequencyGroups FrequencyGroup 0:* FREQUENCY GROUPs in the frame.
«cntd» groupsOfServices GroupOfServices 0:* GROUP OF SERVICEs in the frame.
«cntd» journeyPartCouples JourneyPartCouple 0:* JOURNEY PART COUPLEs in the frame.
«cntd» coupledJourneys CoupledJourney 0:* COUPLED JOURNEYs in the frame.
«cntd» serviceFacilitySets ServiceFacilitySet 0:* SERVICE FACILITY SETs in the frame.
«cntd» typesOfService TypeOfService 0:* TYPEs OF SERVICE in the frame.
«cntd» flexibleServiceProp FlexibleServiceProp 0:* FLEXIBLE SERVICE PROPERTIES in the
erties erties frame.
«cntd» notices Notice 0:* NOTICEs in the frame.
«cntd» noticeAssignments NoticeAssignment 0:* NOTICE ASSIGNMENTs in the frame.
«cntd» journeyMeetings JourneyMeeting 0:* JOURNEY MEETINGs in the frame.
«cntd» journeyInterchange Interchange 0:* JOURNEY FREQUENCY GROUPs in the
s frame.
«cntd» interchangeRules InterchangeRule 0:* INTERCHANGE RULEs in the frame.
«cntd» journeyAccounting JourneyAccounting 0:* Default JOURNEY ACCOUNTING values
s for JOURNEYs in frame.
Timetable_VersionFrameStructure (restriction)
attributes
DataManagedObjectGroup
C ommon Properties of an object managed by a responsible
O RGA NISA TIO N.
VersionFrameGroup
Elements of a V ERSIO N FRA ME.
VehicleModes
type VehicleModeListOfEnumerations
0 .1
Modes of V EHIC LE JO URNEYs in timetable.
TimetableFrame
type Timetable_VersionFrameStructure
HeadwayService
A coherent set of timetable data (V EHIC LE JO URNEYs and
type xsd:boolean
TimetablePropertiesGroup
BLO C Ks) to which the same V A LIDITY C O NDITIO Ns
hav e been assigned.
A dditional descriptiv e properties of TIMETA BLE FRA ME. 0 .1
Whether this is a Headway SERV IC E, that is, one shown as
operating at a prescribed interv al rather than to a fixed
timetable.
Monitored
type xsd:boolean
0 .1
Whether V EHIC LE JO URNEYs of line are normally
monitored. Prov ides a default v alue for the Monitored
element on indiv idual journey s of the timetable.
TimetableDefaultsGroup
Default properties of elements in TIMETA BLE FRA ME. Use
these v alues on child elements if not specified on indiv idual
elements.
timeDemandTypes
type timeDemandTypesInFrame_RelStr.
0 .1
TIME DEMA ND TYPEs in frame.
timeDemandTypeAssignments
TimeDemandTypeInFrameGroup
type timeDemandTypeAssignmentsInFr.
Elements for use of TIME DEMA ND TYPE in a frame.
0 .1
TIME DEMA ND TYPE A SSIGNMENTs in frame.
timingLinkGroups
type groupOfLinksInFrame_RelStructure
0 .1
TIMING LINK GRO UPs in frame.
TimetableJourneyInFrameGroup
Properties of journey s in TIMETA BLE FRA ME.
notices
TimetableVersionFrameGroup
type noticesInFrame_RelStructure
Elements for a TIMETA BLE FRA ME.
0 .1
NoticeAssignmentsInFrameGroup
NO TIC Es in frame.
Elements for use of NO TIC Es in a frame.
noticeAssignments
type noticeAssignmentsInFrame_RelSt.
0 .1
NO TIC E A SSIGNMENTs in frame.
journeyMeetings
type journeyMeetingsInFrame_RelStru.
0 .1
JO URNEY MEETINGs in frame.
journeyInterchanges
type journeyInterchangesInFrame_Rel.
0 .1
InterchangeInFrameGroup
INTERC HA NGES in frame.
Properties of INTERC HA NGEs in TIMETA BLE FRA ME.
defaultInterchanges
type defaultInterchangseInFrame_RelS.
0 .1
DEFA ULT INTERC HA NGES in frame.
interchangeRules
type interchangeRulesInFrame_RelStru.
0 .1
INTERC HA NGE RULEs in frame.
vehicleTypes
VehicleTypeInFrameGroup
type vehicleTypesInFrame_RelStructure
Elements for a V EHIC LE TYPEs in frame.
0 .1
V EHIC LE TYPEs in frame.
journeyAccountings
JourneyAccountingInFrameGroup
type journeyAccountingsInFrame_RelS.
Elements for a V EHIC LE TYPEs in frame.
0 .1
V EHIC LE TYPEs in frame.
Figure 7 — TimetableFrame — XSD
TimetableFrameDefaultsGroup - Group
NetworkView
type Netw ork_DerivedView Structure
Simplified v iew of a NETWO RK.
LineView
type Line_DerivedView Structure
Simplified v iew of a LINE.
OperatorView
type Operator_DerivedView Structure
Simplified v iew of O PERA TO R. A ll data except the identifier
will be deriv ed through the relationship.
ServiceCalendarFrameRef
TimetableDefaultsGroup
type ServiceCalendarFrameRefStructure
Default properties of elements in TIMETA BLE FRA ME. Use
Reference to a SERV IC E C A LENDA R FRA ME.
these v alues if not specified on indiv idual elements.
DefaultMode
type VehicleModeEnumeration
Default V EHIC LE MO DE to use on JO URNEYs in
TIMETA BLE.
JourneyAccountingRef
type JourneyAccountingRefStructure
Reference to a JO URNEY A C C O UNTING.
bookingTimes
type containedAvailabilityConditions_R.
When bookings can be made for a SERV IC E.

Figure 8 — TimetableFrameDefaultsGroup — XSD
TimetableJourneyInFrameGroup - Group
vehicleJourneys
type journeysInFrame_RelStructure
V EHIC LE JO URNEYS in frame.
frequencyGroups
type frequencyGroupsInFrame_RelStr.
FREEWUENC Y GRO UPs In frame. C an be used to
template V EHC ILE JO URNEYs
groupsOfServices
type groupsOfServicesInFrame_RelStr.
Groupings of Journey s In frame. C an be used to define
inbound and outbound beds for a matrix presentation of teh
JO RUNEYs in the TIMETA BLE.
trainNumbers
type trainNumbersInFrame_RelStructure
TRA IN NUMBERs  in frame.
TimetableJourneyInFrameGroup
journeyPartCouples
Properties of journey s in TIMETA BLE FRA ME.
type journeyPartCouplesInFrame_RelSt.
JO URNEY C O UPLINGs in frame.
coupledJourneys
type coupledJourneysInFrame_RelStru.
JO URNEY C O UPLINGs in frame.
serviceFacilitySets
type serviceFacilitySetsInFrame_RelSt.
SERV IC E FA C ILITIES in frame.
typesOfService
type typesOfServiceInFrame_RelStruc.
TYPES of SERV IC E in frame.
flexibleServiceProperties
type flexibleServicePropertiesInFrame.
FLEXIBLE SERV IC E PRO PERTIES in frame.

Figure 9 — TimetableJourneyInFrameGroup — XSD
7.2 Journey and Journey Times
The JOURNEY and JOURNEY TIMEs model exchanges planned services and dead runs and their timings.
7.2.1 Vehicle Journey
7.2.1.1 VEHICLE JOURNEY – Conceptual MODEL
NOTE The following explanations use excerpts from Transmodel.
The daily operation of a vehicle is described by VEHICLE JOURNEYs. A VEHICLE JOURNEY is the
defined movement of a vehicle using a specified JOURNEY PATTERN on a particular ROUTE. This
movement is hence made between the first and the last POINTs IN JOURNEY PATTERN. Being defined
for a DAY TYPE, a VEHICLE JOURNEY is a class of journeys that would take place at the same time on
each day of a specific DAY TYPE.
7.2.1.1.1 Basic Vehicle Journey – Conceptual MODEL
There are two different main types of VEHICLE JOURNEYs: passenger-carrying SERVICE JOURNEYs
and non-service DEAD RUNs.
— A SERVICE JOURNEY is a VEHICLE JOURNEY on which passengers will be allowed to board or
alight from vehicles at stops. These journeys are usually published and known by passengers.
— A DEAD RUN may be necessary for the vehicle to proceed, from the PARKING POINT it was parked
at, to the first STOP POINT of the JOURNEY PATTERN where it will start its service operation. On the
opposite direction, a DEAD RUN may relate the last STOP POINT the vehicle has stopped at (finishing
its service) to the PARKING POINT where it will be parked. A DEAD RUN may also occur when a
vehicle changes from one ROUTE to another one in order to continue its service there, or for other
various reasons.
class NeTEx TM TP Vehicle Journey Basic MODEL
Name: NeTEx TM TP Vehicle Journey Basic MODEL
Author: NeTEx
Version: 1.0
Service Calendar
JOURNEY
Created: 16/03/2010 12:40:40
MODEL::DAY TYPE
Updated: 03/10/2012 15:40:14
+ Name [0.1]
+for
+ Description [0.1]
«PK»
1.*
~ id
+worked
on
+timed *
from
VEHICLE JOURNEY
*
+ DepartureTime
+ JourneyDuration [o.1]
+for
«PK»
LINK SEQUENCE
+ id
Journey Pattern MODEL::
1 *
+made using
JOURNEY PATTERN
0.1
+by default timed
DEAD RUN
+th
...