EN 12896-3:2016
(Main)Public transport - Reference data model - Part 3: Timing information and vehicle scheduling
Public transport - Reference data model - Part 3: Timing information and vehicle scheduling
1.1 General Scope of the Standard
The main objective of the present standard is to present the Reference Data Model for Public Transport, based on:
- the Reference Data Model, EN12896, known as Transmodel V5.1,
- CEN EN 28701, known as IFOPT,
incorporating the requirements of
- EN 15531-1 to -3 and TS 15531-4 and -5: Service interface for real-time information relating to public transport operations (SIRI),
- TS 16614-1 and 2: Network and Timetable Exchange (NeTEx), in particular, the specific needs for long distance train operation.
A particular attention is drawn to the data model structure and methodology:
- the data model is described in a modular form in order to facilitate the understanding and the use of the model,
- the data model is entirely described in UML.
In particular, a Reference Data Model kernel is described, referring to the data domain:
- Network Description: routes, lines, journey patterns, timing patterns, service patterns, scheduled stop points and stop places.
This part corresponds to the Transmodel V5.1 Network Description extended by the IFOPT relevant parts.
Furthermore, the following functional domains are considered:
- Timing Information and Vehicle Scheduling (runtimes, vehicle journeys, day type-related vehicle schedules)
- Passenger Information (planned and real-time)
- Fare Management (fare structure, sales, validation, control)
- Operations Monitoring and Control: operating day-related data, vehicle follow-up , control actions
- Management Information and Statistics (including data dedicated to service performance indicators).
- Driver Management:
- Driver Scheduling (day-type related driver schedules),
- Rostering (ordering of driver duties into sequences according to some chosen methods),
- Driving Personnel Disposition (assignment of logical drivers to physical drivers and recording of driver performance).
The data modules dedicated to cover most functions of the above domains will be specified.
Several concepts are shared by the different functional domains. This data domain is called “Common Concepts”.
1.2 Functional Domain Description
The different functional domains taken into account in the present standard and of which the data have been represented as the reference data model are described in “Public Transport Reference Data Model - Part 1: Common Concepts”.
They are:
- Public Transport Network and Stop Description
- Timing Information and Vehicle scheduling
- Passenger information
- Fare Management
- Operations monitoring and control
- Management information
- Personnel Management: Driver Scheduling, Rostering, Personnel Disposition.
The aspects of multi-modal operation and multiple operators’ environment are also taken into account.
1.3 Particular Scope of this Document
The present European Standard entitled “Reference Data Model for Public Transport – Part 3: Timing Information and Vehicle Scheduling”. incorporates
- 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.
- 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 days types. It constitutes the main part of the Vehicle Scheduling Data Domain.
- Vehicle Journey Assignment Model: describes operational assignments (advertised vehicle labels, stopping positions) related to particular vehicle journeys.
This document itself is composed of the following parts:
- Main document (normative) representing the data model,
(...)
Ö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
Inteligentni transportni sistemi - Referenčni podatkovni model - 3. del: Časovne informacije in razporejanje vozil
1.1 Splošno področje uporabe standarda
Glavni cilj trenutnega standarda je predstavitev referenčnega podatkovnega modela za javni prevoz na podlagi:
– referenčnega podatkovnega modela, standard EN12896, poznan kot Transmodel različice 5.1,
– standarda CEN EN 28701, poznan kot IFOPT,
vsebuje zahteve
-– standardov od EN 15531-1 do -3 ter TS 15531-4 in -5: Vmesnik za informiranje v realnem času za potrebe delovanja javnega prevoza (SIRI),
– TS 16614-1 in 2: Izmenjava omrežnih in voznorednih podatkov (NeTEx), predvsem specifične potrebe za obratovanje vlaka med kraji.
Posebna pozornost je namenjena strukturi podatkovnega modela in metodologiji:
– podatkovni model je opisan v modularni obliki za lažje razumevanje in uporabo modela
– podatkovni model je v celoti opisan v UML.
Opisano je zlasti jedro referenčnega podatkovnega modela, ki se nanaša na podatkovno domeno:
– Opis omrežja: poti, linije, vzorci potovanj, časi potovanj, storitveni vzorci in načrtovana postajališča.
Ta del ustreza opisu omrežja v Transmodelu različice 5.1 in je razširjen z relevantnimi deli IFOPT.
Poleg tega so obravnavane naslednje funkcionalne domene:
– Časovni razpored in razpored vozil (vozni časi, poti vozil, dnevni razporedi vozil)
– Informacije o potnikih (načrtovane in v realnem času)
– Upravljanje voznin (struktura voznin, prodaja, preverjanje, nadzor)
– Vodenje in nadzor: dnevni podatki o obratovanju, spremljanje vozil, nadzorni ukrepi
– Informacije o upravljanju in statistika (vključno s podatki, namenjenimi kazalcem uspešnosti storitev).
– Upravljanje voznikov:
– Razpored voznikov (dnevni razporedi voznikov),
– Urniki (razporejanje dolžnosti voznikov v zaporedje glede na nekatere izbrane metode),
– Razporejanje voznega osebja (dodelitev logičnih voznikov fizičnim voznikom in beleženje storilnosti voznika).
Določeni bodo podatkovni modeli, ki bodo zajemali večino funkcij iz zgornjih domen.
Različne funkcionalne domene imajo skupnih več konceptov. Ta podatkovna domena se imenuje »Skupni koncepti«.
1.2 Opis funkcionalne domene
Različne funkcionalne domene, ki so upoštevane v trenutnem standardu in katerih podatki so predstavljeni kot referenčni podatkovni model, so opisane v Referenčnem podatkovnem modelu javnega prevoza – 1.del: Skupni koncepti.
To so:
– Opis omrežja javnega prevoza in postajališč
– Časovni razpored in razpored vozil
– Informacije o potnikih
– Upravljanje voznin
– Vodenje in nadzor
– Informacije o upravljanju
– Upravljanje osebja: razpored voznikov, urniki, razporejanje osebja.
Upoštevani so tudi vidiki multimodalnosti in okolja z večkratnimi operatorji.
1.3 Posebno področje uporabe tega dokumenta
Trenutni evropski standard »Referenčni podatkovni model za javni prevoz – 3. del: Časovni razpored in razpored vozil.« vključuje
– Model potovanj in časov potovanj: opisuje časovne informacije na ravni potovanj vozil, npr. načrtovane časovne razporede za vozila na dnevni ravni.
– Model potovanj z datumi: opisuje povezavo časovnega razporeda za posamezni obratovalni dan in dnevne časovne razporede,
– Model časov prehodov: opisuje vse različne vrste časov prehodov za dnevne informacije,
– Model storitev vozil: opisuje informacije, povezane z delom vozil, kot je načrtovano za posamezne dneve. Ta model je glavni del podatkovne domene razporeda vozil.
– Model dodelitve potovanja vozil: opisuje operativne dodelitve (oglaševane oznake vozil, postajališča), povezane s potovanji določenega vozila.
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
01-januar-2017
1DGRPHãþD
SIST EN 12896:2006
,QWHOLJHQWQLWUDQVSRUWQLVLVWHPL5HIHUHQþQLSRGDWNRYQLPRGHOGHO ýDVRYQH
LQIRUPDFLMHLQUD]SRUHMDQMHYR]LO
Intelligent transport systems - Reference data model - Part 3: Timing information and
vehicle scheduling
Öffentlicher Verkehr - Datenreferenzmodell - Teil 3: Taktinformationen und
Fahrzeugdisposition
Télématique du transport routier et de la circulation - Modèle de données de référence -
Partie 3 : Informations horaires et horaires des véhicules
Ta slovenski standard je istoveten z: EN 12896-3:2016
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.
EN 12896-3
EUROPEAN STANDARD
NORME EUROPÉENNE
September 2016
EUROPÄISCHE NORM
ICS 35.240.60 Supersedes EN 12896:2006
English Version
Public transport - Reference data model - Part 3: Timing
information and vehicle scheduling
Télématique du transport routier et de la circulation - Öffentlicher Verkehr - Datenreferenzmodell - Teil 3:
Modèle de données de référence - Partie 3 : Taktinformationen und Fahrzeugdisposition
Informations horaires et horaires des véhicules
This European Standard was approved by CEN on 5 May 2016.
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. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists 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, 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
© 2016 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 12896-3:2016 E
worldwide for CEN national Members.
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
1.1 General scope of the Standard . 5
1.2 Functional domain description . 6
1.3 Particular scope of this document . 6
2 Normative references . 7
3 Terms and definitions . 7
4 Symbols and abbreviations . 7
5 Timing information and vehicle scheduling data domain . 7
5.1 Introduction . 7
5.2 Overview . 8
5.2.1 Model and document structure . 8
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 . 21
5.3.7 Interchange . 25
5.3.8 Interchange rule . 28
5.3.9 Coupled journey . 29
5.3.10 Flexible service . 36
5.3.11 Journey accounting . 38
5.4 Dated journey – Conceptual model . 39
5.5 Passing times . 40
5.5.1 Passing times . 40
5.6 Vehicle scheduling . 42
5.6.1 Tactical resource planning . 42
5.6.2 Resources for tactical planning . 43
5.6.3 Vehicle service . 43
5.7 Vehicle journey assignments . 49
5.7.1 Train component label assignment . 49
5.7.2 Stopping position assignment . 50
5.8 Explicit frames. 52
5.8.1 Timetable frame . 52
5.8.2 Vehicle schedule frame . 52
Bibliography . 85
European foreword
This document (EN 12896-3:2016) has been prepared by Technical Committee CEN/TC 278
“Transmodel”, the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by March 2017, and conflicting national standards shall
be withdrawn at the latest by March 2017.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document together with documents EN 12896-1:2016 and EN 12896-2:2016 supersedes
EN 12896:2006.
The series composed of the following documents:
Public transport - Reference data model - Part 1: Common concepts
Public transport - Reference data model - Part 2: Public transport network
Public transport - Reference data model - Part 3: Timing information and vehicle scheduling
Public transport - Reference data model - Part 4: Operations monitoring and control
Public transport - Reference data model - Part 5: Fare management
Public transport - Reference data model - Part 6: Passenger information
Public transport - Reference data model - Part 7: Driver management
Public transport - Reference data model - Part 8: Management information and statistics
Together these create version 6 of the European Standard EN 12896, known as “Transmodel” and thus
replace Transmodel V5.1.
The split into several documents intends to ease the task of users interested in particular functional
domains. Modularisation of Transmodel, undertaken within the NeTEx project, has contributed
significantly to this new edition of Transmodel.
In addition to the eight Parts of this European Standard, an informative Technical Report (Public
transport – Reference data model – Informative documentation) is also being prepared to provide
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 all the eight parts are
completed.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: 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
EN 12896-3 presents the following items:
— rationale for the Transmodel Standard;
— use of the Transmodel Standard;
— applicability of the Transmodel Standard;
— conformance statement;
— Transmodel origins;
— reference to the previous version and other documents.
The data structures represented in EN 12896-1 are generic patterns that are referenced by different
other parts.
EN 12896-2 presents space-related data structures.
This European Standard presents time-related data structures and replaces the sections of
EN 12896:2006 referring to the time-related tactical planning components and to vehicle scheduling.
1 Scope
1.1 General scope of the Standard
The main objective of the present standard is to present the reference data model for public transport,
based on:
— the reference data model, EN 12896, known as Transmodel V5.1;
— EN 28701, known as IFOPT;
incorporating the requirements of:
— EN 15531-1 to −3 and CEN/TS 15531-4 and CEN/TS 15531-5, Service interface for real-time
information relating to public transport operations (SIRI);
— CEN/TS 16614-1 and CEN/TS 16614-2, Network and Timetable Exchange (NeTEx), in particular,
the specific needs for long distance train operation.
A particular attention is drawn to the data model structure and methodology:
— the data model is described in a modular form in order to facilitate the understanding and the use
of the model;
— the data model is entirely described in UML.
In particular, a Reference Data Model kernel is described, referring to the data domain:
— network description: routes, lines, journey patterns, timing patterns, service patterns, scheduled
stop points and stop places.
This part corresponds to the Transmodel V5.1 network description extended by the IFOPT relevant
parts.
Furthermore, the following functional domains are considered:
— timing information and vehicle scheduling (runtimes, vehicle journeys, day type-related vehicle
schedules);
— passenger information (planned and real-time);
— fare management (fare structure, sales, validation, control);
— operations monitoring and control: operating day-related data, vehicle follow-up, control actions;
— management information and statistics (including data dedicated to service performance
indicators);
— driver management:
— driver scheduling (day-type related driver schedules);
— rostering (ordering of driver duties into sequences according to some chosen methods);
— driving personnel disposition (assignment of logical drivers to physical drivers and recording
of driver performance).
The data modules dedicated to cover most functions of the above domains will be specified.
Several concepts are shared by the different functional domains. This data domain is called “common
concepts”.
1.2 Functional domain description
The different functional domains taken into account in the present standard and of which the data have
been represented as the reference data model are described in “Public transport reference data model -
part 1: Common concepts”.
They are:
— public transport network and stop description;
— timing information and vehicle scheduling;
— passenger information;
— fare management;
— operations monitoring and control;
— management information;
— personnel management: driver scheduling, rostering, personnel disposition.
The aspects of multi-modal operation and multiple operators’ environment are also taken into account.
1.3 Particular scope of this document
The present European Standard entitled “Reference data model for public transport – Part 3: Timing
information and vehicle scheduling” incorporates:
— 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;
— 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 days
types. it constitutes the main part of the vehicle scheduling data domain;
— vehicle journey assignment model: describes operational assignments (advertised vehicle labels,
stopping positions) related to particular vehicle journeys.
This document itself is composed of the following parts:
— main document (normative) representing the data model;
— Annex A (normative), containing the data dictionary and attributes tables, i.e. the list of all the
concepts present in the main document together with the definitions;
— Annex B (informative), indicating the data model evolutions.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
EN 12896-1:2016, Public transport - Reference data model - Part 1: Common concepts
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 12896-1:2016 apply.
4 Symbols and abbreviations
AVM Automated vehicle monitoring
AVMS Automated vehicle management system
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
SIRI Service interface for real-time information
UML Unified modelling language
URI Uniform resource identifier
URL Universal resource locator
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
5.2.1 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 days
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 defined
movement of a 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 (cf.
[7]), a VEHICLE JOURNEY is a class of journeys that would take place at the same time on each day of a
specific DAY TYPE.
5.3.1.1.2 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 (cf. [7]) at
which it was parked to the first SCHEDULED STOP POINT of the JOURNEY PATTERN (cf. [8]) 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 (cf.
[8]) to another one in order to continue its service there, or for various other reasons.
class TI JT Vehicle Journey Basic MODEL
Name: TI JT Vehicle Journey Basic MODEL
Author: Transmodel
Version: 1.0
JOURNEY
Created: 05/02/2014 11:25:26
Updated: 03/09/2014 13:30:15 + Description [0.1]
+ TransportMode [0.1]
CC Service
+ TransportSubmode [0.1]
Calendar MODEL::
+ Monitored [0.1]
DAY TYPE
+for
«UID»
1.*
+ Id
+worked on *
LINK SEQUENCE
VEHICLE JOURNEY
+for +made using
NT Journey Pattern
+ DepartureTime [0.1]
MODEL::JOURNEY
1 *
+ JourneyDuration [0.1]
PATTERN
«UID»
+ Id
0.1
+by default
timed from
+timed from 0.*
+the timing
+the timing
0.1
reference for
reference for 1
POINT IN LINK SEQUENCE
NT Journey Pattern MODEL:: DEAD RUN
TIMING POINT IN JOURNEY
TI Service
+ DirectionType [0.1]
PATTERN
Journey MODEL::
+ DeadRunType [0.1]
SERVICE
«UID»
+a view of *
JOURNEY
+ Id
+viewed as 1
POINT
NT Timing Pattern
MODEL::TIMING
POINT
Figure 1 — Vehicle journey – Basic conceptual model (UML)
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 2.
These include interactions with other journeys (JOURNEY PART, JOURNEY MEETING, etc.); temporal
and other conditions (DAY TYPE, VALIDITY CONDITION, cf. [7]); 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.
class TI JT Vehicle Journey MODEL
CC Generic Accessibility
+including 0.* +part of 0.*
LINK SEQUENCE
+by default
MODEL::ACCESSIBILITY
POINT IN LINK SEQUENCE
1 timed from NT Journey Pattern MODEL::JOURNEY PATTERN
ASSESSMENT +determining
CC Generic Validity
NT Journey Pattern MODEL::
MODEL::VALIDITY
TIMING POINT IN JOURNEY +the timing
0.1 0.* 0.*
CONDITION
PATTERN reference for
+determined
+characterised +characterising 0.1
+for 1 0.*
by
by
+the timing reference for 0.1
+applicable for 0.*
0.*
+characterising
+characterised by 0.1
CC Transport
JOURNEY +characterised by
0.1
Organisations
+ Description [0.1]
MODEL::
CC Service Calendar
+ TransportMode [0.1]
OPERATIONAL +the classification for
MODEL::DAY TYPE
CONTEXT + TransportSubmode [0.1]
+for
+ Monitored [0.1] * +classified as 0.1 TYPE OF SERVICE
«UID»
+characterising 0.1
1.*
«UID»
+ Id
+for 1.* +timed
+made
+ Id
+worked
from
* using +characterised by
0.* 0.* 0.*
on *
+classified as
+worked on *
VEHICLE JOURNEY
+including +in
TI Vehicle Service + DepartureTime [0.1]
0.1
MODEL::BLOCK 0.1 *
+ JourneyDuration [0.1]
TYPE OF PRODUCT
+subdivided in +a classification for
«UID» CATEGORY
+ Id
«UID»
0.* +identified by
+ Id
+part
of
TI Coupled Journey
*
MODEL::JOURNEY
+identifying
TEMPLATE VEHICLE
PART
0.*
JOURNEY
+identified by 0.1
TRAIN NUMBER
0.* +identifying
«UID»
+made using 0.1
+ Id
+ ForAdvertisement [0.1]
DEAD RUN
TI Service Journey
+ ForProduction [0.1]
MODEL::SERVICE
+ DirectionType [0.1]
+ Description [0.1]
JOURNEY
+ DeadRunType [0.1]
+for 0.*
«UID»
+ Id «UID»
FACILITY SET
+ Id
0.1
CC Facility MODEL: Name: TI JT Vehicle Journey MODEL
:SERVICE FACILITY Author: Transmodel
+for
Version: 1.0
SET
+made using
Created: 05/02/2014 11:25:26
0.*
+comprising Updated: 21/09/2014 09:33:30
0.1
TI Service Journey
+part of 1.*
MODEL::TEMPLATE
SERVICE JOURNEY
CC Facility
MODEL::
FACILITY
Figure 2 — Vehicle journey – conceptual model (UML)
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 (cf. [7]). describes such remarks. It may concern a whole LINE, or a GROUP OF
POINTS, e.g. one or several STOP AREAs.
More frequently, a NOTICE will be assigned to a JOURNEY PATTERN, a COMMON SECTION (cf. [8]), 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 (cf. [8]) 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 (cf. [8]). 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 headsigns.
class TI JT Vehicle Journey Notice Assignment MODEL
Name: TI JT Vehicle Journey Notice Assignment MODEL
POINT IN LINK SEQUENCE
Author: Transmodel
LINK SEQUENCE NT Journey Pattern MODEL::
Version: 1.0
+made up of
+on POINT IN JOURNEY
NT Journey Pattern MODEL::
Created: 17/02/2014 18:30:19
PATTERN
JOURNEY PATTERN
Updated: 03/09/2014 13:35:40
1 1.*
+part of 0.*
+including 0.*
+used to +for +marked
1.* 1
0.1
0.1
define by +end 0.1 +start of
CC Generic Validity
of MODEL::VALIDITY
+applicable for
CONDITION
+defined
0.*
for
* +made using
+assigned
+applicable for *
+from
to *
* +to * *
JOURNEY
TI Vehicle Journey MODEL::
0.1
+assigned to NT Notice Assignment MODEL::NOTICE
VEHICLE JOURNEY
ASSIGNMENT +defined for *
*
+marked by
+ DepartureTime [0.1]
+assigned by +marked by
+ JourneyDuration [0.1] TI Interchange
+assigned to
MODEL::
«UID»
0.* 0.1
INTERCHANGE
+ Id
0.*
+assigned * +using *
to
+marked by
+used by 1
TI Service Journey
MODEL::GROUP OF 0.1
CC Notice MODEL::
+a classification for
0.*
SERVICES
CC Notice MODEL::
TYPE OF NOTICE
NOTICE
+classified as 0.1
+marked
+defined 0.1
by
for
NT Common Section MODEL::
+provided as
+providing 0.*
0.*
COMMON SECTION
CC Notice MODEL:: CC Notice MODEL::
0.1
+classiifed as
DELIVERY VARIANT TYPE OF DELIVERY
VARIANT
0.*
+a classification for
Figure 3 — Vehicle journey notice assignment – Conceptual model (UML)
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.
class TI JT Basic Service Journey MODEL
TI Vehicle Journey
TI Vehicle Journey
* +the classification for MODEL::TYPE OF
MODEL::JOURNEY
SERVICE
+classified as
0.1
GROUP OF SERVICES
+made up of
1.*
+in + DirectionType [0.1]
«UID»
0.1
+ Id
SPECIAL SERVICE
+ Client [0.1]
+ DepartureTime [0.1]
*
+ JourneyDuration [0.1]
+included in *
+ Print [0.1]
+made
+using
+ Dynamic [0.1]
+proposed up of
«UID» 0.1
for
LINK SEQUENCE
+ Id
NT Journey Pattern
0.1
CC Vehicle Type MODEL::
TI Vehicle Journey
*
MODEL::JOURNEY
* +for +for
VEHICLE TYPE
+described
MODEL::VEHICLE
PATTERN
by
JOURNEY
+made 1
0.1
using
+for
TI Journey Pattern
+used to
NT Service Pattern
Times MODEL::
*
define
+specified by
MODEL::SERVICE +for
VEHICLE TYPE
JOURNEY PATTERN
PREFERENCE
1 *
+requested for
0.*
+operated by 0.*
+made using 0.1
SERVICE JOURNEY
+proposed for 0.1 +comprising
*
+ ServiceAlteration [0.1]
+ Print [0.1]
+present at
0.*
+ Dynamic [0.1]
+ DirectionType [0.1]
+for FACILITY SET
+made using
«UID» CC Facility MODEL::
0.1 0.*
+ Id SERVICE FACILITY SET
Name: TI JT Basic Service Journey MODEL
+comprising 0.1
0.1
Author: Transmodel
+affected by
Version: 1.0
Created: 27/05/2014 14:00:46
Updated: 03/09/2014 13:52:33
TEMPLATE VEHICLE JOURNEY +part of 1.*
TEMPLATE SERVICE
CC Facility MODEL::
JOURNEY
NT Check Constraint
FACILITY
+limited to +for
+a process for
MODEL::CHECK
«UID»
CONSTRAINT
0.* 0.1
0.*
+ Id
Figure 4 — Service journey – basic conceptual model (UML)
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 (cf. [7]) 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 (cf. [8]) 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.
class TI JT Service Journey MODEL
0.1
GROUP OF SERVICES
1.* +made up of
+in
+the + DirectionType [0.1]
SPECIAL SERVICE
classification
«UID»
TI Vehicle Journey TI Vehicle Journey
* for
+ Id
MODEL::JOURNEY MODEL::TYPE OF + Client [0.1]
SERVICE + DepartureTime [0.1]
0.1
+classified as
+ JourneyDuration [0.1]
+ Print [0.1]
+described by
+ Dynamic [0.1]
* +for 0.1
«UID»
+ Id
LINK SEQUENCE
+made using
+for
+using * NT Journey Pattern
MODEL::JOURNEY
TI Vehicle Journey
* 1
PATTERN
MODEL::VEHICLE
+included in *
Name: TI JT Service Journey MODEL
JOURNEY
Author: Transmodel
+made
Version: 1.0
+proposed for
up of
Created: 30/04/2014 14:23:20
0.1 0.1
Updated: 03/09/2014 13:52:36
+requested for
CC Vehicle Type MODEL::
0.*
VEHICLE TYPE
0.*
+operated by
+made using 0.1
SERVICE JOURNEY
+proposed for
*
+ ServiceAlteration [0.1]
+ Print [0.1]
0.1
+specified by 1
+ Dynamic [0.1]
+comprising
+ DirectionType [0.1]
+made using
«UID»
+ Id 0.1 +for *
1 1 0.1
+affected by TI Journey Pattern
+start of +end of Times MODEL::
+for +present at
0.*
0.*
VEHICLE TYPE
FACILITY SET
PREFERENCE
TEMPLATE VEHICLE JOURNEY
CC Facility MODEL::
TEMPLATE SERVICE
SERVICE FACILITY SET +for *
JOURNEY
+comprising 0.1
«UID»
+ Id
+a process for 0.*
+part of
TI Interchange 1.*
MODEL:: NT Check Constraint
+for
INTERCHANGE MODEL::CHECK CC Facility MODEL::
+limited to
CONSTRAINT FACILITY
0.* 0.1
+from * +to *
+used to define 1
POINT
TI Interchange MODEL:: +from
1 +from 1
TI Interchange MODEL:: +from
SERVICE JOURNEY NT Service NT Service Pattern
SERVICE JOURNEY
* +start of 1
+start of
* MODEL::SERVICE
INTERCHANGE Pattern MODEL: *
PATTERN +start of
+to 1 JOURNEY PATTERN
:SCHEDULED +to
INTERCHANGE
+to
STOP POINT
* 1
+end of *
+end of
* +end of
Figure 5 — Service journey – Conceptual model (UML)
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 a number of 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. pupils 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 a whole 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 (cf. [8]).
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, in order to choose easily the appropriate run and wait
times.
Figure 7 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.
class TI JT Time Demand Times MODEL
Name: TI JT Time Demand Times MODEL
Author: Transmodel CC Service
TI Journey Pattern
+for +used to define
Version: 1.0 Calendar MODEL::
Times MODEL::
Created: 05/02/2014 11:25:26
DAY TYPE
VEHICLE TYPE
* 1
Updated: 03/09/2014 13:50:08
+for PREFERENCE
+for 1.*
*
+worked on
DEFAULT SERVICE *
JOURNEY RUN TIME
JOURNEY
TI Vehicle Journey MODEL::VEHICLE JOURNEY
+ RunTime
«UID»
+associated with
+ Id [0.1]
+made +made using *
*
*
using
*
+associated
TI Journey Pattern +for 1
with
Times MODEL::
LINK SEQUENCE
TURNAROUND TIME
NT Journey Pattern MODEL::
LIMIT
JOURNEY PATTERN
* +used
+associated
by
with +used
default
to
+used to
+worked using +allowing
1 1 1
1 by
define +worked
define
+used to *
using
define +for 0.*
NT Time Demand Type MODEL::TIME
DEMAND TYPE +used to define TI Journey
*
+asociated
TI Journey Timing
Pattern Times
with
0.1
+associated
MODEL::JOURNEY
MODEL::
with
TIMING
JOURNEY
*
+used to
PATTERN
define
HEADWAY
+used to define
DEFAULT DEAD RUN
RUN TIME
+associated 1
* +allowed on *
+associated
with 1
+ RunTime
with
«UID» TI Journey Pattern Times
*
+used to
MODEL::JOURNEY PATTERN
+ Id [0.1]
+used to
define
LAYOVER
define
+associated
*
+used to 1
with
define
+associated with
1 +covered
*
TI Journey Pattern Times
1 +covered in
*
in
MODEL::JOURNEY
TI Journey Pattern Times
PATTERN WAIT TIME
LINK
+associated MODEL::JOURNEY PATTERN
+associated
NT Timing Pattern MODEL::TIMING LINK 1
with RUN TIME
with
*
+assigned to
+covered in
*
Figure 6 —Time demand times – Conceptual model (UML)
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 (cf. [8]) 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 (5.3.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 TIME;
— DEFAULT SERVICE JOURNEY RUN TIME.
class TI JT Journey Timings MODEL
Name: TI JT Journey Timings MODEL
exclusion: either time bands or Author: Transmodel
+determined for time demand types determine
Version: 1.0
NT Time Demand Type
the timing
Created: 05/02/2014 11:25:26
MODEL::TIME
0.*
Updated: 21/09/2014 08:43:45
+determining
0.1 DEMAND TYPE
JOURNEY TIMING
CC Transport
0.1 + Name [0.1]
Organisations
+used to define
0.*
+ VehicleMode [0.1]
MODEL::
CC Service
OPERATIONAL «UID»
Calendar MODEL::
*
+asociated with
0.1
CONTEXT + Iid +associated with
0.1
TIME BAND
*
0.* +characterising +determining +determined by +used to define
JOURNEY LAYOVER JOURNEY WAIT JOURNEY
TI Journey Pattern Times MODEL::
TIME HEADWAY
+ Layover [0.1] TURNAROUND TIME LIMIT
+ WaitTime [0.1]
+ Frequency [0.1]
«UID»
+ MinimumDuration [0.1]
+ Id «UID» «UID»
+ MaximumDuration
+ Id + Id
«UID»
0.*
0.* +timed +for + Id [0.1]
at
* * +to *
+from +defined for
JOURNEY RUN
TIME
+restricted to
0.1
+ RunTime [0.1]
TI Vehicle Journey
TI Vehicle Journey
Times MODEL:: «UID»
NT Route MODEL:
Times MODEL::
VEHICLE JOURNEY
+ Id
:TURN STATION
VEHICLE JOURNEY
LAYOVER
HEADWAY +associated
0.*
with
+passed
TI Vehicle Journey
1 1
1 every
+start of
Times MODEL:: +end of TI Vehicle Journey
+for 1
VEHICLE Times MODEL::
POINT
JOURNEY WAIT
VEHICLE JOURNEY
TIME
N
...
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...