UC:TT:ExchangeOfFormationData
|
| Exchange of formation data Subschema: Timetable and Rostering Related subschemas: IS RS Reported by: iRFP | |||
| |||
| 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-Schemas
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:
- 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