UC:TT:ExchangeOfFormationData

Exchange of formation data Subschema: Timetable and Rostering   Related subschemas: IS RS  Reported by: iRFP

DRAFT railML® version TBD

For general information on use cases see UC:Use cases

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 period. 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 nor the path 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 <operationalTrainSectionPart>s of <vehicle>s (using <formation>s)
• <validity>s of <operationalTrainVariant>s
• commercial and technical properties of <operationalTrainSectionPart>s/<formation>s
• added and removed <operationalTrainSectionPart>s within an <operationalTrain>

The usecase does not cover the exchange of data exchanged on the level of whole trains, in particular:

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

As a consequence, it is assumed that both source and target system of the exchanged data must refer to the same set of <operationalTrain>s, i.e. the <operationTrains>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:

• <operationalTrain>
• <operationalTrainVariant>
• <operationalTrainSection>
• <operationalTrainSectionPart>
• <operationalPoint>
• <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 TT data do you expect to receive/send (elements)?

Used elements:

Element	Mandatory	Remarks
<operationalPoint>	x	used for referencing an existing operational point within the target system
<designator>		used for identifying an existing operational point within the target system
<formation>	x
<vehicleRef>	x
<vehicle>	x	used for referencing an existing vehicle within the target system
<administrativeData>		used for referencing an existing vehicle within the target system
<timePeriod>
@publicHolidayMode
<validity>	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
<operationalTrainSectionPart>	x	used for referencing an existing train part within the target system and to identify removed or added trainParts
<formationInformation>	x
<passengerFacilities>
<freightFacilities>
@validityRef	x
<baseItineraryPoint>	x	operationalPoint>
<operationalTrainVariant>	x	used for referencing an existing train within the target system
<itinerary>	x

Additional requirements: Looking at the modelling of railML^® 2.x the following requirement needs to be fulfilled: The predecessor and successor of each <trainPart> within a <train> must be uniquely defined. If a <trainPart> has more than one predecessor or successor according to the operating day, the <trainPart> must be divided among several commercial trains. Practically, this means that each <trainPartSequence> of a commercial train may only reference one <trainPart>.

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 <operationalPoints>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