Bsi bs en 12896 3 2016

It splits into: — vehicle journey model; — service journey model; — time demand times model; — journey timing model ; — journey pattern times model; — vehicle journey times model; — inte

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 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”.

Functional domain description

The current standard outlines various functional domains, with the data represented in the reference data model detailed in "Public Transport Reference Data Model - Part 1: Common Concepts."

— public transport network and stop description;

— timing information and vehicle scheduling;

— personnel management: driver scheduling, rostering, personnel disposition

The aspects of multi-modal operation and multiple operators’ environment are also taken into account.

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

This document references essential materials that are crucial for its application For references with specific dates, only the cited edition is applicable In the case of undated references, the most recent edition of the referenced document, including any amendments, is relevant.

EN 12896-1:2016, Public transport - Reference data model - Part 1: Common concepts

For the purposes of this document, the terms and definitions given in EN 12896-1:2016 apply

AVMS Automated vehicle management system

IFOPT Identification of fixed objects in public transport

NeTEx Network and Timetable Exchange

SIRI Service interface for real-time information

5 Timing information and vehicle scheduling data domain

Introduction

The operation of vehicles essential for delivering the advertised service involves both service journeys and dead runs, which are unproductive trips required to reposition vehicles, primarily between the depot and service locations Vehicle journeys are categorized by day types, representing all operating days planned under the same service offer The tactical planning process is structured around these day types within the reference data model, encompassing all necessary entities for schedule development, including various run times, wait times, scheduled interchanges, and turnaround times.

Vehicle scheduling involves grouping vehicle journeys into operational blocks, while driver scheduling focuses on managing driver duties within these blocks The reference data model encompasses the necessary entities and relationships to thoroughly outline the data requirements for these functions, regardless of the specific methods and algorithms used by various software systems.

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:

— 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.

Journey and journey times

Vehicle journey

A VEHICLE JOURNEY refers to the defined movement of a vehicle along a specific JOURNEY PATTERN on a designated ROUTE, occurring between the initial and final POINTs of the JOURNEY PATTERN Each VEHICLE JOURNEY is categorized by a DAY TYPE, indicating that these journeys occur consistently at the same time on each day of that 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 is required for a vehicle to travel from its PARKING POINT to the first SCHEDULED STOP POINT of its JOURNEY PATTERN, where it begins service Conversely, a DEAD RUN can also occur when returning from the last SCHEDULED STOP POINT to the PARKING POINT after completing service Additionally, DEAD RUNS may happen when a vehicle transitions between different ROUTES to continue its service or for other reasons.

TI Serv ice Journey MODEL::

Name: TI JT Vehicle Journey Basic MODEL Author: Transmodel

NT Journey Pattern MODEL::JOURNEY PATTERN

TIMING POINT IN JOURNEY PATTERN

NT Timing Pattern MODEL::TIMING POINT

CC Serv ice Calendar MODEL::

Figure 1 — Vehicle journey – Basic conceptual model (UML)

5.3.1.1.3 Vehicle journey details – Conceptual model

A vehicle journey encompasses various elements, including interactions with other journeys such as journey parts and journey meetings Additionally, it is influenced by temporal and other conditions, like day type and validity conditions, as referenced in [7] Further descriptive and classification aspects also play a role in defining a vehicle journey.

10 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

Name: TI JT Vehicle Journey MODEL Author: Transmodel

TI Serv ice Journey MODEL::SERVICE JOURNEY

TI Serv ice Journey MODEL::TEMPLATE SERVICE JOURNEY

TYPE OF PRODUCT CATEGORY ôUIDằ

CC Generic Validity MODEL::VALIDITY CONDITION

CC Generic Accessibility MODEL::ACCESSIBILITY ASSESSMENT

Figure 2 — Vehicle journey – conceptual model (UML)

For effective passenger and driver communication, it is beneficial to attach remarks to various components of the supply, such as points, lines, or sections For example, highlighting the use of a shortened journey pattern can be crucial These remarks are typically displayed as footnotes on public timetables at stops, in timetable booklets, or on driver cards for driver information The entity NOTICE describes these remarks, which can pertain to an entire line or a group of points, such as one or more stop areas.

A NOTICE is increasingly linked to a JOURNEY PATTERN, a COMMON SECTION, or a specific VEHICLE JOURNEY Often, the same NOTICE is applied to multiple entities, such as 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 differs from a DESTINATION DISPLAY, as the former specifies evolving characteristics of a journey or journey pattern, typically found in leaflets or accessible through dynamic trip planning tools In contrast, a DESTINATION DISPLAY provides stable information related to a JOURNEY PATTERN, such as the destination announcement shown on bus headsigns.

Name: TI JT Vehicle Journey Notice Assignment MODEL Author: Transmodel

NT Notice Assignment MODEL::NOTICE

DELIVERY VARIANT CC Notice MODEL::

Figure 3 — Vehicle journey notice assignment – Conceptual model (UML)

Service journey

A service journey refers to a vehicle journey that permits passengers to board or alight at designated stops There are various definitions of service journeys, with two primary interpretations being particularly noteworthy.

