prEN 12896-3

SLOVENSKI STANDARD
01-februar-2026
Javni prevoz - Referenčni podatkovni model - 3. del: Časovne informacije in
razporejanje vozil
Public transport - Reference data model - Part 3: Timing information and vehicle
scheduling
Öffentlicher Verkehr - Datenreferenzmodell - Teil 3: Taktinformationen und
Fahrzeugdisposition
Transports publics - Modèle de données de référence - Partie 3 : Informations horaires
et horaires des véhicules
Ta slovenski standard je istoveten z: prEN 12896-3
ICS:
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.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
November 2025
ICS 35.240.60 Will supersede EN 12896-3:2016
English Version
Public transport - Reference data model - Part 3: Timing
information and vehicle scheduling
Transports publics - Modèle de données de référence - Öffentlicher Verkehr - Datenreferenzmodell - Teil 3:
Partie 3 : Informations horaires et horaires des Taktinformationen und Fahrzeugdisposition
véhicules
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 278.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

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 European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

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. prEN 12896-3:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
1 Scope . 5
2 Normative references . 5
3 Terms, definitions and abbreviations . 5
3.1 Terms and definitions . 5
3.2 Abbreviations . 6
4 General information . 7
5 Timing information and vehicle scheduling data domain . 7
5.1 Introduction . 7
5.2 Overview - Model and document structure . 7
5.3 Journey and journey times . 8
5.3.1 Vehicle journey . 8
5.3.2 Service journey . 11
5.3.3 Time demand times . 14
5.3.4 Journey timing . 16
5.3.5 Journey pattern times . 19
5.3.6 Vehicle journey times . 20
5.3.7 Interchange . 22
5.3.8 Interchange rule – Conceptual model . 26
5.3.9 Coupled journey . 27
5.3.10 Flexible service . 32
5.3.11 Journey accounting . 34
5.4 Dated journey – Conceptual model . 35
5.4.1 Dated journey . 35
5.4.2 Dated vehicle journey interchange . 37
5.5 Passing times . 38
5.5.1 Passing times . 38
5.5.2 Passenger at stop time . 40
5.6 Vehicle scheduling . 41
5.6.1 Tactical resource planning . 41
5.6.2 Resources for tactical planning . 41
5.6.3 Vehicle service . 42
5.7 Vehicle journey assignments . 47
5.7.1 Train component label assignment – Conceptual model . 47
5.7.2 Stopping position assignment . 48
5.7.3 Deck plan assignment . 49
5.7.4 Deck entrance assignment . 51
5.7.5 Vehicle recharging plan . 52
5.8 Explicit frames . 54
5.8.1 Timetable frame . 54
5.8.2 Vehicle schedule frame . 54
Annex A (normative) Data Dictionary . 56
A.1 Introduction . 56
A.2 Data Dictionary – Timing information and vehicle scheduling . 56
Annex B (informative) Data Model Evolutions . 84
B.1 Introduction . 84
B.2 Diagrams with additional concepts and relationships with other Parts . 84
B.3 Diagrams with additional relationships . 85
Annex C (informative) Significant technical changes between this document and the
previous edition . 87
Bibliography . 88

