UC:TT:IntegratedTMS

IntegratedTMS (ITMS) Subschema: Timetable and Rostering   Related subschemas: IS TT RS  Reported by: Thales Germany

(version(s) 3.2)

For general information on use cases see UC:Use cases

Use case / Anwendungsfall

Integrated Traffic Management System / Integriertes Verkehrsmanagement

Description / Beschreibung

The UseCase Integrated Traffic Management System (ITMS) defines exchange of information between Timetable Construction System (TCS) and Traffic Management System (TMS).

Data Flows and Interfaces / Datenflüsse und Schnittstellen

These data are relevant for both systems. Plans are transmitted from TCS to TMS. In situations where TCS is the single owner of the plan data, changes to the operational plan are transmitted back from the TMS to TCS. This enables the TCS to also work on VSTP level.

Scenarios / Szenarien

Timetable data has to be exchanged in different situations. There are at least three major scenarios that have to be considered.

Periodic Planning / Fahrplanperiode

In the first scenario the TMS will receive data from a timetable planning system. This timetable shall include all timetable objects (train missions) for a defined period, usually some months but up to a year. Its timetable period usually lies in the future. It shall be the complete collection of planned schedules in this period.

In this scenario the highest amount of data must be exchanged. However, this transmission will be done only once in a long period.

Updates of Periodic Plan / Aktualisierung des Periodenfahrplans

It shall be possible to update the once defined Periodic Plan. These updates can be small, from a single train mission, up to big, when the whole Periodic Plan timetable must be updated.

The frequency of updates typically ranges from once a day for a single train mission to once a week for bigger timetabling activities, but there shall be no strict limit.

Traffic Management / Disposition

Traffic management usually looks at a planning horizon from now to a couple of days into the future. Changes of the timetable within this time frame will be called short term timetable planning (or scheduling). This planning usually works on single trains or a group of regular trains.

This planning will always be done with regard to the current operational situation. This means that the actual state of the railway network may not allow realizing train runs, which were possible if traffic would be running according to plan. So, due to delay, re-routing and cancellation of a train run or the unavailability of parts of the infrastructure it is not possible to change the train mission without checking it against the current operational situation.

The result of the checking must be sent from the TMS to the TPS in order to let the TPS know if the planning was successful or not. This result takes the form of an updated plan for the checked train runs.

Interference with other railML^® schemas / Interferenz mit anderen railML^®-Schemen

• Infrastructure
  • <operationalType> (signal, station, tracks, stopPosition)
• Interlocking
  • <routes>
  • <overlap>, <dangerPoint>
  • <flankProtection>
• RollingStock
• <formation>
  • <trainOrder>
  • <vehicleRef>
• <vehicle>
  • <engine>
  • <wagon>

Infrastructure (Interlocking) / Infrastruktur

Timetable data requires references to data from the Infrastructure schema. There is a reference to Operating Points in all cases. The sequence of Operating Points describes the path of a train through the railway network. The path between the OCPs is determined by a railway line ID. A railway line can consist of 1 or two railway line tracks. If it is a double track line, the route between two OCPs needs to be determined by line ID AND line track (0 = ascending vs 1 = descending according to mileage). Each OCP requires a mileage value. The referencing of infrastructure needs to be able to describe also more complicated scenarios, like reversing in a station, which could mean that the train first travels in ascending direction of mileage on a line and after reversing in descending direction on the same track.

Once the planning becomes more detailed also tracks and routes as references to the infrastructure can be specified.

Joining and splitting of train runs can also be part of the timetable data. Especially but not only in this case, for even more detailed planning, stopping places – so, positions on a track where a train is scheduled to stop – will be referenced, too. For more detailed processing there is additional information about the used lines and tracks of the network and the stop position on the track. And finally, the exact path of the train run in the infrastructure (or in the interlocking /ERTMS) can be specified in a train routing plan. The exchange of information about restrictions concerning the infrastructure shall not be part of this use case ITMS. On the other hand a restriction of the infrastructure can be the reason why a new planning activity must be performed. In this use case it shall be assumed that both the TPS and the TMS have sufficient information about the availability of infrastructure.

For tracks, a kinematic envelope must be given.

RollingStock

The traffic management system executes several checks (plan vs. real) internally that are based on certain vehicle and formation attributes. These checks are:

• OBU registration data vs. planning data
• Checks for train attributes and restrictions against static and dynamic infrastructure attributes (e.g. platform lengths, catenary)

Common train attributes are known at planning time and need to be provided by the exchanged data.

Required Attributes