— 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

12 class TI JT Basic Serv ice Journey MODEL

TI Vehicle Journey MODEL::TYPE OF SERVICE

Name: TI JT Basic Service Journey MODEL Author: Transmodel

TI Journey Pattern Times MODEL::

NT Serv ice Pattern MODEL::SERVICE JOURNEY PATTERN

NT Check Constraint MODEL::CHECK CONSTRAINT

+the classification for +classified as 0 1

Figure 4 — Service journey – basic conceptual model (UML)

Operators can enhance the classification of VEHICLE JOURNEYs by distinguishing between SERVICE JOURNEYs and DEAD RUNs By assigning a TYPE OF SERVICE to each VEHICLE JOURNEY, they can highlight shared characteristics, such as those occurring during peak load periods.

A default vehicle type may be suggested for a journey based on the time of day, route, and journey pattern This proposed vehicle type should be considered by the scheduling algorithm when compiling vehicle operation blocks The selection process may utilize a ranked list of vehicle types tailored to each service journey pattern This is defined by the vehicle type preference class, which assigns a priority rank to each vehicle type according to specific service journey patterns, day types, and time demand types.

The SERVICE JOURNEY INTERCHANGE allows for the scheduled transfer of passengers between two SERVICE JOURNEYs at the same or different SCHEDULED STOP POINTs This interchange, along with the facilities grouped in a SERVICE FACILITY SET available for the SERVICE JOURNEY, is crucial information for public advertising.

TI Vehicle Journey MODEL::TYPE OF SERVICE

Name: TI JT Service Journey MODEL Author: Transmodel

NT Check Constraint MODEL::CHECK

NT Serv ice Pattern MODEL:

+made up of 0 1 +included in *

+the classification for +classified as 0 1

Figure 5 — Service journey – Conceptual model (UML)

Most public transport services operate traditionally along designated routes that connect multiple service journey patterns Passengers can board or alight at fixed stop points and are required to pay fares for their journeys.

The fare system currently in use may vary, but it often includes additional service types such as school services, occasional services, and demand-responsive services, collectively referred to as "special" services.

The key differences between classical services and special services primarily lie in access rights and fare systems Special services may have unique fare structures and restricted access for specific groups, such as students from certain schools Unlike classical services, which are typically ordered by a designated authority, special services can be requested by different authorities or clients for specific needs, such as chartering a bus for a trip These services are often not included in standard schedules but are added to the production plan based on daily requirements Additionally, the routes and journey patterns for special services are usually less defined, often providing only general information about their origin and destination Some locations may serve as scheduled stop points for special services without being officially recognized by the operator due to the absence of necessary infrastructure.

The term SPECIAL SERVICE refers to a unique type of service that operates differently from a traditional VEHICLE JOURNEY, characterized by specific features It is a regular service designed for a particular DAY TYPE, with key attributes including a defined 'start time' and 'end time'.

A SPECIAL SERVICE is defined by its specific TYPE OF SERVICE, enabling the categorization of services based on user needs This classification helps identify the DEAD RUNs required to deliver the offered services Typically, SPECIAL SERVICES are organized into GROUPs OF SERVICES, which may be publicly advertised, such as the published numbers for school services.

A special service mission can be characterized by a JOURNEY PATTERN, similar to classical VEHICLE JOURNEYs, particularly for regular services with standard SCHEDULED STOP POINTs, such as those for football matches More commonly, these services are defined by a ROUTE that typically includes just an origin and a destination POINTs Since these endpoints are also TIMING POINTs, the mission of a SPECIAL SERVICE is represented by a simplified JOURNEY PATTERN.

Time demand times

5.3.3.1TIME DEMAND times – Conceptual model

Run times and wait times fluctuate throughout the day, primarily influenced by traffic conditions and the volume of passengers boarding or alighting at stops These varying conditions are categorized into distinct levels of demand, referred to as the TIME DEMAND TYPE concept.

The TIME DEMAND TYPES categorize traffic conditions such as "peak hour traffic," "off-peak traffic," and "night-owl traffic," which significantly affect bus operation run times These run times vary based on the time of day, while wait times at stops are influenced by passenger demand, mirroring the traffic patterns on the roads Consequently, TIME DEMAND TYPES are essential for classifying standard run and wait times according to specific traffic conditions.

Each vehicle journey occurs at a specific time, influenced by unique traffic conditions and passenger demand levels To effectively capture these characteristics, a time demand type is assigned to each vehicle journey, facilitating the selection of suitable run and wait times.

Figure 7 illustrates the timing information related to the TIME DEMAND TYPE, including RUN TIMES, WAIT TIMES, and additional metrics such as HEADWAY frequency, TURNAROUND TIME LIMIT, and JOURNEY PATTERN LAYOVER This data is essential for understanding the class TI JT Time Demand Times model.

TI Journey Pattern Times MODEL::JOURNEY PATTERN RUN TIME

TI Vehicle Journey MODEL::VEHICLE JOURNEY

TI Journey Pattern Times MODEL::JOURNEY PATTERN WAIT TIME

