Es gibt in railML naturgemäß keine einheitliche Identifizierung für Züge. Vielmehr ist es von Einsatzfall, lokalen Gepflogenheiten und den beteiligten Programmen abhängig, wie Züge identifiziert werden. raiLML hingegen ist ein allgemeingültiges Austauschformat, das hier mehrere Möglichkeiten erlaubt.

Das verbreitetste Attribut zur Identifikation eines (betrieblichen) Zuges (railML: <train> mit @type=operational) ist die Zugnummer (railML: @trainNumber). Meist reicht diese allein jedoch nicht aus, um einen Zug eindeutig zu identifizieren - etwa kann die gleiche Zugnummer an verschiedenen Verkehrstagen unterschiedliche Trassen bzw. Züge beschreiben.

Im Falle mehrerer Trassen mit gleicher Zugnummer an disjunkten Verkehrstagen steht in railML das Attribut additionalTrainNumber zur Unterscheidung zur Verfügung. Es gibt in diesem Fall mehrere <train>s mit @type=operational, mit der gleichen @trainNumber und @scope=primary, die sich nur durch @additionalTrainNumber unterscheiden (siehe Beispiel 1).

Zudem gibt es in einigen Ländern das Phänomen das "Nebenlaufs": An unterschiedlichen (disjunkten) Verkehrstagen nimmt ein und derselbe betriebliche Zug abschnittsweise verschiedene Laufwege oder Zeiten an. Dies führt zu anderen Werten des Attributes @scope:

• secondaryInner = Zwischen-Nebenlauf = "Doppelfahrplan"
• secondaryStart = Vor-Nebenlauf = "Startflügel"
• secondaryEnd = Nach-Nebenlauf = "Zielflügel"

(siehe Beispiel 2).

Dies ist aber immer durch "Umformulieren" zu mehreren Hauptläufen vermeidbar (scope=primary wie zuvor genannt).

Trotz alledem kann es softwaretechnisch vorkommen, dass FBS Daten exportiert, die gegen die "Soll-Richtlinie" verstoßen und die gleiche Zugnummer am selben Tag enthalten. Das kann durchaus gewollte Absicht sein, etwa wenn ein Zug den Abbildungsbereich des Anwenders verlässt, auf "fremder" Infrastruktur weiterfährt und danach wieder in den Abbildungsbereich des Anwenders zurückkommt. Ein Beispiel wäre ein österreichischer Zug, der zwischen Salzburg und Kufstein über Rosenheim fährt. Er könnte tatsächlich zweimal am selben Verkehrstag in (österreichischen) railML-Daten enthalten sein, nämlich einmal bis Salzburg und einmal ab Kufstein. Ähnliches wäre es, wenn ein Zug einmal auf einer Teilstrecke durch Schienenersatzverkehr unterbrochen würde (siehe Beispiel 3).

In jedem Fall kann die FBS-RailML-Schnittstelle doppelt vorkommende Zugnummern - je Verkehrstag oder allgemein - durch optionale Prüfmöglichkeiten beim Export erkennen und verhindern. Es ist sinnvoll, die konkreten Möglichkeiten und Restriktionen vor Inbetriebnahme des Datenaustauschs zwischen dem beteiligten Software-Hersteller, dem Anwender und iRFP abzustimmen, wofür wir natürlich gern zur Verfügung stehen.

Mehr Informationen zu diesem Thema finden Sie hier auf den Seiten 21 - 24.