TT:times ocpTT ocpsTT trainPart
|
times
Scheme description / Schemenbeschreibung
Position of times in the XML-Tree / Position von times im XML-Baum
- Parent: <ocpTT>
- Children: None
Multiplicity / Anzahl
Semantics / Bedeutung
The Element <times> describes arrival and departure times of a train with their scope.
Das Element <times> beschreibt Ankunfts- und Abfahrtszeiten eines Zuges und ihre Interpretation.
Please, be aware of the semantic constraint(s)!
Attributes of times / Attribute von times
- scope: The attribute @scope is used to distinguish different <times> elements at the same parent <ocpTT>. Typically, they refer to different planning or operating stages (comp. #Semantics and restrictions of the attribute scope).
Das attribute @scope wird verwendet um verschiedene <times> Elemente am selben ĂŒbergeordneten Element unterscheiden zu können. Typischerweise beziehen sich die Werte auf unterschiedliche Planungs- bzw. Betriebsstadien (vgl. #Semantics and restrictions of the attribute scope).
- Possible values are:
- actual: in the sense of "current"; timetable data, that the train generated by its run
- calculated timetable data, calculated by a simulation tool
- published timetable data, that the passenger gets on written sheets or online
- scheduled arrival/departure times for operational purposes
- earliest used to express a wish of a customer at a very early planning stage of a new timetable: The earliest acceptable arrival and/or departure time.
- latest used to express a wish of a customer at a very early planning stage of a new timetable: The latest acceptable arrival and/or departure time.
- other:anything: Any value that does not fit any value from the previous enumeration list, fulfilling the constraint: at minimum two characters, whitespace is not allowed. Please, apply Dev:usingAny accordingly.
|
|
- arrival: Moment at which the train ends its movement and gets to a halt at the parent <ocpTT>; usually called arrival time.
- If this attribute is set at the first <ocpTT> of a <trainPart> that is also the first of the <trainPartSequence> of all <train>s it belongs to, it shall describe an "arrival from outside of the scope of the railML file": It expresses that the train arrives at that first <ocpTT> at the given time, but the railML file does not express from where the train arrives nor whether it arrives as a train movement at all or rather as a shunting movement.
- arrivalDay: arrival on the n-th day, with train (but not necessarily the parent trainPart) starting on day 0 at its first departure. To learn, how to handle values â 0, see How to indicate midnight overruns in railML.
- departure: departure or run-through (passing) time;
- normally specified at all except the very last station of the last trainPart (section) of a train:
- If this attribute is set at the last <ocpTT> of a <trainPart> that is also the last of the <trainPartSequence> of all <train>s it belongs to, it shall describe "departure to outside of the scope of the railML file": It expresses that the train departs at that last <ocpTT> at the given time, but the railML file does not express to where the train departs nor whether it departs as a train movement at all or rather as a shunting movement.
- departureDay: departure on the n-th day, with <train> (but not necessarily the parent <trainPart>) starting on day 0 at its first departure. To learn, how to handle values â 0, see How to indicate midnight overruns in railML.
- xs:anyAttribute: This provides an extension point for non-railMLÂź attributes in a foreign namespace. How to use it?
(introduced with version 2.2)
Syntactic Constraints / Syntaktische BeschrÀnkungen
- scope: tTimeScope (union of (restriction of xs:string, tOtherEnumerationValue); tOtherEnumerationValue is an arbitrary string starting with 'other:' followed by at minimum two characters, white space not allowed for extending railMLÂź enumeration lists); mandatory
- arrival: xs:time; optional
- arrivalDay: xs:integer; default: 0; optional
- departure: xs:time; optional
- departureDay: xs:integer; default: 0; optional
Semantic Constraints / Semantische BeschrÀnkungen
|
|
|
|
|
|
|
Best practice & Examples / Empfohlene Anwendung & Beispiele
Semantics and restrictions of the attribute scope
Slot ordering / Trassenbestellung
In the use case slot ordering the attributes 'earliest' and 'latest' are intended to define a wish of a RU or authority as customer of an IM. The customer likes to order a slot with the earliest departure at... or with the latest arrival at... Therefore, 'earliest' and 'latest' are related here to early planning states because they define something like the "first idea" of the timetable of a train.
They are not to be used as a redundancy to <ocpTT>.<sectionTT>.<runTimes>.operationalReserve, additionalReserve, minimalTime. Naturally a timetable defines a "timeslot" rather than an exact time - 'run time' is a random variable in a physical sense â so in order to express this volatility, use the above mentioned attributes of the element <runTimes>.
Im Anwendungsfall Trassenbestellung werden 'earliest' und 'latest' verwendet, um die gewĂŒnschte Zeit fĂŒr den Zug zu beschreiben: Das EVU oder die Behörde als Kunde eines EIU möchte eine Trasse mit der frĂŒhesten Abfahrt an X oder der spĂ€testen Ankunft an Y bestellen. Entsprechend beziehen sich 'earliest' und 'latest' auf sehr frĂŒhe Planungsphasen, bei denen eine erste Idee eines Zugfahrplans ausgetauscht wird.
'Earliest' und 'latest' sind nicht redundant zu <ocpTT>.<sectionTT>.<runTimes>.operationalReserve, additionalReserve, minimalTime zu verwenden. Es ist selbstverstĂ€ndlich, dass ein Fahrplan einen zeitlichen "Slot" definiert und keine exakte Zeitangabe - Fahrzeit ist eine ZufallsgröĂe im physikalischen Sinn. Um diese Streuung auszudrĂŒcken, sind die genannten Attribute des Elements <runTimes> zu verwenden.
Data exchange for DAS and TMS / Datenaustausch fĂŒr FAS und RBL
Another use case, that 'earliest' and 'latest' can be used for, is timetable simulation. 'Earliest' and 'latest' can be used here to either specify the input for a simulation or as output of a simulation run to transfer the results to a subsequent Timetable Planning System (TPS), Driver Advisory System (DAS) or Traffic Management System (TMS). Ein weiterer Use Case, bei dem 'earliest' und 'latest' zum Einsatz kommen können, ist Fahrplan-Simulation. 'Earliest' und 'latest' können hier verwendet werden, um entweder die Eingangsdaten fĂŒr eine Simulation zu beschreiben, oder aber die Ergebnisse der Simulation an ein Fahrplankonstruktionssystem, Fahrerassistenzsystem (FAS)[1] oder RechnergestĂŒtztes Betriebsleitsystem (RBL)[2] weiterzugeben.
Example / Beispiel
<trainPart id='tp_1' > <operatingPeriodRef ref='opp_once_a_day'/> <ocpsTT> <ocpTT sequence='1' ocpRef='ocp_A' ocpType='stop'> <times scope='earliest' departure='16:30'/> <times scope='scheduled' departure='16:31:18'/> <times scope='published' departure='16:30'/> <times scope='actual' departure='16:39:10'/> </ocpTT> <ocpTT sequence='2' ocpRef='ocp_B' ocpType='pass'> <times scope='scheduled' departure='16:38:02.46'/> <times scope='actual' departure='16:45:27'/> </ocpTT> <ocpTT sequence='3' ocpRef='ocp_C' ocpType='stop'> <times scope='latest' arrival='16:55'/> <times scope='scheduled' arrival='16:49:12.46'/> <times scope='published' arrival='16:50'/> <times scope='actual' arrival='16:56:02'/> </ocpTT> </trainPart>
The train part runs from ocp_A via ocp_B to ocp_C. Originally there was an order requesting the train to leave ocp_A at the earliest at 16:30 and to arrive at ocp_C not later than 16:55. Only the use case can clarify whether the time difference between 16:30 and 16:55 must be greater than the actual minimum travelling time or what to prefer in case of any inconsistencies.
The train was scheduled to leave ocp_A at 16:31:18, to pass ocp_B at 16:38 and to arrive at ocp_C at 16:49. But, the published departure time at ocp_A was 16:30, so one minute earlier than scheduled and just in time of the 'earliest' limit. The published arrival was 16:50, so rounded up to the next full minute, probably to be âon the safe sideâ.
Finally, the train did actually leave ocp_A at 16:39:10, so 8 minutes late (even 9 mins compared to the published time). It did pass ocp_B at 16:45, still 7 mins late, and did arrive at ocp_C at 16:56, also 7 mins late. So, it did fail to reach the âlatestâ arrival limit â we have to accept a discrepancy between âlatestâ and âactualâ at ocp_C. The <operatingPeriodRef>='opp_once_a_day' of the <trainPart> must clarify to which certain day the actual times refer.
Der Zugteil fĂ€hrt von ocp_A ĂŒber ocp_B nach ocp_C. UrsprĂŒnglich gab es eine Bestellung, in der der Zug frĂŒhestens um 16:30 Uhr von ocp_A abfahren und spĂ€testens um 16:55 Uhr in ocp_C ankommen sollte. Ob der Zeitunterschied zwischen 16:30 und 16:55 Uhr gröĂer als die tatsĂ€chliche Mindestbeförderungszeit sein muss oder was im Falle von Inkonsistenzen zu bevorzugen ist, kann nur durch den Anwendungsfall geklĂ€rt werden.
Der Zug wurde so geplant, dass er ocp_A um 16:31:18 Uhr verlĂ€sst, ocp_B um 16:38 Uhr passiert und ocp_C um 16:49 Uhr erreicht. Aber die veröffentlichte Abfahrtszeit in ocp_A war 16:30 Uhr, also eine Minute frĂŒher als geplant und gerade noch rechtzeitig vor der 'frĂŒhesten' Grenze. Die veröffentlichte Ankunftszeit war 16.50 Uhr, also aufgerundet auf die nĂ€chste volle Minute, wahrscheinlich um "auf der sicheren Seite" zu sein.
SchlieĂlich fuhr der Zug tatsĂ€chlich um 16:39:10 Uhr von ocp_A ab, also mit 8 Minuten VerspĂ€tung (sogar 9 Minuten verglichen mit der veröffentlichten Zeit). Er passierte ocp_B um 16:45 Uhr, mit immer noch 7 Minuten VerspĂ€tung, und kam bei ocp_C um 16:56 Uhr an, ebenfalls mit 7 Minuten VerspĂ€tung. Das heiĂt, die " spĂ€teste" Ankunftszeit wurde nicht erreicht - wir mĂŒssen die Unstimmigkeit zwischen der "spĂ€testen" und der "tatsĂ€chlichen" Ankunftszeit bei ocp_C akzeptieren. Die <operatingPeriodRef>='opp_once_a_day' des <trainPart> muss klĂ€ren, auf welchen bestimmten Tag sich die tatsĂ€chlichen Zeiten beziehen.
Notes / Anmerkungen
Handling midnight overruns / Umgang mit MitternachtsĂŒbergĂ€ngen
- âMain Article: How to indicate midnight overruns in railML
The attributes arrivalDay and departureDay are a counting of the number of midnight overruns relatively to a reference place (e. g. departure, see below). These attributes are optional with default value 0, e. g they do not have to be written as long as a train didnât run over midnight. But, after the first run over midnight, they must be written with values >0.
It is intended that the arrival/departureDay counting starts with 0 at the first departure of a train. Therefore, the value -1 can occur in rare cases of an arrival before the first departure (âarrival from nowhereâ, from outside the scope of the railML file). In case a train did already run over midnight before the first departure in the railML data, this first <ocpTT> may also have an arrival/departureDay >0.
If a <train> consists of several <trainPart>s which are sequentially linked, the day counting normally refers to the first departure of the whole <train>. So, it may happen that single <trainParts> already start with day counting >0.
A âback-jumpâ of the day counting may happen especially from the view of a commercial train (<train> with type=âcommercialâ): This means that the train first refers to <trainPart>s which did run over midnight and later refers to <trainPart>s which did not run over midnight.
- âHauptartikel: Abbildung von MitternachtsĂŒbergĂ€ngen in railML
Die Attribute arrivalDay und departureDay stellen eine ZĂ€hlung der Anzahl MitternachtsĂŒbergĂ€nge relativ zu einem Bezugspunkt (s. u.) dar. Diese Attribute sind optional mit Default-Wert 0, d. h. sie mĂŒssen solange nicht angegeben werden, solange ein Zug noch nicht ĂŒber Mitternacht gefahren ist. Nach dem ersten MitternachtsĂŒbergang, d. h. sobald ihr Wert >0 ist, sind sie jedoch anzugeben.
Es ist vorgesehen, dass die Tages- bzw. MitternachtszĂ€hlung (arrival/departureDay) an der ersten Abfahrt eines Zuges mit 0 beginnt. Demzufolge kann der Wert -1 vorkommen bei der ersten Ankunft im seltenen Fall, dass der Zug am ersten Bahnhof ĂŒber Mitternacht steht und zuvor âvon auĂerhalbâ kommt. Sollte der Zug bereits vor dem ersten abgebildeten Abfahrtsbahnhof â quasi âim Auslandâ â ĂŒber Mitternacht gefahren sein, darf diese erste <ocpTT> ebenfalls einen Tagesindex (arrival/departureDay) >0 aufweisen.
Wenn ein Zug aus mehreren (zu aufeinanderfolgenden Abschnitten verketteten) Zugteilen besteht, bezieht sich die TageszÀhlung i. d. R. auf den ersten Abfahrtsort des Gesamtzuglaufs. Bei einzelnen Zugteilen kann es also vorkommen, dass diese bereits mit TageszÀhlung >0 beginnen.
Wenn ZugteillĂ€ufe (in railML: commercial trains) von einem Zug auf einen anderen ĂŒbergehen, kann es zu einem âRĂŒckschrittâ der TageszĂ€hlung von >0 auf =0 kommen. Dies bedeutet, dass Zugteillauf von einem Zug, der bereits ĂŒber Mitternacht gefahren ist, ĂŒbergeht auf einen Zug, der noch nicht ĂŒber Mitternacht gefahren ist.
Special case of a non-zero operating day offset at the first <ocpTT> of a train run /
Spezialfall eines Verkehrstage-Offset ungleich Null an der ersten <ocpTT> eines Zuglaufs
- âMain Article: Examples for a non-zero operating day offset at the first ocpTT of a train run
- âMain Article: Beispiele fĂŒr einen Verkehrstage-Offset ungleich Null an der ersten ocpTT eines Zuglaufs
Open issues / Offene Punkte/Pendenzen
Not yet described. / Noch nicht beschrieben.
- â Fahrerassistenzsystem (FAS) ()
- â Betriebsleitsystem (RBL):de:RechnergestĂŒtztes_Betriebsleitsystem de:RechnergestĂŒtztes Betriebsleitsystem ( RechnergestĂŒtztes Betriebsleitsystem (RBL))