TI Journey Pattern Times MODEL::JOURNEY PATTERN LAYOVER

NT Timing Pattern MODEL::TIMING LINK

NT Time Demand Type MODEL::TIME DEMAND TYPE

Name: TI JT Time Demand Times MODEL

Figure 6 —Time demand times – Conceptual model (UML)

DEFAULT RUN TIMES for SERVICE JOURNEYs and DEAD RUNs can be recorded for each TIMING LINK, with each run time corresponding to a specific TIME DEMAND TYPE When a TIMING LINK is utilized by multiple JOURNEY PATTERNs, these default times are applicable whenever it is serviced by a VEHICLE JOURNEY, irrespective of the JOURNEY PATTERN in use.

A JOURNEY PATTERN RUN TIME allows for more accurate control of run times, as it applies specifically to TIMING LINKS for VEHICLE JOURNEYs that follow the designated JOURNEY PATTERN.

It will override the default run times for this TIMING LINK

Journey Pattern Run Times consist of various run times categorized by different Time Demand Types Each Time Demand Type associated with a specific vehicle journey helps in selecting the relevant time from the recorded set for a particular Timing Link within the covered Journey Pattern.

A JOURNEY PATTERN WAIT TIME indicates the duration a vehicle must pause at a designated TIMING POINT, such as for passenger boarding or to connect with another LINE These wait times are influenced by the specific JOURNEY PATTERN of the VEHICLE JOURNEY and 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

Turnaround time refers to the duration a vehicle takes to travel from the end of one route to the beginning of another The turnaround time limit is determined by the type of time demand and is recorded for a specific 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.

Journey timing

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:

— DEFAULT SERVICE JOURNEY RUN TIME class TI JT Journey Timings MODEL

TI Vehicle Journey Times MODEL::

TI Time Demand Times MODEL::

DEFAULT DEAD RUN RUN TIME

TI Time Demand Times MODEL::

Name: TI JT Journey Timings MODEL Author: Transmodel

Version: 1.0 Created: 05/02/2014 11:25:26 Updated: 21/09/2014 08:43:45 exclusion: either time bands or time demand types determine the timing

NT Timing Pattern MODEL::TIMING POINT

NT Timing Pattern MODEL::TIMING LINK

+asociated with * +used to define 0 1

Figure 7 — Journey timing – Conceptual model (UML)

Layover times refer to the designated time allowance provided at the conclusion of each vehicle journey before commencing the next one This period serves to accommodate delays or fulfill other needs, such as allowing rest for the driver Essentially, layover time acts as a buffer, which may or may not be utilized during actual operations.

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

Wait times are recorded to indicate how long a vehicle must pause at a specific timing point, such as for passengers to board or alight, or to connect with another vehicle on a different line These wait times are influenced by the journey pattern of the vehicle and the type of time demand Additionally, journey pattern wait times can also occur during dead runs, particularly at designated timing points where a driver may be relieved.

A JOURNEY WAIT TIME may be stored for each individual VEHICLE JOURNEY, at any TIMING POINT IN JOURNEY PATTERN, in the covered JOURNEY PATTERN

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

Headway frequency data for a vehicle journey takes precedence over the journey pattern headway, representing the time interval between consecutive vehicle journeys This information should align with the headway journey group when available, as the headway journey group offers a more detailed description of headway services.

The JOURNEY RUN TIME allows for precise control of run times by establishing a specific duration for a TIMING LINK, applicable only to designated VEHICLE JOURNEYs, thereby overriding the default run times associated with that TIMING LINK.

Journey run times consist of various durations tailored to specific time demand types Each vehicle journey is associated with a particular time demand type, which helps in selecting the correct time from the recorded set for a specific timing link within the corresponding journey pattern.

A vehicle journey run time is unique to each vehicle journey and is applicable to a specific timing link When a vehicle journey run time is present, it takes precedence over any previously stored run time associated with that timing link.

When determining layover times, it is essential to consider the maximum and minimum turnaround times Turnaround time refers to the duration a vehicle takes to travel from the end of one route to the beginning of another Scheduling systems utilize specific limitations on turnaround times as parameters in the vehicle scheduling process.

The TURNAROUND TIME LIMIT is determined by the TIME DEMAND TYPE and is associated with two TIMING POINTs: one where a vehicle concludes a SERVICE JOURNEY and another where a new SERVICE JOURNEY begins The turnaround time also accounts for the duration of a DEAD RUN scheduled between these two TIMING POINTs.

The transition from the end point of a service journey to the start point of the next is typically represented by a dead run pattern However, for short movements, it may not be necessary to model this explicitly Instead, a minimum duration can be recorded in the turnaround time limit, indicating the least time required for a vehicle to traverse this brief distance This minimum duration will be overridden by the run times and any wait times linked to a specifically modeled dead run between the relevant timing points.

In a SERVICE JOURNEY, passengers can board or alight at designated SCHEDULED STOP POINTs along the JOURNEY PATTERN Consequently, run times may vary depending on whether a vehicle is operating on a SERVICE JOURNEY or a DEAD RUN As a result, default run times are documented in two distinct categories: DEFAULT SERVICE JOURNEY RUN TIME and DEFAULT DEAD RUN RUN TIME.