European foreword
This document (prEN 12896-3: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 CEN Enquiry.
This document will supersede EN 12896-3:2016.
Annex C provides details of the significant technical changes between this document and
EN 12896-3:2016.
This document is part of the European standard series EN 12896, known as “Transmodel”. This is a series
of documents that comprises the following parts:
— EN 12896-1, Public transport - Reference data model - Part 1: Common concepts
— EN 12896-2, Public transport - Reference data model - Part 2: Public transport network
— EN 12896-3, Public transport - Reference data model - Part 3: Timing information and vehicle
scheduling
— EN 12896-4, Public transport - Reference data model - Part 4: Operations monitoring and control
— EN 12896-5, Public transport - Reference data model - Part 5: Fare management
— EN 12896-6, Public transport - Reference data model - Part 6: Passenger information
— EN 12896-7, Public transport - Reference data model - Part 7: Driver management
— EN 12896-8, Public transport - Reference data model - Part 8: Management information and statistics
— EN 12896-10, Public transport - Reference data model - Part 10: Alternative Modes
Together these documents create Transmodel version 6.2 and thus replace Transmodel V6.0.
In addition to the nine normative parts of this series, a Technical Report (Public Transport – Reference
Data Model – Informative Documentation) was published in 2016 under the reference CEN/TR 12896-9.
It provides additional information to help those implementing projects involving the use of Transmodel.
It is intended that this Technical Report will be extended and republished as soon as all the normative
parts are revised.
The split into several documents is intended to ease the task of users interested in particular functional
domains. It corresponds to the modularisation of Transmodel into functionally related parts, each made
up of distinct UML packages and subpackages that describe a particular aspect of public transport. The
NeTEx UML model follows the same modularisation, allowing a direct mapping from the conceptual
model to the implementation.
For information on the conventions, methodology and notations for conceptual modelling, for a clear
overview to help understand the core principles, structure and purpose of Transmodel, and for
information on the Functional domains and Modes of operation, refer to EN 12896-1.
1 Scope
The present document is composed of the following data packages:
— journey and Interchange;
— vehicle Journey Assignment;
— journey Times;
— block and Vehicle Service;
— dated Journey;
— explicit Frame.
This document itself is composed of the following parts:
— main document representing the data model for the concepts shared by the different domains
covered by Transmodel (normative);
— Annex A containing the data dictionary and attribute tables, i.e. the list of all the concepts presented
in the main document together with their definitions (normative);
— Annex B presenting the model evolution (informative);
— Annex C, providing details of the significant technical changes between this document and EN 12896-
1:2015 (informative)
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.
EN 12896-1, Public transport - Reference data model - Part 1: Common concepts
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 12896-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1.1
headway
interval between vehicles servicing a route and hence between the arrival of services at a stop
3.1.2
relief
person taking the place of another person as responsible for a certain task (such as driving a bus)
3.1.3
run time
time taken for a vehicle to go between two points
Note 1 to entry: In Transmodel a run time may be specified for the individual SERVICE LINK between two stops and
for the whole journey pattern.
3.1.4
wait time
time interval a vehicle spends waiting at a timing point such as a stop in the course of a journey, as distinct
from the run times spent moving between the points
3.2 Abbreviations
API Application Programming Interface
AVM Automatic Vehicle Monitoring
AVMS Automatic Vehicle Monitoring System
GIS Geographical Information System
GPS Global Positioning System
HTTP Hypertext Transfer Protocol
IFOPT Identification of Fixed Objects in Public Transport
ISO International Standards Organization
IT Information Technology
NeTEx Network and Timetable Exchange
PT Public Transport
PTO Public Transport Operator
OJP Open API for Distributed Journey Planning
OpRa Operating Raw Data and statistics exchange
SIRI Service Interface for Real-time Information
TM Transmodel
UML Unified Modelling Language
URI Uniform Resource Identifier
URL Universal Resource Locator
VDV Verband Deutscher Verkehrsunternehmen (Germany)
WGS World Geodetic Standard
4 General information
The following standards are based on the Transmodel conceptual data model for public transport domain
to provide a harmonized, interoperable, and consistent approach for public transport data, service
interfaces, and journey planning across Europe:
— EN 15531 (series) [10] to [16] – Service interfaces for real-time public transport operations.
— CEN/TS 16614 (series) (NeTEx) [17] to [22] – Network and timetable data exchange, including
passenger information and accessibility.
— CEN/TS 17118 [23] – Open API for distributed journey planning.
5 Timing information and vehicle scheduling data domain
5.1 Introduction
The work of the vehicles necessary to provide the service offer advertised to the public consists of service
journeys and dead runs (unproductive journeys are necessary to transfer vehicles where they are needed,
mainly from the depot into service and vice versa). Vehicle journeys are defined for day types rather than
individual operating days. A day type is a classification of all operating days for which the same service
offer has been planned. The whole tactical planning process is seen on the level of day types in the
reference data model, with all entities necessary to develop schedules. These include a series of entities
describing different types of run times and wait times, scheduled interchanges, turnaround times etc.
Chaining vehicle journeys into blocks of vehicle operations, and cutting driver duties from the vehicle
blocks, are parts of the main functions of vehicle scheduling and driver scheduling, respectively. The
corresponding entities and relationships included in the reference data model allow a comprehensive
description of the data needs associated with this functionality, independently of the particular methods
and algorithms applied by the different software systems.
5.2 Overview - Model and document structure
The timing information model is splits into four main sub-models defined as UML packages.
— Journey and journey times model: describes the time-related information at the level of vehicle
journeys, i.e. planned timing for the vehicles at day-type level. It splits into:
— vehicle journey model;
— service journey model;
— time demand times model;
— journey timing model ;
— journey pattern times model;
— vehicle journey times model;
— interchange model;
— interchange rule model;
— coupled journey model;
— flexible service model;
— journey accounting model;
— dated journey model: describes the link of the timing information for a single operating day and the
day type related timing;
— passing times model: describes all the different types of passing times for the day type related
information;
— vehicle service model: describes the information related the work of vehicles as planned for day
types. It constitutes the main part of the vehicle scheduling data domain.
5.3 Journey and journey times
5.3.1 Vehicle journey
5.3.1.1 Vehicle journey – Conceptual model
5.3.1.1.1 General
The daily operation of a vehicle is described by VEHICLE JOURNEYs. A VEHICLE JOURNEY is the planned
movement of a type of public transport vehicle using a specified JOURNEY PATTERN on a particular
ROUTE. This movement is made between the first and the last POINTs IN JOURNEY PATTERN. Being
defined for a DAY TYPE (see EN 12896-1, Public transport - Reference data model - Part 1: Common
concepts), a VEHICLE JOURNEY is a class of journeys that would take place at the same time on each day
of a specific DAY TYPE. The type of intended public transport vehicle is indicated by a VEHICLE TYPE,
TRAIN or COMPOUND TRAIN.
5.3.1.1.2 Basic-vehicle journey
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 (see. EN 12896-2,
Public transport - Reference data model - Part 2: Public transport network topology) at which it was
parked to the first SCHEDULED STOP POINT of the JOURNEY PATTERN (see EN 12896-2, Public
transport - Reference data model - Part 2: Public transport network topology) where it will start its
service operation. In the opposite direction, a DEAD RUN may relate the last SCHEDULED 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 (see EN 12896-2,
Public transport - Reference data model - Part 2: Public transport network topology) to another one
in order to continue its service there, or for various other reasons.
Figure 3 — Vehicle Journey – Basic MODEL (INFO)
5.3.1.1.3 Vehicle journey details – Conceptual model
A VEHICLE JOURNEY may be further defined by a number of other elements, as shown in Figure 4. These
include interactions with other journeys (JOURNEY PART, JOURNEY MEETING, etc.); temporal and other
conditions (DAY TYPE, VALIDITY CONDITION, see EN 12896-2, Public transport - Reference data model
- Part 2: Public transport network topology; 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.
Figure 4 — Vehicle Journey MODEL
5.3.1.2 Vehicle journey notice assignment
For passenger information (or sometimes driver information) purposes, it is often useful to attach
remarks to various parts of the supply (a point, a line, a section, etc.). For instance, the fact that a
shortened journey pattern is used exceptionally may be emphasized. Such remarks are usually printed
as footnotes on public timetables at stops, timetable booklets or, for driver information, on driver cards.
The entity NOTICE (see EN 12896-2, Public transport - Reference data model - Part 2: Public transport
network topology). describes such remarks. It may concern any entity, e.g. a whole LINE, or a GROUP OF
POINTS.
More frequently, a NOTICE will be assigned to a JOURNEY PATTERN, a COMMON SECTION (see
EN 12896-2, Public transport - Reference data model - Part 2: Public transport network topology), or
even a specific VEHICLE JOURNEY. In such a case, the same NOTICE often will be assigned to several
objects (e.g. to several consecutive VEHICLE JOURNEYs).
Moreover, the validity of a NOTICE, for instance on a JOURNEY PATTERN or a COMMON SECTION, may
be restricted from a POINT IN JOURNEY PATTERN, or to another POINT IN JOURNEY PATTERN.
The entity NOTICE ASSIGNMENT (see EN 12896-1, Public transport - Reference data model - Part 1:
Common concepts) describes these spatial or operational assignments. Only the most frequent
assignments are represented in the model. Other may be added using the same construction.
A NOTICE ASSIGNMENT may be subject to various other conditions of validity (such as DAY TYPE, TIME
BAND), represented by VALIDITY CONDITIONs.
A NOTICE has a different meaning than a DESTINATION DISPLAY (see EN 12896-2, Public transport -
Reference data model - Part 2: Public transport network topology). The first is designed to specify some
characteristics of a journey or a journey pattern which are likely to evolve. They are in most cases printed
in leaflets but may also be queried by dynamic trip planning tools. A DESTINATION DISPLAY corresponds
to stable information attached to a JOURNEY PATTERN, for instance the destination announcement
displayed on bus head signs
Figure 5 — Vehicle Journey Notice Assignment – VIEW
5.3.2 Service journey
5.3.2.1 Service journey – Conceptual model
A SERVICE JOURNEY is a VEHICLE JOURNEY on which passengers will be allowed to board or alight from
vehicles at stops. There are several different possible ways to define SERVICE JOURNEYs, in particular
the two following:
— as the service between an origin and a destination, as advertised to the public;
— as the longest service during which a passenger is allowed to stay on the same vehicle.
Figure 6 — Basic Service Journey MODEL
In addition to the distinction between SERVICE JOURNEYs and DEAD RUNs, operators may wish to
classify VEHICLE JOURNEYs by further criteria. For these purposes a TYPE OF SERVICE may be assigned
to a VEHICLE JOURNEY, which would express other common properties (e.g. “journey at the maximum
load period”).
A default VEHICLE TYPE (see EN 12896-1, Public transport - Reference data model - Part 1: Common
concepts) may be proposed for a journey, chosen according to the time of day at which a SERVICE
JOURNEY takes place, and the ROUTE and JOURNEY PATTERN (see EN 12896-2, Public transport -
Reference data model - Part 2: Public transport network topology) it covers. The proposed VEHICLE TYPE
preferably will be taken into account by the scheduling algorithm used to compile blocks of vehicle
operation. The choice of such a preference may take into account a ranked list of VEHICLE TYPEs for each
SERVICE JOURNEY PATTERN. This is described by the class VEHICLE TYPE PREFERENCE, depending on
a particular SERVICE JOURNEY PATTERN, for which a priority ‘rank’ is given for each VEHICLE TYPE, for
each DAY TYPE and TIME DEMAND TYPE.
SERVICE JOURNEY INTERCHANGE (the scheduled possibility for transfer of passengers between two
SERVICE JOURNEYs at the same or different SCHEDULED STOP POINTs) occurring on the SERVICE
JOURNEY and facilities (grouped in a SERVICE FACILITY SET) available for the SERVICE JOURNEY, are
also important related information, especially when advertising to the public.
Figure 7 — Service Journey MODEL
5.3.2.2 Special services
Most public transport services are operated in a classical way, on a LINE grouping two or more SERVICE
JOURNEY PATTERNs, along which passengers may board or alight at fixed stop points, paying fares
according to the fare system in use. However, some other types of service may be offered (school services,
occasional services, demand-responsive services, etc.). They are usually named “special” services.
The differences between classical services and special services may refer to several different aspects, the
most important being that the access rights to SPECIAL SERVICEs may differ from the others. Besides
occasional services for which the usual fare system applies (e.g. a football match), there are other services
using a different system: special fares, access restricted to certain population groups (e.g. students from
a particular school), etc. In some cases, the service is not directly ordered by the authority in charge of
the classical services, but by another authority or by a particular client (which for instance books a bus
for a trip or an entire day). Special services are generally not planned in a schedule designed for a DAY
TYPE, though it may be the case for very regular services (e.g. school service planned between two
SERVICE JOURNEYs). More often, they are added to the production plan for each particular operating day,
according to the requirements for that day. The mission for a special service is usually not described using
classical ROUTEs and JOURNEY PATTERNs. Regular special services may have only a rough indication of
their origin and destination, which is the case for most occasional services. Some places may play the role
of SCHEDULED STOP POINT for a special service but are not registered as such by the operator, because
no equipment (post or shelter) is installed, etc.
The entity SPECIAL SERVICE describes a service that is not operated in the classical way, i.e. differing
from a VEHICLE JOURNEY by some characteristics. A SPECIAL SERVICE is a regular service planned for a
DAY TYPE. It has as main attributes a ‘start time’ and an ‘end time’.
A SPECIAL SERVICE is characterized by a TYPE OF SERVICE, which allows various distinguishing
categories of services, according to the needs of the user. This classification also allows distinguishing the
DEAD RUNs necessary to perform the sold services. SPECIAL SERVICEs are usually grouped into GROUPs
OF SERVICES, which sometimes may be advertised (e.g. the school services may have a published
number).
The mission corresponding to a special service may be described by a JOURNEY PATTERN, as classical
VEHICLE JOURNEYs. This is the case for some relatively frequent services, using normal SCHEDULED
STOP POINTs (e.g. service for football match). More frequently, they are only described by a ROUTE, often
reduced to an origin and a destination POINTs. However, as these end points shall be TIMING POINTs,
the mission of a SPECIAL SERVICE is described by a simplified JOURNEY PATTERN.
5.3.3 Time demand times
5.3.3.1 Time demand times – Conceptual model
Run times and wait times vary during the day, depending in particular on traffic conditions and on the
number of passengers boarding or alighting from vehicles at stops. A classification of these conditions
into arbitrary levels of demand is defined by the TIME DEMAND TYPE concept (see EN 12896-2, Public
transport - Reference data model - Part 2: Public transport network topology).
The TIME DEMAND TYPEs mainly indicate situations like “peak hour traffic conditions”, “off-peak traffic”,
“night-owl traffic”, etc. In bus operation for instance, the duration of run times usually differs between
these situations. Wait times at stops rather depend on the passenger demand, which also varies with the
time of day, but in a very similar pattern to the traffic conditions on the roads. Therefore, the TIME
DEMAND TYPE serves as an indicator to classify standard run times as well as wait times, depending on
specific conditions.
Each VEHICLE JOURNEY takes place at a defined time which can be characterized by specific traffic
conditions and a certain passenger demand level. To express these characteristics, a TIME DEMAND TYPE
may be assigned to a VEHICLE JOURNEY, to choose easily the appropriate run and wait times.
Figure 8 represents timing information associated with the TIME DEMAND TYPE: RUN TIMEs, WAIT
TIMEs, and a few other timing information like HEADWAY frequency, TURNAROUND TIME LIMIT and
JOURNEY PATTERN LAYOVER.
Figure 8 — Time Demand Times MODEL
A set of DEFAULT RUN TIMEs (for SERVICE JOURNEYs and DEAD RUNs) may be recorded for any TIMING
LINK, one run time corresponding to one TIME DEMAND TYPE. If the TIMING LINK (see EN 12896-2,
Public transport - Reference data model - Part 2: Public transport network topology) is used by several
JOURNEY PATTERNs, the default times may be applied any time it is covered by a VEHICLE JOURNEY,
regardless of the JOURNEY PATTERN.
A more precise control of run times is possible: a JOURNEY PATTERN RUN TIME is a run time for a
TIMING LINK that will be valid only for VEHICLE JOURNEYs made on the specified JOURNEY PATTERN.
It will override the default run times for this TIMING LINK.
JOURNEY PATTERN RUN TIMEs are sets of run times for different TIME DEMAND TYPEs. The TIME
DEMAND TYPE for a particular VEHICLE JOURNEY is used to select the appropriate time from the set
recorded for a particular TIMING LINK belonging to the JOURNEY PATTERN covered.
A JOURNEY PATTERN WAIT TIME may be recorded to define the time a vehicle will have to wait at a
specified TIMING POINT, e.g. to allow a large number of passengers to board or alight, or to wait for a
connecting vehicle on another LINE. These wait times depend on the JOURNEY PATTERN that the
VEHICLE JOURNEY covers, and on the TIME DEMAND TYPE.
JOURNEY PATTERN WAIT TIMEs may occur on DEAD RUNs also, e.g. at a certain TIMING POINT in a
DEAD RUN PATTERN where the driver will be relieved.
A minimum layover time may be defined separately at the end of each JOURNEY PATTERN. This will be
stored in the JOURNEY PATTERN LAYOVER entity, depending on a TIME DEMAND TYPE.
A turnaround time is the time taken by a vehicle to proceed from the end of a ROUTE to the start of
another. The TURNAROUND TIME LIMIT is dependent on a TIME DEMAND TYPE and is stored against a
pair of TIMING POINTs.
The VEHICLE TYPE PREFERENCE, depending on a particular SERVICE JOURNEY PATTERN, defines a
priority ‘rank’ given for each VEHICLE TYPE, for each DAY TYPE and TIME DEMAND TYPE.
Lastly, HEADWAY JOURNEY GROUP (see 5.3.4.1.4 and 5.3.6) and JOURNEY PATTERN HEADWAY, used to
define services based on headway frequencies (defined in 5.3.5), are both potentially dependent on TIME
DEMAND TYPE.
5.3.4 Journey timing
5.3.4.1 Journey timing – Conceptual model
5.3.4.1.1 General
The JOURNEY TIMING model defines common properties for timing elements that can be specialized in
the VEHICLE JOURNEY and JOURNEY PATTERN timing models.
A JOURNEY TIMING provides an abstract type for a number of different specialized types of timing
information:
— JOURNEY LAYOVER;
— JOURNEY WAIT TIME;
— JOURNEY HEADWAY;
— JOURNEY RUN TIME;
— TURNAROUND TIME LIMIT;
— DEFAULT DEAD RUN RUN TIME;
— DEFAULT SERVICE JOURNEY RUN TIME.
Figure 9 — Journey Timing MODEL
5.3.4.1.2 Layover times
LAYOVER TIMEs describe a certain time allowance that may be given at the end of each VEHICLE
JOURNEY, before starting the next one, to compensate for delays or for other purposes (e.g. rest time for
the driver). This “layover time” can be regarded as a buffer time, which may or may not be consumed in
real time operation.
A minimum layover time may be defined separately at the end of each JOURNEY PATTERN. This will be
stored in the JOURNEY PATTERN LAYOVER entity, depending on a TIME DEMAND TYPE.
Such standard layover times may be superseded by a layover time defined for a specific VEHICLE
JOURNEY.
5.3.4.1.3 Wait times
A JOURNEY PATTERN WAIT TIME may be recorded to define the time a vehicle will have to wait at a
specified TIMING POINT, e.g. to allow a large number of passengers to board or alight, or to wait for a
connecting vehicle on another LINE. These wait times depend on the JOURNEY PATTERN that the
VEHICLE JOURNEY covers, and on the TIME DEMAND TYPE.
JOURNEY PATTERN WAIT TIMEs may occur on DEAD RUNs also, e.g. at a certain TIMING POINT in a
DEAD RUN PATTERN where the driver will be relieved.
A VEHICLE JOURNEY WAIT TIME, if it exists, overrides any JOURNEY PATTERN WAIT TIMEs that may
have been stored for the TIMING POINT in question.
5.3.4.1.4 Headway times
Headway frequency information that is available for a VEHICLE JOURNEY supersedes the JOURNEY
PATTERN HEADWAY. It has to be understood as the time interval between the previous and the next
VEHICLE JOURNEY. This information shall be consistent with HEADWAY JOURNEY GROUP if available
(HEADWAY JOURNEY GROUP being a more detailed way of describing headway services).
5.3.4.1.5 Default run times
For any TIMING LINK, run times corresponding to one TIME DEMAND TYPE may be recorded. In some
cases, such run times are default run times and if the TIMING LINK is used by several JOURNEY
PATTERNs, the default times may be applied any time it is covered by a VEHICLE JOURNEY, regardless
the JOURNEY PATTERN.
5.3.4.1.6 Journey run times
A precise control of run times is possible by using the JOURNEY RUN TIME. It defines a run time for a
TIMING LINK that will be valid only on a specific VEHICLE JOURNEY or for VEHICLE JOURNEYs on a
specific JOURNEY PATTERN. It overrides the default run times for this TIMING LINK.
A VEHICLE JOURNEY RUN TIME is specific to one VEHICLE JOURNEY and applies to a particular TIMING
LINK. If it exists, it overrides any run time that may have been stored for the TIMING LINK in question.
5.3.4.1.7 Turnaround times
Another constraint to be taken into account in fixing layover times may be a maximal or minimal
turnaround time. A turnaround time is the time taken by a vehicle to proceed from the end of a ROUTE to
the start of another. There are some limitations for turnaround times, which are used as parameters by
scheduling systems for the vehicle scheduling procedure.
The TURNAROUND TIME LIMIT is dependent on a TIME DEMAND TYPE and is stored against a pair of
TIMING POINTs. These points represent a TIMING POINT where a vehicle may end a SERVICE JOURNEY
and a TIMING POINT where a subsequent SERVICE JOURNEY may start from. The duration of a DEAD
RUN (relating the two TIMING POINTs) possibly scheduled between these two SERVICE JOURNEYs is
included in the turnaround time.
5.3.4.1.8 Times for dead runs
The path to proceed from the end point of a SERVICE JOURNEY to the start point of the following is
normally described by a DEAD RUN PATTERN. However, it is often not worth modelling explicitly a short
movement as a DEAD RUN, covering an explicit DEAD RUN PATTERN. In such a case, a ‘minimum
duration’ may be stored in the TURNAROUND TIME LIMIT, as the minimum time needed by a vehicle to
cover this short path. This minimum duration will of course be superseded by the run times (plus wait
times, if any) associated with an explicitly modelled DEAD RUN between the two TIMING POINTs
concerned.
In the case of a SERVICE JOURNEY, there are SCHEDULED STOP POINTs in the JOURNEY PATTERN where
passengers can board or alight from the vehicle. Therefore, run times probably will be different if a vehicle
crosses a TIMING LINK during a SERVICE JOURNEY or a DEAD RUN. Default run times are hence recorded
in two different entities: DEFAULT SERVICE JOURNEY RUN TIME and DEFAULT DEAD RUN RUN TIME.
Using these default run times, the timing information for each VEHICLE JOURNEY can be derived by
looking for the TIMING POINTs in the associated JOURNEY PATTERN, accessing the TIMING LINKs
between these TIMING POINTs and choosing the appropriate run time. These times will be found, for
each TIMING LINK, in the DEFAULT SERVICE JOURNEY RUN TIME or DEFAULT DEAD RUN RUN TIME
entity, according to the type of journey.
The choice among the run times recorded for one TIMING LINK is determined by the TIME DEMAND
TYPE which has been assigned to the VEHICLE JOURNEY.
5.3.5 Journey pattern times
5.3.5.1 Journey pattern times – Conceptual model
5.3.5.1.1 Journey pattern run times
A more precise control of run times is possible by using JOURNEY PATTERN RUN TIMEs instead of the
default times at TIMING LINK level. A JOURNEY PATTERN RUN TIME is a run time for a TIMING LINK that
will be valid only for VEHICLE JOURNEYs made on the specified JOURNEY PATTERN. It overrides the
default run times that might have been defined for this TIMING LINK.
JOURNEY PATTERN RUN TIMEs are sets of run times for different TIME DEMAND TYPEs. The TIME
DEMAND TYPE for a particular VEHICLE JOURNEY is used to select the appropriate time from the set
recorded for a particular TIMING LINK belonging to the JOURNEY PATTERN covered.
NOTE JOURNEY PATTERN RUN TIME can be superseded by a VEHICLE JOURNEY RUN TIME.
5.3.5.1.2 Layover times
A certain time allowance may be given at the end of each VEHICLE JOURNEY, before starting the next one,
to compensate delays or for other purposes (e.g. rest time for the driver). This “layover time” can be
regarded as a buffer time on a specified JOURNEY PATTERN for the different TIME DEMAND TYPEs. This
layover may be superseded by a specific VEHICLE JOURNEY LAYOVER.
5.3.5.1.3 Frequency-based services
In the case of frequency-based services, another type of information is needed, namely headway duration
information. It is given by JOURNEY PATTERN HEADWAY that is available for all the VEHICLE JOURNEYs
running on the JOURNEY PATTERN at the TIMING POINTs IN JOURNEY PATTERN depending upon the
different TIME DEMAND TYPEs.
5.3.5.1.4 Journey pattern wait times
A JOURNEY PATTERN WAIT TIME may be recorded to define the time a vehicle will have to wait at a
specified TIMING POINT, e.g. to allow a large number of passengers to board or alight, or to wait for a
connecting vehicle on another LINE. These wait times depend on the JOURNEY PATTERN that the
VEHICLE JOURNEY covers, and on the TIME DEMAND TYPE. This wait time can be superseded by a
VEHICLE JOURNEY WAIT TIME (described in 5.3.6).
The JOURNEY PATTERN WAIT TIME represents the time a vehicle has to wait at a specific TIMING POINT
IN JOURNEY PATTERN, for a specified TIME DEMAND TYPE.
5.3.5.1.5 Vehicle type preference
The VEHICLE TYPE PREFERENCE represents a default VEHICLE TYPE proposed for the journeys,
depending on the JOURNEY PATTERN covered and the TIME DEMAND TYPE. It is not a truly temporal
concept but has to be understood as a proposal to be taken into account for BLOCK compilation
(described in 5.3.9.2 and 5.6.3.2). It may be a ranked list of VEHICLE TYPEs for each SERVICE JOURNEY
PATTERN and for each DAY TYPE and TIME DEMAND TYPE.
5.3.5.1.6 Operational context dependency
Figure 10 provides a reminder that all this timing information is to be considered in a specific
OPERATIONAL CONTEXT, that expresses the characterization of a set of operational objects, such as
timing or links determined either by a DEPARTMENT or by an ORGANISATIONAL UNIT (see EN 12896-2,
Public transport - Reference data model - Part 2: Public transport network topology).
Figure 10 — Journey Pattern Times MODEL
5.3.6 Vehicle journey times
5.3.6.1 Vehicle journey times – Conceptual model
5.3.6.1.1 Requirements for exceptions
There may be reasons for needing a more precise control of run and wait times than it is possible using
the standard times at JOURNEY PATTERN level. Some exception times may be required for a single
VEHICLE JOURNEY. For instance, a vehicle may be slowed intentionally on a particular VEHICLE JOURNEY
to meet a scheduled interchange. Some companies adjust the times (e.g. wait times, but even run times)
to cope with driver scheduling regulations. In the case of a very long VEHICLE JOURNEY, e.g. in a rural
area, a single TIME DEMAND TYPE may not apply to the whole journey, because traffic conditions change
substantially between its start and end.
It is hence necessary to be able to override the standard times by times for a specific VEHICLE JOURNEY.
5.3.6.1.2 Journey timing overview
A number of specializations of JOURNEY TIMING are used to provide VEHICLE JOURNEY:
— VEHICLE JOURNEY RUN TIME is the time taken to traverse a specified TIMING LINK IN JOURNEY
PATTERN on a specified VEHICLE JOURNEY. This gives the most detailed control over times and
overrides the DEFAULT SERVICE JOURNEY RUN TIME, the JOURNEY PATTERN RUN TIME and the
...