From railML 2 Wiki
Jump to navigation Jump to search
🗒️ This page is mirrored from page UC:TT:RunTimeCalculationInput in The railML® 3 wiki.
Run Time Calculation Input Data
Subschema: Timetable and Rostering
Reported by: Jernbanedirektoratet/Bane NOR
Stift.png (version(s) )
For general information on use cases see UC:Use cases

Use case / Anwendungsfall

Run Time Calculation Input Data; Fahrzeitberechnung

Description / Beschreibung

This use cases aim is to exchange data with systems that are focused on train runtime calculation. This kind of calculation is carried out in varying levels of detail at all stages of timetable planning and execution. The use case is only looking at the necessary input data for the calculation. The results of a run time calculation are not part of this use case. Typical reading systems for data as described here are timetabling tools, run time calculators, simulation tools or driver advisory systems.

The typically necessary data for this UC can be separated into 3 general domains:

  • Infrastructure
  • Rollingstock and
  • Timetable

Based on this the use case is split into three sub-use cases each covering on of the above domains; Infrastructure is covered by RTCI-a, Rollingstock by RTCI-b and Timetable by RTCI-c. The data that is exchanged for this use case usually does not cover environmental factors, such as low adhesion, air pressure or head wind. This does of course not mean that such information can not be considered in the calculation of an importing system, it is however not part of the standardized data exchange.

The rollingstock information exchanged for this use case is focused on modern railway rollingstock (manufacturing date later than 1974). Information that is necessary to calculate run times of historical rollingstock is not considered here.

The result of the run time calculation is typically used for timetable design.

This use case does not cover exchange of precalculated, assumed or otherwise fixed run times. These may be included in a future use case RTCO that describes how communication of the results of the calculation. Energy calculation is not covered by this use case as it requires a set of information that far exceeds the one required here. The necessary information may be included in another future use case extending this one.

Data Flows and Interfaces / DatenflĂĽsse und Schnittstellen

As the aim of the use case is to provide the basis for the calculation of run times which is the basis for timetable design, typically the infrastructure and rollingstock data is not changing very often. Also, the amount of data exchanged here will not change a lot between data deliveries. It is considered the master data for run time calculation tools.

The timetable information, on the other hand, although the least detailed, included in this use case may be exchanged with a high frequency. Typically timetable data is exchanged on a macroscopic level, so that stop patterns of the trains can be described. It should however also be possible to provide more detailed information.

Dependent railML® domains / Abhängige railML-Domänen

This use case depends on information from infrastructure for the track geometry, rollingstock for information in the vehicles calculate the run time with and timetable to understand where to stop.

Information of either subdomain may be left out when importing data to a system that covers data of that domain already.

Characterizing Data / Charakterisierung der Daten

Relevant infrastructure data typically describes among other things the geometry of the tracks, the gradients and speed profiles. Information in signals may be relevant in rare cases but often is not included.

Rollingstock data usually includes the capabilities of the available vehicles, often in a generalized manner. This includes braking curves, acceleration capabilities, air resistance, a weight that is used in the calculation to just name a few. Also, information on supported train control systems may be included. Rollingstock information for this use case is exchanged focused on formations. Such formations are considered to be a sequence of vehicles, at least one vehicle. Typically, vehicles of such formations are not specific vehicles but rather vehicles of a certain type.

Timetable data is far less detailed compared to the beforementioned domains. What is necessary here is the itinerary of the train. This is usually provided as macroscopic stop pattern or on a mesoscopic level, where also the tracks can be described. The most detailed that is envisioned for this use case is a microscopic description of the timetable.

Sub-use cases / Teil - Usecases


Additional remarks / Zusätzliche Bemerkungen


References / Verweise