To determine the timing information for each vehicle journey, one must examine the timing points within the corresponding journey pattern By accessing the timing links between these points and selecting the relevant run time, the necessary data can be obtained The appropriate times for each timing link are specified in either the default service journey run time or the default dead run run time entity, depending on the journey type.

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.

Journey pattern times

5.3.5.1 JOURNEY PATTERN TIMES – Conceptual model

For each TIMING LINK, run times associated with a specific TIME DEMAND TYPE can be documented In certain instances, these run times are set as default values When a TIMING LINK is utilized by multiple JOURNEY PATTERNs, the default run times may be applied whenever it is included in a VEHICLE JOURNEY, irrespective of the JOURNEY PATTERN.

For enhanced control over run times beyond the default settings at the TIMING LINK level, utilizing JOURNEY PATTERN RUN TIMES is essential A JOURNEY PATTERN RUN TIME specifically applies to a TIMING LINK and is only valid for VEHICLE JOURNEYs that follow the designated JOURNEY PATTERN.

It overrides the default run times that might have been defined for this TIMING LINK

Journey Pattern Run Times consist of various run times categorized by different Time Demand Types Each Time Demand Type associated with a specific vehicle journey helps in selecting the relevant time from the recorded set for a particular Timing Link within the covered Journey Pattern.

A JOURNEY PATTERN WAIT TIME indicates the duration a vehicle must pause at a designated TIMING POINT, such as for passenger boarding or to connect with another LINE These wait times are influenced by the specific JOURNEY PATTERN of the VEHICLE JOURNEY and the TIME DEMAND TYPE.

At the conclusion of each vehicle journey, a designated layover time may be allocated to accommodate delays or provide necessary rest for the driver This layover time serves as a buffer within a defined journey pattern, tailored to various time demand types Additionally, this general layover may be replaced by a specific vehicle journey layover when applicable.

For frequency-based services, it is essential to have headway duration information, which is provided by the JOURNEY PATTERN HEADWAY This data is accessible for all VEHICLE JOURNEYs operating on the JOURNEY PATTERN at the TIMING POINTs, varying according to different TIME DEMAND TYPEs.

The JOURNEY PATTERN WAIT TIME indicates the duration a vehicle must wait at a designated TIMING POINT IN JOURNEY PATTERN for a particular TIME DEMAND TYPE This wait time may be overridden by the VEHICLE JOURNEY WAIT TIME, as detailed in section 5.3.6.

The VEHICLE TYPE PREFERENCE indicates a suggested default VEHICLE TYPE for journeys based on the JOURNEY PATTERN and TIME DEMAND TYPE This concept is not strictly temporal; rather, it serves as a guideline for BLOCK compilation, as detailed in sections 5.3.9.2 and 5.6.3.2 It may consist of a ranked list of VEHICLE TYPEs tailored for each SERVICE JOURNEY PATTERN, DAY TYPE, and TIME DEMAND TYPE.

Figure 10 emphasizes the importance of considering timing information within a specific operational context, which characterizes a set of operational objects, including timing or links defined by a department or organizational unit.

JOURNEY PATTERN RUN TIME ôUIDằ

JOURNEY PATTERN WAIT TIME ôUIDằ

TIMING LINK IN JOURNEY PATTERN

NT Journey Pattern MODEL::TIMING POINT IN JOURNEY PATTERN

CC Serv ice Calendar MODEL::DAY TYPE

Name: TI JT Journey Pattern Times MODEL

CC Transport Organisations MODEL::OPERATIONAL CONTEXT

Figure 8 — Journey Pattern Times – Conceptual Model (UML)

Vehicle journey times

5.3.6.1 VEHICLE JOURNEY TIMES – Conceptual model

Precise control of run and wait times may be necessary beyond standard JOURNEY PATTERN levels, particularly for specific VEHICLE JOURNEYS For example, a vehicle might be intentionally slowed to align with a scheduled interchange Companies often modify wait and run times to adhere to driver scheduling regulations Additionally, during lengthy VEHICLE JOURNEYS in rural areas, a single TIME DEMAND TYPE may not be applicable due to significant variations in traffic conditions along the route.

It is hence necessary to be able to override the standard times by times for a specific VEHICLE JOURNEY

A number of specializations of JOURNEY TIMING are used to provide VEHICLE JOURNEY:

Vehicle journey run time refers to the duration required to complete a specific timing link within a journey pattern for a designated vehicle journey This parameter allows for precise control over travel times, superseding the default service journey run time, journey pattern run time, and default dead run run time.

Vehicle journey wait time refers to the duration a vehicle spends waiting at a specific timing point within its journey pattern This wait time takes precedence over the journey pattern wait time.

— VEHICLE JOURNEY LAYOVER is the time allowance at the end of a specified VEHICLE JOURNEY This time supersedes any global layover or JOURNEY PATTERN LAYOVER

Vehicle journey headway refers to the frequency of time intervals between consecutive vehicle journeys This information is crucial for understanding the timing of vehicle journeys, as it indicates the duration between the previous and the next journey.

