UC:TT:ExchangeOfFormationData

Use case

Use case / Anwendungsfall / :

Exchange of formation data; Austausch von Wagenreihungen/Behängungsdaten;

Description / Beschreibung /

The usecase describes the exchange of data between a software tool for short term formation planning to a timetable database, which contains data of the whole timetable periode. The software for short term planning allows to add or delete train parts of already existing trains and to define a (potentially different) formation for a train part on each of its operating days. The assigned formation must match the restrictions of the train path (maximum speed, length and weight, driving and braking characteristics, etc.), i.e. a change of the formation data does not affect the running times of the trains. Furthermore, a change of the formation data should not affect the operating days of the train (a decrease of operating days is allowed).

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

The usecase covers the exchange of the following data:

• the composition of <trainPart>s of <vehicle>s (using <formation>s)
• <operatingPeriod>s of <trainPart>s
• commercial and technical properties of <trainPart>s/<formation>s
• added and removed <trainPart>s within a <train>

The usecase does not cover the exchange of data concerning the <train>, in particular:

• changes of the train path or times (<ocpsTT>)
• added or removed <train>s

As a consequence, it is assumed that both source and target system of the exchanged data must refer to the same set of <train>s, i.e. the <train>s in both systems must have the same external identifier and identical (macroscopic) train paths. Since the usecase mainly modifies existing objects in the target system, it is necessary that the railML data can be assigned to the corresponding objects in the target system. This applies for the following railML object types:

• <train>
• <trainPart>
• <ocp>
• <vehicle>

All those object types must contain a key expression that is unique within the railML data set and which also exists in the target system. This key expression may be one single attribute or a combination of several attributes of the respective object type.

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

infrastructure, rolling stock

Characterizing Data / Charakterisierung der Daten /

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

weekly-yearly

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

• infrastructure: big
• timetable: small (operatingPeriod: tiny)
• rolling stock: big (formation: tiny)

Which views are represented by the data (focus)?

Mid and short term planning

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

Used elements:

Element	Mandatory	Remarks
<ocp>	x	used for referencing an existing ocp within the target system
<designator>		used for referencing an existing ocp within the target system
<formation>	x
<vehicleRef>	x
<vehicle>	x	used for referencing an existing vehicle within the target system
<operator>		used for referencing an existing vehicle within the target system
<manufacturer>		used for referencing an existing vehicle within the target system
<timetablePeriod>
<holiday>
<operatingPeriod>	x
<category>		used for referencing an existing category within the target system; used for the creation of new train parts that so far not existed in the target system
<trainPart>	x	used for referencing an existing train part within the target system and to identify removed or added trainParts
<formationTT>	x
<places>
<service>
<operatingPeriodRef>	x
<ocpTT>	x	used for referencing an existing train part within the target system; mandatory are only the first and last <ocpTT> of the train part and their references to the <ocp>
<train>	x	used for referencing an existing train within the target system
<trainPartSequence>	x
<trainPartRef>	x

Additional requirements:

It must be possible to chain all <trainPart> elements that model one run through group of vehicles. Each of these sequences of <trainPart> elements must have a key that is unique in the railML data set as well as in the target system.

Improvements for further versions:

In the current implementation of railml^® 2.x it is not clearly defined how two <trainPart> elements in succeeding <trainPartSequence>s must be chained to model a running through service (group of vehicles). One approach is to chain all <trainPart> elements with the same key (code, name, etc.) in an order whereat the last referenced <ocp> of the current <trainPart> is the same as the first <ocp> of the following <trainPart>. (This order can already be deduced from commercial train elements.) A better modelling for this aspect is, in the author’s opinion, to use the concept of commercial trains in a different way than currently described in Wiki: Each commercial train should model exactly one sequence of <trainPart> elements. Today it may contain several "parallel" sequences of <trainPart> elements at the same time, which makes it impossible to figure out which <trainPart> elements of two succeeding <trainPartSequence>s must be linked together.

Used terms and expressions:

• target system: the system, in which the railML data is imported
• data set: a set of railML data that is transfered to the target system within one transaction, usually the content of one railML file

Open Issues:

• Referencing <ocp>s via "code" or <designator>
• Modelling defined and undefined timetable periods
• One commercial train for each trainPart sequence or only multiple trainParts in each sequence of commercial train allowed; moving the key attribute (code or name) from trainPart to the commercial train
• referencing trains (via "code" or trainNumber/scope/additionalTrainNumber)
• referencing categories

Sand box

Diskussion timetable Treffen Wien 16.03.2015

• <trainPart>.trainNumber: nichts oder (redundant) Nummer des verkehrlichen/commercial Zugs wie <train>.trainNumber
• <trainPart>.code: Nummer des Zugteils (wie "61458" für Praha - Erfurt) -> Verwendung unklar
• <trainPart>.name: optional Name des Zugteils (wie "Canopus")

An einem operational train sollte kein Znr-Wechsel modelliert werden. trainNumber vom <trainPart> sollte nicht verwendet werden, zur Abbildung von Zugnummerwechseln bei durchlaufenden Zügen. Hierfür müsste ein neues Attribut an der trainPartsequence vorgesehen werden.

Offen ist, ob ein Wechsel der Zugnummern bei betrieblichen Zügen praktisch vorkommen kann.

trainNumber und name sollen inhaltlich zum commercial train verschoben werden -> evtl. in 2.3. als deprecated erklären. code soll am trainPart erhalten bleiben.

operational trains:

• <train>.trainNumber/scope/additionalTrainNumber: wie bekannt in der "Summe" (als Tripel) Eindeutigkeitskriterum über alle operational trains
• <train>.code: frei für eine Art Schlüssel des Zuges, der über die railML-Datei hinaus Bedeutung haben kann
• <train>.name: nicht verwendet

commercial trains:

• <train>.trainNumber/scope/additionalTrainNumber: wie bekannt in der "Summe" (als Tripel) Eindeutigkeitskriterum über alle commercial trains (Besonderheit FBS: hier nur trainNumber benutzt, scope/additionalTrainNumber immer leer)
• <train>.code: frei für eine Art Schlüssel des Zuges, der über die railML-Datei hinaus Bedeutung haben kann
• <train>.name: optional Name des Zuges (wie "Canopus")

trainNumber vs. code im Allgemeinen:

code soll für jeden Tag eine eindeutige Bezeichnung eines Zuges herstellen (im Gegensatz zur trainNumber, die an einem Tag mehrfach vorkommen kann, z.B. verschiedene EVU, etc.). code soll eine eindeutige Id für den Zug darstellen und darf deswegen nicht Zugeigenschaften, wie Verkehrstage, Laufweg etc. abbilden.

für die "Betitelung" (Vermarktung) von commercial trains dem Reisenden gegenüber = Spaltenüberschrift im Kursbuch gilt: wenn <commercial train>.trainNumber angegeben ist, wird diese verwendet. Ansonsten wird <commercial train>.name verwendet. Eines von beiden muss angegeben sein.

besondere Bedingungen für das Einlesen von RailML-Dateien in FBS: - <commercial train>.trainNumber/scope/additionalTrainNumber/name werden nicht ausgewertet