For each formation, separated information for traction units (TU) and wagon train is required. Additionally, some information is required for the entire formation (traction units with wagon train). The information is required for each train part separately.

Wagon train:

• Length in m
• Number of wagons
• Number of axles
• Max speed (max. limit defined by lowest vmax of planned vehicles)
• Brutto load/weight in t
  • Optional: Netto and Tara weight separated
• Max axle load in t (Radsatzlast)
  • Value for the maximum load on a specific axle
• Braking Capability (Bremsgewicht) in % or, if load is given, in t
• Cant Deficiency Class (Neigetechnik)
  • Specification from publicly available UNISIG Specification SUBSET-026-06 https://www.era.europa.eu/content/set-specifications-3-etcs-b3-r2-gsm-r-b1_en
  • Additional information to be displayed:
    • Breaking Position (Bremsstellung)
      • Requires predefined set of values (W, G, …)
      • May be region-specific sets
    • Air Tightness (Druckschutz, Boolean)
    • Emergency Brake Override (Notbremsüberbrückung, Boolean)

Traction Unit:

• Design series (Baureihe)
  • Design series variant (Baureihenvariante)
  • Optional function of traction unit (leading, non-leading)

Timetable

The timetable shall contain this information:

• Overview
  • Starting OCP of train part
  • Identity of train (train number)
  • Weekly rules (Verkehrstageschlüssel) (incl. holiday rules (Feiertagsschlüssel) and additional/excluding dates)
  • Train type (Zuggattung)
    • Main and sub types (incl. empty train; “Leerzug”)
  • Train priority
  • Number and Position of traction unit (Position: Count ascending in driving direction)
  • Companies (for statistical purposes):
    • Orderer (Besteller)
    • Operator (Betreiber)
    • Operator/Owner of traction unit (Traktionär)
    • Company of train driver
• Chain of operating points describes the path through the railway network. It must be possible to identify the start and destination operating point. When the train mission/run starts or ends in another network and there is no further information about the details of the schedule outside the network managed by the TMS the first/last operating points inside the TMS managed network can be used as start and destination operating point. (border station, interchange station). In any case shall be marked where the train mission/run enters the own TMS managed network.
• Diversions/Alternative Routes can be given additionally to the described path (given by OCPs)
• Station Tracks are used to provide a more detailed description which is the desired location inside the Operating Point.
  • Station Track: References one OCP
  • Line Track: References two OCPs for start and end point
• Stopping Places can be specified to describe a detailed location, where the train shall stop. Timetable can optionally reference to a specific route.
• The Stop Description (Stop, No Stop, Stop on Demand, Stop only for Exit, Stop only for Entry) is used to specify the kind of the planned stop. Additionally, it is very important to know the kind of stop being commercial or operational.
• There are different times to deliver information, when a train passes, arrives or departs. Minimum stopping times are used to declare possible variations. There can be published and scheduled times.
• Calculated run time reserve times in seconds need to be explicitly attributed.
• A timetable shall have specified the dates when it is valid. This usually describes the first and the last day of operation and on which days between it will be operated. Within that period, the validity dates shall be given by three further attributes
• Weekday rule (to determine, on which of the days of the period the train is running) needs to be deducable from bitmask. It must refer to a specific timetable.
• Holiday rule (to determine, on which of the bank holidays of the period the train is running) needs to be deducable from bitmask.
• Additional/exclusion days (to announce variations from the weekday rules) need to be deducable from bitmask.
• Validities always apply to trains that are planned like this. The scope of this use case does not extend to conceptional trains or mere ideas of train runs in very early planning stages. Timetable data exchanged with a TMS is ready to be executed.
• A schedule (train run) shall be identified by a commercial train number, and the operation day. A single train can be identified by its train number and the start date.
  • Commercial train number
  • Operational train number
• A train mission/run may have a diverging operational train number from the commercial number
• There shall be information about the operator of the train
• The timetable shall include information about the Formations This provides further information about the available equipment (transport capabilities, restaurant, classes, children’s play areas, …)
• Train Service Line Code defines on which commercial line (and direction on the line as an optional additional parameter) it operates (e.g., “S1”, “RB14”)
• Type of operation (commercial/operational): Implicitly known by train type
• For traffic management it is especially important to keep track of connections to other trains for customers/passengers or operational reasons (Crossing/Split/Join). Connections shall be specified between a specific train run and another train run.
  • Types of Connections: Crew Exchange, Add empty coach to current train, ...