VEHICLE JOURNEY WAIT TIME ôUIDằ

VEHICLE JOURNEY RUN TIME ôUIDằ

Name: TI JT Vehicle Journey Times MODEL Author: Transmodel

TI Journey Timing MODEL::JOURNEY LAYOVER

TI Journey Timing MODEL::JOURNEY WAIT TIME

TI Journey Timing MODEL::JOURNEY HEADWAY

TI Journey Timing MODEL::JOURNEY RUN TIME

Figure 9 — Vehicle journey times — Conceptual model (UML)

A more detailed model of frequency-based services is discussed in the next section

5.3.6.2 Frequency based service– Conceptual model

Two different types of services are commonly found, representing journeys with a particular behaviour as to the regularity of their timing

One of them is the common frequency-based service, based on the concept of HEADWAY INTERVAL, i.e a regular interval duration between the journeys such as ‘every 10 min’, for example

Another possibility is that of a particular ‘rhythm’ occurring over every hour, for example, services running at ‘xx10’, ‘xx25’, ‘xx45’ past each hour

A TEMPLATE VEHICLE JOURNEY is linked to a JOURNEY FREQUENCY GROUP, which signifies a collection of JOURNEYs operating at a specific frequency This relationship may depend on the TIME DEMAND TYPE and TIME BAND.

Passenger information systems often need to display multiple journeys in a single timetable column, such as "And then every 20 minutes until 6 pm." This model enables the aggregation of journey groups through a TEMPLATE JOURNEY, allowing for the specification of an overall frequency This can be achieved using either a HEADWAY JOURNEY GROUP, which indicates a frequency like "every 10 min," or a RHYTHMICAL JOURNEY GROUP, which operates at regular intervals past each hour, such as "xx10," "xx25," and "xx45."

Every scheduled vehicle journey operates on a defined set of passing times; however, these times may not be disclosed to passengers Instead, the journey can be presented based on its frequency, emphasizing how often it runs.

For passenger information purposes it is possible to consider a TEMPLATE VEHICLE JOURNEY without any concrete VEHICLE JOURNEYs class TI JT Frequency Based Serv ice MODEL

TI Vehicle Journey MODEL::TEMPLATE VEHICLE JOURNEY

This article defines a series of JOURNEYs to illustrate specific behaviors, such as frequency-based services and rhythmical services, which operate at regular intervals (e.g., at xxh10, xxh25, and xxh45) This approach is particularly beneficial for enhancing passenger information.

"rytm" every hour (runs all xxh10, xxh25 and xxh45 for example) This is specially useful for passenger information.

This is valid for specific timebands, on specific DAY TYPE (through the JOURNEY GROUP).

Services runing with a regular interval (every

10 mn for example) This is specially useful for passenger information.

This is valid for specific timebands, on specific DAY TYPEs (through the JOURNEY GROUP).

Name: TI JT Frequency Based Service MODEL

TI Journey Pattern Times MODEL::JOURNEY PATTERN HEADWAY

TI Serv ice Journey MODEL::TEMPLATE SERVICE JOURNEY

JOURNEY PATTERN POINT IN LINK SEQUENCE

CC Serv ice Calendar MODEL:

+ timing reference for 1 +referenced by 0 *

Figure 10 — Vehicle journey frequency – Conceptual model (UML)

Interchange

5.3.7.1.1Interchange, connection and navigation path

To reach a trip's destination without direct service between the origin and scheduled stop points, passengers must interchange vehicles This transfer involves leaving one vehicle at a scheduled stop point and boarding another vehicle that operates on a different service journey, often on a different line, at the same or another scheduled stop point.

A SERVICE JOURNEY INTERCHANGE consists of two distinct SERVICE JOURNEYs, where passengers transfer from a feeder SERVICE JOURNEY to a distributor (“fetcher”) SERVICE JOURNEY These SERVICE JOURNEYs may either stop at the same SCHEDULED STOP POINT or at two different, yet nearby, SCHEDULED STOP POINTs, which often belong to the same STOP AREA Passengers should be prepared to walk a certain distance after disembarking from the feeder SERVICE JOURNEY to reach the stop for the distributor SERVICE JOURNEY.

A CONNECTION indicates a viable walking link for passengers to transfer between public transport vehicles at designated SCHEDULED STOP POINTs, along with the time allowed for this transfer.

Software for managing guaranteed interchanges utilizes time data from a CONNECTION to determine the wait time required for a distributor SERVICE JOURNEY after a fetcher SERVICE JOURNEY arrives In the absence of a specific CONNECTION, timings from a DEFAULT CONNECTION can be applied.

The CONNECTION time data can enhance passenger information in travel planners, but often requires more detailed insights tailored to individual preferences and capabilities To achieve this, additional information can be obtained from attributes linked to the physical model, including PATH LINKs and NAVIGATION PATHs.

