UC:TT:ExchangeOfFormationData: Difference between revisions

From railML 3 Wiki
Jump to navigation Jump to search
[unchecked revision][checked revision]
m (1 revision imported)
(-fra)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{UseCase|TT||title=Exchange of formation data|IS=1|RS=1|reporter=iRFP}}
{{UseCase|TT|title=Exchange of formation data|IS=1|RS=1|reporter=iRFP}}


{{UC title}}
{{UC title}}


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


{{UC description}}
{{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 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).
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).




Line 14: Line 13:


The usecase covers the exchange of the following data:
The usecase covers the exchange of the following data:
* the composition of <trainPart>s of <vehicle>s (using <formation>s)
* the composition of <operationalTrainSectionPart>s of <vehicle>s (using <formation>s)
* <operatingPeriod>s of <trainPart>s
* <validity>s of <operationalTrainVariant>s
* commercial and technical properties of <trainPart>s/<formation>s
* commercial and technical properties of <operationalTrainSectionPart>s/<formation>s
* added and removed <trainPart>s within a <train>
* added and removed <operationalTrainSectionPart>s within an <operationalTrain>


The usecase does not cover the exchange of data concerning the <train>, in particular:
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 (<ocpsTT>)
* changes of the train path or times (<baseItinerary>)
* added or removed <train>s
* 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 <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:
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:
* <train>
* <operationalTrain>
* <trainPart>
* <operationalTrainVariant>
* <ocp>
* <operationalTrainSection>
* <operationalTrainSectionPart>
* <operationalPoint>
* <vehicle>
* <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.
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}}
{{UC interference}}
Line 60: Line 60:
!Element !! Mandatory !!Remarks
!Element !! Mandatory !!Remarks
|-
|-
| {{IS:Tag|ocp}} || x || used for referencing an existing ocp within the target system
| {{IS:Tag|operationalPoint}} || x || used for referencing an existing operational point within the target system
|-
|-
| {{IS:Tag|designator}} ||  || used for referencing an existing ocp within the target system
| {{IS:Tag|designator}} ||  || used for identifying an existing operational point within the target system
|-
|-
| {{RS:Tag|formation}} || x
| {{RS:Tag|formation}} || x
Line 70: Line 70:
| {{RS:Tag|vehicle}} || x || used for referencing an existing vehicle within the target system
| {{RS:Tag|vehicle}} || x || used for referencing an existing vehicle within the target system
|-
|-
| {{RS:Tag|operator}} || || used for referencing an existing vehicle within the target system
| {{RS:Tag|administrativeData}} || || used for referencing an existing vehicle within the target system
|-
|-
| {{RS:Tag|manufacturer}} || || used for referencing an existing vehicle within the target system
| {{CO:Tag|timePeriod}} ||  
|-
|-
| {{TT:Tag|timetablePeriod}} ||
| {{@|publicHolidayMode|BitmaskValidity}}  
|-
|-
| {{TT:Tag|holiday}}
| {{TT:Tag|validity}} || x
|-
| {{TT:Tag|operatingPeriod}} || 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|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|trainPart}} || x || used for referencing an existing train part within the target system and to identify removed or added trainParts
| {{TT:Tag|operationalTrainSectionPart}} || x || used for referencing an existing train part within the target system and to identify removed or added trainParts
|-
|-
| {{TT:Tag|formationTT}} || x
| {{TT:Tag|formationInformation}} || x
|-
|-
| {{TT:Tag|places}}
| {{TT:Tag|passengerFacilities}}
|-
|-
| {{TT:Tag|service}}
| {{TT:Tag|freightFacilities}}
|-
|-
| {{TT:Tag|operatingPeriodRef}} || x
| {{@|validityRef|TT:validity}} || x
|-
|-
| {{TT:Tag|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>
| {{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|train}} || x || used for referencing an existing train within the target system
| {{TT:Tag|operationalTrainVariant}} || x || used for referencing an existing train within the target system
|-
|-
| {{TT:Tag|trainPartSequence}} || x
| {{TT:Tag|itinerary}} || x
|-
| {{TT:Tag|trainPartRef}} || x
|-
|-
|}
|}
Line 104: Line 100:


'''Additional requirements:'''
'''Additional requirements:'''
 
Looking at the modelling of railML<sup>®</sup> 2.x the following requirement needs to be fulfilled:
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.
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:'''
'''Improvements for further versions:'''
Line 118: Line 114:
'''Open Issues:'''
'''Open Issues:'''


* Referencing <ocp>s via "code" or <designator>
* Modelling defined and undefined timetable periods
* 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
* 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 trains (via "code" or trainNumber/scope/additionalTrainNumber)
* referencing categories
* referencing categories

Latest revision as of 13:26, 13 March 2023

Exchange of formation data
Subschema: Timetable and Rostering
 
Related subschemas: IS RS 
Reported by: iRFP
Stift.png (version(s) not yet specified)
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:

  • 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
Retrieved from "https://wiki3.railml.org/index.php?title=UC:TT:ExchangeOfFormationData&oldid=7240"