FprCEN/TS 16614-2
(Main)Public transport - Network and Timetable Exchange (NeTEx) - Part 2: Public transport scheduled timetables exchange format
Public transport - Network and Timetable Exchange (NeTEx) - Part 2: Public transport scheduled timetables exchange format
16614 (NeTEx) is composed of a series of standards:
- Part 1: Description of the public transport network topology exchange format.
- Part 2: Description of the scheduled timetables exchange format.
- Part 3: Description of the fare information exchange format.
- Part 4: Description of the passenger information European profile (EPIP).
- Part 5: Description of the alternative modes exchange format.
- Part 6: Description of the accessibility European profile (EPIAP).
The present update concerns Part 2.
All the parts will be updated together, except Part 6 currently under formal vote (a NWI is produced for each Part). This update is done in a similar timeframe as the Transmodel (EN12896) revision, to achieve the best possible consistency.
The updated version of TS 16614 is going to be published as NeTEx v2.
The global updates consist in the following main extensions/enhancements:
- Deck plan allowing for a digitalised representation of spaces and equipment on board vehicles (with considerations of accessibility features),
- Physical layout of compound vehicles (e.g. train composition),
- Multiple minor enhancements, adjustments, and fixes to consider all the feedback from the previous versions of NeTEx, especially in the context of the European Delegated Regulation EU 2017/1926
Consistency and coherences with Transmodel and SIRI and OJP have also been challenged and minor updates are to be integrated in this revision.
Öffentlicher Verkehr - Netzwerk- und Fahrplan-Austausch (NeTEx) - Teil 2: Austauschformat für Fahrpläne im öffentlichen Verkehr
Transport Public - Échanges des informations planifiées (NeTEx) - Partie 2: Description de l'offre de transport
Javni prevoz - Izmenjava omrežnih in voznorednih podatkov (NeTEx) - 2. del: Izmenjavni format za vozne rede rednega javnega prevoza
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
01-december-2025
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:
Austauschformat für Fahrpläne im öffentlichen Verkehr
Transport Public - Échanges des informations planifiées (NeTEx) - Partie 2: Description
de l'offre de transport
Ta slovenski standard je istoveten z: FprCEN/TS 16614-2
ICS:
03.220.01 Transport na splošno Transport in general
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
FINAL DRAFT
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
October 2025
ICS Will supersede CEN/TS 16614-2:2020
English Version
Public transport - Network and Timetable Exchange
(NeTEx) - Part 2: Public transport scheduled timetables
exchange format
Transport Public - Échanges des informations Öffentlicher Verkehr - Netzwerk- und Fahrplan-
planifiées (NeTEx) - Partie 2: Description de l'offre de Austausch (NeTEx) - Teil 2: Austauschformat für
transport Fahrpläne im öffentlichen Verkehr
This draft Technical Specification is submitted to CEN members for Vote. It has been drawn up by the Technical Committee
CEN/TC 278.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.
Warning : This document is not a Technical Specification. It is distributed for review and comments. It is subject to change
without notice and shall not be referred to as a Technical Specification.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. FprCEN/TS 16614-2:2025 E
worldwide for CEN national Members.
Contents Page
European foreword. 5
0 Introduction . 6
0.1 General . 6
0.2 Transport modes . 6
0.3 Compatibility with existing standards and recommendations . 7
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 9
4 Symbols and abbreviations . 9
5 Use Cases for Journey & Journey Time Exchange . 9
6 Generic Physical Model and XSD mapping rules. 9
7 Timing Information – Conceptual and physical data model . 9
7.1 Introduction . 9
8 The Journey and Journey Times model . 9
8.1 General . 9
8.2 Journey and Journey Times – Model dependencies .10
9 VEHICLE JOURNEY .10
10 SERVICE JOURNEY .10
11 TIME DEMAND TIMEs .10
12 PASSING TIMEs .10
13 JOURNEY TIMINGs .10
14 JOURNEY PATTERN TIMEs .10
15 VEHICLE JOURNEY TIMEs .10
16 INTERCHANGE .11
17 COUPLED JOURNEY .11
18 JOURNEY ACCOUNTING .11
18.1 General . Error! Bookmark not defined.
18.2 Explicit Frames .11
18.2.1 Timetable Frame .11
18.3 Journey and Journey Times .21
18.3.1 Vehicle Journey .21
19 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. .21
19.1.2 Service Journey .43
20 As the service between an origin and a destination, as advertised to the public. .43
21 As the longest service during which a passenger is allowed to stay on the same
vehicle. .43
21.1.2 Time Demand Times .68
21.1.3 Journey Timing .78
22 JOURNEY LAYOVER; . 78
23 JOURNEY WAIT TIME; . 78
24 JOURNEY HEADWAY; . 78
25 JOURNEY RUN TIME; . 78
26 TURNAROUND TIME LIMIT; . 78
27 DEFAULT DEAD RUN TIME; . 78
28 DEFAULT SERVICE JOURNEY RUN TIME. . 78
28.1.2 Journey Pattern Times . 87
28.1.3 Vehicle Journey Times . 94
28.1.4 Vehicle Journey Frequency . 101
28.1.5 Interchange . 111
29 Interchange with another service, of which only the arrival or departure time is
known. . 114
30 More generally, service scheduled according to the time fixed for an external
event, which will feed, or be fed by, this service (school, spectacle, etc.). . 114
31 Organisation of a meeting (hub) between several services, during a defined time
band; this is a simplified specification of several interchanges. If needed this
could be described in detail using several INTERCHANGE RULEs or SERVICE
JOURNEY INTERCHANGEs. . 114
32 Specification of a rendez-vous (time and place) for any journey that can meet the
appointment. . 115
32.1.2 Interchange Rule . 133
32.1.3 Coupled Journey . 144
32.1.4 Flexible Service. 165
33 BOOKING ARRANGEMENT describing, for on demand service, the type of booking
(online, CallOffice, CallDriver, etc.), how long in advance of departure day or time
a service may be ordered, etc. . 167
34 CONTACT DETAILs providing URL, phone number, mail, etc. in order to book the
service or to get information. . 167
34.1.2 Dated Journey . 174
34.1.3 Passing Times . 182
34.1.4 Passenger at Stop Times . 191
34.1.5 Call . 195
35 PASSING TIMEs, grouped by arrival and departure; . 196
36 Stop usage information (passthrough, no boarding, etc.); . 196
37 DESTINATION DISPLAY and VIA information; . 196
38 STOP ASSIGNMENTs to specific QUAYs i.e. platforms; . 196
39 Visit number (order within the VEHICLE JOURNEY, including repeated visits); . 196
40 Referenced entities and their derived properties, such as SCHEDULED STOP
POINT, JOURNEY PARTs, SERVICE JOURNEY INTERCHANGES, SERVICE LINKs, etc;
........................................................................................................................................................... 196
41 Onward SERVICE LINKs for the route that is being. followed . 196
42 NOTICEs relating to the stop. . 196
42.1.2 Dated Call . 217
43 NOTICEs relating to the CALL. . 218
43.2 Journey Assignment . 219
43.2.1 Journey Accounting . 219
43.2.2 Deck Plan Assignment . 224
43.2.3 Deck Entrance Assignment . 228
43.2.4 Stopping Position Assignment . 232
43.2.5 Train Component Label Assignment . 234
43.2.6 Vehicle Journey Stop Assignment . 237
43.2.7 RestrictedServiceFacilitySet . 240
44 Vehicle Scheduling . 242
44.1 Vehicle Scheduling – Model dependencies. 242
44.2 Vehicle Scheduling . 244
44.2.1 Vehicle Schedule Frame . 244
44.2.2 Vehicle Service . 246
44.2.3 Train Service . 260
44.2.4 Recharging Plan . 263
Annex A (informative) Monitoring & Control (Transmodel Part4) . 270
A.1 Introduction . 270
A.2 Monitoring & Control . 270
A.2.1 Monitored Vehicle Journey . 270
A.2.2 Dated Passing Times – Physical Model . 277
A.3 Occupancy . 283
A.3.1 Vehicle Occupancy . 283
A.3.2 Deck Occupancy . 290
A.3.3 Occupancy View . 295
Annex B (informative) Driver Scheduling (Transmodel Part7) . 304
B.1 Introduction . 304
B.2 Driver Scheduling . 304
B.2.1 Driver Schedule Frame . 304
B.2.2 Time Allowance . 309
B.2.3 Duty . 311
B.2.4 Duty Stretch . 316
B.2.5 Driver Trip . 318
Annex C (informative) Changes in NeTEx Version 2.0 . 323
C.1 Introduction . 323
C.2 General Changes . 323
C.3 List of changes . 323
C.4 Github pull Requests . 324
Bibliography . 326
European foreword
This document (FprCEN/TS 16614-2:2025) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
This document is currently submitted to the Vote on TS.
This document will supersede CEN/TS 16614-2:2019.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
0 Introduction
0.1 General
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 document specifies a Network and Timetable Exchange (NeTEx) about public transport. It is
intended to be used to exchange static data relating to public transport between the systems of PT
organisations. It can also be seen as a complement 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; (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.
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information) based
on Transmodel V6.2 (EN 12986),and SIRI (CEN/TS 15531-4/5 and EN 15531-1/2/3) and supports
information exchange of relevance to public transport services for passenger information and
Automated Vehicle Monitoring Systems (AVMS).
NOTE Many NeTEx concepts are taken directly from Transmodel. 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 public transport scheduling systems and AVMS. However it is not
restricted to these purposes, and NeTEx can provide an effective solution to many other use cases for
transport data exchange.
0.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.
Such modes may be operated, conventionally according to a fixed timetable, or flexibly as demand
responsive services.
Additionally, NeTex v2.0 takes into account the alternative modes of operation such as cycle hire, taxis,
car-pooling, ride sharing. They have both network (i.e., places where services may be accessed),
service (i.e., the available services and how to book them), and fare aspects (i.e., the costs of different
services).
NeTex v2.0 distinguishes the following types of 'mode of operation':
— conventional mode of operation: the legacy method of operation which is provided as a scheduled
and/or flexible publicly advertised flexible transport offer. This method of operation is either following
a fixed schedule and fixed routes or linked to a fixed network/schedule but offering flexibility, in order
for instance, to optimise the service or to satisfy passenger demand;
— alternative mode of operation: any publicly advertised mode of operation different from the
conventional mode of operation, in particular vehicle sharing, vehicle rental and vehicle pooling; and
— personal mode of operation: a private mode of transport excluding any publicly advertised use.
0.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 organisations; 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.
1 Scope
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. As defined by
Transmodel, 'Public transport' has to be understood as services advertised and available for use by the
general public carried out by any means of transport.
This Technical Specification is made up of six 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 4 is the description of the European passenger information profile.
Part 5 is the description of the alternative modes exchange format.
Part 6 is the description of the European passenger information accessibility profile.
Part 1 is fully standalone, and parts 2, 3, 4, 5 and 6 rely on Part 1 and possibly any previous part.
The XML schema can be downloaded from http://netex-cen.eu (or directly from
https://github.com/NeTEx-CEN/NeTEx), along with available guidance on its use, example XML files,
and case studies of national and local deployments.
This document is highly technical, and a special care has been taken to keep the text readable. In
particular a set of formatting conventions is followed that enhances the usual CEN writing rules in
order to distinguish references to elements of the formal models within text:
Transmodel terms and NeTEx conceptual model elements are in capital letters (JOURNEY PATTERN
for example).
NeTEx physical model names are in bold italic font and use CamelCase style with no spaces
(JourneyPattern, for example).
NeTEx physical model attribute types are in italic font and use CamelCase style with no spaces
(TypeOfEntity, for example).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments)
applies.
CEN/TS 16614-1, 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 apply.
4 Symbols and abbreviations
For the purposes of this document, the symbols and abbreviations given in CEN/TS 16614-1 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 Introduction
The NeTEx Part 2 timing information model is split into four main submodels defined as UML packages.
Figure 1 – NeTEx Part 2 main packages
8 The Journey and Journey Times model
8.1 General
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 times model: describes all the different types of passing times
The vehicle service model: describes the information related to vehicles and their services
8.2 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 (UML)
8.3 Explicit Frames
8.3.1 Timetable Frame
8.3.1.1 TIMETABLE FRAME – Conceptual MODEL
The elements of the JOURNEY AND 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.
Figure 4 — Timetable Frame – Conceptual MODEL (UML)
8.3.1.2 Timetable Frame – Physical Model
The following diagram gives an overview of the contents of a TIMETABLE FRAME.
Figure 5 — Timetable Frame Contents – Physical Model (UML)
8.3.1.3 Timetable Frame Details – Physical Model
The following diagram shows the Physical model for a TIMETABLE FRAME.
Figure 6 — Timetable Frame – Physical Model Detail (UML)
8.3.1.4 Timetable Frame – XSD and attributes
8.3.1.4.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
Classification Name Type Cardin Description
ality
::> ::> VersionFrame ::> TIMETABLE FRAME inherits
from VERSION FRAME.
«PK» id TimetableFrameIdType 1:1 Identifier of TIMETABLE
FRAME.
«enum» VehicleModes AllPublicTransportModesE 0:* Reference to PUBLIC
num TRANSPORT MODEs for
TIMETABLE.
Classification Name Type Cardin Description
ality
HeadwayService xsd:boolean 0:1 Whether services of
TIMETABLE are operated as
headway services.
Monitored xsd:boolean 0:1 Whether services of
TIMETABLE are monitored in
real time. Provides a default
value for the Monitored
element on individual journeys
of the timetable.
XGRP TimetableDefaultsGroup xmlGroup 0:1 Elements specifying shared
defaults for timetable.
«cntd» timeDemandTypes TimeDemandType 0:* TIME DEMAND TYPEs in the
frame.
«cntd» timeDemandTypeAssignmen TimeDemandTypeAssignm 0:* TIME DEMAND TYPE
ts ent ASSIGNMENTS in the frame.
«cntd» timingLinkGroups GroupOfLinks 0:* TIMING LINK GROUPs in the
frame.
XGRP TimetableJourneyInFrameGr xmlGroup 0:1 Elements describing VEHICLE
oup JOURNEYs in timetable.
«cntd» notices Notice 0:* NOTICEs in the frame.
«cntd» noticeAssignments NoticeAssignment 0:* NOTICE ASSIGNMENTs in the
frame.
XGRP InterchangeInFrameGroup xmlGroup 0:1 Elements describing
INTERCHANGEs in timetable.
«cntd» vehicleTypes VehicleType 0:* VEHICLE TYPEs in the frame.
«cntd» journeyAccountings JourneyAccounting 0:* Default JOURNEY ACCOUNTING
values for JOURNEYs in frame.
«cntd» occupancies OccupancyView 0:* OCCUPANCY VIEWs in frame.
See Annex A. +v2.0
Figure 7 — TimetableFrame — XSD
8.3.1.4.1.1 TimetableDefaultsGroup – Model Group
The TimetableDefaultsGroup specifies default values that apply to all journeys in the TIMETABLE
FRAME timetable unless explicitly overridden by a specific journey.
Table 2 – TimetableDefaultsGroup – Group
Classific Name Type Cardi Description
ation nality
«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 OperatorView 0:1 Reference to default OPERATOR for
TIMETABLE and derived values of
OPERATOR.
«FK» ServiceCalendarFram ServiceCalendarFrameRef 0:1 Reference to default Service CALENDAR
eRef for TIMETABLE.
«enum» DefaultMode AllPublicTransportModesEnu 0:1 Reference to default PUBLIC TRANSPORT
m MODE for TIMETABLE. See Part1 for
allowed values.
«FK» Journey- JourneyAccountingRef 0:1 Default JOURNEY ACCOUNTING value for
AccountingRef JOURNEYs in frame.
«cntd» bookingTimes AvailabilityCondition 0:* Times at which bookings can be made for
the services in the Timetable.
«cntd» AccessibilityAssessme AccessibilityAssessment 0:1 Default ACCESSIBILITY ASSESSMENT to
nt assume for journeys in frame. +v1.1
«FK» TransportTypeRef TransportTypeRef 0:1 Reference to TRANSPORT TYPE.
Figure 8 — TimetableDefaultsGroup — XSD
8.3.1.4.1.2 TimetableJourneyInFrameGroup – XML Group
The TimetableJourneyInFrameGroup specifies the journeys in the TIMETABLE.
Table 3 – TimetableJourneyInFrameGroup – Group
Classification Name Type Cardin Description
ality
«cntd» vehicleJourneys Journey (VehicleJourney / 0:* VEHICLE JOURNEYs & SERVICE
DatedVehicleJourney / JOURNEYs in the frame.
NormalDatedVehicleJourney
/ ServiceJourney /
DatedServiceJourney /
DeadRun / SpecialService /
TemplateServiceJourney)
«cntd» frequencyGroups FrequencyGroup 0:* FREQUENCY GROUPs in the
frame.
Classification Name Type Cardin Description
ality
«cntd» groupsOfServices GroupOfServices 0:* GROUP OF SERVICEs in the
frame.
«cntd» trainNumbers TrainNumber 0:* TRAIN NUMBERs 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» restrictedServiceFacilitySet restrictedServiceFacilitySet 0:* Restricted Service Facility Sets
s in the frame. +v2.0
Note: a UML synchronisation
discrepancy has been identified
here and shall be solved un
future revisions
«cntd» deckPlanAssignments DeckPlanAssignment 0:* DECK PLAN ASSIGNMENTs in
the frame.
«cntd» typesOfService TypeOfService 0:* TYPEs OF SERVICE in the
frame.
«cntd» flexibleServiceProperties FlexibleServiceProperties 0:* FLEXIBLE SERVICE
PROPERTIES in the frame.
«cntd» vehicleJourneyStopAssign VehicleJourney 0:* VEHICLE JOURNEY STOP
ments StopAssignment ASSIGNMENTs in the frame.
Figure 9 — TimetableJourneyInFrameGroup — XSD
8.3.1.4.1.3 InterchangeInFrameGroup– XML Group
The InterchangeInFrameGroup specifies the interchanges in the TIMETABLE.
Table 4 – InterchangeInFrameGroup – Group
Classification Name Type Cardin Description
ality
«cntd» journeyMeetings JourneyMeeting 0:* JOURNEY MEETINGs in the
frame.
«cntd» journeyInterchanges Interchange 0:* INTERCHANGEs in the frame.
«cntd» defaultInterchanges DefaultInterchange 0:* DEFAULT INTERCHANGEs in
the frame.
Classification Name Type Cardin Description
ality
«cntd» interchangeRules InterchangeRule 0:* INTERCHANGE RULEs in the
frame.
journeyMeetings
type journeyMeetingsInFrame_RelStructure
JO URNEY MEETINGs in frame.
journeyInterchanges
type journeyInterchangesInFrame_RelStructure
InterchangeInFrameGroup INTERC HA NGES in frame.
Properties of INTERC HA NGEs in defaultInterchanges
TIMETA BLE FRA ME.
type defaultInterchangseInFrame_RelStructure
DEFA ULT INTERC HA NGES in frame.
interchangeRules
type interchangeRulesInFrame_RelStructure
INTERC HA NGE RULEs in frame.
Figure 10 — InterchangeInFrameGroup — XSD
8.4 Journey and Journey Times
The JOURNEY AND JOURNEY TIMEs model exchanges planned services and dead runs and their
timings.
8.4.1 Vehicle Journey
8.4.1.1 VEHICLE JOURNEY – Conceptual MODEL
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.
8.4.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.
9 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.
Figure 11 — Basic Vehicle Journey – Conceptual MODEL (UML)
9.1.1.1.1 Vehicle Journey Details – Conceptual MODEL
A VEHICLE JOURNEY may be further defined by a number of other elements, as shown in the following
figure. These include interactions with other journeys (JOURNEY PART, JOURNEY MEETING, etc.);
temporal and other conditions (DAY TYPE, VALIDITY CONDITION); further descriptive and
classification information (TRAIN NUMBER, PRODUCT CATEGORY, TYPE OF SERVICE, stops etc.); and
operational data (BLOCK).
A TEMPLATE JOURNEY allows a set of VEHICLE JOURNEYs to be defined that follow a common
temporal pattern – See FREQUENCY GROUPs below.
Figure 12 — Vehicle Journey – Conceptual MODEL (UML)
9.1.1.2 Vehicle Journey – Physical Model
9.1.1.2.1 Journey – Physical Model
The JOURNEY physical model describes common properties of all types of JOURNEY.
Figure 13 —Journey – Journey MODEL (UML)
1.1.1.1.1 Vehicle Journey Introduction – Physical Model
The following diagram gives an overview of the VEHICLE JPOURNEY model.
Figure 14 — Vehicle Journey – Physical Model overview (UML)
9.1.1.2.2 Vehicle Journey Overview – Physical Model
The VEHICLE JOURNEY physical model adds detailed attributes for VEHICLE JOURNEYs.
Figure 15 — Vehicle Journey – Physical Model (UML)
9.1.1.2.3 Journey Identification – Physical Model
Sometimes it is useful to be able to reference a service journey without specifying an identifier. A
JourneyDesignator allows a JOURNEY to be identified using a combination of attributes.
For example, “the SNCF operated Train that arrives in Paris from Lyon at 16:52”.
A particular case in point is to arrange interchange between
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...