A SERVICE JOURNEY INTERCHANGE refers to the planned interchange between two SERVICE JOURNEYs operated by the same vehicle, commonly seen in circular lines and coupled journeys It is crucial to adapt passenger information accordingly, as passengers are not required to change vehicles due to the implicit transfer Additionally, operation control staff must be informed of the potential impacts on passengers if the operation changes to involve two different vehicles for the SERVICE JOURNEYs.

In real-time operations, it is essential to manage interchanges that are publicly advertised Delays in arriving vehicles may require waiting times for others Consequently, the company is likely to establish specific rules and guidelines for drivers to follow when deviations from the planned schedule occur.

The SERVICE JOURNEY INTERCHANGE serves as a repository for essential details regarding the planned interchange between two SERVICE JOURNEYs It includes information on whether the interchange is advertised, if it is guaranteed, and the maximum waiting time a vehicle may have for a connecting vehicle beyond the scheduled departure time.

26 class TI JT Interchange MODEL

SERVICE JOURNEY PATTERN INTERCHANGE ôUIDằ

Name: TI JT Interchange MODEL Author: Transmodel

NT Notice Assignment MODEL::NOTICE

NT Stop Assignment MODEL::STOP ASSIGNMENT

NT Serv ice Pattern MODEL::SCHEDULED STOP POINT

NT Stop Place MODEL:: STOP PLACE

NT Serv ice Pattern MODEL::

Figure 11 — Interchange – Conceptual model (UML)

When optimizing SERVICE JOURNEY start times, the scheduler must consider parameters that impact service quality, particularly the effect of passenger waiting times at interchanges on overall travel durations The goal is to minimize waiting times at interchanges while accommodating necessary transfer periods Simultaneously, the public transport company must operate efficiently, maximizing the use of its limited fleet of vehicles and drivers.

Passenger waiting times at interchanges are influenced by the schedule, necessitating a balance between ideal conditions and practical limitations To achieve the optimal compromise, specific quality parameters must be considered during the journey optimization and synchronization process.

The DEFAULT INTERCHANGE entity is utilized to store quality parameters associated with SCHEDULED STOP POINTS, where passengers can disembark from one vehicle and board another This entity applies to any pair of SERVICE JOURNEYs that connect the initial and subsequent SCHEDULED STOP POINTS.

The maximum allowable duration for an interchange between SERVICE JOURNEYs at SCHEDULED STOP POINTs is a critical parameter If this duration is exceeded, the interchange will be deemed invalid, and the scheduler may receive a warning from the system to retime the journeys Failure to address this issue could result in these journeys not being advertised as connected at the designated SCHEDULED STOP POINTs.

Another parameter is the standard duration that is aimed at, when planning an interchange This should be taken into account as a reference value when timing the SERVICE JOURNEYs

A JOURNEY MEETING describes the possibility to plan the schedules according to various interchange possibilities:

— interchange with another service, of which only the arrival or departure time is known;

— 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.);

The organization of a meeting hub involves coordinating multiple services within a specified time frame, serving as a simplified overview of various interchanges For a more detailed understanding, this can be elaborated using specific INTERCHANGE RULEs or SERVICE JOURNEY INTERCHANGEs as outlined in section 5.3.8.

— specification of a rendez-vous (time and place) for any journey that can meet the appointment

A JOURNEY MEETING can be associated with one or multiple SERVICE JOURNEYs, organized based on the specifics of the JOURNEY MEETING These journeys may be scheduled according to an earliest time, such as the arrival of a feeder line plus the transfer duration, or a latest time, like the opening hour of the school being served In some cases, both time constraints may apply, such as the time band of a hub.

A JOURNEY MEETING occurs at designated SCHEDULED STOP POINTs, also known as TIMING POINTs It is primarily organized for VEHICLE JOURNEYs that fall under the same DAY TYPE The timing for these VEHICLE JOURNEYs is typically determined based on the specified JOURNEY MEETING.

Sometimes, the scheduled possibility to interchange needs to be differentiated, depending on the SERVICE JOURNEY PATTERNs involved The SERVICE JOURNEY PATTERN INTERCHANGE specifies

Interchange rule

An INTERCHANGE RULE allows an intended interchange to be recorded in the schedule without having to specify the exact details of both SERVICE JOURNEYs involved in the interchange

The INTERCHANGE RULE offers sufficient information to identify eligible SERVICE JOURNEY INTERCHANGEs after the scheduling process is finalized This identification may occur later when schedules from various sources are synchronized within an integrator system or in real-time, taking into account any late rescheduling and delays affecting the involved LINEs.

A SERVICE JOURNEY INTERCHANGE allows passengers to transfer between two distinct SERVICE JOURNEYs This transfer can occur at a SCHEDULED STOP POINT, enabling passengers to switch from a feeder SERVICE JOURNEY to a distributor SERVICE JOURNEY at the same or a nearby location.

Often the two involved SERVICE JOURNEYs in the interchange are planned separately Sometimes the SERVICE JOURNEYs are worked by different companies

Managing the precise details of a SERVICE JOURNEY during an interchange is challenging for schedulers, as these journeys can be modified, canceled, or substituted at any moment.

To simplify the management of external changes and avoid the constant need to adjust the schedule based on the external service journey, it is more efficient to implement an interchange rule.

