View source for UC:TT:ExchangeOfFormationData

{{UseCase|TT|title=Exchange of formation data|IS=1|RS=1|reporter=iRFP}}

{{UC title}}

Exchange of formation data; {{Deu|Austausch von Wagenreihungen/Behängungsdaten}}; {{Fra|???}}


{{UC description}}

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).


{{UC flows}}

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.

{{UC interference}}

infrastructure, rolling stock

{{UC data}}

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

{{UC update}}

* weekly-yearly

{{UC complexity}}

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

{{UC focus}}

Mid and short term planning

{{UC elements|TT}}

Used elements:
{|
|-
!Element !! Mandatory !!Remarks
|-
| {{IS:Tag|operationalPoint}} || x || used for referencing an existing operational point within the target system
|-
| {{IS:Tag|designator}} ||  || used for identifying an existing operational point within the target system
|-
| {{RS:Tag|formation}} || x
|-
| {{RS:Tag|vehicleRef}} || x
|-
| {{RS:Tag|vehicle}} || x || used for referencing an existing vehicle within the target system
|-
| {{RS:Tag|administrativeData}} || || used for referencing an existing vehicle within the target system
|-
| {{CO:Tag|timePeriod}} || 
|-
| {{@|publicHolidayMode|BitmaskValidity}} 
|-
| {{TT:Tag|validity}} || x
|-
| {{TT:Tag|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
|-
| {{TT:Tag|operationalTrainSectionPart}} || x || used for referencing an existing train part within the target system and to identify removed or added trainParts
|-
| {{TT:Tag|formationInformation}} || x
|-
| {{TT:Tag|passengerFacilities}}
|-
| {{TT:Tag|freightFacilities}}
|-
| {{@|validityRef|TT:validity}} || x
|-
| {{TT:Tag|baseItineraryPoint}} || x || used for referencing an existing operational train section within the target system; mandatory are only the first and last <baseItineraryPoint>s of the operational train section and their references to the <IS:Tag|operationalPoint>
|-
| {{TT:Tag|operationalTrainVariant}} || x || used for referencing an existing train within the target system
|-
| {{TT:Tag|itinerary}} || x
|-
|}


'''Additional requirements:'''
Looking at the modelling of railML<sup>®</sup> 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<sup>®</sup> 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