• Connections can be guaranteed. Guaranteed connections need a maximum waiting time. Train operator can cancel guaranteed connections. Connections need a minimum transfer time,
• It shall also be described if the train will be Joined or Split.
• Used Formation/Design series
  • See "Rollingstock" section

Characterizing Data / Charakterisierung der Daten

How often do the data change (update)?

• yearly for LTP, VLTP
• regular changes for STP
• daily for VSTP

How big are the data fragments to be exchanged (complexity)?

• LTP, VLTP: big
• STP, VSTP updates: little

Which views are represented by the data (focus)?

• VLTP: Very long term planning
• LTP: Long term planning (e.g. for yearly timetable distribution)
• STP: Short term planning (e.g. for track works)
• Passenger information

Which specific data do you expect to receive/send (elements)?

• <train>
  • <trainPartSequence>
  • <trainPartRef>
• <trainPart>
  • <formationTT>
  • <operatingPeriodRef>
  • <ocpsTT>
    • <time>
    • <sectionTT>
      • <runTimes>
    • <connections>
    • <stopDescription>
      • <stopTimes>
  • <organizationalUnitBinding>
• <category>
• <operating Period>
  • <operatingDay>
  • <specialService>
• <timetablePeriod>

Extension of the Use Case

The Use Case can be extended with these functionalities:

Restriction Handling: Manage the availability of the infrastructure.

Glossary

Abbreviations

Abbreviation	Term
ERTMS	European Railway Traffic Management System
OP	Operational Point
TMS	Traffic Management System
TPS	Traffic Planning System
UN	Code for hazardous materials
UT	Unusual Transport

Explanations

Term	Explanation
Connection	Connections are used to exchange passengers, personnel or goods between à train runs. Internal connections are connections within the same planning system. External connections are connections between train runs and external services, like ferries, busses or railway services planned somewhere else.
Formation	Specific constellation of vehicles. The formation information contains information for → design series and for → wagon trains; “Logical” vehicles. (e.g. BR 101)
Join	Different → trains/→ formationsare coupled to continue with a single path, There can also be complex Split/Join operations where waggons are exchanged / the formation changes (e.g. Night trains)
Line Track	→ Track, that references two OPs for start and end point
Operating Day	Operating day is an attribute described by a date. The start and end time of the operating day do not necessarily coincide with the start (00:00) and end (23:59) of the day in local time.
Operational Point	- Refer railML infrastructure -
Periodic Planning	Initial timetable planning for a defined period (usually annual planning)
Railway Line	Part of the infrastructure consecutive mileage, consisting a number of → OPs
Schedule	Actual operation of the specific → train mission on a specific operation day
Service Line	Contains → train runs which follow (at least in one major section) the same path at different times.
Short Term Planning	Changes to the timetable between start of the periodic plan (first train run) and about 24 hours before the first affected à train run starts
Split	A → train/→ formation can be separated into parts which continue with different pathes; There can also be complex Split/Join operations where waggons are exchanged / the formation changes (e.g. Night trains)
Station	OP with at least one switch where a train can begin, stop, end, cross or change direction
Station Track	→ Track, that references one → OP
Stop Description	Stop, No Stop, Stop on Demand, Only for Entry or Exit; Is used to specify the kind of the planned stop. It is very important to know the kind of stop being commercial or operational
Stopping Point	OP without any switches where trains can begin, stop or end.
Stopping Place	Place where the train regularly shall stop. Usually stopping places are distinguished into passenger and freight stopping places. Passenger stopping places need a platform. Departures and arrivals refer to stopping places. Planned arrival and departure times refer to a stopping place. Actual arrival and departure times are interpolated to the exact position of the referred stopping place to match the planned times for a proper deviation calculation.
Timetable	The sum of all à train missions for a period and/or a defined location
Timetable Period	Timespan, defined by begin and end time, for which a planned timetable shall be valid. There can be different periods but they shall not overlap.
Track	- Refer railML infrastructure – Element type platform
Train	Specific “physical” vehicles for → formation.
Train Mission (Itinerary)	Describes the booked path and times of a planned single journey with all relevant parameters for planning (e.g. train length, train category, …)
Train Number	Identifier for train mission/run. The train number should be unique for one operating day.
Train Run	Schedule
UN Number	United Nations number that identifies hazardous materials Lists of UN numbers ()
Updates of a Periodic Plan	Update of the initial periodic plan before (or about 24 hours before) the first train run of the planning period starts
Unusual Transport	Transport that exceeds the normally allowed profile
Vehicle	Can be either traction unit or wagon
Working Timetable/ Rostering/Umlaufplan	The data about all planned train and rolling stock movements (refer railML rostering)