The INTERCHANGE RULE uses INTERCHANGE RULE PARAMETERs which will remain stable over time to identify the involved SERVICE JOURNEYs

The INTERCHANGE RULE PARAMETER outlines the criteria a candidate SERVICE JOURNEY must meet for consideration, which may apply to a specific LINE and DIRECTION Additionally, criteria may involve the time of day or a designated SERVICE JOURNEY identifier The selection of criteria or their combinations will vary based on different use cases.

The SCHEDULED STOP POINTs for both feeder and distributor SERVICE JOURNEYs can be filtered based on the INTERCHANGE RULE Instead of designating a specific SCHEDULED STOP POINT, a broader STOP AREA can be defined, allowing any SCHEDULED STOP POINT within that area to be accepted for the SERVICE JOURNEY This approach is particularly beneficial when the precise stopping locations are uncertain or subject to change.

The final matching criterion is the maximum interchange window duration, which filters out pairs of feeder and distributor SERVICE JOURNEYs This ensures that the feeder's arrival time is not excessively earlier than the distributor's departure time, making the combination irrelevant for SERVICE JOURNEY INTERCHANGE.

Name: TI JT Interchange Rule MODEL

NT Serv ice Pattern MODEL::SCHEDULED STOP POINT

NT Serv ice Pattern MODEL::STOP AREA

TI Journey Timing MODEL::JOURNEY TIMING

CC Serv ice Calendar MODEL:

NT Time Demand Type MODEL::TIME DEMAND TYPE ôExclusionằ

Figure 12 — Interchange rule – Conceptual model (UML)

Coupled journey

Rail systems offer a significant advantage over conventional bus systems through the operation of coupled vehicles, such as TRAIN or COMPOUND TRAIN types This capability allows for a more flexible adjustment of service supply to meet demand, enabling trains to be shortened or lengthened throughout the day or even within a single SERVICE JOURNEY.

Train journeys can be intricate, as a compound train may split into two or more sections at a branching point, with each part continuing on distinct routes to different destinations.

Two short trains from different routes can be scheduled to meet at a junction, where they are coupled to form a single long train that continues on a shared path.

The COUPLED JOURNEY concept pertains to the coupling of vehicles, where a 'vehicle' is defined as a stable unit throughout its JOURNEY This can refer to a single vehicle, such as a tramway, or a TRAIN made up of multiple TRAIN ELEMENTs, or even a COMPOUND TRAIN consisting of several elementary TRAINs.

The TRAIN entity represents a basic unit of a train, classified as a VEHICLE TYPE It is made up of various TRAIN ELEMENTs that are assembled together The arrangement of these TRAIN ELEMENTs within the TRAIN is specified by a TRAIN COMPONENT, which outlines their order in the overall structure.

Vehicle coupling actions are fundamentally linked to the concept of VEHICLE TYPE A TRAIN, like any vehicle, operates through VEHICLE JOURNEYs In the absence of coupling actions during a VEHICLE JOURNEY, only one TRAIN is involved However, multiple TRAINs can be coupled for part of a VEHICLE JOURNEY or for extended durations, leading to changes in the composition of the compound train, thus altering the VEHICLE TYPE This interaction of coupled vehicles is encapsulated in the concept of COMPOUND TRAINs, represented by the class TI JT Coupled Journey MODEL.

TI Vehicle Journey MODEL::VEHICLE

TI Vehicle Journey MODEL::TRAIN NUMBER

CC Generic Point & Link MODEL::POINT

Name: TI JT Coupled Journey MODEL

+made up of 0 1 +included in *

+used as main part in 1

Figure 13 — Coupled journey – Basic conceptual model (UML)

5.3.9.2 Journey part and journey part couple

Two distinct points of view of vehicle coupling need to be taken into account:

Operational management oversees work periods for each vehicle type, referred to as BLOCKs These BLOCKs, detailed in section 5.6.3.2, consist of journeys from a parking point to another and are made up of multiple vehicle journeys Additionally, BLOCKs can be coupled to enhance efficiency.

Compound blocks illustrate the work of a vehicle while it is either coupled to another vehicle or temporarily separated These blocks consist of various parts that correspond to different segments of the vehicle's journey This modeling approach enables the classification of block parts, indicating whether coupling or separation occurs at the beginning or end of a block.

Passenger information is influenced by whether VEHICLE JOURNEYs are coupled or not, particularly at intermediate points where routes meet or diverge JOURNEY PARTs define the various segments of a VEHICLE JOURNEY, with coupled segments designated as JOURNEY PARTs The primary purpose of JOURNEY PARTITION in this context is "coupling," where one JOURNEY PART serves as the main segment of the combined vehicle The JOURNEY PART COUPLE entity represents the connection between a JOURNEY PART and the main segment Conversely, when vehicles separate, new JOURNEY PARTs are formed, and the purpose of JOURNEY PARTITION shifts to "separation."

A coupled journey is a comprehensive trip managed by a compound train, consisting of two or more vehicle journeys that remain connected throughout the journey pattern This type of journey can be perceived as a single vehicle journey, which simplifies passenger information, as travelers are indifferent to the journey's composite nature from a vehicle management perspective.

