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

[0..∞]

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 recorded arrival and/or departure times of a currently running or already driven train
• calculated arrival and/or departure times from a simulation tool
• published arrival and/or departure times that the passengers get on written sheets or online
• scheduled arrival and/or departure times for operational purposes
• earliest acceptable arrival and/or departure time (used to express a wish of a customer at a very early planning stage of a new timetable)
• latest acceptable arrival and/or departure time (used to express a wish of a customer at a very early planning stage of a new timetable)
• expected (introduced with version 2.5) forecasted arrival and/or departure times based on realtime data
• 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.

🗒️ Not to be confused with <train>@scope, that distinguishes different paths / alternative slots of a train.

🗒️ Not to be confused with <train>@processStatus, that describes the scope in relation to a process of train path ordering.

• 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

Semantic Constraint "TT:010":   @scope='earliest' and 'latest' are not intended to encode supplement times, as this is redundant to <ocpTT>.<sectionTT>.<runTimes>@operationalReserve, @additionalReserve, @minimalTime. @scope='earliest' und 'latest' sind nicht zur Abbildung von Fahrzeitzuschlägen zu verwenden, da dies redundant zu <ocpTT>.<sectionTT>.<runTimes>@operationalReserve, @additionalReserve, @minimalTime ist.   Proposed on June 19th 2019 Approved on October 15th 2020 Discuss this semantic constraint Please, recognize our guidelines on semantic constraints

Semantic Constraint "TT:012":   When @scope='actual' is used, then the operating period and/or timetable period specified at the trainpart level shall refer to only one operating day. Like this the operating day to which the actual times refer is defined. Wenn @scope= 'actual' verwendet wird, bezieht sich die operating period und/oder timetable period des train(part) auf nur einen einzelnen Betriebstag. Es muss so festgelegt werden, auf welchen Betriebstag sich die erfassten Ist-Zeiten beziehen.   Proposed on June 19th 2019 Approved on June 2nd 2022 FIXME: add Link to discussion! Please, recognize our guidelines on semantic constraints

Semantic Constraint "TT:014":   @arrival is not to be specified if the attribute ocpType of the parent <ocpTT> has the value pass - use departure for run-through (passing) times; This is in line with the definition of @arrival as the moment at which the train ends its movement and gets to a halt at the parent <ocpTT>.   Proposed on June 19th 2019 Approved on June 2nd 2022 FIXME: add Link to discussion! Please, recognize our guidelines on semantic constraints

Semantic Constraint "TT:015":   At the first <ocpTT> of a <trainPart> that is not the first one of the <trainPartSequence>, the attribute @arrival is optional. If it is set anyway, then, for consistency reasons, the value of @arrival of the regarding <ocpTT> must be identical for both this <trainPart> and the preceding one.   Proposed on June 19th 2019 Approved on June 2nd 2022 FIXME: add Link to discussion! Please, recognize our guidelines on semantic constraints

Semantic Constraint "TT:016":   At the last <ocpTT> of a <trainPart> that is not the last one of the <trainPartSequence>, the attribute @departure is optional. If it is set anyway, then, for consistency reasons, the value of @departure of the regarding <ocpTT> must be identical for both this <trainPart> and the subsequent one.   Proposed on October 09th 2020 Approved on June 2nd 2022 FIXME: add Link to discussion! Please, recognize our guidelines on semantic constraints

Best practice & Examples / Empfohlene Anwendung & Beispiele

Semantics and restrictions of the attribute scope

Consistency expectations

In general it is expected that all <times> instances of the same @scope are consistent with each other. "consistent with each other" in this context means, that the times following the path of the train are continuously increasing, with respect to possibly crossed time zones. The reason for this is that it is assumed that all <times> instances of the same @scope are semantically linked. However, there are use cases where this may not apply. For example <times> with the @scope earliest or latest may encode inconsistencies as described below. Also for published <times> it is known that in some cases consistency is broken. In some use cases this can also happen in other @scopes, for example if railML is used as a means of transferring data from a planning system to a visualization with the express purpose of viewing inconsistencies graphically. It is acceptable practice though to refuse importing of such data in reading programs if such use case is excluded. A appropriate error reporting is advised in this case.

