Public transport — Network and Timetable Exchange (NeTEx) — … › wp-content › uploads › 2014 › 07 › ... · 2014-09-01 · Systems). However it is not restricted to

Document type: Technical Specification Document subtype: Document stage: Formal Vote Document language: E C:\Data\NeTEx\Part 2 - V17 Publication\Part 2 - Word document\prCEN TS 278308 FV (E)-v17 UpdatedDoc.doc STD Version 2.5a

CEN/TC 278 Date: 2013-03

TC 278 WI 00278308

CEN/TC 278

Secretariat: NEN

Public transport — Network and Timetable Exchange (NeTEx) — Part 2: Public transport scheduled timetables exchange format

NeTEx — Haupt-Element — Teil 2: Teil-Titel

Transport Public — Echanges des informations planifiées (NeTEx) — Partie 2 : Description de l'offre de transport

ICS:

Descriptors:

TC 278 WI 00278308:2013 (E)

2

Contents Page

Foreword ............................................................................................................................................................. 4

Introduction ........................................................................................................................................................ 5

1 Scope ...................................................................................................................................................... 6

1.1 General ................................................................................................................................................... 6

1.2 Transport modes ................................................................................................................................... 6

1.3 Compatibility with existing standards and recommendations ......................................................... 6

2 Normative references ........................................................................................................................... 6

3 Terms and definitions ........................................................................................................................... 7

4 Symbols and abbreviations ................................................................................................................. 7

5 Use Cases for Journey & Journey Time Exchange ........................................................................... 7

6 Generic Physical Model and XSD mapping rules .............................................................................. 7

7 Timing Information – Conceptual and physical data model ............................................................. 7

7.1 Introducion ............................................................................................................................................. 7

7.1.1 Journey and Journey Times – Model dependencies ......................................................................... 8

7.2 Journey and Journey Times .............................................................................................................. 16

7.2.1 Vehicle Journey ................................................................................................................................... 16

7.2.2 Service Journey................................................................................................................................... 31

7.2.3 Time Demand Times ........................................................................................................................... 46

7.2.4 Journey Timing .................................................................................................................................... 56

7.2.5 Journey Pattern Times ....................................................................................................................... 65

7.2.6 Vehicle Journey Times ....................................................................................................................... 73

7.2.7 Interchange .......................................................................................................................................... 90

7.2.8 Interchange Rule ............................................................................................................................... 108

7.2.9 Coupled Journey ............................................................................................................................... 116

7.2.10 Flexible Service ................................................................................................................................. 134

7.2.11 Journey Accounting ......................................................................................................................... 143

7.2.12 Dated Journey ................................................................................................................................... 146

7.2.13 Passing Times ................................................................................................................................... 151

7.2.14 Call ...................................................................................................................................................... 159

7.2.15 Dated Call ........................................................................................................................................... 175

8 Vehicle Scheduling ........................................................................................................................... 177

8.1 Vehicle Scheduling – Model dependencies .................................................................................... 177

8.2 Vehicle Scheduling ........................................................................................................................... 178

8.2.1 Vehicle Schedule Frame ................................................................................................................... 178

8.2.2 Vehicle Service .................................................................................................................................. 182

8.2.3 Train Service ...................................................................................................................................... 196

Annex A (informative) Monitoring & Control .............................................................................................. 201

A.1 Introduction ....................................................................................................................................... 201

A.2 Monitoring & Control ........................................................................................................................ 201

A.2.1 Monitored Vehicle Journey .............................................................................................................. 201

A.2.2 Dated Passing Times – Physical Model .......................................................................................... 208

Annex B (informative) Driver Scheduling ..................................................................................................... 213

B.1 Introduction ....................................................................................................................................... 213

B.2 Driver Scheduling.............................................................................................................................. 213

B.2.1 Driver Schedule Frame ..................................................................................................................... 213

B.2.2 Duty .................................................................................................................................................... 216

B.2.3 Duty Stretch ....................................................................................................................................... 223

3

Bibliography .................................................................................................................................................... 226

TC 278 WI 00278308:2013 (E)

4

Foreword

This document (TC 278 WI 00278308) has been prepared by Technical Committee CEN/TC 278 “Road transport and traffic telematics”, the secretariat of which is held by NEN.

This document is currently submitted to the Formal Vote.

This document presents Part 2 of the European Technical Specification known as “NeTEx”. NeTEx provides a framework for specifying communications and data exchange protocols for organisations wishing to exchange scheduled Information relating to public transport operations.

This Technical Specification is made up of three parts defining a single European Standard, which provides a complete exchange format for public transport networks, timetable description and fare information.

Part 1 is the description of the public transport network topology exchange format. It also contains use case shared with part 2, and modelling rules and the description of a framework shared by all parts.

Part 2 is the description of the scheduled timetables exchange format.

Part 3 is the description of the fare information exchange format.

Part 1 is fully standalone, and parts 2 and 3 rely on part 1.

The XML schema can be downloaded from www.netex.org.uk, along with available guidance on its use, example XML files, and case studies of national and local deployments.

This document is higly technical, and a special care has been taken on keeping the text readable. This has been done through a set of editorial rules enhancing usual CEN writing rules:

To avoid confusion with usual wording, Transmodel terms are in capital letters (JOURNEY PATTERN for example).

To avoid confusion with usual wording, attributes names are in bold/italic style and use camelcase style with no spaces (JourneyPattern for example).

To avoid confusion with usual wording, attributes types are in italic style and use camelcase style with no spaces (TypeOfEntity for example).

5

Introduction

Public transport services rely increasingly on information systems to ensure reliable, efficient operation and widely accessible, accurate passenger information. These systems are used for a range of specific purposes: setting schedules and timetables; managing vehicle fleets; issuing tickets and receipts; providing real-time information on service running, and so on.

This European Technical Specification specifies a Network and Timetable Exchange (NeTEx) about public transport. It is intended to be used to exchange information between PT organisations systems containing scheduled public transport data. It can also be seen as a complement to the SIRI (Service Interface for Real-time Information) standard, as SIRI needs reference data exchange in the scope of NeTEx before any possible real-time exchange.

Well-defined, open interfaces have a crucial role in improving the economic and technical viability of public transport Information Systems of all kinds. Using standardised interfaces, systems can be implemented as discrete pluggable modules that can be chosen from a wide variety of suppliers in a competitive market, rather than as monolithic proprietary systems from a single supplier. Interfaces also allow the systematic automated testing of each functional module, vital for managing the complexity of increasing large and dynamic systems. Furthermore, individual functional modules can be replaced or evolved, without unexpected breakages of obscurely dependent function.

This standard will improve a number of features of public transport information and service management: Interoperability – the standard will facilitate interoperability between information processing systems of the transport operators by: (i) introducing common architectures for message exchange; (ii) introducing a modular set of compatible information services for real-time vehicle information; (ii) using common data models and schemas for the messages exchanged for each service; and (iv) introducing a consistent approach to data management.

Technical advantages include the following: reusing a common communication layer shared with SIRI for all the various technical services enables cost-effective implementations, and makes the standard readily extensible in future.

TC 278 WI 00278308:2013 (E)

6

1 Scope

1.1 General

NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information) based on

Transmodel V5.1 (EN 12986), IFOPT (CEN/TS 28701) and SIRI (CEN/TS 15531-4/5 and EN 15531-1/2/31) and supports information exchange of relevance to public transport services for passenger information and AVMS systems.

NOTE Many NeTEx concepts are taken directly from Transmodel and IFOPT; the definitions and explanation of these concepts are extracted directly from the respective standards and reused in NeTEx, sometimes with further adaptions in order to fit the NETEx context.

The data exchanges targeted by NeTEx are predominantly oriented towards passenger information and also for data exchange between transit scheduling systems and AVMS (Automated Vehicle Monitoring Systems). However it is not restricted to these purposes, and NeTEx can provide an effective solution to many other use cases for transport exchange.

1.2 Transport modes

Most public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tramway, ferry, and their submodes. It is possible to describe airports and air journeys, but there has not been any specific consideration of any additional provisions that apply especially to air transport.

1.3 Compatibility with existing standards and recommendations

The concepts covered in NeTEx that relate in particular to long-distance train travel include; rail operators and related organizations; stations and related equipment; journey coupling and journey parts; train composition and facilities; planned passing times; timetable versions and validity conditions.

In the case of long distance train the NeTEx takes into account the requirements formulated by the ERA (European Rail Agency) – TAP/TSI (Telematics Applications for Passenger/ Technical Specification for Interoperability, entered into force on 13 May 2011 as the Commission Regulation (EU) No 454/2011), based on UIC directives.

As regards the other exchange protocols, a formal compatibility is ensured with TransXChange (UK), VDV 452 (Germany), NEPTUNE (France), UIC Leaflet, BISON (Netherland) and NOPTIS (Nordic Public Transport Interface Standard).

The data exchange is possible either through dedicated web services, through data file exchanges, or using the SIRI exchange protocol as described in part 2 of the SIRI documentation.

2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

EN 15531-1, Public transport - Service interface for real-time information relating to public transport

operations - Part 1: Context and framework2

1 Under development

2 Under development (WI 00278340)

7


operations - Part 2: Communications infrastructure3


operations - Part 3: Functional service interfaces4

CEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring

CEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange

EN 12896, Road transport and traffic telematics - Public transport - Reference data model

EN 28701, Intelligent transport systems - Public transport - Identification of Fixed Objects in Public Transport (IFOPT)

3 Terms and definitions

For the purposes of this document, the terms and definitions given in CEN/TS 16614-1 apply.

4 Symbols and abbreviations

For the purposes of this document, the symbols and abbreviations given in CEN/TS 16614-1 apply.

5 Use Cases for Journey & Journey Time Exchange

NeTEx Part 2 shares its use cases with NeTEx Part 1 since many use cases involve both part 1 and part 2 entities. Please refer to NeTEx Part 1 for a detailed use case description.

6 Generic Physical Model and XSD mapping rules

For consistency, the mapping rules for transforming a Conceptual Model to Physical Model and then to XSD are shared between all parts of NeTEx.

Please refer to NeTEx Part 1 for a detailed description of the Physical Model and XSD mapping rules.

7 Timing Information – Conceptual and physical data model

7.1 Introducion

NeTEx Part 2 timing information model is splited into four main submodels defined as UML packages.

Figure 1 – NeTEx Part 2 main packages



TC 278 WI 00278308:2013 (E)

8

The Journey and Journey Times model: describes the model planned services and dead runs and their timings

Figure 2 – JourneyAndJourneyTimes packages

The dated journey model: describes the services for a single operating day

The passing time model: describes all the different types of passing times

The vehicle service model: describes the informations related to vehicles and their services

7.1.1 Journey and Journey Times – Model dependencies

The JOURNEY AND JOURNEY TIMES Model describes the VEHICLE JOURNEYs and other components making up a timetable and is itself divided into a number of separate submodels covering different aspects of VEHICLE JOURNEYs. For ease of understanding, the submodels are presented one at a time, each describing only a small set of related concepts.

The submodels depend on a number of general NeTEx framework models and reusable components described elsewhere (for example, the GENERIC POINT AND LINK model, NOTICE model, etc.,) – See NeTEx Part 1 for further details.

The following figure shows the dependencies between the JOURNEY AND JOURNEY TIMES physical submodels. The terminal packages contain the SERVICE FRAME and the TIMETABLE FRAME. These two VERSION FRAMEs are containers that organise the other payload elements into a coherent set of elements suitable for exchange as a serialised file. The payload elements are contained in the following packages:

TIMETABLE FRAME

VEHICLE JOURNEY: models journeys that vehicles make.

SERVICE JOURNEY: additionally models the properties of journeys that carry passengers.

TIME DEMAND TIMEs: models the times of the different demand levels found during a day.

PASSING TIMEs: describes the times of vehicles at points in their journey.

JOURNEY TIMINGs: describes the common timing properties for journeys.

9

JOURNEY PATTERN TIMEs: describes the timings of JOURNEY PATTERNs.

VEHICLE JOURNEY TIMEs: describes the timings of VEHICLE JOURNEYs.

INTERCHANGE: describes interchanges between journeys.

COUPLED JOURNEY: describes multipart journeys which join and split.

FLEXIBLE SERVICE: additional describes demand responsive transport services.

JOURNEY ACCOUNTING: assigns a cost basis for journeys.

pkg XSD NeTEx - Part 2 - Journey & Journey Times Model Dependencies

XSD NeTEx RC Reusable Component

XSD NeTEx - Part 2 - Schedules and Versions

XSD NeTEx - Part 2 - Operations & Monitoring

XSD NeTEx - Part 1 - Tactical Planning

XSD NeTEx - Part 1 - Network Description

Name: XSD NeTEx - Part 2 - Journey & Journey Times Model Dependencies

Author: NeTEx

Version: 1.0

Created: 07/02/2010 22:30:50

Updated: 04/04/2012 14:08:31

VehicleJourneyTimesModel

TimingAlgorithm

VehicleJourneyLayover

VehicleJourneyRunTime

VehicleJourneyWaitTime

VehicleJourneyModel

Journey

VehicleJourney

DeadRun

TemplateVehicleJourney

TrainNumber

TypeOfService

TypeOfProductCategory

JourneyDesignator

PassingTimesModel

PassingTime

TimetabledPassingTime

TimeDemandTimesModel

DefaultServiceJourneyRunTime

DefaultDeadRunRunTime

JourneyPatternTimesModel

JourneyPatternWaitTime

JourneyPatternRunTime

JourneyPatternLayover

JourneyPatternHeadway

VehicleTypePreference

JourneyTimingModel

JourneyTiming

JourneyRunTime

JourneyWaitTime

JourneyLayover

JourneyHeadway

TurnaroundTimeLimit

HeadwayIntervalTimeDemandTypeModel

TimeDemandType

TimeDemandTypeAssignment

TypeOfTimeDemandType

JourneyPatternModel

JourneyPattern

DeadRunPattern

PointInJourneyPattern

TimingPointInJourneyPattern

TimingLinkInJourneyPattern

TypeOfJourneyPattern

Serv icePatternModel

StopArea

ScheduledStopPoint

ServiceLink

ServicePattern

ServiceJourneyPattern

StopPointInJourneyPattern

Connection

ConnectionEnd

TypeOfStopPoint

RouteModel

Direction

RoutePoint

RouteLink

Route

PointOnRoute

TurnStation A

VehicleTypeModel

Vehicle

VehicleType

VehicleModel

VehicleEquipmentProfi le

PassengerCapacity

PurposeOfEquipmentProfi le

TypeOfFuel

VehicleServ iceModel

Block

BlockPart

CompoundBlock

CourseOfJourneys

ReliefOpportunity

VehicleService

VehicleServicePart

NoticeAssignmentModel

NoticeAssignment

Serv iceJourneyModel

GroupOfServices

ServiceJourney

SpecialService

TemplateServiceJourney

JourneyEndpoint

InterchangeRuleModel

InterchangeRule

InterchangeRuleParameter

InterchangeRuleTiming

DatedPassingTimesPackage

DatedPassingTimesModel

DatedPassingTimeSupport

InterchangeModel

DefaultInterchange

Interchange

ServiceJourneyInterchange

ServiceJourneyPatternInterchange

InterchangeTimes

JourneyMeeting

CoupledJourneyModel

JourneyPart

CoupledJourney

JourneyPartCouple

PurposeOfJourneyPartition

TypeOfCoupling

FacilityModel

Facil i tySet

ServiceFacil i tySet

SiteFacil i tySet

Facil i ty

Accommodation

OnboardStay

Facil i tyList

VehicleJourneyFrequencyModel

JourneyFrequencyGroup

HeadwayJourneyGroup

RhythmicalJourneyGroup

VehicleJourneyHeadway

JourneyFrequency

CallModel

Call

Arrival

Departure

OnwardServiceLinkView

OnwardTimingLinkView

CallPart

StopAssignmentModel

StopAssignment

PassengerStopAssignment

DynamicStopAssignment

JourneyAccountingModel

JourneyAccounting

FlexibleNetworkModel

FlexibleRoute

FlexibleLine

BookingArrangements

FlexiblePointProperties

FlexibleLinkProperties

FlexibleServ iceModel

FlexibleServiceProperties

FlexibleStopAssignment

TypeOfFlexibleService

Serv iceRequirementModel

VehicleRequirement

ManoeuvringRequirement

PassengerCarryingRequirement

Facil i tyRequirement

DeadRunCallModel

DeadRunCall

DeadRunArrival

DeadRunDeparture

DeadRunCallPart

Figure 3 — Journey – Model Dependencies

7.1.1.1 Timetable Frame

7.1.1.1.1 TIMETABLE FRAME – Conceptual MODEL

The elements of the JOURNEY & JOURNEY TIMES model can be grouped with a TIMETABLE FRAME which holds a coherent set of timetable related elements for data exchange (see VERSION FRAME in the NeTEx Framework section for general concepts relating to version frames).

The primary component exchanged by a TIMETABLE FRAME is a SERVICE JOURNEY, which describes an individual journey. This and other components of a TIMETABLE FRAME are described in detail in the following sections.

TC 278 WI 00278308:2013 (E)

10

class NeTEx EF Timetable Frame MODEL

May 2011

TIMETABLE VERSION

FRAME renamed to

TIMETABLE FRAME

Generic Validity

MODEL::VALIDITY

CONDITION

Generic Version

MODEL::VERSION

FRAME

TIMETABLE FRAME

Time Demand Type

MODEL::TIME

DEMAND TYPE

Time Demand Type

MODEL::TIME DEMAND

TYPE ASSIGNMENT

Generic Point &

Link MODEL::

GROUP OF LINKS

Serv ice Journey

MODEL::GROUP

OF SERVICES

Serv ice

Journey

MODEL::

SERVICE

JOURNEY

JOURNEY

Vehicle Journey

MODEL::VEHICLE

JOURNEY

Vehicle Journey

MODEL::DEAD RUN

Vehicle Journey Times

MODEL::JOURNEY

FREQUENCY GROUP

Coupled Journey

MODEL::JOURNEY

PART

Coupled Journey MODEL::

JOURNEY PART COUPLE

Coupled Journey

MODEL::TRAIN

NUMBER

Interchange

MODEL::

JOURNEY

MEETING

INTERCHANGE

Interchange MODEL::

SERVICE JOURNEY

INTERCHANGE

INTERCHANGE

Interchange MODEL::

SERVICE JOURNEY

PATTERN

INTERCHANGE

Notice

MODEL::

NOTICE

Name: NeTEx EF Timetable Frame MODEL

Author: Kasia

Version: 1.0

Created: 23/05/2011 16:16:28

Updated: 05/01/2012 17:29:38

Serv ice Calendar Frame

MODEL::SERVICE

CALENDAR FRAME

Serv ice

Journey

MODEL::

TYPE OF

SERVICE

Coupled Journey MODEL::

PURPOSE OF JOURNEY

PARTITION

Coupled Journey

MODEL::TYPE OF

COUPLING

Journey Accounting

MODEL::JOURNEY

ACCOUNTING


MODEL::TEMPLATE

VEHICLE JOURNEY

Reusable Av ailability MODEL::

AVAILABILITY CONDITION

+composed of 1..*

+runs on 0..1

+subdivided in

1

+part of

*

+valid for*

+used as main part in

1

+including as

main part

0..1

+used to define *

+for 1

+used by default by

* +made using

*

+dated by0..*

+take use of

0..1

+restricted to

1

+defined for

*

+joining 1

+including as

joining part

0..1

0..1

0..*

0..1

0..*

0..*

0..*

Figure 4 — Timetable Frame – Conceptual MODEL (UML)

7.1.1.1.2 Timetable Frame – Physical Model

The following diagram shows the Physical model for a TIMETABLE FRAME.

11

class XSD NeTEx TP Timetable Frame Intro

Name: XSD NeTEx TP Timetable Frame Intro

Author: nickk

Version: 1.0

Created: 10/12/2010 17:19:28

Updated: 11/04/2012 14:53:22

TypeOfValue

DataSource

DataManagedObject

VersionFrame

DataManagedObject

ValidityCondition

TimetableFrame

DataManagedObject

TimeDemandType

DataManagedObject

JourneyPartCouple

DataManagedObject

JourneyPart

Journey

VehicleJourney

Serv iceJourney

GroupOfEntities

GroupOfServ ices

DataManagedObject

Notice

TypeOfEntity

TypeOfServ ice

Interchange

Serv iceJourneyPatternInterchange

Interchange

Serv iceJourneyInterchange

TypeOfValue

TypeOfCoupling

DeadRun

DataManagedObject

TimeDemandTypeAssignment

GroupOfEntities

GroupOfLinks

DataManagedObject

JourneyMeeting

Serv iceCalendarFrame

TypeOfValue


GroupOfEntities


DataManagedObject

TrainNumber

JourneyWaitTime

JourneyPatternWaitTimeJourneyRunTime


TypeOfValue

TimingAlgorithm


TemplateServ iceJourney

DataManagedObject

JourneyAccounting

Av ailabilityCondition

VersionedChild

FlexibleServ iceProperties

identified by 0..*

identifies 0..*

used to define 1

associated with *

runs on

0..*

used to define *

for 1

in 0..*

made up of

composed of

1..*

runs on 0..1 subdivided in 1

{ordered}

part of *

belongs to

0..*

comprising

identified by

0..1

identifies 0..*

flexible properties

0..1

defines 1..*

is defined by1..*

joining0..*

including as joining part0..1

uses 0..*

dated by 0..1

used to define 1

associated with *

booking times

restricted to

1

defined for

*source of

0..1

produced by

*

Figure 5 — Timetable Frame Contents – Physical Model (UML)

TC 278 WI 00278308:2013 (E)

12

class XSD NeTEx TP Timetable Frame Model

Name: XSD NeTEx TP Timetable Frame Model

Author: nickk

Version: 1.0

Created: 25/03/2011 10:05:23

Updated: 11/04/2012 14:53:22

VersionFrame

TimetableFrameModel::TimetableFrame

VehicleModes :VehicleModeEnum [0..*]

HeadwayService :boolean [0..1]

Monitored :boolean [0..1]

«PK»

id :TimetableFrameIdType

«EV»

NetworkView :NetworkView [0..1]

LineView :LineView [0..1]

OperatorView :OrganisationView [0..1]

ServiceCalendarFrameRef :ServiceCalendarFrameRef* [0..1]

DefaultMode :VehicleModeEnum [0..1]

«contained»

bookingTimes :Availabil ityCondition [0..*]

timeDemandTypes :TimeDemandType [0..*]

timeDemandTypeAssignments :T imeDemandTypeAssignment [0..*]

timingLinkGroups :GroupOfLinks [0..*]

vehicleJourneys :Journey [0..*]

frequencyGroups :Interchange [0..*]

groupsOfServices :GroupOfServices [0..*]

trainNumbers :TrainNumbers [0..*]

journeyPartCouples :JourneyPartCouple [0..*]

typesOfService :TypeOfService [0..*]

flexibleServiceProperties :FlexibleServiceProperties [0..*]

notices :Notice [0..*]

noticeAssignments :NoticeAssignment [0..*]

journeyMeetings :JourneyMeeting [0..*]

journeyInterchanges :Interchange [0..*]

interchangeRules :InterchangeRule [0..*]

journeyAccounting :JourneyAccounting [0..*]

defaultInterchanges :Interchange [0..*]

«FK»

JourneyAccountingRef :JourneyAccounting [0..1]

DataManagedObject

TimeDemandTypeModel::TimeDemandType

DataManagedObject

CoupledJourneyModel::

JourneyPartCouple

Journey

VehicleJourneyModel::VehicleJourney

GroupOfEntities

Serv iceJourneyModel::GroupOfServ ices

DataManagedObject

NoticeModel::Notice

TypeOfEntity

VehicleJourneyModel::

TypeOfServ ice

Interchange

InterchangeModel::


Interchange

InterchangeModel::


TypeOfValue

«ImplementAsEnum»

CoupledJourneyModel::TypeOfCoupling

GroupOfEntities

PointAndLinkModel::

GroupOfLinks

DataManagedObject

InterchangeModel::JourneyMeeting

DataManagedObject

TimeDemandTypeModel::TimeDemandTypeAssignment

DataManagedObject


JourneyPart

Serv iceJourneyModel::

Serv iceJourney


DeadRun

VersionFrame

Serv iceCalendarFrameModel::Serv iceCalendarFrame

DerivedView

OrganisationView::

OrganisationView

DataManagedObject

Serv iceCalendarModel::

DayType

DerivedView

«TM_VIEW»

LineAndRouteViews::LineView

DerivedView

«TM_VIEW»

LineAndRouteViews::DirectionView

DerivedView

«TM_VIEW»

LineAndRouteViews::NetworkView

DerivedView

«TM_VIEW»

NoticeAssignmentView::

NoticeAssignmentView

GroupOfEntities

VehicleJourneyFrequencyModel::


DataManagedObject


TrainNumber

DataManagedObject

JourneyAccountingModel::

JourneyAccounting

ValidityCondition

Av ailabilityConditionModel::Av ailabilityCondition

VersionedChild

FlexibleServ iceModel::FlexibleServ iceProperties

combining

0..*

combined in 1

0..1

default

used by 0..*

uses 0..*

used by default by 0..1

made using *

runs on 0..*

used to define *for 1

note 0..*

applies to

in

0..*

made up of

subdivided in1

{ordered}

part of *

runs

for

0..1

0..*

combines from 1

identified by0..*

identifies

0..*

identified

by

0..1

identifies

0..*

joining

0..* including as joining part

0..1

composed of

1..* runs on0..1

0..*

uses 0..*

dated by 0..1booking times

default

validdays

0..*

valid for

*

comprising

0..1default

on

0..*

day type

worked on *

for 1

Figure 6 — Timetable Frame – Physical Model Detail (UML)

7.1.1.1.3 Timetable Frame — XSD and attributes

7.1.1.1.3.1 TimetableFrame – Model Element

A set of timetable data (VEHICLE JOURNEYs, etc.) to which the same VALIDITY CONDITIONs have been assigned.

Table 1 – TimetableFrame – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> VersionFrame ::> TIMETABLE FRAME inherits from VERSION

FRAME.

«PK» id TimetableFrame-

IdType

1:1 Identifier of TIMETABLE FRAME.

VehicleModes VehicleModeEnum 0:* Reference to vehicle transport MODEs

TIMETABLE

HeadwayService xsd:xsd:boolean 0:1 Whether services of TIMETABLE are operated

a headway services.

Monitored xsd:xsd:boolean 0:1 Whether services of TIMETABLE are

monitored in real time.

«EV» NetworkView NetworkView 0:1 Reference to default NETWORK for

TIMETABLE and derived values of NETWORK.

13

«EV» LineView LineView 0:1 Reference to default LINE for TIMETABLE and

derived values of LINE.

«EV» OperatorView OrganisationView 0:1 Reference to default OPERATOR for

TIMETABLE and derived values of

OPERATOR.

«EV» ServiceCalendar-

FrameRef

ServiceCalendar-

FrameRef

0:1 Reference to default Service CALENDAR for

TIMETABLE.

«EV» DefaultMode VehicleModeEnum 0:1 Reference to default Transport MODE for

TIMETABLE.

«cntd» Journey-

AccountingRef

JourneyAccountingRef 0:1* Default JOURNEY ACCOUNTING values for

JOURNEYs in frame.

«cntd» bookingTimes AvailabilityCondition 0:* Times at which bookings can be made for the

services in the Timetable.

«cntd» timeDemandTypes TimeDemandType 0:* TIME DEMAND TYPEs in the frame.

«cntd» timeDemandType-

Assignments

TimeDemandType-

Assignment

0:* TIME DEMAND TYPE ASSIGNMENTS in the

frame.

«cntd» timingLinkGroups GroupOfLinks 0:* TIMING LINK GROUPs in the frame.

«cntd» vehicleJourneys Journey 0:* VEHICLE JOURNEYs & SERVICE

JOURNEYS s in the frame.

«cntd» frequencyGroups FrequencyGroup 0:* FREQUENCY GROUPs in the frame.

«cntd» groupsOfServices GroupOfServices 0:* GROUP OF SERVICEs in the frame.

«cntd» journeyPartCouples JourneyPartCouple 0:* JOURNEY PART COUPLEs in the frame.

«cntd» coupledJourneys CoupledJourney 0:* COUPLED JOURNEYs in the frame.

«cntd» serviceFacilitySets ServiceFacilitySet 0:* SERVICE FACILITY SETs in the frame.

«cntd» typesOfService TypeOfService 0:* TYPEs OF SERVICE in the frame.

«cntd» flexibleService-

Properties

FlexibleService-

Properties

0:* FLEXIBLE SERVICE PROPERTIES in the

frame.

«cntd» notices Notice 0:* NOTICEs in the frame.

«cntd» noticeAssignments NoticeAssignment 0:* NOTICE ASSIGNMENTs in the frame.

«cntd» journeyMeetings JourneyMeeting 0:* JOURNEY MEETINGs in the frame.

«cntd» journeyInterchanges Interchange 0:* JOURNEY FREQUENCY GROUPs in the

frame.

«cntd» interchangeRules InterchangeRule 0:* INTERCHANGE RULEs in the frame.

«cntd» journeyAccountings JourneyAccounting 0:* Default JOURNEY ACCOUNTING values for

JOURNEYs in frame.

TC 278 WI 00278308:2013 (E)

14

Timetable_VersionFrameStructure

A coherent set of timetable data (V EHIC LE JO URNEYs and

BLO C Ks) to which the same V A LIDITY C O NDITIO Ns

hav e been assigned.

TimetableFrame

(restriction)

type Timetable_VersionFrameStructure

attributes

C ommon Properties of an object managed by a responsible

O RGA NISA TIO N .

DataManagedObjectGroup

E lements of a V ERSIO N FRA ME.

VersionFrameGroup

E lements for a TIMETA BLE FRA ME.

TimetableVersionFrameGroup

A dditional descriptiv e properties of TIMETA BLE F RA ME.

TimetablePropertiesGroup

Modes of V EHIC LE JO URNEYs in timetable.

VehicleModes

0 1..

type VehicleModeListOfEnumerations

Whether this is a Headway SERV IC E, that is, one shown as

operating at a prescribed interv al rather than to a fixed

timetable.

HeadwayService

0 1..

type xsd:boolean

Whether V EHIC LE JO URNEYs of line are normally

monitored. Prov ides a default v alue for the Monitored

element on indiv idual journey s of the timetable.

Monitored

0 1..

type xsd:boolean

Default properties of elements in TIMETA BLE FRA ME. Use

these v alues on child elements if not specified on indiv idual

elements.

TimetableDefaultsGroup

E lements for use of TIME DEMA ND TYPE in a frame.

TimeDemandTypeInFrameGroup

TIME DEMA ND TYPEs in frame.

timeDemandTypes

0 1..

type timeDemandTypesInFrame_RelStr...

TIME DEMA ND TYPE A SSIGNMENTs in frame.

timeDemandTypeAssignments

0 1..

type timeDemandTypeAssignmentsInFr...

TIMING LINK GRO UPs in frame.

timingLinkGroups

0 1..

type groupOfLinksInFrame_RelStructure

Properties of journey s in TIMETA BLE FRA ME.

TimetableJourneyInFrameGroup

E lements for use of NO TIC Es in a frame.

NoticeAssignmentsInFrameGroup NO TIC Es in frame.

notices

0 1..

type noticesInFrame_RelStructure

NO TIC E A SS IGNMENTs in frame.

noticeAssignments

0 1..

type noticeAssignmentsInFrame_RelSt...

Properties of INTERC HA NGEs in TIMETA BLE FRA ME.

InterchangeInFrameGroup

JO URNEY MEETINGs in frame.

journeyMeetings

0 1..

type journeyMeetingsInFrame_RelStru...

INTERC HA NGES in frame.

journeyInterchanges

0 1..

type journeyInterchangesInFrame_Rel...

DEFA ULT INTERC HA NGES in frame.

defaultInterchanges

0 1..

type defaultInterchangseInFrame_RelS...

INTERC HA NGE RULEs in frame.

interchangeRules

0 1..

type interchangeRulesInFrame_RelStru...

E lements for a V EHIC LE TYPEs in frame.

VehicleTypeInFrameGroup

V EHIC LE TYPEs in frame.

vehicleTypes

0 1..

type vehicleTypesInFrame_RelStructure

E lements for a V EHIC LE TYPEs in frame.

JourneyAccountingInFrameGroup

V EHIC LE TYPEs in frame.

journeyAccountings

0 1..

type journeyAccountingsInFrame_RelS...

Figure 7 — TimetableFrame — XSD

15

TimetableFrameDefaultsGroup - Group


these v alues if not specified on indiv idual elements.

TimetableDefaultsGroup

S implified v iew of a NETWO RK.

NetworkView

type Netw ork_DerivedView Structure

S implified v iew of a LINE.

LineView

type Line_DerivedView Structure

S implified v iew of O PERA TO R. A ll data except the identifier

w ill be deriv ed through the relationship.

OperatorView

type Operator_DerivedView Structure

Reference to a SERV IC E C A LENDA R FRA ME.

ServiceCalendarFrameRef

type ServiceCalendarFrameRefStructure

Default V EHIC LE MO DE to use on JO URNEYs in

TIMETA BLE.

DefaultMode

type VehicleModeEnumeration

Reference to a JO URNEY A C C O UNTING.

JourneyAccountingRef

type JourneyAccountingRefStructure

When bookings can be made for a SERV IC E.

bookingTimes

type containedAvailabilityConditions_R...

Figure 8 — TimetableFrameDefaultsGroup — XSD

TC 278 WI 00278308:2013 (E)

16

TimetableJourneyInFrameGroup - Group

Properties of journey s in TIMETA BLE FRA ME.

TimetableJourneyInFrameGroup

V EHIC LE JO URNEYS in frame.

vehicleJourneys

type journeysInFrame_RelStructure

FREEWUENC Y GRO UPs In frame. C an be used to template V EHC ILE JO URNEYs

frequencyGroups

type frequencyGroupsInFrame_RelStr...

Groupings of Journey s In frame. C an be used to define

inbound and outbound beds for a matrix presentation of teh JO RUNEYs in the TIMETA BLE.

groupsOfServices

type groupsOfServicesInFrame_RelStr...

TRA IN NUMBERs in frame.

trainNumbers

type trainNumbersInFrame_RelStructure

JO URNEY C O UPLINGs in frame.

journeyPartCouples

type journeyPartCouplesInFrame_RelSt...

JO URNEY C O UPLINGs in frame.

coupledJourneys

type coupledJourneysInFrame_RelStru...

SERV IC E FA C ILITIES in frame.

serviceFacilitySets

type serviceFacilitySetsInFrame_RelSt...

TYPES of SERV IC E in frame.

typesOfService

type typesOfServiceInFrame_RelStruc...

F LEXIBLE SERV IC E PRO PERTIES in frame..

flexibleServiceProperties

type f lexibleServicePropertiesInFrame...

Figure 9 — TimetableJourneyInFrameGroup — XSD

7.2 Journey and Journey Times

The JOURNEY and JOURNEY TIMEs model exchanges planned services and dead runs and their timings.

7.2.1 Vehicle Journey

7.2.1.1 VEHICLE JOURNEY – Conceptual MODEL

NOTE The following explanations use excerpts from Transmodel.

The daily operation of a vehicle is described by VEHICLE JOURNEYs. A VEHICLE JOURNEY is the defined movement of a vehicle using a specified JOURNEY PATTERN on a particular ROUTE. This movement is hence made between the first and the last POINTs IN JOURNEY PATTERN. Being defined for a DAY TYPE, a VEHICLE JOURNEY is a class of journeys that would take place at the same time on each day of a specific DAY TYPE.

17

7.2.1.1.1 Basic Vehicle Journey – Conceptual MODEL

There are two different main types of VEHICLE JOURNEYs: passenger-carrying SERVICE JOURNEYs and non-service DEAD RUNs.

A SERVICE JOURNEY is a VEHICLE JOURNEY on which passengers will be allowed to board or alight from vehicles at stops. These journeys are usually published and known by passengers.

A DEAD RUN may be necessary for the vehicle to proceed, from the PARKING POINT it was parked at, to the first STOP POINT of the JOURNEY PATTERN where it will start its service operation. On the opposite direction, a DEAD RUN may relate the last STOP POINT the vehicle has stopped at (finishing its service) to the PARKING POINT where it will be parked. A DEAD RUN may also occur when a vehicle changes from one ROUTE to another one in order to continue its service there, or for other various reasons.

class NeTEx TM TP Vehicle Journey Basic MODEL

DEAD RUN

+ DeadRunType

«PK»

+ id

VEHICLE JOURNEY

+ DepartureTime

+ JourneyDuration [o..1]

«PK»

+ id

Serv ice Calendar

MODEL::DAY TYPE

LINK SEQUENCE

Journey Pattern MODEL::

JOURNEY PATTERN

POINT IN LINK SEQUENCE


TIMING POINT IN JOURNEY

PATTERN

Serv ice Journey MODEL::

SERVICE JOURNEY

+ ServiceAlteration [0..1]

+ DirectionType

+ Print [0..1]

+ Dynamic [0..1]

«PK»

+ id

Name: NeTEx TM TP Vehicle Journey Basic MODEL

Author: NeTEx

Version: 1.0

Created: 16/03/2010 12:40:40

Updated: 03/10/2012 15:40:14

POINT

Timing Pattern MODEL::TIMING POINT

JOURNEY

+ Name [0..1]

+ Description [0..1]

«PK»

~ id

+worked

on*

+for

1..*

+made using*

+for

1

+the timing reference

for

1

+by default timed

from

0..1

+viewed

as

1

+a view

of

*

+timed

from

*


for0..1

Figure 10 — Basic Vehicle Journey – Conceptual MODEL (UML)

7.2.1.1.2 Vehicle Journey Details – Conceptual MODEL

A VEHICLE JOURNEY may be further defined by a number of other elements, as shown in the following figure. These include interactions with other journeys (JOURNEY PART, JOURNEY MEETING, etc.); temporal and other conditions (DAY TYPE, VALIDITY CONDITION); further descriptive and classification information (TRAIN NUMBER, PRODUCT CATEGORY, TYPE OF SERVICE, stops etc., ); and operational data (BLOCK).

A TEMPLATE JOURNEY allows a set of VEHICLE JOURNEYs to be defined that follow a common temporal pattern – See FREQUENCY GROUPs below.

TC 278 WI 00278308:2013 (E)

18

class NeTEx TM TP Vehicle Journey MODEL

Interchange

MODEL::DEFAULT

INTERCHANGE

DEAD RUN

+ DeadRunType

«PK»

+ id

Interchange

MODEL::JOURNEY

MEETING

Coupled Journey

MODEL::JOURNEY

PART

VEHICLE JOURNEY

+ DepartureTime

+ JourneyDuration [o..1]

«PK»

+ id

POINT

Serv ice Pattern

MODEL::SCHEDULED

STOP POINT

Serv ice Calendar

MODEL::DAY TYPE

LINK SEQUENCE


JOURNEY PATTERN




PATTERN

Name: NeTEx TM TP Vehicle Journey MODEL

Author: NeTEx

Version: 1.0

Created: 16/03/2010 12:53:31

Updated: 01/10/2012 19:03:58

Serv ice Journey

MODEL::SERVICE

JOURNEY

Vehicle Serv ice MODEL::BLOCK

Facility MODEL::

FACILITY

FACILITY SET

Facility MODEL::

SERVICE

FACILITY SET

SITE

Stop Place MODEL::

STOP PLACE

STOP PLACE SPACE

Stop Place MODEL::QUAY

Stop Assignment MODEL::STOP ASSIGNMENT

JOURNEY

+ Name [0..1]


«PK»

~ id

Generic Validity

MODEL::VALIDITY

CONDITION

TYPE OF SERVICE

«PK»

+ id

TEMPLATE VEHICLE

JOURNEY

«PK»

+ id [0..1]

Transport Organisations

MODEL::OPERATIONAL

CONTEXT

Serv ice Journey

MODEL::TEMPLATE

SERVICE JOURNEY

TRAIN NUMBER

+ ForAdvertisement

+ ForProduction


«PK»

+ id

Accessibility MODEL::

ACCESSIBILITY

ASSESSMENT

TYPE OF

PRODUCT

CATEGORY

«PK»

+ id

+the classification for

0..1

+classified as

*

+classified

as

0..*

+a classi fication for

0..1

+part of 1..*

+comprises 0..1

+for0..*

+to 1

+in 0..*

+containing1

0..*

neighbour

of

0..*

+for 0..*

+to 0..1

+for

0..*

+made using

0..1

+applicable for 0..*

+for 0..*

+applicable for0..*

+characterized by

0..1

+characterized by 0..*

+characterizing 0..*

+characterized by0..*

+characterizing 0..1

+characterized by0..1

+characterizing 0..1

0..* subzone

of

1

+including

0..1

+in

*

+for 0..*

+made using 0..1

+subdivided

in1

+part

of

*

+identifying

0..1+identified by

0..*

+for 1

+worked on *

+combining *

+combined

in

*

+start

of

1

+from*

+for 0..*

+to 1

+to

*

+end

of

1

+concerning*

+concerned

by

1..*

+worked

on *

+for

1..*

+made using

*

+for 1

+the timing

reference for

1

+by default timed

from

0..1

+timed

from

*


for

0..1

+identifying 0..* +identified by0..*

Figure 11 — Vehicle Journey – Conceptual MODEL (UML)

7.2.1.2 Vehicle Journey – Physical Model

The VEHICLE JOURNEY physical model adds detailed attributes for VEHICLE JOURNEYs.

19

class XSD NeTEx TP Vehicle Journey Model

DataManagedObject

VehicleJourneyModel::TrainNumber

ForAdvertisement :normalizedString [0..1]

ForProduction :normalizedString [0..1]

Description :Multi l ingualString [0..1]

«PK»

id :TrainNumberIdType

DataManagedObject

InterchangeModel::DefaultInterchange

DataManagedObject


DataManagedObject

CoupledJourneyModel::JourneyPart

TypeOfValue



VersionFrame


Name: XSD NeTEx TP Vehicle Journey Model

Author: NeTEx

Version: 1.0

Created: 25/11/2009 14:35:57

Updated: 02/08/2012 14:55:54

VehicleJourneyModel::DeadRun

DirectionType :DirectionTypeEnum [0..1]

DeadRunType :DeadRunTypeEnum [0..1]

«PK»

id :DeadRunIdType

«FK»

OperatorRef :OperatorRef* [0..1]

LineRef :LineRef* [0..1]

«contained»

groupsOfServices :GroupOfService [0..*]

trainNumbers :TimeDemandTypeRef* [0..*]

Origin :JourneyEndpoint [0..1]

Destination :JourneyEndpoint [0..1]

calls :DeadRunCall [0..*] {ordered}


DepartureTime :time

JourneyDuration :duration [0..1]

«PK»

id :VehicleJourneyIdType

«contained»

Frequency :JourneyFrequency [0..1]

dayTypes :DayTypeRef* [0..*]

timeDemandTypes :TimeDemandTypeRef* [0..*]

parts :JourneyPart [0..*]

noticeAssignments :NoticeAssignmentView [0..*]

waitTimes :VehicleJourneyWaitTime [0..*]

runTimes :VehicleJourneyRunTime [0..*]

layovers :VehicleJourneyLayover [0..*]

passingTimes :TimetabledPassingTime [0..*]

pointsInSequence :PointInSequence [0..*]

«FK»

RouteRef :RouteRef* [0..1]

JourneyPatternRef :JourneyPatternRef* [0..1]

TimeDemandTypeRef :TimeDemandTypeRef* [0..1]

TimingAlgorithmRef :TimingAlgorithmRef* [0..1]

FrequencyGroupRef :JourneyFrequencyGroupIdType* [0..1]

VehicleTypeRef :VehicleTypeRef* [0..1]

OperationalContextRef :VehicleTypeRef* [0..1]

BlockRef :BlockRef* [0..1]

CourseOfJourneysRef :CourseOfJourneysRef* [0..1]

«AK»

PublicCode :normalizedString [0..1]


JourneyPatternModel::


LinkSequence

JourneyPatternModel::JourneyPattern

DataManagedObject


DayType

TimingPoint

Serv icePatternModel::ScheduledStopPoint

«enumeration»

VehicleJourneyValues::

ReasonForMeetingEnum

splitting

other

joining

DataManagedObject

VehicleServ iceModel::Block

TypeOfValue

«XmlImplementAs...

FacilityModel::Facility

FacilitySet

FacilityModel::

Serv iceFacilitySet

DataManagedObject

TimeDemandTypeModel::

TimeDemandType

«enumeration»

VehicleJourneyValues::

DeadRunTypeEnum

GarageRunOut

GarageRunIn

TurningManoeuvre

Other

GroupOfEntities



ServiceJourney


Serv iceJourneyModel::TemplateServ iceJourney

«PK»

id :TemplateServiceJourneyIdType [0..1]

ValidityCondition

Av ailabilityConditionModel::Av ailabilityCondition


JourneyFrequency

LinkSequence

VehicleJourneyModel::Journey


TransportMode :VehicleModeEnum [0..1]

TransportSubmode :TransportSubMode [0..1]

ExternalVehicleJourneyRef :normalizedString*

«PK»

id :JourneyIdType

«FK»

TypeOfProductCategoryRef :TypeOfProductCategoryRef* [0..1]

TypeOfServiceRef :TypeOfServiceRef* [0..1]

LinkSequenceProjectionRef :LinkSequenceProjectionRef* [0..1]

«contained»

journeyAccountings :JourneyAccounting [0..*]

Accessibil ity :Accessibil ityAssessment [0..1]

VersionedChild

AccessibilityModel::AccessibilityAssessment

concerning *

concerned by1..*

used by

0..*

uses

0..*

timed from *

timing reference for

0..1


1

by default timed from

0..1

made using *

for 1

on 0..*

day type

worked on

*

for

1

as

0..1

assessed

valid 0..*

day 0..1

0..*

combines from 1

to *

end of 1

facil ity

1..*

comprises

runs on

0..*

composed of

1..*

runs on

0..1

defines

1..*

is defined by1..*

faci l ies

for

causing 1

caused by 1..*

0..1

0..*

subdivided in

1

{ordered}

part of *

booking times

used by default by0..1

made using

*

valid for

*

comprising

0..1

including

0..1

in

*

combining

0..*

combined in 1

identified by

0..*

identifies

0..*

start of 1

from *

Figure 12 — Vehicle Journey – Physical Model (UML)

TC 278 WI 00278308:2013 (E)

20

7.2.1.3 Vehicle Journey – Attributes and XSD

7.2.1.3.1 Journey – Model Element

JOURNEY defines common properties of a journey, such as TYPE OF SERVICE, JOURNEY ACCOUNTING, etc.

Table 2 – Journey – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> LinkSequence ::> JOURNEY inherits from LINK SEQUENCE.

«PK» id JourneyIdType 1:1 Identifier of JOURNEY.

Description MultilingualString 0:1 Description of JOURNEY.

TransportMode VehicleModeEnum 0:1 Transport MODE of JOURNEY.

TransportSubmod

e

TransportSubmode 0:1 Transport Sub MODE of JOURNEY.

«AK» ExternalJourney-

Ref

ExternalObjectRef 0:1 An alternative code that uniquely identifies the

JOURNEY, specifically for use in AVMS

systems.

NOTE For VDV compatibility.

«FK» TypeOfProduct-

CategoryRef

TypeOfProductCategoryR

ef

0:1 PRODUCT CATEGORY of a JOURNEY.

«FK» TypeOfServiceRef TypeOfServiceRef 0:1 TYPE OF SERVICE of JOURNEY.

«FK» a LinkSequence

ProjectionRef

LinkSequenceProjectionR

ef

0:1 Reference to LINK SEQUENCE PROJECTION

to use to PROJECT JOURNEY onto map, etc.

b LinkSequence

Projection

LinkSequenceProjection 0:1 LINK SEQUENCE PROJECTION to use to

PROJECT JOURNEY onto map, etc.

«cntd» journeyAccountin

gs

JourneyAccounting 0:* JOURNEY ACCOUNTINGs that apply of

JOURNEY.

21

Journey_VersionStructure

C ommon proerties of a JO URNEY.

Journey

(extension)

type Journey_VersionStructure

attributes


O RGA NISA TIO N.


Elements for a LINK SEQ UENC E.

LinkSequenceGroup

Elements for a JO URNEY.

JourneyGroup

Text description of a JO URNEY.

Description

type MultilingualString

Mode of transport of JO URNEY.

TransportMode

type AllVehicleModesOfTransportEnumeration

A submode of a Public Transport MO DE.

TransportSubmode

type TransportSubmodeStructure

A n alternativ e code that uniquely identifies the JO URNEY.

Specifically for use in A V MS sy stems. F or V DV compatibility .

ExternalVehicleJourneyRef

type ExternalObjectRefStructure

Reference to a TYPE O F PRO DUC T C A TEGO RY. P roduct

of a JO URNEY. e.g. IC S, Thales etc

See ERA B.4 7037 C haracteristic description code.

TypeOfProductCategoryRef

type TypeOfProductCategoryRefStructure

Reference to a TYPE O F SERV IC E.

TypeOfServiceRef

type TypeOfServiceRefStructure

Reference to a LINK SEQ UENC E PRO JEC TIO N.

LinkSequenceProjectionRef

type LinkSequenceProjectionRefStructure

A Projection of a whole LINK SEQ UENC E as an ordered series of PO INTs.

LinkSequenceProjection

type LinkSequenceProjection_VersionStructure

JO URNEY A C C O UNTING to be used to attribute

JO URNEY costs.

journeyAccountings

type journeyAccountings_RelStructure

Figure 13 — Journey — XSD

7.2.1.3.2 VehicleJourney – Model Element

The planned movement of a public transport vehicle on a DAY TYPE from the start point to the end point of a JOURNEY PATTERN on a specified ROUTE.

Table 3 – VehicleJourney – Element

Classifi

cation

Name Type Cardi

nality

Description

::> ::> Journey ::> VEHICLE JOURNEY inherits from JOURNEY.

«PK» id VehicleJourney IdType 1:1 Identifier of VEHICLE JOURNEY.

DepartureTime xsd:time 1:1 Departure time of VEHICLE JOURNEY.

JourneyDuration xsd:duration 0:1 Duration of VEHICLE JOURNEY.

«cntd» Frequency JourneyFrequency 0:* Headway frequencies for VEHICLE JOURNEY.

TC 278 WI 00278308:2013 (E)

22

«FK» Frequency-

GroupRef

JourneyFrequency-

GroupRef

0:1 FREQUENCY GROUP of VEHICLE JOURNEY.

«FK» DayTypeRef DayTypeRef 1:* Reference to DAY TYPE on which VEHICLE

JOURNEY runs.

«FK» RouteRef RouteRef 0:1 Reference to ROUTE on which VEHICLE

JOURNEY runs.

«FK» JourneyPattern-

Ref

JourneyPatternRef 0:1 Reference to JOURNEY PATTERN over which

VEHICLE JOURNEY runs.

«FK» TimeDemandRef TimeDemandTypeRef 0:1 Reference to TIME DEMAND TYPE during which

VEHICLE JOURNEY starts.

«FK» Timing-

AlgorithmRef

TimingAlgorithmRef 0:1 Reference to TIMING ALGORITHM to use to

compute passing times for VEHICLE JOURNEY.

«FK» BlockRef BlockRef 0:1 Reference to BLOCK under which VEHICLE

JOURNEY runs.

«AK» PublicCode xsd:normalizedString 0:1 Public Code for VEHICLE JOURNEY.

«cntd» layovers VehicleJourneyLayover 0:* LAYOVERs for VEHICLE JOURNEY.

«cntd» waitTimes VehicleJourneyWaitTime 0:* WAIT TIMEs for VEHICLE JOURNEY.

«cntd» runTimes VehicleJourneyRunTime 0:* RUN TIMEs for VEHICLE JOURNEY.

«cntd» passingTimes TimetabledPassingTime 0:* TIMETABLED PASSING TIMEs for VEHICLE

JOURNEY.

«cntd» timeDemand-

Types

TimeDemandTypeRef 0:* TIME DEMAND TYPEs referenced by VEHICLE

JOURNEY.

«cntd» parts JourneyPart 0:* JOURNEY PARTs for VEHICLE JOURNEY.

«cntd» notice-

Assignments

NoticeAssignmentView 0:* NOTICE ASSIGNMENTs that apply to

JOURNEY.

«cntd» pointsInSequence PointInSequence 0:* POINTs in SEQUENCE for VEHICLE JOURNEY.

VehicleJourney_VersionStructure

The planned mov ement of a public transport v ehicle on a

DA Y TYPE from the start point to the end point of a

JO URNEY PA TTERN on a specified RO UTE.

VehicleJourney

(restriction)

type VehicleJourney_VersionStructure

attributes


O RGA NISA TIO N.


E lements for a LINK SEQ UENC E.

LinkSequenceGroup


JourneyGroup

E lements for V EHIC LE JO URNEY.

VehicleJourneyGroup E lements for V EHIC LE JO URNEY.

VehicleJourneyPropertiesGroup

Time Elements for V EHIC LE JO URNEY.

VehicleJourneyTimesGroup

Figure 14 — VehicleJourney — XSD

23

7.2.1.3.2.1 VehicleJourneyReferencesGroup - Group

Elements for associations of V EHIC LE JO URNEY w ith other

entities.

VehicleJourneyReferencesGroup

DA Y TYPEs for Journey .

dayTypes

type dayTypeRefs_RelStructure

Reference to a RO UTE.

RouteRef

type RouteRefStructure

Reference to a JO URNEY PA TTERN.

JourneyPatternRef

type JourneyPatternRefStructure

Reference to a DEA D RUN JO URNEY PA TTERN.

DeadRunJourneyPatternRef

type DeadRunJourneyPatternRefStruct...

Reference to a SERV IC E JO URNEY PA TTERN.

ServiceJourneyPatternRef

type ServiceJourneyPatternRefStructure

Reference to a SERV IC E PA TTERN.

ServicePatternRef

type ServicePatternRefStructure

Reference to a TIME DEMA ND TYPE used at start of

JO URNEY.

TimeDemandTypeRef

type TimeDemandTypeRefStructure

Reference to a TIMING A LGO RITHM TYPE.

TimingAlgorithmTypeRef

type TimingAlgorithmTypeRefStructure

Reference to a JO URNEY FREQ UENCY GRO UP.

JourneyFrequencyGroupRef

type JourneyFrequencyGroupRefStru...

Reference to a HEA DWA Y JO URNEY GRO UP.

Headw ayJourneyGroupRef

type Headw ayJourneyGroupRefStruct...

Reference to a RHYTHMIC A L JO URNEY GRO UP.

RhythmicalJourneyGroupRef

type RhythmicalJourneyGroupRefStru...

Reference to a V EHIC LE TYPE.

VehicleTypeRef

type VehicleTypeRefStructure

Reference to an O PERA TIO NA L C O NTEXT.

OperationalContextRef

type OperationalContextRefStructure

Reference to a BLO C K.

BlockRef

type BlockRefStructure

Reference to a TRA IN BLO C K.

TrainBlockRef

type TrainBlockRefStructure

Reference to a C O URSE O F JO URNEYS (Run).

CourseOfJourneysRef

type CourseOfJourneysRefStructure

Public code for JO URNEY.

PublicCode

type xsd:normalizedString

Figure 15 — VehicleJourneyReferencesGroup — XSD

TC 278 WI 00278308:2013 (E)

24



WA IT TIMEs for V EHIC LE JO URNEY at different TIMING

PO INTs.

waitTimes

type vehicleJourneyWaitTimes_RelStru...

Run times for V EHIC LE JO URNEY ov er different TIMING

LINKs.

runTimes

type vehicleJourneyRunTimes_RelStru...

LA YO V ER times for V EHIC LE JO URNEY.

layovers

type vehicleJourneyLayovers_RelStru...

PA SSING TIMEs for V EHIC LE JO URNEY.

passingTimes

type timetabledPassingTimes_RelStruc...

Figure 16 — VehicleJourneyTimesGroup — XSD

7.2.1.3.3 DeadRun – Model Element

A non-service VEHICLE JOURNEY.

Table 4 – DeadRun – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> VehicleJourney ::> DEAD RUN inherits from VEHICLE JOURNEY.

«PK» id DeadRunIdType 1:1 Identifier of DEAD RUN.

«FK» VehicleTypeRef VehicleTypeRef 0:1 Reference to TYPE OF VEHICLE to use on of

SERVICE JOURNEY.

«EV» OperatorRef OrganisationRef 0:1 Reference to OPERATOR of SERVICE

JOURNEY.

«EV» LineRef LineRef 0:1 Reference to LINE of SERVICE JOURNEY.

DirectionType DirectionTypeEnum 0:1 Type of DIRECTION.

«cntd» groupsOfServices GroupOfServices 0:* GROUP OF SERVICEs to which DEAD RUN

belongs.

«cntd» trainNumbers TrainNumber 0:* TRAIN NUMBERs associated with DEAD RUN.

«cntd» Origin JourneyEndpoint 0:1 Origin of DEAD RUN.

«cntd» Destination JourneyEndpoint 0:1 Destination of DEAD RUN.

DeadRunType DeadRunTypeEnum 1:1 Type of DEAD RUN.

«cntd» calls DeadRunCall 0:* CALLs making up DEAD RUN.

25

DeadRunWithCalls_VersionStructure

A non-serv ice V EHIC LE JO URNEY.

DeadRun

(restriction)

type DeadRunWithCalls_VersionStruct...

attributes

C ommon P roperties of an object managed by a responsible

O RGA NISA TIO N.


Elements for a LINK SEQ UENC E.

LinkSequenceGroup


JourneyGroup

Elements for V EHIC LE JO URNEY.

VehicleJourneyGroup

Elements for DEA D RUN.

DeadRunGroup

Reference Elements for a SERV IC E JO URNEY, including

additional deriv ed data.

DeadRunReferencesGroup

Elements for origin and destination of DEA D RUN C an be

deriv ed from the Pattern. Must not contradict the JO URNEY

PA TTERN.

DeadRunEndpointsGroup O rigin for DEA D RUN. C an be Deriv ed from JO RUNEY

PA TTERN.

Origin

0 1..

type DeadRunEndpointStructure

Destination for DEA D RUN. C an be deriv ed from

JO RUNEY PA TTERN.

Destination

0 1..

type DeadRunEndpointStructure

Ty pe of DEA D RUN

DeadRunType

0 1..

type DeadRunTypeEnumeration

Elements for DEA D RUN.

DeadRunWithCallsGroup

C omplete sequence of stops along the route path, in calling

order.

calls

0 1..

type deadRunCalls_RelStructure

Figure 17 — DeadRun — XSD

7.2.1.3.3.1 DeadRunReferencesGroup — Group

Elements for a DEA D RUN.,

including additional deriv ed data.

DeadRunReferencesGroup

Reference to an O PERA TO R.

OperatorRef

type OperatorRefStructure

substGrp TransportOrganisationRef

Reference to a LINE.

LineRef

type LineRefStructure

substGrp VersionOfObjectRef

A Direction as one of a restricted set of

v alues.

DirectionType

type DirectionTypeEnumeration

default outbound

GRO UPS O F SERV IC Es to which a DEA D

RUN belongs.

groupsOfServices

type groupOfServicesRefs_RelStru...

TRA IN NUMBERs -= deriv ed through

JO URNEY PA RTs of a JO URNEY - for a

multi-part JO URNEY only .

trainNumbers

type trainNumberRefs_RelStructure

Figure 18 — DeadRunReferencesGroup — XSD

TC 278 WI 00278308:2013 (E)

26

7.2.1.3.3.1 DeadRunType – Allowed values

The following figure shows the allowed values for DeadRunType (DeadRunTypeEnum).

Table 5 – DeadRunType – Allowed values

Value Description

garageRunOut Garage run out

garageRunIn Garage run in

turningManoeuvre Turning manoeuvre

other Other

7.2.1.3.4 TemplateVehicleJourney – Model Element

A repeating VEHICLE JOURNEY for which a frequency has been specified, either as a HEADWAY JOURNEY GROUP (e.g. every 20 minutes) or a RYTHMICAL JOURNEY GROUP (e.g. at 15, 27 and 40 minutes past the hour) has been specified. It may thus represent multiple journeys or it could also be used simply as a template for adding single extra DATED VEHICLE JOURNEYs after the planning phase.

The frequency of the journey could be defined by a FREQUENCY GROUP. See later.

The TEMPLATE VEHICLE JOURNEY of a RYTHMICAL JOURNEY GROUP needs passing times, where only the minute part is meaningful (passing times are repeated every hour with the same minutes), therefore the hour part of passing times will be ignored (a "00" value is recommended)

Table 6 – TemplateVehicleJourney – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> Journey ::> TEMPLATE VEHICLE JOURNEY inherits from

JOURNEY.

«PK» id TemplateVehicle-

JourneyIdType

0:1 Identifier of TEMPLATE VEHICLE JOURNEY.

TemplateVehicle-

JourneyType

TemplateVehicle-

JourneyTypeEnum

0:1 Type of TEMPLATE VEHICLE JOURNEY.

«cntd» frequencyGroups JourneyFrequencyGroup 0:* FREQUENCY GROUPs defining TEMPLATE

VEHICLE JOURNEY.

27

TemplateVehicleJourney_VersionStructure

A repeating V EHIC LE JO URNEY for w hich a frequency has

been specified, either as a HEA DWA Y JO URNEY GRO UP

(e.g. ev ery 20 minutes) or a RHYTHMIC A L JO URNEY

GRO UP (e.g. at 15, 27 and 40 minutes past the hour). It

may thus represent multiple journey s.


(restriction)

type TemplateVehicleJourney_VersionStructure

attributes


O RGA NISA TIO N.



LinkSequenceGroup

E lements for a JO URNEY.

JourneyGroup

E lements for TEMPLA TE V EHIC LE JO URNEY.

TemplateVehicleJourneyGroup Type of TEMPLA TE V EHIC LE JO URNEY.

TemplateVehicleJourneyType

0 1..

type TemplateVehicleJourneyTypeEnumeration

frequency groups defining Template journey . C an only be of

one ty pe.

frequencyGroups

0 1..

type frequencyGroups_RelStructure

Figure 19 — TemplateVehicleJourney — XSD

7.2.1.3.4.1 TemplateVehicleJourneyType – Allowed values

The following table shows the allowed values for TemplateVehicleJourneyType (TemplateVehicleJourneyTypeEnum).

Table 7 – TemplateVehicleJourneyType – Allowed values

Value Description

headway Journeys run at intervals

rhythmic Journeys run according to a pattern of start

times.

other Other

7.2.1.3.5 TypeOfService – Model Element

A classification for VEHICLE JOURNEYs and SPECIAL SERVICEs to express some common properties of journeys to be taken into account in the scheduling and/or operations control process.

Table 8 – TypeOfService – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> TypeOfEntity ::> TYPE OF SERVICE inherits from TYPE OF

ENTITY.

«PK» id TypeOfServiceIdType 1:1 Identifier of TYPE OF SERVICE.

TC 278 WI 00278308:2013 (E)

28

TypeOfServiceStructure

C lassification of a Serv ice.

TypeOfService

(restriction)

type TypeOfServiceStructure

attributes


O RGA NISA TIO N.


E lements for TYPE O F V A LUE.

TypeOfValueGroup

Figure 20 — TypeOfService — XSD

7.2.1.3.6 TypeOfProductCategory – Model Element

A classification for VEHICLE JOURNEYs to express some common properties of journeys for marketing and fare products.

Table 9 – TypeOfProductCategory – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> TypeOfValue ::> TYPE OF PRODUCT CATEGORY inherits from

TYPE OF VALUE.

«PK» id TypeOfProductCategoryeIdType 1:1 Identifier of TYPE OF PRODUCT CATEGORY.

7.2.1.3.7 TrainNumber – Model Element

Specification of codes assigned to particular VEHICLE JOURNEYs when operated by TRAINs of COMPOUND TRAINs according to a functional purpose (passenger information, operation follow-up, etc.).

Table 10 – TrainNumber – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> TIME DEMAND PROFILE inherits from DATA

MANAGED OBJECT

«PK» id TrainNumberIdType 1:1 Identifier of TRAIN NUMBER.

ForAdvertisement xsd:normalizedString 0:1 TRAIN NUMBER to use for advertisement to public

if different from ID.

ForProduction xsd:normalizedString 0:1 TRAIN NUMBER to use for production purposes, for

instance towards technical systems that require an

odd or even value according to safety regulations, if

different from ID.

Description MultilingualString 0:1 Description of TRAIN NUMBER.

29

TrainNumberStructure

Specification of codes assigned to particular V EHIC LE

JO URNEYs when operated by TRA INs of C O MPO UND

TRA INs according to a functional purpose (passenger information, operation follow-up, etc).

TrainNumber

(restriction)

type TrainNumberStructure

attributes

C ommon Properties of an object managed by a responsible O RGA NISA TIO N.


E lements for TRA IN NUMBER Group.

TrainNumberGroup

Description of TRA IN NUMBER.

Description

0 1..


TRA IN NUMBER to use w hen adv ertising Train -If different

from Id.

ForAdvertisement

0 1..


TRA IN NUMBER to use for production -If different from

Id.

ForProduction

0 1..


Figure 21 — TrainNumber — XSD

7.2.1.3.8 JourneyDesignator – Model Element

A set of descriptive attributes of a JOURNEY other than its identifier that may be used to identify it. This is of use when describing journeys from a foreign system for which the identifiers are not known

Table 11 – JourneyDesignator – Element

Classifi

cation

Name Type Cardin-

ality

Description

«FK» FromPointRef TimingPointRef 0:1 Origin TIMING POINT to use to identify a

JOURNEY.

«FK» ToPointRef TimingPointRef 0:1 Destination TIMING POINT to use to identify

JOURNEY.

DepartureTime xsd:time 0:1 Departure time of VEHICLE JOURNEY from origin

point.

ArrivalTime xsd:time 0:1 Arrival time of VEHICLE JOURNEY at destination

point.

«AK» Alternative-

JourneyRef

xsd:normalizedString 0:1 Alternative identifier of JOURNEY. May possibly be

unique only in a limited context.

«FK» DayTypeRef DayTypeRef 0:1 DAY TYPE to use to identify JOURNEY.

TC 278 WI 00278308:2013 (E)

30

JourneyDesignatorStructure

V alue reference to a SERV IC E JO URNEY. P rov ides an

alternativ e way of identify ing a Journey .

JourneyDesignator

type JourneyDesignatorStructure

O rigin of Journey .

FromPointRef

type TimingPointRefStructure

Destination of Journey .

ToPointRef


E lements for a Designator

DesignatorGroup

Date of JO URNEY.

Date

type xsd:date

Time of departure of JO URNEY from PO INT.

DepartureTime

type xsd:time

Day a offset if T ime of departure of JO URNEY from origin

PO INT from current O PERA TING DA Y .

DepartureDayOffset

type xsd:integer

Time of arriv al of JO URNEY at destination PO INT.

ArrivalTime

type xsd:time

Day a offset if T ime of arriv al of JO URNEY at destination

PO INT.

ArrivalDayOffset

type xsd:integer

Reference to a DA Y TYPE.

DayTypeRef

type DayTypeRefStructure


LineRef


Reference to a DIREC TIO N.

DirectionRef

type DirectionRefStructure

A lternativ e ID fro journey .

AlternativeJourneyRef


Figure 22 — JourneyDesignator — XSD

7.2.1.4 XML Examples of Vehicle Journey

See SERVICE JOURNEY for examples of a VEHICLE JOURNEY.

7.2.1.4.1 Dead Run XML Example with passing times and calls

The following code fragment shows a DEAD RUN to position a vehicle at the first stop of a service.

For EXAMPLE

<DeadRun version="any" id="xj:dr_L24_01o">

<Name>1st Dead Run out from Garage in Day service</Name>

<DepartureTime>11:00:00.0Z</DepartureTime>

<dayTypes>

<DayTypeRef version="any" ref="xj:DT_01"/>

</dayTypes>

<RouteRef version="any" ref="kx:rt_24o"/>

31

<DeadRunJourneyPatternRef version="any" ref="kx:drjp_L24_01o"/>

<BlockRef version="any" ref="ops:blk_L24_01"/>

<passingTimes>

<TimetabledPassingTime id="kx:tpt_dr_L24_01o_001">

<TimingPointInJourneyPatternRef version="any" ref="kx:pijp_drjp_L24_01o_001"/>


</TimetabledPassingTime>

<TimetabledPassingTime id="kx:tpt_dr_L24_01o_002">

<StopPointInJourneyPatternRef version="any" ref="kx:pijp_drjp_L24_01o_002"/>

<ArrivalTime>11:10:00.0Z</ArrivalTime>

<WaitingTime>PT5M</WaitingTime>


</passingTimes>

<DirectionType>outbound</DirectionType>

<Origin>

<PointRef version="any" ref="mybus:grgpt1"/>

</Origin>

<Destination>

<PointRef version="any" ref="mybus:ssp_001"/>

</Destination>

<DeadRunType>garageRunOut</DeadRunType>

</DeadRun>

7.2.2 Service Journey

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

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 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 it covers. The proposed VEHICLE TYPE will preferably 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 entity 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 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.

TC 278 WI 00278308:2013 (E)

32

class NeTEx TM TP Serv ice Journey MODEL

GROUP OF SERVICES

+ DirectionType

«PK»

+ id

SERVICE JOURNEY

+ ServiceAlteration [0..1]

+ DirectionType

+ Print [0..1]

+ Dynamic [0..1]

«PK»

+ id

JOURNEY

SPECIAL SERVICE

+ StartTime

+ EndTime [0..1]

+ Client

«PK»

+ id

Vehicle Journey MODEL::

TYPE OF SERVICE

LINK SEQUENCE

Journey Pattern MODEL::JOURNEY PATTERN

Vehicle Type MODEL::VEHICLE TYPE

Name: NeTEx TM TP Service Journey MODEL

Author: NeTEx

Version: 1.0

Created: 16/03/2010 13:08:11

Updated: 27/03/2012 16:15:52

JOURNEY

Vehicle Journey MODEL::VEHICLE

JOURNEY

Journey Pattern Times

MODEL::VEHICLE TYPE

PREFERENCE

Serv ice Pattern MODEL::SERVICE

JOURNEY PATTERN

Interchange MODEL::SERVICE

JOURNEY INTERCHANGE

Interchange MODEL::SERVICE

JOURNEY PATTERN

INTERCHANGE

Interchange

MODEL::

INTERCHANGE

POINT

Serv ice Pattern

MODEL::

SCHEDULED STOP

POINT

Facility MODEL::

FACILITY

FACILITY SET

Facility MODEL::SERVICE FACILITY SET

Check Constraint

MODEL::CHECK

CONSTRAINT

TEMPLATE VEHICLE JOURNEY

TEMPLATE SERVICE JOURNEY

«PK»

+ id [0..1]

+part of

1..*+comprises0..1

+to *

+end of

1

+to *

+end of 1

+start of

1

+from

*

+start of

1

+from *

+start of 1

+from *

+start of1

+from * +to

*

+end of 1

+affected by

0..1

+a process for

0..*

+used to define 1

+for

*

+proposed for

0..1

+made

using

*

+using *

+proposed

for 0..1+operated by

0..*

+requested for 0..*

+present

at

0..*

+comprising

0..1

+made up of

0..1

+included in

*

+made using

*

+for

1

+made up

of0..1

+in

1..*

+the classification

for

0..1

+classified

as

*

+for 0..1

+described

by

*

+to *

+end of 1

+for

0..*

+made using

0..1

+specified by 1

+for *

Figure 23 — Service Journey – Conceptual MODEL (UML)

7.2.2.2 Special Services

Most of 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

33

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 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 characterised by a TYPE OF SERVICE, which allows distinguishing various categories of services, according to the needs of the user. This classification allows as well distinguishing the DEAD RUNs necessary to perform the sold services. SPECIAL SERVICEs are usually grouped into GROUPs OF SERVICES, which may be sometimes 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 STOP POINTs (e.g. service for football match). More frequently, they are only described by a ROUTE, often reduced to 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.

7.2.2.3 Service Journey – Physical Model

SERVICE JOURNEY is used extensively to provide passenger information about journeys. As well as having a number of immediate attributes it is also used to assemble a number of derived attributes that are useful for presentation and that are available through relationships to related elements such as LINE, OPERATOR and JOURNEY PATTERN. As such the SERVICE JOURNEY in the physical model is in effect a view.

class XSD NeTEx TP Serv ice Journey Model

TimingPoint


LinkSequence


DataManagedObject

VehicleTypeModel::

VehicleType

Serv icePatternModel::Serv iceJourneyPattern

«PK»

id :ServiceJourneyPatternIdType

«FK»

TypeOfServicePattern :TypeOfServicePatternEnum*

InterchangeModel::Serv iceJourneyPatternInterchange

InterchangeModel::


Journey

Serv iceJourneyModel::SpecialServ ice

StartTime :time

EndTime :time [0..1]

Cl ient :normal izedString

«PK»

id :SpecialServiceIdType

«FK»



TypeOfEnti ty


TypeOfServ ice

«PK»

id :TypeOfServiceIdType

Serv iceJourneyModel::Serv iceJourney

ServiceAlteration :ServiceAlterationEnum [0..1]

DirectionType :DirectionTypeEnum

Print :boolean [0..1]

Dynamic :DynamicAdvertisementEnum [0..1]

«PK»

id :ServiceJourneyIdType

«FK»


«EV»

OperatorView :OperatorView [0..1]

LineView :LineView [0..1]

JourneyPatternVew :JourneyPatternView

«contained»



cal ls :Cal l [0..*]

facil ii ties :Facil ity [0..*]


checkConstraints :CheckConstraint [0..*]

FlexibleProperties :FlexibleServiceProperties

trainNumbers :T imeDemandTypeRef* [0..*]

Name: XSD NeTEx TP Service Journey Model

Author: NeTEx

Version: 1.0

Created: 25/11/2009 17:29:44

Updated: 02/08/2012 14:46:59

GroupOfEnti ties

Serv iceJourneyModel::GroupOfServ ices

DirectionType :DirectionTypeEnum

«PK»

id :GroupOfServicesIdType

«FK»

DayTypeRef :DayTypeRef*

«EV»

DirectionView :DirectionView [0..1]

«contained»

members :VehicleJourneyRef* [0..*]


DataManagedObject

InterchangeModel::Interchange

Transfer

Serv icePatternModel::Connection

Journey


VehicleJourney

DerivedView

«TM_VIEW»

Serv icePatternViews::ScheduledStopPointView

/Name :Multil ingualString [0..1]

/TypeOfPointRef :TypeOfPointIdType

/ShortName :Multi lingualString [0..1]

/Description :Multi lingualString [0..1]

/Label :Multi lingualString [0..1]

/StopType :StopTypeEnum [0..1]

/Url :normal izedString

«PK»

ScheduledStopPointRef :ScheduledStopPointIdType

«AK»

/PrivateCode :PrivateCodeType [0..1]

/Publ icCode :normal izedString [0..1]

DerivedView

«TM_VIEW»

LineAndRouteViews::LineView


/Name :Multil ingualString

/ShortName :Multi l ingualString [0..1]

/Description :Multi lingualString [0..1]

/TransportMode :ModeEnum* [0..1]

/Submode :SubmodeEnum* [0..1]

«FK»

LineRef :LineIdType

DerivedView

«TM_VIEW»

JourneyPatternView::JourneyPatternView

/Name :Multi lingualString

«FK»

JourneyPatternRef :JourneyPatternIdType* [0..1]

«EV»

/DestinationDisplayView :DestinationDisplayView

«contained»

/noticeAssignments :NoticeAssignment [0..*]

DerivedView

OrganisationView::OrganisationView

/Name :normal izedString

/OrganisationType :TypeOfOrganisationEnum


/TradingName :Multil ingualString [0..1]

/LegalName :Multil ingualString [0..1]

«FK»

OrganisationRef :OrganisationIdType

Organisation

TransportOrganisationModel::

Operator

DerivedView

«TM_VIEW»

LineAndRouteViews::DestinationDisplayView

/Name :Multi lingualString



/SideText :Multi lingualString [0..1]

/FrontText :Multi l ingualString [0..1]


/ShortCode :normal izedString [0..1]

«PK»

DestinationDisplayRer :DestinationDisplayIdType

DataManagedObject

LineModel::DestinationDisplay

DerivedView

«TM_VIEW»

NoticeAssignmentView::


DataManagedObject

LineModel::Line

Serv iceJourneyModel::JourneyEndpoint

Name :Multi lingualString

«FK»

PointRef :ScheduledStopPointRef* [0..1]

DataManagedObject

CheckConstraintModel::

CheckConstraint

«enumeration»

Serv iceJourneyValues::

DynamicAdv eristementEnum

always

never

onlyIfOrdered

onlyIfInitiated

InterchangeRuleModel::

InterchangeRule

processaffects

note

0..*

appl ies to

interchange 0..*

at 0..1

interchange0..*

at

0..1

changing 0..*

using 0..1

destination

note

0..*applies to

run by

0..*

primary 0..1

run by 0..*

additional

0..1

summary 0..1

view of 1

0..*destination

1

summary 0..1

view of 1

summary 0..*

view of 1

start

of1

from 0..*

start

of1

from*to *

end

of1

summary0..*

view of 1to 0..*

end

of

1

/journey

to

0..*

/destination

0..1

end

at 0..1

/starts

/origin

0..1

made using *

for 1

summary 0..1

view of 1

using

*

proposed for

0..1

rule

0..*

appl ies to

0..1

to *

end of 1

origin

start

of

1

from *

start

of1

from *

start

of1

from

*

the classification

for

0..1

classified

as*

made up of 0..1

in 1..*

for

0..1

described by *

to

*

end of 1

proposed for

0..1

made using

*

stop 1

origin

to *

end of

1

Figure 24 — Service Journey – Physical Model (UML)

TC 278 WI 00278308:2013 (E)

34

7.2.2.4 Service Journey – Attributes and XSD

7.2.2.4.1 GroupOfServices – Model Element

A group of SERVICEs, often known to its users by a name or a number.

Table 12 – GroupOfServices – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> GroupOfEntities ::> GROUP OF SERVICES inherits from GROUP OF

ENTITIES.

«PK» id GroupOfServicesIdType 1:1 Identifier of GROUP OF SERVICEs.

«FK» dayTypes DayTypeRef 0:* Reference DAY TYPEs applying to the GROUP OF

SERVICEs.

DirectionType DirectionTypeEnum 1:1 Type of DIRECTION. See Part 1.

«EV» DirectionView DirectionView 0:1 Reference to common DIRECTION of SERVICE

JOURNEYs in the GROUP OF SERVICE, with

derived values.

«cntd» destination-

Displays

DestinationDisplay 0:* DESTINATION DISPLAYs associated with the

GROUP OF SERVICEs.

«cntd» members VehicleJourneyRef 0:* Members of a GROUP OF SERVICEs.

«cntd» notice-

Assignments

NoticeAssignmentView 0:* NOTICE ASSIGNMENTs that apply to a GROUP

OF SERVICE.

35

A group of SERV IC Es, often know n to its

users by a name or a number.

GroupOfServices

type GroupOfServices_Versio...

derivedBy restriction

substGrp GroupOfEntities

attributes

C ommon Properties of an object

managed by a responsible

O RGA NISA TIO N.


E lements of a GRO UP O F

ENTITies.

GroupOfEntitiesGroup

E lements for a GRO UP O F

SERV IC Es.

GroupOfServicesGroup

The DA Y TYPEs of all the

serv ices in this group.

dayTypes


v alues.

DirectionType


default outbound


DirectionRef


substGrp TypeOfValueRef

S implified V iew of DIREC TIO N.

DirectionView

type Direction_DerivedView St...

derivedBy extension

substGrp DerivedView

Destinations associated w ith this GRO UP O F

SERV IC Es.

destinationDisplays

type destinationDisplayRefs_RelStru...

Serv ices in GRO UP.

members

type groupOfServicesMembers_Rel...

NO TIC Es relev ant for the whole GRO UP O F

SERV IC Es.

noticeAssignments

type noticeAssignments_RelStructure

Figure 25 — GroupOfServices — XSD

7.2.2.4.2 ServiceJourney – Model Element

A passenger carrying VEHICLE JOURNEY for one specified DAY TYPE. The pattern of working is in principle defined by a SERVICE JOURNEY PATTERN.

Table 13 – ServiceJourney – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> Journey ::> SERVICE JOURNEY inherits from JOURNEY. It

includes elements from VEHICLE JOURNEY

«PK» id ServiceJourneyIdType 1:1 Identifier of SERVICE JOURNEY.

ServiceAlteration ServiceAlterationEnum 0:1 Status to journey - planned, cancelled, etc.

«FK» VehicleTypeRef VehicleTypeRef 0:1 Reference to TYPE OF VEHICLE to use on of

SERVICE JOURNEY.

«EV» OperatorView OrganisationView 0:1 Reference to OPERATOR of SERVICE JOURNEY.

May include OPERATOR's derived values.

«EV» LineView LineView 0:1 Reference to LINE of SERVICE JOURNEY. May

include derived values of LINE.

TC 278 WI 00278308:2013 (E)

36

DirectionType DirectionTypeEnum 1:1 Type of DIRECTION.

Print xsd:boolean 0:1 Whether this journey should be visible to public in

print channels.

Dynamic Dynamic-

AdvertisementEnum

0:1 When this journey should be visible to public in

dynamic channels.

«EV» JourneyPattern-

View

JourneyPatternView 1:1 Reference to JOURNEY PATTERN of SERVICE

JOURNEY and derived values of PATTERN.

«cntd» Origin JourneyEndpoint 0:1 Origin of SERVICE JOURNEY.

«cntd» Destination JourneyEndpoint 0:1 Destination of SERVICE JOURNEY.

«cntd» calls Call 0:* CALLs made by SERVICE JOURNEY.

«cntd» facilities Facility 0:* Facilities on SERVICE JOURNEY.

«cntd» groupsOfServices GroupOfServices 0:* GROUP OF SERVICEs to which SERVICE

JOURNEY belongs.

«cntd» checkConstraints CheckConstraint 0:* CHECK CONSTRAINTs which apply to SERVICE

JOURNEY, check in time, security time. These are

advisory and not for journey planning.

«cntd» FlexibleService-

Properties

FlexibleServiceProperties 1:1 Flexible properties of SERVICE JOURNEY.

37

ServiceJourney_VersionStructure

A planned V EHIC LE JO URNEY taking place on a particular

DA Y TYPE.

The V IEW includes deriv ed ancillary data from referenced

entities.

ServiceJourney

(restriction)

type ServiceJourney_VersionStructure

attributes

C ommon P roperties of an object managed by a responsible O RGA NISA TION .


Elements for a LINK SEQUENC E.

LinkSequenceGroup


JourneyGroup

E lements for a SERV IC E JO URNEY, including additional deriv ed data.

ServiceJourneyGroup

If the journey is an alteration to a timetable, indicates the

original journey , and the nature of the difference.

ServiceAlterationGroup

0 1..

Whether journey is as planned, a cancellation or an extra

journey . Default is as P lanned.

ServiceAlteration

0 1..

type ServiceAlterationEnumeration

E lements for Serv ice time.

ServiceTimeGroup

Time of departure.

DepartureTime

0 1..

type xsd:time

F requency of Journey .

Frequency

0 1..

type FrequencyStructure

Total length of Journey . C an be computed from indiv idual

times. A dd to Departure time to obtain JOURNEY arriv al time.

JourneyDuration

0 1..

type xsd:duration

E lements for associations of V EHIC LE JO URNEY w ith other entities.


Reference elements for a SERV IC E JO URNEY, including additional deriv ed data.

ServiceJourneyReferencesGroup

E lements for origin and destination of JO URNEY. C an be

deriv ed from the Pattern. Must not contradict the calls.

ServiceJourneyEndpointsGroup O rigin for JO URNEY.

Origin

0 1..

type JourneyEndpointStructure

Destination for JO URNEY.

Destination

0 1..


A dv ertisement E lements for info about publicising SERV IC E JO URNEY.

ServiceJourneyAdvertisementGroup Whether the journey is included in printed media. Default is true.

Print

0 1..

type xsd:boolean

When SERV IC E JO URNEY is to be publicised in dy namic

media. Default is alw ay s.

Dynamic

0 1..

type DynamicAdvertisementEnumeration

T ime E lements for V EHIC LE JO URNEY.


E lements for parts of a SERV IC E JO URNEY, i

ServiceJourneyPartsGroup

SERV IC E REQ UIEMENTS for SERV IC E JO URNEY.

These are the normal planned values, not necessarily the A C TUA L V EHIC LE EQ UIPMENT.

ServiceRequirementTypeGroup

Required M inimum capacity for serv ice. Note actual C apacity is giv en by v ehicle type.

0 1..

Reference to a PA SSENGER C A RRYING REQ UIREMENT.

PassengerCarryingRequirement...

type PassengerCarryingRequirementR...

Requirements for carry ing passengers.


type PassengerCarryingRequirement_...

Requirements for TRA IN SIZe.

TrainSize

0 1..

type TrainSizeStructure

V EHIC EL EQ UIPMENT av ailable on serv ice.

equipments

0 1..

type vehicleEquipments_RelStructure

P roperties of the serv ice if all or part of it is run as a DRT /. F LEXIBLE SERV IC E.


0 1..

type FlexibleServiceProperties_Versio...

Figure 26 — ServiceJourney — XSD

7.2.2.4.2.1 ServiceAlteration – Allowed values

The following figure shows the allowed values for ServiceAlteration (ServiceAlterationEnum).

Table 14 – ServiceAlteration – Allowed values

Value Description

extraJourney Journey is a short term addition to the original planned

schedule.

cancellation Journey is a cancellation of a journey in the planned

schedule.

planned Journey is as planned.

TC 278 WI 00278308:2013 (E)

38

7.2.2.4.2.2 VehicleJourneyReferencesGroup – Model Element

E lements for associations of V EHIC LE JO URNEY w ith other

entities.


DA Y TYPEs for Journey .

dayTypes


Reference to a RO UTE.

RouteRef

type RouteRefStructure


JourneyPatternRef









ServicePatternRef


Reference to a TIME DEMA ND TYPE used at start of

JO URNEY.

TimeDemandTypeRef


Reference to a TIMING A LGO RITHM TYPE.

TimingAlgorithmTypeRef

type TimingAlgorithmTypeRefStructure

Reference to a JO URNEY FREQ UENC Y GRO UP.

JourneyFrequencyGroupRef

type JourneyFrequencyGroupRefStru...

Reference to a HEA DWA Y JO URNEY GRO UP.

Headw ayJourneyGroupRef

type Headw ayJourneyGroupRefStruct...

Reference to a RHYTHMIC A L JO URNEY GRO UP.

RhythmicalJourneyGroupRef

type RhythmicalJourneyGroupRefStru...


VehicleTypeRef






BlockRef



TrainBlockRef


Reference to a C O URSE O F JO URNEYS (Run).

CourseOfJourneysRef

type CourseOfJourneysRefStructure

Public code for JO URNEY.

PublicCode


Figure 27 — VehicleJourneyReferencesGroup — XSD

39

7.2.2.4.2.3 ServiceJourneyReferencesGroup – Model Element

Reference elements for a SERV IC E

JO URNEY, including additional deriv ed data.

ServiceJourneyReferencesGroup


OperatorRef


substGrp TransportOrganisationRef

S implified v iew of O PERA TO R. A ll data

except the identifier w ill be deriv ed through the

relationship.

OperatorView

type Operator_DerivedView St...

derivedBy extension


LINE followed by SERV IC E

JO URNEY Use v iew to get

deriv ed v alues.


LineRef


substGrp VersionOfObjectRef

Reference to a FLEXIBLE LINe.

FlexibleLineRef

type FlexibleLineRefStructure

substGrp LineRef

S implified v iew of a LINE.

LineView

type Line_DerivedView Struct...

derivedBy extension


A group of F LEXIBLE RO UTEs of which is

generally know n to the public by a similar

name or number and which hav e common

booking arrangements.

FlexibleLineView

type FlexibleLine_DerivedVie...

derivedBy extension



v alues.

DirectionType


default outbound

S implified v iew of a JO URNEY PA TTERN.

JourneyPatternView

type JourneyPattern_DerivedVi...


Grouping of serv ices of a journey - for a

multi-part journey only .

groupsOfServices

type groupOfServicesRefs_RelStru...

O ther TIME DEMA ND TYPEs used in journey .

timeDemandTypes

type timeDemandTypeRefs_RelStruc...

TRA IN NUMBERs -= deriv ed through

JO URNEY PA RTs of a journey - for a

multi-part journey only .

trainNumbers

type trainNumberRefs_RelStructure

Figure 28 — ServiceJourneyReferencesGroup — XSD

7.2.2.4.2.4 DynamicAdvertisement – Allowed values

The following table shows the allowed values for DynamicAdvertisement (DynamicAdvertisementEnum).

Table 15 – DynamicAdvertisement – Allowed values

Value Description

onlyIfSignedOn Only show journey in public displays if driver has signed in

OnlyIfOrdered Only show journey in public displays if journey has been ordered

always Always show journey in public displays

never Never show journey in public displays

TC 278 WI 00278308:2013 (E)

40

7.2.2.4.2.5 VehicleJourneyTimesGroup – Model Element



WA IT TIMEs for V EHIC LE JO URNEY at different TIMING

PO INTs.

waitTimes

type vehicleJourneyWaitTimes_RelStru...

Run times for V EHIC LE JO URNEY ov er different TIMING

LINKs.

runTimes

type vehicleJourneyRunTimes_RelStru...

LA YO V ER times for V EHIC LE JO URNEY.

layovers

type vehicleJourneyLayovers_RelStru...

PA SSING TIMEs for V EHIC LE JO URNEY.

passingTimes

type timetabledPassingTimes_RelStruc...

Figure 29 — VehicleJourneyTimesGroup — XSD

7.2.2.4.2.6 ServiceJourneyPartsGroup – Model Element

Elements for parts of a SERV IC E JO URNEY, i

ServiceJourneyPartsGroup

JO URNEY PA RTs of a journey - for a multi-part journey

only .

parts

type journeyParts_RelStructure

NO TIC Es that apply to the SERV IC E JO URNEY.

notices


C omplete sequence of stops along the route path, in calling

order.

calls

type calls_RelStructure

FA C ILITies av ailable associated w ith JO URNEY.

facilities

type serviceFacilitySets_RelStructure

C HEC K C O NSTRA INTs which apply to SERV IC E

JO URNEY, e.g. check in time, security time. These are

adv isory only and not for use in journey planning.

checkConstraints

type checkConstraints_RelStructure

Figure 30 — ServiceJourneyPartsGroup — XSD

41

7.2.2.4.2.7 ServiceRequirementTypeGroup – Model Element


These are the normal planned v alues, not necessarily the

A C TUA L V EHIC LE EQ UIPMENT.


Required Minimum capacity for serv ice. Note actual

C apacity is giv en by v ehicle ty pe.

Reference to a PA SSENGER C A RRYING REQ UIREMENT.


type PassengerCarryingRequirementR...

Requirements for carry ing passengers.


type PassengerCarryingRequirement_...

Requirements for TRA IN SIZe.

TrainSize

type TrainSizeStructure

V EHIC EL EQ UIPMENT av ailable on serv ice.

equipments

type vehicleEquipments_RelStructure

Figure 31 — ServiceRequirementTypeGroup — XSD

7.2.2.4.3 SpecialService – Model Element

A work of a vehicle that is not planned in a classical way, i.e. that is generally not based on VEHICLE JOURNEYs using JOURNEY PATTERNs. It involves specific characteristics (such as specific access rights) and/or may be operated under specific circumstances.

Table 16 – SpecialService – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> Journey ::> SPECIAL SERVICE inherits from JOURNEY.

«PK» id SpecialServiceIdType 1:1 Identifier of SPECIAL SERVICE.

StartTime xsd:time 1:1 Start time for SPECIAL SERVICE.

EndTime xsd:time 0:1 End time for SPECIAL SERVICE.

Client xsd:normalizedString 1:1 Client for SPECIAL SERVICE.

DayTypeRef DayTypeRef 0:1 DAY TYPE for SPECIAL SERVICE.

«FK» JourneyPattern-

Ref

JourneyPatternRef 0:1 JOURNEY PATTERN for SPECIAL SERVICE.

«FK» VehicleTypeRef VehicleTypeRef 0:1 VEHICLE TYPE for SPECIAL SERVICE.

«cntd» Origin JourneyEndpoint 0:1 Origin of SERVICE JOURNEY.

«cntd» Destination JourneyEndpoint 0:1 Destination of SERVICE JOURNEY.

Print xsd:boolean 0:1 Whether this journey should be visible to public in

print channels.

Dynamic Dynamic-

AdvertisementEnum

0:1 When this journey should be visible to public in

dynamic channels.

«FK» VehicleTypeRef VehicleTypeRef 0:1 VEHICLE TYPE for SPECIAL SERVICE.

:: Booking-

Arrangements-

Group

BookingArrangements 0:1 BOOKING ARRANGEMENTs for SPECIAL

SERVICE

TC 278 WI 00278308:2013 (E)

42

SpecialService_VersionStructure

A passenger carry ing V EHIC LE JO URNEY for one specified

DA Y TYPE. The pattern of working is in principle defined by a SERV IC E JO URNEY PA TTERN.

SpecialService

(restriction)

type SpecialService_VersionStructure

attributes


O RGA NISA TIO N.



LinkSequenceGroup


JourneyGroup

E lements for SPEC IA L SERV IC E.

SpecialServiceGroup

Elements for SERV IC E time.

ServiceTimeGroup

Time of departure.

DepartureTime

0 1..

type xsd:time

F requency of Journey .

Frequency

0 1..


Total length of Journey . C an be computed from indiv idual

times. A dd to Departure time to obtain JO URNEY arriv al time.

JourneyDuration

0 1..

type xsd:duration

C lient of Special Serv ice.

Client

0 1..

type xsd:string


DayTypeRef



JourneyPatternRef









ServicePatternRef



VehicleTypeRef

0 1..


Reference to a C O MPO UND TRA IN

CompoundTrainRef

type CompoundTrainRefStructure

Reference to a TRA IN.

TrainRef

type TrainRefStructure

Elements for origin and destination of JO URNEY. C an be

deriv ed from the Pattern. Must not contradict the calls.

ServiceJourneyEndpointsGroup O rigin for JO URNEY.

Origin

0 1..


Destination for JO URNEY.

Destination

0 1..


A dv ertisement E lements for info about publicising SERV IC E

JO URNEY.

ServiceJourneyAdvertisementGroup Whether the journey is included in printed media. Default is

true.

Print

0 1..

type xsd:boolean

When SERV IC E JO URNEY is to be publicised in dy namic media. Default is alway s.

Dynamic

0 1..

type DynamicAdvertisementEnumeration

Elements for BO O KING A RRA NGEMENTs of a F LEXIBLE

LINE. May be ov erridden on an indiv idual F LEXIBLE SERV IC E.

BookingArrangementsGroup

Figure 32 — SpecialService — XSD

7.2.2.4.3.1 BookingArrangements – Group

Information about booking a flexible journey.

43

Table 17 – BookingArrangements Group– Group

Classifi

cation

Name Type Cardin-

ality

Description

BookingMethods BookingMethodEnum 0:* Booking method for FLEXIBLE LINE.

BookingAccess BookingAccessEnum 0:1 Who can make a booking.

LatestBooking-

Time

MultilingualString 0:1 Latest time in day that booking can be made.

MinimumBooking

Period

xsd:duration 0:1 Minimum interval in advance of departure day or

time that service may be ordered.

E lements for BO O KING A RRA NGEMENTs of a FLEXIBLE

LINE. May be ov erridden on an indiv idual F LEXIBLE

SERV IC E.


A llowed Way s of Making a BO O KING.

BookingMethods

type FlexibleBookingMethodListOfEnum...

Who can make a booking. Default is public.

BookingAccess

type BookingAccessEnumeration

Latest time in day that booking can be made.

LatestBookingTime

type xsd:time

M inimum interv al in adv ance of departure day or time that

Serv ice may be ordered.

MinimumBookingPeriod

type xsd:duration

Note about booking the FLEXIBLE LINE.

bookingNotes

type notices_RelStructure

Figure 33 — BookingArrangementsGroup — XSD

7.2.2.4.4 TemplateServiceJourney – Model Element

A repeating SERVICE JOURNEY for which a frequency has been specified, either as a HEADWAY JOURNEY GROUP (e.g. every 20 minutes) or a RYTHMICAL JOURNEY GROUP (e.g. at 15, 27 and 40 minutes past the hour). It may thus represent multiple journeys or it could be used simply as a template for adding single extra DATED VEHICLE JOURNEYs after the planning phase.

The frequency of the journey could be defined by a FREQUENCY GROUP. See later

The TEMPLATE SERVICE JOURNEY of a RYTHMICAL JOURNEY GROUP needs passing times, where only the minute part is meaningful (passing times are repeated every hour with the same minutes), therefore the hour part of passing times will be ignored (a "00" value is recommended).

Table 18 – TemplateServiceJourney – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> TemplateVehicleJourney ::> TEMPLATE SERVICE JOURNEY inherits from

TC 278 WI 00278308:2013 (E)

44

TEMPLATE VEHICLE JOURNEY.

«PK» id TemplateService-

JourneyIdType

0:1 Identifier of TEMPLATE SERVICE JOURNEY.

TemplateServiceJourney_VersionStructure

A V EHIC LE JO URNEY w ith a set of frequencies that may

be used to represent a set of similar journey s differing only

by their time of departure.

TemplateServiceJourney

(restriction)

type TemplateServiceJourney_Version...

attributes


O RGA NISA TIO N.



LinkSequenceGroup


JourneyGroup

E lements for a SERV IC E JO URNEY, including additional

deriv ed data.

ServiceJourneyGroup

E lements for TEMPLA TE V EHIC LE JO URNEY.

TemplateVehicleJourneyGroup

Figure 34 — TemplateServiceJourney — XSD

7.2.2.5 XML Examples of Service Journey

7.2.2.5.1 Service Journey XML Example with passing times and calls

The following code fragment shows a SERVICE JOURNEY with just three stops – but five timing points.

For EXAMPLE:

<ServiceJourney version="any" id="hde:sj_24o_02_AxxD">


<dayTypes>

<DayTypeRef version="any" ref="hde:Daype:DT_01-MF-NH"/>

</dayTypes>

<ServicePatternRef version="any" ref="hde:svp_24o_AxxD"/>

<TimeDemandTypeRef version="any" ref="mybus:td_01"/>

<LineRef version="any" ref="mybus:LN_24"/>

<JourneyPatternView>

<RouteRef version="any" ref="mybus:RT_24o"/>


<DestinationDisplayRef version="any" ref="mybus:DST_Delta"/>

</JourneyPatternView>

<passingTimes>

<TimetabledPassingTime version="any" id="mybus:tpt_24o_02_AxxD_SSP_001">

<StopPointInJourneyPatternRef version="any" ref="hde:spijp_24o_AxxD_01"/>



<TimetabledPassingTime version="any" id="hde:tpt_24o_02_AxxD_SSP_001_t1">

<TimingPointInJourneyPatternRef version="any" ref="hde:tpijp_24o_AxxD_02"/>



<TimetabledPassingTime version="any" id="hde:tpt_24o_02_AxxD_SSP_001_t2">






45




<StopPointInJourneyPatternRef version="any" ref="hde:spijp_24o_AxxD_04"/>

<ArrivalTime>15:40:00.0Z</ArrivalTime>


</passingTimes>

<calls>

<Call id="hde:Call:sj_24o_02_001" order="1">

<ScheduledStopPointRef version="any" ref="mybus:SSP_001"/>

<Arrival>

<ForAlighting>false</ForAlighting>

</Arrival>

<Departure>

<Time>14:20:00.0Z</Time>

</Departure>

</Call>




</Arrival>

<Departure>

<Time>14:50:00.0Z</Time>

</Departure>

</Call>



<Arrival>

<Time>15:40:00.0Z</Time>

</Arrival>

<Departure>

<ForBoarding>false</ForBoarding>

</Departure>

</Call>

</calls>

</ServiceJourney>

7.2.2.5.2 Service Journey XML Example with passing times and calls

The following code fragment shows a SERVICE JOURNEY.

For EXAMPLE

<ServiceJourney version="any" id="hde:sj_24o_01">


<dayTypes>

<DayTypeRef version="any" ref="hde:DT_02-Everyday-NotHoliday"/>

<DayTypeRef version="any" ref="hde:DT_ChristmasEve"/>

<DayTypeRef version="any" ref="hde:DT_ChristmasDay"/>

<DayTypeRef version="any" ref="hde:DT_ChristmasDayDisplacement"/>

<DayTypeRef version="any" ref="hde:DT_NewYearsEve"/>

<DayTypeRef version="any" ref="hde:DT_NewYearsDay"/>

<DayTypeRef version="any" ref="hde:DT_2ndJanuary"/>

<DayTypeRef version="any" ref="hde:DT_GoodFriday"/>

<DayTypeRef version="any" ref="hde:DT_EasterSunday"/>

<DayTypeRef version="any" ref="hde:DT_EasterMonday"/>

</dayTypes>

<ServicePatternRef version="any" ref="hde:svp_24o"/>

<TimeDemandTypeRef version="any" ref="mybus:tdt_01"/>

<BlockRef ref="mybus:Block:BLK_24o5">EXTERNAL</BlockRef>





<DestinationDisplayRef version="any" ref="mybus:DST_Charley"/>


<runTimes>

<VehicleJourneyRunTime id="hde:vjrt_sj_24o_01">

<Name>Overall run time</Name>

<TimeDemandTypeRef version="any" ref="mybus:tdt_01"/>

<TimingLinkRef version="any" ref="mybus:SSP_001_to_SSP_077"/>

<RunTime>PT70M</RunTime>

</VehicleJourneyRunTime>

TC 278 WI 00278308:2013 (E)

46

</runTimes>

7.2.3 Time Demand Times

7.2.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 entity.

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

TIME DEMAND TYPEs, built from a CALENDAR DAY and a TIME BAND through an ASSIGNMENT mechanism, have already been introduced in NeTEx Part 1, as part of the tactical planning component: the following figure represents the associated timing information, which are RUN TIMEs, WAIT TIMEs, and a few other timing information like HEADWAY frequency, TURNAROUND TIME LIMIT and JOURNEY PATTERN LAYOVER.

47

class NeTEx TM TP Time Demand Times MODEL

Journey Pattern Times MODEL::

JOURNEY PATTERN RUN TIME

Time Demand Type MODEL::TIME

DEMAND TYPE

LINK SEQUENCE

Journey Pattern

MODEL::JOURNEY

PATTERN

Name: NeTEx TM TP Time Demand Times MODEL

Author: NeTEx

Version: 1.0

Created: 18/10/2010 21:56:21

Updated: 03/10/2012 15:41:49

LINK

Timing Pattern

MODEL::TIMING LINK


MODEL::VEHICLE TYPE

PREFERENCE

JOURNEY


JOURNEY

JOURNEY TIMING

DEFAULT SERVICE

JOURNEY RUN TIME

+ RunTime

«PK»

+ id [0..1]

JOURNEY TIMING

DEFAULT DEAD RUN RUN

TIME

+ RunTime

«PK»

+ id [0..1]


MODEL::JOURNEY

PATTERN WAIT TIME


MODEL::JOURNEY

PATTERN LAYOVER


MODEL::JOURNEY

PATTERN HEADWAY

JOURNEY TIMING

Journey Pattern Times MODEL::

TURNAROUND TIME LIMIT

JOURNEY FREQUENCY GROUP

Vehicle Journey Times MODEL::

HEADWAY JOURNEY GROUP

Serv ice

Calendar

MODEL::DAY

TYPE

+used by defaul t by

*

+made using *

+used to

define

1

+associated with*

+worked

using

1

+for

0..*

+used to define

1+associated with

* +allowing 1

+allowed on*

+used to

define

1

+associated with *

+covered in

1

+associated with

*

+used to

define1

+associated with*

+worked on *

+for 1..*

+covered in1

+associated with*

+worked

using

1

+assigned

to*

+used to define

1

+for

*

+used to define

1

+for*

+made using *

+for 1

+assciated with*

+used to define

1

+made using *

+used by default by

0..*+covered in

1

+associated with

*

+used to

define

1

+associated with*

+used to define1

+associated with *

Figure 35 —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 is used by several JOURNEY PATTERNs, the default times may be applied any time it is covered by a VEHICLE JOURNEY, regardless the JOURNEY PATTERN.

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.

TC 278 WI 00278308:2013 (E)

48

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 and JOURNEY PATTERN HEADWAY, used to define services based on headway frequencies, are both potentially depending on TIME DEMAND TYPE.

7.2.3.2 Time Demand Times – Physical Model

The following figure shows the TIME DEMAND TIMEs physical model.

49

class XSD NeTEx TP Time Demand Times Model

JourneyTiming

TimeDemandTimesModel::

DefaultServ iceJourneyRunTime

RunTime :duration

«PK»

id :DefaultServiceRunTimeIdType [0..1]

ServiceJourneyRef :ServiceJourneyRef*

DataManagedObject


Name :Multil ingualString [0..1]

Description :Multil ingualString [0..1]

«PK»

id :T imeDemandTypeIdType

«AK»

PrivateCode :PrivateCodeType [0..1]

«contained»

Presentation :Presentation [0..1]

runTimes :JourneyRunTime [0..*]

waitTimes :JourneyWaitTime [0..*]

layovers :JourneyLayover [0..*]

headways :JourneyHeadway [0..*]

turnaroundTimes :TurnaroundTimeLimit [0..*]

vehiclePreferences :VehiclePreference [0..*]

«FK»

OperationalContextRef :OperationalContextRef* [0..1]

TypeOfTimeDemandTypeRef :TypeOfTimeDemandTypeRef* [0..1]

DataManagedObject

TimeDemandTypeModel::TimeDemandTypeAssignment

JourneyTiming

JourneyPatternTimesModel::


Rank :positiveInteger [0..1]

«PK»

id :VehicleTypePreferenceIdType [0..1]

«FK»

VehicleTypeRef :VehicleTypeRef*

DayTypeRef :DayTypeRef* [0..1]

JourneyWaitTime



«PK»

id :JourneyPatternWaitTimeIdType [0..1]

«FK»

JourneyPatternRef :JourneyPatternRef*

Name: XSD NeTEx TP Time Demand Times Model

Author: NeTEx

Version: 1.0

Created: 30/01/2010 00:44:51

Updated: 12/10/2012 14:33:25

JourneyTiming



RunTime :duration

«PK»

id :DefaultDeadRunTimeIdType [0..1]

Journey


VersionFrame

Serv iceFrameModel::Serv iceFrame

JourneyRunTime



«PK»

id :JourneyPatternRunTimeIdType [0..1]

«FK»

LinkRef :TimingLinkIdType*


GroupOfEntities

TimingPatternModel::GroupOfTimingLinks

DataManagedObject

VehicleTypeModel::VehicleType

JourneyLayover


JourneyPatternLayov er

«PK»

id :JourneyPatternLayoverIdType [0..1]

«FK»





«PK»

id :DeadRunIdType

«FK»



«contained»







Serv iceJourney

Link

TimingPatternModel::TimingLink

DataManagedObject

Serv iceCalendarModel::DayType

DataManagedObject

TransportOrganisationModel::

OperationalContext

distinguished by

0..*

distinguishes

0..1

distinguished by

0..*

distinguishes

0..1

used to define

0..*

for

0..1

worked on*

for 1

proposed for 0..1

made using*

0..*used to define 1

associated with *

operated by

0..*

requested for

0..*

0..*

1

member

0..*

comprises

0..*

distinguishes0..1

valid for*

comprising

1

used to define 1

associated with

*

used by default by0..1

made using

*

used by

0..*

uses

0..*

covered in1

associated with0..*

used to define

1

associated with *used to define 1

associated with*

specified by 1

for *

used to define 1

for *

used to define

1for *

used to define*

for 1

covered in

1

associated with*

used to define 1

associated with *

Figure 36 — Time Demand Times – Physical Model (UML)

TC 278 WI 00278308:2013 (E)

50

7.2.3.2.1 Using Time Demand Times – Physical Model

The following figure shows how timing information is associated with TIMING POINTs and TIMING LINKs for a given TIME DEMAND TYPE. The JourneyTiming element holds common association properties: it are specialised to create a number of different types of timing.

class XSD NeTEx TP Time Demand Times Use


DefaultServ iceJourneyRunTime

RunTime :duration

«PK»

id :DefaultServiceRunTimeIdType [0..1]

ServiceJourneyRef :ServiceJourneyRef*

DataManagedObject


Name: XSD NeTEx TP Time Demand Times Use

Author: NeTEx

Version: 1.0

Created: 11/04/2012 16:28:55

Updated: 12/04/2012 10:22:13



RunTime :duration

«PK»

id :DefaultDeadRunTimeIdType [0..1]

VehicleJourney


VehicleJourney


Serv iceJourney

DataManagedObject

TransportOrganisationModel::OperationalContext

VersionedChild

JourneyTimingModel::JourneyTiming


VehicleMode :VehicleModeEnum [0..1]

«PK»

id :JourneyTimingIdType

«FK»


TimebandRef :TimebandRef* [0..1]


DataManagedObject

Serv iceCalendarModel::Timeband

used to define 1

associated with*

timing

0..*

made up of

0..1

used to define 1

associated with

*

0..*

0..*

distinguishes

0..1

distinguished by 0..*

distinguishes 0..1

timing 0..*

happens during 0..1

Figure 37 — Time Demand Times Use – Physical Model (UML)

7.2.3.3 Time Demand Times – Attributes and XSD

7.2.3.3.1 DefaultServiceJourneyRunTime – Model Element

The default time taken by a vehicle to traverse a TIMING LINK during a SERVICE JOURNEY, for a specified TIME DEMAND TYPE. This time may be superseded by the JOURNEY PATTERN RUN TIME or VEHICLE JOURNEY RUN TIME if these exist.

51

Table 19 – DefaultServiceJourneyRunTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyTiming ::> DEFAULT SERVICE JOURNEY RUN TIME inherits

from JOURNEY TIMING.

«PK» id DefaultService-

RunTimeIdType

0:1 Identifier of DEFAULT SERVICE JOURNEY RUN

TIME.

RunTime xsd:duration 1:1 Run time as a duration.

«PK» ServiceJourneyRef ServiceJourneyRef 1:1 SERVICE JOURNEY with which DEFAULT RUN

TIME is associated.

DefaultServiceJourneyRunTime_VersionedChildStructure

The default time taken by a v ehicle to trav erse a TIMING

LINK during a SERV IC E JO URNEY, for a specified TIME

DEMA ND TYPE. This time may be superseded by the

JO URNEY PA TTERN RUN TIME or V EHIC LE JO URNEY

RUN TIME if these exist.

DefaultServiceJourneyRunTime

(restriction)

type DefaultServiceJourneyRunTime_...

attributes

E lements for a V ERSIO NED C HILD.

VersionedChildGroup

E lements of a JO URNEY TIMING.

JourneyTimingGroup

DEFA ULT SERV IC E JO URNEY / RUN TIME elements.

DefaultServiceJourneyRunTimeGroup Run time as interv al.

RunTime

type xsd:duration

Reference to a SERV IC E JO URNEY.

ServiceJourneyRef

0 1..

type ServiceJourneyRefStructure

Reference to a TEMPLA TE V EHIC LE JO URNEY.

TemplateServiceJourneyRef

type TemplateServiceJourneyRefStruc...

Figure 38 — DefaultServiceJourneyRunTime — XSD

7.2.3.3.2 DefaultDeadRunRunTime – Model Element

The time taken to traverse a TIMING LINK during a DEAD RUN, for a specified TIME DEMAND TYPE. This time may be superseded by the JOURNEY PATTERN RUN TIME or VEHICLE JOURNEY RUN TIME if these exist.

Table 20 – DefaultDeadRunRunTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyTiming ::> DEFAULT DEAD RUN RUN TIME inherits from

JOURNEY TIMING.

«PK» id DefaultDeadRunTimeIdType 0:1 Identifier of DEFAULT DEAD RUN RUN TIME.

RunTime xsd:duration 1:1 Default time to make a DEAD RUN.

TC 278 WI 00278308:2013 (E)

52

DefaultDeadRunRunTime_VersionedChildStructure

The time taken to trav erse a TIMING LINK during a DEA D

RUN, for a specified TIME DEMA ND TYPE. This time may

be superseded by the JO URNEY PA TTERN RUN TIME or

V EHIC LE JO URNEY RUN TIME if these exist.


(restriction)

type DefaultDeadRunRunTime_Version...

attributes


VersionedChildGroup


JourneyTimingGroup

DEFA ULT DEA D RUN / RUN TIME elements.

DefaultDeadRunRunTimeGroup Run time as interv al.

RunTime

type xsd:duration

Reference to a DEA D RUN.

DeadRunRef

0 1..

type DeadRunRefStructure

Figure 39 — DefaultDeadRunRunTimeTime — XSD

7.2.3.4 Time Demand Profile —Physical Model

The following figure introduces the Physical Model for a TIME DEMAND PROFILE. It provides a convenient way of handling a set of JOURNEY PATTERN RUN TIMEs using the same TIME DEMAND TYPE.

class XSD NeTEx TP Time Demand Profile Model

DataManagedObject


Name: XSD NeTEx TP Time Demand Profile Model

Author: NeTEx

Version: 1.0

Created: 17/11/2010 09:14:34

Updated: 12/04/2012 10:22:11

Journey


JourneyRunTime

JourneyPatternTimesModel::JourneyPatternRunTime

DataManagedObject

TimeDemandProfileModel::TimeDemandProfile


«PK»

id :TimeDemandProfi leIdType

«FK»

VehicleJourneyRef :VehicleJourneyRef* [0..1]


«contained»

members :TimeDemandProfileMember* [0..*]

VersionedChild

TimeDemandProfileModel::TimeDemandProfileMember

Order :integer

«PK»

id :TimeDemandProfi leMemberIdType

«FK»

TimeDemandRef :TimeDemandTypeRef*

TimeDemandProfi leRef :TimeDemandProfileRef*

JourneyPatternRunTimeRef :JourneyPatternRunTimeIdType* [0..1]

LinkSequence


used by

0..*

for

for 1

used in

0..*

uses

0..1

used by 0..*

uses 0..*

used by default by

0..1

made using*

worked using 1

assigned to *

used inmember

1

used to define 1

associated with *

members 0..*

1for 0..*

used in 0..1

made using

*

for 1

Figure 40 — Time Demand Profile – Physical Model (UML)

7.2.3.5 Time Demand Profile – Attributes and XSD

7.2.3.5.1 TimeDemandProfile – Model Element

An indicator of traffic conditions or other factors which may affect vehicle run or wait times. It may be entered directly by the scheduler or defined by the use of TIME BANDs.

53

Table 21 – TimeDemandProfile – Element

Classifi

cation

Name Type Cardi

nality

Description

::> ::> DataManagedObject ::> TIME DEMAND PROFILE inherits from DATA

MANAGED OBJECT

«PK» id TimeDemandProfileIdType 1:1 Identifier of TIME DEMAND PROFILE.

Name MultilingualString 0:1 VEHICLE JOURNEY associated with TIME

DEMAND PROFILE.

«FK» TimeDemandTypeR

ef

TimeDemandTypeRef 0:1 TIME DEMAND TYPE associated with TIME

DEMAND PROFILE.

«FK» TimebandRef TimebandRef 0:1 Reference to a TIME BAND.

«FK» JourneyPatternRef JourneyPatternRef 0:1 JOURNEY PATTERN associated with TIME

DEMAND PROFILE.

«FK» VehicleJourneyRef VehicleJourneyRef 0:1 Identifier of TIME DEMAND PROFILE.

«cntd» members TimeDemand-

ProfileMember

0:* Members of TIME DEMAND PROFILE.

TC 278 WI 00278308:2013 (E)

54

TimeDemandProfile_VersionStructure

TIME DEMA ND PRO F ILE.

TimeDemandProfile

(restriction)

type TimeDemandProfile_VersionStruc...

attributes


O RGA NISA TIO N.


TIME DEMA ND PRO F ILE elements.

TimeDemandProfileGroup

Name of P rofile.

Name

0 1..


0 1..

Reference to a TIME DEMA ND TYPE. If giv en by context

need not be stated.

TimeDemandTypeRef


Reference to a TIME BA ND.

TimebandRef

type TimebandRefStructure


JourneyPatternRef

0 1..









ServicePatternRef


Reference to a V EHIC LE JO URNEY. If giv en by context

does not need to be repeated.

VehicleJourneyRef

0 1..

type VehicleJourneyRefStructure


DeadRunRef


members

0 1..

type timeDemandProfileMembers_RelSt...

Figure 41 — TimeDemandProfile — XSD

7.2.3.5.2 TimeDemandProfileMember – Model Element

A members of the TIME DEMAND PROFILE described above.

Table 22 – TimeDemandProfileMember – Element

Classifi

cation Name Type Cardin-

ality Description

::> ::> GroupMember ::> TIME DEMAND PROFILE inherits from GROUP

MEMBER.

«PK» id TimeDemandProfile-

MemberIdType

1:1 Identifier of TIME DEMAND PROFILE MEMBER.

order xsd:integer 1:1 Order of member within profile.

«FK» TimeDemand-

ProfileRef

TimeDemandProfileRef 1:1 TIME DEMAND PROFILE of PROFILE MEMBER.

«PK» TimeDemandRef TimeDemandTypeRef 1:1 TIME DEMAND TYPE of PROFILE MEMBER.

«FK» JourneyPattern- JourneyPatternRunTime- 0:1 JOURNEY PATTERN RUN TIME of PROFILE

55

RunTimeRef Ref MEMBER.

TimeDemandProfileMember_VersionStructure

TIME DEMA ND PRO F ILE member.

TimeDemandProfileMember

(restriction)

type TimeDemandProfileMember_Versi...

attributes

Elements for a V ERSIO NED C HILD.

VersionedChildGroup

User defined Extensions to ENTITY in schema. (Wrapper tag

used to av oid problems w ith handling of optional 'any ' by

some v alidators).

Extensions

0 1..

type ExtensionsStructure

Description

0 1..


Parent GRO UP O F ENTITies to which this member assigns serv ice - If giv en by context, can be omitted.

GroupRef

0 1..

type VersionOfObjectRefStructure

Reference to a member of the group.

MemberObjectRef

type VersionOfObjectRefStructure

Elements for a TIME DEMA ND PRO FILE member.

TimeDemandProf ileMemberGroup

Name of TIME DEMA ND PRO F ILE MEMBER.

Name

0 1..



need not be stated.

TimeDemandTypeRef

0 1..


The time taken to trav erse a TIMING LINK in a particular JO URNEY PA TTERN, for a specified TIME DEMA ND

TYPE If it exists, it w ill ov erride the DEF A ULT SERV IC E

JO URNEY RUN TIME and DEF A ULT DEA D RUN RUN

TIME.


0 1..

type JourneyPatternRunTime_Version...

Figure 42 — TimeDemandProfileMember — XSD

7.2.3.6 XML Example of Time Demand Timings

The following code fragment shows a TIME DEMAND TYPE with several RUN TIMEs associated with it for particular links.

For EXAMPLE

<timeDemandTypes>

<TimeDemandType version="any" id="kx:tdt_45_Day">

<Name>Normal Time demand </Name>

<runTimes>



<JourneyRunTime version="any" id="kx::jprt_sjp_L24o_ssp_001-ssp_002_tdt_45">

<Name>Run Time from 001 to 002: 10 minutes</Name>

<TimingLinkRef version="any" ref="kx:tl_ssp_001_to_ssp_002"/>


</JourneyRunTime>

<JourneyRunTime version="any" id="kx:jprt_sjp_L24o_ssp_002-ssp_077_tdt_45">

<Name>Run Time from 002 to 007: 20 minutes</Name>



</JourneyRunTime>


<Name>Time from 077 to 002: 20 minutes</Name>

<TimeDemandTypeRef version="any" ref="kx:tdt_45_Day"/>


TC 278 WI 00278308:2013 (E)

56


</JourneyRunTime>


<Name>Time from 002 to 001: 10 minutes</Name>

<TimeDemandTypeRef version="any" ref="kx:tdt_45_Day"/>



</JourneyRunTime>

</runTimes>

</TimeDemandType>

<TimeDemandType version="any" id="kx:tdt_46_Night">

<Name>Night Time demand </Name>

</TimeDemandType>

</timeDemandTypes>

7.2.4 Journey Timing

7.2.4.1 JOURNEY TIMING – Conceptual MODEL

The JOURNEY TIMING model defines common properties for timing elements that can be specialised in the VEHICLE JOURNEY and JOURNEY PATTERN timing models. A JOURNEY TIMING provides an abstract type for a number of different specialised 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.

57

class Journey Timings MODEL

Time Demand Type

MODEL::JOURNEY

TIMING


«PK»

~ id

JOURNEY

LAYOVER

+ Duration [0..1]

«PK»

~ idJOURNEY WAIT

TIME

+ WaitTime

«PK»

~ id

JOURNEY

HEADWAY

+ Frequency

«PK»

~ id

JOURNEY RUN

TIME

+ RunTime

«PK»

~ id


MODEL::VEHICLE

JOURNEY LAYOVER


MODEL::VEHICLE

JOURNEY WAIT TIME


MODEL::VEHICLE

JOURNEY HEADWAY


MODEL::VEHICLE

JOURNEY RUN TIME


MODEL::TURNAROUND

TIME LIMIT

Time Demand Times

MODEL::DEFAULT DEAD

RUN RUN TIME

Time Demand Times

MODEL::DEFAULT

SERVICE JOURNEY

RUN TIME

Name: Journey Timings MODEL

Author: Kasia

Version: 1.0

Created: 16/11/2011 15:45:48

Updated: 27/03/2012 19:24:22

Time Demand Type MODEL::

TIME DEMAND TYPE

Serv ice Calendar

MODEL::TIME BAND

exclusion: either time

bands or time demand

types determine the

timing

POINT

Timing Pattern MODEL::

TIMING POINT

LINK


TIMING LINK


MODEL::OPERATIONAL

CONTEXT

+timed at

0..*

+for 1

+for 0..*

+passed every 1

+associated with0..*

+covered in

1

+asociated with

*

+used to define

0..1

+to

*

+end of

1

+determined for 0..*

+determining 0..1

+used to define

0..1+associated with

*

+determining

0..1

+determined by

0..*

+start of1

+from *

+covered in1

+associated with*+covered in 1

+associated with

*

+characterized by

0..*

+characterizing

0..*

Figure 43 — Journey Timing – Conceptual MODEL (UML)

7.2.4.1.1 Layover times

LAYOVER TIMEs describe a certain time allowance that may be given at the end of each VEHICLE JOURNEY, before starting the next one, to compensate delays or for other purposes (e.g. rest time for the driver). This “layover time” can be regarded as a buffer time, which may or may not be actually consumed in real time operation.

A minimum layover time may be defined separately at the end of each JOURNEY PATTERN. This will be stored in the JOURNEY PATTERN LAYOVER entity, depending on a TIME DEMAND TYPE.

Such standard layover times may be superseded by a layover time defined for a specific VEHICLE JOURNEY.

TC 278 WI 00278308:2013 (E)

58

7.2.4.1.2 Wait times

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

7.2.4.1.3 Headway times

Headway frequency information that is available for a VEHICLE JOURNEY supersedes the JOURNEY PATTERN HEADWAY. It has to be understood as the delay between the previous and the next VEHICLE JOURNEY. This information shall be consistent with HEADWAY JOURNEY GROUP if available (HEADWAY JOURNEY GROUP being a more detailed way of describing headway services).

7.2.4.1.4 Run times

A precise control of run times is possible by using the JOURNEY RUN TIME. It defines a run time for a TIMING LINK that will be valid only for specific VEHICLE JOURNEYs and overrides the default run times for this TIMING LINK.

JOURNEY 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 VEHICLE JOURNEY RUN TIME is specific to one VEHICLE JOURNEY and applies to a particular TIMING LINK. If it exists, it overrides any run time that may have been stored for the TIMING LINK in question.

7.2.4.1.5 Turnaround times

Another constraint to be taken into account in fixing layover times may be a maximal or minimal turnaround time. A turnaround time is the time taken by a vehicle to proceed from the end of a ROUTE to the start of another. There are some limitations for turnaround times, which are used as parameters by scheduling systems for the vehicle scheduling procedure.

The TURNAROUND TIME LIMIT is dependent on a TIME DEMAND TYPE and is stored against a pair of TIMING POINTs. These points represent a TIMING POINT where a vehicle may end a SERVICE JOURNEY and a TIMING POINT where it may start from, for a subsequent SERVICE JOURNEY. The duration of a DEAD RUN (relating the two TIMING POINTs) possibly scheduled between these two SERVICE JOURNEYs is included in the turnaround time.

7.2.4.1.6 Times for Dead Runs

The path to proceed from the end point of a SERVICE JOURNEY to the start point of the following is normally described by a DEAD RUN PATTERN. However, it is often not worth to model explicitly a short movement as a DEAD RUN, covering an explicit DEAD RUN PATTERN. In such a case, a ‘minimum duration’ may be stored in the TURNAROUND TIME LIMIT, as the minimum time needed by a vehicle to cover this short path. This minimum duration will of course be superseded by the run times (plus wait times, if any) associated with an explicitly modelled DEAD RUN between the two TIMING POINTs concerned.

59

In the case of a SERVICE JOURNEY, there are STOP POINTs in the JOURNEY PATTERN where passengers can board or alight from the vehicle. Therefore, run times will probably be different if a vehicle crosses a TIMING LINK during a SERVICE JOURNEY or a DEAD RUN. Default run times are hence recorded in two different entities: DEFAULT SERVICE JOURNEY RUN TIME and DEFAULT DEAD RUN RUN TIME.

Using these default run times, the timing information for each VEHICLE JOURNEY can be derived by looking for the TIMING POINTs in the associated JOURNEY PATTERN, accessing the TIMING LINKs between these TIMING POINTs and choosing the appropriate run time. These times will be found, for each TIMING LINK, in the DEFAULT SERVICE JOURNEY RUN TIME or DEFAULT DEAD RUN RUN TIME entity, according to the type of journey.

The choice among the run times recorded for one TIMING LINK is determined by the TIME DEMAND TYPE which has been assigned to the VEHICLE JOURNEY.

7.2.4.2 Journey Timing – Physical Model

The following figure shows the JOURNEY TIMING physical model and its attributes.

class XSD NeTEx TP Journey Timing Model

DataManagedObject


Name: XSD NeTEx TP Journey Timing Model

Author: NeTEx

Version: 1.0

Created: 26/01/2010 18:14:55

Updated: 01/10/2012 23:51:10

VersionedChild


Name :Multi l ingualString [0..1]


«PK»


«FK»


TimebandRef :TimebandRef* [0..1]


JourneyTimingModel::

JourneyRunTime

RunTime :duration

«PK»

id :RunTimeIdType

«FK»

LinkRef :TimingLinkRef* [0..1]


JourneyWaitTime

WaitTime :duration

«PK»

id :WaitTimeIdType

«FK»

TimingPointRef :TimingPointRef*


JourneyLayover

Layover :duration [0..1]

«PK»

id :LayoverIdType

«FK»

PointRef :PointRef*

Link


Mode :VehicileModeEnum [0..1]

«PK»

id :TimingLinkIdType

«FK»

FromPointRef :TimingPointRef*

ToPointRef :TimingPointRef*

OperationalContextRef :OperationalContextRef [0..1]

TimingPatternModel::TimingPoint

Category :string [0..1]

AllowedForWaitTime :duration [0..1]

Flexible :boolean [0..1]

TimingPointType :TimingStatusEnum [0..1]

«PK»

id :TimingPointIdType

VehicleAndCrewModel::

ParkingPoint

«PK»

id :ParkingPointIdType


ReliefPoint

«PK»

id :ReliefPointIdType

«FK»

CrewBaseRef :CrewBaseRef*

DataManagedObject

PointAndLinkModel::Point

JourneyTimingModel::JourneyHeadway

Frequency :HeadwayInterval

«PK»

id :HeadwayIdType

JourneyTimingModel::HeadwayInterv al

ScheduledHeadwayInterval :duration [0..1]

MinimumHeadwayInterval :duration [0..1]

MaximumHeadwayInterval :duration [0..1]

«enumeration»

TransportModeValues::

VehicleModeEnum

air

bus

coach

funicular

metro

rail

trolleyBus

tram

water

cableway

other

DataManagedObject



TurnaroundTimeLimit

MinimumDuration :duration [0..1]

MaximumDuration :duration

«PK»

id :TurnaroundTimeIdType [0..1]

to

*end of

1distinguished

by

0..*

distinguishes

0..1

distinguished by

0..*

distinguishes

0..1

0..*

distinguishes 0..1

sourceat

start of

1

from

*

at every

0..*

passed

1

time

0..*

at

timeover

start of

1

from *

timing

0..*

made up of

0..1

to*

end of

1

Figure 44 — Journey Timing – Physical Model (UML)

TC 278 WI 00278308:2013 (E)

60

7.2.4.3 Journey Timing – Attributes and XSD

7.2.4.3.1 JourneyWaitTime – Model Element

The time a vehicle has to wait at a specific TIMING POINT IN JOURNEY PATTERN, for a specified TIME DEMAND TYPE. This wait time can be superseded by a VEHICLE JOURNEY WAIT TIME.

Table 23 – JourneyWaitTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyTiming ::> JOURNEY WAIT TIME inherits from JOURNEY

TIMING.

«PK» id WaitTimeIdType 1:1 Identifier of JOURNEY WAIT TIME.

«FK» TimingPointRef TimingPointRef 1:1 POINT associated with of JOURNEY WAIT TIME.

WaitTime xsd:duration 1:1 Wait time of JOURNEY WAIT TIME.

61

JourneyTiming_VersionedChildStructure

A time-related information referring to journey timing whose

v alue depends on the time of use and so can be associated

w ith a TIME DEMA ND TYPE, TIME BA ND or

O PERATIO NA L C O NTEXT.

JourneyTiming

type JourneyTiming_VersionedChildStructure

attributes


VersionedChildGroup


JourneyTimingGroup

Name of JO URNEY TIMING.

Name



need not be stated.

TimeDemandTypeRef



TimebandRef


V EHIC LE MO DE: a characterisation of the operation

according to the means of transport (bus, tram, metro, train,

ferry , ship).

VehicleMode

type AllModesEnumeration




Headway interv al information that is av ailable for all the

V EHIC LE JO URNEYs running on the JO URNEY PA TTERN

for a giv en TIME DEMA ND TYPE, at a giv en TIMING

PO INT. This is a default v alue that can be superseded by

V EHIC LE JO URNEY HEA DWAY. This information must be

consistent w ith HEA DWAY JO URNEY GRO UP if av ailable

(HEA DWA Y JO URNEY GRO UP being a more detailed way

of describing headway serv ices).

JourneyHeadway

type JourneyHeadw ay_VersionedChildStructure

Time allowance at the end of each journey on a specified

JO URNEY PA TTERN, to allow for delay s and for other

purposes. This lay over supersedes any global lay ov er and

may be superseded by a specific V EHIC LE JO URNEY

LA YO V ER.

JourneyLayover

type JourneyLayoverStructure

The time taken to trav erse a TIMING LINK in a particular

JO URNEY PA TTERN, for a specified TIME DEMA ND

TYPE. If it exists, it w ill ov erride the DEFA ULT SERV IC E

JO URNEY RUN TIME and DEFA ULT DEA D RUN RUN

TIME.

JourneyRunTime

type JourneyRunTime_VersionedChildStructure

The time a v ehicle has to wait at a specific TIMING PO INT

IN JO URNEY PA TTERN, for a specified TIME DEMA ND

TYPE. This wait time can be superseded by a V EHIC LE

JO URNEY WA IT TIME.

JourneyWaitTime

type JourneyWaitTime_VersionedChildStructure

Figure 45 — JourneyWaitTime — XSD

7.2.4.3.2 JourneyRunTime – Model Element

The time taken to traverse a TIMING LINK in a particular JOURNEY PATTERN, for a specified TIME DEMAND TYPE. If it exists, it will override the DEFAULT SERVICE JOURNEY RUN TIME and DEFAULT DEAD RUN RUN TIME.

Table 24 – JourneyRunTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyTiming ::> JOURNEY RUN TIME inherits from JOURNEY

TIMING.

«PK» id RunTimeIdType 1:1 Identifier of JOURNEY RUN TIME.

«FK» TimingLinkRef TimingLinkRef 0:1 TIMING LINK associated with timing.

TC 278 WI 00278308:2013 (E)

62

RunTime xsd:duration 1:1 Run time of JOURNEY RUN TIME.

JourneyRunTime_VersionedChildStructure

The time taken to trav erse a TIMING LINK in a particular JO URNEY PA TTERN, for a specified TIME DEMA ND

TYPE. If it exists, it w ill ov erride the DEFA ULT SERV IC E

JO URNEY RUN TIME and DEFA ULT DEA D RUN RUN TIME.

JourneyRunTime

(restriction)

type JourneyRunTime_VersionedChildStructure

attributes


VersionedChildGroup


JourneyTimingGroup

Elements of a JO URNEY RUN TIME.

JourneyRunTimeGroup Reference to a TIMING LINK.

TimingLinkRef

0 1..

type TimingLinkRefStructure

RUN TIME as an interv al.

RunTime

type xsd:duration

Figure 46 — JourneyRunTime — XSD

7.2.4.3.3 JourneyLayover – Model Element

Time allowance at the end of each journey on a specified JOURNEY PATTERN, to allow for delays and for other purposes. This layover supersedes any global layover and may be superseded by a specific VEHICLE JOURNEY LAYOVER.

Table 25 – JourneyLayover – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyTiming ::> JOURNEY LAYOVER inherits from JOURNEY

TIMING.

«PK» id LayoverIdType 1:1 Identifier of JOURNEY LAYOVER.

Layover xsd:duration 0:1 Time spent on JOURNEY LAYOVER.

«FK» PointRef PointRef 1:1 POINT associated with of JOURNEY LAYOVER.

63

JourneyLayoverStructure



purposes. This lay ov er supersedes any global lay over and

may be superseded by a specific V EHIC LE JO URNEY LA YO V ER.

JourneyLayover

(restriction)

type JourneyLayoverStructure

attributes


VersionedChildGroup

Elements of a JO URNEY TIMING.

JourneyTimingGroup

Elements of a JO URNEY LA YO V ER.

JourneyLayoverGroup Lay ov er time as interv al.

Layover

type xsd:duration

Reference to a PO INT.

PointRef

type PointRefStructure

Reference to a TIMING PO INT. If giv en by context does not need to be stated.

TimingPointRef


Figure 47 — JourneyLayover — XSD

7.2.4.3.4 JourneyHeadway – Model Element

Headway frequency information that is available for all the VEHICLE JOURNEY running on the JOURNEY PATTERN for a given TIME DEMAND TYPE, for the journey or at a run at a given TIMING POINT.

This is a default value that can be superseded by VEHICLE JOURNEY HEADWAY. This information shall be consistent with HEADWAY JOURNEY GROUP if available (HEADWAY JOURNEY GROUP being a more detailed way of describing headway services).

Table 26 – JourneyHeadway – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyTiming ::> JOURNEY HEADWAY inherits from JOURNEY

TIMING.

«PK» id HeadwayIdType 1:1 Identifier of JOURNEY HEADWAY.

HeadwayInterval-

Group

HeadwayIntervalGroup 1:1 Set of HEADWAY INTERVALs describing frequency

of JOURNEY.

TC 278 WI 00278308:2013 (E)

64

JourneyHeadway_VersionedChildStructure

Headway interv al information that is av ailable for all the

V EHIC LE JO URNEYs running on the JO URNEY PA TTERN

for a giv en TIME DEMA ND TYPE, at a giv en TIMING

PO INT. This is a default v alue that can be superseded by V EHIC LE JO URNEY HEA DWA Y. This information must be

consistent w ith HEA DWA Y JO URNEY GRO UP if av ailable

(HEA DWA Y JO URNEY GRO UP being a more detailed way

of describing headway serv ices).

JourneyHeadway

(restriction)

type JourneyHeadw ay_VersionedChildStructure

attributes


VersionedChildGroup


JourneyTimingGroup

E lements of a JO URNEY HEA DWA Y Interv al.

Headw ayIntervalGroup

Scheduled normal headway interv al.

ScheduledHeadwayInterval

0 1..

type xsd:duration

M inimum headway interv al.

MinimumHeadwayInterval

0 1..

type xsd:duration

Maximum headway interv al.

MaximumHeadwayInterval

0 1..

type xsd:duration

Figure 48 — JourneyHeadway — XSD

7.2.4.3.5 HeadwayInterval – Model Group

Set of Headway intervals to use to define a headway period.

Table 27 – HeadwayInterval – Group

Classifi

cation

Name Type cardina

lity

Description

ScheduledHeadwayInterval xsd:duration 0:1 Scheduled HEADWAY INTERVAL.

MinimumHeadwayInterval xsd:duration 0:1 Minimum HEADWAY INTERVAL.

MaximumHeadwayInterval xsd:duration 0:1 Maximum HEADWAY INTERVAL.

Ty pe for a HEA DWA Y INTERV A L.

HeadwayIntervalStructure

Elements of a JO URNEY HEA DWA Y Interv al.




type xsd:duration

Minimum headway interv al.


type xsd:duration



type xsd:duration

Figure 49 — HeadwayInterval — XSD

65

7.2.4.3.6 TurnaroundTimeLimit – Model Element

The maximum time for which a vehicle may be scheduled to wait at a particular TIMING POINT (often included in a TURN STATION) without being returned to a PARKING POINT. A minimum time for a vehicle to turn its direction may also be recorded. This may be superseded by a DEAD RUN.

Table 28 – TurnaroundTimeLimitTime – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> JourneyTiming ::> TURNAROUND TIME LIMIT inherits from

JOURNEY TIMING.

«PK» id TurnaroundTimeLimit-

IdType

0:1 Identifier of TURNAROUND TIME LIMIT.

MinimumDuration xsd:duration 0:1 Minimum time needed for turnaround.

MaximumDuration xsd:duration 1:1 Maximum time needed for turnaround.

TurnaroundTimeLimitTime_VersionedChildStructure

The maximum time for which a v ehicle may be scheduled to w ait at a particular TIMING PO INT (often included in a TURN STA TIO N)

w ithout being returned to a PA RKING PO INT. A minimum time for

a v ehicle to turn its direction may also be recorded. This may be

superseded by a DEA D RUN.

TurnaroundTimeLimitTime

(restriction)

type TurnaroundTimeLimitTime_VersionedChildStructure

attributes


VersionedChildGroup


JourneyTimingGroup

TURNA RO UND TIME LIMIT elements.

TurnaroundTimeLimitTimeGroup Minimum turnaround time as an interv al.

MinimumDuration

0 1..

type xsd:duration

Maximum turnaround time as an interv al.

MaximumDuration

0 1..

type xsd:duration

Figure 50 — TurnaroundTimeLimitTime — XSD

7.2.5 Journey Pattern Times

7.2.5.1 JOURNEY PATTERN TIMES – Conceptual MODEL


For any TIMING LINK, run times corresponding to one TIME DEMAND TYPE may be recorded. In some cases, such run times are default run times and if the TIMING LINK is used by several JOURNEY PATTERNs, the default times may be applied any time it is covered by a VEHICLE JOURNEY, regardless the JOURNEY PATTERN.

However, NeTEx allows for a more precise control of run times than is possible by using default times at TIMING LINK level, namely JOURNEY PATTERN RUN TIMEs. A JOURNEY PATTERN RUN TIME is a run time for a TIMING LINK that will be valid only for VEHICLE JOURNEYs made on the specified JOURNEY PATTERN. It overrides the default run times that might have been defined for this TIMING LINK.

TC 278 WI 00278308:2013 (E)

66

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.

A certain time allowance may be given at the end of each VEHICLE JOURNEY, before starting the next one, to compensate delays or for other purposes (e.g. rest time for the driver). This “layover time” can be regarded as a buffer time on a specified JOURNEY PATTERN for the different TIME DEMAND TYPEs. This layover may be superseded by a specific VEHICLE JOURNEY LAYOVER (cf. 5.1.5).

In the case of frequency-based services, another type of information is needed, namely headway duration information. It is given by JOURNEY PATTERN HEADWAY that is available for all the VEHICLE JOURNEYs running on the JOURNEY PATTERN at the TIMING POINTs IN JOURNEY PATTERN depending upon the different TIME DEMAND TYPEs. A more detailed modelling of frequency-based services is described in 5.1.5.

The VEHICLE TYPE PREFERENCE represents a default VEHICLE TYPE proposed for the journeys, depending on the JOURNEY PATTERN covered and the TIME DEMAND TYPE. It is not a truly temporal concept but has to be understood as a proposal to be taken into account for BLOCK compilation. It may be a ranked list of VEHICLE TYPEs for each SERVICE JOURNEY PATTERN and for each DAY TYPE and TIME DEMAND TYPE.

The diagram reminds that all this timing information is to be considered in a specific OPERATIONAL CONTEXT, that expresses the characterization of a set of operational objects, such as timing or links determined either by a DEPARTMENT or by an ORGANISATIONAL UNIT.

67

class NeTEx TM TP Journey Pattern Times MODEL

JOURNEY PATTERN RUN TIME

«PK»

+ id [0..1]

Time Demand Type MODEL::TIME DEMAND TYPEJOURNEY

PATTERN

LAYOVER

«PK»

+ id [0..1]

LINK SEQUENCE

Journey Pattern MODEL::JOURNEY

PATTERN

JOURNEY PATTERN

WAIT TIME

«PK»

+ id [0..1]

Name: NeTEx TM TP Journey Pattern Times MODEL

Author: NeTEx

Version: 1.0

Created: 16/03/2010 11:45:47

Updated: 24/09/2012 10:52:12




PATTERN



POINT IN JOURNEY

PATTERN


TIMING LINK IN JOURNEY

PATTERN

LINK


TIMING LINK

POINT


TIMING POINT

JOURNEY

PATTERN

HEADWAY

«PK»

+ id [0..1]

VEHICLE TYPE

PREFERENCE

+ Rank

«PK»

+ id [0..1]

Serv ice Calendar

MODEL::DAY

TYPE

Serv ice Pattern

MODEL::SERVICE

JOURNEY PATTERN

Transport Organisations MODEL::OPERATIONAL CONTEXT

+viewed as1

+a view

of*

+characterized by 0..*

+characterizing

0..*

+determined for 0..*

+determining 0..1

+used to define 1

+for *

+used to

define

1 +for

*

+used to

define

1 +for

*

+worked using

1

+for 0..*

1

0..* +to

*+end of1

+start of

1

+from

*+characterized by

0..*

+characterizing

0..*

+viewed as 1

+a view of

*

+worked using

1

+assigned to

*

+associated with

1

+applied at

*

+used to define

1

+associated with *

+on 1..*+made up of

1

+the timing

reference for

1

+by default

timed from

0..1

+used to

define

1

+associated with

*

+allowing1

+allowed on

*

+assciated with

*

+used to define

1

+used to define

1

+associated with

*

+covered in 1

+associated with *

+made up of1

+in *

Figure 51 — Journey Pattern Times – Conceptual MODEL (UML)

7.2.5.2 Journey Pattern Times – Physical Model

The physical model is derived from the conceptual model and specialises elements of the JOURNEY TIMING model.

In this case, the value ‘duration’ represents the duration of the different times for the whole JOURNEY PATTERN. In other words, the different ‘durations’ represent time elements (run times, wait times, etc.) for all the VEHICLE JOURNEYs of a certain JOURNEY PATTERN, depending on the time of use, i.e. associated with a TIME DEMAND TYPE or, for users working with TIME BANDs, associated to a particular TIME BAND.

TC 278 WI 00278308:2013 (E)

68

class XSD NeTEx Journey Pattern Times Model contents

LinkSequence


«PK»

id :JourneyPatternIdType [0..1]

«FK»


/DirectionType :DirectionEnum* [0..1]

/DirectionRef :DirectionRef* [0..1]

DestinationDisplayRef :DestinationDisplayRef [0..1]

TypeOfJourneyPatternRef :TypeOfJourneyPatternRef* [0..1]


«contained»

runTimes :JourneyPatternRunTime [0..*]

waitTimes :JourneyPatternWaitTime [0..*]

headways :JourneyPatternHeadway [0..*]

layovers :JourneyPatternLayover [0..*]

pointsInSequence :PointInJourneyPattern [0..*]

l inksInSequence :LinkInJourneyPattern [0..*]

JourneyRunTime



«PK»

id :JourneyPatternRunTimeIdType [0..1]

«FK»

LinkRef :T imingLinkIdType*


JourneyPatternModel::DeadRunPattern

«PK»

id :DeadRunJourneyPatternIdType [0..1]JourneyLayover



«PK»

id :JourneyPatternLayoverIdType [0..1]

«FK»


PointInLinkSequence

JourneyPatternModel::PointInJourneyPattern

«PK»

id :PointInJourneyPatternIdType

«FK»


PointRef :PointRef* [0..1]

DestinationDisplayRef :DestinationDisplayRef* [0..1]

«contained»

vias :Via [0..*]


JourneyWaitTime



«PK»

id :JourneyPatternWaitT imeIdType [0..1]

«FK»


JourneyPatternModel::TimingPointInJourneyPattern

isWaitPoint :boolean

«PK»

id :T imingPointInJourneyPatternId

«FK»

PointRef :TimingPointRef* [0..1]

OnwardTimingLinkRef :TimingLinkRef*

«contained»


waitTimes :JourneyPatternRunTime [0..*]

LinkInLinkSequence



«PK»

id :T imingLinkInJourneyPatternIdType

«FK»

TimingLinkRef :TimingLinkRef*


«contained»

waitTimes :JourneyPatternWaitT ime [0..*]

DataManagedObject




«PK»

id :TimeDemandTypeIdType

«AK»


«contained»

Presentation :Presentation [0..1]

runTimes :JourneyRunTime [0..*]

waitT imes :JourneyWaitT ime [0..*]

layovers :JourneyLayover [0..*]

headways :JourneyHeadway [0..*]

turnaroundTimes :TurnaroundTimeLimit [0..*]

vehiclePreferences :VehiclePreference [0..*]

«FK»


TypeOfTimeDemandTypeRef :TypeOfTimeDemandTypeRef* [0..1]

Link


Mode :VehicileModeEnum [0..1]

«PK»

id :TimingLinkIdType

«FK»

FromPointRef :TimingPointRef*

ToPointRef :T imingPointRef*

OperationalContextRef :OperationalContextRef [0..1]

Point






«PK»


Name: XSD NeTEx Journey Pattern T imes Model contents

Author: NeTEx

Version: 1.0

Created: 05/01/2010 18:53:33

Updated: 12/10/2012 15:22:14

JourneyTiming


JourneyHeadway


JourneyTimingModel::HeadwayInterval




JourneyTiming



Rank :positiveInteger [0..1]

«PK»

id :VehicleTypePreferenceIdType [0..1]

«FK»

VehicleTypeRef :VehicleTypeRef*

DayTypeRef :DayTypeRef* [0..1]



«PK»

id :JourneyPatternHeadwayIdType [0..1]

«FK»

JourneyRef :JourneyPatternRef*

used to define

1

associated

with

*

at every

0..*

passed

1

to

*

end of

1

from 0..*

to

0..1

start

of

1

from

*

associated

with

0..*used to

defineassociated with 0..*

used to define

made

up of

1

in *

viewed as 1

{ordered}

a view of*

0..*

used to define

1

for * viewed as1a view of*

on

1..*

{ordered}

made up of

1

associated with

1

applied at *

view of

0..*

viewed as

1

allowing

1 allowed on*

used to define

1

associated with

*

worked using1

assigned to

*

covered in 1

associated with

*

used to

define

1

associated with

*

0..*


1

by

default

timed

from

0..1

interval

0..*

at

0..1

Figure 52 — Journey Pattern Times – Physical Model (UML)

7.2.5.2.1 Journey Pattern Time hierarchies – Physical Model

The following figures shows the inherited attributes of the various journey timings.

69

class XSD NeTEx Journey Pattern Times Hierarchy

Name: XSD NeTEx Journey Pattern Times Hierarchy

Author: NeTEx

Version: 1.0

Created: 11/01/2010 16:32:54

Updated: 11/04/2012 17:24:49

EntityInVersion

ResponsibilityModel::VersionedChild



«PK»

+ id :JourneyPatternLayoverIdType [0..1]

«FK»

# JourneyPatternRef :JourneyPatternRef*



«PK»

+ id :JourneyPatternRunTimeIdType [0..1]

«FK»

# LinkRef :TimingLinkIdType*




«PK»

+ id :JourneyPatternWaitTimeIdType [0..1]

«FK»



+ Name :Multil ingualString [0..1]

+ VehicleMode :VehicleModeEnum [0..1]

«PK»

~ id :JourneyTimingIdType

«FK»

# TimeDemandTypeRef :TimeDemandTypeRef* [0..1]

# TimebandRef :T imebandRef* [0..1]

# OperationalContextRef :OperationalContextRef* [0..1]


JourneyLayover

+ Layover :duration [0..1]

«PK»

~ id :LayoverIdType

«FK»

# PointRef :PointRef*


JourneyRunTime

+ RunTime :duration

«PK»

~ id :RunTimeIdType

«FK»

# LinkRef :TimingLinkRef* [0..1]


JourneyWaitTime

+ WaitTime :duration

«PK»

~ id :WaitTimeIdType

«FK»

# TimingPointRef :TimingPointRef*



+ Rank :positiveInteger [0..1]

«PK»

+ id :VehicleTypePreferenceIdType [0..1]

«FK»

# VehicleTypeRef :VehicleTypeRef*

# DayTypeRef :DayTypeRef* [0..1]


JourneyHeadway

+ Frequency :HeadwayInterval

«PK»

~ id :HeadwayIdType



«PK»

+ id :JourneyPatternHeadwayIdType [0..1]

«FK»

# JourneyRef :JourneyPatternRef*

JourneyTimingModel::HeadwayInterv al

+ ScheduledHeadwayInterval :duration [0..1]

+ MinimumHeadwayInterval :duration [0..1]

+ MaximumHeadwayInterval :duration [0..1]

Figure 53 — Journey Pattern Times – Physical Model (UML)

7.2.5.3 Journey Pattern Times – Attributes and XSD

7.2.5.3.1 JourneyPatternWaitTime – Model Element

The JOURNEY PATTERN WAIT TIME represents the time a vehicle has to wait at a specific TIMING POINT IN JOURNEY PATTERN, for a specified TIME DEMAND TYPE. This wait time can be superseded by a VEHICLE JOURNEY WAIT TIME.

Table 29 – JourneyPatternWaitTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyWaitTime ::> JOURNEY PATTERN WAIT TIME inherits from

JOURNEY WAIT TIME.

«PK» id JourneyPatternWaitTimeIdType 0:1 Identifier of JOURNEY PATTERN WAIT TIME.

TC 278 WI 00278308:2013 (E)

70

«FK» JourneyRef JourneyPatternRef 1:1 JOURNEY PATTERN with which WAIT TIME is

associated.

JourneyPatternWaitTime_VersionedChildStructure

The time a v ehicle has to wait at a specific TIMING PO INT

IN JO URNEY PA TTERN, for a specified TIME DEMA ND

TYPE. This wait time can be superseded by a V EHIC LE

JO URNEY WA IT TIME.


(restriction)

type JourneyPatternWaitTime_Version...

attributes


VersionedChildGroup


JourneyTimingGroup

E lements of a JO URNEY WA IT TIME.

JourneyWaitTimeGroup

E lements of a JO URNEY PA TTERN WA IT TIME.

JourneyPatternWaitTimeGroup


JourneyPatternRef

0 1..





Figure 54 — JourneyPatternWaitTime — XSD

7.2.5.3.2 JourneyPatternRunTime – Model Element

The JOURNEY PATTERN RUN TIME is the time taken to traverse a TIMING LINK in a particular JOURNEY PATTERN, for a specified TIME DEMAND TYPE. If it exists, it will override the DEFAULT SERVICE JOURNEY RUN TIME and DEFAULT DEAD RUN RUN TIME.

Table 30 – JourneyPatternRunTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyRunTime ::> JOURNEY PATTERN RUN TIME inherits from

JOURNEY RUN TIME.

«PK» id JourneyPatternRunTimeIdType 0:1 Identifier of JOURNEY PATTERN RUN TIME.

«FK» LinkRef TimingLinkRef 1:1 TIMING LINK with which TURNAROUND TIME is

associated.

«FK» JourneyRef JourneyPatternRef 1:1 JOURNEY PATTERN with which TURNAROUND

TIME is associated.

71

JourneyPatternRunTime_VersionedChildStructure

The time taken to trav erse a TIMING LINK in a particular

JO URNEY PA TTERN, for a specified TIME DEMA ND

TYPE If it exists, it w ill ov erride the DEFA ULT SERV IC E

JO URNEY RUN TIME and DEFA ULT DEA D RUN RUN

TIME.


(restriction)

type JourneyPatternRunTime_Version...

attributes


VersionedChildGroup


JourneyTimingGroup

E lements of a JO URNEY RUN TIME.

JourneyRunTimeGroup

E lements of a JO URNEY PA TTERN RUN TIME.

JourneyPatternRunTimeGroup


JourneyPatternRef

0 1..





Figure 55 — JourneyPatternRunTime — XSD

7.2.5.3.3 JourneyPatternLayover – Model Element

The JOURNEY PATTERN LAYOVER is the time allowance at the end of each journey on a specified JOURNEY PATTERN, to allow for delays and for other purposes. This layover supersedes any global layover and may be superseded by a specific VEHICLE JOURNEY LAYOVER.

Table 31 – JourneyPatternLayover – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyLayoverTime ::> JOURNEY PATTERN LAYOVER inherits from

JOURNEY LAYOVER.

«PK» id JourneyPatternLayoverIdType 0:1 Identifier of JOURNEY PATTERN LAYOVER.

«FK» JourneyPatte

rnRef

JourneyPatternRef 1:1 JOURNEY PATTERN with which LAYOVER is

associated.

JourneyPatternLayoverStructure



purposes. This lay ov er supersedes any global lay ov er and

may be superseded by a specific V EHIC LE JO URNEY LA YO V ER.

JourneyPatternLayover

(restriction)

type JourneyPatternLayoverStructure

attributes


VersionedChildGroup


JourneyTimingGroup

E lements of a JO URNEY LA YO V ER.

JourneyLayoverGroup

E lements of a JO URNEY PA TTERN LA YO V ER.

JourneyPatternLayoverGroup


JourneyPatternRef

0 1..





Figure 56 — JourneyPatternLayover — XSD

TC 278 WI 00278308:2013 (E)

72

7.2.5.3.4 JourneyPatternHeadway – Model Element

The JOURNEY PATTERN HEADWAY is the headway frequency information that is available for all the VEHICLE JOURNEYs running on the JOURNEY PATTERN at the different TIMING POINTs IN JOURNEY PATTERN. This is a default value that can be superseded by the VEHICLE JOURNEY HEADWAY on a specific journey.

This information shall be consistent with HEADWAY JOURNEY GROUP if available (HEADWAY JOURNEY GROUP being a more detailed way of describing headway services, cf. 5.1.5).

Table 32 – JourneyPatternHeadway – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> TimeDemandHeadway ::> JOURNEY PATTERN HEADWAY inherits from

TIME DEMAND HEADWAY.

«PK» id JourneyPatternHeadwayIdType 0:1 Identifier of JOURNEY PATTERN HEADWAY.

«FK» JourneyRef JourneyPatternRef 1:1 JOURNEY PATTERN with which HEADWAY is

associated.

JourneyPatternHeadway_VersionedChildStructure

Headway frequency information that is av ailable for all the

V EHIC LE JO URNEY running on the JO URNEY PA TTERN

for a giv en TIME DEMA ND TYPE, for the journey or at a

run at a giv en TIMING PO INT. .

This is a default v alue that can be superseded by V EHIC LE

JO URNEY HEA DWA Y. This information must be consistent

w ith HEA DWA Y JO URNEY GRO UP if av ailable (HEA DWA Y JO URNEY GRO UP being a more detailed way

of describing headw ay serv ices).


(restriction)

type JourneyPatternHeadw ay_Versio...

attributes


VersionedChildGroup


JourneyTimingGroup



E lements of a JO URNEY PA TTERN HEA DWA Y.

JourneyPatternHeadw ayGroup


JourneyPatternRef

0 1..





Reference to a TIMING PO INT. If giv en by context does

not need to be stated.

TimingPointRef

0 1..


Figure 57 — JourneyPatternHeadway — XSD

7.2.5.3.5 VehicleTypePreference – Model Element

The preference for the use of a particular VEHICLE TYPE for a SERVICE JOURNEY PATTERN, depending on the DAY TYPE and TIME DEMAND TYPE. The rank of preferences shall be recorded. Different VEHICLE TYPEs may be given the same rank.

Table 33 – VehicleTypePreference – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> TimeDemandTiming ::> JOURNEY PATTERN HEADWAY inherits from

TIME DEMAND TIMING.

73

«PK» id VehicleType-

PreferenceIdType

0:1 Identifier of VEHICLE TYPE PREFERENCE.

Rank xsd:positiveInteger 1:1 Ranking of VEHICLE TYPE PREFERENCE.

«FK» DayTypeRef DayTypeRef 0:1 DAY TYPE with which PREFERENCE is associated.

«FK» VehicleTypeRef VehicleTypeRef 1:1 VEHICLE TYPE with which PREFERENCE is

associated.

VehicleTypePreference_VersionedChildStructure

The preference for the use of a particular V EHIC LE TYPE for a SERV IC E JO URNEY PA TTERN, depending on the

DA Y TYPE and TIME DEMA ND TYPE. The rank of

preferences must be recorded. Different V EHIC LE TYPEs

may be giv en the same rank.


(restriction)

type VehicleTypePreference_Version...

attributes


VersionedChildGroup


JourneyTimingGroup

E lements for a V EHIC LE TYPE PREFERENC E.

VehicleTypePreferenceGroup

Relativ e ranking of this preference.

Rank

0 1..

type xsd:positiveInteger


DayTypeRef

0 1..


Reference to a V EHIC LE TYPE PREFERENC E.

VehicleTypePreferenceRef

0 1..

type VehicleTypePreferenceRefStruct...

Figure 58 — VehicleTypePreference — XSD

7.2.6 Vehicle Journey Times

7.2.6.1 VEHICLE JOURNEY TIMES – Conceptual MODEL

There may be reasons for needing a more precise control of run and wait times than is possible using the standard times at JOURNEY PATTERN level. Some exception times may be required for a single VEHICLE JOURNEY. For instance, a vehicle may be slowed intentionally on a particular VEHICLE JOURNEY to meet a scheduled interchange. Some companies adjust the times (e.g. wait times, but even run times) to cope with driver scheduling regulations. In the case of a very long VEHICLE JOURNEY, e.g. in a rural area, a single TIME DEMAND TYPE may not apply to the whole journey, because traffic conditions change substantially between its start and end.

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

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

VEHICLE JOURNEY RUN TIME is the time taken to traverse a specified TIMING LINK IN JOURNEY PATTERN on a specified VEHICLE JOURNEY. This gives the most detailed control over times and overrides the DEFAULT SERVICE JOURNEY RUN TIME and JOURNEY PATTERN RUN TIME and the DEFAULT DEAD RUN RUN TIME.

VEHICLE JOURNEY WAIT TIME is the time for a vehicle to wait at a particular TIMING POINT IN JOURNEY PATTERN on a specified VEHICLE JOURNEY. This wait time will override the JOURNEY PATTERN WAIT TIME.

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

TC 278 WI 00278308:2013 (E)

74

VEHICLE JOURNEY HEADWAY is the headway frequency information that is available for a VEHICLE JOURNEY (to be understood as the delay between the previous and the next VEHICLE JOURNEY).

class NeTEx TM TP Vehicle Journey Times MODEL

JOURNEY


JOURNEY

VEHICLE JOURNEY WAIT

TIME

«PK»

+ id [0..1]

VEHICLE JOURNEY

LAYOVER

«PK»

+ id [0..1]

VEHICLE JOURNEY RUN

TIME

«PK»

+ id [0..1]


Journey Pattern MODEL::TIMING

POINT IN JOURNEY PATTERN

LINK SEQUENCE


JOURNEY PATTERN

Name: NeTEx TM TP Vehicle Journey Times MODEL

Author: NeTEx

Version: 1.0

Created: 30/11/2009 10:00:00

Updated: 03/10/2012 15:48:58

VEHICLE JOURNEY

HEADWAY

«PK»

+ id [0..1]

Serv ice

Calendar

MODEL::DAY

TYPE

Time Demand Type

MODEL::TIME

DEMAND TYPE

Vehicle Serv ice

MODEL::BLOCKVehicle Journey

MODEL::DEAD RUN

Transport Organisations MODEL::

OPERATIONAL CONTEXT

Journey Timing MODEL::

JOURNEY TIMING


«PK»

~ id

Journey Timing

MODEL::JOURNEY

LAYOVER

+ Duration [0..1]

«PK»

~ id

Journey Timing

MODEL::JOURNEY

WAIT TIME

+ WaitTime

«PK»

~ id

Journey Timing

MODEL::JOURNEY

HEADWAY

+ Frequency

«PK»

~ id

Journey Timing

MODEL::JOURNEY

RUN TIME

+ RunTime

«PK»

~ id

+asociated with

*

+used to define

0..1

+determining

0..1

+determined by 0..*

+characterized by

0..*

+characterizing

0..1

+determined for

0..*

+determining

0..1

+for

1

+worked

on

*

+worked

on*

+for

1..*

+the timing reference for

1..

+for 0..*

+made using

*

+for

1

+the timing reference for1

+by default timed

from0..1

+timed

from

*


0..1

+worked

using

1

+valid

on *

+allowing

1

+allowed on 0..1

+worked using

1

+valid

on*

+associated with 1

+applied at *

+used by default by *

+made using

*

+including

0..1

+in *

+characterized by

0..*

+characterizing

0..*

Figure 59 — Vehicle Journey Times — Conceptual MODEL (UML)

A more detailed model of frequency-based services is represented in the diagram below. 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 ‘every 10 minutes’ for example. The other possibility is a set of particular ‘rhythm’ services occurring over every hour, for example, services running at ‘xxh10’, ‘xxh25’, ‘xxh45’ past the hour. In either case a TEMPLATE VEHICLE JOURNEY is associated with a JOURNEY FREQUENCY GROUP to represents a group of JOURNEYs running at the given frequency.

Such a behaviour can be conditional upon the TIME DEMAND TYPE and TIME BAND.

75

class NeTExTM TP Frequency Based Serv ice MODEL

JOURNEY


JOURNEY




PATTERN

LINK SEQUENCE


JOURNEY PATTERN

JOURNEY HEADWAY

VEHICLE JOURNEY

HEADWAY

Serv ice Calendar

MODEL::DAY TYPE


DEMAND TYPE


+ HeadwayDisplay [0..1]

«PK»

+ id [0..1]

Vehicle Journey

MODEL::DEAD RUN

JOURNEY RUN TIME

VEHICLE JOURNEY RUN

TIME


SERVICE JOURNEY

JOURNEY FREQUENCY

GROUP

+ FirstDepartureTime

+ LastDepartureTime [0..1]

+ DayOffset [0..1]

«PK»

+ id [0..1]

RHYTHMICAL JOURNEY

GROUP

«PK»

+ id [0..1]

Serv ice Calendar

MODEL::TIME BAND

Vehicle Journey

MODEL::TEMPLATE

VEHICLE JOURNEY

Defines a group of

JOURNEYs in order to

describe special

behavior l ike frequency

based services or

rythmical services (runs

all xxh10, xxh25 and

xxh45... for example;

this is specially useful

for passengenr

information)

Services having the

same "rytm" every hour

(runs al l xxh10, xxh25

and xxh45... for

example)

This is special ly useful

for passengenr

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 passengenr

information.

This is val id for specific


DAY TYPEs (through

the JOURNEY

GROUP).

Name: NeTExTM TP Frequency Based Service MODEL

Author: NeTEx

Version: 1.0

Created: 17/03/2011 15:34:58

Updated: 03/10/2012 15:50:52


MODEL::JOURNEY

PATTERN HEADWAY

HEADWAY

INTERVAL

Serv ice Journey

MODEL::

TEMPLATE

SERVICE

JOURNEY

+for 0..*

+active on 0..*

1

0..*

+worked using

1

+for

0..*

+defines

1..*

+is

defined

by

1..*

+for 0..*

+active on 0..*

+composed of

1..*

+runs

on

0..1

+determined by 0..*

+determining 1

+worked

using

1+val id

on

*

+assciated with

*

+used to define

1

+made

using

*

+used by default by 0..*

+worked

on*

+for

1..*


1..

+for

0..*


+by default timed

from

0..1

+made using

*

+for

1

+timed

from*

+the timing reference for 0..1

+used by default by

*

+made using

*

Figure 60 — Frequency Based Service – Conceptual MODEL (UML)

7.2.6.2 Vehicle Journey Times – Physical Model

The physical model is derived from the conceptual model. For the frequency-based services the concept of JOURNEY FREQUENCY is introduced. It is the frequency at which a given VEHICLE will run at a given TIMING POINT for a given TIME DEMAND TYPE. This frequency supersedes any global frequency or JOURNEY PATTERN FREQUENCY. HEADWAY INTERVAL gives a set of headway intervals to use to define a headway duration. The physical model allows for a link between every VEHICLE JOURNEY with the timing algorithm used to compute times at timing points.

TC 278 WI 00278308:2013 (E)

76

class XSD NeTEx Vehicle Journey Times Model

Name: XSD NeTEx Vehicle Journey Times Model

Author: NeTEx

Version: 1.0

Created: 26/01/2010 15:27:14

Updated: 03/10/2012 20:15:15




«PK»

id :DeadRunIdType

«FK»



«contained»






Journey


DepartureTime :time


«PK»


«contained»






waitT imes :VehicleJourneyWaitTime [0..*]





«FK»



TimeDemandTypeRef :T imeDemandTypeRef* [0..1]

TimingAlgorithmRef :T imingAlgorithmRef* [0..1]






«AK»


VehicleJourneyTimesModel::VehicleJourneyRunTime

«PK»

id :VehicleJourneyRunTimeIdType [0..1]

«FK»


VehicleJourneyTimesModel::


«PK»

id :VehicleJourneyWaitTimeIdType [0..1]

«FK»

JourneyRef :VehicleJourneyRef* [0..1]


JourneyPatternModel::TimingPointInJourneyPattern

LinkSequence


DataManagedObject


DayType



«PK»

id :VehicleJourneyLayoverIdType [0..1]

«FK»


DataManagedObject


DataManagedObject


JourneyTimingModel::JourneyWaitTime

WaitTime :duration

«PK»

id :WaitTimeIdType

«FK»

TimingPointRef :T imingPointRef*


JourneyLayover

Layover :duration [0..1]

«PK»

id :LayoverIdType

«FK»

PointRef :PointRef*


JourneyRunTime

RunTime :duration

«PK»

id :RunTimeIdType

«FK»

LinkRef :TimingLinkRef* [0..1]

VersionedChild




«PK»


«FK»


T imebandRef :T imebandRef* [0..1]


TypeOfValue


TimingAlgorithm

«PK»

id :T imingAlgorithmIdType

DataManagedObject



JourneyHeadway


«PK»

id :HeadwayIdType

al lowing 1

allowed on

0..1

distinguished by 0..*

distinguishes0..1

distinguished

by

0..*

distinguishes

0..1

distinguished by

0..*

distinguishes0..1

journey

0..*

compute using

0..1

0..*

distinguishes 0..1

timing

0..*

made up of

0..1

worked on *

for 1

valid

0..*

day

0..1

timing reference for1

by default timed from 0..1

made using

*

for

1

interval 0..*

at 0..1

timed from* timing reference for0..1

associated with 1

applied at

*

worked using

1

valid on

*

worked using 1

valid

on

*

including 0..1

in *

used by default by

0..1made using*

associated with 0..*

used to define

Figure 61 — Vehicle Journey Times – Physical Model (UML)

The VEHICLE JOURNEY TIMES physical model is directly derived from the conceptual model. However, for convenience of implementation purposes, an additional view element, a CALL is traduced, see later below. This assembles data related to a POINT IN JOURNEY PATTERN, as part of a VEHICLE JOURNEY.

In particular a CALL incorporates information concerning the time a vehicle passes a SCHEDULED STOP POINT or other POINT IN JOURNEY PATTERN. In the case where the PASSING TIMEs are known, this is represented by ‘arrival times’ and ‘departure times’. In the case of frequency-based services, although at an operational level there may still be known arrival and departure times for each journey, they are not necessarily exposed to the user, but rather the timings of vehicles at a stop may be presented as intervals, for example ‘Every 5 to 10 minutes’.

77

class XSD NeTEx TP Call Intro Further

DataManagedObject

DestinationDisplay

NormalDatedVehicleJourney

Name: XSD NeTEx TP Call Intro Further

Author: nickk

Version: 1.0

Created: 07/02/2011 09:38:26

Updated: 20/05/2011 10:55:51

Journey

DatedVehicleJourney

Journey

VehicleJourney

DataManagedObject

DayType

VersionedChild

«view»

Call

PointInLinkSequence


LinkSequence

JourneyPattern


PassingTime


TimingPoint

ScheduledStopPoint

DataManagedObject

StopAssignment

StopPlaceSpace

BoardingPosition::

Quay

Site

StopPlace

VersionedChild

FootnoteAssignment

DataManagedObject

Footnote

Arriv alDeparture

DataManagedObject

Interchange Rule

Serv iceJourney

CallPart

DataManagedObject

JourneyMeeting

DataManagedObject

JourneyPart


TimeDemandHeadway


0..1

note 0..*

applies to

0..*

notes

to *

end of 0..1

using

*

used

by

1

note 0..*

applies to

arrives 0..1

part of

departs 0..1

part of

rules 0..*

apply to

assigns 0..*

for 1

journey to

0..*destination 0..1

0..*

combines from

1

meets 0..*

at

1

met 0..*

at

1

part of

0..*at

passed

at1

at *

using

*used

by

1

using *

used

by1

worked

on

*

for 1

made using *

for 1

at 0..*

show 0..1

Call 0..*

passed

at

1

visit 0..*

at 1

stops

at

0..*

visited by

part of

every 0..1

0..*

quays

for

platform 0..1

start

of

0..1

from *

named by *

advertised for

0..1

/used

by0..1 {Must be same as that of VehicleJoruney}

altered to use

*

using

0..1

for *

at

1

0..1equivalent to

0..1

0..*

for

assigned

to

1

scheduled

0..*

is to

0..1

on

1..*

{ordered}

made up of 1

Figure 62 — Call – Physical Model (UML)

7.2.6.3 Vehicle Journey Times – Attributes and XSD

7.2.6.3.1 VehicleJourneyWaitTime – Model Element

The VEHICLE JOURNEY WAIT TIME is the time for a vehicle to wait at a particular TIMING POINT IN JOURNEY PATTERN on a specified VEHICLE JOURNEY. This wait time will override the JOURNEY PATTERN WAIT TIME.

Table 34 – VehicleJourneyWaitTime – Element

Classifi

cation

Name Type Cardi

nality

Description

::> ::> JourneyWaitTime ::> VEHICLE JOURNEY WAIT TIME inherits from

TC 278 WI 00278308:2013 (E)

78

JOURNEY WAIT TIME.

«PK» id VehicleJourneyWaitTimeIdType 0:1 Identifier of VEHICLE JOURNEY WAIT TIME.

«FK» Vehicle-

JourneyRef

VehicleJourneyRef 0:1 Reference to a VEHICLE JOURNEY with which this

WAIT TIME is associated.

VehicleJourneyWaitTime_VersionedChildStructure

The time for a v ehicle to wait at a particular TIMING

PO INT IN JO URNEY PA TTERN on a specified V EHIC LE

JO URNEY. This wait time w ill ov erride the JO URNEY

PA TTERN WA IT TIME.


(restriction)

type VehicleJourneyWaitTime_Version...

attributes


VersionedChildGroup


JourneyTimingGroup

E lements of a JO URNEY WA IT TIME.

JourneyWaitTimeGroup

E lements for a V EHIC LE JO URNEY WA IT TIME.

VehicleJourneyWaitTimeGroup



VehicleJourneyRef

0 1..



DeadRunRef


Figure 63 — VehicleJourneyWaitTime — XSD

7.2.6.3.2 VehicleJourneyRunTime – Model Element

The VEHICLE JOURNEY RUN TIME is the time taken to traverse a specified TIMING LINK IN JOURNEY PATTERN on a specified VEHICLE JOURNEY. This gives the most detailed control over times and overrides the DEFAULT SERVICE JOURNEY RUN TIME and JOURNEY PATTERN RUN TIME and the DEFAULT DEAD RUN RUN TIME.

Table 35 – VehicleJourneyRunTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyRunTime ::> VEHICLE JOURNEY RUN TIME inherits from

JOURNEY RUN TIME.

«PK» id VehicleJourneyRunTimeId

Type

0:1 Identifier of VEHICLE JOURNEY RUN TIME.

«FK» VehicleJourneyRe

f

VehicleJourneyRef 0:1 VEHICLE JOURNEY for which this is a RUN TIME.

79

VehicleJourneyRunTime_VersionedChildStructure

The time taken to trav erse a specified TIMING LINK IN

JO URNEY PA TTERN on a specified V EHIC LE JO URNEY. This giv es the most detailed control ov er times and ov errides

the DEFA ULT SERV IC E JO URNEY RUN TIME and

JO URNEY PA TTERN RUN TIME and the DEFA ULT DEA D

RUN RUN TIME. There may be different times for different TIME DEMA ND TYPES.

VehicleJourneyRunTime

(restriction)

type VehicleJourneyRunTime_Version...

attributes


VersionedChildGroup


JourneyTimingGroup

E lements of a JO URNEY RUN TIME.

JourneyRunTimeGroup

E lements for a V EHIC LE JO URNEY RUN TIME.

VehicleJourneyRunTimeGroup



VehicleJourneyRef

0 1..



DeadRunRef


Figure 64 — VehicleJourneyRunTime — XSD

7.2.6.3.3 VehicleJourneyLayover – Model Element

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

Table 36 – VehicleJourneyLayover – Element

Classifi

cation

Name Type Cardi

nality

Description

::> ::> JourneyLayover ::> VEHICLE JOURNEY LAYOVER inherits from

JOURNEY LAYOVER.

«PK» id VehicleJourneyLayoverIdType 0:1 Identifier of VEHICLE JOURNEY LAYOVER.

«FK» VehicleJourney

Ref

VehicleJourneyRef 0:1 Reference to a VEHICLE JOURNEY with which this

LAYOVER is associated.

VehicleJourneyLayoverStructure

A time allowance at the end of a specified V EHIC LE

JO URNEY. This time supersedes any global lay ov er or

JO URNEY PA TTERN LA YO V ER.


(restriction)

type VehicleJourneyLayoverStructure

attributes


VersionedChildGroup


JourneyTimingGroup

E lements of a JO URNEY LA YO V ER.

JourneyLayoverGroup

E lements for a V EHIC LE JO URNEY LA YO V ER.

VehicleJourneyLayoverGroup

Reference to a V EHIC LE JO URNEY. If giv en by context does not need to be repeated.

VehicleJourneyRef

0 1..



DeadRunRef


Figure 65 — VehicleJourneyLayover — XSD

TC 278 WI 00278308:2013 (E)

80

7.2.6.3.4 TimingAlgorithm – Model Element

Timing algorithm used to compute times at timing points.

Table 37 – TimingAlgorithm – Element

Classifi


ality Description

::> ::> TypeOfValue ::> TIMING ALGORITHM inherits from TYPE OF

VALUE.

«PK» id TimingAlgorithmIdType 1:1 Identifier of TIMING ALGORITHM.

TimingAlgorithmType_ValueStructure

C lassification of a TIMING A LGO RITHM.

TimingAlgorithmType

(restriction)

type TimingAlgorithmType_ValueStruct...

attributes


O RGA NISA TIO N.



TypeOfValueGroup

Figure 66 — TimingAlgorithmType — XSD

7.2.6.4 Vehicle Journey Frequency

7.2.6.4.1 Vehicle Journey Frequency – Conceptual MODEL

Often in passenger information systems there is a requirement to show multiple journeys as a single column in a timetable for example “And then every 20 minutes until 6 pm”. The JOURNEY FREQUENCY model allows groups of journeys to be aggregated using a TEMPLATE JOURNEY and an overall frequency to be specified for them, using either a HEADWAY JOURNEY GROUP (e.g. ‘every 10 minutes’) or a RHYTHMICAL JOURNEY GROUP – one that runs at a regular interval past the hour (for example ‘xxh10’, ‘xxh25’ and ‘xxh45’).

Even though every scheduled VEHICLE JOURNEY has a specific set of PASSING TIMEs that it will run to, these will not necessarily be revealed to the passenger and a JOURNEY FREQUENCY can be used to present the journey as frequency based.

For passenger information purposes it is possible to exchange a TEMPLATE VEHICLE JOURNEY without any concrete VEHICLE JOURNEYs.

81

class NeTExTM TP Frequency Based Serv ice MODEL

JOURNEY


JOURNEY




PATTERN

LINK SEQUENCE


JOURNEY PATTERN

JOURNEY HEADWAY

VEHICLE JOURNEY

HEADWAY

Serv ice Calendar

MODEL::DAY TYPE


DEMAND TYPE


+ HeadwayDisplay [0..1]

«PK»

+ id [0..1]

Vehicle Journey

MODEL::DEAD RUN

JOURNEY RUN TIME

VEHICLE JOURNEY RUN

TIME


SERVICE JOURNEY

JOURNEY FREQUENCY

GROUP

+ FirstDepartureTime

+ LastDepartureTime [0..1]

+ DayOffset [0..1]

«PK»

+ id [0..1]

RHYTHMICAL JOURNEY

GROUP

«PK»

+ id [0..1]

Serv ice Calendar

MODEL::TIME BAND

Vehicle Journey

MODEL::TEMPLATE

VEHICLE JOURNEY

Defines a group of

JOURNEYs in order to

describe special

behavior l ike frequency

based services or

rythmical services (runs

all xxh10, xxh25 and

xxh45... for example;

this is special ly useful

for passengenr

information)

Services having the

same "rytm" every hour

(runs all xxh10, xxh25

and xxh45... for

example)

This is special ly useful

for passengenr

information.

This is valid for specific


DAY TYPE (through

the JOURNEY

GROUP).

Services runing with a

regular interval (every

10 mn... for example)

This is specially useful

for passengenr

information.

This is val id for specific


DAY TYPEs (through

the JOURNEY

GROUP).

Name: NeTExTM TP Frequency Based Service MODEL

Author: NeTEx

Version: 1.0

Created: 17/03/2011 15:34:58

Updated: 03/10/2012 15:50:52


MODEL::JOURNEY

PATTERN HEADWAY

HEADWAY

INTERVAL

Serv ice Journey

MODEL::

TEMPLATE

SERVICE

JOURNEY

+for 0..*

+active on 0..*

1

0..*

+worked using

1

+for

0..*

+defines

1..*

+is

defined

by

1..*

+for 0..*

+active on 0..*

+composed of

1..*

+runs

on

0..1

+determined by 0..*

+determining 1

+worked

using

1+valid

on

*

+assciated with

*

+used to define

1

+made

using

*

+used by default by 0..*

+worked

on*

+for

1..*


1..

+for

0..*


+by default timed

from

0..1

+made using

*

+for

1

+timed

from*

+the timing reference for 0..1

+used by default by

*

+made using

*

Figure 67 — Vehicle Journey Frequency – Conceptual Model (UML)

7.2.6.4.2 Vehicle Journey Frequency – Physical Model

The following figure shows the Physical model for VEHICLE JOURNEY FREQUENCY with detailed attributes.

TC 278 WI 00278308:2013 (E)

82

class XSD NeTEx Frequency Based Serv ices Model


HeadwayJourneyGroup

HeadwayInterval :HeadwayInterval [0..1]

HeadwayDisplay :HeadwayUseEnum [0..1]

«PK»

id :HeadwayJourneyGroupIdType [0..1]

GroupOfEntities

VehicleJourneyFrequencyModel::JourneyFrequencyGroup

FirstDepartureTime :time

LastDepartureTime :time [0..1]

DayOffset :DayOffsetType [0..1]

«PK»

id :FrequencyGroupIdType [0..1]

«contains»

timeDemandTypes :TimeDemandRef* [0..1]

journeys :VehicleJourneyRef [0..*]



«PK»

id :RhythmicalJourneyGroupIdType [0..1]

«contains»

timebands :Timeband [1..*]


Serv iceJourneyModel::TemplateServ iceJourney

«PK»

id :TemplateServiceJourneyIdType [0..1]

DataManagedObject


TimeDemandType

Journey





LinkSequence


JourneyPattern

VehicleJourneyFrequencyModel::VehicleJourneyHeadway

«PK»

id :VehicleJourneyHeadwayIdType [0..1]

«FK»

JourneyRef :VehicleJourneyIdType* [0..1]

TimimngPointInPatternRef :T imingPointInPatternRef*

JourneyRunTime

VehicleJourneyTimesModel::VehicleJourneyRunTime

«PK»

id :VehicleJourneyRunTimeIdType [0..1]

«FK»



Serv iceJourney

DataManagedObject


DataManagedObject

Serv iceCalendarModel::Timeband

StartTime :time

EndTime :time

DayOffset :DayOffsetType [0..*]

Duration :duration [0..*]

«PK»

id :T imebandIdType






JourneyHeadway


«PK»

id :HeadwayIdType

VersionedChild


«enumeration»

VehicleJourneyFrequencySupport::

HeadwayUseEnum

DisplayPassingTimesOnly

DisplayAsWellAsPassingTimes

DisplayInsteadOfPassingTimes

Name: XSD NeTEx Frequency Based Services Model

Author: NeTEx

Version: 1.0

Created: 19/05/2011 14:28:51

Updated: 12/10/2012 15:26:42


JourneyFrequency

Frequency :HeadwayIntervalsGroup

HeadwayDisplay :HeadwayDisplayEnum [0..1]

FrequencyRegulated :boolean [0..1]




timing

0..*

happens during

0..1

0..*

made

using*

for 1

worked using

1

valid on *

interval 0..*

at 0..1

worked on *for

1

0..*

on 0..*day type

associated with

0..*

used to define

composed of

1..*

runs on

0..1

active during

defines

1..*

is

defined

by

1..*

runs on

0..*


1

by

default

timed

from

0..1

timing 0..*

made up of 0..1

used by default by 0..1

made using *

used by 0..*

uses

0..*

timed

from*


0..1

0..*associated

with

1

associated with 0..*

used to define

83

Figure 68 — Vehicle Journey Frequency – Physical Model (UML)

7.2.6.5 Vehicle Journey Frequency – Attributes and XSD

7.2.6.5.1 JourneyFrequencyGroup – Model Element

JOURNEY FREQUENCY GROUP defines a set of JOURNEYs in order to describe special frequency behaviour like frequency based services or rhythmical services (one that runs at a regular interval past the hour, for example ‘xxh10’, ‘xxh25’ and ‘xxh45’; this is especially useful for passenger information).

Table 38 – JourneyFrequencyGroup – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> GroupOfEntities ::> JOURNEY FREQUENCY GROUP inherits from

GROUP OF ENTITies.

«PK» id FrequencyGroupIdType 0:1 Identifier of FREQUENCY GROUP.

FirstDeparture-

Time

xsd:time 1:1 Time of first departure in FREQUENCY GROUP.

LastDeparture-

Time

xsd:time 0:1 Time of last departure in FREQUENCY GROUP.

DayOffset xsd:integer 0:1 Offset of end time day from start time.

«cntd» timeDemand-

Types

TimeDemandRef 0:1 TIME DEMAND TYPEs for which this FREQUENCY

GROUP applies.

«cntd» journeys VehicleJourneyRef 0:* Journeys belonging to FREQUENCY GROUP.

TC 278 WI 00278308:2013 (E)

84

JourneyFrequencyGroup_VersionStructure

A group of JO URNEYs defined in order to describe special

behav iour like frequency based serv ices or rhy thmical

serv ices (runs all xxh10, xxh25 and xxh45... for example; this

is especially useful for passenger information).


type JourneyFrequencyGroup_VersionStructure

attributes


O RGA NISA TIO N.


E lements of a GRO UP O F ENTITies.


E lements for a JO URNEY FREQ UENC Y GRO UP.

JourneyFrequencyGroupGroup

Time of first departure in JO URNEY FREQ UENC Y GRO UP.

FirstDepartureTime

type xsd:time

Time of last departure in JO URNEY FREQ UENC Y GRO UP.

LastDepartureTime

type xsd:time

O ffset day s for end time. Number of day s after the starting

departure time of the journey if not same calendar day .

Default is 0 for same day .

DayOffset

type DayOffsetType

TIME DEMA ND TYPES associated w ith JO URNEY

FREQ UENC Y GRO UP.

timeDemandTypes

type timeDemandTypeRefs_RelStructure

TIME DEMA ND TYPES associated w ith JO URNEY

FREQ UENC Y GRO UP.

journeys

type explicitJourneyRefs_RelStructure

Defines a group of JO URNEYs in order to describe special

F requency behav ior like frequency based serv ices or

rhy thmical serv ices (runs all xxh10, xxh25 and xxh45... for

example; this is specially useful for passenger information)

HeadwayJourneyGroup

type Headw ayJourneyGroup_VersionStructure

A group of V EHIC LE JO URNEYS follow ing the same

JO URNEY PA TTERN hav ing the same "rhy thm" ev ery

hour (for example runs all xxh10, xxh25 and xxh45... e)

between a specified start and end time.


type RhythmicalJourneyGroup_VersionStructure

Figure 69 — JourneyFrequencyGroup — XSD

7.2.6.5.2 HeadwayJourneyGroup – Model Element

A group of VEHICLE JOURNEYs following the same JOURNEY PATTERN and having the same headway interval between a specified start and end time (for example, ‘every 10 minutes’). This is especially useful for presenting passenger information.

Table 39 – HeadwayJourneyGroup – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyFrequencyGroup ::> HEADWAY JOURNEY GROUP inherits from

JOURNEY FREQUENCY GROUP.

«PK» id HeadwayJourney-

GroupIdType

0:1 Identifier of HEADWAY JOURNEY GROUP.

Scheduled-

HeadwayInterval

xsd:duration 0:1 Scheduled normal HEADWAY INTERVAL.

85

Minimum-

HeadwayInterval

xsd:duration 0:1 Minimum HEADWAY INTERVAL.

Maximum-

HeadwayInterval

xsd:duration 0:1 Maximum HEADWAY INTERVAL.

HeadwayDisplay HeadwayUseEnum 0:1 How headway is to be displayed to passengers.

Description MultilingualString 0:1 Description of Headway Journey Groups.

Headw ayJourneyGroup_VersionStructure

Defines a group of JO URNEYs in order to describe special

F requency behav ior like frequency based serv ices or

rhy thmical serv ices (runs all xxh10, xxh25 and xxh45... for

example; this is specially useful for passenger information)

HeadwayJourneyGroup

(restriction)

type Headw ayJourneyGroup_VersionStructure

attributes


O RGANISA TIO N.


Elements of a GRO UP O F ENTITies.


Elements for a JO URNEY F REQ UENC Y GRO UP.


Elements for a HEA DWA Y JO URNEY GRO UP.

Headw ayJourneyGroupGroup

Elements of a JO URNEY HEA DWA Y Interv al.


Scheduled normal headw ay interv al.

ScheduledHeadw ayInterval

0 1..

type xsd:duration



0 1..

type xsd:duration


MaximumHeadw ayInterval

0 1..

type xsd:duration

How headway v alue should be display ed to public.

Headw ayDisplay

0 1..

type Headw ayUseEnumeration

Text to describe interv al.

Description

0 1..


Figure 70 — HeadwayJourneyGroup — XSD

7.2.6.5.2.1 HeadwayDisplay – Allowed values

The following table shows the allowed values for HeadwayDisplay (HeadwayDisplayEnum).

Table 40 – HeadwayDisplay – Allowed values

Value Description

displayInsteadOfPassingTimes Display intervals instead of passing times.

displayAsWellAsPassingTimes Display intervals as well as passing times.

displayPassingTimesOnly Display only passing times.

7.2.6.5.3 RhythmicalJourneyGroup – Model Element

A group of VEHICLE JOURNEYs following the same JOURNEY PATTERN having the same "rhythm" every hour (for example, ‘runs at xxh10, xxh25 and xxh45 past the hour’) between a specified start and end time.

TC 278 WI 00278308:2013 (E)

86

Table 41 – RhythmicalJourneyGroup – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> JourneyFrequencyGroup ::> RHYTHMICAL JOURNEY GROUP inherits from

JOURNEY FREQUENCY GROUP.

«PK» id RhythmicalJourney-

GroupIdType

0:1 Identifier of RHYTHMICAL JOURNEY GROUP.

«cntd» timebands Timeband 1:* Timebands describing RHYTHMICAL FREQUENCY

GROUP. Each specifies some minutes past the

hour.

RhythmicalJourneyGroup_VersionStructure

A group of V EHIC LE JO URNEYS follow ing the same

JO URNEY PA TTERN hav ing the same "rhy thm" ev ery

hour (for example runs all xxh10, xxh25 and xxh45... e)

between a specified start and end time.


(restriction)

type RhythmicalJourneyGroup_VersionStructure

attributes


O RGA NISA TIO N.


Elements of a GRO UP O F ENTITies.


Elements for a JO URNEY FREQ UENC Y GRO UP.


Elements for a Rhy thmical JO URNEY GRO UP.

RhythmicalJourneyGroupGroup

TIMEBA NDS associated w ith JO URNEY F REQ UENCY

GRO UP.

timebands

0 1..

type timebandRefs_RelStructure

Figure 71 — RhythmicalJourneyGroup — XSD

7.2.6.5.4 VehicleJourneyHeadway – Model Element

VEHICLE JOURNEY HEADWAY describes the headway frequency information to use when presenting an individual VEHICLE JOURNEY (to be understood as the delay between the previous and the next VEHICLE JOURNEY). This information shall be consistent with HEADWAY JOURNEY GROUP if the JOURNEY is part of a FREQUENCY GROUP.

Table 42 – VehicleJourneyHeadway – Element

Classifi


ality Description

::> ::> HeadwayInterval ::> VEHICLE JOURNEY HEADWAY inherits from

HEADWAY INTERVAL.

«PK» id VehicleJourney-

HeadwayIdType

0:1 Identifier of VEHICLE JOURNEY HEADWAY.

«FK» JourneyRef VehicleJourneyRef 0:1 Reference to JOURNEY associated with VEHICLE

JOURNEY HEADWAY.

«FK» TimingPoint-

InPatternRef

TimingPointInPatternRef 1:1 Reference to a TIMING POINT in JOURNEY

PATTERN associated with VEHICLE JOURNEY

HEADWAY.

87

VehicleJourneyHeadway_VersionedChildStructure

A frequency at which a giv en V EHIC LE JO URNEY w ill run. This

frequency supersedes any global frequency or JO URNEY PA TTERN

FREQ UENC Y.


(restriction)

type VehicleJourneyHeadw ay_VersionedChildStructure

attributes


VersionedChildGroup


JourneyTimingGroup



E lements for a V EHIC LE JO URNEY FREQ UENC Y.

VehicleJourneyHeadw ayGroup



VehicleJourneyRef

0 1..



DeadRunRef


Reference to a TIMING PO INT IN JO URNEY PA TTERN.

If giv en by context does not need to be stated.

TimingPointInJourneyPatternRef

0 1..

type TimingPointInJourneyPatternRefStructure

Figure 72 — VehicleJourneyHeadway — XSD

7.2.6.5.5 JourneyFrequency – Model Element

JOURNEY FREQUENCY describes a frequency at which a given VEHICLE will run at a given TIMING POINT for a given TIME DEMAND TYPE. This frequency supersedes any global frequency or JOURNEY PATTERN FREQUENCY.

Table 43 – JourneyFrequency – Element

Classifi

cation

Name Type Cardin-

ality

Description

Description MultilingualString 0:1 Text description to use for frequency. E.g. ‘Every

five minutes’.

ScheduledHeadw

ayInterval

duration 0:1 Scheduled normal HEADWAY INTERVAL.

Minimum-

HeadwayInterval

duration 0:1 Minimum HEADWAY INTERVAL.

Maximum-

HeadwayInterval

duration 0:1 Maximum HEADWAY INTERVAL.

FrequencyRegulat

ed

boolean 0:1 Whether frequency falls under regulatory agreement

or not.

HeadwayDisplay HeadwayUseEnum 0:1 Use to be made of HEADWAY INTERVAL

information when displaying to public. Default is

'Display Instead of Passing Times'.

TC 278 WI 00278308:2013 (E)

88

Ty pe for a HEA DWA Y INTERV A L.

FrequencyStructure





type xsd:duration



type xsd:duration



type xsd:duration

Use to be made of Headway information when display ing to

public. Default is Display Instead of Passing Times.

HeadwayDisplay

type Headw ayUseEnumeration

Whether serv ice falls under regulations for frequency serv ice.

FrequencyRegulated

type xsd:boolean

Descriptiv e phrase to use for frequency . e.g. "Ev ery x

minus" If not specified generate from indiv idual elements.

Description


Figure 73 — JourneyFrequency — XSD

7.2.6.6 XML Example of Frequency Journeys

7.2.6.6.1 Frequency Journey Group - XML Example

The following code fragment shows a TEMPLATE VEHICLE JOURNEY two different frequency groups.

For EXAMPLE

<TemplateServiceJourney version="any" id="hde:tvjh_24o_01">


<dayTypes>

<DayTypeRef version="any" ref="hde:DT_01MTWTFSS"/>

</dayTypes>

<ServicePatternRef ref="hde:svp_24o">EXTERNAL</ServicePatternRef>

<LineRef version="any" ref="mybus:Line:LN_234"/>

<calls>

<Call id="hde:tvjh_24o_02_001" version="any" order="1">


<Arrival>


</Arrival>

<Departure>

<Time>10:20:00.0Z</Time>

</Departure>

</Call>



<Arrival>

<Time>11:20:00.0Z</Time>

</Arrival>

<Departure>

<Time>11:22:00.0Z</Time>

<WaitTime>PT2M</WaitTime>

</Departure>

</Call>



<Arrival>

<Time>12:20:00.0Z</Time>

89

</Arrival>

<Departure>


</Departure>

</Call>

</calls>

<frequencyGroups>

<HeadwayJourneyGroup version="any" id="hde:hjg_24o_01">

<Name>Regular Interval service between 10am and 12:00 pm</Name>

<Description>About every 12 minutes</Description>

<FirstDepartureTime>10:00:00</FirstDepartureTime>

<LastDepartureTime>12:00:00</LastDepartureTime>

<ScheduledHeadwayInterval>PT12M</ScheduledHeadwayInterval>

<HeadwayDisplay>DisplayInsteadOfPassingTimes</HeadwayDisplay>

</HeadwayJourneyGroup>

<HeadwayJourneyGroup version="any" id="hde:hjg_24o_02">


<Description>About every 20 minutes</Description>




<HeadwayDisplay>DisplayInsteadOfPassingTimes</HeadwayDisplay>

</HeadwayJourneyGroup>

</frequencyGroups>

</TemplateServiceJourney>

7.2.6.6.2 Rhythmical Journey Group - XML Example

The following code fragment shows a TEMPLATE VEHICLE JOURNEY with a RHYTHMICAL JOURNEY GROUP.

For EXAMPLE

<TemplateServiceJourney version="any" id="hde:tvj_24o_02">


<dayTypes>

<DayTypeRef version="any" ref="hde:DT_01MTWTFSS"/>

</dayTypes>

<ServicePatternRef ref="hde::jp_24o"/>


<calls>

<Call id="hde:tvj_24o_02_001" version="any" order="1">


<Arrival>


</Arrival>

<Departure>

<Time>10:20:00.0Z</Time>

</Departure>

<Frequency>


</Frequency>

</Call>

<Call id="hde:Ca:tvj_24o_02_002" version="any" order="2">


<Departure>

<Time>11:22:00.0Z</Time>

</Departure>

<Frequency>


</Frequency>

</Call>

<Call id="hde:tvj_24o_02_003" version="any" order="3">


<Arrival>

<Time>12:20:00.0Z</Time>

</Arrival>

<Departure>


</Departure>

<Frequency>


TC 278 WI 00278308:2013 (E)

90

</Frequency>

</Call>

</calls>

<frequencyGroups>

<RhythmicalJourneyGroup version="any" id="hde:rjg_24o_01">


<Description>At 20 & 45 Minutes past the hour </Description>



<timebands>

<TimebandRef version="any" ref="hde:TM_20"/>

<TimebandRef version="any" ref="hde:TM_45"/>

</timebands>

</RhythmicalJourneyGroup>

</frequencyGroups>

</TemplateServiceJourney>

7.2.7 Interchange

7.2.7.1 INTERCHANGE – Conceptual MODEL


In order to reach the destination of a trip if there is no direct service between the origin and the destination SCHEDULED STOP POINTs, a passenger will have to interchange between vehicles. A transfer will be necessary where the passenger will leave the vehicle at a particular SCHEDULED STOP POINT and enter another vehicle (which serves another SERVICE JOURNEY, usually on a different LINE) at the same or another SCHEDULED STOP POINT.

Each SERVICE JOURNEY INTERCHANGE involves two different SERVICE JOURNEYs. The passenger makes the transfer from a feeder SERVICE JOURNEY to a distributor (“fetcher”) SERVICE JOURNEY.

Sometimes both SERVICE JOURNEYs are planned to stop at exactly the same SCHEDULED STOP POINT but usually there are two different (but nearby) SCHEDULED STOP POINTs involved. In such a case, these SCHEDULED STOP POINTs will often (but need not necessarily) belong to the same STOP AREA. Passengers will have to walk a certain distance after disembarking from the feeder SERVICE JOURNEY to reach the stop position of the distributor SERVICE JOURNEY.

A CONNECTION expresses that there is a possible walking link that is suitable for a passenger to interchange from one public transport vehicle to another between two specified SCHEDULED STOP POINTs and the time allocated for a passenger to traverse the link.

Software used to control guaranteed interchanges can use the time information given to use a CONNECTION link as to assist calculating how long a distributor SERVICE JOURNEY needs to wait after a fetcher SERVICE JOURNEY has arrived before it can depart. If no specific CONNECTION link is available, timings from a DEFAULT CONNECTION may be used.

The connection time information could also be used for passenger information such as in travel planners, however sometimes more detailed information about timings and suitable paths adapted to the individual traveller’s specific preferences and capabilities is necessary. In that case additional information can be retrieved from attributes related to the physical model, such as PATH LINKs and NAVIGATION PATHs (see NeTEx Part 1).

In some cases a SERVICE JOURNEY INTERCHANGE expresses an interchange between two SERVICE JOURNEYs specifically planned to be operated by the same physical vehicle. This concept is for instance used for circular lines and coupled journeys. This means that passenger information should be adapted to the fact that the passenger should not change vehicle as the transfer is implicit. In this case it is also important that operation control staff is aware of the consequences to passengers if the operation is altered in such a way that two different vehicles are used for the two involved SERVICE JOURNEYs.

In real-time operation, interchanges that are advertised to the public should be controlled. For instance, vehicles may sometimes have to wait if the arriving vehicle in an interchange is delayed. The company will

91

probably define certain rules and instructions for drivers on how to react in case of deviations from the planned schedule.

The SERVICE JOURNEY INTERCHANGE may be used to store some information on the planned interchange between two SERVICE JOURNEYs such as if it is advertised or not, if it is guaranteed or not and the maximum time a vehicle may wait for a connecting vehicle, beyond the planned departure time.

class NeTEx TM TP Interchange MODEL

JOURNEY MEETING


+ LatestTime

+ Earl iestTime [0..1]

+ Reason [0..1]

«PK»

+ id

SERVICE JOURNEY INTERCHANGE

+ ControlCentreNotifyThreshold [0..1]

«PK»

+ IdSERVICE JOURNEY

PATTERN INTERCHANGE

«PK»

+ id


SERVICE JOURNEY

JOURNEY


JOURNEY

POINT

Serv ice Pattern MODEL::

SCHEDULED STOP POINT

JOURNEY PATTERN

Serv ice Pattern

MODEL::SERVICE

JOURNEY PATTERN

Name: NeTEx TM TP Interchange MODEL

Author: NeTEx

Version: 1.0

Created: 22/10/2010 19:20:15

Updated: 27/03/2012 18:02:50

INTERCHANGE

+ Name [0..1]


+ Priority [0..1]

+ StaySeated [0..1]

+ CrossBorder [0..1]

+ Planned [0..1]

+ Guaranteed [0..1]

+ Advertised [0..1]

+ Control led [0..1]

«PK»

+ id

Notice Assignment

MODEL::NOTICE

ASSIGNMENT

Notice MODEL::NOTICE

SITE

Stop Place MODEL::

STOP PLACE

Stop Assignment MODEL::STOP

ASSIGNMENT

TRANSFER

Serv ice Pattern

MODEL::

CONNECTION

DEFAULT INTERCHANGE

+ Description

+ MaximumDuration [0..1]

+ StandardDuration [0..1]

«PK»

+ id

Service Pattern

MODEL::

CONNECTION END

Interchange Rule MODEL::

INTERCHANGE RULE

PARAMETER

Interchange Rule MODEL::

INTERCHANGE RULE

Generic Validity MODEL::VALIDITY

CONDITION

0..*

neighbour

of0..*

+applicable for

*

+defined for

*

+assigned

by0..*

+marked

by1

+applicable for

0..*

+defined for

*

+distributing 1

+defining distributor for*

+for

0..*

+to

1

+using 0..*

+used as

0..1

+applicable for

0..*

+for

0..*

+start of

1

+from

*

+for 0..*

+at

0..1

+start of1

+from

*

+to

*

+end of

1

+feeding 1

+defining

feeder for*

+using*

+used

by

1

+for 0..*

+to 1

+start of 1

+from *

+start of1

+from *

+start of 1

+from *

+to *

+end of 1

+assigned

to

*

+marked

by

0..1

+combining *

+combined

in

*

+to *

+end of 1

+a view of 0..*

+viewed as 1

+to

*+end of1

+to *

+end of

1

+concerning

*

+concerned by1..*

+to *

+end

of1

+start of

1

+from *

Figure 74 — Interchange – Conceptual MODEL (UML)

7.2.7.1.1 Default Timings for Interchanges

Some timing values for SERVICE JOURNEY INTERCHANGEs may be derived from other NeTEx elements during the planning and scheduling processing.

TC 278 WI 00278308:2013 (E)

92

When optimising the start times of the SERVICE JOURNEYs, the scheduler has to take into account certain parameters affecting service quality, for example the influence of passenger waiting times at interchanges on their total travel times. Ideally the waiting times for passengers at interchanges resulting from the journey schedule should be as short as possible, allowing for necessary transfer time. But on the other hand, the public transport company has to provide its service efficiently, according to a limited number of vehicles available. Thus the waiting times of passengers at interchanges, resulting from the schedule, will be a compromise between what is desirable and what is possible. In order to find the best compromise, certain quality parameters are defined that have to be taken into account by the journey optimisation and synchronisation process, and by journey planning engines when computing possible journeys. The entity DEFAULT INTERCHANGE is used to store such quality parameters. It is recorded against a SCHEDULED STOP POINT where passengers may leave a vehicle and a second SCHEDULED STOP POINT where they can proceed to enter a second vehicle. It may be used for any pair of SERVICE JOURNEYs serving respectively the first and the second SCHEDULED STOP POINT.

One of the stored parameters is the maximum duration that would be allowed for an interchange. If this maximum duration is exceeded for a pair of SERVICE JOURNEYs serving the two SCHEDULED STOP POINTs, this will no longer be regarded as a possible interchange between these journeys. In this situation, the scheduler will perhaps be warned by the system and be asked to retime these journeys; otherwise these journeys may not be advertised as connected at the specified 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.

7.2.7.1.2 Journey meetings and Interchanges

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

Organisation of a meeting (hub) between several services, during a defined time band; this is a simplified specification of several interchanges. If needed this could be described in detail using several INTERCHANGE RULEs or SERVICE JOURNEY INTERCHANGEs.

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

A JOURNEY MEETING may be related to one or several SERVICE JOURNEYs, which are planned according to this JOURNEY MEETING. It may be timed by an earliest time (e.g. the arrival time of a feeder line, plus the duration of a possible transfer) or by a latest time (e.g. the opening hour of the school served by the journey), or both (e.g. the time band of a hub).

A JOURNEY MEETING is located at one or several STOP POINTs, which shall be also classified as TIMING POINTs. It is planned in principle for VEHICLE JOURNEYs specified for the same DAY TYPE. The timing reference of these VEHICLE JOURNEYs will probably be chosen according to the JOURNEY MEETING specified.

In NeTEx consequences of any DEFAULT INTERCHANGE or JOURNEY MEETING used in the planning phase that needs to be exchanged should be expressed as the resulting SERVICE JOURNEY timings, INTERCHANGE RULEs and/or SERVICE JOURNEY INTERCHANGEs.

7.2.7.1.3 Service Journey Pattern Interchange

Sometimes, the scheduled possibility to interchange needs to be differentiated, depending on the SERVICE JOURNEY PATTERNs involved. The SERVICE JOURNEY PATTERN INTERCHANGE specifies such an interchange between two particular SERVICE JOURNEY PATTERNs and a corresponding pair of SCHEDULED STOP POINTs, which shall be served by the respective JOURNEY PATTERNs. The quality level to be aimed at will certainly depend on the service frequency on each

93

SERVICE JOURNEY PATTERN. If these frequencies are more or less similar, the default values can be used as maximum and standard duration of interchange times. If the frequency is very low on one SERVICE JOURNEY PATTERN and considerably higher on another, the situation is different. An interchange waiting time of 13 minutes may be acceptable for passengers if the buses only run every two hours on a particular SERVICE JOURNEY PATTERN, but would not be a good solution if the buses run every 15 minutes.

The SERVICE JOURNEY PATTERN INTERCHANGE may be used to store some information on the planned interchange between two SERVICE JOURNEY PATTERNs (level of priority, advertised or not, guaranteed or not). It allows as well to store the quality parameters (maximum and standard duration) to be used for scheduling of SERVICE JOURNEYs, which will override any default parameter.

Thus the SERVICE JOURNEY PATTERN INTERCHANGE could in some instances be used during the planning phase to decide the actual timings of involved SERVICE JOURNEYs to be exchanged.

It is possible to exchange the SERVICE JOURNEY PATTERN INTERCHANGE through NeTEx using the INTERCHANGE RULE (see later chapter). Alternatively the consequences of the SERVICE JOURNEY PATTERN INTERCHANGE could be applied and exchanged as the resulting SERVICE JOURNEY INTERCHANGEs.

7.2.7.1.3.1 Interchange Rule

There is also a close relation between SERVICE JOURNEY INTERCHANGE and INTERCHANGE RULE. In the physical model the SERVICE JOURNEY INTERCHANGE expresses an interchange between two specified SERVICE JOURNEYs, while the INTERCHANGE RULE (which is described in a later chapter) expresses interchanges where only one or none of the both SERVICE JOURNEYs are specified explicitly.

7.2.7.2 Interchange – Physical Model

The INTERCHANGE physical model describes SERVICE JOURNEY INTERCHANGEs and CONNECTION links and how they relate to the SERVICE JOURNEY and SCHEDULED STOP POINT. It includes detailed attributes:

StaySeated expresses that the distributor and feeder SERVICE JOURNEYs are the same physical vehicle.

Planned expresses that the interchange is planned.

Advertised expresses that the interchange should be advertised to the public.

Guaranteed expresses that it is guaranteed that the feeder SERVICE JOURNEY will wait for the distributor SERVICE JOURNEY.

7.2.7.2.1 Use of Interchange times

MaximumWaitTime expresses the maximum duration a distributor SERVICE JOURNEY should delay its departure time waiting for a feeder ServiceJourney.

If specified, the ExplictTransferTime attribute of the SERVICE JOURNEY INTERCHANGE overrides the DefaultDuration for the CONNECTION. This value expresses the default duration allocated for a passenger to transfer, normally by walking, from the SCHEDULED STOP POINT of the feeder SERVICE JOURNEY to the SCHEDULED STOP POINT of the distributor SERVICE JOURNEY. The default transfer time of the passenger should be added to the feeder SERVICE JOURNEY forecasted arrival time to decide if the distributor Service Journey will exceed the MaximumWaitTime when waiting for passengers from the delayed distributor.

TC 278 WI 00278308:2013 (E)

94

class XSD NeTEx TP Serv ice Interchange Model

DataManagedObject

DefaultInterchange

Description :MultlingualString

MaximumDuration :duration [0..1]

StandardDuration :duration [0..1]

«PK»

id :DefaultInterchangeIdType

«FK»

FromPointRef :ScheduledStopPointRef*

ToPointRef :ScheduledStopPointRef*

DataManagedObject

JourneyMeeting

Description :Mul tlingualString [0..1]

LatestTime :time

EarliestTime :time [0..1]

Reason :ReasonForMeetingEnum [0..1]

«PK»

id :JourneyMeetingIdType

«FK»

AtStopPointRef :ScheduledStopPointRef*

FromJourneyRef :VehicleJourneyRef*

ToJourneyRef :VehicleJourneyRef*

FromPointInJourneyPatternRef :PointInJourneyPatternRef* [0..1]

ToPointInJourneyPatternRef :PointInJourneyPatternRef* [0..1]

Name: XSD NeTEx TP Service Interchange Model

Author: NeTEx

Version: 1.0

Created: 25/09/2010 19:02:41

Updated: 12/10/2012 15:28:00

Journey

VehicleJourney

TimingPoint

ScheduledStopPoint

DataManagedObject

StopAssignment


FromVisitNumber :integer [0..1]

ToVisitNumber :integer [0..1]

«PK»

Id :ServiceJourneyInterchangeIdType

«FK»

JourneyPatternInterchangeRef :ServiceJourneyPatternInterchangeIdType*

FromJourneyRef :ServiceJourneyRef*

ToJourneyRef :ServiceJourneyRef*




FromVisitNumber :integer [0..1]

ToVisitNumber :integer [0..1]

«PK»

id :ServiceJourneyPatternInterchangeIdType

«FK»

FromJourneyPatternRef :ServiceJourneyPatternRef*

ToJourneyPatternRef :ServiceJourneyPatternRef*



Serv iceJourney

JourneyPattern

Serv iceJourneyPattern

Transfer

Connection

DataManagedObject

Interchange

Name :MultlingualString [0..1]

Description :MultlingualString [0..1]

Priori ty :InterchangePriorityType [0..1]

StaySeated :boolean [0..1]

CrossBorder :boolean [0..1]

Planned :boolean [0..1]

Guaranteed :ConnectionCertaintyEnum [0..1]

Advertised :boolean [0..1]

Controlled :boolean [0..1]

TransferModes :AccessModeEnum [0..1]

«PK»

id :InterchangeIdType

«AK»


«FK»

ConnectionRef :ConnectionRef* [0..1]

«contained»

Timings :InterchangeTimings [0..*]


VersionedChild

NoticeAssignment

PointInLinkSequence


«enumeration»

AccessModeEnum

foot

bicycle

boat

car

taxi

shuttle

«enumeration»

ConnectionCertaintyEnum

guaranteed

normallyGuaranteed

notGuaranteed

neverGuaranteed

DataManagedObject

ValidityCondition

«ImplementAsGroup»

InterchangeTimes

StandardWaitTime :duration [0..1]

MaximumWaitTime :duration [0..1]

MaximumAutomaticWindow :duration [0..1]

StandardTransferTime :duration [0..1]

MinimumTransferTime :duration [0..1]

MaximumTransferTime :duration [0..1]

ControlCentreNotifyThreshold :duration [0..1]

when

0..*

val id

interchange

0..*

at 0..1

connects0..*

at 0..1

start of

1

from

0..*

changing 0..*

using 0..1

to *

end of 1

restricting

* defined for

*

start of

0..1

from

*

0..1

equivalent to

0..1

to *

end of

0..1

met

0..*

at 1

meets 0..*

at 1

assigned

to0..*

marked

by

to

0..*

end of

1

combining

0..*

combined in

1

0..*

combines from

1

assigned

to0..*

marked

by

to *

end of 1

to*

end of

1

to

*

end of

1

note

0..*

appl ies to

assignment

0..*

of 1

concerning*

concerned by

1..*start of

1

from

*

start of 1

from *

start of

1

from

*

start of

1

from

*

start of1

from *

to

*

end of

1

Figure 75 — Service Interchange – Physical Model (UML)

7.2.7.3 Interchange – Attributes and XSD

7.2.7.3.1 DefaultInterchange – Model Element

A quality parameter fixing the acceptable duration (standard and maximum) for an interchange to be planned between two STOP POINTs. This parameter will be used to control whether any two VEHICLE JOURNEYs serving those points may be in connection.

Table 44 – DefaultInterchange – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> DEFAULT INTERCHANGE inherits from DATA

MANAGED OBJECT

«PK» id DefaultInterchangeIdType 1:1 Identifier of DEFAULT INTERCHANGE.

Description MultilingualString 1:1 Description of JOURNEY MEETING.

MaximumDuration xsd:duration 0:1 Maximum wait time for DEFAULT INTERCHANGE.

StandardDuration xsd:duration 0:1 Standard wait time for DEFAULT INTERCHANGE.

«FK» FromPointRef ScheduledStopPointRef 1:1 SCHEDULED STOP POINT from which the

95

DEFAULT INTERCHANGE starts.

«FK» ToPointRef ScheduledStopPointRef 1:1 SCHEDULED STOP POINT at which the DEFAULT

INTERCHANGE ends.

DefaultInterchange_VersionStructure

A quality parameter fixing the acceptable duration (standard

and maximum) for an INTERC HA NGE to be planned

between two SC HEDULED STO P PO INTs. This parameter

w ill be used to control whether any tw o VEHIC LE

JO URNEYs serv ing those points may be in connection.

DefaultInterchange

(restriction)

type DefaultInterchange_VersionStructure

attributes


O RGA NISATIO N.


DefaultInterchangeGroup

SC HEDULED STO P PO INT feeding INTERC HA NGE. If

absent apply to all STO P PO INTs.

FromStopPointRef

0 1..

type ScheduledStopPointRefStructure

SC HEDULED STO P PO INT distributing from

INTERC HA NGE. If absent apply to all STO P PO INTs.

ToStopPointRef

0 1..


Description of INTERC HA NGE.

Description

0 1..


E lements for INTERC HA NGE WA IT TIME.

InterchangeWaitTimeGroup

S tandard wait time for INTERC HA NGE.

StandardWaitTime

0 1..

type xsd:duration

Maximum wait time for INTERCHA NGE.

MaximumWaitTime

0 1..

type xsd:duration

Maximum automatic wait time for INTERC HA NGE.

MaximumAutomaticWaitTime

0 1..

type xsd:duration

E lements for INTERC HA NGE TRA NSFER duration.

InterchangeTransferDurationGroup

Standard transfer duration for INTERC HA NGE.

StandardTransferTime

0 1..

type xsd:duration

Maximum transfer duration for INTERC HA NGE.

MinimumTransferTime

0 1..

type xsd:duration


MaximumTransferTime

0 1..

type xsd:duration

Figure 76 — DefaultInterchange — XSD

7.2.7.3.2 Interchange – Model Element

The scheduled possibility for transfer of passengers between two SERVICE JOURNEYs at the same or different STOP POINTs.

Table 45 – Interchange – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> INTERCHANGE inherits from DATA MANAGED

OBJECT.

«PK» id InterchangeIdType 1:1 Identifier of INTERCHANGE.

Name MultilingualString 0:1 Name of INTERCHANGE.

Description MultilingualString 0:1 Description of INTERCHANGE.

TC 278 WI 00278308:2013 (E)

96

«AK» PrivateCode xsd:normalizedString 0:1 Alternative key for INTERCHANGE.

«AK» External-

InterchangeRef


INTERCHANGE specifically for use in AVMS

systems.


«FK» ConnectionRef ConnectionRef 0:1 CONNECTION link over which the interchange

takes place.

Priority InterchangePriorityType 0:1 Priority assigned to INTERCHANGE.

StaySeated xsd:boolean 0:1 Whether passengers can stay seated to make

INTERCHANGE.

CrossBorder xsd:boolean 0:1 Whether INTERCHANGE involves crossing a

national border.

Planned xsd:boolean 0:1 Whether INTERCHANGE is planned.

Guaranteed ConnectionCertaintyEnum 0:1 Whether INTERCHANGE is guaranteed, that is

distributor services may be held in order to ensure

the connection.

Advertised xsd:boolean 0:1 Whether INTERCHANGE is advertised to the public.

Controlled xsd:boolean 0:1 Whether INTERCHANGE is controlled.

«cntd» Interchange-

TimesGroup

InterchangeTimesGroup 0:* Timings that apply to the INTERCHANGE.

TransferModes AccessModeEnum 0:1 Out of vehicle TRANSPORT MODEs by which

transfer at the interchange can be made. See

Reusable components.

«cntd» notice-

Assignments

NoticeAssignmentView 0:* NOTICE ASSIGNMENTs that apply to the

INTERCHANGE.

97

Interchange_VersionStructure

The scheduled possibility for transfer of passengers between

two SERV IC E JO URNEYs at the same or different STO P

PO INTs.

Interchange

(extension)

type Interchange_VersionStructure

attributes


O RGA NISA TIO N.


E lements for INTERC HA NGE.

InterchangeGroup

Name of INTERC HA NGE RULE.

Name


Description of SC HEDULED STO P PO INT feeding

INTERC HA NGE.

Description


A priv ate code that uniquely identifies the element. May be

used for inter-operating w ith other (legacy ) sy stems.

PrivateCode

type PrivateCodeStructure

A n alternativ e code that uniquely identifies the

INTERC HA NGE. Specifically for use in A V MS sy stems. For

V DV compatibility .

ExternalInterchangeRef


Reference to a C O NNEC TIO N Link ov er which the

INTERC HA NEG takes place.

ConnectionRef

type ConnectionRefStructure

Priority to assign to this INTERC HA NGE.

Priority

type InterchangePriorityType

E lements for INTERC HA NGE - detailed properties.

InterchangePropertyGroup

Time Elements for SERV IC E JO URNEY INTERC HA NGE.

InterchangeTimesGroup

A C C ESS MO DES by which the transfer can be made

transferModes

type AccessModeListOfEnumerations

NO TIC Es of an interchange.

noticeAssignments


Figure 77 — Interchange — XSD

7.2.7.3.2.1 InterchangePropertyGroup — Group

E lements for JO URNEY MEETING describing detailed

properties.

JourneyMeetingPropertiesGroup

Description of JO URNEY MEETING.

Description


Earliest time for JO URNEY MEETING.

EarliestTime

type xsd:time

Latest time for JO URNEY MEETING.

LatestTime

type xsd:time

Reason for JO URNEY MEETING.

Reason

type ReasonForMeetingEnumeration

Figure 78 — InterchangePropertyGroup — XSD

TC 278 WI 00278308:2013 (E)

98

Table 46 – InterchangeTimesGroup – Element

Classifi

cation

Name Type Cardin-

ality

Description

StandardWaitTime xsd:duration 0:1 Standard Time to wait at Interchange.

MaximumWaitTime xsd:duration 0:1 Maximum time that DISTRIBUTOR will wait after its

planned departure time.

MaximumAutomatic-

Window

xsd:duration 0:1 Maximum window for holding DISTRIBUTOR will

wait.

StandardTransferTime xsd:duration 0:1 Standard Time needed for transfer.

MinimumTransferTime xsd:duration 0:1 Minimum Time needed for transfer.

MaximumTransferTime xsd:duration 0:1 Maximum Time needed for transfer.

ControlCentre-

NotifyThreshold

xsd:duration 0:1 Interval before CONTROL CENTRE should be

notified associated with SERVICE JOURNEY

INTERCHANGE.

7.2.7.3.2.2 InterchangeTimesGroup — Group

Time Elements for SERV IC E JO URNEY INTERC HA NGE.




Standard wait time for INTERC HA NGE.

StandardWaitTime

type xsd:duration

Maximum wait time for INTERC HA NGE.

MaximumWaitTime

type xsd:duration



type xsd:duration



Standard transfer duration for INTERC HA NGE.


type xsd:duration


MinimumTransferTime

type xsd:duration


MaximumTransferTime

type xsd:duration

Interv al before C O NTRO L C ENTRE should be notified

associated w ith SERV IC E JO URNEY INTERC HA NGE.

ControlCentreNotifyThreshold

type xsd:duration

Figure 79 — InterchangeTimesGroup — XSD

7.2.7.3.2.3 ConnectionCertainty – Allowed values

The following table shows the allowed values for ConnectionCertainty (ConnectionCertaintyEnum).

99

Table 47 – ConnectionCertainty – Allowed values

Value Description

guaranteed The connection is guaranteed under any circumstances.

normallyGuaranteed The connection is normally guaranteed, although the connection time available is shorter than the

location connection time.

notGuaranteed The connection is not guaranteed, although the connection time available is longer than the location

connection time.

neverGuaranteed The connection is never guaranteed, although the connection time available is longer than the

location connection time

7.2.7.3.3 ServiceJourneyInterchange – Model Element

The scheduled possibility for transfer of passengers between two SERVICE JOURNEYs at the same or different STOP POINTs.

Table 48 – ServiceJourneyInterchange – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> Interchange ::> SERVICE JOURNEY INTERCHANGE inherits from

INTERCHANGE.

«PK» id ServiceJourney-

InterchangeIdType

1:1 Identifier of SERVICE JOURNEY INTERCHANGE.


interchange starts.

FromVisitNumber xsd:integer 0:1 Visit number of feeder journey (only needed if

multiple visits).

«FK» ToPointRef ScheduledStopPointRef 1:1 SCHEDULED STOP POINT to which the

interchange goes.

ToVisitNumber xsd:integer 0:1 Visit number of distributor journey (only needed if

multiple visits).

«FK» FromJourneyRef ServiceJourneyRef 1:1 Reference to feeder SERVICE JOURNEY from

which interchange is made.

«FK» ToJourneyRef ServiceJourneyRef 1:1 Reference to distributor SERVICE JOURNEY to

which interchange is made.

«FK» ServiceJourneyPa

ttern-

InterchangeRef

ServiceJourneyPattern-

InterchangeRef

1:1 Reference to SERVICE JOURNEY PATTERN

INTERCHANGE for which interchange is made.

TC 278 WI 00278308:2013 (E)

100

ServiceJourneyInterchange_VersionStructure

The scheduled possibility for transfer of passengers between

two SERV IC E JO URNEYs at the same or different STO P

PO INTs.

ServiceJourneyInterchange

(restriction)

type ServiceJourneyInterchange_Vers...

attributes


O RGANISA TIO N.


E lements for INTERC HANGE.

InterchangeGroup

Elements for SERV IC E JO URNEY INTERCHA NGE.

ServiceJourneyInterchangeGroup

E lements for INTERC HANGE.

InterchangeEndpointGroup

0 1..

SCHEDULED STO P PO INT feeding INTERC HANGE.

FromPointRef


V isit number to distinguish which v isit to F RO M

SC HEDULED STO P PO INT this is. Default is one. O nly

needed for circular routes w ith connections at the same stop

on different v isits.

FromVisitNumber

0 1..

type xsd:nonNegativeInteger

SCHEDULED STO P PO INT distributing from

INTERCHA NGE.

ToPointRef


V isit number to distinguish which v isit to TO SC HEDULED STO P PO INT this is. Default is one. O nly needed for

circular routes w ith connections at the same stop on different

v isits.

ToVisitNumber

0 1..


V EHIC LE JO URNEY that feeds the INTERC HA NGE.

FromJourneyRef


V EHIC LE JO URNEY that distributes from the

INTERCHA NGE.

ToJourneyRef


Reference to a SERV ICE JO URNEY PATTERN

INTERC HA NGE.

ServiceJourneyPatternInterchan...

0 1..

type ServiceJourneyPatternInterchang...

Figure 80 — ServiceJourneyInterchange — XSD

7.2.7.3.4 ServiceJourneyPatternInterchange – Model Element

A recognised/organised possibility for passengers to change public transport vehicles using two STOP POINTs (which may be identical) on two particular SERVICE JOURNEY PATTERNs, including the maximum wait duration allowed and the standard to be aimed at. These may supersede the times given for the DEFAULT INTERCHANGE. Schedulers may use this entity for synchronisation of journeys.

Table 49 – ServiceJourneyPatternInterchange – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> Interchange ::> SERVICE JOURNEY PATTERN INTERCHANGE

inherits from INTERCHANGE.

«PK» id ServiceJourneyPattern-

InterchangeIdType

1:1 Identifier of SERVICE JOURNEY PATTERN

INTERCHANGE.

MaximumDuration xsd:duration 0:1 Maximum duration of a transfer for SERVICE

JOURNEY PATTERN INTERCHANGE.

StandardDuration xsd:duration 0:1 Standard duration of a transfer for SERVICE

JOURNEY PATTERN INTERCHANGE.


interchange starts.

FromVisitNumber xsd:integer 0:1 Visit number of feeder journey (only needed if

multiple visits).

101

«FK» ToPointRef ScheduledStopPointRef 1:1 SCHEDULED STOP POINT to which the

interchange goes.

ToVisitNumber xsd:integer 0:1 Visit number of distributor journey (only needed if

multiple visits).

«FK» FromJourney-

PatternRef

ServiceJourneyPatternRef 1:1 Feeder SERVICE JOURNEY PATTERN from which

SERVICE JOURNEY PATTERN INTERCHANGE is

made.

«FK» ToJourneyPattern

Ref

ServiceJourneyPatternRef 1:1 Distributor SERVICE JOURNEY PATTERN to which

SERVICE JOURNEY PATTERN INTERCHANGE is

made.

ServiceJourneyPatternInterchange_VersionStructure

A recognised/organised possibility for passengers to change

public transport v ehicles using two STO P PO INTs (which

may be identical) on two particular SERV IC E JO URNEY PA TTERNs, including the maximum w ait duration allowed

and the standard to be aimed at. These may supersede the times giv en for the DEFA ULT INTERC HA NGE. Schedulers

may use this entity for sy nchronisation of journey s.

ServiceJourneyPatternInterchange

(restriction)

type ServiceJourneyPatternInterchang...

attributes


O RGA NISA TIO N.


Elements for INTERC HA NGE.

InterchangeGroup

Elements for SERV IC E JO URNEY PA TTERN INTERC HA NGE.

ServiceJourneyPatternInterchangeGroup


InterchangeEndpointGroup

SC HEDULED STO P PO INT feeding INTERC HA NGE.

FromPointRef


V isit number to distinguish which v isit to FRO M

SC HEDULED STO P PO INT this is. Default is one. O nly needed for circular routes w ith connections at the same stop

on different v isits.

FromVisitNumber

0 1..


SC HEDULED STO P PO INT distributing from

INTERC HA NGE.

ToPointRef


V isit number to distinguish which v isit to TO SC HEDULED STO P PO INT this is. Default is one. O nly needed for

circular routes w ith connections at the same stop on different v isits.

ToVisitNumber

0 1..


JO URNEY PA TTERN that feeds INTERC HA NGE.

FromJourneyPatternRef


JO URNEY PA TTERN that distributes from INTERCHA NGE.

ToJourneyPatternRef


Figure 81 — ServiceJourneyPatternInterchange — XSD

7.2.7.3.5 JourneyMeeting – Model Element

A time constraint for one or several SERVICE JOURNEYs fixing interchanges between them and/or an external event (e.g. arrival or departure of a feeder line, opening time of the theatre, etc.).

Table 50 – JourneyMeeting – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> JOURNEY MEETING inherits from DATA

MANAGED OBJECT

«PK» id JourneyMeetingIdType 1:1 Identifier of JOURNEY MEETING.

«FK» AtPointRef ScheduledStopPointRef 1:1 POINT at which MEETING can take place.

TC 278 WI 00278308:2013 (E)

102

«FK» FromJourneyRef VehicleJourneyRef 1:1 Inbound feeder JOURNEY that meets.

«FK» ToJourneyRef VehicleJourneyRef 1:1 Outbound distributor JOURNEY that meets.

Description MultiLingualString 0:1 Description of JOURNEY MEETING.

EarliestTime xsd:time 0:1 Latest time at which MEETING can take place.

LatestTime xsd:time 1:1 Earliest time at which MEETING can take place.

Reason ReasonForMeetingEnum 0:1 Reason for JOURNEY MEETING.

«FK» FromPointIn-

JourneyPatternRe

f

PointInJourneyPatternRef 0:1 POINT IN JOURNEY PATTERN of Inbound feeder

JOURNEY that meets.

«FK» ToPointInJourney

PatternRef

PointInJourneyPatternRef 0:1 POINT IN JOURNEY PATTERN of outbound

distributor JOURNEY that meets.

JourneyMeeting_VersionStructure

A time constraint for one or sev eral SERV IC E JO URNEYs fixing interchanges between them and/or an external ev ent

(e.g. arriv al or departure of a feeder line, opening time of the theatre, etc.).

JourneyMeeting

(restriction)

type JourneyMeeting_VersionStructure

attributes


O RGA NISA TIO N.


Elements for JO URNEY MEETING.

JourneyMeetingGroup

Name of Journey meeting.

Name

0 1..


SC HEDULED STO P PO INT at which JO URNEY MEETING

takes place.

AtStopPointRef

0 1..


V EHIC LE JO URNEY that feeds JO URNEY MEETING.

FromJourneyRef


V EHIC LE JO URNEY that distributes from JO URNEY

MEETING.

ToJourneyRef


E lements for JO URNEY MEETING describing detailed properties.


C onnection Elements for JO URNEY MEETING describing

the connecting JO URNEY.

JourneyMeetingConnectionGroup

Figure 82 — JourneyMeeting — XSD

103

7.2.7.3.5.1 JourneyMeetingPropertiesGroup — Group


properties.


Description of JO URNEY MEETING.

Description


Earliest time for JO URNEY MEETING.

EarliestTime

type xsd:time

Latest time for JO URNEY MEETING.

LatestTime

type xsd:time

Reason for JO URNEY MEETING.

Reason

type ReasonForMeetingEnumeration

Figure 83 — JourneyMeetingPropertiesGroup — XSD

TC 278 WI 00278308:2013 (E)

104

7.2.7.3.5.2 JourneyMeetingConnectionGroup— Group

C onnection E lements for JO URNEY MEETING describing



Reference to C O NNEC TIO N at w hich JO URNEY

MEETING takes place.

ConnectionRef

type ConnectionRefStructure

SC HEDULED STO P PO INT to which JO URNEY

MEETING connects if different from current stop

interchange.

ConnectingStopPointRef

0 ∞..


Name of C O NNETC ING STO P PO INT.

ConnectingStopPointName

0 ∞..


Reference to a JO URNEY.

JourneyRef

type JourneyRefStructure

Reference to a DA TED V EHIC LE JO URNEY.

DatedVehicleJourneyRef



ServiceJourneyRef





Reference to a SPEC IA L SERV IC E.

SpecialServiceRef

type SpecialServiceRefStructure



VehicleJourneyRef



DeadRunRef


S implified v iew of C O NNEC TING JO URNEY.

ConnectingJourneyView

type ConnectingJourney_DerivedView ...

LINE that is being met


LineRef


Reference to a FLEXIBLE LINe.

FlexibleLineRef

type FlexibleLineRefStructure

S implified v iew of connecting LINE.

ConnectingLineView

type Line_DerivedView Structure

Figure 84 — JourneyMeetingConnectionGroup— XSD

105

7.2.7.3.5.3 ReasonForMeeting – Allowed values

The following table shows the allowed values for ReasonForMeeting (ReasonForMeetingEnum).

Table 51 – ReasonForMeeting – Allowed values

Value Description

joining Meeting is joining of two services.

splitting Meeting is splitting of two services.

tariffSection Meeting is for start of a Tariff Section

serviceFacility Meeting is for start of service Facilities.

7.2.7.3.6 JourneyMeetingView – Model Element

A JourneyMeetingView provides a view of a JOURNEY MEETING including derived attributes. See JOURNEY MEETING and INTERCHANGE for a description of attributes.

JourneyMeeting_DerivedViewStructure

Simplified v iew of JO URNEY MEETING.

JourneyMeetingView

type JourneyMeeting_DerivedView Str...

attributes

Reference to a JO URNEY MEETING.

JourneyMeetingRef

type JourneyMeetingRefStructure


properties.


Maximum w ait time for JO URNEY MEETING.

MaximumWaitTime

type xsd:duration

C onnection E lements for JO URNEY MEETING describing



E lements for INTERC HA NGE - detailed properties.

InterchangePropertyGroup

Whether the passenger can remain in v ehicle (i.e. block

linking). Default is false: the passenger must change vehicles

for this INTERC HA NGE.

Default is false.

StaySeated

type xsd:boolean

Whether INTERC HA NGE inv olv es crossing an international

border.

Default is false.

CrossBorder

type xsd:boolean

E lements for INTERC HA NGE management - detailed

properties.

InterchangeManagementGroup

Whether INTERC HA NGE is planned in a timetable.

Default is true.

Planned

type xsd:boolean

Whether INTERC HA NGE is guaranteed. Default is false.

Guaranteed

type xsd:boolean

Whether INTERC HA NGE is adv ertised as an interchange.

Default is true.

Advertised

type xsd:boolean

Whether INTERC HA NGE is controlled in real-time.

Default is true.

Controlled

type xsd:boolean

Timings for the transfer.

TransferDuration

type TransferDurationStructure

Figure 85 — JourneyMeetingView — XSD

TC 278 WI 00278308:2013 (E)

106

7.2.7.3.7 ConnectingJourneyView – Model Element

ConnectingJourneyView provides a view of a CONNECTING JOURNEY including derived attributes.

ConnectingJourney_DerivedViewStructure

S implified v iew of C O NNEC TING JO URNEY.

ConnectingJourneyView

type ConnectingJourney_DerivedView ...

attributes

Serv ice Journey to which srev ice connects

ServiceJourneyRef


Time of Departure.

DepartureTime

type xsd:time

F requency of departure.

Frequency


Name of journey .

Name


S implified v iew of a DESTINA TIO N DISPLA Y. Includes

deriv ed properties of the DESTINA TIO N DISPLA Y.

DestinationDisplayView

type DestinationDisplay_DerivedView ...


DayTypeRef



JourneyPatternRef









ServicePatternRef


O rder of Point w ithin C onnecting journey as an absolute

number.

ConnectingOrder


O rder of Point w ithin C onnecting as number of v isits to the same stop. Default is 1.

ConnectingVisitNumber


Figure 86 — ConnectingJourneyView — XSD

107

7.2.7.4 XML Example of Interchanges

7.2.7.4.1 Service Journey Interchange - XML Example

The following code fragment shows two SERVICE JOURNEY INTERCHANGEs.

For EXAMPLE

<journeyInterchanges>

<ServiceJourneyInterchange version="any" id="hde:sji_24o_01_to_46o_01">

<Description>15:00 Change for Romeo </Description>

<ConnectionRef version="any" ref="mybus:cx_SSP_002"/>

<StaySeated>false</StaySeated>

<Planned>true</Planned>

<Guaranteed>false</Guaranteed>

<Advertised>true</Advertised>

<Controlled>false</Controlled>

<StandardWaitTime>PT30M</StandardWaitTime>

<MaximumWaitTime>PT35M</MaximumWaitTime>

<StandardTransferTime>PT1M</StandardTransferTime>

<MinimumTransferTime>PT1M</MinimumTransferTime>

<FromPointRef version="any" ref="mybus:SSP_002"/>

<ToPointRef version="any" ref="mybus:SSP_002"/>

<FromJourneyRef version="any" ref="hde:sj_24o_01"/>

<ToJourneyRef version="any" ref="hde:sj_46o_01"/>

</ServiceJourneyInterchange>

<ServiceJourneyInterchange version="any" id="hde:sji_24o_02_to_46o_02">

<Description>16:00 Change for Romeo </Description>

<ConnectionRef version="any" ref="mybus:cx_SSP_002"/>

<StaySeated>false</StaySeated>




<Controlled>false</Controlled>





<FromPointRef version="any" ref="mybus:SSP_002"/>

<ToPointRef version="any" ref="mybus:SSP_002"/>




7.2.7.4.2 Journey Meeting - XML Example

The following code fragment shows tow SERVICE JOURNEY MEETINGs.

For EXAMPLE

<journeyMeetings>

<JourneyMeeting version="any" id="hde:jm_24o_46o_01">

<AtStopPointRef version="any" ref="mybus:SSP_002"/>



<Description>Transfer to route 46</>

<EarliestTime>14:30:00.0Z</EarliestTime>

<LatestTime>14:35:00.0Z</LatestTime>

</JourneyMeeting>

<JourneyMeeting version="any" id="hde:jm_24o_46o_02">

<AtStopPointRef version="any" ref="mybus:SSP_002"/>



<Description>Transfer to route 46</Description>

<EarliestTime>15:30:00.0Z</EarliestTime>

<LatestTime>15:35:00.0Z</LatestTime>

</JourneyMeeting>

</journeyMeetings>

TC 278 WI 00278308:2013 (E)

108

7.2.8 Interchange Rule

7.2.8.1 INTERCHANGE RULE – Conceptual MODEL

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 instead provides enough details so that eligible SERVICE JOURNEY INTERCHANGEs can be determined at a later stage after the scheduling is completed. This later stage could be when two schedules from different sources are coordinated in an integrator system, or in real time in a system considering late re-scheduling and delays of involved LINEs.

As described earlier, a SERVICE JOURNEY INTERCHANGE involves two different SERVICE JOURNEYs. The passenger has the possibility to transfer from a feeder SERVICE JOURNEY at a SCHEDULED STOP POINT to a distributor SERVICE JOURNEY at the same or nearby SCHEDULED STOP POINT.

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

This means that it is not an easy task for a scheduler to keep track of the exact details of the SERVICE JOURNEY at the other end of an intended interchange as the SERVICE JOURNEY at the other end might be altered, deleted or replaced at any time.

Instead of trying to keep track of such external changes and continuously readjust the schedule with the details of the external SERVICE JOURNEY, it is easier in this case to use 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 specifies criteria that a candidate SERVICE JOURNEY shall fulfil to be considered. Examples of such criteria are working on a certain LINE in a specific DIRECTION. There could also be criteria relating to time of day or matching a specified SERVICE JOURNEY identifier. Which criteria or combination of criteria that are used will differ for different use cases.

In the same way it is possible to filter on which SCHEDULED STOP POINTs the INTERCHANGE RULE applies. The SCHEDULED STOP POINT of the feeder and distributor SERVICE JOURNEY are defined separately. Instead of specifying a SCHEDULED STOP POINT, it is possible to specify a STOP AREA. This is interpreted as that any SCHEDULED STOP POINT within that STOP AREA is accepted for the related SERVICE JOURNEY. The STOP AREA construction is useful when the exact details of where the vehicle is planned to stop are not known in advance, or might change at a late stage.

Finally there is also a final matching criterion, the maximum interchange window duration. This is used to filter out pairs of feeder and distributor SERVICE JOURNEYs where the feeder is planned to arrive so much earlier than the distributor is planned to depart, that the combination is not of interest as a SERVICE JOURNEY INTERCHANGE.

109

class NeTEx TM TP Interchange Rule MODEL

INTERCHANGE RULE

JOURNEY


JOURNEY

POINT

Serv ice Pattern

MODEL::SCHEDULED

STOP POINT

Name: NeTEx TM TP Interchange Rule MODEL

Author: NeTEx

Version: 1.0

Created: 06/06/2011 16:43:39

Updated: 03/10/2012 15:53:29

Interchange MODEL::

INTERCHANGE

INTERCHANGE RULE PARAMETER

Route MODEL::

LINE

Route MODEL::

DIRECTION

MODE

Reusable Transport

Mode MODEL::

VEHICLE MODE

ORGANISATION


MODEL::OPERATOR

Serv ice Pattern

MODEL::STOP AREA

TRANSFER

Serv ice Pattern

MODEL::CONNECTION

Generic Validity

MODEL::VALIDITY

CONDITION

Time Demand Type

MODEL::TIME

DEMAND TYPE

INTERCHANGE RULE

TIMING

«PK»

+ idJourney Timing MODEL::

JOURNEY TIMING

Serv ice Calendar

MODEL::TIME BAND

Service Pattern

MODEL::

CONNECTION END

ORGANISATION PART


MODEL::CONTROL CENTRE

+used to define 0..1

+associated with *

+using

0..*

+used as

0..1

+asociated with*

+used to define

0..1

+start

of

1

+from*

+for

0..*

+at

0..1

+using

0..*

+used as

0..1

+included in

1..*

+composed of0..1

+using

0..*

+used as

0..1

+operated by

0..*

+operating

0..*

+using

0..*

+used as0..1

+to

*

+end

of1

+using

0..*

+used as 0..1

+servicing 0..*

+serviced by0..*

+a view of 0..*

+viewed as

1

+using 0..*

+used as

0..1

+using 0..*

+used as 0..1

+distributing1

+defining

distributor for*

+feeding 1

+defining

feeder for *

+primary for 0..1

+run by 0..*

+using

0..*

+used as

0..1

+controll ing0..1

+controlled by 0..*

+applicable for

*+defined for

*

Figure 87 — Interchange Rule – Conceptual MODEL (UML)

7.2.8.2 Interchange Rule – Physical Model

The following figure shows the physical model for an INTERCHANGE RULE.

Each INTERCHANGE RULE may have a feeder and distributor filter: that is, an INTERCHANGE RULE PARAMETER that constrains the rule only to apply to a specified set of journeys. Constraints include the LINE, DIRECTION, OPERATOR, connecting STOP POINT, connection STOP AREA, origin STOP POINT, and penultimate STOP POINT.

There may be different INTERCHANGE RULE TIMINGs for different times of day.

MaximumWindow expresses the maximum duration between the feeder SERVICE JOURNEYs planned arrival time and the distributor SERVICE JOURNEYs planned departure time.

MaximumWaitTime expresses the maximum duration a distributor SERVICE JOURNEY should delay its departure time waiting for a feeder SERVICE JOURNEY.

The default transfer time of the passenger should be added to the forecasted arrival time of the feeder SERVICE JOURNEY to decide if the distributor SERVICE JOURNEY will exceed the MaximumWaitTime when waiting for passengers from the delayed distributor.

TC 278 WI 00278308:2013 (E)

110

class XSD NeTEx TP Interchange Rule Model

Name: XSD NeTEx TP Interchange Rule Model

Author: NeTEx

Version: 1.0

Created: 16/11/2010 17:26:55

Updated: 25/09/2012 11:32:30

ScheduledStopPoint

Zone

StopArea

Connection

DataManagedObject

Transfer

ConnectionEnd

Mode

«XmlImplementAsEnu...

VehicleMode

TransferDuration

DefaultDuration :duration

FrequentTravellerDuration :duration [0..1]

OccasionalTravel lerDuration :duration [0..1]

MobilityRestrictedTravellerDuration :duration [0..1]

InterchangeRule

MaximumWindow :duration [0..1]

Exclude :boolean [0..1] = false

Priority :integer [0..1] = false

«PK»

id :InterchangeRuleIdType

«contained»

validity :Validi tyCondition* [0..1]

FeederFilter :InterchangeRuleParameter [0..1]

DistributorFilter :InterchangeRuleParameter [0..1]

timings :InterchangeRuleTiming [0..*]

«FK»

ControlCentreRef :ControlCentreRef* [0..1]

InterchangeRuleParameter


MaximumInterchangeWindow :duration [0..1]

«FK»

StopAreaRef :StopAreaRef* [0..1]

StopPlaceRef :StopPlaceRef* [0..1]



ExternalLineRef :normal izedString* [0..1]

DirectionRef :DirectionRef* [0..1]

ExternalDirectionRef :normalizedString* [0..1]

ScheduledStopPointRef :ScheduledStopPointRef* [0..1]

AdjacentStopPointRef :ScheduledStopPoinRef* [0..1]

AdjacentPointRef :PointRef* [0..1]

EndStopPointRef :ScheduledStopPointRef* [0..1]

ServiceJourneyRef :ServiceJourneyRef* [0..1]

«contained»

JourneyDesignator :JourneyDesignator [0..1]

DataManagedObject

Line

TypeOfValue

Direction

VehicleJourney

Serv iceJourney

Organisation

Operator

OrganisationPart

ControlCentre

DataManagedObject

Interchange

Name :MultlingualString [0..1]

Description :Multl ingualString [0..1]

Priority :InterchangePriorityType [0..1]

StaySeated :boolean [0..1]

CrossBorder :boolean [0..1]

Planned :boolean [0..1]

Guaranteed :ConnectionCertaintyEnum [0..1]

Advertised :boolean [0..1]

Controlled :boolean [0..1]

TransferModes :AccessModeEnum [0..1]

«PK»

id :InterchangeIdType

«AK»


«FK»

ConnectionRef :ConnectionRef* [0..1]

«contained»

Timings :InterchangeTimings [0..*]



InterchangeTimes :InterchangeTimes

«PK»

id :InterchangeRuleTimingIdType

«FK»

InterchangeRuleRef :InterchangeRuleRef*

DataManagedObject

TimeDemandType

DataManagedObject

Timeband

Time planning o=of

journeys may be done

in terms of EITHER

timebands OR abstract

timebands - TIME

DEMAND TYPES

VersionedChild

JourneyTiming

DataManagedObject

ValidityCondition

JourneyDesignator

DataManagedObject

Point

TimingPoint

«ImplementAsGroup»

InterchangeTimes

StandardWaitT ime :duration [0..1]

MaximumWaitTime :duration [0..1]

MaximumAutomaticWindow :duration [0..1]

StandardTransferTime :duration [0..1]

MinimumTransferTime :duration [0..1]

MaximumTransferTime :duration [0..1]

ControlCentreNotifyThreshold :duration [0..1]

timing 0..*

made up of 0..1

identifies 0..*

identified by

1

0..*

applies to

0..1

rule 0..*

applies to

0..1

0..*

restrict to

0..1

run by

0..*

primary 0..1 controls 0..*

controlled by 0..1

used on 0..1

uses as primary *

timing 0..*

happens during

0..1

uses 0..*

next at

0..1

when0..*

valid

uses

0..*

interchaneg at

0..1

uses

0..*

journey

ending

at

/journey

to0..*

/destination 0..1

connects

0..*

to 1

stop

0..*member of

0..*

uses *

ending at 0..1

interchange

0..*

at

0..1

end of 1

to

usesused in

valid

0..*

transfer

for

0..*

mode

0..1

applies to

0..*

Mode 0..1

duration

0..*

timed by

to

0..1

distributing

1

from

0..1feeding

1..

uses

0..*

on

for

0..*

l ine

0..1

start of 1

from

Figure 88 — Interchange Rule – Physical Model (UML)

7.2.8.3 Interchange Rule – Attributes and XSD

7.2.8.3.1 InterchangeRule – Model Element

INTERCHANGE RULE specifies conditions for considering JOURNEYs to meet or not to meet, specified indirectly: by a particular MODE, DIRECTION or LINE. Such conditions may alternatively be specified directly, indicating the corresponding services. In this case they are either a SERVICE JOURNEY PATTERN INTERCHANGE or a SERVICE JOURNEY INTERCHANGE.

Table 52 – InterchangeRule – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> INTERCHANGE RULE inherits from DATA

MANAGED OBJECT

«PK» id InterchangeRuleIdType 1:1 Identifier of INTERCHANGE RULE.

MaximumWindow xsd:duration 0:1 Maximum window for holding DISTRIBUTOR will

wait.

«cntd» validity ValidityCondition 0:1 VALIDITY CONDITION governing INTERCHANGE

RULE.

Exclude xsd:boolean 0:1 Whether rule is to exclude interchanges of journeys

that match the filter criteria.

111

«FK» ControlCentreRef ControlCentreRef 0:1 Reference to a CONTROL CENTRE for which

RULE applies.

«cntd» FeederFilter InterchangeRule-

Parameter

0:1 Feeder journey INTERCHANGE RULE FILTER

associated with INTERCHANGE RULE.

«cntd» DistributorFilter InterchangeRule-

Parameter

0:1 Distributor journey INTERCHANGE RULE FILTER

associated with INTERCHANGE RULE.

«cntd» timings InterchangeRuleTiming 0:* Timings for INTERCHANGE RULE.

InterchangeRule_VersionStructure

C onditions for considering journey s to meet or not to meet, specified indirectly : by a particular MO DE, DIREC TIO N or

LINE. Such conditions may alternativ ely be specified

directly , indicating the corresponding serv ices. In this case

they are either a SERV IC E JO URNEY PA TTERN

INTERC HA NGE or a SERV IC E JO URNEY

INTERC HA NGE.

InterchangeRule

(restriction)

type InterchangeRule_VersionStructure

attributes


O RGA NISA TIO N.



InterchangeGroup

Elements for an INTERC HA NGE RULE.

InterchangeRuleGroup

V A LIDITY C O NDITIO Ns apply ing to INTERC HA NGe.

validityConditions

0 1..

type validityConditions_RelStructure

Reference to a C O NNEXTIO N ZO NE area.

ConnectionZoneRef

0 1..

type ZoneRefStructure

Reference to a C O NTRO L C ENTRE.

ControlCentreRef

0 1..

type ControlCentreRefStructure

Whether rule is to exclude any connections that satisfy the

criteria. Default is false.

Exclude

0 1..

type xsd:boolean

F eeder end of INTERC HA NGE RULE.

FeederFilter

0 1..

type InterchangeRuleParameterStructure

D istributor end of INTERC HA NGE RULE.

DistributorFilter

0 1..

type InterchangeRuleParameterStructure

A dditional timings for the INTERC HA NGE RULE for specific

TIME DEMA ND TYPEs.

tim ings

0 1..

type interchangeRuleTimings_RelStruc...

Figure 89 — InterchangeRule — XSD

7.2.8.3.2 InterchangeRuleParameter – Model Element

Assignment of parameters characterising an INTERCHANGE RULE.

A specification of the filtering criteria for the feeder or distributor end of an INTERCHANGE RULE.

Table 53 – InterchangeRuleParameter – Element

Classifi Name Type Cardin- Description

TC 278 WI 00278308:2013 (E)

112

cation ality

::> ::> DataManagedObject ::> INTERCHANGE RULE PARAMETER inherits from

DATA MANAGED OBJECT

TransportMode VehicleModeEnum 0:1 Mode of CONNECTING JOURNEYs to which

INTERCHANGE RULE applies.

«FK» StopAreaRef StopAreaRef 0:1 STOP AREA to which INTERCHANGE RULE

applies.

«FK» StopPlaceRef StopPlaceRef 0:1 STOP PLACE feeding or distributing JOURNEY to

which INTERCHANGE RULE applies.

«FK» OperatorRef OperatorRef 0:1 OPERATOR of JOURNEYs to which


«FK» LineRef LineRef 0:1 LINE of JOURNEYs to which INTERCHANGE

RULE applies.

«FK» ExternalLineRef ExternalLineRef 0:1 External reference to LINE of JOURNEYs to which


«FK» DirectionRef DirectionRef 0:1 Reference to DIRECTION of TRANSFER to which

INTERCHANGE RULE applies

«FK» External-

DirectionRef

ExternalDirectionRef 0:1 External reference to DIRECTION of TRANSFER to

which INTERCHANGE RULE applies

«FK» ScheduledStop-

PointRef

ScheduledStopPointRef 0:1 Start or end SCHEDULED STOP POINT in

INTERCHANGE of connecting JOURNEY to which


«FK» AdjacentStop-

PointRef

ScheduledStopPointRef 0:1 Prior (feeder) or onwards (distributor) STOP POINT

before of journeys to which INTERCHANGE RULE

applies.

«FK» AdjacentStop-

PlaceRef

StopPlaceRef 0:1 Prior (feeder) or onwards (distributor) STOP PLACE

before of journeys to which INTERCHANGE RULE

applies.

«FK» AdjacentPointRef PointRef 0:1 Prior (feeder) or onwards (distributor) POINT before

connection used by journey to which


«FK» EndStopPointRef ScheduledStopPointRef 0:1 Origin (for feed journeys) or Destination (for

distributor journeys) SCHEDULED STOP POINT of

connecting JOURNEY to which INTERCHANGE

RULE applies.

«FK» ServiceJourneyRef ServiceJourneyRef 0:1 SERVICE JOURNEY to which INTERCHANGE

RULE applies.

Maximum-

InterchangeWindow

xsd:duration 0:1 Maximum interval for making interchange.

«cntd» JourneyDesignator JourneyDesignator 0:1 Means of identifying a JOURNEY whose ID is not

known.

113

Ty pe for INTERC HA NGE RULE PA RA METER.

InterchangeRuleParameterStructure

Identifier of MO DE of end Point of TRA NSFER . Default is

all modes.

TransportMode

type AllVehicleModesOfTransportEnumeration


OperatorRef


Identifier of a P lace at end point of transfer.

StopAreaRef

type StopAreaRefStructure

Reference to a STO P PLA C E.

StopPlaceRef

type StopPlaceRefStructure

Line filter Elements for an INTERC HA NGE RULE

PA RA METER.

InterchangeRuleLineFilterGroup

lines for which this applies.

AllLines

type EmptyType


LineRef


A lternativ e LINE Reference for A V MS sy stem.

ExternalLineRef



DirectionRef


A lternativ e DIREC TIO N Reference for A V MS sy stem.

ExternalDirectionRef


Stop filter E lements for an INTERC HA NGE RULE

PA RA METER.

InterchangeRulePointFilterGroup

Reference to a SC HEDULED STO P PO INT.

ScheduledStopPointRef


P rior (feeder) or onwards (distributor) SC HEDULED STO P

PO INT before/after C O NNEC TIO N

AdjacentStopPointRef


P rior (feeder) or onwards (distributor) SC HEDULED STO P

PLA C E before/after C O NNEC TIO N

AdjacentStopPlaceRef

type StopPlaceRefStructure

P rior (feeder) or onwards (distributor) PO INT (not

necessarily a STO P PO INT) before/after connection

AdjacentPointRef


Identifier of end i.e. origin (feeder) or destination

(Distributor)(SC HEDULED STO P PO INT of

feeder/distributor JO URNEY.

EndStopPointRef



need not be stated.

TimeDemandTypeRef


Reference to a connecting V EHIC LE JO URNEY to whom

INTERC HA NGE RULE applies. If absent applies to all

journey s.

ServiceJourneyRef


V alue reference to a SERV IC E JO URNEY. Prov ides an

alternativ e way of identify ing a Journey .

ServiceDesignator

type ServiceDesignatorStructure

Maximum interv al for making INTERC HA NGe.

MaximumInterchangeWindow

type xsd:duration

Figure 90 — InterchangeRuleParameter — XSD

TC 278 WI 00278308:2013 (E)

114

7.2.8.3.3 InterchangeRuleTiming – Model Element

Conditions for considering JOURNEYs to meet or not to meet, specified indirectly: by a particular MODE, DIRECTION or LINE. Such conditions may alternatively be specified directly, indicating the corresponding services. In this case they are either a SERVICE JOURNEY PATTERN INTERCHANGE or a SERVICE JOURNEY INTERCHANGE.

Table 54 – InterchangeRuleTiming – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> VersionedChild ::> INTERCHANGE RULE TIMING inherits from

VERSIONED CHILD.

«PK» id InterchangeRule-

TimingIdType

1:1 Identifier of INTERCHANGE RULE TIMING.

«FK» InterchangeRuleRef InterchangeRuleRef 1:1 Identifier of INTERCHANGE RULE to which this

timing belongs.

MaximumWindow xsd:duration 0:1 Maximum window for holding DISTRIBUTOR will

wait.

StandardWaitTime xsd:duration 0:1 Standard Time to wait at Interchange.

MaximumWaitTime xsd:duration 0:1 Maximum time that DISTRIBUTOR will wait.

StandardTransferTime xsd:duration 0:1 Standard Time needed for transfer.

MinimumTransferTime xsd:duration 0:1 Minimum Time needed for transfer.

MaximumTransferTime xsd:duration 0:1 Maximum Time needed for transfer.

InterchangeRuleTiming_VersionStructure

C onditions for considering journey s to meet or not to meet, specified indirectly : by a particular MO DE, DIREC TIO N or LINE. Such conditions may alternativ ely be specified

directly , indicating the corresponding serv ices. In this case they are either a SERV IC E JO URNEY PA TTERN INTERC HA NGE or a SERV IC E JO URNEY

INTERC HA NGE.


(restriction)

type InterchangeRuleTiming_VersionSt...

attributes


VersionedChildGroup

User defined Extensions to ENTITY in schema. (Wrapper tag

used to av oid problems w ith handling of optional 'any ' by some v alidators).

Extensions

0 1..



JourneyTimingGroup

E lements for an INTERC HA NGE RULE TIMING.

InterchangeRuleTimingGroup

Time Elements for SERV ICE JO URNEY INTERCHA NGE.




Standard wait time for INTERCHA NGE.

StandardWaitTime

0 1..

type xsd:duration

Maximum wait time for INTERC HA NGE.

MaximumWaitTime

0 1..

type xsd:duration



0 1..

type xsd:duration



Standard transfer duration for INTERCHA NGE.


0 1..

type xsd:duration

Maximum transfer duration for INTERCHA NGE.

MinimumTransferTime

0 1..

type xsd:duration

Maximum transfer duration for INTERCHA NGE.

MaximumTransferTime

0 1..

type xsd:duration

Interv al before CO NTRO L C ENTRE should be notified

associated w ith SERV IC E JO URNEY INTERC HA NGE.

ControlCentreNotifyThreshold

0 1..

type xsd:duration

Figure 91 — InterchangeRuleTiming — XSD

115

7.2.8.4 XML Example of Interchange Rule

The following code fragment shows three INTERCHANGE RULEs.

For EXAMPLE

<interchangeRules>

<InterchangeRule version="any" id="hde:IR_25_all_f">

<Name>Main Station - All inbound</Name>

<ConnectionRef version="any" ref="mybus:Connection:CX_25"/>

<Priority>5</Priority>




<Controlled>true</Controlled>


<MaximumAutomaticWaitTime>PT2M</MaximumAutomaticWaitTime>



<MaximumTransferTime>PT8M</MaximumTransferTime>

<ControlCentreRef ref="hde:123"/>

<FeederFilter>

<TransportMode>bus</TransportMode>

<AllLines/>

<MaximumInterchangeWindow>PT5M</MaximumInterchangeWindow>

</FeederFilter>

</InterchangeRule>

<InterchangeRule version="any" id="hde:IR_25_LN1_f">

<Name>Main Station - Line 1 inbound Special rule</Name>

<ConnectionRef version="any" ref="mybus:CX_25"/>



<Guaranteed>true</Guaranteed>






<ControlCentreRef ref="hde:123"/>

<FeederFilter>



<DirectionRef version="any" ref="mybus:DR_hbf"/>


<NextStopPointRef version="any" ref="mybus:SSP_003"/>

<EndStopPointRef version="any" ref="mybus:SSP_002"/>


</FeederFilter>

</InterchangeRule>

<InterchangeRule version="any" id="hde:IR_25_LN6_d">

<Name>Main Station - Line 6 outbound </Name>

<ConnectionRef version="any" ref="mybus:CX_25"/>











<MaximumTransferTime>PT8M</MaximumTransferTime>

<ControlCentreRef ref="hde:ControlCentre:123"/>

<DistributorFilter>



<DirectionRef version="any" ref="mybus:DR_Hospital"/>


<NextStopPointRef version="any" ref="mybus:SSP_011"/>

<EndStopPointRef version="any" ref="mybus:SSP_012"/>


</DistributorFilter>

</InterchangeRule>

TC 278 WI 00278308:2013 (E)

116

</interchangeRules>

7.2.9 Coupled Journey

7.2.9.1 COUPLED JOURNEY – Conceptual MODEL

An important additional issue for rail systems compared to conventional bus systems, is the operation of vehicles coupled in trains, rather than running as separate autonomous vehicles. One consequence is the additional possibility to adjust the service supply to the demand as regards the types of vehicle. Trains may be shortened or prolonged during the day, or even within one service journey.

Furthermore the description of journeys to the passenger is more complex as train may be separated in two (or more) parts at a particular branching point, where both train parts continue their journey on different routes towards separate destinations. Conversely, two short trains coming from different feeding routes may be scheduled to meet at a joining point, where they are coupled to continue their service as one long train on a common route.

NeTEx separately represents the coupling of vehicles in a TRAIN and the linking of JOURNEY PARTs of VEHICLE JOURNEYs.

The concept of a COUPLED JOURNEY is related to the action of vehicle coupling.

‘Vehicle’ is understood as a unit remaining stable all along a VEHICLE JOURNEY. Therefore, a ‘vehicle’ may be either a single vehicle (e.g. a single tramway vehicle) or a TRAIN composed of several TRAIN ELEMENTs or a COMPOUND TRAIN composed of elementary TRAINs.

The considerations related to the vehicle coupling actions are based on the concept of VEHICLE TYPE.

The entity TRAIN describes an elementary train and is thus a VEHICLE TYPE. A TRAIN consists of TRAIN ELEMENTs assembled together. The composition of the TRAIN is provided by a TRAIN COMPONENT, giving the order of the TRAIN ELEMENT in the TRAIN.

Like any vehicle, a TRAIN operates VEHICLE JOURNEYs. If there is no coupling action during a VEHICLE JOURNEY, there is only one TRAIN for the journey. Two or more TRAINs may be coupled together for a part of a VEHICLE JOURNEY, or for longer periods, during which the composition of the compound train changes (thus the VEHICLE TYPE). Such coupled vehicles are represented by the concept of COMPOUND TRAINs.

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

For operational management, which will typically manage work periods for each VEHICLE TYPE. Such periods are described as BLOCKs, worked from a PARKING POINT to another, composed of sets of VEHICLE JOURNEYs. BLOCKs may be coupled (building COMPOUND BLOCKs, representing the work of a vehicle during the time it is coupled to another vehicle) or separated for a while, building BLOCK PARTs, i.e. the parts of a BLOCK corresponding to the different JOURNEY PARTs of the VEHICLE JOURNEYs in a BLOCK. In this modelling TYPE OF COUPLING allows for a classification of BLOCK PARTs, for example to indicate whether the coupling or the separation may occur at the start or at the end of a BLOCK.

For passenger information, which is not concerned by the BLOCK description but by the fact that VEHICLE JOURNEYs are either coupled or not; these actions are occurring during a journey (at an intermediate point, e.g. where two routes meet, or separation where they diverge), JOURNEY PARTs are considered to describe the different journey parts. Any part of a VEHICLE JOURNEY that is coupled with another is qualified with a JOURNEY PART. In such a case, the PURPOSE OF JOURNEY PARTITION is “coupling”. One of the coupled JOURNEY PARTs is considered to be the main part of the compound vehicle formed. The entity JOURNEY PART COUPLE represents the

117

coupling of one JOURNEY PART to the main one. In the case of the separation of vehicles, JOURNEY PARTs are created and the PURPOSE OF JOURNEY PARTITION is “separation”.

7.2.9.1.1 Train coupling – Conceptual MODEL

class NeTEx TM MM Train Coupling View

Vehicle Serv ice

MODEL::

COMPOUND

BLOCK

Vehicle Serv ice

MODEL::BLOCK

PART


VEHICLE TYPE

Train MODEL::TRAIN

Train MODEL::TRAIN

COMPONENT Train MODEL::TRAIN

ELEMENT


Train MODEL::TRAIN IN

COMPOUND TRAIN

Train MODEL::

COMPOUND TRAIN

Name: NeTEx TM MM Train Coupling View

Author: NeTEx

Version: 1.0

Created: 19/01/2011 14:32:20

Updated: 03/10/2012 15:55:02

+included

in

* +including

0..1

+assigned to

1

+using *

+assigned to

1

+using

*

+uses as

1 +use of *

+referring to

*+reference for

1

+used

for*

+composed of

1

+using

*

+used

for1

+using *

+assigned

to

1

+made up of 0..1

+included in

*

+used for

1

+using *+used

for*

+composed

of

1

Figure 92 — Train Coupling – Conceptual MODEL (UML)

7.2.9.1.2 Journey Parts & Train Numbers

A COUPLED JOURNEY is a complete journey operated by a COMPOUND TRAIN, composed of two or more VEHICLE JOURNEYs remaining coupled together all along a JOURNEY PATTERN. A COUPLED JOURNEY may be viewed as a single VEHICLE JOURNEY. This view of a COUPLED JOURNEY as a single VEHICLE JOURNEY is used for passenger information, as the passenger does not care whether this journey is composite from the vehicle management point of view.

Both operational and passenger information points of view are linked to a concept of TRAIN NUMBER, which gives a specification of codes assigned to particular VEHICLE JOURNEYs, JOURNEY PARTs and JOURNEY PART COUPLEs when operated by TRAINs or COMPOUND TRAINs according to a functional purpose (passenger information, operation follow-up, etc.). Two attributes control the exposing of numbers for use: ForAdvertisement and ForProduction.

TC 278 WI 00278308:2013 (E)

118

class NeTEx TM MM Coupled Journey MODEL


PURPOSE OF JOURNEY

PARTITION

«PK»

+ id

Name: NeTEx TM MM Coupled Journey MODEL

Author: NeTEx

Version: 1.0

Created: 19/01/2011 13:08:05

Updated: 27/03/2012 18:15:58

JOURNEY PART


+ StartTime

+ EndTime

+ Coupl ingType [0..1]

«PK»

+ id

JOURNEY


JOURNEY

JOURNEY PART COUPLE

+ order


«PK»

+ id

Vehicle Serv ice

MODEL::BLOCK

PART

Exclusion

LINK SEQUENCE


JOURNEY PATTERN

Generic Point & Link MODEL::POINT

Vehicle Serv ice

MODEL::

COMPOUND

BLOCK





PATTERN


TRAIN NUMBER

TYPE OF

COUPLING

COUPLED

JOURNEY

- Description

«PK»

+ id

+assigned to1

+using *

+to

*

+end of

1

+from

*

+start of

1

+using

*+assigned to1

+made up of 0..1

+included in *

+operated by

0..*

+requested

for0..*

+included in*

+including

0..1

+assigned to

1 +using *

+to

*

+end of

1

+made using *

+for1

+classification for0..1

+classi fied by0..*

+part of 1..*

+composed of 0..1

+in *

+including

0..1

+referring to

*

+reference for 1

+used as main part in1

+including as

main part0..1

+joining 1

+including as joining

part0..1

0..1

0..*

+identi fying 0..*

+identified by 0..*

+viewed as1

+a view

of0..1

+including0..1

+in *

+start of

1

+from

*

+subdivided in

1+part of

*

+causing

1

+caused by1..*

+identifying

0..1

+identified by

0..*

+proposed for0..*

+made using

0..*

+uses as 1

+use of*

Figure 93 — Coupled Journey – Conceptual MODEL (UML)

7.2.9.2 Coupled Journey – Example

Both the joining and splitting of train journeys can be represented in NeTEx, with exact information about which carriage goes to which destination.

119

Figure 94 — Example – Joining and splitting Trains

7.2.9.2.1 Example of Joining and splitting: Amsterdam to Warsaw

In this example, we consider a train that starts in Amsterdam that has parts that run to three separate destinations, Warsaw, Copenhagen and Prague. Hannover and Berlin are the splitting points and another train (60467) joins the Berlin to Prague leg. There are multiple TRAIN NUMBERs associated with the respective trains

A

Win

ter

On

ly

Amsterdam BerlinHannover Warsaw

Prague

Copenhagen

Join Split example : Amsterdam – Hannover – Berlin - Warsaw

T-447457447 40447

T:4044740447

T-447447T-447457 447

T-457457 60457

Join

44

7

Jo

in4

57

Join

40

44

7

Split

457

Join 6

0457

Split

4044

7

Figure 95 — Example – Joining and splitting: Amsterdam to Warsaw

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

TC 278 WI 00278308:2013 (E)

120

457

-JO

UR

NE

Y

A


Prague

Copenhagen

Join Split example : Four SERVICE JOURNEYs , Five TRAIN NUMBERs

457447 40447

40447

447457 447

457 60457

T-447

T-40447

T-457

T-447 T-447

447-JOURNEY

457-JOURNEY

60

457

-JO

UR

NE

Y

40447-JOURNEY PART-1

404

47-J

OU

RN

EY

Advertised: 447, 457, 40447

TTID: 447

Advertised: 40447

TTID: 40447

Advertised: 447

TTID : 447

Advertised: 457, 60457 TTID: 457

Advertised: 447, 457 TTID: 447

Figure 96 — Example – Journeys: Amsterdam to Warsaw

The JOURNEY PARTs are shown in the following diagram.

121

A


Prague

Copenhagen

Join Split example : 9 JOURNEY PARTs , 3 JOURNEY PART COUPLEs

457447 40447

40447

447457 447

457 60457

T-447

T-40447

T-457

T-447T-447

447-JOURNEY PART COUPLE-1

447-JOURNEY PART-1


457-JOURNEY PART-1


447-JOURNEY PART-2

457-JOURNEY PART-2

447-JOURNEY PART-3

404

47-J

OU

RN

EY

PA

RT

-2

45

7-J

OU

RN

EY

PA

RT

CO

UP

LE

-3

60

45

7-J

OU

RN

EY

PA

RT

-1

457

-JO

UR

NE

Y P

AR

T-3

Figure 97 — Example – Journey Parts: Amsterdam to Warsaw

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

TC 278 WI 00278308:2013 (E)

122


447-JOURNEY PART-1


457-JOURNEY PART-1447-JOURNEY PART COUPLE-2

447-JOURNEY PART-2

457-JOURNEY PART-2

45

7-J

OU

RN

EY

PA

RT

CO

UP

LE

-3

60

45

7-J

OU

RN

EY

PA

RT

-1

457

-JO

UR

NE

Y P

AR

T-3

A


Prague

Copenhagen

Join / Split Example : 6 JOURNEY MEETINGs

457447 40447

40447

447457 447

457 60457

Jo

in45

7

Join

60457

ME

ET

ING

Join44

7

ME

ETIN

G

ME

ET

ING

MEETING

Split 457

ME

ET

ING

Join 4

0447

ME

ET

ING

Sp l

it 40

447

T-40447

T-457

T-447 T-447T-4474

04

47-J

OU

RN

EY

PA

RT

-2

447-JOURNEY PART-3

Figure 98 — Example – Journey Meetings: Amsterdam to Warsaw

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

ZZ-457-COMPOUND TRAIN

XX-447-COMPOUND TRAIN

E E

A

AmsterdamBerlinHannover

Warsaw

Prague

Copenhagen

Join / Split example : Four simple TRAINs , Three COMPOUND TRAINs

2 2 2 2 2 2 R 1 1 2 2 2 2 2 2 2 2 1 1

2 2 2 1 1

1 1 2 2 R

EE

E

2 2 2 2 2 2 R 1 1 2 2 2 2 2E

2 2 2 2 2 E

2 2 2 2 2 2 R 1 1

447-TRAIN 01 457-TRAIN 01 40447 -TRAIN 01

YY-447-COMPOUND TRAIN

447-TRAIN 01 457-TRAIN 02

457-TRAIN-01 40457 -TRAIN

447-TRAIN 02

40447 -TRAIN 02

Figure 99 — Example – Journey Meetings: Amsterdam to Warsaw

123

The detailed train makeup can be related to the JOURNEY PARTs using JOURNEY PART COUPLEs and BOCK PARTs. Here we show the Amsterdam to Warsaw elements.

40447-JOURNEY

40447 -JOURNEY


447-JOURNEY

447-BLOCK

AmsterdamBerlinHannover Warsaw

Join / Split example : 447 to Warsaw: One BLOCK, Three BLOCK PARTs

2 2 2 2 2 2 R 1 1 2 2 2 2 2 2 2 2 1 1 2 2 2 2 2 2 R 1 1 2 2 2 2 2 EE EE E2 2 2 2 2 2 R 1 1

447 -TRAIN 01 457-TRAIN 01 40447 -TRAIN 01

YY-447-COMPOUND TRAIN

447-TRAIN 01 457-TRAIN 02 447 -TRAIN 02

447-BLOCK PART - 2

447-BLOCK PART - 1

447-BLOCK PART -3

447-JOURNEY PART COUPLE-1 447-JOURNEY PART COUPLE-2

447-JOURNEY PART-1


457-JOURNEY PART-1

447-JOURNEY PART-2

457-JOURNEY PART-2

447-JOURNEY PART-2

XX-447-COMPOUND BLOCK YY-447-COMPOUND BLOCK

Figure 100 — Example – Train Block Parts and Journey Part Couples: Amsterdam to Warsaw

The detailed train makeup can be related to the JOURNEY PARTs using JOURNEY PART COUPLEs and BOCK PARTs. Here we show the Amsterdam to Prague elements.

TC 278 WI 00278308:2013 (E)

124


40447-BLOCK

A

Amsterdam HannoverCopenhagen

Join / Split example : 447 to Copenhagen : One BLOCK, Two BLOCK PARTs

2 2 2 2 2 2 R 1 1 2 2 2 2 2 2 2 2 1 1 2 2 2 1 1EE

447-TRAIN 01 457-TRAIN 01 40447-TRAIN 01

40447-BLOCK PART - 2447-BLOCK PART - 1


40447 -TRAIN 02

E

40447-JOURNEY

447-JOURNEY

447-JOURNEY PART-1

40447-JOURNEY PART-140447-JOURNEY PART-2

40447-JOURNEY

457-JOURNEY PART-1

XX-447-COMPOUND BLOCK

Figure 101 — Example – Train Block Parts and Journey Part Couples: Amsterdam to Copenhagen

7.2.9.3 Coupled Journey – Physical Model

The following figure shows the physical model for COUPLED JOURNEYs.

125

class XSD NeTEx MM Coupled Journey Model

DataManagedObject


CoupledJourney

Description :Multil ingualSrring

«PK»

id :CoupledJourneyIdType

«FK»


«contained»

journeys :VehicleJourney [0..*]

DataManagedObject

CoupledJourneyModel::JourneyPartCouple

order :positiveInteger


«PK»

id :JourneyPartCoupleIdType

«FK»




MainPartRef :JourneyPartRef*

TrainNumberRef :TrainNumberRef* [0..1]

«contained»

joinedParts :JourneyPartRef [0..*]

DataManagedObject

VehicleServ iceModel::BlockPart

Order :integer [0..1]



«PK»

id :BlockPartIdType

«FK»

BlockRef :BlockRef*


CompoundBlockRef :CompoundBlockRef* [0..1]

JourneyPartCoupleRef :CompoundBlockRef* [0..1]

«contains»

journeyParts :JourneyPartRef* [0..*]

Name: XSD NeTEx MM Coupled Journey Model

Author: NeTEx

Version: 1.0

Created: 17/01/2010 19:42:43

Updated: 12/10/2012 15:40:36

DataManagedObject



StartTime :time

EndTime :time

«PK»

id :JourneyPartIdType

«FK»

ParentJourneyRef :VehicleJourneyRef*

PurposeRef :PurposeOfJourneyPartitionRef* [0..1]

MainPartRef :JourneyPartCoupleRef* [0..1]

JoiningPartCoupleRef :JourneyPartCoupleRef* [0..1]

BlockPartRef :BlockPartRef* [0..1]


FromStopPointRef :ScheduledStopPointRef* [0..1]

ToStopPointRef :ScheduledStopPointRef* [0..1]

«contained»

facilities :ServiceFacil itySet [0..*]

TypeOfValue



«PK»

id :PurposeOfJourneyPartitionIdType

Journey


DepartureTime :time


«PK»


«contained»






waitTimes :VehicleJourneyWaitTime [0..*]





«FK»




TimingAlgorithmRef :TimingAlgorithmRef* [0..1]






«AK»


TypeOfValue

«ImplementAsEnum»


TypeOfCoupling«enumeration»

CoupledJourneySupport::

TypeOfCouplingEnum

serviceFacility

tariffSection

coupling

other

none

DataManagedObject




PreparationDuration :duration [0..1]

StartTime :time [0..1]

StartTimeDayOffset :DayOffsetType [0..1]

FinishingDuration :duration [0..1]


EndTimeDayOffset :DayOffsetType [0..1]

«PK»

id :BlockIdType

«FK»

ServicePartRef :VehicleServicePartRef* [0..1]

StartPointRef :ParkingPointRef* [0..1]

EndPointRef :ParkingPointRef* [0..1]


«contained»

validityConditions :ValidityCondition [0..*]


blockParts :BlockPart [0..*]

reliefOpportunities :ReliefOpportunity [0..*]

al lowances :TimeAllowance [0..*]

journeys :JourneyRef* [0..*]

TimingPoint


Facil itySet

FacilityModel::Serv iceFacilitySet

DataManagedObject

VehicleJourneyModel::TrainNumber

ForAdvertisement :normalizedString [0..1]

ForProduction :normalizedString [0..1]


«PK»

id :TrainNumberIdType

DataManagedObject


subdivided in

1

{ordered}

part of *

using *

assigned to 1

operated by

0..* requested for

0..*

links0..*

to 1

links 0..*

from 1

referring to

*

reference for 1

identified by

0..*

identifies

0..*

viewed as

1

a view of 0..1

including

0..1

included in

*

0..1

0..*

causing 1

caused by 1..*

facilies

forin *

including

0..1

uses as

1

use of *

identified by

0..1

identifies0..*

joining 0..*

including as joining part0..1

used as main part in

1

including as main part

0..1

including 0..1

included in

*

part of 1..*

{ordered}

composed of 0..1

including 0..1

in *

Figure 102 — Coupled Journey – Physical Model (UML)

TC 278 WI 00278308:2013 (E)

126

7.2.9.3.1 Train Coupling – Physical Model

class XSD NeTEx MM Train to Block Assignment Model

DataManagedObject

VehicleServ iceModel::CompoundBlock

+ Name :Multi l ingualString [0..1]

«PK»

+ id :CompoundBlockIdType

«FK»

# VehicleTypeRef :VehicleServicePartRef* [0..1]

+ StartPoint :PointInJourneyPatternRef*

+ EndPoint :PointInJourneyPatternRef*

VersionedChild

TrainModel::TrainInCompoundTrain

+ order :positiveInteger

+ Description :Multi l ingualString [0..1]

+ Label :Multi l ingualString [0..1]

«PK»

+ id :TrainInCompoundTrainIdType

«FK»

# CompoundTrainRef :CompoundTrainRef*

# TrainRef :TrainIdType*

TrainModel::CompoundTrain

«PK»

+ id :CompoundTrainIdType

Name: XSD NeTEx MM Train to Block Assignment Model

Author: NeTEx

Version: 1.0

Created: 07/02/2011 17:30:12

Updated: 17/04/2012 10:43:05

DataManagedObject


DataManagedObject


+ Order :integer [0..1]



«PK»

+ id :BlockPartIdType

«FK»

# BlockRef :BlockRef*

# VehicleTypeRef :VehicleTypeRef* [0..1]

# CompoundBlockRef :CompoundBlockRef* [0..1]

# JourneyPartCoupleRef :CompoundBlockRef* [0..1]

«contains»

# journeyParts :JourneyPartRef* [0..*]

TrainModel::Train

«PK»

+ id :TrainIdType

«contained»

+ TrainSize :TrainSize [0..1]

- components :TrainComponent [0..*]

DataManagedObject


DataManagedObject

TrainModel::TrainElement

+ id :TrainElementIdType



+ FareClasses :FareClassEnum [0..*]

+ Length :LengthType [0..1]

«FK»

+ TrainElementType :TypeOfTrainElementEnum

«contained»

+ PassengerCapacity :PassengerCapacity [0..1]

- capacities :PassengerCapacity [0..*]

- TrainSize :TrainSize [0..1]

+ equipments :Equipment [0..*]

+ facil ities :Facil ity [0..*]

VersionedChild

TrainModel::TrainComponent

+ Order :positiveInteger



+ Label :Multi l ingualString [0..1]

«PK»

+ id :TrainComponentIdType

«FK»

# TrainRef :TrainRef*

# TrainElementRef :TrainElementRef* [0..1]

DataManagedObject

VehicleTypeModel::Vehicle


+ ShortName :Multi l ingualString [0..1]

«PK»

+ id :VehicleIdType

«AK»

+ VehicleRegistrationNumber :normalizedString [0..1]

+ PrivateCode :PrivateCodeType [0..1]

«FK»

# VehicleTypeRef :VehicleTypeRef* [0..1]

PointInLinkSequence



+assigned to1

+using *

+to *

+end of 1

+classifying 1

+classified as *

+using

* +used

for

1

+made up of 0..1

+included in *

+using*

+assigned to

1

+from *

+start of 1

+working within

1

+taken over

by*

+included in

*

+including

0..1

+uses

as

1+use

of

*

+working within1

+taken over

by

*

+using

*

+used

for

1..+composed of

1 +used

for

*

+working within 1

+taken over

by

*+assigned to1

+using

*

+used for*

+composed of 1

Figure 103 — Train to Block Assignment – Physical Model (UML)

7.2.9.4 Coupled Journey – Attributes and XSD

7.2.9.4.1 JourneyPart – Model Element

A part of a VEHICLE JOURNEY created according to a specific functional purpose, for instance in situations when vehicle coupling or separating occurs.

127

Table 55 – JourneyPart – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> JOURNEY PART inherits from DATA MANAGED

OBJECT

«PK» id JourneyPartIdType 1:1 Identifier of JOURNEY PART.

Description MultilingualString 0:1 Description of a JOURNEY PART.

«FK» ParentJourneyRef VehicleJourneyRef 0:1 Parent VEHICLE JOURNEY to which JOURNEY

PART belongs.

«FK» MainPartRef JourneyPartCoupleRef 1:1 REFERENCE to JOURNEY PART COUPLE of main

JOURNEY of a JOURNEY PART.

«FK» JourneyPart-

CoupleRef

JourneyPartCoupleRef 0:1 REFERENCE to JOURNEY PART COUPLE of

JOURNEY that JOURNEY PART joins.

«FK» TrainNumberRef TrainNumberRef 0:1 REFERENCE to TRAIN NUMBER of JOURNEY

PART

«FK» BlockPartRef BlockPartRef 0:1 REFERENCE to BLOCK PART of JOURNEY that

JOURNEY PART joins.

«FK» FromStopPointRef ScheduledStopPointRef 0:1 REFERENCE to from start SCHEDULED STOP

POINT for JOURNEY PART.

«FK» ToStopPointRef ScheduledStopPointRef 0:1 REFERENCE to end SCHEDULED STOP POINT

for JOURNEY PART.

StartTime xsd:time 1:1 Start time of a JOURNEY PART.

EndTime xsd:time 1:1 End time of a JOURNEY PART.

«FK» PurposeOf-

JourneyPartition-

Ref

PurposeOfJourneyPartitio

nRef

0:1 PURPOSE of JOURNEY PARTITION.

«cntd» facilities ServiceFacilitySet 0:* Facilities available during a JOURNEY PART.

TC 278 WI 00278308:2013 (E)

128

JourneyPart_VersionStructure

A part of a V EHIC LE JO URNEY created according to a

specific functional purpose, for instance in situations w hen

v ehicle coupling or separating occurs.

JourneyPart

(restriction)

type JourneyPart_VersionStructure

attributes


O RGA NISA TIO N.


Elements for JO URNEY PA RT.

JourneyPartGroup

Description of JO URNEY PA RT

Description

0 1..


Reference to parent of w hich this is part. If giv en by context

does not need to be stated.

ParentJourneyRef

0 1..


Main JO URNEY PA RT for journey .

MainPartRef

type JourneyPartCoupleRefStructure

Reference to a JO URNEY PA RT C O UPLE.

JourneyPartCoupleRef

0 1..


Reference to a TRA IN NUMBER.

TrainNumberRef

0 1..

type TrainNumberRefStructure

Reference to a BLO C K PA RT.

BlockPartRef

0 1..

type BlockPartRefStructure

Reference to a TRA IN BLO C K PA RT.

TrainBlockPartRef

type TrainBlockPartRefStructure

Point at which this JO URNEY PA RT starts.

FromStopPointRef

0 1..


Point at which this JO URNEY PA RT ends.

ToStopPointRef

0 1..


Start time of JO URNEY PA RT.

StartTime

type xsd:time

End time of JO URNEY PA RT.

EndTime

type xsd:time

Reference to a PURPO SE O F JO URNEY PA RTITIO N.

PurposeOfJourneyPartitionRef

0 1..

type PurposeOfJourneyPartitionRefStr...

F acilities av ailable during JO URNEY PA RT.

facilities

0 1..

type serviceFacilitySets_RelStructure

Figure 104 — JourneyPart — XSD

129

7.2.9.4.2 CoupledJourney – Model Element

A complete journey operated by a coupled train, composed of two or more VEHICLE JOURNEYs remaining coupled together all along a JOURNEY PATTERN. A COUPLED JOURNEY may be viewed as a single VEHICLE JOURNEY.

Table 56 – CoupledJourney – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> COUPLED JOURNEY inherits from DATA

MANAGED OBJECT

«PK» id CoupledJourneyIdType 1:1 Identifier of COUPLED JOURNEY.

Description MultilingualString 1:1 Description of COUPLED JOURNEY.

«FK» TrainBlockRef BlockRef 0:1 BLOCK supplying that COUPLE JOURNEY.

«cntd» journeys VehicleJourney 0:* JOURNEYs linked by of COUPLED JOURNEY.

CoupledJourney_VersionStructure

A complete journey operated by a coupled train, composed

of two or more V EHIC LE JO URNEYs remaining coupled together all along a JO URNEY PA TTERN. A C O UPLED

JO URNEY may be v iewed as a single V EHIC LE

JO URNEY.

CoupledJourney

(restriction)

type CoupledJourney_VersionStructure

attributes


O RGA NISA TIO N.


E lements for C O UPLED JO URNEY.

CoupledJourneyGroup

Description of C O UPLED JO URNEY.

Description

0 1..



TrainBlockRef

0 1..


V EHIC LE JO URNEYs making up the C O UPLED JO URNEY.

journeys

0 1..

type vehicleJourneyRefs_RelStructure

Figure 105 — CoupledJourney — XSD

7.2.9.4.3 JourneyPartCouple – Model Element

Two or more JOURNEY PARTs of different VEHICLE JOURNEYs served simultaneously by a train set up by coupling their single vehicles.

Table 57 – JourneyPartCouple – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> JOURNEY PART COUPLE Inherits from DATA

MANAGED OBJECT.

«PK» id JourneyPartCoupleIdType 1:1 Identifier of JOURNEY PART COUPLE.

order xsd:positiveInteger 1:1 Order of JOURNEY PART COUPLE within

TC 278 WI 00278308:2013 (E)

130

JOURNEY.

Description MultilingualString 0:1 Description of JOURNEY PART COUPLE.

«FK» FromPointRef ScheduledStopPointRef 1:1 Reference to POINT at which JOURNEY PART

COUPLE starts.

«FK» ToPointRef ScheduledStopPointRef 1:1 Reference to POINT at which JOURNEY PART

COUPLE ends.

«FK» BlockRef BlockRef 0:1 Reference to BLOCK associated with JOURNEY

PART COUPLE.

«FK» MainPartRef JourneyPartRef 1:1 Main JOURNEY PART associated with JOURNEY

PART COUPLE.

«cntd» joinedParts JourneyPartRef 0:* JOURNEY PARTs that JOURNEY PART COUPLE

joins.

«FK» TrainNumberRef TrainNumberRef 0:1 REFERENCE to TRAIN NUMBER of JOURNEY

PART COUPLE.

JourneyPartCouple_VersionStructure

Two or more JO URNEY PA RTs of different V EHIC LE

JO URNEYs serv ed simultaneously by a train set up by

coupling their single v ehicles.

JourneyPartCouple

(restriction)

type JourneyPartCouple_VersionStructure

attributes


O RGA NISA TIO N.


E lements for JO URNEY PA RT C O UPLe.

JourneyPartCoupleGroup

Time of Departure.

Description

0 1..


Start time of JO URNEY PA RT.

StartTime

type xsd:time

End time of JO URNEY PA RT.

EndTime

type xsd:time

Point at which this JO URNEY PA RT starts.

FromStopPointRef


Point at which this JO URNEY PA RT ends.

ToStopPointRef


Main Journey JO URNEY PA RT of coupling.

MainPartRef

type JourneyPartRefStructure

JO UREY PA RTs in JO URNEY PA RT C O UPLE.

journeyParts

0 1..

type journeyPartRefs_RelStructure

Reference to a TRA IN NUMBER.

TrainNumberRef

0 1..

type TrainNumberRefStructure

Figure 106 — JourneyPartCouple — XSD

131

7.2.9.4.4 PurposeOfJourneyPartition – Model Element

A classification of JOURNEY PARTITIONs according to their functional purpose.

Table 58 – PurposeOfJourneyPartition – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> TypeOfValue ::> PURPOSE OF JOURNEY PARTITION inherits from

TYPE OF VALUE

«PK» id PurposeOfJourney-

PartitionIdType

1:1 Identifier of PURPOSE OF JOURNEY PARTITION.

PurposeOfJourneyPartition_ValueStructure

A n operational purpose changing w ithin a JO URNEY

PA TTERN and w ith this subdiv iding the SERV IC E

JO URNEY into JO URNEY PA RTs.


(restriction)

type PurposeOfJourneyPartition_ValueStructure

attributes


O RGA NISA TIO N.



TypeOfValueGroup

Figure 107 — PurposeOfJourneyPartition — XSD

7.2.9.5 XML Example of Journey Parts & Couple Journeys

The following code fragment shows a SERVICE JOURNEY with three parts.

For EXAMPLE

<ServiceJourney version="any" id="hde:sj_447">

<Description>447 Amsterdam to Warsaw</Description>

<DepartureTime>09:00:00Z</DepartureTime>

<ServiceJourneyPatternRef version="any" ref="hde:JP_447_amsterdam_warsaw"/>

<TrainRef version="any" ref="hde:trn_447"/>

<BlockRef version="any" ref="ops:blk_447_amsterdam-warsaw"/>

<LineView>

<PublicCode>447</PublicCode>

<Name>Amsterdam to Warsaw Express</Name>

<TransportMode>rail</TransportMode>

</LineView>


<RouteRef version="any" ref="myrail:RT_447"/>


<DestinationDisplayRef version="any" ref="hde:DST_warsaw"/>


<parts>

<JourneyPart version="any" id="hde:jpt_447_01">

<ParentJourneyRef version="any" ref="hde:sj_447"/>

<MainPartRef version="any" ref="hde:vjp_447_01"/>

<JourneyPartCoupleRef version="any" ref="hde:jpc_01_amsterdam-hannover"/>

<TrainNumberRef version="any" ref="hde:tn_447"/>

<BlockPartRef version="any" ref="ops:blkpt_447_01_amsterdam-hannover"/>

<FromStopPointRef version="any" ref="uic:nl_amsterdam"/>

<ToStopPointRef version="any" ref="uic:de_hannover"/>

<StartTime>09:00:00Z</StartTime>

<EndTime>12:00:00Z</EndTime>

<Description>Amsterdam to Hannover</Description>

<PurposeOfJourneyPartitionRef

ref="hde:coupling">coupling</PurposeOfJourneyPartitionRef>

TC 278 WI 00278308:2013 (E)

132

</JourneyPart>



<MainPartRef version="any" ref="hde:JourneyPart:jpt_447_02"/>

<JourneyPartCoupleRef version="any" ref="hde:jpc_02_hannover-berlin"/>


<BlockPartRef version="any" ref="ops:BlockPart:blkpt_447_02_hannover-berlin"/>

<FromStopPointRef version="any" ref="uic:de_hannover"/>

<ToStopPointRef version="any" ref="uic:de_berlin"/>

<StartTime>12:00:00Z</StartTime>


<Description>Hannover to Berlin</Description>



</JourneyPart>



<MainPartRef version="any" ref="hde:JourneyPart:jpt_447_03"/>


<BlockPartRef version="any" ref="ops:blkpt_447_03_berlin-warsaw"/>

<FromStopPointRef version="any" ref="uic:de_berlin"/>

<ToStopPointRef version="any" ref="uic:pl_warsaw"/>

<StartTime>15:10:00.0Z</StartTime>


<Description>Berlin to Warsaw</Description>



</JourneyPart>

</parts>

<calls>

<Call id="hde:sj_447_001" version="any" order="1">

<ScheduledStopPointRef version="any" ref="uic:nl_amsterdam"/>

<Arrival>


</Arrival>

<Departure>

<Time>09:00:00.0Z</Time>

<ForBoarding>true</ForBoarding>

<journeyMeetings>

<JourneyMeetingView>

<JourneyMeetingRef version="any"

ref="hde:jm_457_joinTo_447_dep_amsterdam"/>

<Description>Join with 457 </Description>

<EarliestTime>09:00:00Z</EarliestTime>

<Reason>joining</Reason>

</JourneyMeetingView>

<JourneyMeetingView>

<JourneyMeetingRef version="any" ref="hde:jm_40447_joinTo_477_dep_amsterdam"/>

<Description>Join with 40447</Description>

<EarliestTime>09:00:00Z</EarliestTime>

<Reason>joining</Reason>

</JourneyMeetingView>

</journeyMeetings>

<ServiceJourneyInterchangeView>

<ServiceJourneyInterchangeRef version="any"

ref="hde:sji_sj_447_to_sj_457"/>

<Description>In Amsterdam Trains join </Description>

<StaySeated>true</StaySeated>





<ConnectingJourneyView>

<ServiceJourneyRef version="any" ref="hde:sj_457"/>

<ConnectingVisitNumber>1</ConnectingVisitNumber>

</ConnectingJourneyView>


</ServiceJourneyInterchangeView>

</interchanges> -->

<QuayAssignmentView>

<StopPlaceRef version="any" ref="uic:nl_amsterdam"/>

<QuayRef version="any" ref="uic:nl_amsterdam_1"/>

<QuayName>Platform 1</QuayName>

</QuayAssignmentView>

</Departure>

133

<DestinationDisplayRef version="any" ref="hde:DST_hannover"/>

</Call>


<ScheduledStopPointRef version="any" ref="uic:de_hannover"/>

<Arrival>

<Time>12:00:00.0Z</Time>

<ServiceJourneyInterchange id="hde:sji_sj_447_to_sj_40447">

<Description>In Amsterdam Carriages split to Copenhagen </Description>

<StaySeated>true</StaySeated>





<ConnectingJourneyView>

<ServiceJourneyRef version="any" ref="hde:sj_457"/>

<ConnectingVisitNumber>1</ConnectingVisitNumber>

</ConnectingJourneyView>



</Arrival>

<Departure>

<Time>12:05:00.0Z</Time>




<QuayRef version="any" ref="uic:de_hannover_5"/>



</Departure>


</Call>


<ScheduledStopPointRef version="any" ref="uic:de_berlin"/>

<Arrival>

<Time>15:00:00.0Z</Time>

</Arrival>

<Departure>

<Time>15:10:00.0Z</Time>




<QuayRef version="any" ref="uic::de_berlin_3"/>



</Departure>


</Call>


<ScheduledStopPointRef version="any" ref="uic:pl_warsaw"/>

<Arrival>

<Time>19:10:00.0Z</Time>


<QuayRef version="any" ref="uic:pl_warsaw_8"/>



</Arrival>

<Departure>


</Departure>

</Call>

</calls>

</ServiceJourney>

7.2.9.5.1 PurposeOfJourneyPartition – Model Element

An operational purpose to change the characteristic within a JOURNEY PATTERN with subdividing the SERVICE JOURNEY into JOURNEY PARTs.

7.2.9.5.2 TypeOfCoupling – Model Element

An operational purpose to change the characteristic within a JOURNEY PATTERN with subdividing the SERVICE JOURNEY into JOURNEY PARTs.

TC 278 WI 00278308:2013 (E)

134

7.2.10 Flexible Service

7.2.10.1 FLEXIBLE SERVICE – Conceptual MODEL

Flexible transport (i.e. Demand Responsive Transport) is characterised by flexible routing and scheduling. Flexible routing is described in the NeTEx Part 1 network topology chapter.

Flexible services can operated on regular line topologies or on a flexible topology. They are defined by extending the regular services with additional flexibility information, through the TYPE OF FLEXIBLE JOURNEY object. If this information is attached to a SERVICE JOURNEY (through FLEXIBLE JOURNEY PROPERTIEs) the all service is flexible. But if it is attached to POINT IN JOURNEY PATTERN, the SERVICE JOURNEY having a FLEXIBLE JOURNEY PROPERTIES will only be flexible on the indicated point (usually these POINTs IN JOURNEY PATTERN will also be SCHEDULED STOP POINTs). This can be used either for partially flexible service or for "mixed types of flexible service" inside the same JOURNEY.

Note that NeTEx point of view on flexible services is a passenger information point of view, not an operator point of view.

Several types of flexible services are available:

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

Dynamic PASSING TIMEs.

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 Stop (i.e. 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 optimise the service).

When a service is flexible, there may be no VEHICLE SERVICE scheduled, for example when they are only "on demand". In this situation a NeTEx dataset will provide a "ghost" VEHICLE SERVICE, being a regular one with FLEXIBLE JOURNEY PROPERTIES and no passing times (i.e. no attached CALLs). This is required in order to provide the possible VALIDITY CONDITIONS, DAY TYPEs, CALENDAR, etc. attached to this FLEXIBLE SERVICE.

135

class NeTEx FS Flexible Serv ice MODEL

Journey Pattern

MODEL::DEAD

RUN PATTERN

LINK SEQUENCE

Journey Pattern

MODEL::JOURNEY

PATTERN



POINT IN JOURNEY

PATTERN


TIMING LINK IN JOURNEY

PATTERN




PATTERN

Journey Pattern

MODEL::TYPE OF

JOURNEY PATTERN

Name: NeTEx FS Flexible Service MODEL

Author: NeTEx

Version: 1.0

Created: 08/01/2010 17:09:40

Updated: 03/10/2012 15:57:40

Serv ice Pattern

MODEL::SERVICE

JOURNEY PATTERN

TYPE OF FLEXIBLE

SERVICE

+ FlexibleServiceType

+ PossibleCancel lation

+ PossiblyMoved

Serv ice Journey

MODEL::SERVICE

JOURNEY

JOURNEY

Vehicle Journey

MODEL::VEHICLE

JOURNEY

FLEXIBLE

SERVICE

PROPERTIES

+made using

*

+for

1

+classification

for0..1

+classified as*

+on

1..*

+made up of

1

+the timing

reference for1

+by

default

timed

from

0..1

+classi fying 1

+classified by

*

+made up of 1

+in *

+classified as

1

+classification

for

0..1

+determined as

flexible by

1+determining the flexibi lity for

0..1

Figure 108 — Flexible Service – Conceptual MODEL (UML)

7.2.10.2 Flexible Service Example

There are numerous examples of flexible services. One of them is the TAD 118 (Tisséo, Toulouse area, France). The figure below provides a schematic map of this flexible service: the red points show the possible stops of the TAD 118 (depending on the demand) and the orange and green lines show the regular service (not flexible) lines.

The TAD 118 services start at 6h20 and end at 20h50 with a journey starting every 30 minutes at Colomiers Gare SNCF (if ther is sufficient demand). This is an example of FLEXIBLE SERVICE with fixed HEADWAY FREQUENCY (the line topology being a Flexible zone with fixed stops, see NeTEx Part 1 - 8.4.8.1 Flexible Network Introduction). In this example cancellation is not possible and PASSING TIME and stop place are not changed after booking.

TC 278 WI 00278308:2013 (E)

136

Figure 109 —Flexible service example: Tisseo TAD 118 (with courtesy of Tisseo, data from August 2012)

7.2.10.2.1 Flexible Service – Type of Flexible Service

The type of Flexible service may be specified on the Journey Pattern.

137

class XSD NeTEx FS Journey Pattern Model

LinkSequence


PointInLinkSequence


«PK»

~ id :PointInJourneyPatternIdType

«FK»

# JourneyPatternRef :JourneyPatternRef* [0..1]

# PointRef :PointRef* [0..1]

# DestinationDisplayRef :DestinationDisplayRef* [0..1]

«contained»

- vias :Via [0..*]

- noticeAssignments :NoticeAssignmentView [0..*]



Name: XSD NeTEx FS Journey Pattern Model

Author: NeTEx

Version: 1.0

Created: 21/09/2011 13:13:11

Updated: 04/04/2012 14:08:34

LinkInLinkSequence



Serv icePatternModel::Serv iceJourneyPattern

«PK»

+ id :ServiceJourneyPatternIdType

«FK»

# TypeOfServicePattern :TypeOfServicePatternEnum*

JourneyPatternModel::DeadRunPattern

«PK»

+ id :DeadRunJourneyPatternIdType [0..1]

TypeOfEnti ty


TypeOfJourneyPattern

«PK»

+ id :TypeOfJourneyPatternIdType

TypeOfValue

FlexibleServ iceModel::TypeOfFlexibleServ ice

+ Id :TypeOfFlexibleServiceIdType

VersionedChild

FlexibleServ iceModel::FlexibleServ iceProperties

+ CancellationPossible :boolean [0..1]

+ ChangeOfTimePossible :boolean [0..1]

# TypeOfFlexibleServiceRef :TypeOfFlexibleServiceRef* [0..1]

«PK»

+ id :FlexibleServicePropertiesIdType

«FK»

+ FlexibleServiceType :FlexibleServiceTypeEnum [0..1]

«contained»

- BookingArrangements :BookingArrangements [0..1]


Journey


+on

1..*

{ordered}

+made up

of

1

+made

using

*

+for 1

+classifying 0..1

+classified as *

+ timing reference for

1

+by default timed

from

0..1

+classifying 1

+classified by

*

0..1

+timed

from

*

+timing reference

for0..1

+made up

of

1

+in *

+calssifies 0..*

+type of 0..1

+flexible +properties

0..1

Figure 110 — Type of Flexible Service – Physical Model (UML)

7.2.10.2.2 Flexible Service – Physical Model details

The physical model introduces a set of attributes through two main nested elements:

BOOKING ARRANGEMENT describing, for on demand service, the type of booking (online, CallOffice, CallDriver, etc.), how long in advance of departure day or time a service may be ordered, etc.

CONTACT DETAILs providing URL, phone number, mail, etc. in order to book the service or to get information.

The following figure shows service and network elements relating to FLEXIBLE services.

TC 278 WI 00278308:2013 (E)

138

class XSD NeTEx TP Flexible Serv ice Model

DataManagedObject

Line

LinkSequence

Route

Name: XSD NeTEx TP Flexible Service Model

Author: NeTEx

Version: 1.0

Created: 01/07/2010 15:59:22

Updated: 04/12/2012 11:32:08

RoutePointRouteLink

FlexibleLine

FlexibleLineType :FlexibleLineTypeEnum

«PK»

id :BookableLineIdType

«contained»

BookingContact :ContactDetai ls [0..1]

BookingArrangements :BookingArrangements [0..1]

notes :Notice* [0..*]

stopPlaces :StopPlace* [0..*]

flexiblePlaces :FlexibleStopPlace* [0..*]

ScheduledStopPointZone

StopArea

Place

FlexibleStopPlace

Place

FlexibleQuay

FlexibleArea

Serv iceLink

TimingLink


«PK»

id :FlexibleAssignmentIdType

«FK»

FlexibleStopPlaceRef :FlexibleStopPlaceRef* [0..1]

QuayRef :FlexibleQuayRef* [0..1]

DataManagedObject

StopAssignment

TimingPoint

PointInLinkSequence

PointOnRoute

FlexibleRoute

FlexibleRouteType :FlexibleRouteTypeEnm

«PK»

id :FlexibleRouteIdType

«enumeration»

FlexibleLinkTypeEnum

hailAndRide

onDemand

other

fixed

«XSDcomplexType»

ContactDetails

ContactPerson :normalizedString [0..1]

Email :EmailAddressType [0..1]

Phone :PhoneNumberType [0..1]

Fax :PhoneNumberType [0..1]

Url :anyURI [0..1]

FurtherDetai ls :Multi l ingualString [0..1]

Organisation

Operator

«enumeration»

FlexibleBookingMethod

callDriver

cal lOffice

online

other

phoneAtStop

none

text

ValidityCondition

Av ailabilityCondition

VersionedChild

FlexibleLinkProperties

LinkRef :LinkRef* [0..1]

MayBeSkipped :boolean

OnMainRoute :boolean

UnscheduledPath :boolean

FlexibleLinkType :FlexibleLinkTypeEnum

«PK»

id :FlexibleLinkPropertiesIdType

DataManagedObject

Link

DataManagedObject

Point

VersionedChild



PointOnRouteRef :PointOnRouteRef* [0..1]

MayBeSkipped :boolean

OnMainRoute :boolean

PointStandingForAZone :boolean

ZoneContainingStops :boolean

«PK»

id :FlexiblePointPropertiesIdType

«enumeration»

BookingAccessEnum

public

authorisedPublic

staff

other

BookingArrangements

BookingMethods :BookingMethodEnum [0..*]

BookingAccess :BookingAccessEnum [0..1]

LatestBookingT ime :Multi l ingualString [0..1]

MinimumBookingPeriod :duration [0..1]

«contained»

bookingNotes :Notice* [0..*]

VersionedChild

FlexibleServ iceProperties

CancellationPossible :boolean [0..1]

ChangeOfTimePossible :boolean [0..1]

TypeOfFlexibleServiceRef :TypeOfFlexibleServiceRef* [0..1]

«PK»

id :FlexibleServicePropertiesIdType

«FK»

FlexibleServiceType :FlexibleServiceTypeEnum [0..1]

«contained»

BookingArrangements :BookingArrangements [0..1]

VersionFrame

TimetableFrame

VehicleJourney

Serv iceJourney

HailAndRideArea

TypeOfValue

TypeOfFlexibleServ ice

Id :TypeOfFlexibleServiceIdType

DataManagedObject

Notice

«enumeration»

FlexibleServ iceTypeEnum

dynamicPassingT imes

fixedPassingTimes

fixedHeadwayFrequency

notFlexible

Other

viewed as 1

a view of *

describes 0..1

is flexibl

through

1

{ordered}

on 1..*

run

by

0..*

primary 0..1

run by 0..*

additional 0..1

calssifies 0..*

type of 0..1

describes

0..1

is flexible

0..1

describes 0..1

is flexible

flexible

properties 0..1

booking times

assignment 0..*

of 1

for

0..*

l ine 0..1

on

1..*

made up of

1

inverse to 0..1

inverse of 0..1

to* end

of

1

start of

1

from

*

area

0..*

1

annotates 0..*

to* end of 1

stop

0..*

member of

0..*

part of 0..*within

1

assignment 0..*

to 1

scheduled 1

to 0..*

start of

1

from

*

start of

1

from

*

to

*

end of

1

Figure 111 — Flexible Service – Physical Model (UML)

7.2.10.3 Flexible Service – Attributes and XSD

7.2.10.3.1 FlexibleServiceProperties – Model Element

Additional Properties of a FLEXIBLE or demand responsive (DRT) service. A service may be part fixed, part flexible or completely flexible.

139

Table 59 — FlexibleServiceProperties – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> FLEXIBLE SERVICE PROPERTIES inherits from

DATA MANAGED OBJECT

«PK» id FlexibleService-

PropertiesIdType

1:1 Identifier of FLEXIBLE SERVICE PROPERTIES.

«FK» TypeOfFlexible-

ServiceRef

TypeOfFlexibleServiceRef 1:1 TYPE OF FLEXIBLE SERVICE for which these are

the properties.

«cntd» Booking-

Arrangements

BookingArrangements 0:1 Booking contact for FLEXIBLE SERVICE.

FlexibleService-

Type

FlexibleServiceTypeEnum 0:1 Flexible service type is

FixedPassingTimes/DynamicPassingTimes/FixedHe

adwayFrequency (in the last value, this provides a

maximum waiting time, but no passing time is

defined, all is done dynamically depending on the

demand). A NotFlexible value is probably also

required to clearly state that a Stop (i.e. Point in

JOURNEY PATTERN) is not flexible when others

are.

Cancellation-

Possible

xsd:boolean 0:1 Whether cancellation is always possible (meaning

the Operator can decided to cancel a journey,

usually because there are not enough passenger, or

they are too busy to run the service.)

ChangeOfTime-

Possible

xsd:boolean 0:1 PossiblyMoved flag tells that it may be moved

(usually passing time update to optimise the service)

(need for both PossibleCancelation and

PossiblyMoved since both can be true... these 2

attributes being really need only

forDynamicPassingTimes ).

TC 278 WI 00278308:2013 (E)

140

FlexibleServiceProperties_VersionStructure

A dditional characteristics of a F LEXIBLE SERV IC E. A serv ice may be partly fixed,

partly flexible.


(restriction)

type FlexibleServiceProperties_Vers...

attributes


O RGA NISA TIO N .


E lements for an indiv idual F LEXIBLE SERV IC E .

FlexibleServicePropertiesGroup

Reference to a TYPE O F F LEXIBLE SERV IC E.

TypeOfFlexibleServiceRef

0 1..

type TypeOfFlexibleServiceRefStruc...

F lexible serv ice ty pe is

F ixedPassingTimes/Dy namicPassingTi

mes/F ixedHeadw ay F requency (in the last v alue, this prov ides a maximum

w aiting time, but no passing time is

defined, all is done dy namically

depending on the demand). A NotF lexible v alue is probably also

required to clearly state that a S top

(i.e. Point in JP ) is not flexible w hen

others are

FlexibleServiceType

0 1..

type FlexibleServiceEnumeration

Whether cancellation is alw ay s

possible (meaning the O perator can decided to

cancel, usually because there

are not enough people, or

they are too busy to run serv ice.)

CancellationPossible

0 1..

type xsd:boolean

Whether the time of the serv cie

may be altered.

ChangeOfTim ePossible

0 1..

type xsd:boolean

E lements for BO O KING

A RRA NGEMENTs of a F LEXIBLE LINE. May be ov erridden on an

indiv idual F LEXIBLE SERV IC E.


Figure 112 — FlexibleServiceProperties — XSD

7.2.10.3.2 FlexibleStopAssignment – Model Element

The allocation of a SCHEDULED STOP POINT (i.e. a STOP POINT of a SERVICE PATTERN or JOURNEY PATTERN) to a specific FLEXIBLE STOP PLACE, and also possibly a FLEXIBLE AREA or HAIL AND RIDE AREA. May be subject to a VALIDITY CONDITION.

Table 60 – FlexibleStopAssignment – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> StopAssignment ::> FLEXIBLE STOP ASSIGNMENT inherits from

STOP ASSIGNMENT.

141

«PK» id FlexibleAssignmentIdType 1:1 Identifier of a FLEXIBLE STOP ASSIGNMENT.

«FK» ScheduledStop-

PointRef

ScheduledStopPointRef 0:1 Scheduled STOP POINT that is assigned to a

FLEXIBLE STOP PLACE by this FLEXIBLE STOP

ASSIGNMENT.

«FK» FlexibleStopPlace

Ref

FlexibleStopPlaceRef 0:1 FLEXIBLE STOP PLACE that is assigned to a

SCHEDULED STOP POINT by this FLEXIBLE

STOP ASSIGNMENT.

«FK» FlexibleQuayRef FlexibleQuayRef 0:1 FLEXIBLE QUAY that is assigned to a

SCHEDULED STOP POINT by this FLEXIBLE

STOP ASSIGNMENT.

FlexibleStopAssignment_VersionStructure

A ssignment of a SC HEDULED STO P PO INT to a

FLEXIBLE STO P PLA C E and quay . etc.


(restriction)

type FlexibleStopAssignment_Version...

attributes


O RGA NISA TIO N.


E lements for a STO P A SSIGNMENT.

StopAssignmentGroup

E lements for a F LEXIBLE STO P A SSIGNMENT.

FlexibleStopAssignmentGroup




Reference to a F LEXIBLE STO P PLA C E.

FlexibleStopPlaceRef

type FlexibleStopPlaceRefStructure

Reference to a FLEXIBLE Q UA Y.

FlexibleQuayRef

0 1..

type FlexibleQuayRefStructure

Reference to a F LEXIBLE A REA .

FlexibleAreaRef

type FlexibleAreaRefStructure

Reference to a HA IL A ND RIDE A REA .

HailAndRideAreaRef

type HailAndRideAreaRefStructure

Figure 113 — FlexibleStopAssignment — XSD

7.2.10.3.3 TypeOfFlexibleService – Model Element

Classification of a FLEXIBLE JOURNEY PATTERN. All the services on this type of JOURNEY PATTERN are flexible services.

Types of flexible services include :

- Virtual line service.

- Flexible service with main route.

- Corridor service.

- Fixed stop area-wide flexible service.

- Free area-wide flexible service.

- Mixed types of flexible service (not at POINT level).

The type of flexibility can be defined at JOURNEY PATTERN LEVEL or at POINT IN JOURNEY PATTERN LEVEL in case of "mixed types of flexible service" inside the same JOURNEY PATTERN

TC 278 WI 00278308:2013 (E)

142

Table 61 – TypeOfFlexibleService – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> TypeOfValue ::> TYPE OF FLEXIBLE SERVICE inherits from TYPE

OF VALUE

id TypeOfFlexibleServiceIdType 1:1 Type of FLEXIBLE SERVICE.

- Virtual line service.

- Flexible service with main route.

- Corridor service.

- Fixed stop area-wide flexible service.

- Free area-wide flexible service. - Mixed types of flexible service

TypeOfFlexibleService_ValueStructure

A classification of FLEXIBLE SERV IC Es according to their functional purpose.

TypeOfFlexibleService

(restriction)

type TypeOfFlexibleService_ValueStru...

attributes


O RGA NISA TIO N.


Elements for TYPE O F V A LUE.

TypeOfValueGroup

Figure 114 — TypeOfFlexibleService — XSD

7.2.10.4 XML Example of Flexible Service

The following code fragment shows a TEMPLATE VEHICLE JOURNEY with two different frequency groups.

For EXAMPLE



<ServicePatternRef version="any" ref="hde:svp_24o"/>

<LineRef version="any" ref="mybus:FlexibleLine:FL_24"/>






<calls>

<Call id="hde:sj_24o_01_001" order="1">


<Arrival>


</Arrival>

<Departure>

<Time>14:00:00.0Z</Time>

</Departure>

</Call>



<Arrival>

<Time>14:30:00.0Z</Time>

</Arrival>

<Departure>

<Time>14:32:00.0Z</Time>

143

</Departure>

</Call>



<Arrival>

<Time>15:10:00.0Z</Time>

</Arrival>

<Departure>


</Departure>

</Call>

</calls>

<FlexibleServiceProperties version="1" id="hde:sj_24o_02">

<TypeOfFlexibleServiceRef ref="myfs" version="any"/>

<BookingMethods>online callOffice</BookingMethods>

<BookingAccess>public</BookingAccess>

<LatestBookingTime>16:00:00Z</LatestBookingTime>

<MinimumBookingPeriod>PT2H</MinimumBookingPeriod>

<bookingNotes>

<NoticeRef version="1" ref="hde:sj_24o_02_BN"/>

</bookingNotes>

</FlexibleServiceProperties>

</ServiceJourney>

7.2.11 Journey Accounting

The JOURNEY ACCOUNTING provides a set of parameters characterizing VEHICLE JOURNEYs or SPECIAL SERVICEs used for accounting purposes in particular in contracts between ORGANISATIONs.

The accounting can be done based on the distance run by the JOURNEY, on its duration or on both.

7.2.11.1 JOURNEY ACCOUNTING – Conceptual MODEL

class NeTEx TP Journey Accounting MODEL

JOURNEY ACCOUNTING

+ Name [0..1]

+ Distance [0..1]

+ Duration [0..1]

+ Partial [0..1]

+ AccountingType [0..1]

«PK»

+ id


JOURNEY


JOURNEY

Vehicle Journey

MODEL::DEAD RUN


SERVICE JOURNEY


SPECIAL SERVICEGeneric

Organisation

MODEL::

ORGANISATION

Name: NeTEx TP Journey Accounting MODEL

Author: NeTEx

Version: 1.0

Created: 19/10/2011 14:40:09

Updated: 03/10/2012 15:58:34

+accounted by

0..1

+accounting

0..*

+defined by 0..*

+defining 0..1

Figure 115 — Journey Accounting – Conceptual MODEL (UML)

TC 278 WI 00278308:2013 (E)

144

7.2.11.2 Journey Accounting – Physical Model

class XSD NeTEx TP Journey Accounting Model

LinkSequence

Journey



TransportSubmode :TransportSubMode [0..1]

ExternalVehicleJourneyRef :normalizedString*

«PK»

id :JourneyIdType

«FK»

TypeOfProductCategoryRef :TypeOfProductCategoryRef* [0..1]

TypeOfServiceRef :TypeOfServiceRef* [0..1]

LinkSequenceProjectionRef :LinkSequenceProjectionRef* [0..1]

«contained»

journeyAccountings :JourneyAccounting [0..*]

Accessibili ty :Accessibil ityAssessment [0..1]

VehicleJourney

DeadRun

SpecialServ ice

Serv iceJourney

Name: XSD NeTEx TP Journey Accounting Model

Author: NeTEx

Version: 1.0

Created: 15/09/2011 17:28:33

Updated: 02/08/2012 14:44:42

DataManagedObject

JourneyAccounting


Distance :DistanceType [0..1]

Duration :duration [0..1]

Partial :boolean [0..1]

AccountingType :JourneyAccountingEnum [0..1]

«PK»

id :JourneyAccountingIdType

«FK»

AccountedObjectRef :ObjectRef* [0..1]

OrganisationRef :OperatorRef* [0..1]

ContractRef :SupplyContractRef* [0..1]


TemplateServ iceJourney

DataManagedObject

Organisation

«enumeration»

AccountingCov erageEnum

contract

subsidy

other

TimingPoint

ScheduledStopPoint

Link

Serv iceLink


StopPointInJourneyPattern

Serv icePattern

LinkSequence

JourneyPattern

made using *

for

1

made up of *

contributing to 1

viewed as 1

a view of *

made up of 1

defining *

accounting 0..*

accounting 0..1start of

1

from

*to

*

end of

1

accounting

0..*

accounted

by

0..1

defined

by

0..*

defining 0..1

for 0..1

described by

*

Figure 116 — Journey Accounting – Physical Model (UML)

7.2.11.3 Journey Accounting – Attributes and XSD

7.2.11.3.1 JourneyAccounting – Model Element

Parameters characterizing VEHICLE JOURNEYs or SPECIAL SERVICEs used for accounting purposes in particular in contracts between ORGANISATIONs.

Table 62 – JourneyAccounting – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> JOURNEY ACCOUNTING inherits from DATA

MANAGED OBJECT.

«PK» id JourneyAccountingIdType 1:1 Identifier of JOURNEY ACCOUNTING.

Name MultilingualString 0:1 Name of JOURNEY ACCOUNTING.

Distance DistanceType 0:1 Distance to us in for JOURNEY ACCOUNTING.

145

Duration xsd:duration 0:1 Duration to use for JOURNEY ACCOUNTING.

Partial xsd:boolean 0:1 Whether all or some of journey is subject to

ACCOUNTING.

AccountingType JourneyAccountingEnum 0:1 Nature of JOURNEY ACCOUNTING.

«FK» Accounted-

ObjectRef

ObjectRef 0:1 Object for which this provides the accounting.

«FK» OrganisationRef OperatorRef 0:1 Reference to ORGANISATION providing contract or

subsidy.

«FK» ContractRef SupplyContractRef 0:1 Supply Contract under which JOURNEY

ACCOUNTING is provided.

JourneyAccounting_VersionStructure

Parameters characterizing V EHIC LE JO URNEYs or

SPEC IA L SERV IC Es used for accounting purposes in particular in contracts between O RGA NISA TIO Ns.

JourneyAccounting

(restriction)

type JourneyAccounting_VersionStructure

attributes

C ommon Properties of an object managed by a responsible O RGA NISATIO N.


E lements for a JO URNEY A C C O UNTING.

JourneyAccountingGroup

Description of A C CO UNTING or contract.

Name

0 1..


O bject for which this accounts.

AccountedObjectRef

0 1..

type OrganisationRefStructure

O RGA NISA TIO N contracting serv ice.

OrganisationRef

0 1..

type OrganisationRefStructure

Reference to a SUPPLY C O NTRA C T.

SupplyContractRef

0 1..

type SupplyContractRefStructure

A ccounting code to assign to Journey .

AccountingCode

0 1..


Nature of cov erage contract, subsidy . Default is contract.

AccountingType

0 1..

type JourneyAccountingEnumeration

Whether all or part of the journey is cov ered.

Partial

0 ∞..

type xsd:boolean

Distance for accounting purposes. If omitted use Journey distance.

Distance

0 1..

type DistanceType

Specifies the paid duration for this serv ice journey . Might

differ from the run time.

Duration

0 1..

type xsd:duration

Figure 117 — JourneyAccounting — XSD

TC 278 WI 00278308:2013 (E)

146

7.2.11.3.1.1 JourneyAccountingType – Allowed values

The following table shows the allowed values for JourneyAccountingType (JourneyAccountingTypeEnum).

Table 63 – JourneyAccountingType – Allowed values

Value Description

contract Journey is undertaken under contract.

subsidy Journey is undertaken under subsidy.

other Other

7.2.11.4 XML Example of Journey Accounting

The following code fragment shows Journey ACCOUNTINGs on a SERVICE JOURNEYs.

For EXAMPLE


<journeyAccountings>

<JourneyAccounting id="mytim:ac02">

<OrganisationRef xsi:type="AuthorityRefStructure" ref="txc:xshire"/>

<AccountingType>subsidy</AccountingType>

<Partial>false</Partial>

<Distance>20</Distance>

</JourneyAccounting>

<JourneyAccounting id="mytim:ac02">

<OrganisationRef xsi:type="AuthorityRefStructure" ref="txc:xshire”/>

<AccountingType>contract</AccountingType>

<Partial>false</Partial>

<Distance>20</Distance>

</JourneyAccounting>

</journeyAccountings>


<ServicePatternRef version="any" ref="hde:ServicePattern:svp_24o"/>

<TimeDemandTypeRef version="any" ref="mybus:TimeDemandType:tdt_01"/>


7.2.12 Dated Journey

7.2.12.1 Dated Journey Package dependencies

The Dated Journey model extends the Vehicle Journey Model.

147

pkg XSD NeTEx - Part 2 - Dated Journey Package Dependencies

XSD NeTEx - Part 2 - Schedules and Versions

XSD NeTEx - Part 2 - Passenger Information


XSD NeTEx - Part 1 - Tactical Planning XSD NeTEx - Part 2 - Journey & Journey Times

XSD NeTEx - Part 2 - Operations & Monitoring

TimeDemandTypePackage

TimeDemandTypeModel

T imeDemandTypeSupportVehicleJourneyPackage

VehicleJourneyModel

VehicleJourneySupport

DatedJourneyPackage

DatedJourneyModel

DatedCallModel

DatedJourneySupport

NoticeAssignmentPackage

NoticeAssignmentModel


JourneyPatternPackage

JourneyPatternModel

JourneyPatternView

JourneyPatternSupport

VehicleTypePackage

VehicleTypeModel

ServiceRequirementModel

VehicleTypeSupport

Serv icePatternPackage

ServicePatternModel

ServicePatternViews

ServicePatternSupport

MonitoringPackage

MonitoringModel

MonitoringSupport

VehicleServ icePackage

VehicleServiceModel

TrainServiceModel

VehicleServiceSupport

TimetableFramePackage

TimetableFrameModel

PassingTimesPackage

PassingTimesModel

PassingTimeSupport

JourneyPatternTimesPackage

JourneyPatternTimesModel

JourneyPatternTimesSupport

VehicleAssignmentPackage

VehicleAssignmentModel

ResourceAssignmentModel

VehicleAssignmentSupport

JourneyTimingPackage

JourneyTimingModel

JourneyTimingSupport

TimeDemandTimesPackage

TimeDemandTimesModel

TimeDemandProfileModel

TimeDemandTimesSupport

Name: XSD NeTEx - Part 2 - Dated Journey Package Dependencies

Author: NeTEx

Version: 1.0

Created: 14/01/2010 13:06:30

Updated: 12/10/2012 14:06:47

PassengerInformationEquipmentPackage

PassengerInformationEquipmentModel

PassengerInformationEquipmentSupport

DatedPassingTimesPackage

DatedPassingTimesModel

DatedPassingTimeSupport

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

«merge»

Figure 118 — Dated Journey Package Dependencies

7.2.12.2 DATED JOURNEY – Conceptual MODEL

Many reasons lead to modify the operational plan in the short term: special events, changes in the road infrastructure, incidents, etc. Some VEHICLE JOURNEYs may be added or deleted, may use alternative or shortened ROUTEs and JOURNEY PATTERNs, occasional services may be added, etc. If these changes are only valid for one or a few days, the reference schedule for a DAY TYPE is maybe not modified, but the changes are only stored for the appropriate OPERATING DAYs: the DATED VEHICLE JOURNEY describes a vehicle journey planned for one specific OPERATING DAY.

The NORMAL DATED VEHICLE JOURNEYs are based upon a VEHICLE JOURNEY, as produced for a DAY TYPE by the scheduling process. If there is no disturbance in the service, these normal journeys will be an exact image of the theoretical plan, applied to the specific OPERATING DAY. However, short-term modifications may be applied to these journeys, for instance when the controller decides to let a vehicle turn before the terminus. Such a control action updates the latest valid plan and produces a modified version of the DATED VEHICLE JOURNEY (provided as explanation but outside of NeTEx scope).

A DATED VEHICLE JOURNEY serves one JOURNEY PATTERN. The classification of JOURNEY PATTERNs through TYPE OF JOURNEY PATTERN may include some categories of occasional JOURNEY PATTERNs, to be used only by extra or modified DATED VEHICLE JOURNEYs (e.g. for occasionally shortened or deviated routes). In this situation, NeTEx allows the exchange of such of occasional JOURNEY PATTERNs without any VEHICLE JOURNEY operating it (for example, a scheduling system sends these occasional JOURNEY PATTERNs to an AVMS who will use some for operational control to create extra VEHICLE JOURNEY serving them).

The following schema also provides some PASSING TIMEs description: detailed explanations of PASSING TIMEs are provided in following sections.

TC 278 WI 00278308:2013 (E)

148

class NeTEx TM OM Dated Journey MODEL

JOURNEY

Vehicle Journey MODEL::VEHICLE JOURNEY

Serv ice Calendar

MODEL::DAY TYPE

LINK SEQUENCE

Journey Pattern MODEL::JOURNEY PATTERN


DATED VEHICLE JOURNEY

«PK»

+ id

Serv ice Calendar

MODEL::OPERATING

DAY

NORMAL DATED

VEHICLE JOURNEY

+ ServiceAlteration



POINT IN JOURNEY

PATTERN

Passing Times MODEL::DATED

PASSING TIME

Passing Times MODEL::PASSING

TIME

Passing Times MODEL::TARGET

PASSING TIME

Notice Assignment MODEL::

NOTICE ASSIGNMENT

Notice MODEL::NOTICE

+for *

+at 1

+marked

by

0..1

+assigned

to*

+start

of0..1

+from*+to *

+end

of0..1

+dated on*

+date of 1

+using

*

+used

by1

+used by

0..1

+altered to use

*+assigned

to

*

+marked

by

0..1

+for 1

+worked on *

+made

using *

+for

1

+on 1..*

+made up of 1

+worked

on*

+for 1..*

+using *

+used by 1

+including 0..1

+in *

Figure 119 — Dated Journey — Conceptual MODEL (UML)

7.2.12.2.1 NeTEx vs. SIRI Scope of Dated Vehicle Journeys

Additional DATED VEHICLE JOURNEYs may be included in the production plan for an OPERATING DAY. Such extra DATED VEHICLE JOURNEYs may be created de novo, or by duplication of an existing journey, with modification of the departure time and other properties. They may for instance correspond to a reinforcement of the service, or result from a complete rescheduling.

The exchange of DATED VEHICLE JOURNEYs for operational purposes (e.g. between an AVMS and a passenger information system) is considered out of scope for NeTEx since this is already covered by the SIRI-PT Publication Timetable Service. The SIRI-PT service in effect uses a view of the NeTEx DATED VEHICLE JOURNEY optimised for its purposes.

However, the NORMAL DATED VEHICLE JOURNEY is an important object for exchanges between scheduling systems and AVMS, and as the NORMAL DATED VEHICLE JOURNEY inherits from the DATED VEHICLE JOURNEY, these both objects are available in NeTEx.

7.2.12.3 Dated Journey – Physical Model

The following diagram shows the DATED JOURNEY physical model.

149

class XSD NeTEx OM Dated Journey Model

DatedJourneyModel::


ServiceAlteration :ServiceAlterationEnum

Name: XSD NeTEx OM Dated Journey Model

Author: NeTEx

Version: 1.0

Created: 30/11/2009 10:18:11

Updated: 02/08/2012 15:35:08

Journey

DatedJourneyModel::DatedVehicleJourney

«PK»

id :DatedVehicleJourneyIdType

«FK»

DriverRef :LogicalDriverRef* [0..1]


OperatingDayRef :OperatingDayRef*

DatedPatternRef :JourneyPatternRef* [0..1]

«contained»

datedTimes :TargetPassingTime [0..*] {ordered}

datedCalls :DatedCall [0..*] {ordered}

Journey


DatedPassingTimesModel::TargetPassingTime

AimedArrivalTime :time [0..1]

AimedDepartureTime :time [0..1]

AimedNonstopPassingTime :time [0..1]

AimedWaitingTime :duration [0..1]

AimedHeadway :HeadwayInterval [0..1]

«PK»

id :AimedPassingTimeIdType [0..1]

LinkSequence


DataManagedObject


DataManagedObject

NoticeModel::Notice

VersionedChild

NoticeAssignmentModel::NoticeAssignment

VersionedChild

PassingTimesModel::PassingTime

AlightAndReboard :boolean


«PK»

id :T imetabledPassingTimeIdType [0..1]

«FK»

JourneyRef :JourneyIdType* [0..1]

PointInJourneyPatternRef :PointInJourneyPatternRef* [0..1]

DatedPassingTimesModel::DatedPassingTime

DatedJourneyRef :JourneyIdType* [0..1]

«PK»

id :DatedPassingTimeIdType

DataManagedObject

ValidityModel::ValidityCondition

DataManagedObject


OperatingDay

DataManagedObject

LineModel::

DestinationDisplay

«enumeration»


Serv iceAlterationEnum

planned

cancellation

extraJourney

GroupOfEntities




HeadwayJourneyGroup

HeadwayInterval :HeadwayInterval [0..1]

HeadwayDisplay :HeadwayUseEnum [0..1]

«PK»

id :HeadwayJourneyGroupIdType [0..1]





worked on *

for

1

composed of

1..*

runs on 0..1

named by *

advertised for 0..1

operates

0..* on 0..1

valid

on0..1assigned to

*

marked by 0..1

assigned to *using

*

used by 1

/used

by

0..1

{Must be same as that of Vehicle

Journey}altered to use

*

on

0..*

day type

made using

*

for

1

assigned

to

0..*

marked

by

using*

used by

1

using*

used by1

for 0..*

at

for*

at 1

restricting*

defined for *

Figure 120 — Dated Journey – Physical Model (UML)

7.2.12.4 Dated Journey – Attributes and XSD

7.2.12.4.1 DatedVehicleJourney – Model Element

A particular journey of a vehicle on a particular OPERATING DAY.

Table 64 – DatedVehicleJourney – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> VehicleJourney ::> DATED VEHICLE JOURNEY inherits from

VEHICLE JOURNEY.

«PK» id DatedVehicleJourney-

IdType

1:1 Identifier of DATED VEHICLE JOURNEY.

«FK» JourneyRef VehicleJourneyRef 0:1 VEHICLE JOURNEY for which this is a DATED

VEHICLE JOURNEY.

«FK» OperatingDayRef OperatingDayRef 1:1 OPERATING DAY for DATED VEHICLE JOURNEY.

«AK» ExternalDated-

JourneyRef


DATED VEHICLE JOURNEY, specifically for use in

AVMS systems.


TC 278 WI 00278308:2013 (E)

150

«FK» DatedJourney-

PatternRef

JourneyPatternRef 0:1 DATED JOURNEY PATTERN of DATED VEHICLE

JOURNEY.

«FK» DriverRef DriverRef 0:* DRIVER of DATED VEHICLE JOURNEY.

«cntd» datedPassing-

Times

TargetPassingTime 0:* Passing times of DATED VEHICLE JOURNEY.

«cntd» datedCalls DatedCall 0:* CALLs of DATED VEHICLE JOURNEY.

7.2.12.4.1.1 DatedVehicleJourneyReferencesGroup — Group

E lements for DA TED V EHIC LE JO URNEY REFERENC Es.

DatedVehicleJourneyReferencesG...


JourneyRef






ServiceJourneyRef






SpecialServiceRef




VehicleJourneyRef



DeadRunRef


Reference to an O PERA TING DA Y.

OperatingDayRef

type OperatingDayRefStructure


DatedJourneyPatternRef


Reference to a DRIV ER.

DriverRef

type DriverRefStructure

Figure 121 — DatedVehicleJourneyReferencesGroup — XSD

151

7.2.12.4.2 NormalDatedVehicleJourney – Model Element

A DATED VEHICLE JOURNEY identical to a long-term planned VEHICLE JOURNEY.

Table 65 – NormalDatedVehicleJourney – Element

Classific

ation

Name Type cardinali

ty

Description

ServiceAlteration ServiceAlterationEnum 1:1 Service alteration type for NORMAL JOURNEY. See

SERVICE JOURNEY.

NormalDatedVehicleJourney_VersionStructure

A DA TED V EHIC LE JO URNEY identical to a long-term

planned V EHIC LE JO URNEY, possibly updated according to

short-term modifications of the PRO DUC TIO N PLA N decided by the control staff.


(restriction)

type NormalDatedVehicleJourney_Ver...

attributes


O RGA NISA TIO N.



LinkSequenceGroup


JourneyGroup

E lements for V EHIC LE JO URNEY.

VehicleJourneyGroup E lements for V EHIC LE JO URNEY.

VehicleJourneyPropertiesGroup



E lements for DA TED V EHIC LE JO URNEY.

DatedVehicleJourneyGroup

E lements for NO RMA L DA TED V EHIC LE JO URNEY.

NormalDatedVehicleJourneyGroup

Ty pe of Serv ice alteration. Default is planned.

ServiceAlterationType

0 1..

type ServiceAlterationEnumeration

Figure 122 — NormalDatedVehicleJourney — XSD

7.2.13 Passing Times

NOTE The following explanations use excerpts from Transmodel.PASSING TIMES – Conceptual MODEL

Many different types of passenger information systems require data about the planned and actual arrival and departure times of vehicles; usually without requiring access to the detailed scheduling data used to compute it. In the conceptual model, such data is represented in a highly normalised form as PASSING TIMEs. Each PASSING TIME indicates the time of a vehicle at a point in a journey pattern. There can be different types of time (arrival, departure, estimated, observed, etc.)

In the Physical model PASSING TIMEs may also be exchanged in context using CALLs, which in effect provide a slightly denormalised view of a POINT IN JOURNEY PATTERN combined with one or more PASSING TIMEs.

7.2.13.1 Timing Computation of a Journey

The computation of timings is not in the scope of NeTEx (NeTEx allows only to exchange the source information, or the result of the computation). But an understanding of this process gives an insight into the role of the timing elements of the NeTEx model.

To compute the timing of a VEHICLE JOURNEY an initial TIMING POINT belonging to the JOURNEY PATTERN for the journey is chosen as a timing reference and a ‘departure time’ is specified for the journey at this point. An initial TIME DEMAND TYPE is chosen that applies for that moment time. The standard run

TC 278 WI 00278308:2013 (E)

152

and wait times for the TIMING LINK to be applied for that TIME DEMAND TYPE are used to compute the time to the next TIMING POINT. The standard times for the TIMING LINKs may be overridden by specific times from the journey pattern, if they exist. The process is repeated for each TIMING POINT and each TIMING LINK in the JOURNEY PATTERN, if necessary changing the TIME DEMAND TYPE in effect at that time in the journey (and hence the wait and run times in effect). The VEHICLE JOURNEY is hence timed at all TIMING POINTs served by the JOURNEY PATTERN.

A journey that acts as a distributor journey for an incoming feeder journey may be further constrained as to its possible departure times by the JOURNEY MEETING or INTERCHANGE RULEs in effect for the meeting.

Not all the SCHEDULED STOP POINTs served by the JOURNEY PATTERN are necessarily TIMING POINTs. It is still useful to compute passing times at such intermediate SCHEDULED STOP POINTs. This is made by interpolation, taking into account for instance the distance between STOP POINTs.

7.2.13.2 Different types of passing times

In the design of the operational plan for a specific OPERATING DAY, planned passing times may be amended by changes made on the schedule. This will produce “target passing times” for this day, supporting the monitoring of operations. In addition, forecasts may be made on “estimated passing times”, mainly for passenger information, and actually “observed passing times” may be recorded by a monitoring system. All these concepts are described by the generic entity PASSING TIME, which has several sub-types.

Only TIMETABLED PASSING TIME and to some extent TARGET PASSING TIME from a NORMAL DATED VEHICLE JOURNEY are really scheduled information and therefore in the scope of NeTEx Part 2.

A first calculation of DATED PASSING TIMEs may be carried out as soon as the DATED VEHICLE JOURNEYs for a particular OPERATING DAY are defined (being NORMAL DATED VEHICLE JOURNEYs). Such passing times are called TARGET PASSING TIMEs.

Later on, modifications of the plan for a specific OPERATING DAY, in particular changes in journeys, are likely to generate the need to modify the passing times (usually in the operation control system or the AVMS).

The TARGET PASSING TIMEs are normally generated for the first time a few days before the OPERATING DAY, and are from that moment on constantly updated, according to the modifications operated to the schedule. The TARGET PASSING TIME can be seen as the latest official plan for vehicle operation.

The other PASSING TIMEs concepts are described below for information, but are relevant for SIRI (real-time information exchange), not for NeTEx.

The drivers will certainly try to meet the TARGET PASSING TIMEs, but in practice the vehicle may deviate from this plan due to the traffic circumstances. Various systems (such as AVM) can monitor these deviations and provide an estimation of PASSING TIMEs at the next stop points, for passenger information or for service control. Such ESTIMATED PASSING TIMEs will be displayed at stops and will be used for trip planning queries. They may be used as well by the AVM system, in order for instance to alert the controller on a forecasted delay for a relief.

The OBSERVED PASSING TIME describes the actual PASSING TIMEs that have been recorded at a specific POINT. This information is used to compute further ESTIMATED PASSING TIMEs and, of course, for statistical purposes. OBSERVED PASSING TIMEs are resulting from the monitoring process and are therefore related to a MONITORED VEHICLE JOURNEY.

153

7.2.13.3 Passing Time details

7.2.13.3.1 Timetabled Passing Times

The PASSING TIMEs that are the result of the scheduling process and to be published in a timetable are called TIMETABLED PASSING TIMEs.

The TIMETABLED PASSING TIMEs are normally generated a long time before the day of operation and are valid for a long period of time (e.g. summer, winter timetable). They are calculated for the planned NORMAL DATED VEHICLE JOURNEYs that were defined during the scheduling process. They may be computed as well for any extra DATED VEHICLE JOURNEY created by a CONTROL ACTION.

The TIMETABLED PASSING TIMEs can be calculated for the TIMING POINTs that were used for scheduling, but they are often also generated through interpolation, for POINTs that were not defined as TIMING POINTs (for instance for all STOP POINTs of a JOURNEY PATTERN). Therefore, a TIMETABLED PASSING TIME is defined for a POINT IN the JOURNEY PATTERN that the journey in question is serving.

7.2.13.3.2 Actual Passing Times (informative)

The PASSING TIMEs that are computed on a specific OPERATING DAY are called DATED PASSING TIMEs. DATED PASSING TIME has several subtypes:

TARGET PASSING TIME, the latest official plan for a DATED VEHICLE JOURNEY, on a POINT IN JOURNEY PATTERN;

ESTIMATED PASSING TIME, a forecast for a MONITORED VEHICLE JOURNEY, on a POINT IN JOURNEY PATTERN;

OBSERVED PASSING TIME, recorded for a MONITORED VEHICLE JOURNEY, on a particular POINT.

7.2.13.3.3 Passing Times Attributes

The sub-types of PASSING TIME have several optional attributes, expressing the time value of a possible:

Arrival time.

Departure time.

Waiting time (in general associated to one of the previous two).

Non-stop passing time when the vehicle is not obliged to stop.

Latest arrival time, being the operator or authority commitment, and very useful for dynamic interchange management (e.g. for a journey planner), it also provides some accuracy information on the arrival time.

Earliest departure time, being the operator or authority commitment, and very useful for dynamic interchange management (e.g. for a journey planner), it also provides some accuracy information on the departure time.

In operations of transport modes such as railway, ferry, etc., the functions carried out when a vehicle passes a stop point are much more complex than, for instance, in bus operations. Passengers may be allowed, when the stopping time is sufficient, to alight for a while (e.g. for refreshment) before resuming their trip on the same vehicle. Some facilities or some specific passenger information may be provided on this occasion.

TC 278 WI 00278308:2013 (E)

154

A PASSING TIME may be a simple passage (e.g. of a bus at a stop point) or a longer stay (e.g. in a maritime port of call). The attribute AlightAndReboard expresses the possibility for the passenger to alight for a while, during the PASSING TIME of a VEHICLE JOURNEY at a particular STOP POINT.

7.2.13.4 Passing Times – Physical Model

7.2.13.4.1 Timetabled Passing Times – Physical Model

The PASSING TIMEs physical model is shown in the following figure and introduces detailed attributes. These include HEADWAY INTERVAL attributes that may be useful to present frequencies of a journey at the stop.

class XSD NeTEx OM Passing Times Model

VersionedChild




«PK»

id :TimetabledPassingTimeIdType [0..1]

«FK»



PassingTimesModel::TimetabledPassingTime

ArrivalTime :time [0..1]

DepartureTime :time [0..1]

WaitingTime :duration [0..1]

Headway :HeadwayInterval [0..1]

EarliestDepartureTime :time [0..1]

LatestArrivalTime :time [0..1]

«PK»

id :PassingTimeIdType [0..1]

Name: XSD NeTEx OM Passing Times Model

Author: NeTEx

Version: 1.0

Created: 27/11/2009 22:36:47

Updated: 02/08/2012 15:23:35



«PK»


«FK»




«contained»

vias :Via [0..*]


LinkSequence


VersionedChild

PointAndLinkSequenceModel::

PointInLinkSequence

LinkSequence

VehicleJourneyModel::Journey

Link






at

for 0..*

passed at 1at * for *

at 1

made using

*

for

1

on1..*

{ordered}

made up of 1

ar 0..*

passed 1

from 0..*

to 0..1

Figure 123 — Timetabled Passing Times – Physical Model (UML)

7.2.13.4.2 Dated Passing Times – Physical Model

The DATED PASSING TIMEs physical model is shown below.

155

class XSD NeTEx OM Dated Passing Times Model



«PK»


VersionedChild




«PK»


«FK»









«PK»









«PK»


Journey


«PK»


«FK»





«contained»



Name: XSD NeTEx OM Dated Passing Times Model

Author: NeTEx

Version: 1.0

Created: 13/12/2010 10:25:30

Updated: 12/10/2012 16:01:10

Journey



«PK»


«FK»




«contained»

vias :Via [0..*]


LinkSequence


«PK»


«FK»







«contained»


waitT imes :JourneyPatternWaitTime [0..*]




linksInSequence :LinkInJourneyPattern [0..*]

VersionedChild


PointInLinkSequence

passed at 1

at

*

for *

at 1

for 0..*

at

/used

by0..1



*

using *

used by 1

for

*

at 1

on

1..*

{ordered}

made up of1

made using

*

for

1

ar

0..*

passed

1

Figure 124 — Dated Passing Times – Physical Model (UML)

7.2.13.5 Passing times – Attributes and XSD

7.2.13.5.1 PassingTime – Model Element

Time data concerning public transport vehicles passing a particular POINT; e.g. arrival time, departure time, waiting time.

Table 66 – PassingTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> VersionedChild ::> PASSING TIME inherits from VERSIONED CHILD.

«PK» id TimetabledPassing-

TimeIdType

0:1 Identifier of TIMETABLED PASSING TIME.

«FK» JourneyRef JourneyRef 0:1 Reference to JOURNEY for which this is a PASSING

TIME.

AlightAndReboard xsd:boolean 1:1 Number of days that the departure day is after the

start day of vehicle journey.

DayOffset xsd:integer 0:1 Number of days departure day is after start day of

vehicle journey.

«FK» PointInJourney-

PatternRef

PointInLinkSequenceRef 0:1 POINT IN SEQUENCE for which this is a PASSING

TIME.

TC 278 WI 00278308:2013 (E)

156

PassingTime_VersionedChildStructure

PA SSING TIME.

PassingTime

type PassingTime_VersionedChildStru...

attributes


VersionedChildGroup

Time demand elements.

PassingTimeGroup


JourneyRef






ServiceJourneyRef






SpecialServiceRef




VehicleJourneyRef



DeadRunRef


Whether can alight and reboard at stop.

AlightAndReboard

type xsd:boolean

Number of day s of departure time after prev ious arriv al

time.

DayOffset

type xsd:integer

Reference to a PO INT IN JO URNEY PA TTERN. If Giv en

by C ontext does not need to stated.

PointInJourneyPatternRef

type PointInJourneyPatternRefStructure

Reference to a STO P PO INT IN SEQ UENC E. If giv en by

context does not need to be stated.

StopPointInJourneyPatternRef

type StopPointInJourneyPatternRefStru...

Reference to a TIMING PO INT IN JO URNEY PA TTERN.

If giv en by context does not need to be stated.

TimingPointInJourneyPatternRef

type TimingPointInJourneyPatternRefSt...

TIMETA BLED PA SSING TIME at TIMING PO INT.


type TimetabledPassingTime_Versione...

Figure 125 — PassingTime — XSD

157

7.2.13.5.2 TimetabledPassingTime – Model Element

Long-term planned time data concerning public transport vehicles passing a particular POINT IN JOURNEY PATTERN on a specified VEHICLE JOURNEY for a certain DAY TYPE. Note that for Journey lasting more than one day, a possible DayOffset is available in passingTimeGroup (see above). If DepartureTime is not in the same day as ArrivalTime the information will be provided thanks to the WaitingTime.

Table 67 – TimetabledPassingTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> PassingTime ::> TIMETABLED PASSING TIME inherits from

PASSING TIME.

«PK» id PassingTimeIdType 0:1 Identifier of PASSING TIME.

ArrivalTime xsd:time 0:1 Arrival time at POINT IN PATTERN.

DepartureTime xsd:time 0:1 Departure time at POINT IN PATTERN.

WaitingTime xsd:duration 0:1 Waiting time at POINT IN PATTERN.

Headway HeadwayInterval 0:1 Headway interval at POINT IN PATTERN.

EarliestDepartureTime xsd:time 0:1 Earliest Departure time at POINT IN PATTERN.

LatestArrivalTime xsd:time 0:1 Latest Arrival time at POINT IN PATTERN.

TC 278 WI 00278308:2013 (E)

158

TimetabledPassingTime_VersionedChildStructure

TIMETA BLED PA SSING TIME at TIMING PO INT.


(restriction)

type TimetabledPassingTime_Versione...

attributes


VersionedChildGroup


PassingTimeGroup

TIEMTA BLED PA SSING TIME elements.

TimetabledPassingTimeGroup

Timetabled arriv al time.

ArrivalTime

0 1..

type xsd:time

Timetabled departure time.

DepartureTime

0 1..

type xsd:time

Timetabled waiting interv al.

WaitingTime

0 1..

type xsd:duration

F requency of serv ice.

Headw ay

0 1..

type Headw ayIntervalStructure

Latest A rriv al Time.

LatestArrivalTime

0 1..

type xsd:time

Earliest Timetabled departure time.

EarliestDepartureTime

0 1..

type xsd:time

Figure 126 — TimetabledPassingTime — XSD

7.2.13.6 Dated Passing times – Attributes and XSD

7.2.13.6.1 DatedPassingTime – Model Element

A PASSING TIME on a particular OPERATING DAY.

Table 68 – DatedPassingTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> PassingTime ::> DATED PASSING TIME inherits from PASSING

TIME.

«PK» id DatedPassingTimeIdType 1:1 Identifier of DATED PASSING TIME.

DatedJourneyRef JourneyRef 0:1 DATED VEHICLE JOURNEY for which this is a

PASSING TIME.

159

DatedPassingTime_VersionedChildStructure

DA TED PA SSING TIME.

DatedPassingTime

type DatedPassingTime_VersionedChil...

attributes


VersionedChildGroup


PassingTimeGroup

Dated PA SSING TIME elements.

DatedPassingTimeGroup

Dated journey for w hich this is the PA SSING TIME. If

giv en by context does not need to be restated.

DatedJourneyRef


TA RGET PA SSING TIME.

TargetPassingTime

type TargetPassingTime_VersionedChi...

Figure 127 — DatedPassingTime — XSD

7.2.13.6.2 EstimatedPassingTime – Model Element

Out of NeTEx scope: see A.2.2.1.1

7.2.13.6.3 ObservedPassingTime – Model Element


7.2.13.6.4 TargetPassingTime – Model Element


7.2.14 Call

7.2.14.1 CALL – Conceptual MODEL

Ordered collections of CALLs may be included in SERVICE JOURNEYs and DEAD RUNs exchanged with NeTEx.

A CALL provides a view of a POINT IN JOURNEY PATTERN that assembles data related to the visit to a stop of a VEHICLE JOURNEY at each SCHEDULED STOP POINT of the journey’s SERVICE PATTERN and possibly other POINT IN JOURNEY PATTERNs (TIMING POINTS). It additionally can include derived data in a form convenient for data exchange and processing of journeys by displays, including :

PASSING TIMEs, grouped by arrival and departure;

Stop usage information (passthrough, no boarding, etc.);

DESTINATION DISPLAY and VIA information;

STOP ASSIGNMENTs to specific QUAYs i.e. platforms;

Visit number (order within the VEHICLE JOURNEY, including repeated visits);

TC 278 WI 00278308:2013 (E)

160

Referenced entities and their derived properties, such as SCHEDULED STOP POINT, JOURNEY PARTs, SERVICE JOURNEY INTERCHANGES, SERVICE LINKs, etc;

NOTICEs relating to the stop.

The use of a CALL simplifies the manipulation of data for passenger information delivery. The concept of a CALL is shared with SIRI.

161

class XSD NeTEx TP Call Model

DerivedView

«TM_VIEW»

LineAndRouteViews::


DataManagedObject


Name: XSD NeTEx TP Call Model

Author: nickk

Version: 1.0

Created: 07/02/2011 09:38:48

Updated: 02/04/2012 17:53:30

Journey


DataManagedObject


DayType

VersionedChild

Call

RequestStop :boolean [0..1]

TimingPointStatus :TimingPointStatusEnum [0..1]

StopUse :StopUseEnum

ChangeOfDestinationDisplay :boolean [0..1]

ChangeOfServiceRequirements :boolean [0..1]

Note :Multil ingualString [0..1]

UpdateDestinationDisplay :boolean [0..1]

«PK»

id :CallIdType

JourneyRef :JourneyIdType*

«AK»

VisitNumber :positiveInteger

«FK»


ScheduledStopPointRef :ScheduledStopPointRef

«contained»

Arrival :Arrival [0..1]

Departure :Departure [0..1]


DestinationDisplay :DestinationDisplayView [0..1]

vias :DestinationDisplayView [0..*]

notices :NoticeAssignmentView [0..*]

«FV»

ScheduledStopPointView :ScheduledStopPointView

OnwardTimingLinkView :OnwardTimingLinkView [0..1]

OnwardServiceLinkView :OnwardServiceLinkView [0..1]

PointInLinkSequence



«enumeration»


StopUseEnum

access

interchangeOnly

passthrough

nobarding

LinkSequence


StopAssignmentModel::PassengerStopAssignment

TimingPoint


DataManagedObject

StopAssignmentModel::StopAssignment

Site

StopPlaceModel::

StopPlace

Interchange


InterchangeRule

DerivedView

«TM_VIEW»

Serv icePatternViews::

ScheduledStopPointView

«enumeration»

TimingPatternSupport::

TimingPointStatusEnum

timingPoint

secondaryTimingPoint

notTimingPoint


Arriv al

Time :time

DayOffset :integer

ForAlighting :boolean

IsFlexible :boolean

CallPart :CallPart [0..*]

Departure

Time :time

DayOffset :integer

ForBoarding :boolean

IsFlexible :boolean

WaitTime :duration [0..*]

CallPart :CallPart [0..*]

CallPart

«FK»

JourneyPartRef :JourneyPartIdType* [0..1]

DutyPartRef :DutyPartIdType* [0..1]

TimeDemandTypeRef :TimeDemandTypeIdType* [0..1]

«contained»

QuayAssignment :StopAssignment [0..1]

journeyMeetings :JourneyMeetingView [0..*]

interchangeRules :InterchangeRule [0..*]

interchanges :Interchange* [0..*]

notices :NoticeAssignment [0..*]

DataManagedObject


Onw ardTimingLinkView

TimingLinkRef :TimingLinkRef* [0..1]

ToPointRef :TimingPointRef*

/RunTime :duration [0..1]

DataManagedObject


DataManagedObject


TimeDemandType

JourneyTimingsModel::HeadwayInterv al





JourneyFrequency



FrequencyRegulated :boolean [0..1]

HeadwayDisplay :HeadwayDisplayEnum [0..1]

Interchange

InterchangeModel::Serv iceJourneyInterchange

AccountableElement

DutyModel::DutyPart

fromnext

0..1

using

0..1

subdivided in 1

{ordered}

part of

*

combining 0..*

combined in 1

0..*

combines from 1

to *

end of

1

stops at 0..*

visited by

rule 0..*

applies to

0..1

arrives 0..1part of departs

0..1part of

duty part

0..1

part of

0..*

at

rules

0..*

apply to

can change

0..*

at

meeting

0..*

of

named by

*

advertised for

0..1

summary 0..1

view of 1

view via 0..*

uses

on

1..*

{ordered}

made up of 1made using *

for 1

0..1

equivalent to

0..1Call

0..*

passed at

1

assignment

0..*

to

1

/journey

to

0..*

/destination 0..1

worked on

*

for

1

used

by0..*

uses

0..*

0..*

to

start of 1from *

concerning*

concerned by

1..*

summary0..*

view of 1

to *end of 1

assignment

0..*

of

1

with

to 0..1

Figure 128 —Call – Physical Model

TC 278 WI 00278308:2013 (E)

162

7.2.14.2 Call – Model Element

A visit to a SCHEDULED STOP POINT (or other POINT IN JOURNEY PATTERN) as part of a SERVICE JOURNEY. The CALL is a view that brings together data relating to the individual visit.

Table 69 – Call – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> VersionedChild ::> CALL inherits from VERSIONED CHILD

«PK» id CallIdType 1:1 Identifier of CALL.

«AK» VisitNumber xsd:positiveInteger 1:1 Repeat count of visit to the same stop with the

journey. Default is 1. Will be higher for routes that

visit the same stop twice.

«PK» JourneyRef JourneyRef 1:1 Reference to JOURNEY containing CALL.


PatternRef

PointInJourneyPatternRef 0:1 POINT IN JOURNEY PATTERN corresponding to

CALL.

RequestStop xsd:boolean 0:1 Whether the stop is a Request Stop.

TimingPointStatus TimingPointStatusEnum 0:1 Timing Status of CALL.

StopUse StopUseEnum 1:1 Activity at stop.

«cntd» Arrival Arrival 0:1 Arrival part of CALL.

«cntd» Departure Departure 0:1 Departure part of CALL.

«cntd» Frequency JourneyFrequency 0:1 Frequency information for CALL.

«FV» ScheduledStop-

PointView

ScheduledStopPointView 0:1 Reference to the SCHEDULED STOP POINT visited

by CALL. May include derived data.

«cntd» Destination-

Display

DestinationDisplayView 0:1 DESTINATION DISPLAY associated with the CALL.

To be used from this point onwards.

ChangeOf-

Destination-

Display

xsd:boolean 0:1 Whether DESTINATION DISPLAY changes at this

point.

«cntd» vias DestinationDisplayView 0:* Set of DESTINATION DISPLAY to use to show as

onward VIA points associated with the CALL.

ChangeOfService-

Requirements

xsd:boolean 0:1 Whether DESTINATION DISPLAY changes at this

point.

Note MultilingualString 0:1 Arbitrary note associated with the CALL. For internal

use. Footnotes etc., should be specified with

NOTICEs.

«cntd» noticeAssignment

s

NoticeAssignmentView 0:* NOTICE ASSIGNMENTs, footnotes etc. associated

with the CALL. May include derived data.

«FV» OnwardTiming-

LinkView

OnwardTimingLinkView 0:1 Reference to the next TIMING LINK followed after

this CALL. May include derived data.

«FV» OnwardService-

LinkView

OnwardServiceLinkView 0:1 Reference to the next SERVICE LINK followed after

this CALL. May include derived data.

163

Call_VersionedChildStructure

A v isit to a SC HEDULED STO P PO INT as part of a

V EHIC LE JO URNEY. A C A LL is a v iew of a PO INT IN

JO URNEY PA TTERN that adds in deriv ed data.

Call

(restriction)

type Call_VersionedChildStructure

attributes


VersionedChildGroup

E lements describing the C A LL.

CallGroup

E lements from a STO P PO INT IN JO URNEY PA TTERN.

StopPointInJourneyPatternView Properti...


ServiceJourneyRef

0 1..





Point in JO URNEY PA TTERN upon which this call is based.

C an be used to obtain full association sets.


0 1..


E lements describing the timing of the C A LL.

CallTimingGroup

A rriv al at C A LL.

Arrival

0 1..

type ArrivalStructure

Departure from a C A LL.

Departure

0 1..

type DepartureStructure

F requency of serv ice at C A LL.

Frequency

0 1..


E lements describing the STO P PO INT IN JO URNEY

PA TTERN properties of the call.

StopPointInPatternPropertiesGroup


These are the normal planned v alues, not necessarily the

A C TUA L V EHIC LE EQ UIPMENT.


Text annotation that applies to this C A LL. This is for internal

use. C ustomer facing should be added to footnote.

Note

0 1..


Figure 129 — Call — XSD

TC 278 WI 00278308:2013 (E)

164

7.2.14.2.1.1 StopPointInJourneyPatternViewPropertiesGroup – Group

E lements from a STO P PO INT IN JO URNEY PA TTERN.

StopPointInJourneyPatternViewPr...

C ount of number of v isits to this stop - as per SIRI use.

Default is 1

VisitNumber


Restrict just to SC HEDULED STO P PO INTs.




S implified v iew of SC HEDULED STO P PO INT.


type ScheduledStopPoint_DerivedVie...

Information about onwards TIMING LINK.


type Onw ardTimingLink_DerivedView ...

reference to onwards SERV IC E LINK.

OnwardServiceLinkRef

type ServiceLinkRefStructure

Information about an onwards SERV IC E LINK.


type Onw ardServiceLink_DerivedVie...

NO TIC Es for C A LL.

notices


Nature of TIMING PO INT. Default is primary .

TimingPointType

type TimingPointTypeEnumeration

Figure 130 — StopPointInJourneyPatternViewPropertiesGroup — XSD

7.2.14.2.1.2 TimingPointStatus – Allowed values

The following table shows the allowed values for TimingPointStatus (TimingPointStatusEnum).

Table 70 – TimingPointStatus – Allowed values

Value Description

timingPoint Timing Point

secondaryTimingPoint Secondary Timing Point

notTimingPoint Not Timing Point

165

7.2.14.2.1.3 StopPointInPatternViewPropertiesGroup – Group

E lements describing common properties of v isit to stop.



PointInPatternPropertiesGroup

E lements for the destinations of a SERV IC E

DestinationViaGroup

Reference to a DESTINA TIO N DISPLA Y.

DestinationDisplayRef

type DestinationDisplayRefStructure

S implified v iew of a DESTINA TIO N DISPLA Y. Includes

deriv ed properties of the DESTINA TIO N DISPLA Y.


type DestinationDisplay_DerivedView ...

Destinations that the SERV IC E goes v ia.

vias

type vias_RelStructure

F lexible properties of a LINK.


type FlexiblePointProperties_Versione...

Whether DESTINA TIO N DISPLA Y should be updated at

this point. If DESTINA TIO N NA ME v alue is different from

Prev ious stop this is implicit.

ChangeOfDestinationDisplay

type xsd:boolean

Whether Serv ice Requirements C hange at this point.

ChangeOfServiceRequirements

type xsd:boolean

NO TIC Es for PO INT IN JO URNEY PA TTERN

noticeAssignments


Whether stop is a request stop for this journey . Default is false.

RequestStop

type xsd:boolean

Nature of use of stop, e.g. access, interchange only , or pass

through. Default is A ccess.

StopUse

type StopUseEnumeration

Figure 131 — StopPointInPatternPropertiesGroup — XSD

7.2.14.3 Arrival – Model Element

The ARRIVAL of a SERVICE JOURNEY to make a CALL at a SCHEDULED STOP POINT.

Table 71 – Arrival – Element

Classifi

cation

Name Type cardina

lity

Description

Time xsd:time 1:1 Latest Time of Arrival.

DayOffset xsd:integer 1:1 Day offset from SERVICE JOURNEY start day. 0 =

Same day.

ForAlighting xsd:boolean 1:1 Whether alighting is allowed for CALL.

IsFlexible xsd:boolean 1:1 Whether use of stop is flexible.

CallPart CallPart 0:* Common elements, e.g. NOTICEs, QUAY

ASSIGNMENT, INTERCHANGEs and JOURNEY

PART associated with Arrival part. of CALL

TC 278 WI 00278308:2013 (E)

166

Reorganisation of Passing times as arriv al.

ArrivalStructure

Latest A rriv al time.

Time

type xsd:time

Number of day s after the departure from prev ious stop.

DayOffset

type xsd:integer

Whether alighting is allowed at the stop Default is true.

ForAlighting

type xsd:boolean

Whether use of stop is flexible, i.e. requires phoning to

arrange. Must be a FLEXIBLE LINE. Default is false.

IsFlexible

type xsd:boolean

E lements describing an arriv al or Departure part of the C A LL.

CallPartGroup

Figure 132 — ArrivalStructure — XSD

7.2.14.4 Departure – Model Element

The DEPARTURE of a SERVICE JOURNEY from making a CALL at a SCHEDULED STOP POINT.

Table 72 – Departure – Element

Classifi

cation Name Type cardina

lity Description

Time xsd:time 1:1 Earliest time of departure.

DayOffset xsd:integer 1:1 Day offset from SERVICE JOURNEY start day. 0 =

Same day.

ForBoarding xsd:boolean 1:1 Whether boarding is allowed for CALL.

IsFlexible xsd:boolean 1:1 Whether use of stop is flexible.

WaitTime xsd:duration 0:* Time to wait at stop after arrival before departure.

CallPart CallPart 0:* Common elements, e.g. NOTICEs, QUAY

ASSIGNMENT, INTERCHANGEs and JOURNEY

PART associated with departure part of CALL.

167

Reorganisation of Passing times as arriv al.

DepartureStructure

Timetabled departure time - Earliest time to depart.

Time

type xsd:time

Number of day s after the arriv al day of the departure time

if not same calendar day .

DayOffset

type xsd:integer

Whether boarding is allowed at the stop. Default is true.

ForBoarding

type xsd:boolean

Whether use of stop is flexible, i.e. requires phoning to

arrange. Must be a FLEXIBLE LINE. Default is false.

IsFlexible

type xsd:boolean


WaitTime

type xsd:duration

E lements describing an arriv al or Departure part of the C A LL.

CallPartGroup

Figure 133 — DepartureStructure — XSD

7.2.14.5 OnwardServiceLinkView – Model Element

The OnwardServiceLinkView can be used to provide information about the onward SERVICE LINK from the CALL.

Table 73 – OnwardServiceLinkView – Element

Classifi

cation

Name Type cardina

lity

Description

ServiceLinkRef ServiceLinkRef 0:1 Reference to onwards SERVICE LINK.

ToPointRef ScheduledStopPointRef 1:1 Reference to next SCHEDULED STOP POINT in

pattern.

Distance DistanceType 0:1 DISTANCE for onward SERVICE LINK.

RunTime xsd:duration 0:1 RUN TIME for onward SERVICE LINK.

TC 278 WI 00278308:2013 (E)

168

OnwardServiceLink_DerivedView Structure

Information about an onwards SERV IC E LINK.


(extension)

type Onw ardServiceLink_DerivedVie...

attributes

Reference to a SERV IC E LINK.

ServiceLinkRef

type ServiceLinkRefStructure

Identifier of PO INT at which LINK ends.

ToPointRef


Distance for SERV IC E LINK.

Distance

type DistanceType

RUN TIME for SERV IC E LINK.

RunTime

type xsd:duration

Figure 134 — OnwardServiceLinkView — XSD

7.2.14.6 OnwardTimingLinkView – Model Element

The OnwardServiceLinkView can be used to provide information about the onward TIMING LINK from the CALL.

Table 74 – OnwardTimingLinkView – Element

Classifi

cation

Name Type cardina

lity

Description

TimingLinkRef TimingLinkRef 0:1 Reference to onwards TIMING LINK.

ToPointRef TimingPointRef 1:1 Reference to next SCHEDULED STOP POINT in

pattern.

RunTime xsd:duration 0:1 RUN TIME for onward TIMING LINK.

169

OnwardTimingLink_DerivedViewStructure

Information about onwards TIMING LINK.


(restriction)

type Onw ardTimingLink_DerivedView ...

attributes

Reference to a TIMING LINK.

TimingLinkRef

0 1..

type TimingLinkRefStructure

Identifier of PO INT at which LINK ends.

ToPointRef

0 1..


Run time for TIMING LINK - TIME BA ND giv en by context.

RunTime

0 1..

type xsd:duration

Figure 135 — OnwardTimingLinkView — XSD

7.2.14.7 CallPartGroup – Model Element

A CallPart describes common properties of an Arrival or Departure of a CALL.

Table 75 – CallPartGroup – Group

Classifi

cation

Name Type cardina

lity

Description

«FK» JourneyPartRef JourneyPartRef 0:1 JOURNEY PART to which CALL belongs.

«cntd» journeyMeetings JourneyMeetingView 0:* JOURNEY MEETINGs of this journey at this specific

CALL PART.

«cntd» interchanges Interchange 0:* INTERCHANGE of this journey at this specific CALL

PART.

«cntd» interchangeRules InterchangeRule 0:* INTERCHANGE RULEs of this journey at this

specific CALL PART.

«FK» TimeDemandType

Ref

TimeDemandTypeRef 0:1 TIME DEMAND TYPE of this journey at this specific

CALL.

«FK» DutyPartRef DutyPartRef 0:1 DUTY that applies from this CALL onwards.

«cntd» QuayAssignment StopAssignment 0:1 Assignment to a QUAY for this CALL PART.

«cntd» notice-

Assignments

NoticeAssignment 0:* NOTICEs that apply at this specific CALL PART.

TC 278 WI 00278308:2013 (E)

170

Elements describing an arriv al or Departure part of the C A LL.

CallPartGroup

Reference to a JO URNEY PA RT.

JourneyPartRef


JO URNEY MEETINGs for v isit.

journeyMeetings

type journeyMeetingView s_RelStructure

INTERC HA NGEs for v isit.

interchanges

type serviceJourneyInterchanges_Rel...

INTERC HA NGE RULEs for v isit.

interchangeRules

type interchangeRules_RelStructure


need not be stated.

TimeDemandTypeRef



TimebandRef


Reference to a DUTY PA RT.

DutyPartRef

type DutyPartRefStructure

E lements for a Q UA YA SSIGNMENT.

QuayAssignmentGroup

Reference to a PA SSENGER STO P A SSIGNMENT.

PassengerStopAssignmentRef

type PassengerStopAssignmentRefStr...

A ssignment to a specific Q UA Y w ithin the STO P PLA C E.

QuayAssignmentView

type PassengerStopAssignment_Deriv...

C hange to a PA SSENGER STO P A SSIGNMENT.


type DynamicStopAssignment_Versio...

NO TIC Es of a C A LL that apply only to the A rriv al or

departure.

notices


Figure 136 — CallPartGroup — XSD

7.2.14.8 DeadRunCall – Model Element

A visit to a POINT as part of a DEAD RUN. The DEAD RUN CALL is a view that brings together data relating to the visit to the individual point.

Table 76 – DeadRunCall – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> VersionedChild ::> DEAD RUN CALL inherits from VERSIONED

CHILD.

«PK» id DeadRunCallIdType 1:1 Identifier of DEAD RUN.

order xsd:integer 0:1 Order of DEAD RUN CALL.

Point choice 0:1 POINT visited by call.

«FK» a RoutePointRef RoutePointRef 0:1 Reference to the ROUTE STOP POINT visited by

DEAD RUN CALL.

«FK» b TimingPointRef TimingPointRef 0:1 Reference to the TIMING STOP POINT visited by

171

DEAD RUN CALL.

«FK» c TimingPointRef 0:1 Reference to the SCHEDULED STOP POINT visited

by CALL.

«FV» d Scheduled-

StopPointView

ScheduledStopPointView 0:1 Reference to the SCHEDULED STOP POINT visited

by CALL. May include derived data.

TimingPointStatus TimingPointStattsEnum 0:1 Nature of TIMING POINT.

JourneyRef DeadRunRef 1:1 Reference to JOURNEY containing CALL.


PatternRef

PointInJourneyPatternRef 0:1 Reference to POINT IN JOURNEY PATTERN for

CALL.

«cntd» Arrival DeadRunArrival 0:1 Arrival part of DEAD RUN CALL.

«cntd» Departure DeadRunDeparture 0:1 Departure part of DEAD RUN CALL.

Note MultilingualString 0:1 Note on CALL.

«cntd» Destination-

Display

DestinationDisplayView 0:1 DESTINATION DISPLAY associated with the CALL.

«cntd» vias DestinationDisplayView 0:* Set of via names to use to show as onward via

points associated with the CALL.

«FV» OnwardTiming-

LinkView

OnwardTimingLinkView 0:1 Onward TIMING LINK for next link from CALL stop.

TC 278 WI 00278308:2013 (E)

172

VersionedChildStructure

Data ty pe for DEA D RUN C A LL.

DeadRunCall_VersionedChildStruc...

(extension)

attributes


VersionedChildGroup

User defined Extensions to ENTITY in schema. (Wrapper tag used to av oid problems w ith handling of optional 'any ' by

some v alidators).

Extensions


attributes

E lements describing the DEA D RUN C A LL.

DeadRunCallGroup

Restrict just to SC HEDULED STO P PO INTs.

Reference to a PO INT.

PointRef


Reference to a RO UTE PO INT.

RoutePointRef

type RoutePointRefStructure

Reference to a TIMING PO INT. If giv en by context does not need to be stated.

TimingPointRef





S implified v iew of SC HEDULED STO P PO INT.


type ScheduledStopPoint_DerivedVie...

Point in JO URNEY PA TTERN upon which this DEA D RUN

C A LL is based. C an be used to obtain full association sets.



E lements describing the timing of the DEA D RUN C ALL.

DeadRunCallTimingGroup A rriv al at DEA D RUN C A LL.

Arrival

type DeadRunCallPartStructure

Departure from a DEA D RUN C A LL.

Departure




Text annotation that applies to this DEA D RUN C A LL. This is

for internal use. C ustomer facing should be added to footnote.

Note


Figure 137 — DeadRunCall — XSD

7.2.14.9 DeadRunArrival – Model Element

The ARRIVAL of a SERVICE JOURNEY DEAD RUN to make a CALL at a POINT IN JOURNEY PATTERN SCHEDULED STOP POINT.

Table 77 – DeadRunArrival – Element

Classifi


ality Description

Time time 1:1 Latest time of arrival.

DayOffset integer 1:1 Day offset from DEAD RUN start day. 0 = Same day.

CallPart DeadRunCallPartGroup 0:* Common properties of a DEAD RUN CALL arrival.

173

Timing E lements describing the DEA D RUN C A LL.

DeadRunCallTimingGroup

DeadRunCallPartStructure

A rriv al at DEA D RUN C A LL.

Arrival



Time

type xsd:time


DayOffset

type xsd:integer


WaitTime

type xsd:duration

Elements describing an arriv al or Departure part of the

DEA D RUN C A LL.

DeadRunCallPartGroup


JourneyPartRef


Reference to a TIME DEMA ND TYPE. If giv en by context need not be stated.

TimeDemandTypeRef



DutyPartRef


DeadRunCallPartStructure

Departure from a DEA D RUN C A LL.

Departure



Time

type xsd:time


DayOffset

type xsd:integer


WaitTime

type xsd:duration

Elements describing an arriv al or Departure part of the

DEA D RUN C A LL.



JourneyPartRef



need not be stated.

TimeDemandTypeRef



DutyPartRef


Figure 138 — DeadRunTimingGroup — XSD

7.2.14.10 DeadRunDeparture – Model Element

The DEPARTURE of a DEAD RUN from making a CALL at a POINT IN JOURNEY PATTERN.

Table 78 – DeadRunDeparture – Element

Classifi

cation

Name Type cardina

lity

Description

Time xsd:time 1:1 Earliest Time of Departure.

DayOffset xsd:integer 1:1 Day offset from DEAD RUN start day. 0 = Same

day.

WaitTime xsd:duration 0:* Time to wait at stop after arrival before departure.

CallPart DeadRunCallPartGroup 0:* Common properties of a DEAD RUN CALL

Departure.

7.2.14.11 DeadRunCallPart – Model Element

The dead run call part describes common properties of a DEAD RUN CALL Arrival and Departure.

TC 278 WI 00278308:2013 (E)

174

Table 79 – DeadRunCallPart – Element

Classifi

cation

Name Type cardina

lity

Description

«FK» JourneyPartRef JourneyPartRef 0:1 JOURNEY PART to which CALL belongs.

«FK» DutyPartRef DutyPartRef 0:1 DUTY that applies from this CALL onwards.

«FK» TimeDemandType

Ref

TimeDemandTypeRef 0:1 JOURNEY MEETINGs of this journey at this specific

DEAD RUN CALL.

E lements describing an arriv al or Departure part of the

DEA D RUN C A LL.



JourneyPartRef



need not be stated.

TimeDemandTypeRef



DutyPartRef


Figure 139 — DeadRunCallPart — XSD

7.2.14.12 XML Examples of Calls

Some examples of CALLs can be found in the examples for SERVICE JOURNEY and COUPLED JOURNEY.

7.2.14.12.1 Calls for a circular route — XML Example

The following code fragment shows a SERVICE JOURNEY with five CALLs (‘A-B-C-D-A’) forming a circular route. The DESTINATION DISPLAY changes as it moves around the circle. The second visit to stop Alpha has a visit number of 2.

For EXAMPLE

<ServiceJourney version="any" id="hde:sj_42c_AE_01">


<dayTypes>

<DayTypeRef version="any" ref="hde:DT_01-MF-NH"/>

</dayTypes>


<runTimes>

<VehicleJourneyRunTime id="hde:vjrt_sj_42c_AE_01">

<Name>Overall run time</Name>


</VehicleJourneyRunTime>

</runTimes>

<calls>

<Call id="hde:sj_42c_AE_01_Alpha1" order="1">

<VisitNumber>1</VisitNumber>

<Arrival>


</Arrival>

<Departure>

175

<Time>14:00:00.0Z</Time>

</Departure>


<ChangeOfDestinationDisplay>true</ChangeOfDestinationDisplay>

</Call>

<Call id="hde:sj_42c_AE_01_Bravo1" order="2">


<ScheduledStopPointRef version="any" ref="mybus:Bravo"/>

<Departure>

<Time>14:15:00.0Z</Time>

</Departure>


</Call>

<Call id="hde:sj_42c_AE_01_Charley1" order="3">


<ScheduledStopPointRef version="any" ref="mybus:Charley"/>

<Departure>

<Time>14:30:00.0Z</Time>

</Departure>

<DestinationDisplayRef version="any" ref="mybus:DST_Alpha"/>


</Call>

<Call id="hde:sj_42c_AE_01_Delta1" order="4">


<ScheduledStopPointRef version="any" ref="mybus:Delta"/>

<Departure>

<Time>14:45:00.0Z</Time>

</Departure>

<DestinationDisplayRef version="any" ref="mybus:DST_Alpha"/>

</Call>

<Call id="hde:sj_42c_AE_01_Alpha2" order="6">


<ScheduledStopPointRef version="any" ref="mybus:Alpha"/>

<Arrival>

<Time>15:15:00.0Z</Time>

</Arrival>

<Departure>

</Departure>



</Call>

</calls>

</ServiceJourney>

7.2.15 Dated Call

7.2.15.1 DATED CALL – Conceptual MODEL

A DATED CALL refines a CALL element and provides a view of a POINT IN JOURNEY PATTERN that assembles data related to the visit to a stop of a VEHICLE JOURNEY at a SCHEDULED STOP POINT.

PASSING TIMEs, grouped by arrival and departure.

Stop usage information (passthrough, no boarding, etc.).

DESTINATION DISPLAY and VIA information.

STOP ASSIGNMENTs to specific QUAYs i.e. platforms.

Visit number (order within the VEHICLE JOURNEY, including repeated visits).

Referenced entities and their derived properties, such as SCHEDULED STOP POINT, JOURNEY PARTs, SERVICE JOURNEY INTERCHANGES, SERVICE LINKs, etc.

NOTICEs relating to the CALL.

TC 278 WI 00278308:2013 (E)

176

class XSD NeTEx Dated Call Model

DataManagedObject


Name :Multil ingualString

ShortName :Multi lingualString [0..1]

SideText :Multi lingualString [0..1]

FrontText :Multil ingualString [0..1]

DriverDisplayText :Multil ingualString [0..1]

ShortCode :normalizedString [0..1]

«PK»

id :DestinationDisplayIdType

«AK»



«contained»

vias :Via [0..*]

variants :DeliveryDisplayVariant [0..*]

DatedJourneyModel::


Name: XSD NeTEx Dated Call Model

Author: NeTEx

Version: 1.0

Created: 20/01/2010 17:25:34

Updated: 12/10/2012 15:56:51

Journey


«PK»


«FK»





«contained»



Journey


DataManagedObject


VersionedChild

CallModel::Call

TimingPointStatus :TimingPointStatusEnum [0..1]

FlexiblePointPropereties :FlexiblePointPropereties [0..1]

ChangeOfDestinationDisplay :boolean [0..1]

ChangeOfServiceRequirements :boolean [0..1]

RequestStop :boolean [0..1]

StopUse :StopUseEnum

Note :Multi lingualString [0..1]

«PK»

id :CallIdType

JourneyRef :JourneyIdType*

«AK»

VisitNumber :positiveInteger

«FK»

ScheduledStopPointRef :ScheduledStopPointRef


ServiceJourneyRef :ScheduledStopPointRef [0..1]

«contained»

Arrival :Arrival [0..1]

Departure :Departure [0..1]


DestinationDisplayView :DestinationDisplayView [0..1]

vias :DestinationDisplayView [0..*]


«FV»

ScheduledStopPointView :ScheduledStopPointView [0..1]

OnwardTimingLinkView :OnwardTimingLinkView [0..1]

OnwardServiceLinkView :OnwardServiceLinkView [0..1]


«enumeration»


StopUseEnum

access

interchangeOnly

passthrough

nobarding

DatedCall

«PK»

id :CallIdType

«FK»

DriverRef :LogicalDriverIdType* [0..1]

LinkSequence


«PK»


«FK»







«contained»






linksInSequence :LinkInJourneyPattern [0..*]

StopAssignmentModel::PassengerStopAssignment

PassingTime








«PK»


TimingPoint


DataManagedObject

StopAssignmentModel::StopAssignment

Site

StopPlaceModel::StopPlace

VersionedChild


PointInLinkSequence


Serv iceJourney

LogicalResource

VehicleAssignmentModel::

LogicalDriver

work

0..*

«view»

crewed by 0..1

made using *

for 1

passed at 1

at

*

/journey

to

0..*

/destination 0..1

assignment

0..*

of 1

assignment 0..*

to 1

stops at

0..*visited by

work 0..*

crewed by0..1

visit 0..*

at 1

vias at

1

vias

0..*

at 0..*

show 0..1

named

by

*

advertised for

0..1

/used by

0..1 {Must be same as that of Vehicle

Journey}

altered to use

*

on

1..*

{ordered}

made

up of

1

for *

at

1

at

0..*

show

0..1

using

*

used by

1

using

*

used by

1

worked on *

for 1

Call

0..*

passed at

1

0..1

equivalent to

0..1

calls

*

{ordered}

journey

Figure 140 — Dated Call – Physical Model (UML)

7.2.15.2 DatedCall – Model Element

A CALL for a DATED VEHICLE JOURNEY.

177

Table 80 – DatedCall – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> Call ::> DATED CALL inherits from CALL.

«PK» id CallIdType 1:1 Identifier of DATED CALL.

«FK» DriverRef LogicalDriverRef 0:1 LOGICAL DRIVER undertaking CALL.

DatedCall_VersionedChildStructure

A v isit to a SC HEDULED STO P PO INT as part of a

V EHIC LE JO URNEY. A C A LL is a v iew of a PO INT IN

JO URNEY PA TTERN that adds in deriv ed data.

DatedCall

(restriction)

type DatedCall_VersionedChildStructure

attributes


VersionedChildGroup

E lements describing the C A LL.

CallGroup

E lements describing the DA TED C A LL.

DatedCallGroup

Reference to a DRIV ER.

DriverRef

0 1..

type DriverRefStructure

Date of departure

ArrivalDate

0 1..

type xsd:date

Date of departure

DepartureDate

0 1..

type xsd:date

Figure 141 — DatedCall — XSD

8 Vehicle Scheduling

8.1 Vehicle Scheduling – Model dependencies

The VEHICLE SERVICE Model describes the BLOCKs and VEHICLE SCHEDULEs for vehicle operation and is itself divided into a number of separate submodels covering different aspects of the scheduling. For ease of understanding, the submodels are presented one at a time, each describing only a small set of related concepts.

The submodels depend on a number of general NeTEx framework models and Part 1 and Part 2 described elsewhere.

The following figure shows the dependencies between the Vehicle Service physical submodels. The terminal packages contain the VEHICLE SCHEDULE FRAME and the DRIVER SCHEDULE FRAME. These two VERSION FRAMEs organise the other elements into a coherent set of elements suitable for exchange as a serialised file. The payload elements are contained in the following packages:

VEHICLE SCHEDULE FRAME

VEHICLE SERVICE: models the BLOCKs and VEHICLE SERVICEs for operation.

TC 278 WI 00278308:2013 (E)

178

TRAIN SERVICE: models the TRAIN BLOCKs for train operation.

DRIVER SCHEDULE FRAME

DUTY: models the driver DUTies for operations.

DUTY STRETCH: models the driver work assignments.

NOTE DUTY and DRIVER related issues are out of current NeTEx scope (it may be integrated in later additional Parts). Therefore, information provided on DUTY and DRIVER is only informative (more information Annex A).

pkg XSD NeTEx - Part 2 - Schedules and Versions Model Dependencies

XSD NeTEx - Part 2 - Journey & Journey Times

XSD NeTEx Base Framework


Name: XSD NeTEx - Part 2 - Schedules and Versions Model Dependencies

Author: nickk

Version: 1.0

Created: 14/01/2010 14:41:32

Updated: 11/01/2012 11:00:03

DutyModel

TypeOfDuty

Duty

DutyPart

DriverTrip

DriverTripTime

AccountableElement

VehicleServ iceModel

Block

BlockPart

CompoundBlock

CourseOfJourneys

ReliefOpportunity

VehicleService

VehicleServicePart

SchedulesAndVersionsFrameModel

VehicleScheduleFrame

DriverScheduleFrame

DutyStretchModel

AccountableChild

Break

BreakFacility

DrivingSpell

Fil lInTime

Pause

Spell

StandBy

Stretch

Task

TypeOfTask

ResponsibilityModel

DataManagedObject

VersionedChild

TypeOfValue

ValueSet

KeyList

KeyValue

VehicleTypeModel

Vehicle

VehicleType

VehicleModel

VehicleEquipmentProfile

PassengerCapacity

PurposeOfEquipmentProfile

TypeOfFuel

VehicleJourneyModel

Journey

VehicleJourney

DeadRun


TrainNumber

TypeOfService

TypeOfProductCategory

JourneyDesignator

CoupledJourneyModel

JourneyPart

CoupledJourney

JourneyPartCouple


TypeOfCoupling

TrainServ iceModel

TrainBlockPart

TrainBlock

Figure 142 — Vehicle Schedules – Model Dependencies

8.2 Vehicle Scheduling

8.2.1 Vehicle Schedule Frame

8.2.1.1 VEHICLE SCHEDULE FRAME – Conceptual MODEL

The elements of the VEHICLE SCHEDULE model can be grouped within a VEHICLE SCHEDULE FRAME which holds a coherent set of vehicle related elements for data exchange; including BLOCKs, COURSEs of JOURNEY, and VEHICLE SERVICE. See VERSION FRAME in the NeTEx Framework section for general concepts relating to version frames.

179

class NeTEx EF Vehicle Schedule Frame MODEL

Generic Validity MODEL::

VALIDITY CONDITION

Generic Version MODEL:

:VERSION FRAME

VEHICLE SCHEDULE FRAME


Vehicle Serv ice

MODEL::VEHICLE

SERVICE

Vehicle Serv ice

MODEL::VEHICLE

SERVICE PARTVehicle Serv ice

MODEL::BLOCK

PART

Vehicle Serv ice MODEL::COURSE

OF JOURNEYS

Name: NeTEx EF Vehicle Schedule Frame MODEL

Author: Kasia

Version: 1.0

Created: 04/06/2011 12:35:05

Updated: 05/01/2012 17:21:14

+restricted to1

+defined for

*

+referring to *

+reference for 1

+part

of *

+including 0..1

+included in *

+compossed of 0..1

+subdivided

in

1

+a part

of

*

+uses as

1

+use of*

+part

of*

+including 0..1

Figure 143 — Vehicle Schedule Frame – Conceptual MODEL (UML)

8.2.1.2 Vehicle Schedule Frame – Physical model

The following diagram shows the physical model for a VEHICLE SCHEDULE FRAME.

TC 278 WI 00278308:2013 (E)

180

class XSD NeTEx SV Vehicle Schedule Frame Intro

Name: XSD NeTEx SV Vehicle Schedule Frame Intro

Author: nickk

Version: 1.0

Created: 16/12/2010 12:19:28

Updated: 03/01/2012 18:47:55

TypeOfValue

DataSource

DataManagedObject

VersionFrame

DataManagedObject

ValidityCondition

DataManagedObject

Block

DataManagedObject

BlockPart

DataManagedObject

VehicleServ ice

DataManagedObject

VehicleServ icePart

DataManagedObject

CourseOfJourneys


DataManagedObject

CompoundBlock

included in*

compossed of 0..1

restricted to

1

defined for

*

source of

0..1

produced by

*

belongs to

0..*comprising

for 1

applies 0..*

uses as 1

use of*referring to *

reference for 1included in

*

including0..1

part of*

including 0..1

Figure 144 — Vehicle Schedule Frame Contents– Physical Model (UML)

class XSD NeTEx SV Vehicle Schedule Frame Model

VersionFrame

SchedulesAndVersionsFrameModel::


Mode :VehicleModeEnum

«PK»

id :VehicleScheduleIdType

«FK»

ServiceCalendarRef :ServiceCalendarIdType*

«contained»

blocks :Block [0..*]

vehicleServices :VehicleService [0..*]

courseOfJourneys :CourseOfJourney [0..*]

compoundBlocks :CompoundBlocks [0..*]

DataManagedObject

VehicleServ iceModel::CourseOfJourneys

Name: XSD NeTEx SV Vehicle Schedule Frame Model

Author: nickk

Version: 1.0

Created: 11/04/2012 13:22:23

Updated: 11/04/2012 13:28:03

DataManagedObject


DataManagedObject

LineModel::Line

VersionFrame

Serv iceCalendarFrameModel::Serv iceCalendarFrame

DataManagedObject

VehicleServ iceModel::VehicleServ ice

Journey


VehicleJourney

DataManagedObject


DataManagedObject


DataManagedObject

VehicleServ iceModel::VehicleServ icePart

DataManagedObject


DataManagedObject

ValidityModel::

ValidityCondition

for 0..*

applies

0..1

included in *

compossed of 0..1

served by

1

operated on *

subdivided in

1

a part of

*

0..*

comprises

including

0..1

in *

val id

0..*

day 0..1

worked on *

for 1

0..*

uses as 1

use of*referring to *

reference for 1

part of*

including 0..1

included in

*

including0..1

for1

appl ies 0..*

Figure 145 — Vehicle Schedule Frame – Physical Model (UML)

181

8.2.1.3 Vehicle Schedule Frame — XSD and attributes

8.2.1.3.1 VehicleScheduleFrame – Model Element

A VEHICLE SCHEDULE FRAME organizes the set of all BLOCKs defined for a specific DAY TYPE to which the same VALIDITY CONDITIONs have been assigned (usually defined for a specific GROUP OF LINEs).

Table 81 – VehicleScheduleFrame – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> VersionFrame ::> VEHICLE SCHEDULE FRAME inherits from

VERSION FRAME.

«PK» id VehicleScheduleIdType 1:1 Identifier of VEHICLE SCHEDULE FRAME.

«FK» Service-

CalendarRef

ServiceCalendarRef 1:1 Reference to SERVICE CALENDAR for VEHICLE

SCHEDULE FRAME.

Mode VehicleModeEnum 0:1 Mode of VEHICLE JOURNEYs in VEHICLE

SCHEDULE FRAME.

«cntd» blocks Block | TrainBlock |

CompoundBlock

0:* BLOCKs in VEHICLE SCHEDULE FRAME.

«cntd» courseOf-

Journeys

CourseOfJourney 0:* COURSEs OF JOURNEYs in VEHICLE

SCHEDULE FRAME.

«cntd» vehicleServices VehicleService 0:* VEHICLE SERVICEs in VEHICLE SCHEDULE

FRAME.

«cntd» relief-

Opportunities

ReliefOpportunity 0:* RELIEF OPPORTUNITies in VEHICLE SCHEDULE

FRAME.

VehicleSchedule_VersionFrameStructure

A coherent set of V ehicle Scheduling data to which the same

V A LIDITY C O NDITIO Ns hav e been assigned.


(restriction)

type VehicleSchedule_VersionFrameS...

attributes


O RGA NISA TIO N.


E lements of a V ERSIO N F RA ME.

VersionFrameGroup

E lements for a V EHIC LE SC HEDULE FRA ME.

VehicleScheduleVersionFrameGroup


these v alues if not specified on indiv idual elements.

VehicleScheduleDefaultsGroup

Reference to a SERV IC E C A LENDA R FRA ME.

ServiceCalendarFrameRef

0 1..

type ServiceCalendarFrameRefStructure

E lements for a V EHIC LE SC HEDULE FRA ME.

VehicleScheduleInFrameGroup

BLO C Ks in frame.

blocks

0 1..

type blocksInFrame_RelStructure

C O URSE O F JO URNEYs (Runs) in frame.

coursesOfJourneys

0 1..

type coursesOfJourneysInFrame_RelS...

V EHIC LE SERV IC ES in frame.

vehicleServices

0 1..

type vehicleServicesInFrame_RelStruc...

V EHIC LE SERV IC ES in frame.

reliefOpportunities

0 1..

type reliefOpportunitiesInFrame_RelStr...

Figure 146 — VehicleScheduleFrame — XSD

TC 278 WI 00278308:2013 (E)

182

8.2.2 Vehicle Service

8.2.2.1 VEHICLE SERVICE – Conceptual MODEL

The whole work of a logical vehicle for a DAY TYPE is described by a VEHICLE SERVICE, composed of one or several VEHICLE SERVICE PARTs.

Three levels of activities (BLOCK, VEHICLE SERVICE PART, and VEHICLE SERVICE) are possible, but will not always be described. The concept of VEHICLE SERVICE is not strictly necessary, once the number of required vehicles has been optimised and, in many situations, the distinction between BLOCK and VEHICLE SERVICE PART is not useful. Therefore quite often only a subpart of this model will be used (e.g. BLOCK).

8.2.2.1.1 Blocks

In vehicle planning for day types, the activities of a logical vehicle are grouped into BLOCKs, which describe continuous periods during which the vehicle constantly requires, in principle, a driver. A BLOCK starts from the time it leaves a PARKING POINT and ends at the time it returns to park at this or another PARKING POINT.

A BLOCK includes in particular all VEHICLE JOURNEYs (SERVICE JOURNEYs and DEAD RUNs) planned for this period. It may include as well SPECIAL SERVICEs. Between two journeys or services, a PAUSE may be planned, during which the driver is still responsible for the vehicle.

A necessary constraint is that all VEHICLE JOURNEYs included in a BLOCK shall refer to the same DAY TYPE. The DAY TYPE of a BLOCK may hence be derived from the DAY TYPE of the VEHICLE JOURNEYs it includes.

Some operators distinguish in addition sequences of BLOCKs starting and ending in a garage (i.e. the end points shall be GARAGE POINTs, but not necessarily a real garage). Such a VEHICLE SERVICE PART may be composed, for instance, of two BLOCKs, separated by a parking period spent, without any driver, at a PARKING POINT which is not a GARAGE POINT (e.g. parking periods at off-peak hours for buses, at a parking point in the city). This concept is useful when no maintenance facility is available at this PARKING POINT or if only a few parking places are available: the physical VEHICLE assigned to this VEHICLE SERVICE PART may not be maintained or exchanged during the parking period without a relatively complex action.

A BLOCK PART is a part of a BLOCK corresponding to the different JOURNEY PARTs of the VEHICLE JOURNEYs in a BLOCK.

One BLOCK for a VEHICLE may last for many hours or even the whole day. Drivers cannot work during such long time and arrangements shall be made to relieve drivers during the BLOCKs. RELIEF POINTs are predefined for this purpose. Every point of time within a BLOCK when the vehicle passes a RELIEF POINT is known as a RELIEF OPPORTUNITY. RELIEF OPPORTUNITies may or may not be taken for actually relieving the driver. Each RELIEF OPPORTUNITY will occur at a RELIEF POINT that is viewed as a TIMING POINT IN JOURNEY PATTERN.

8.2.2.1.2 Course of Journeys

Another classical method of designing the work of logical vehicles uses the concept of COURSE OF JOURNEYS. This method starts with the definition of VEHICLE JOURNEYs for all the LINEs of an ORGANISATIONAL UNIT (e.g. a depot, or even the whole network). All these VEHICLE JOURNEYs are then chained into suitable BLOCKs of vehicle operation. As a result of this method, one BLOCK is likely to be operated on several (or even many) different LINEs. A COURSE OF JOURNEYS is a part of a BLOCK continuously operated on one single LINE, without any interruption. Thus, a BLOCK will include several COURSEs OF JOURNEYS if it consists of VEHICLE JOURNEYs serving more than one LINE.

In some cases BLOCKs are subdivided into COURSEs OF JOURNEYS using additional criteria, e.g. change of the driver or other (arbitrarily chosen) events or situations. An (optional) attribute giving the start

183

time of a COURSE OF JOURNEYS in the BLOCK will then determine which journeys are included in that course.

Any COURSE OF JOURNEYs shall include only VEHICLE JOURNEYs belonging to the same BLOCK, hence defined for the same DAY TYPE. This entity is hence valid for one DAY TYPE only.

8.2.2.1.3 Vehicle Type

A VEHICLE TYPE characterises the common properties of a defined class of public transport vehicles. The most relevant properties for scheduling are the seating and standing capacities.

Depending on the time of day at which a SERVICE JOURNEY takes place, and on the ROUTE and JOURNEY PATTERN it covers, a default VEHICLE TYPE may be proposed for this journey. The most suitable VEHICLE TYPE will be chosen to meet the demand at various periods of the day, whenever possible. For instance, articulated or double-deck buses will be preferred to standard buses on the lines where the demand is the most important, especially at peak hours.

However, practical limitations, in particular of infrastructure, will also orient the choice of a VEHICLE TYPE, depending on its size: minibuses will be chosen for routes passing through narrow streets, while double-deck buses could not be used where the available height in tunnels is not sufficient. In rail systems, the VEHICLE TYPE should for instance be compatible with the length of stations and the height of platforms.

TC 278 WI 00278308:2013 (E)

184

class NeTEx TM VS Vehicle Serv ice MODEL

RELIEF OPPORTUNITY

+ Name [0..1]

+ Time


«PK»

+ id

BLOCK

+ Name [0..1]


+ PreparationDuration [0..1]

+ FinishingDuration [0..1]

+ StartTime [0..1]

+ EndTime [0..1]

+ EndTimeDayOffset [0..1]

«PK»

+ id

VEHICLE SERVICE

+ Name [0..1]


«PK»

+ idVEHICLE SERVICE

PART

+ Name [0..1]


«PK»

+ id


JOURNEY

Vehicle Journey

MODEL::VEHICLE

JOURNEY

Name: NeTEx TM VS Vehicle Service MODEL

Author: NeTEx

Version: 1.0

Created: 19/10/2010 13:00:34

Updated: 03/10/2012 16:00:32

RELIEF POINT

Vehicle & Crew Point

MODEL::PARKING

POINT

Vehicle & Crew

Point MODEL::

GARAGE POINT

Serv ice Calendar

MODEL::DAY TYPE

COURSE OF JOURNEYS

+ Name [0..1]


+ StartTimeInBlock

+ PreparationDuration [0..1]

+ FinishingDuration [0..1]

«PK»

+ id

BLOCK PART

+ Order [0..1]


«PK»

+ id

DATED BLOCK

NORMAL DATED

BLOCK

COMPOUND BLOCK

+ Name [0..1]

«PK»

+ id

+including 0..1

+in*

+assigned to

1

+using *

+assigned to

1

+using

*

+uses as

1

+use of

*

+subdivided

in1

+a part

of *

+worked on*

+for 1..*

+starting at

*

+start of

1

+ending at*

+end of1

+started at

*

+start of 1

+included in

*

+including

0..1

+ended at

*

+end of

1

+including1

+in

*

+using*

+assigned

to

1

+operated by

0..*

+requested for

0..*+made up of

0..1

+included in

*

+part

of*

+including

0..1

+part

of

*

+including

0..1

+using *

+used by0..1

+referring to

*

+reference for

1

+for 1

+worked on

*

Figure 147 — Vehicle Service – Conceptual MODEL (UML)

8.2.2.2 Vehicle Service – Physical Model

The following figure shows the physical model.

185

class XSD NeTEx VS Vehicle Serv ice Model

DataManagedObject

VehicleServ iceModel::ReliefOpportunity

Name :MultilingualString [0..1]

T ime :time

Description :Multi lingualString [0..1]

«PK»

id :Rel iefOpportunityIdType

«FK»

BlockRef :BlockRef*

DataManagedObject


Name :Multi lingualString [0..1]




StartTimeDayOffset :Integer [0..1]



EndTimeDayOffset :Integer [0..1]

«PK»

id :BlockIdType

«FK»





«contained»

validi tyConditions :Validi tyCondition [0..*]



rel iefOpportunities :Rel iefOpportunity [0..*]

allowances :TimeAllowance [0..*]


DataManagedObject

VehicleServ iceModel::

VehicleServ ice



«PK»

id :VehicleServiceIdType

DataManagedObject

VehicleServ iceModel::VehicleServ icePart



«PK»

id :VehicleServicePartIdType

«FK»

VehicleServiceRef :VehicleServiceRef*

StartPointRef :GaragePointRef* [0..1]

EndPointRef :GaragePointRef* [0..1]

DataManagedObject

DutyModel::Duty





«PK»

id :DutyIdType

«contained»

parts :DutyPart [0..*]

DatedBlock

VehicleAssignmentModel::

NormalDatedBlock

«PK»

id :NormalDatedBlockIdType

Name: XSD NeTEx VS Vehicle Service Model

Author: nickk

Version: 1.0

Created: 25/11/2009 15:32:00

Updated: 11/04/2012 12:14:49

Journey


VersionFrame


DataManagedObject


ReliefPoint


ParkingPoint

DataManagedObject


Order :integer [0..1]



«PK»

id :BlockPartIdType

«FK»

BlockRef :BlockRef*


CompoundBlockRef :CompoundBlockRef* [0..1]

JourneyPartCoupleRef :CompoundBlockRef* [0..1]

«contains»

journeyParts :JourneyPartRef* [0..*]

DataManagedObject

VehicleServ iceModel::CourseOfJourneys




StartTimeInBlock :time



«PK»

id :CourseOfJourneyIdType

«FK»

BlockRef :BlockRef*

LineRef :LineRef*

«contained»


DataManagedObject

LineModel::Line


GaragePoint

DataManagedObject



«PK»

id :CompoundBlockIdType

«FK»

VehicleTypeRef :VehicleServicePartRef* [0..1]

StartPoint :PointInJourneyPatternRef*

EndPoint :PointInJourneyPatternRef*

DataManagedObject


DayType

DataManagedObject

ValidityModel::

ValidityCondition

used in0..*

ends

at

0..1

included in

*

including

0..1

referring to *

reference for 1using *used by

0..1

including

1

in

*

subdivided in1

a part

of

*

part of

*

including

0..1

including 0..1

in *

0..*

comprises

served by

1operated on *

ending at

*

end of

1

part of*

including

0..1

comprising 0..1

valid for

*

used in0..*

starts at 0..1

using

*

assigned to 1

operated by

0..*

requested for

0..*

assigned to

1

using *

assigned to 1

using

*

made up of 0..1

included in *

valid 0..*

day 0..1

worked on*

for 1

for 1

applies 0..*

val id for*

comprising 0..1

valid for *

comprising 0..1

starting at

*

start of

1

Figure 148 — Vehicle Service – Physical Model (UML)

TC 278 WI 00278308:2013 (E)

186

8.2.2.3 Vehicle Service – Attributes and XSD

8.2.2.3.1 Block – Model Element

The work of a vehicle from the time it leaves a PARKING POINT after parking until its next return to park at a PARKING POINT. Any subsequent departure from a PARKING POINT after parking marks the start of a new BLOCK.

Table 82 – Block – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> BLOCK inherits from DATA MANAGED OBJECT.

«PK» id BlockIdType 1:1 Identifier of BLOCK.

Name MultilingualString 0:1 Name of BLOCK.

Description MultilingualString 0:1 Description of BLOCK.

PrivateCode PrivateCode 0:1 Private code of BLOCK.

Preparation-

Duration

xsd:duration 0:1 How long needed to prepare to run BLOCK.

StartTime xsd:time 0:1 Start time of BLOCK. In principle this can be derived

from the Start time of the first journey and the

preparation duration but may be stated explicitly as

well.

StartTime-

DayOffset

xsd:integer 0:1 Day offset of Start time from current OPERATING

DAY

FinishingDuration xsd:duration 0:1 How long needed to prepare to complete BLOCK.

EndTime xsd:time 0:1 End time of BLOCK. In principle this can be derived

from the Start time of the last journey and the

finishing duration but may be stated explicitly as

well.

EndTime-

DayOffset

xsd:integer 0:1 Day offset of end time from current OPERATING

DAY

«cntd» validityConditions ValidityCondition 0:* VALIDITY CONDITIONS controlling use of BLOCK.

«FK» dayTypes DayType 0:1 DAY TYPE associated with BLOCK.

«FK» VehicleService-

PartRef

VehicleServicePartRef 0:1 SERVICE PART associated with BLOCK.

«FK» VehicleTypeRef VehicleServicePartRef 0:1 VEHICLE TYPE associated with BLOCK.

«FK» StartPointRef PointRef 0:1 POINT from which BLOCK starts.

«FK» EndPointRef PointRef 0:1 POINT at which BLOCK ends.

«cntd» journeys JourneyRef 0:* Journeys in BLOCK.

«cntd» coursesOf-

Journeys

CourseOfJourneyRef 0:* Runs or Courses of Journey in BLOCK.

«cntd» blockParts BlockPart 0:* Parts of BLOCK.

«cntd» reliefOpportunitie

s

ReliefOpportunity 0:* RELIEF OPPORTUNITies in BLOCK.

187

Block_VersionStructure

The work of a v ehicle from the time it leav es a PA RKING

PO INT after parking until its next return to park at a

PA RKING PO INT. A ny subsequent departure from a

PA RKING PO INT after parking marks the start of a new

BLO C K. The period of a BLO C K has to be covered by DUTies.

Block

(restriction)

type Block_VersionStructure

attributes



E lements for BLO C K.

BlockGroup


BlockPropertiesGroup

Name of BLO C K.

Name

0 1..


Description of BLO C K.

Description

0 1..


A priv ate code that uniquely identifies the element. May be

used for inter-operating w ith other (legacy ) sy stems.

PrivateCode

0 1..



BlockTimingGroup


BlockReferencesGroup

C omponent E lements for BLO C K.

BlockComponentsGroup

Figure 149 — Block — XSD

TC 278 WI 00278308:2013 (E)

188

8.2.2.3.1.1 BlockTimingGroup – Model Element

Timing Elements for BLO C K.

BlockTimingGroup

Time to complete BLO C K.

PreparationDuration

type xsd:duration

Start time of block - In principle this can be deriv ed from the Start time of the first journey and the preparation duration

but may be stated expllictky as well.

StartTime

type xsd:time

Day offset of S tart time from current O PERA TING DA Y

StartTimeDayOffset

type xsd:integer

Time to complete BLO C K.

FinishingDuration

type xsd:duration

End time of block - In principle this can be deriv ed from the Start time of the last journey and the finishing duration but

may be stated expllictky as well.

EndTime

type xsd:time

Day offset of end time from current O PERA TING DA Y

EndTimeDayOffset

type xsd:integer

V A LIDITY C O NDITIO Ns pertaining to ENTITY.

validityConditions

type validityConditions_RelStructure

DA Y TYPEs for BLO C K.

dayTypes


Figure 150 — BlockTimingGroup — XSD

189

8.2.2.3.1.2 BlockReferencesGroup – Model Element

Reference elements for BLO C K.

BlockReferencesGroup

Reference to a V EHIC LE SERV IC E PA RT.

VehicleServicePartRef

type VehicleServicePartRefStructure


VehicleTypeRef


PointRefStructure

Point at which BLO C K starts Should be a PA RKING PO INT

but might be of unknown ty pe.

StartPointRef

type PointRefStructure attributes

Point at which BLO C K ends Point at w hich BLO C K starts

Should be a PA RKING PO INT but might be of unknown

ty pe.

EndPointRef


Figure 151 — BlockReferencesGroup — XSD

8.2.2.3.1.3 BlockComponentsGroup – Model Element

C omponent E lements for BLO C K.

BlockComponentsGroup

JO URNEYS making up BLO C K.

journeys

type journeyRefs_RelStructure

Runs in BLO C K PA RT.

courseOfJourneys

type coursesOfJourneys_RelStructure

BLO C K PA RTS in BLO C K.

blockParts

type blockParts_RelStructure

RELIEF O PPO RTUNITIES of a BLO C K-

reliefOpportunities

type reliefOpportunities_RelStructure

Figure 152 — BlockComponentsGroup — XSD

8.2.2.3.2 BlockPart – Model Element

A part of position of a vehicle BLOCK.

Table 83 – BlockPart – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> BLOCK PART inherits from DATA MANAGED

TC 278 WI 00278308:2013 (E)

190

OBJECT

order xsd:integer 0:1 Order of BLOCK PART within BLOCK.

«PK» id BlockPartIdType 1:1 Identifier of BLOCK PART.

Name MultilingualString 0:1 Name of BLOCK PART.

Description MultilingualString 0:1 Description of BLOCK PART.

«FK» BlockRef BlockRef 1:1 Reference to parent BLOCK of which this is part.

«FK» VehicleTypeRef VehicleTypeRef 0:1 VEHICLE TYPE to be used for BLOCK PART.

«FK» Compound-

BlockRef

CompoundBlockRef 0:1 COMPOUND BLOCK corresponding to BLOCK

PART - for TRAINs.

Journey parts Choice JOURNEY PARTs in BLOCK.

«FK» a JourneyPart-

CoupleRef

JourneyPartCoupleRef 0:1 Reference to a JOURNEY PART COUPLE

identifying a set of JOURNEY PARTs.

«cntd» b journeyParts JourneyPartRef 0:* References to JOURNEY PARTs in BLOCK.

BlockPart_VersionStructure

A part of a BLO C K.

BlockPart

(restriction)

type BlockPart_VersionStructure

attributes


O RGA NISA TIO N.


E lements for BLO C K PA RT.

BlockPartGroup

Name of BLO C K PA RT.

Name

0 1..


Description of BLO C K PA RT.

Description

0 1..



BlockRef

0 1..



TrainBlockRef



VehicleTypeRef

0 1..


0 1..

Reference to a JO URNEY PA RT C O UPLE.

JourneyPartCoupleRef


JO URNEY PA RTs in BLO C K PA RT.

journeyParts

type journeyPartRefs_RelStructure

Figure 153 — BlockPart — XSD

191

8.2.2.3.3 CompoundBlock – Model Element

The work of a vehicle during the time it is coupled to another vehicle.

Table 84 – CompoundBlock – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> COMPOUND BLOCK inherits from DATA

MANAGED OBJECT.

«PK» id CompoundBlockIdType 1:1 Identifier of COMPOUND BLOCK.

Name MultilingualString 0:1 Name of COMPOUND BLOCK.

Description MultilingualString 0:1 Description of COMPOUND BLOCK.

«FK» VehicleTypeRef VehicleServicePartRef 0:1 VEHICLE TYPE associated with COMPOUND

BLOCK.

«FK» StartPointRef PointInJourneyPatternRef 1:1 Start POINT IN JOURNEY PATTERN of

COMPOUND BLOCK.

«FK» EndPointRef PointInJourneyPatternRef 1:1 End POINT IN JOURNEY PATTERN of

COMPOUND BLOCK.

parts BlockPart 0:* BLOCK PARTs in COMPOUND BLOCK.

CompoundBlockStructure

A composite BLO C K formed of sev eral BLO C Ks coupled

together during a certain period. A ny coupling or separation

action marks the start of a new C O MPO UND BLO C K.

CompoundBlock

(restriction)

type CompoundBlockStructure

attributes


O RGA NISA TIO N.


E lements for C O MPO UND BLO C K

CompoundBlockGroup

Name of C O MPO UND BLOC K.

Name

0 1..


Description of C O MPO UND BLO C K.

Description

0 1..



VehicleTypeRef

0 1..


TimingPointInJourneyPatternRefStructure

Staring timing point of C O MPO UND BLO C K.

StartPointRef

0 1..

type TimingPointInJourneyPatternRefSt... attributes

Ending timing point of C O MPO UND BLO C K.

EndPointRef

0 1..

type TimingPointInJourneyPatternRefSt...

BLO C K PA RTs which make up C O MPO UND BLO C K.

parts

0 1..

type blockParts_RelStructure

Figure 154 — CompoundBlock — XSD

TC 278 WI 00278308:2013 (E)

192

8.2.2.3.4 CourseOfJourneys – Model Element

A part of a BLOCK composed of consecutive VEHICLE JOURNEYs defined for the same DAY TYPE, all operated on the same LINE.

Table 85 – CourseOfJourney – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> COURSE OF JOURNEY inherits from DATA

MANAGED OBJECT.

«PK» id CourseOfJourneyIdType 1:1 Identifier of COURSE OF JOURNEY.

Name MultilingualString 0:1 Name of COURSE OF JOURNEYs.

Description MultilingualString 0:1 Description of COURSE OF JOURNEYs.

CourseOfJourney

sNumber

xsd:integer 0:1 Number for COURSE OF JOURNEYs.

Preparation-

Duration

xsd:duration 0:1 How long needed to prepare for COURSE OF

JOURNEY in BLOCK.

StartTimeInBlock xsd:time 1:1 Start time of COURSE OF JOURNEY in BLOCK.

StartTime-

DayOffset

xsd:integer 0:1 Day offset of start time from OPERATING DAY at

start of Journey.

FinishingDuration xsd:duration 0:1 How long COURSE OF JOURNEY in BLOCK.

«FK» BlockRef BlockRef 1:1 BLOCK with which COURSE OF JOURNEY is

ASSOCIATED.

«FK» LineRef LineRef 1:1 LINE ASSOCIATED with COURSE OF JOURNEY.

«contain

ed»

journeys JourneyRef 0:* VEHICLE JOURNEYs associated with COURSE OF

JOURNEY.

193

CourseOfJourneys_VersionStructure

A part of a BLO CK composed of consecutiv e V EHIC LE JO URNEYs defined for the same DA Y TYPE, all operated

on the same LINE.

CourseOfJourneys

(restriction)

type CourseOfJourneys_VersionStructure

attributes


O RGA NISA TIO N.


E lements for C O URSE O F JO URNEYs.

CourseOfJourneysGroup

Name of C O URSE O F JO URNEYs.

Name

0 1..


Description of C O URSE O F JO URNEYs.

Description

0 1..


Numeric identifier of C O URSE of JO URNEYS.

CourseOfJourneysNumber

0 1..


A priv ate code that uniquely identifies the element. May be used for inter-operating w ith other (legacy ) sy stems.

PrivateCode

0 1..


How long the run takes to prepare.

PreparationDuration

0 1..

type xsd:duration

Time at which run starts.

StartTimeInBlock

0 1..

type xsd:time

Day offset of S tart time from current O PERA TING DA Y

StartTimeDayOffset

0 1..

type xsd:integer

How long the run takes.

FinishingDuration

0 1..

type xsd:duration


BlockRef

0 1..



TrainBlockRef



LineRef

0 1..


JO URNEYS making up C O URSE O F JO URNEYs.

journeys

0 1..

type journeyRefs_RelStructure

Figure 155 — CourseOfJourneys — XSD

8.2.2.3.5 ReliefOpportunity – Model Element

A time in a BLOCK where a vehicle passes a RELIEF POINT. This opportunity may or may not be actually used for a relief.

Table 86 – ReliefOpportunity – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> RELIEF OPPORTUNITY inherits from DATA

MANAGED OBJECT.

«PK» id ReliefOpportunityIdType 1:1 Identifier of RELIEF OPPORTUNITY.

Name MultilingualString 0:1 NAME of RELIEF OPPORTUNITY.

TC 278 WI 00278308:2013 (E)

194

Description MultilingualString 0:1 DESCRIPTION of RELIEF OPPORTUNITY.

Time xsd:time 1:1 TIME at which RELIEF OPPORTUNITY takes place.

«FK» BlockRef BlockRef 1:1 BLOCK associated with RELIEF OPPORTUNITY.

Description MultilingualString 0:1 DESCRIPTION of RELIEF OPPORTUNITY.

ReliefOpportunity_VersionStructure

A time in a BLO C K w here a v ehicle passes a RELIEF

PO INT. This opportunity may or may not be actually used for a relief.

ReliefOpportunity

(restriction)

type ReliefOpportunity_VersionStructure

attributes



E lements for RELIEF O PPO RTUNITY.

ReliefOpportunityGroup

Name of RELIEF O PPO RTUNITY.

Name

0 1..


Description of RELIEF O PPO RTUNITY.

Description

0 1..


Time at which RELIEF O PPO RTUNITY occurs.

Time

type xsd:time


BlockRef

0 1..



TrainBlockRef


Figure 156 — ReliefOpportunity — XSD

8.2.2.3.6 VehicleService – Model Element

A work plan for a vehicle for a whole day, planned for a specific DAY TYPE. A VEHICLE SERVICE includes one or several VEHICLE SERVICE PARTs.

Table 87 – VehicleService – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> VEHICLE SERVICE inherits from DATA MANAGED

OBJECT.

id VehicleServiceIdType 1:1 Identifier of VEHICLE SERVICE.

Name MultilingualString 0:1 Name of VEHICLE SERVICE.

Description MultilingualString 0:1 Description of VEHICLE SERVICE.

«cntd» vehicleService-

Parts

VehicleServicePart 0:* Parts of VEHICLE SERVICE.

195

VehicleService_VersionStructure

A w ork plan for a v ehicle for a w hole day , planned for a

specific DA Y TYPE. A V EHIC LE SERV IC E includes one or

sev eral V EHIC LE SERV IC E PA RTs.

VehicleService

(restriction)

type VehicleService_VersionStructure

attributes

C ommon P roperties of an object managed by a responsible O RGA NISA TIO N.


Elements for V EHIC LE SERV IC E.

VehicleServiceGroup

Name of V EHIC LE SERV IC E.

Name

0 1..


Description of V EHIC LE SERV IC E.

Description

0 1..


Parts of a V EHIC LE SERV IC E.

vehicleServiceParts

0 1..

type vehicleServiceParts_RelStructure

Figure 157 — VehicleService — XSD

8.2.2.3.7 VehicleServicePart – Model Element

A part of a VEHICLE SERVICE composed of one or more BLOCKs and limited by periods spent at the GARAGE managing the vehicle in question.

Table 88 – VehicleServicePart – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> VEHICLE SERVICE PART inherits from DATA

MANAGED OBJECT.

«PK» id VehicleServicePartIdType 1:1 Identifier of VEHICLE SERVICE PART.

Name MultilingualString 0:1 Name of VEHICLE SERVICE PART.

Description MultilingualString 0:1 Description of VEHICLE SERVICE PART.

«FK» VehicleServiceRef VehicleServiceRef 1:1 VEHICLE SERVICE of which this a VEHICLE

SERVICE PART.

«FK» StartPointRef GaragePointRef 0:1 Start GARAGE POINT of VEHICLE SERVICE

PART.

«FK» EndPointRef GaragePointRef 0:1 End GARAGE POINT of VEHICLE SERVICE PART.

TC 278 WI 00278308:2013 (E)

196

VehicleServicePart_VersionStructure

A part of a V EHIC LE SERV IC E composed of one or more

BLO C Ks and limited by periods spent at the GA RA GE

managing the v ehicle in question.

VehicleServicePart

(restriction)

type VehicleServicePart_VersionStruc...

attributes


O RGA NISA TIO N.


E lements for V EHIC LE SERV IC E PA RT.

VehicleServicePartGroup

Name of V EHIC LE SERV IC E PA RT.

Name

0 1..


Description of V EHIC LE SERV IC E PA RT.

Description

0 1..


Reference to a V EHIC LE SERV IC E.

VehicleServiceRef

0 1..

type VehicleServiceRefStructure

GaragePointRefStructure

StartPointRef

0 1..

type GaragePointRefStructure attributes

EndPointRef

0 1..

type GaragePointRefStructure

Figure 158 — VehicleServicePart — XSD

8.2.3 Train Service

8.2.3.1 TRAIN SERVICE – Conceptual MODEL

The TRAIN SERVICE Model allows TRAINs and parts of trains to be related to JOURNEY PARTs.

class XSD NeTEx Train Block Intro

TrainBlock

TrainBlockPart

Name: XSD NeTEx Train Block Intro

Author: nickk

Version: 1.0

Created: 11/01/2012 09:41:02

Updated: 12/01/2012 13:23:06

DataManagedObject

CoupledJourney

DataManagedObject

JourneyPartCouple

DataManagedObject

JourneyPart

TypeOfValue


Journey

VehicleJourney

DataManagedObject

Block

VersionedChild

BlockPart


1

including as main part

0..1

uses as 1

use of *

including

0..1

in

*

subdivided in 1

{ordered}

part of *

part of 1..*

{ordered}

composed of

0..1

referring to *

reference for 1

in

*

including

0..1

including

0..1

included in

*

joining 0..*

including as joining part

0..1

viewed as 1

a view of 0..1

referring to *

reference for

1

including

0..1

included in *causing 1

caused by 1..*

197

Figure 159 — Train Service Model – Conceptual MODEL (UML)

8.2.3.2 Train Service – Physical Model

The following figure shows the Physical model for the TRAIN SERVICE Model.

class XSD NeTEx Train Block Model

TrainServ iceModel::TrainBlock

id :TrainBlockIdentifier

«contained»

coupledJourneys :CoupledJourneyRef* [0..*]

BlockPart

TrainServ iceModel::TrainBlockPart



TypeOfCoupling :normalizedString

«PK»

id :TrainBlockPartIdType

«FK»

BlockRef :TrainBlockRef* [0..1]

Name: XSD NeTEx Train Block Model

Author: nickk

Version: 1.0

Created: 11/01/2012 09:20:41

Updated: 11/04/2012 12:14:48

DataManagedObject


CoupledJourney

Description :Multi l ingualSrring

«PK»

id :CoupledJourneyIdType

«FK»


«contained»

journeys :VehicleJourney [0..*]

DataManagedObject

CoupledJourneyModel::JourneyPartCouple

order :positiveInteger


«PK»

id :JourneyPartCoupleIdType

«FK»




MainPartRef :JourneyPartRef*


«contained»

joinedParts :JourneyPartRef [0..*]

DataManagedObject



StartTime :time

EndTime :time

«PK»

id :JourneyPartIdType

«FK»

ParentJourneyRef :VehicleJourneyRef*

PurposeRef :PurposeOfJourneyPartitionRef* [0..1]

MainPartRef :JourneyPartCoupleRef* [0..1]

JoiningPartCoupleRef :JourneyPartCoupleRef* [0..1]

BlockPartRef :BlockPartRef* [0..1]


FromStopPointRef :ScheduledStopPointRef* [0..1]

ToStopPointRef :ScheduledStopPointRef* [0..1]

«contained»

facil i ties :ServiceFacili tySet [0..*]

TypeOfValue



«PK»

id :PurposeOfJourneyPartitionIdType

Journey


DataManagedObject









EndTimeDayOffset :Integer [0..1]

«PK»

id :BlockIdType

«FK»





«contained»

validityConditions :ValidityCondition [0..*]



rel iefOpportunities :ReliefOpportunity [0..*]

al lowances :TimeAllowance [0..*]


part of

1..*

{ordered}

composed of

0..1

subdivided in 1

{ordered}

part of *

including

0..1

in

*

viewed as

1

a view of 0..1

joining 0..*

including as joining part

0..1


1

including as main part 0..1

causing 1

caused by 1..*

including

0..1

included in

*

including

0..1

included in

*

including 0..1

included in

*

including

0..1

included in *

referring to*

reference for

1

Figure 160 — Train Service Model – Physical Model (UML)

8.2.3.3 TrainServiceModel – Attributes and XSD

8.2.3.3.1 TrainBlock – Model Element

A composite train formed of several BLOCKs coupled together during a certain period. Any coupling or separation action marks the start of a new TRAIN BLOCK.

Table 89 – TrainBlock – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> Block ::> TRAIN BLOCK inherits from BLOCK.

id TrainBlockIdentifier 1:1 Identifier of a TRAIN BLOCK.

«cntd» coupledJourneys CoupledJourneyRef 0:* COUPLED JOURNEYs associated with COURSE

OF JOURNEY.

TC 278 WI 00278308:2013 (E)

198

TrainBlock_VersionStructure

A composite train formed of sev eral BLO C Ks coupled together during a certain period. A ny coupling or separation

action marks the start of a new TRA IN BLO C K.

TrainBlock

(restriction)

type TrainBlock_VersionStructure

attributes




BlockGroup

E lements for TRA IN BLO C K.

TrainBlockGroup

JO URNEYS making up BLO C K.

coupledJourneys

0 1..

type coupledJourneys_RelStructure

Figure 161 — TrainBlock — XSD

8.2.3.3.2 TrainBlockPart – Model Element

The position of a vehicle BLOCK within a TRAIN BLOCK.

Table 90 – TrainBlockPart – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> BlockPart ::> TRAIN BLOCK PART inherits from BLOCK PART.

«PK» id TrainBlockPartIdType 1:1 Identifier of a TRAIN BLOCK PART.

StartTime xsd:time 0:1 Start time of TRAIN BLOCK PART.

StartTime-

DayOffset

xsd:integer 0:1 Day offset of start time from OPERATING DAY at

start of journey.

EndTime xsd:time 0:1 End time of TRAIN BLOCK PART.

EndTime-

DayOffset

xsd:integer 0:1 Day offset of end time from OPERATING DAY at

start of journey.

TypeOfCoupling xsd:normalizedString 01 TYPE OF COUPLING of TRAIN BLOCK PART.

199

TrainBlockPart_VersionStructure

The w ork of a v ehicle from the time it leav es a PA RKING

PO INT after parking until its next return to park at a

PA RKING PO INT. A ny subsequent departure from a

PA RKING PO INT after parking marks the start of a new

TRA IN BLO C K PA RT. The period of a TRA IN BLO C K

PA RT has to be cov ered by DUTies.

TrainBlockPart

(restriction)

type TrainBlockPart_VersionStructure

attributes


O RGA NISA TIO N.


E lements for BLO C K PA RT.

BlockPartGroup

E lements for TRA IN BLO C K PA RT.

TrainBlockPartGroup

Start time of BLO C K PA RT- In principle this can be deriv ed

from the Start time of the first journey and the preparation

duration but may be stated explicitly as w ell.

StartTime

0 1..

type xsd:time

Day offset of Start time from current O PERA TING DA Y

StartTimeDayOffset

0 1..

type xsd:integer

End time of BLO C K PA RT. In principle this can be deriv ed

from the Start time of the last journey and the finishing

duration but may be stated explicitly as w ell.

EndTime

0 1..

type xsd:time

Day offset of end time from current O PERA TING DA Y

EndTimeDayOffset

0 1..

type xsd:integer

Ty pe fo C oupling

TypeOfCoupling

0 1..


Figure 162 — TrainBlockPart — XSD

TC 278 WI 00278308:2013 (E)

200

201

Annex A (informative)

Monitoring & Control

A.1 Introduction

Although NeTEx is dedicated to scheduled information exchange, it is important to have a good understanding of how it is related to realtime information. The following chapters provides such an explanation. Therefore the information and model below are mainly out of NeTEx scope (but still Transmodel compliant).

Real-time information exchange has to be manage using SIRI (CEN/TS 15531-1/5). SIRI and NeTEx are both based on Transmodel and IFOPT and are fully compatible.

A.2 Monitoring & Control

A.2.1 Monitored Vehicle Journey

A.2.1.1 Monitored Vehicle Journey – Conceptual MODEL

The following Monitored Vehicle Journey model is purely informative and is not fully explained here: refer to Transmodel for further details (most of the following explanation is directly extracted from Transmodel).

A MONITORED VEHICLE JOURNEY describes a journey recognised as being in process, at the time of the VEHICLE MONITORING.

Whenever possible, a MONITORED VEHICLE JOURNEY will be related to a DATED VEHICLE JOURNEY. This means that the system states that the journey underway is a DATED VEHICLE JOURNEY present in the latest valid plan.

In normal situations, this DATED VEHICLE JOURNEY is the expected journey, i.e. the DATED VEHICLE JOURNEY planned at that time in the DATED BLOCK assigned as work plan to the monitored LOGICAL VEHICLE. However, there may be some inconsistency with the work plan. It is in particular the case when the service has an important delay and that the LOGICAL VEHICLE is supposed to run a further DATED VEHICLE JOURNEY than the monitored journey. In some rare cases, the system may even monitor a DATED VEHICLE JOURNEY belonging to another DATED BLOCK than assigned to that LOGICAL VEHICLE.

In other situations, the system is unable to identify any DATED VEHICLE JOURNEY, but recognises a particular JOURNEY PATTERN as being served by the MONITORED VEHICLE JOURNEY. In classical AVM systems, this may happen if the vehicle follows an unexpected JOURNEY PATTERN, possibly because a control action has been ordered verbally, but not yet entered by the controller. Some modern systems, coupled to a geographical system, allow to build a ROUTE and a JOURNEY PATTERN unknown so far, when a vehicle serves them..

As long as the MONITORED VEHICLE JOURNEY is not completed, there is some uncertainty as regards the monitoring data. For instance, the vehicle may be monitored as serving a particular JOURNEY PATTERN, but operates an unexpected short turn at an intermediate TURN STATION. The system should be in principle able to declare a further VEHICLE MONITORING, modifying the previous one by indication of the actually served JOURNEY PATTERN (which has its end at the TURN STATION).

It is of importance to distinguish the latest valid plan from the monitored situation on the network. The monitored situation may be sometimes not precise enough (failure, gap in the location process, etc.) or not detailed enough to be related to a work plan. The latest valid plan is not always up to date, for instance when a control action is ordered verbally before having been entered in the monitoring system by the

TC 278 WI 00278308:2013 (E)

202

controller. In some systems, the work plan is even not registered in the system (e.g. when the system is only oriented towards passenger information).

A.2.1.1.1 Monitored Passing Times

Theoretical passing times at stop points may be computed from the basic timing information (see section 6.4.7). In the design of the operational plan for a specific OPERATING DAY, such planned passing times may be amended by changes made on the schedule. This will produce “target passing times” for this day, supporting the monitoring of operations. In addition, forecasts may be made on “estimated passing times”, mainly for passenger information, and actually “observed passing times” may be recorded by a monitoring system. All these concepts are described by the generic entity PASSING TIME, which has several sub-types.

Modifications of the plan for a specific OPERATING DAY, in particular changes in journeys, are likely to generate the need to recalculate the passing times. These modified passing times are defined as DATED PASSING TIMEs. Several sub-types of DATED PASSING TIME reflect the different status and use of passing times at different moments in time.

A first calculation of DATED PASSING TIMEs may be carried out as soon as the DATED VEHICLE JOURNEYs for a particular OPERATING DAY are defined. Such passing times are called TARGET PASSING TIMEs. They are calculated for all points that are defined as TIMING POINTs IN JOURNEY PATTERN for the corresponding DATED VEHICLE JOURNEYs.

The TARGET PASSING TIMEs are normally generated for the first time a few days before the OPERATING DAY, and are from that moment on constantly updated, according to the modifications operated to the schedule. The TARGET PASSING TIME can be seen as the latest official plan for vehicle operation.

The drivers will certainly try to meet the TARGET PASSING TIMEs, but in practice the vehicle may deviate from this plan due to the traffic circumstances. Various systems (such as AVM) can monitor these deviations and provide an estimation of PASSING TIMEs at the next stop points, for passenger information or for service control. This estimation may be based on planned run times or on mean run times. Such ESTIMATED PASSING TIMEs will be displayed at stops or will be used for trip planning queries. They may be used as well by the AVM system, in order for instance to alert the controller on a forecasted delay for a relief.

An ESTIMATED PASSING TIME is computed for a particular MONITORED VEHICLE JOURNEY, at a specified POINT IN JOURNEY PATTERN. The ESTIMATED PASSING TIMEs are constantly changing with every new information about the progress of the vehicle on its route. It can be useful to store some ESTIMATED PASSING TIMEs for statistical reasons.

The entity OBSERVED PASSING TIME describes the actual PASSING TIMEs that have been recorded at a specific POINT. This information is used to compute further ESTIMATED PASSING TIMEs and, of course, for statistical purposes. OBSERVED PASSING TIMEs are resulting from the monitoring process and are therefore related to a MONITORED VEHICLE JOURNEY. This entity may also be used for manual collection (surveys) of passing times. Any collected passing time that cannot be related to a MONITORED VEHICLE JOURNEY should be described, on the contrary, only as a VEHICLE DETECTING at the measurement POINT.

203

class TM OM Monitoring MODEL contents

DETECTED OPERATION

Id :TM_Identi fier

type of operation :normalizedString

IMPEDED TIME

start time :time

end time :time

distance from l ink start point :TM_Length

distance covered :TM_Length

MONITORED OPERATION

Id :TM_Identi fier

type of operation :normalizedString

MONITORED SPECIAL SERVICE

Id :TM_Identi fier

MONITORED VEHICLE JOURNEY

VEHICLE DETECTING

Id :TM_Identifier

timestamp :dateTime

type :normalizedString

VEHICLE MONITORING

timestamp :dateTime

type :normalizedString

LOGICAL VEHICLE

Id :TM_Identifier

Name: TM OM Monitoring MODEL contents

Author: nickk

Version: 1.0

Created: 24/09/2009 18:19:49

Updated: 12/07/2012 15:39:05

LINK SEQUENCE

JOURNEY PATTERN

«PK»


DATED VEHICLE JOURNEY

«PK»


of *

detected by 0..1

during *

delayed by 1

of *

monitored by 0..1

on *

monitored by 0..1

monitored as using *

covered by 0..1

on *

monitored by 0..1

operated by 0..1

monitored as operating *

of *

detected by 0..1

of *

monitored by 1

used by

0..1

altered to use

*

Figure 163 — Monitored Vehicle Journey — Conceptual MODEL (UML)

A.2.1.2 Monitored Vehicle Journey – Physical Model

The following diagram shows the MONITORED VEHICLE JOURNEY physical model.

TC 278 WI 00278308:2013 (E)

204

class XSD NeTEx OM Monitored Journey Model

Name: XSD NeTEx OM Monitored Journey Model

Author: nickk

Version: 1.0

Created: 30/11/2009 15:43:57

Updated: 12/04/2012 10:28:08

Journey


DatedPassingTime







«PK»


VersionedChild

CallModel::Call

DatedPassingTime

MonitoredPassingTimesModel::

EstimatedPassingTime

ExpectedArrivalTime :time [0..1]

ExpectedDepartureTime :time [0..1]

ExpectedNonstopPassingTime :time [0..1]

ExpectedWaitingTime :duration [0..1]

ExpectedHeadway :HeadwayInterval [0..1]

«PK»

id :EstimatedPassingTimeIdType [0..1]

DatedPassingTime

MonitoredPassingTimesModel::

ObservedPassingTime

ActualArrivalTime :time [0..1]

ActualDepartureTime :time [0..1]

ActualNonstopPassingTme :time [0..1]

ActualWaitingTime :duration [0..1]

ActualHeadway :HeadwayInterval [0..1]

«PK»

id :Observed PassingTimeIdType [0..1]

Journey

MonitoredJourneyModel::MonitoredVehicleJourney

«PK»

id :MonitoredVehicleJourneyIdType

«FK»

DatedVehicleJourneyRef :DatedVehicleJourneyRef* [0..1]

«contained»

passingTimes :DatedPassingTime [0..*] {ordered}

calls :MonitoredCall [0..*] {ordered}

previousCalls :PreviousCall [0..1]

onwardCalls :OnwardCall [0..*] {ordered}

«view»

MonitoredJourneyModel::MonitoredCall

«contained»

TargetTimes :TargetPassingTime [0..1]

EstimatedTimes :EstimatedPassingTime [0..1]

ObservedTimes :ObservedPassingTime [0..1]

«view»

MonitoredJourneyModel::Prev iousCall

«contained»


ObservedTimes :ObservedPassingTime [0..1]

«view»

MonitoredJourneyModel::OnwardCall

«contained»


EstimatedTimes :EstimatedPassingTime [0..1]

DataManagedObject


OperatingDay

StopAssignmentModel::


TimingPoint

Serv icePatternModel::

ScheduledStopPoint



DataManagedObject


StopAssignment

StopPlaceSpace

StopPlaceModel::Quay

Site

StopPlaceModel::

StopPlace

PointInLinkSequence


DataManagedObject

LineModel::

DestinationDisplay

CallModel::

Arriv al

CallModel::

Departure

CallModel::CallPart

Interchange


InterchangeRule

DataManagedObject


TimeDemandType

Interchange

InterchangeModel::


AccountableElement

DutyModel::DutyPart

0..*

{ordered}

previous

for

*

at

1

part of

0..*

{ordered}

comprises1

operated by

0..1

monitored as operating

*

part of 0..1

comprises

passed at

1

at

*

0..1equivalent to

0..1

Call

0..*

passed at 1

assignment

0..*

of 1

visit

0..*

at

1

scheduled 0..*

to 0..1

operates 0..*

on

0..1

assignment 0..*

overrides 0..1

quay 0..*

part of

assignment 0..*

to 1

at 0..*

show 0..1

at 0..*

show

0..1

vias at

1

vias

0..*

arrives

0..1

part of

departs

0..1

part of

using0..1

rules

0..*

apply to

can change 0..*

at

to

*

end of

1

duty part 0..1

Figure 164 — Monitored Vehicle Journey – Physical Model (UML)

205

A.2.1.3 Monitored JourneyModel – Attributes and XSD

A.2.1.3.1 MonitoredVehicleJourney – Model Element

A journey that is monitored as being operated by a LOGICAL VEHICLE. According to the monitoring system capabilities, a MONITORED VEHICLE JOURNEY may be related to a DATED VEHICLE JOURNEY, or only to a JOURNEY PATTERN.

Table 91 – MonitoredVehicleJourney – Element

Classifi

cation

Name Type Cardin-

ality

Description

«PK» id MonitoredVehicleJourney-

IdType

1:1 Identifier of MONITORED VEHICLE JOURNEY.

«FK» DatedVehicle-

JourneyRef

DatedVehicleJourneyRef 0:1 DATED VEHICLE JOURNEY which this

MONITORED VEHICLE JOURNEY follows.

«cntd» passingTimes DatedPassingTime 0:* Passing times for MONITORED VEHICLE

JOURNEY.

«cntd» calls MonitoredCall 0:* MONITORED CALLs for MONITORED VEHICLE

JOURNEY.

«cntd» previousCalls PreviousCall 0:1 PREVIOUS CALLs before current stop in

JOURNEY.

«cntd» onwardCalls OnwardCall 0:* ONWARD CALLs after current stop in journey.

A.2.1.3.2 MonitoredSpecialService – Model Element

A special service that is monitored as being operated by a LOGICAL VEHICLE.

Table 92 – MonitoredSpecialService – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> Journey ::> MONITORED SPECIAL SERVICE inherits from

JOURNEY.

«PK» id Monitored-

SpecialServiceIdType

1:1 Identifier of MONITORED SPECIAL SERVICE.

«FK» SpecialServiceRef SpecialServiceRef 0:1 Reference tyo a MONITORED SPECIAL SERVICE.

A.2.1.3.3 MonitoredCall – Model Element

A CALL in a MONITORED VEHICLE JOURNEY for which real-time data is available.

TC 278 WI 00278308:2013 (E)

206

Table 93 – MonitoredCall – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> Call ::> MONI|TORED CALL inherits from CALL.

«cntd» TargetTimes TargetPassingTime 0:1 Intended times at TIMING POINT IN JOURNEY

PATTERN,.

«cntd» EstimatedTimes EstimatedPassingTime 0:1 Estimated times at TIMING POINT IN JOURNEY

PATTERN.

«cntd» ObservedTimes ObservedPassingTime 0:1 Observed times at TIMING POINT IN JOURNEY

PATTERN.

previousCalls PreviousCall 0:* CALLs previous to this CALL.

onwardsCalls OnwardCall 0:* CALLs subsequent to this CALL.


Data ty pe for Monitored C A LL.

MonitoredCall_VersionedChildS...

(extension)

attributes

E lements for a V ERSIO NED

C HILD.

VersionedChildGroup

User defined Extensions to

ENTITY in schema. (Wrapper

tag used to av oid problems w ith

handling of optional 'any ' by

some v alidators).

Extensions


E lements describing the

C A LL.

CallGroup


Monitored C A LL.

MonitoredCallGroup

S implified TA RGET PA SSING TIME.

TargetPassingTimeView

type TargetPassingTime_View ...

derivedBy extension

S implified ESTIMA TED PA SSING TIME.

EstimatedPassingTimeView

type EstimatedPassingTime_View St...

S implified O BSERV ED PA SSING TIME.

ObservedPassingTimeView

type ObservedPassingTime_View St...

Prev ious stops in the SERV IC E

PA TTERN.

previousCalls

type previousCalls_RelStructure

O nwards stops in the SERV IC E

PA TTERN.

onwardCalls

type onw ardCalls_RelStructure

Figure 165 — MonitoredCall — XSD

A.2.1.3.4 PreviousCall – Model Element

An already completed CALL of a MONITORED VEHICLE JOURNEY that occurred earlier in the JOURNEY PATTERN before the current stop.

207

Table 94 – PreviousCall – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> Call ::> PREVIOUS CALL inherits from CALL.


PATTERN.

«cntd» ObservedTimes ObservedPassingTime 0:1 Observed times at TIMING POINT IN JOURNEY

PATTERN.


Data ty pe for Prev ious C A LL.

PreviousCall_VersionedChildStr...

(extension)

attributes


VersionedChildGroup


ENTITY in schema. (Wrapper tag used to av oid problems w ith


some v alidators).

Extensions



C A LL.

CallGroup


Prev ious C A LL.

PreviousCallGroup S implified TA RGET PA SSING TIME.



derivedBy extension




Figure 166 — PreviousCall — XSD

A.2.1.3.5 OnwardCall – Model Element

A further CALL of a MONITORED VEHICLE JOURNEY that will occurred later in the JOURNEY PATTERN after the current stop.

Table 95 – OnwardCall – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> Call ::> ONWARDS CALL inherits from CALL.


PATTERN.

«cntd» EstimatedTimes EstimatedPassingTime 0:1 Estimated times at TIMING POINT IN JOURNEY

PATTERN.

TC 278 WI 00278308:2013 (E)

208


Data ty pe for O nward C A LL.

OnwardCall_VersionedChildStr...

(extension)

attributes


VersionedChildGroup


ENTITY in schema. (Wrapper tag used to av oid problems w ith


some v alidators).

Extensions



C A LL.

CallGroup


O nw ard C A LL.

Onw ardCallGroup S implified TA RGET PA SSING TIME.



derivedBy extension




Figure 167 — OnwardCall — XSD

A.2.2 Dated Passing Times – Physical Model

Additional information about DATED PASSING TIMEs physical model are provided here: they are providing the link between NeTEx and SIRI concepts. The physical model is reminded below (see 7.2.13.6).

class XSD NeTEx OM Dated Passing Times Model



«PK»


VersionedChild




«PK»


«FK»









«PK»









«PK»


Journey


«PK»


«FK»





«contained»



Name: XSD NeTEx OM Dated Passing Times Model

Author: NeTEx

Version: 1.0

Created: 13/12/2010 10:25:30

Updated: 12/10/2012 16:01:10

Journey



«PK»


«FK»




«contained»

vias :Via [0..*]


LinkSequence


«PK»


«FK»







«contained»






l inksInSequence :LinkInJourneyPattern [0..*]

VersionedChild


PointInLinkSequence

passed at 1

at

*

for *

at 1

for 0..*

at

/used

by0..1



*

using *

used by 1

for

*

at 1

on

1..*

{ordered}

made up of1

made using

*

for

1

ar

0..*

passed

1

Figure 168 — Dated Passing Times – Physical Model (UML)

209

A.2.2.1 Passing times – Attributes and XSD

A.2.2.1.1 EstimatedPassingTime – Model Element

Time data, calculated from the latest available input, about when a public transport vehicle will pass a particular POINT IN JOURNEY PATTERN on a specified DATED VEHICLE JOURNEY. These are mainly used to inform passengers about expected times of arrival and/or departure, but may also be used for monitoring and re-planning.

Table 96 – EstimatedPassingTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DatedPassingTime ::> ESTIMATED PASSING TIME inherits from DATED

PASSING TIME.

«PK» id EstimatedPassing-

TimeIdType

0:1 Identifier of ESTIMATED PASSING TIME.

ExpectedDeparture-

Time

xsd:time 0:1 Expected departure time at POINT IN JOURNEY

PATTERN.

ExpectedArrivalTime xsd:time 0:1 Expected arrival time at POINT IN JOURNEY

PATTERN.

ExpectedWaitingTime xsd:duration 0:1 Expected waiting time at POINT IN JOURNEY

PATTERN.

ExpectedNonstop-

PassingTime

xsd:time 0:1 Expected nonstop passing time at POINT IN

JOURNEY PATTERN.

ExpectedHeadway HeadwayInterval 0:1 Expected headway time at POINT IN JOURNEY

PATTERN.

TC 278 WI 00278308:2013 (E)

210

EstimatedPassingTime_VersionedChildStructure

Estimated PA SSING TIME.

EstimatedPassingTime

(restriction)

type EstimatedPassingTime_Versioned...

attributes

E lements for a V ERSIONED C HILD.

VersionedChildGroup


PassingTimeGroup



Dated journey for which this is the PA SSING TIME. If


DatedJourneyRef

0 1..


Estimate elements.

EstimatedPassingTimeGroup

Expected Times at stop.

EstimatedTimesAtStopGroup

Expected A rriv al time.

ExpectedArrivalTime

0 1..

type xsd:time

Expected departure time.

ExpectedDepartureTime

0 1..

type xsd:time

Expected waiting interv al.

ExpectedWaitingTime

0 1..

type xsd:duration

Expected PA SSING TIME if doesn't stop at TIMING

PO INT.

ExpectedNonstopPassingTime

0 1..

type xsd:time

Expected F requency of serv ice.

ExpectedHeadway

0 1..


Figure 169 — EstimatedPassingTime — XSD

A.2.2.1.2 ObservedPassingTime – Model Element

The actual passing of a public transport vehicle at a pre-defined POINT during a MONITORED VEHICLE JOURNEY.

Table 97 – ObservedPassingTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DatedPassingTime ::> OBSERVED PASSING TIME inherits from DATED

PASSING TIME.

«PK» id Observed

PassingTimeIdType

0:1 Identifier of OBSERVED PASSING TIME.

ActualArrivalTime xsd:time 0:1 Actual arrival time at POINT IN JOURNEY

PATTERN.

ActualDepartureTim

e

xsd:time 0:1 Actual departure time at POINT IN JOURNEY

PATTERN.

ActualWaitingTime xsd:duration 0:1 Actual waiting time at POINT IN JOURNEY

PATTERN.

ActualNonstop-

PassingTme

xsd:time 0:1 Actual nonstop passing time at POINT IN JOURNEY

PATTERN.

ActualHeadway HeadwayInterval 0:1 Actual headway time at POINT IN JOURNEY

PATTERN.

211

ObservedPassingTime_VersionedChildStructure

O BSERV ED PA SSING TIME.

ObservedPassingTime

(restriction)

type ObservedPassingTime_Versione...

attributes


VersionedChildGroup


PassingTimeGroup



Dated journey for which this is the PA SSING TIME. If


DatedJourneyRef

0 1..


O BSERV ED PA SSING TIME elements.

ObservedPassingTimeGroup

A ctual Times at stop.

ObservedTimesAtStopGroup

A ctual A rriv al time.

ActualArrivalTime

0 1..

type xsd:time

A ctual departure time.

ActualDepartureTime

0 1..

type xsd:time

A ctual waiting interv al.

ActualWaitingTime

0 1..

type xsd:duration

A ctual PA SSING TIME if doesn't stop at TIMING PO INT.

ActualNonstopPassingTime

0 1..

type xsd:time

A ctual F requency of serv ice.

ActualHeadway

0 1..


Figure 170 — ObservedPassingTime — XSD

A.2.2.1.3 TargetPassingTime – Model Element

Time data about when a public transport vehicle should pass a particular POINT IN JOURNEY PATTERN on a particular DATED VEHICLE JOURNEY, in order to match the latest valid plan.

Table 98 – TargetPassingTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DatedPassingTime ::> TARGET PASSING TIME inherits from DATED

PASSING TIME.

«PK» id AimedPassingTime-

IdType

0:1 Identifier of AIMED PASSING TIME.

AimedArrivalTime xsd:time 0:1 Intended arrival time at TIMING POINT IN

JOURNEY PATTERN.

AimedDepartureTime xsd:time 0:1 Intended departure time at TIMING POINT IN

JOURNEY PATTERN.

AimedWaitingTime xsd:duration 0:1 Aimed waiting time at TIMING POINT IN JOURNEY

PATTERN.

AimedNonstop-

PassingTime

xsd:time 0:1 Intended passing time at TIMING POINT IN

JOURNEY PATTERN if vehicle does not stop.

AimedHeadway HeadwayInterval 0:1 Aimed headway interval at POINT IN JOURNEY

PATTERN.

TC 278 WI 00278308:2013 (E)

212

TargetPassingTime_VersionedChildStructure

TA RGET PA SSING TIME.

TargetPassingTime

(restriction)

type TargetPassingTime_VersionedChi...

attributes

Elements for a VERSIO NED C HILD.

VersionedChildGroup


PassingTimeGroup



TA RGET PA SSING TIME elements.

TargetPassingTimeGroup

A imed Times at stop.

TargetTimesAtStopGroup

A imed A rriv al time.

AimedArrivalTime

0 1..

type xsd:time

A imed departure time.

AimedDepartureTime

0 1..

type xsd:time

A imed w aiting interv al.

AimedWaitingTime

0 1..

type xsd:duration

A imed PA SSING TIME if doesn't stop at TIMING PO INT.

AimedNonstopPassingTime

0 1..

type xsd:time

A imed F requency of serv ice.

AimedHeadw ay

0 1..


Figure 171 — TargetPassingTime — XSD

213

Annex B (informative)

Driver Scheduling

B.1 Introduction

Although DRIVERs and DUTY are not in NeTEx's scope, it is important to have a good understanding of how they could possibly be connected together. The following chapters provides such an explanation. Therefore the information and model below are only informative.

B.2 Driver Scheduling

B.2.1 Driver Schedule Frame

B.2.1.1 DRIVER SCHEDULE FRAME – Conceptual MODEL

The elements of the Network Description model can be grouped with a DRIVER SCHEDULED FRAME which holds a coherent set of driver related elements for data exchange. See VERSION FRAME in the NeTEx Framework section for general concepts relating to version frames.

The DRIVER SCHEDULE FRAME holds DUTies and DUTY parts, describing a driver’s allocated work.

class NeTEx EF Driv er Schedule Frame MODEL

Generic Validity MODEL::

VALIDITY CONDITION

Generic Version MODEL:

:VERSION FRAME

DRIVER SCHEDULE FRAME

DUTY PART

DUTY

TIME ALLOWANCE

Name: NeTEx EF Driver Schedule Frame MODEL

Author: Kasia

Version: 1.0

Created: 06/06/2011 08:18:52

Updated: 05/01/2012 17:20:59

+complemented by 1

+attached to *

*

+complemented by

1

+attached to

*

+restricted to1

+defined for

*

Figure 172 — Driver Schedule Frame – Conceptual MODEL (UML)

TC 278 WI 00278308:2013 (E)

214

B.2.1.2 Driver Schedule Frame – Physical Model

The following diagram shows the Physical model for a DRIVER SCHEDULE FRAME.

class XSD NeTEx SV Driv er Schedule Frame Intro

Name: XSD NeTEx SV Driver Schedule Frame Intro

Author: nickk

Version: 1.0

Created: 12/12/2010 00:50:27

Updated: 11/04/2012 14:06:47

TypeOfValue

DataSource

DataManagedObject

VersionFrame

DataManagedObject

ValidityCondition

Driv erScheduleFrame

DataManagedObject

Duty

AccountableElement

DutyPart

VersionedChild

TimeAllowance

VersionedChild

Driv erTripTime

DataManagedObject

Driv erTrip

restricted to

1

defined for

*source of

0..1

produced by

*

belongs to

0..*

comprising

complemented by 1

attached to

*

part of

*

made up of

0..1

complemented by 1

attached to

*for *

covered in 1

Figure 173 — Driver Schedule Frame Contents – Physical Model (UML)

215

class XSD NeTEx SV Driver Schedule Model

VersionFrame

SchedulesAndVersionsFrameModel::

Driv erScheduleFrame

«PK»

id :DriverScheduleIdType

«contained»

duties :Duty [0..*]

dutyParts :DutyPart [0..*]

driverTrips :DriverTrip [0..*]

Name: XSD NeTEx SV Driver Schedule Model

Author: nickk

Version: 1.0

Created: 11/04/2012 13:29:50

Updated: 11/04/2012 14:07:23

DataManagedObject

DutyModel::Duty

AccountableElement

DutyModel::DutyPart

VersionedChild

VehicleServ iceAllowanceModel::

TimeAllowance

VersionedChild

DutyModel::Driv erTripTime

DataManagedObject

DutyModel::Driv erTrip

complemented by 1

attached to *

complemented by 1

attached to *

for *

covered in 1

Figure 174 — Driver Schedule Frame – Physical Model (UML)

B.2.1.3 Driver Schedule Frame — XSD and attributes

B.2.1.3.1 DriverScheduleFrame – Model Element

A DRIVER SCHEDULE FRAME organizes the set of all DUTies defined for a specific DAY TYPE to which the same VALIDITY CONDITIONs have been assigned.

Table 99 – DriverScheduleFrame – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> VersionFrame ::> DRIVER SCHEDULE FRAME inherits from

VERSION FRAME.

«PK» id DriverScheduleIdType 1:1 Identifier of DRIVER SCHEDULE FRAME.

«cntd» duties Duty 0:* DUTies in DRIVER SCHEDULE FRAME.

«cntd» dutyParts DutyPart 0:* DUTY PARTs in DRIVER SCHEDULE FRAME.

«cntd» driverTrips DriverTrip 0:* DRIVER TRIPs in DRIVER SCHEDULE FRAME.

TC 278 WI 00278308:2013 (E)

216

DriverSchedule_VersionFrameStructure

A coherent set of Driv er Scheduling data to which the same

V A LIDITY C O NDITIO Ns hav e been assigned.

DriverScheduleFrame

(restriction)

type DriverSchedule_VersionFrameStr...

attributes


O RGA NISA TIO N.


E lements of a V ERSIO N FRA ME.

VersionFrameGroup

E lements for a DRIV ER SC HEDULE FRA ME.

DriverScheduleVersionFrameGroup

Elements for a DUTY FRA ME.

DutyFrameGroup

DUTIes in frame.

duties

0 1..

type dutiesInFrame_RelStructure

DUTY PA RTs (Runs) in frame.

dutyParts

0 1..

type dutyPartsInFrame_RelStructure

DRIV ER TRIPs in frame.

driverTrips

0 1..

type driverTripsInFrame_RelStructure

Figure 175 — DriverScheduleFrame — XSD

B.2.2 Duty

B.2.2.1 DUTY – Conceptual MODEL


A DUTY describes a day’s work for a logical driver on one DAY TYPE.

An assigned DUTY may be divided into one or two (or sometimes even more) DUTY PARTs, which are each bounded by sign on and sign off. A DUTY consisting of two DUTY PARTs is commonly known as a “split” duty. A DUTY PART is a continuous period during which the driver is under the responsibility of the operator. In many companies, a DUTY PART is therefore a continuous paid period as well.

class TM TP Duty MODEL Contents

DRIVER TRIP TIME

duration :duration

transport mode :TM_AnyType

DRIVER TRIP

Id_driver trip :TM_Identifier

accounting time :duration

accounting factor :TM_AnyType

DUTY

Id :TM_Identifier

finishing duration :duration

preparation duration :duration

VERSION

TM TP Network MODEL::

TIMETABLE VERSION

name :normalizedString

POINT

TM ND Timing Pattern

MODEL::TIMING POINT

category

allowed for wait time

TM DS Duty MODEL::DUTY PART

Id :TM_Identifier



driver access duration :duration

driver return duration :duration

end time :time



start time :time

TM VS Vehicle Serv ice

MODEL::TIME

ALLOWANCE

duration :duration

Name: TM TP Duty MODEL Contents

Author: nickk

Version: 1.0

Created: 24/09/2009 17:32:56

Updated: 27/09/2009 16:23:02

started at *

start of 1

complemented by

1

attached to *ended at *

end of 1

start of

1

from

*to

*

end of

1

for *

covered in 1

complemented by

1

attached to

*

comprising 0..1

valid for *

217

Figure-176— DUTY — Conceptual MODEL (UML)

B.2.2.1.1 Duty – Physical Model

The following figure shows the DUTY Physical Model.

class XSD NeTEx Duty Model

TypeOfValue


TypeOfAllowance

PreOrPost :normalizedString

«PK»

Id :TypeOfAllowanceIdType

VersionedChild

DutyModel::Driv erTripTime


Duration :duration

TransportMode :TransportModeIdType [0..1]

«PK»

id :DriverTripTimeIdType [0..1]

«FK»

ParentRef :DriverTripRef*

DataManagedObject

DutyModel::Driv erTrip


AccountingFactor :string [0..1]

AccountingTime :duration


«PK»

id :DriverTripIdType

«FK»

StartPointRef :TimingPointRef*

EndPointRef :TimingPointRef*

DutyModel::DutyPart

DriverAccessDuration :duration [0..1]

DriverReturnDuration :duration [0..1]





DayOffset :integer [0..1]

«PK»

id :DutyPartIdType

«FK»

DutyRef :DutyRef*

StartPointRef :TimingPointRef*

EndPointRef :TimingPointRef*

Name: XSD NeTEx Duty Model

Author: nickk

Version: 1.0

Created: 27/11/2009 20:35:32

Updated: 11/12/2011 22:57:06

Point






«PK»


VersionedChild


TimeAllowance

Duration :duration

«FK»

TypeOfAllowance :TypeOfAllowanceIdType

«PK»

BlockRef :BlockIdType

DutyRef :DutyIdType

DataManagedObject

DutyModel::Duty





«PK»

id :DutyIdType

«contained»

parts :DutyPart [0..*]

VersionFrame


DataManagedObject

DutyModel::AccountableElement


AccountingFactor :string [0..1]

AccountingTime :duration

«PK»

id :AccountableElementIdType

comprising

0..1

valid for

*

start of

1

from

*

to

*

end of

1

ended at *

end of 1

started at *

start of 1

complemented by 1

attached to *

part of*

made up of

0..1

complemented by

1

attached to

*

for*

covered in 1

classified as

*

a classification for

1

Figure 177 — Duty – Physical Model (UML)

B.2.2.1.2 Duty – Attributes and XSD

B.2.2.1.2.1 Duty – Model Element

The work to be performed by a driver on a particular DAY TYPE.

TC 278 WI 00278308:2013 (E)

218

Table 100 – Duty – Element

Classifi

cation

Name Type cardina

lity

Description

::> ::> DataManagedObject ::> DUTY inherits from DATA MANAGED OBJECT.

«PK» id DutyIdType 1:1 Identifier of DUTY.

Name MultilingualString 0:1 Name of DUTY.

Description MultilingualString 0:1 Description of DUTY.

Preparation-

Duration

xsd:duration 0:1 Time needed to prepare for DUTY.

FinishingDuration xsd:duration 0:1 Time needed to complete DUTY at end.

«cntd» parts DutyPart 0:* List of DUTY Parts.

Duty_VersionStructure

The work to be performed by a driv er on a particular DA Y

TYPE.

Duty

(restriction)

type Duty_VersionStructure

attributes



E lements for a DUTY.

DutyGroup

Description of DUTY.

Description

0 1..


Time to complete DUTY.

FinishingDuration

0 1..

type xsd:duration

Time to complete DUTY.

PreparationDuration

0 1..

type xsd:duration

Reference to a TIMETA BLE FRA ME.

TimetableFrameRef

0 1..

type TimetableFrameRefStructure

Parts of a DUTY.

dutyParts

0 1..

type dutyParts_RelStructure

Figure 178 — Duty — XSD

219

B.2.2.1.2.2 AccountableElement – Model Element

A period of a driver's DUTY during which he or she is continuously working without a BREAK. PAUSEs during which he or she remains responsible for the vehicle may be included.

Table 101 – AccountableElement – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> ACCOUNTABLE ELEMENT inherits from DATA

MANAGED OBJECT.

«PK» id AccountableElement-

IdType

1:1 Identifier of ACCOUNTABLE ELEMENT.

Description MultilingualString 0:1 Description of ACCOUNTING ELEMENT.

AccountingFactor xsd:normalizedString 0:1 Accounting code to use on ACCOUNTABLE

ELEMENT.

AccountingTime xsd:duration 1:1 Accountable time to use on ACCOUNTABLE

ELEMENT.

AccountableElementStructure

A period of a driv er's DUTY during which (s)he is

continuously working w ithout a BREA K. PA USEs during which (the)he remains responsible for the v ehicle may be

included.

AccountableElement

(restriction)

type AccountableElementStructure

attributes



E lements for an A C C O UNTA BLE ELEMENT

AccountableElementGroup

Description of A C C O UNTA BLE ELEMENT.

Description

0 1..


How long a time shoudl be used for the the

A C C O UNTA BLE ELEMENT.

AccountingTIme

0 1..

type xsd:duration

A ccounting Factor to use for the the A C C O UNTA BLE ELEMENT.

AccountingFactor

0 1..

type xsd:duration

Time to prepare A C C O UNTA BLE ELEMENT.

PreparationDuration

0 1..

type xsd:duration

Time to complete A C C O UNTA BLE ELEMENT.

FinishingDuration

0 1..

type xsd:duration

Figure 179 — AccountableElement — XSD

B.2.2.1.2.3 DutyPart – Model Element

A continuous part of a driver DUTY during which (s)he is under the management of the company. A DUTY PART may include BREAKs.

TC 278 WI 00278308:2013 (E)

220

Table 102 – DutyPart – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> DUTY PART inherits from DATA MANAGED

OBJECT.

«PK» id DutyPartIdType 1:1 Identifier of DUTY PART.

«FK» DutyRef DutyRef 1:1 Reference to of DUTY of which this is part.

DriverAccessDuration xsd:duration 0:1 Time needed for driver access to DUTY PART.

DriverReturnDuration xsd:duration 0:1 Time needed for driver return from DUTY PART.

PreparationDuration xsd:duration 0:1 Time needed to prepare for DUTY PART.

FinishingDuration xsd:duration 0:1 Time needed to complete DUTY PART.

StartTime xsd:time 0:1 Start time of DUTY PART.

«FK» StartPointRef TimingPointRef 1:1 Start POINT of DUTY PART.

EndTime xsd:time 0:1 End time of DUTY PART.

«FK» EndPointRef TimingPointRef 1:1 End POINT of DUTY PART.

DayOffset xsd:integer 0:1 Day offset of end Time of DUTY PART from atart of

JOURNEY.

221

DutyPart_VersionStructure

A continuous part of a driv er DUTY during which (s)he is

under the management of the company . A DUTY PA RT

may include BREA Ks.

.

DutyPart

(restriction)

type DutyPart_VersionStructure

attributes


O RGA NISA TIO N.


E lements for an A C C O UNTA BLE ELEMENT

AccountableElementGroup

E lements for a DUTY PA RT.

DutyPartGroup

Time for DRIV ER to access DUTY PA RT.

DriverAccessDuration

0 1..

type xsd:duration

Time for DRIV ER to return from DUTY PA RT.

DriverReturnDuration

0 1..

type xsd:duration

Reference to a DUTY.

DutyRef

0 1..

type DutyRefStructure

Start time.

StartTime

0 1..

type xsd:time

End time.

EndTime

0 1..

type xsd:time

Day offset for end time.

DayOffset

0 1..

type xsd:integer

TIMING PO INT at w hich DUTY PA RT starts.

StartPointRef

0 1..


TIMING PO INT at w hich DUTY PA RT starts.

EndPointRef

0 1..


Figure 180 — DutyPart — XSD

B.2.2.1.2.4 DriverTrip – Model Element

A planned non-driving movement of a driver within a DUTY PART. This may be necessary to reach the first SPELL in a STRETCH, between two SPELLs or after the last SPELL in a STRETCH. It may be entirely on foot or may use a VEHICLE JOURNEY on a vehicle driven by another driver.

Table 103 – DriverTrip – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> DRIVER TRIP inherits from DATA MANAGED

OBJECT.

«PK» id DriverTripIdType 1:1 Identifier of DRIVER TRIP.

TC 278 WI 00278308:2013 (E)

222

Name MultilingualString 0:1 Name of DRIVER TRIP.

AccountingFactor xsd:string 0:1 Accounting code to use for DRIVER TRIP.

AccountingTime xsd:duration 1:1 Accountable time to use for DRIVER TRIP.

Description MultilingualString 0:1 Description of DRIVER TRIP.

«FK» StartPointRef TimingPointRef 1:1 Start POINT of DRIVER TRIP.

«FK» EndPointRef TimingPointRef 1:1 End POINT of DRIVER TRIP.

DriverTrip_VersionStructure

A planned non-driv ing mov ement of a driv er w ithin a DUTY PA RT. This may be necessary to reach the first SPELL in a

STRETC H, between two SPELLs or after the last SPELL in a STRETC H. It may be entirely on foot or may use a V EHIC LE JO URNEY on a v ehicle driv en by another driv er.

DriverTrip

(restriction)

type DriverTrip_VersionStructure

attributes


O RGA NISA TIO N.


E lements for a DRIV ER TRIP .

DriverTripGroup

Description of DRIV ER TRIP.

Description

0 1..


TIMING PO INT at which run starts.

StartPointRef

0 1..


TIMING PO INT at which run starts.

EndPointRef

0 1..


How long the run takes.

AccountingTIme

0 1..

type xsd:duration

How long the run takes to prepare.

AccountingFactor

0 1..

type xsd:duration

DRIV ER TRIP TIMEs for DRIV ER TRIP.

tripTimes

0 1..

type driverTripTimes_RelStructure

Figure 181 — DriverTrip — XSD

B.2.2.1.2.5 DriverTripTime – Model Element

The time allowed for a driver to cover a particular DRIVER TRIP during a specified TIME BAND.

Table 104 – DriverTripTime – Element

Classifi

cation

Name Type Cardin-

ality

Description

::> ::> DataManagedObject ::> DRIVER TRIP TIME inherits from DATA MANAGED

OBJECT.

223

«PK» id DriverTripTimeIdType 0:1 Identifier of DRIVER TRIP TIME.

«FK» DriverTripRef DriverTripRef 1:1 DRIVER TRIP to which this DRIVER TRIP TIME

belongs.

Description MultilingualString 0:1 Description of DRIVER TRIP TIME.

Duration xsd:duration 1:1 Duration of DRIVER TRIP TIME.

TransportMode TransportModeEnum 0:1 Transport mode of DRIVER TRIP TIME.

DriverTripTime_VersionStructure

A part of a BLO C K composed of consecutiv e V EHIC LE JO URNEYs defined for the same DA Y TYPE, all operated

on the same LINE.

DriverTripTime

(restriction)

type DriverTripTime_VersionStructure

attributes


O RGA NISA TIO N.


E lements for a DRIV ER TRIP TIME.

DriverTripTimeGroup

Description of DRIV ER TRIP TIME.

Description

0 1..


Reference to a DRIV ER TRIP .

DriverTripRef

0 1..

type DriverTripRefStructure

How long the DRIV ER TRIP takes.

Duration

0 1..

type xsd:duration

Mode of Transport.

TransportMode

0 1..

type VehicleModeEnumeration

Figure 182 — DriverTripTime — XSD

B.2.3 Duty Stretch

B.2.3.1 DUTY STRETCH – Conceptual MODEL


As a DUTY PART may last a relatively long time, they often include breaks planned for driver resting. Each DUTY PART is composed of one or several STRETCHes, which are continuous period of work not interrupted by any BREAK. A BREAK should therefore follow a STRETCH and is included in the corresponding DUTY PART.

Each STRETCH is composed of one or several SPELLs. A SPELL describes a period during which the same main activity is to be performed (e.g. driving a vehicle, stand-by period, etc.). SPELLs are subdivided into DRIVING SPELLs and NON DRIVING SPELLs.

TC 278 WI 00278308:2013 (E)

224

class TM DS Duty Stretch MODEL contents

Schedules and Versions Frame

MODEL::DUTY PART

Id :TM_Identifier



driver access duration :duration

driver return duration :duration

end time :time



start time :time

STRETCH

Id :TM_Identifier



end time :time

start time :time



BREAK

duration :duration



BREAK FACILITY


NON DRIVING SPELL

end time :time

start time :time

PAUSE

duration :duration



STAND-BY TASK


TYPE OF TASK


SPELL

Id :TM_Identifier





DRIVING SPELL

FILL IN TIME

duration :duration



Name: TM DS Duty Stretch MODEL contents

Author: nickk

Version: 1.0

Created: 27/09/2009 12:09:10

Updated: 27/09/2009 17:48:50

part of

*

including

0..1

used for 1

in *

followed by 1

after 0..1

used for 0..1

in *

completed by 1

added to 0..1

part of *

including 0..1

classifying 1

classified as *

Figure 183 — STRRTCH and SPELL— Conceptual MODEL (UML)

B.2.3.2 Duty Stretch – Physical Model

The following figure shows the DUTY STRETCH Physical Model.

225

class Duty Stretch Mo...

DutyStretchModel::Stretch

EndTime: time

StartTime: time

«PK»

Id: StretchIdType

«FK»

DutyPartRef: DutyPartIdType*

DutyStretchModel::Break

«PK»

Id: BreakIdType

ParentRef: StretchlIdType*

«FK»

BreakFacil ityRef: BreakFacil ityIdType*

TypeOfValue

DutyStretchModel::BreakFacility

«PK»

Id: BreakFacil ityIdType

DutyStretchModel::FillInTime:

:NonDriv ingSpell

EndTime: time

StartTime: time

DutyStretchModel::Pause

«PK»

Id: PauseIdType

ParentRef: BreakFacil ityIdType*

DutyStretchModel::

StandBy

«PK»

Id: StandByIdType

DutyStretchModel::Task

Name: normalizedString

«PK»

Id: TaskIdType

«FK»

TypeRef: TypeOfTaskIdType*

TypeOfValue

DutyStretchModel::

TypeOfTask

«PK»

Id: TypeOfTaskIdType

DutyStretchModel::Spell

«PK»

Id: SpellIdType

«FK»

StretchRef: StretchIdType*

DutyStretchModel::

Driv ingSpell

«PK»

Id: DrivingSpellIdType

DutyStretchModel::FillInTime

«PK»

Id: Fil lInTimeIdType

ParentRef: DrivingSpellldType*

Name: Duty Stretch Model

Author: nickk

Version: 1.0

Created: 04/01/2010 16:31:42

Updated: 16/12/2010 11:51:24

DutyModel::DutyPart

DriverAccessDuration: duration [0..1]

DriverReturnDuration: duration [0..1]

EndTime: time

StartTime: time

«PK»

Id: DutyPartIdType

«FK»

StartPointRef: TimingPointIdType*

EndPointRef: TimingPointIdType*

DataManagedObject

DutyModel::AccountableElement

AccountingTime: duration

AccountingFactor: TM_AnyType

FinishingDuration: duration [0..1]

PreparationDuration: duration [0..1]

«PK»

Id: AccountableElementIdType

VersionedChild

DutyStretchModel::AccountableChild

Duration: duration

AccountingFactor: TM_AnyType

AccountingTime: duration

completed by 1

added to 0..1

part of *

including 0..1

classifying 1

classified as *

followed by 1

after 0..1

used

for

0..1

in *

used

for

1

in *

part of

*

including

0..1

Figure 184 — Duty Stretch – Physical Model (UML)

TC 278 WI 00278308:2013 (E)

226

Bibliography

[1] CEN/TS 15531-1, Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework

[2] CEN/TS 15531-2, Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications infrastructure

[3] CEN/TS 15531-3, Public transport - Service interface for real-time information relating to public transport operations - Part 3: Functional service interfaces

[4] CEN/TS 15531-4, Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring

[5] CEN/TS 15531-5, Public transport - Service interface for real-time information relating to public transport operations - Part 5: Functional service interfaces - Situation Exchange

[6] EN 12896, Road transport and traffic telematics - Public transport - Reference data model

[7] EN 28701, Road transport and traffic telematics - Public transport - Identification of fixed objects in public transport

[8] ISO-8601:2000, Data elements and interchange formats – Information interchange – Representation of dates and times.

[9] ISO-639/IETF 1766, Tags for the Identification of Languages.

[10] ISO/IEC 19501-1:2002, Unified Modelling Language (UML) – Part 1: Specification

[11] National standards, in particular profile NEPTUNE, TransXChange, BISON and VDV 452, and other standards like NOPTIS

[12] ERA TAP-TSI: Commission Regulation (EU) No 454/2011 of 5 May 2011 on the technical specification for interoperability relating to the subsystem ‘telematics applications for passenger services’ of the trans-European rail system.

[13] UIC recommendations and leaflets.

[14] XML, Extensible Mark-up Language (XML) 1.0 W3C Recommendation 04 February 2004, available at http://www.w3.org/TR/2004/REC-xml-20040204.

Documents

Public transport — Network and Timetable Exchange (NeTEx) — … › wp-content › uploads › 2014 › 07 › ... · 2014-09-01 · Systems). However it is not restricted to