The concept of TRAIN NUMBER connects both operational and passenger information, assigning specific codes to VEHICLE JOURNEYs, JOURNEY PARTs, and JOURNEY PART COUPLEs operated by TRAINs or COMPOUND TRAINs for various functional purposes, such as passenger information and operational follow-up The exposure of these numbers is regulated by two attributes: ForAdvertisement and ForProduction.

The following examples illustrate the joining and splitting of trains and the relationship to the journey coupling or splitting

Figure 14 — Example – Joining and splitting trains (source NeTEx)

5.3.9.4.2 Example of joining and splitting: Amsterdam to Warsaw

In this scenario, a train departs from Amsterdam and branches out to three distinct destinations: Warsaw, Copenhagen, and Prague The splitting points for these routes are Hannover and Berlin, where an additional train (60467) connects to the Berlin to Prague segment Each train is identified by its unique TRAIN NUMBER.

Figure 15 — Example – Joining and splitting: Amsterdam to Warsaw (source NeTEx)

This can be represented by three SERVICE JOURNEYs, each made up of several JOURNEY PARTs

Figure 16 — Example – Journeys: Amsterdam to Warsaw (source NeTEx)

The JOURNEY PARTs are shown in the following diagram

Figure 17 — Example – Journey parts: Amsterdam to Warsaw (source NeTEx)

The points at which the journeys join or split can be represented by JOURNEY MEETINGs

Figure 18 — Example – Six journey meetings: Amsterdam to Warsaw (source NeTEx)

The detailed train makeup of which carriages go to which destinations can be represented with TRAIN, TRAIN COMPONENTs and TRAIN ELEMENTs

Figure 19 — Example – Journey meetings: Amsterdam to Warsaw (source NeTEx)

Flexible service

Flexible transport (i.e demand responsive transport) is characterized by flexible routing and scheduling Flexible routing is described in [8]

Flexible services can function on both regular line topologies and flexible topologies, characterized by the integration of additional flexibility information via the TYPE OF FLEXIBLE JOURNEY object When this information is linked to a SERVICE JOURNEY through FLEXIBLE JOURNEY PROPERTIES, the entire service becomes flexible Conversely, if it is associated with a POINT IN JOURNEY PATTERN, only the specified point will exhibit flexibility, typically coinciding with SCHEDULED STOP POINTs This approach allows for the implementation of partially flexible services or a combination of different flexible service types within the same JOURNEY Various types of flexible services are available to cater to diverse needs.

— Fixed PASSING TIMEs (i.e scheduled passing time: there is a timetable, but the service will only run under condition, mainly sufficient demand)

— Fixed HEADWAY FREQUENCY (in this case, a maximum waiting time is available through a HEADWAY JOURNEY GROUP, but no passing times are defined, all is done dynamically depending on the demand)

A NotFlexible value indicates whether a POINT IN JOURNEY PATTERN is flexible or not

Two additional properties can also be supplied:

1) whether cancellation is possible or not, even after booking (meaning that the Operator can decide to cancel a service or a stop, usually because there is not enough demand, or the service is too busy;

2) whether the PASSING TIME and place may be updated or not, even after booking (usually passing times update to optimize the service) class TI JT Flexible Serv ice MODEL

Name: TI JT Flexible Service MODEL

TYPE OF FLEXIBLE SERVICE ôUIDằ

NT Journey Pattern MODEL::JOURNEY

MODEL::TYPE OF JOURNEY PATTERN

NT Journey Pattern MODEL::DEAD RUN PATTERN

NT Journey Pattern MODEL::TIMING LINK IN JOURNEY PATTERN

+classified by * +made up of 1

Figure 20 — Flexible service – Conceptual model (UML)

Flexible services, such as the TAD 118 in the Toulouse area of France, exemplify innovative transportation solutions The accompanying schematic map illustrates the TAD 118's potential stops, marked in red, which vary based on demand, while the orange and green lines represent the established regular service routes.

Figure 21 — Flexible service example: Tisseo TAD 118 with courtesy of Tisseo, data from August

Journey accounting

The JOURNEY ACCOUNTING framework offers essential parameters that define VEHICLE JOURNEYs and SPECIAL SERVICEs for accounting in organizational contracts This accounting can be based on either the distance traveled or the duration of the JOURNEY, or a combination of both, as outlined in the TI JA Journey Accounting MODEL.

TI Vehicle Journey MODEL::VEHICLE

TI Vehicle Journey MODEL::DEAD RUN

TI Serv ice Journey MODEL::

Name: TI JA Journey Accounting MODEL Author: Transmodel

Figure 22 — Journey accounting – Conceptual model (UML)

Passing times

Vehicle scheduling

Vehicle journey assignments

Explicit frames

Tiêu đề	Timing Information And Vehicle Scheduling
Trường học	British Standards Institution
Chuyên ngành	Public Transport
Thể loại	British Standard
Năm xuất bản	2016
Thành phố	Brussels

Định dạng
Số trang	90
Dung lượng	7,98 MB