Im Allgemeinen wird erwartet, dass alle <times>-Instanzen desselben @scope miteinander konsistent sind. "Miteinander konsistent" bedeutet in diesem Zusammenhang, dass die Zeiten, dem Zuglauf folgend, kontinuierlich ansteigen. Der Grund dafür ist, dass angenommen wird, dass alle <times>-Instanzen desselben @scope semantisch miteinander verbunden sind. Es gibt jedoch Anwendungsfälle, auf die dies nicht zutrifft. Zum Beispiel <times> mit dem @scope earliest oder latest kodieren möglicherweise Inkonsistenzen, wie beispielsweise unten beschrieben. Auch für published <times> ist bekannt, dass in einigen Fällen die Konsistenz gebrochen wird. In einigen Anwendungsfällen kann dies auch in anderen @scopes vorkommen, z.B. wenn railML als Mittel zur Übertragung von Daten aus einem Planungssystem in eine Visualisierung mit dem ausdrücklichen Zweck verwendet wird, Inkonsistenzen grafisch darzustellen. Es ist jedoch akzeptierte Praxis, den Import solcher Daten in Leseprogrammen zu verweigern, wenn ein solcher Anwendungsfall ausgeschlossen ist. In diesem Fall wird eine entsprechende Fehlermeldung empfohlen.

scope values 'earliest' and 'latest'

As just explained it is in general assumed that the <times> specified for earliest and latest at one <ocpTT> should be consistent with each other. Accordingly the times specified for earliest (taking into account @arrivalDay and @departureDay) must be earlier than those specified for latest. Only in very rare cases this assumption is broken. For example in strategic planning it may be necessary to communicate impossibilities that result from various dependencies in order for the receiving system to adjust accordingly to avoid those impossibilities.

Wie soeben erläutert, wird im Allgemeinen davon ausgegangen, dass die für earliest und latest an einem <ocpTT> angegebenen <times> miteinander harmonieren sollten. Dementsprechend sollten die für earliest angegebenen Zeiten (unter Berücksichtigung von @arrivalDay und @departureDay) früher sein als die für latest angegebenen Zeiten. Nur in sehr seltenen Fällen wird diese Annahme gebrochen. Zum Beispiel kann es bei der strategischen Planung notwendig sein, Unmöglichkeiten mitzuteilen, die sich aus verschiedenen Abhängigkeiten ergeben, damit das empfangende System entsprechende Anpassungen vornehmen kann, um diese Unmöglichkeiten zu vermeiden.

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) oder Rechnergestütztes Betriebsleitsystem (RBL) 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.

Mapping to TAF/TAP TSI <TimeAtLocation>

In order to interact with the TAF/TAP and railML, arrival and departure times need to be mapped between these two standards. In TAF/TAP arrival and departure times are specified using <TimeAtLocation>. In general the concepts are quite similair, railML as well as TAF/TAP specify times with a time field that may be extended with a day offset for specifying times that exceed the normal 24 hours day. Both standards also support providing metadata for supplied time information, similair to the attribute @scope described above. A mapping between @scope and its TAF/TAP equivalent @TimingQualifierCode can be found below.
Um mit TAF/TAP und railML interagieren zu können, müssen die Ankunfts- und Abfahrtszeiten zwischen diesen beiden Standards gemapped werden. In TAF/TAP werden Ankunfts- und Abfahrtszeiten mit <TimeAtLocation> angegeben. Im Allgemeinen sind die Konzepte recht ähnlich. Sowohl in railML als auch in TAF/TAP werden Zeiten mit einem Zeitfeld angegeben, das um einen Tagesoffset erweitert werden kann, um Zeiten anzugeben, die über den normalen 24-Stunden-Tag hinausgehen. Beide Standards enthalten auch Metadaten für gelieferte Zeitangaben, ähnlich wie das oben beschriebene Attribut @scope. Ein Mapping zwischen @scope und seinem TAF/TAP-Äquivalent @TimingQualifierCode finden Sie unten.

View/edit list on the separate source page.

TAF/TAP @TimingQualifierCode	railML @scope	Description Beschreibung
PLA	published	Public arrival Veröffentlichte Ankunftszeit
PLD	published	Public departure Veröffentlichte Abfahrtszeit
ALA	scheduled	Actual arrival (from a scheduling perspective) Tatsächliche Ankunft (Planungsperspektive)
ALD	scheduled	Actual departure (from a scheduling perspective) Tatsächliche Abfahrt (Planungsperspektive)
ELA	earliest	Earliest possible/desired arrival Früheste mögliche/erwünschte Ankunft
ELD	earliest	Earliest possible/desired departure Früheste mögliche/erwünschte Abfahrt
LLA	latest	Latest possible/desired arrival Späteste mögliche/erwünschte Ankunft
LLD	latest	Latest possible/desired departure Späteste mögliche/erwünschte Abfahrt

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.