Beispiel: Wenn Sie z

Beispiel: Wenn Sie z

RailML®-Schnittstelle Themenübersicht Ausgewählte Beispiele zum RailML®-Format (Auszug) RailML-Version: 2.0-2.2 Erstausgabe: Juli 2010 ältere Ausgabe...

809KB Sizes 0 Downloads 27 Views

RailML®-Schnittstelle Themenübersicht

Ausgewählte Beispiele zum RailML®-Format (Auszug) RailML-Version: 2.0-2.2 Erstausgabe: Juli 2010 ältere Ausgaben: 03.08.2010, 19.03.2012, 26.03.2012, 16.04.2012, 22.05.2012, 16.01.2013 Stand: 08.12.2014 In diesem Dokument werden in loser Folge und willkürlicher Auswahl typische Beispielsituationen aus dem Eisenbahnbetrieb und deren Abbildung in RailML vorgestellt. Besonderes Augenmerk liegt dabei auf solchen Situationen, die neu in RailML 2.x sind oder deren Abbildung sich geändert hat. Die Auflistung ist in keinerlei Hinsicht vollständig – die Möglichkeiten von RailML sind weitaus umfangreicher, als hier dargestellt werden kann. Sofern nicht anders genannt, sind die hier angegebenen Beispiele für die RailML-Schemenversionen ab 2.0 gültig. Einige Beispiele beziehen sich auf erst nach Version 2.0 eingeführte Attribute, was dann explizit genannt wird. In der Regel sind die Dateien, aus denen hier beispielhaft zitiert wird, unter www.irfp.de/deutsch/fbs/schnittstelle_railml.html sowohl als RailML-Dateien als auch als PDF-Dateien (Tabellenfahr- und Umlaufpläne) zum Herunterladen verfügbar.

Themenübersicht Themenübersicht................................................................................................................... 1 Verschiedene Haltearten ....................................................................................................... 2 Alternative Stationsnamen ..................................................................................................... 3 Zugarten, Zuggattungen, Produkte und Fahrgastfahrten ....................................................... 4 Kilometrierung von Gleisen und Strecken .............................................................................. 6 Fahrt auf dem Gegengleis ..................................................................................................... 8 Allgemeines zu Zügen und Zugteilen....................................................................................10 Flügeln von Zügen................................................................................................................11 Allgemeines zu Datumsbezügen, Gültigkeitsperiode und Feiertagen ...................................14 Abbildung spezieller Verkehrstageregelungen ohne Datumsbezug ......................................15 Abbildung spezieller Verkehrstageregelungen mit Datumsbezug .........................................17 Mitternachtsübergänge .........................................................................................................18 Primärschlüssel von Zügen, Mehrfachzugläufe, Ergänzungsfahrpläne .................................21 Umlaufpläne .........................................................................................................................25 Kopfinformationen (Dublin Core Metadata Element Set) ......................................................30

© iRFP

Seite 1

Stand: 08.12.2014

RailML®-Schnittstelle Verschiedene Haltearten

Verschiedene Haltearten “normaler” Verkehrshalt:

General traffic stop



Betriebshalt Infrastrukturbetreiber: Operational stop infrastructure

Betriebshalt Fahrzeugbetreiber:

Operational stop by TOC



Bedarfshalt:

Stop on request / on demand



Halt nur zum Aussteigen:

Stop to alight only



Das Attribut stopOnRequest ist nur anzugeben, wenn commercial=true ist. Das Attribut operationalStopOrdered 1 ist nur anzugeben, wenn commercial=false ist. Es ist nicht vorgesehen, mehrere Haltearten gleichzeitig anzugeben. Entsprechend den Gepflogenheiten im Eisenbahnbetrieb gelten: Wenn Gründe für einen Verkehrs- und einen Betriebshalt gleichzeitig vorliegen, wird ein Verkehrshalt angegeben. Wenn ein Betriebshalt sowohl durch den Infrastrukturbetreiber als auch durch den Fahrzeugbetreiber erforderlich wird, wird er als Betriebshalt durch Fahrzeugbetreiber ausgewiesen (bestellter Betriebshalt). Ein Bedarfshalt ist eine besondere Form des Verkehrshaltes.

1

Das Attribut operationalStopOrdered wurde mit RailML 2.2 eingeführt.

© iRFP

Seite 2

Stand: 08.12.2014

RailML®-Schnittstelle Alternative Stationsnamen

Alternative Stationsnamen



Mit dem Typ operationalName kann ein alternativer Name angegeben werden, der für innerbetriebliche Zwecke zu verwenden ist. Mit dem Typ trafficName können mehrere alternative Namen angegeben werden, die zur Veröffentlichung geeignet sind. Diese können sich hinsichtlich Sprache und/oder Zeichensatz unterscheiden, wie aus den Beispielen ersichtlich ist. Die Angabe des xml:lang-Attributs ist optional und nur selten vorhanden oder gar notwendig. Sofern das Attribut verwendet wird, sind die Sprachcodes nach ISO 639 anzugeben. Wie nebenstehendes Beispiel zeigt, kann die Unterscheidung alternativer Stationsnamen auch allein im Zeichensatz und nicht in der Sprache liegen. Im Beispiel sind beide angegebenen Namen neugriechisch, jedoch einmal mit griechischen und einmal mit lateinischen Buchstaben. abbreviation='ΑΘΗΝ' name='ΑΘΗΝΑ'>

© iRFP

Seite 3

Stand: 08.12.2014

RailML®-Schnittstelle Zugarten, Zuggattungen, Produkte und Fahrgastfahrten

Zugarten, Zuggattungen, Produkte und Fahrgastfahrten Innerhalb der Elemente und gibt es in RailML derzeit kein Attribut, das unmittelbar erkennen lässt, von welcher Zuggattung ein Zug(teil) ist oder ob es ein Reisezug (Fahrgastfahrt, personenbefördernd) ist. Vielmehr muss hierfür das Attribut categoryRef des Elements „zurückverfolgt“ werden:

Die Zugarten sind innerhalb der Struktur in einer eigenen Liste zusammengefasst. Hier können die optionalen Attribute trainUsage und deadRun zu Rate gezogen werden, um festzustellen, ob eine Zugart i. d. R. für Reiseverkehr vorgesehen ist:

Es bleibt hier dem lesenden Programm überlassen, wie es damit umgeht, wenn diese Attribute nicht angegeben sind: Es kann einen Standard-Fall annehmen oder beim Anwender nachfragen oder diese Attribute zwingend erfordern, indem es eine Fehlermeldung ausgibt. Das bei angegebene Attribut categoryRef verweist auf Zugarten (categories), die in der Praxis üblicherweise als Produkte bezeichnet und auch veröffentlicht werden. Hierbei ist zu beachten, dass ein Zug gleichzeitig mehrere Produkte haben kann, da verschiedene Zugteile unterschiedliche Produkte haben können (s. a. Kapitel Allgemeines zu Zügen und Zugteilen). Dies kommt durchaus auch praktisch vor, z. B. die zwischen Erfurt und Plaue (Thüringen) vereinigt verkehrenden Züge der Erfurter Bahn (Produktbezeichnung EB) und Süd-Thüringen-Bahn (Produktbezeichnung STB) oder die bei der ÖBB gelegentlich an Züge mit der Produktbezeichnung RailJet angehangenen Verstärkungswagen, die jedoch als IC vermarktet werden. Dem gegenüber steht die traditionelle Zuggattung als etwas eher Betriebsinternes, wobei ein Zug in einem Streckenabschnitt nur eine Zuggattung haben kann. Für diese Zuggattung gibt es in RailML das Attribut categoryRef im Element , und zwar unter , da auch die betriebliche Gattung innerhalb des Laufwegs eines Zuges wechseln kann. Praktische Beispiele für solche Wechsel wären die vielen Fernreisezüge, die vor und nach ihrem eigentlichen (veröffentlichten) Zuglauf als Leerreisezüge zu- und abgeführt werden, wie das z. B. zwischen Berlin-Grunewald, Lehrter Bahnhof und Rummelsburg üblich ist:

Das Attribut categoryRef unter für die betriebliche Zuggattung wird üblicher Weise nur bei betrieblichen Zügen (Elemente mit Ausprägung type='operational') angegeben.

© iRFP

Seite 4

Stand: 08.12.2014

RailML®-Schnittstelle Zugarten, Zuggattungen, Produkte und Fahrgastfahrten

Es gibt in RailML derzeit keine explizite Unterscheidung zwischen Produkt und Gattung – ein Element kann sowohl als Zuggattung (d. h. referenziert von einem ) als auch als Produkt (d. h. referenziert von einem ) verwendet werden. Auch hier bleibt es dem lesenden Programm überlassen, wie es mit theoretisch möglichen Widersprüchen innerhalb der inhaltlichen Redundanz umgeht, falls ein Zug(teil) über seine .categoryRef z. B. als personenbefördernd, über seine .categoryRef jedoch als nicht personenbefördernd dargestellt wird. Es wird empfohlen, sich für verkehrliche Eigenschaften (wie z. B. personenbefördernd) am Produkt zu orientieren, für eventuelle betriebliche Eigenschaften (wie vielleicht categoryPriority) jedoch an der Gattung. Um einen Zug oder Zugteil explizit als personenbefördernd oder nicht personenbefördernd zu deklarieren, muss dieser zwingend über categoryRef auf eine entsprechend definierte verweisen. In diesem Zusammenhang ist jedoch zu beachten, dass gelegentlich das sogenannte „Überschreiben von Sitzplätzen“ vorkommt: Hierbei wird das Element unter benutzt, um die aus einer Formation (Attribut formationRef) „geerbten“ Platzkapazitäten zu überschreiben, d. h. im Einzelfall zu korrigieren. Falls die Platzkapazitäten dabei auf 0 korrigiert werden, folgt daraus implizit, dass der Zugteil in gewissem Sinne nicht mehr personenbefördernd sein kann – u. U. obwohl seine categoryRef etwas anderes suggeriert. Diese Möglichkeit wird z. B. benutzt, um abgesperrte Wagen innerhalb eines Zuges auszudrücken (ein Teil der Wagen = Zugteil darf von Reisenden ganz normal benutzt werden, ein anderer Zugteil ist jedoch abgesperrt, z. B. weil diese Wagen nicht an einen Bahnsteig passen).

Es kann zwar alternativ auch durch Zuweisung eines „Leerzug-Produkts“ zu diesem Zugteil ausgedrückt werden, dass die Wagen als abgesperrt gelten, jedoch ist das nicht immer üblich und oft von Gepflogenheiten des Anwenders abhängig (und kann daher nicht immer durch das schreibende Programm sichergestellt werden). Ebenso sollte i. d. R. nicht der gesamte Zug, sondern nur einige seiner Teile, durch Überschreiben auf 0 Plätze gesetzt sein. Dennoch wird lesenden Programmen empfohlen, beim Feststellen von Eigenschaften wie personenbefördernd oder zu veröffentlichen auch das Überschreiben der Plätze zu prüfen und ggf. darauf zu reagieren. Besonderer Hinweis zum Export von RailML aus dem Fahrplanbearbeitungssystem FBS: Damit die korrekt und vollständig von FBS nach RailML ausgegeben werden, ist es notwendig, alle verwendeten Zuggattungen in FBS zu konfigurieren. Das ist normalerweise (bei Verwendung des mitgelieferten Zuggattungsverzeichnisses FBS.znv) schon der Fall. Falls jedoch eine bisher noch nicht registrierte Gattung bzw. Produktbezeichnung verwendet wird, sollte geprüft werden, ob diese korrekt (z. B. für Reiseverkehr) konfiguriert ist. Das ist mit dem FBS-Editor für Zuggattungsverzeichnisse möglich (s. Menü Programme  ZNV). Dort sollte sie in der linken Liste eingetragen sein und darin eine Verwendung (eine Art von Reiseverkehr oder Güterverkehr) eingeschaltet sein. Um das sicherzustellen, gibt es in der FBS-RailML-Schnittstelle unter inhaltliche Prüfungen die Option alle Züge müssen eine definierte Zuggattung haben. Wenn das Zielprogramm die Fahrgastfahrten korrekt feststellen soll, empfehlen wir, diese Prüfung beim Export aus FBS immer eingeschaltet zu lassen und bei eventuellen Warnmeldungen die Zuggattungen entsprechend zu konfigurieren.

© iRFP

Seite 5

Stand: 08.12.2014

RailML®-Schnittstelle Kilometrierung von Gleisen und Strecken

Kilometrierung von Gleisen und Strecken Aus historischen Gründen ist die Kilometrierung einer Eisenbahnstrecke oft nicht ununterbrochen fortlaufend. Zum Beispiel durch Korrekturen der Streckenführung oder Eignerwechsel kann sie beliebige Unstetigkeitsstellen aufweisen („springen“) und/oder die Zählrichtung wechseln („fallen“). In RailML wird die praktische, historische (z. B. an Hektometertafeln angeschriebene) Kilometrierung einer Strecke als absolute Kilometrierung bezeichnet. Zur genauen Bestimmung von Entfernungen ist aber auch eine ununterbrochene Kilometrierung notwendig. Diese ist i. d. R. virtuell, d. h. in der Praxis nicht direkt erkennbar. Sie wird in RailML als relative Kilometrierung bezeichnet. Die relative Kilometrierung eines Gleises (RailML: Attribut pos) ist immer ununterbrochen fortlaufend steigend, jedoch nicht unbedingt bei 0 beginnend. Der Zusammenhang zwischen relativer und absoluter Kilometrierung erschließt sich durch die mileageChanges-Struktur. Die Angabe der absoluten Kilometrierung an den Betriebsstellen (crossSection) ist dazu redundant. In dem Sonderfall, bei dem die absoluten Kilometrierung auf der gesamten Strecke identisch ist mit der relativen Kilometrierung, kann die gesamte mileageChanges-Struktur in der RailML-Datei fehlen. Es sind dann alle absoluten (außen sichtbaren) Kilometrierungen als identisch zur jeweiligen relativen Position anzusetzen. Das folgende Beispiel definiert ein Streckengleis, welches (1) am Anfang fallend kilometriert ist, beginnend mit dem absoluten Kilometer 9,430 (2) nach 9424 Metern, also bei absolutem km 0,006, auf den neuen km-Wert 23,376 springt und von dort an steigend weiterläuft, (3) nach 18809 Metern (vom Anfang der Strecke), also bei bisherigem absoluten km 32,761 (= 23.376 + 18.809 - 9.424) auf den neuen km-Wert 33,391 springt und von dort an wiederum fallend weiterläuft 1 2 3

Die Pos. 1 ist nur in FBS-RailML (interne Version 2.0.5) vorhanden. Es ist ersichtlich, wie die Elemente , und in ihren absPos-Attributen die jeweils an dieser Position geltende absolute Kilometrierung angeben. Das Attribut absPosIn gibt auf redundante Art die „alte“ (bisherige) absolute Kilometrierung an einem -Element an. Dieser Wert ließe sich immer auch aus dem vorherigen -Element berechnen.

© iRFP

Seite 6

Stand: 08.12.2014

RailML®-Schnittstelle Kilometrierung von Gleisen und Strecken

Es sei angemerkt, dass die Ausprägungen up und down des Attributs dir numerisch („hochzählen“, „runterzählen“) zu interpretieren sind und damit vom britischen Sprachgebrauch abweichen, wo up = „in Richtung London“ und down = „weg von London“ bedeuten. Mit dem optionalen Attribut type kann die Art Kilometrierungssprungs angegeben werden (sofern es sich dabei nicht um einen Kilometrierungsrichtungswechsel 2 handelt). Dies bezieht sich terminologisch auf die in der Praxis unterschiedenen Begriffe „Fehlerstelle“: type = missing „Überglänge“: type = overlapping Das folgende Beispiel definiert eine Kilometrierung, die von km 32,567 auf km 32,600 springt. Da es sich um steigende Kilometrierung handelt (dir=up) und die Werte zwischen 32,567 und 32,600 also fehlen, handelt es sich um eine Fehlerstelle: 3

Das folgende Beispiel definiert eine Kilometrierung, die von km 22,233 auf km 21,200 „zurückspringt“. Da es sich um steigende Kilometrierung handelt (dir=up) kommen die Werte zwischen 21,200 und 22,233 doppelt vor, es handelt sich also um eine Überlänge: 3

2

Ein Kilometrierungsrichtungswechsel kommt auf Strecken der DB Netz AG und vielen anderen EIU nicht vor, da diese in solchen Fällen eine neue Streckennummer vergeben. Damit wird der Fall in RailML auf zwei tracks aufgeteilt. 3 Die initiale Zeile ist nur in FBS-RailML (interne Version 2.0.5) vorhanden. Sie wird hier nur wiedergegeben zum leichteren Verständnis. Mit den derzeitigen RailML-Schemen ist die initiale Kilometrierungsrichtung nur durch Auswerten von .absPos und .absPosIn ermittelbar. Dies soll (u. a.) ab RailML 3.0 geändert werden. © iRFP

Seite 7

Stand: 08.12.2014

RailML®-Schnittstelle Fahrt auf dem Gegengleis

Fahrt auf dem Gegengleis In RailML gibt es zunächst keine explizite Kennzeichnung der Regelfahrrichtung eines Gleises. Auch bei Gruppierung der Gleise (RailML: tracks) zu Strecken (RailML: trackGroups) sind alle Gleise zunächst gleichwertig. Beispiel für die Gruppierung von drei (Strecken-)Gleisen zu einer Strecke:

track 2 C-B

F

E

D

C

B

A

trackGroups: line

track 3 E-D track 1 A-F

In dieser Philosophie der Gruppierung von Gleisen zu Strecken ergibt sich eine Regelfahrrichtung – sofern überhaupt notwendig – nur sehr indirekt z. B. durch entsprechende sicherungstechnische Ausrüstung bzw. das Fehlen derselben (was in RailML nur erkennbar ist, sofern das entsprechende sicherungstechische Teilschema verwendet wird) oder gar nur durch das überwiegende Vorkommen von Zügen einer Fahrtrichtung. Sofern dennoch die Angabe einer Regelfahrrichtung gewünscht wird, ist dies mit dem Attribut mainDir möglich:

Das Attribut mainDir hat allerdings keine technische Bedeutung, d. h. es folgt keinerlei technische bzw. infrastrukturelle Eigenschaft des Gleises aus seinem Wert. Zu beachten ist, dass mainDir sich auf die relative Kilometrierungsrichtung bezieht und damit vom Attribut mileageChange.dir abweicht, wo sich dir natürlich auf die absolute Kilometrierungsrichtung bezieht. Der Grund für die Festlegung auf relative Kilometrierungsrichtung ist, dass sich mainDir immer auf das gesamte Gleis bezieht, während die absolute Kilometrierungsrichtung innerhalb des Gleises mehrfach wechseln kann und damit nicht eindeutig wäre. Im konkreten Beispiel wird das Gleis in der Regel in Richtung aufsteigender relativer Kilometrierung gebraucht (mainDir=up), währenddessen die absolute Kilometrierung fallend ist (dir=down). Das Gleis wird folglich in der Regel in Richtung fallender absoluter Kilometrierung gebraucht.

© iRFP

Seite 8

Stand: 08.12.2014

RailML®-Schnittstelle Fahrt auf dem Gegengleis

Ebenso wie die Regelfahrrichtung ergibt sich bei der RailML-Philosophie eine Zugfahrt auf dem Gegengleis zunächst indirekt, indem ein Zugteil über sein Attribut trackRef ein Gleis referenziert, welches offensichtlich nicht das für diese Fahrtrichtung gewöhnliche ist. Um hier vereinfachend ein Erkennen der Fahrt auf dem Gegengleis zu ermöglichen, ohne die Infrastruktur dereferenzieren zu müssen, kann das optionale Attribut trackInfo verwendet werden. Es wird empfohlen, hier trackInfo=1 für Regelgleis, trackInfo=2 für Gegengleis zu verwenden und das Attribut nur auf zweigleisigen Streckenabschnitten anzugeben. Dies ist jedoch keine zwingende RailML-Vorschrift.

Im konkreten Beispiel fährt der Zug bis DRAG und ab DAF auf dem Regelgleis einer zweigleisigen Strecke entgegen der Kilometrierung, was in diesem Falle Streckengleis 2 (tr_80.6212_2) ist. Das Regelgleis ist zusätzlich erkennbar an trackInfo=1. Im Abschnitt DRAG-DAF fährt er jedoch auf dem Gegengleis, hier erkennbar indirekt an trackRef =tr_80.6212_1 sowie direkt an trackInfo=2. Hinweis: Der hier gezeigte Ausschnitt bezieht sich auf FBS-RailML 2.05. trackRef wird ab RailML 2.1 als Unter-Element und nicht als Attribut ausgegeben; inhaltlich treffen die Aussagen aber weiterhin unverändert zu.

© iRFP

Seite 9

Stand: 08.12.2014

RailML®-Schnittstelle Allgemeines zu Zügen und Zugteilen

Allgemeines zu Zügen und Zugteilen Die Grundphilosophie der RailML-timetable-Version 2.0 ist, den vielfältigen Praxisanforderungen des Eisenbahnbetriebs wie z. B. Flügeln von Zügen, Verstärken, Wagenzugdurchlauf, Einsatz von Kurswagen usw. durch „Zerlegen“ von Zügen in kleinste, unteilbare Einheiten gerecht zu werden. Diese kleinsten unteilbaren Zugeinheiten werden trainParts genannt. Die eigentlichen Zuginformationen wie Zeiten, Fahrzeuge usw. sind an den Zugteilen zu finden. Die Zug-Struktur () in RailML hingegen fasst lediglich Zugteile zu Zügen zusammen, enthält aber darüber hinausgehend i. d. R. keine weiteren Informationen. Während sich innerhalb eines Zuglaufes (RailML-Element train) z. B. die Verkehrstage oder die Anzahl Fahrzeuge ändern können, sind innerhalb eines Elements trainPart immer alle Eigenschaften konstant. Die RailML-Elemente train können je einen betrieblichen oder verkehrlichen Zug enthalten. Wenn das train-Element einen betrieblichen Zug enthält, ist dessen Attribut type=operational. Wenn das train-Element einen verkehrlichen Zug enthält, ist dessen Attribut type=commercial. Das Zusammensetzen aus betrieblicher Sicht ergibt Züge, wie sie der Eisenbahner und das Eisenbahninfrastrukturunternehmen „sehen“, jedoch nicht unbedingt wie sie der Reisende sieht. Die Grundeigenschaft betrieblicher Züge ist, dass zu einem Zeitpunkt auf einem Streckengleis nur ein Zug fahren kann. Dieser Zug muss klar durch eine betriebliche Zugnummer definiert sein. Dieser Sichtweise kommt teilweise ein Sicherheitsaspekt zu (z. B. Verständigung zwischen den Betriebsstellen); sie wird daher als grundlegend empfunden. Das Zusammensetzen aus verkehrlicher Sicht ergibt „Züge“, wie der Reisende sie i. d. R. sieht und wie sie z. B. in Aushang- oder Tabellenfahrplänen (Kursbuch) oder elektronischen Fahrplanmedien angegeben werden. Hierbei können zu einem Zeitpunkt auf (quasi) einem Streckengleis mehrere (verkehrliche) Züge gleichzeitig „fahren“: In einem Tabellenfahrplan werden gekuppelte Züge durch zwei benachbarte Spalten mit gleichen Zeiten dargestellt. In einem Aushangfahrplan können zwei Zeilen mit gleicher Abfahrtszeit und gleichem Gleis vorhanden sein, wobei beide Zeilen unterschiedliche Ziele angeben, die Zugteile aber erst im späteren Zuglauf getrennt werden. Bedingt durch die Sichtweise trifft der Begriff „Zug“ hier nur im weitesten Sinne zu: So müssen „verkehrliche Züge“ nicht unbedingt ein Triebfahrzeug haben (z. B. Kurswagen). Jeder Zugteil wird i. d. R. durch genau je einen betrieblichen und einen verkehrlichen Zug erfasst. Jeder Zug (train-Element) führt alle Zugteile, aus denen er besteht, in seiner Struktur trainPartRef mit ref und position auf. Ein Zug kann dabei entweder gleichzeitig (an einer Stelle seines Zuglaufs) oder nacheinander (in aufeinanderfolgenden Abschnitten seines Zuglaufs) aus verschiedenen Teilen bestehen. Der Wert trainPartRef.position zählt die Stellung im Zug an einer Stelle im Zuglauf. Es kann daher mehrere trainPartRef-Einträge mit gleicher position geben, wenn die entsprechenden Zugteile an verschiedenen Abschnitten im Zuglauf vorkommen. Zu beachten ist, dass trainPartRef.position nicht unbedingt die tatsächliche Stellung im Zug angibt - durch unterschiedliche Verkehrstage der Zugteile können Teile mit niedrigerem position-Wert an bestimmten Tagen im Zugverband „fehlen“. Mehrere Zugteile an einer Stelle eines Zuglaufs kommen z. B. beim (abschnittsweisen) Verstärken oder Flügeln von Zügen vor. Aufeinanderfolgende Abschnitte eines Zuglaufs kommen z. B. vor, wenn unterwegs Verkehrstage wechseln.

© iRFP

Seite 10

Stand: 08.12.2014

RailML®-Schnittstelle Flügeln von Zügen

Flügeln von Zügen Unter Flügeln von Zügen ist hier das vereinigte Verkehren zweier Zugteile (meist Triebwagen) zu verstehen, die auf einem Teilabschnitt ihres Laufweges auch unabhängig voneinander verkehren. Dies ist im Prinzip nicht zu unterscheiden vom klassischen Begriff des Doppelzuges. Hingegen stellen die bei DB Netz gebräuchlichen Begriffe Start- und Zielflügel etwas anderes dar, worauf unter Mehrfachzuglauf/Ergänzungsfahrpläne eingegangen wird. Beispiel 1 Zunächst ist festzuhalten, dass beim Flügeln von Zügen ein wichtiger Unterschied zwischen der betrieblichen und der verkehrlichen Sichtweise auf die Züge besteht: Betrieblich (insbesondere aus Sicht des Eisenbahninfrastrukturunternehmens (EIU)) gibt es im vereinigten Abschnitt (im Beispiel: Dresden Hbf – Bischofswerda) nur einen Zug, während es aus verkehrlicher Sicht zwei (vereinigte) Züge sind. Die im Tabellenfahrplan im Spaltenkopf und in anderen verkehrlichen Auskunftsmedien angegebene Nummer ist daher nicht identisch mit der eigentlichen betrieblichen Zugnummer. Dieser Unterschied ist oft Grund für Verwirrung, da der Begriff Zugnummer hier nicht immer „sauber“ verwendet wird. verkehrlicher Zug trc_95001 (3)

verkehrlicher Zug trc_20201 (4)

vereinigter Abschnitt: betrieblicher Zug tro_95001 (1) Zugteile tp_95001_DH-DBW (5) und tp_20201_DH-DBW (6)

betrieblicher Zug tro_20201 (2)

In RailML werden die Züge zunächst in kleinste, nicht weiter unterteilbare Einheiten zerlegt. Diese kleinsten unteilbaren Zugeinheiten werden Zugteile genannt. Die eigentlichen Zuginformationen wie Zeiten, Fahrzeuge usw. sind an den Zugteilen zu finden. Zugteile werden dann sowohl zu betrieblichen als auch zu verkehrlichen Zügen zusammengesetzt.

Zugteil tp_20201 (7)

betrieblicher Zug tro_95001 (1) Zugteil tp_95001_DBW-DZ (8)

Das Attribut id der Züge und Zugteile dient nur der eindeutigen Bezeichnung und darf nicht interpretiert werden. Aus dem Attribut trainNumber der betrieblichen Züge ist erkennbar, unter welcher (offiziellen) Zugnummer der Zug beim EIU geführt wird. Die betrieblichen und verkehrlichen Züge können am Attribut type (=operational oder commercial) unterschieden werden.

Auszüge aus der zugehörigen RailML-Datei: 1

2

© iRFP

Seite 11

Stand: 08.12.2014

RailML®-Schnittstelle Flügeln von Zügen 3

4

5

ocp_DH = Dresden Hbf ocp_DN = Dresden-Neustadt ocp_DBW = Bischofswerda

ocp_DH = Dresden Hbf ocp_DN = Dresden-Neustadt ocp_DBW = Bischofswerda

6 8 ocp_DBW = Bischofswerda ocp_DEB = Ebersbach ocp_DZ = Zittau

ocp_DBW = Bischofswerda ocp_DBZ = Bautzen ocp_DL = Löbau ocp_DG = Görlitz

7

© iRFP

Seite 12

Stand: 08.12.2014

RailML®-Schnittstelle Flügeln von Zügen

Aus den Elementen trainPartSequence der Züge ist die Reihenfolge der Laufwegabschnitte („serielle“ Verkettung der Zugteile) erkennbar. Das Attribut sequence enthält die laufende Nummer des Laufwegabschnitts. Sofern in einem Laufwegabschnitt mehr als ein Zugteil vorkommt (hier: tro_95001 sequence 1), enthalten die Attribute position die Reihenfolge der Zugteile im Zugverband. (Zu beachten ist jedoch, dass position nicht unbedingt die tatsächliche Stellung im Zug angibt - durch unterschiedliche Verkehrstage der Zugteile können Teile mit niedrigerem position-Wert an bestimmten Tagen im Zugverband „fehlen“.) Beispiel 2 Im folgenden Beispiel wird der Unterschied zwischen betrieblicher und verkehrlicher Zugnummer besonders deutlich. verkehrliche Züge: verkehrlicher Zug 83107

verkehrlicher Zug 83507

betrieblicher Zug 83107

betrieblicher Zug 83507

betriebliche Züge: vereinigter Abschnitt: betrieblicher Zug 83107 (2teilig)

betrieblicher Zug 83107

betrieblicher Zug 83907



© iRFP

Seite 13

Stand: 08.12.2014

RailML®-Schnittstelle Allgemeines zu Datumsbezügen, Gültigkeitsperiode und Feiertagen

Allgemeines zu Datumsbezügen, Gültigkeitsperiode und Feiertagen Im Falle des Datenaustauschs von konkreten Fahrplänen verfügen die in einer RailML-Datei enthaltenen Fahrplandaten i. d. R. auch über einen Datumsbezug. Der Datumsbezug wird im Element timetablePeriod und optional ergänzend in den Elementen operatingPeriod hergestellt. Typischer Weise enthält ein Element timetablePeriod - Beginn und Ende der Gültigkeitsperiode in den Attributen startDate und endDate, - eine optionale Aufzählung von Feiertagen innerhalb der Gültigkeitsperiode.

Im einfachsten Fall enthält nur das eine vorhandene Element timetablePeriod einen Datumsbezug über startDate+endDate und ggf. noch über holidays. Die Elemente operatingPeriod können ohne weitere Angabe eines konkreten Datums beliebige Wochentage aus dem Gültigkeitsbereich referenzieren (s. nachfolgende Beispiele). Die Angabe der Feiertage ist die Bezugsbasis für die Unterelemente operatingDayDeviance der Elemente opertingPeriod. Die Elemente holidays und operatingDayDeviance sind daher zunächst nur gemeinsam sinnvoll anzuwenden. Wenn keine Elemente operatingDayDeviance angegeben sind, würden holidays nicht ausgewertet. Es ist aber dennoch denkbar, die Feiertage nur der Vollständigkeit halber anzugeben. Eine RailML-Datei kann, muss aber nicht über eine Gültigkeitsperiode verfügen. Eine RailML-Datei kann auch mehrere Gültigkeitsperioden beinhalten, wobei sich jede operatingPeriod und damit auch jeder Zug und Zugteil immer nur auf eine Gültigkeitsperiode gleichzeitig beziehen kann. RailML-Dateien ohne Gültigkeitsperiode haben entweder kein Element timetablePeriod oder nur Elemente timetablePeriod ohne startDate+endDate. Wenn keine Gültigkeitsperiode definiert ist, dürfen die Elemente operatingPeriod ebenfalls nicht über die Attribute startDate, endDate und bitMask und auch nicht über Unterelemente specialService verfügen. StartDate und endDate dürfen nur gemeinsam angegeben werden, nicht nur eines der beiden, d. h. es darf keine „offenen“ Perioden geben. Die Differenz der Attribute startDate und endDate definiert die Länge der Bitmasken (Attribut bitMask) der Elemente operatingPeriod.

© iRFP

Seite 14

Stand: 08.12.2014

RailML®-Schnittstelle Abbildung spezieller Verkehrstageregelungen ohne Datumsbezug

Abbildung spezieller Verkehrstageregelungen ohne Datumsbezug Verkehrstageregelungen (Saisonierungen) werden im RailML-Element timetable.operatingPeriods codiert. In einer Verkehrstageregelung (operatingPeriod) sind die einzelnen Tage auf zwei redundante Arten codiert: Einmal im Attribut bitMask über die gesamte Periode sowie in den Unterelementen operatingDay und specialService aufgeschlüsselt nach konkreter Eingabe in Regel- und Sonderverkehrstage. Der Grund für diese Dopplung ist, dass sich die Bitmaske zwar technisch relativ gut weiterverarbeiten, jedoch nicht eindeutig in eine Nutzereingabe rückverwandeln lässt. (D. h. es gibt mehrere Eingaben, die zur gleichen Bitmaske führen.) Für einige Anwendungen ist es wichtig, die Angaben genau so zu übermitteln, wie der Anwender sie eingegeben hat. Im Übrigen kann es relativ aufwändig sein, aus einer Bitmaske eine Trennung in Regel- und Sonderverkehrstage vorzunehmen (es kann z. B. eine Korrelationsanalyse erfordern, die Eingabe „W[Sa], nicht 24., 31.12.; auch 17.11.“ aus einer Bitmaske wiederherzustellen). Der Beschreibung mit operatingDay-Elementen kommt besondere Bedeutung zu, wenn z. B. bei „strategischen“ (langfristigen) Fahrplänen keine Gültigkeitsperiode definiert ist (keine timetablePeriod bzw. ohne startDate+endDate; s. a. vorheriges Kapitel). Das Element operatingDay enthält ein Unterelement operatingDayDeviance, dessen Bedeutung an den folgenden Beispielen erläutert werden soll: Im Allgemeinen gibt das Element operatingDayDeviance an, das die Verkehrstageregelung abweichend von operatingCode verkehrt oder nicht verkehrt, wenn ein Wochentag in der unter holidayOffset angegebenen Relation zu einem Feiertag steht. Das Attribut ranking definiert, welches operatingDayDeviance-Element gilt, falls es mehrere gleichzeitig zutreffende gibt. Beispielsweise könnte ein Wochentag gleichzeitig Feiertag und ein Tag vor einem Feiertag sein (in Deutschland z. B. der 25.12.). Beispiel 1 Die Verkehrstageregelung W[Sa] = Mo-Fr[S] = „Montag bis Freitag, jedoch nicht an Feiertagen“ wird wie folgt abgebildet:

Die Angabe operatingCode='1111100' bedeutet, dass die Regelung an den ersten fünf Wochentagen (=Montag bis Freitag) verkehrt. Die Angabe operatingCode='0000000' holidayOffset='0' bedeutet, dass die Regelung abweichend davon nicht verkehrt (=0000000), wenn der jeweilige Tag auf einen Feiertag fällt (holidayOffset=0 - „null Tage Versatz zu einem Feiertag“ hat). Beispiel 2 Die Verkehrstageregelung S = „Sonntag und alle Wochenfeiertage“ wird wie folgt abgebildet:

Die Angabe operatingCode='0000001' bedeutet, dass die Regelung nur an Sonntagen verkehrt. Die Angabe operatingCode='1111111' holidayOffset='0' bedeutet, dass die Regelung abweichend davon an allen Tagen verkehrt, die auf einen Feiertag fallen.

© iRFP

Seite 15

Stand: 08.12.2014

RailML®-Schnittstelle Abbildung spezieller Verkehrstageregelungen ohne Datumsbezug

Beispiel 3 Die Verkehrstageregelung vS = „Werktage vor Sonn- und Feiertagen“ wird wie folgt abgebildet:

Die Angabe operatingCode='0000010' bedeutet, dass die Regelung nur an Sonnabenden verkehrt (=vor Sonntagen). Die Angabe operatingCode='1111110' holidayOffset='-1' bedeutet, dass die Regelung auch an Montagen bis Sonnabenden verkehrt, sofern sie einen Tag vor einem Feiertagen liegen (holidayOffset=-1). Die Angabe operatingCode='0000000' holidayOffset='0' bedeutet, dass die Regelung nicht an Feiertagen verkehrt. Falls ein Tag gleichzeitig Feiertag und ein Tag vor einem Feiertag ist (in Deutschland z. B. 25.12.), verkehrt die Regelung nicht, denn es gilt dann die holidayOffset=0-Angabe. Entsprechend RailMLDokumentation (http://wiki.railml.org/index.php?title=TT:operatingDayDeviance) gilt im Zweifelsfall die Angabe mit niedrigerem ranking-Wert. Insgesamt sind die drei Zeilen (von oben nach unten) in etwa wie folgt zu interpretieren: Zeile 1: „verkehrt an Samstagen,... Zeile 2: ... sowie an Montagen bis Samstagen wenn vor einem Feiertag,... Zeile 3: ...jedoch nicht an Feiertagen“ Beispiel 4 Ein Zug beginnt seine Fahrt an Sa+S = „Samstagen sowie Sonn- und Feiertagen“ und verkehrt im Laufe der Fahrt über Mitternacht. Die Rückfahrt nach Mitternacht muss zwangsläufig an „Folgetagen von Sa+S“ stattfinden. In RailML würde Sa+S wie folgt abgebildet:

Die Folgetage von Sa+S sind demzufolge (alle Bitmasken um ein Bit nach rechts rotiert):

Für diese Regelung gibt es im deutschsprachigen Raum keine standardisierte Kurzbezeichnung. Sie ist nicht identisch mit So+nS, denn letztere würde abgebildet durch:

Mit RailML lassen sich auch Folge- und Vortage „sauber“ abbilden, was allein mit deutschen Kurzbezeichnungen so nicht möglich ist. Solange eine Fahrplanperiode definiert ist, ließen sich solche Folge- und Vortagesregelungen durch Verwendung von Sonderverkehrstagen (specialService in RailML) umschreiben. Wenn jedoch keine Fahrplanperiode zur Verfügung steht, ist die Lösung mit operatingDayDeviance die einzig mögliche. Dies betrifft insbesondere die bei Wettbewerbsverfahren (Ausschreibungsfahrplänen ohne konkrete Fahrplanperiode) im Vor- und Nachlauf um Wochenenden recht häufig vorkommenden Regelungen „Arbeitstage vor v (Arbeitstage vor arbeitsfreien Tagen), n (Arbeitstage nach arbeitsfreien Tagen), v (arbeitsfreie Tage vor Arbeitstagen) und n (arbeitsfreie Tage nach Arbeitstagen). © iRFP

Seite 16

Stand: 08.12.2014

RailML®-Schnittstelle Abbildung spezieller Verkehrstageregelungen mit Datumsbezug

Abbildung spezieller Verkehrstageregelungen mit Datumsbezug Hierbei geht es um solche Fälle wie „verkehrt nicht am 24. und 31.12.“ oder „nur vom 01.07.31.08.“. Voraussetzung hierfür ist, dass auch eine zugehörige Gültigkeitsperiode (timetablePeriod mit angegebenem startDate+endDate) definiert ist. Für diese Fälle können folgende zusätzlichen Elemente und Attribute verwendet werden: - Attribute startDate+endDate des Elements operatingDay, - Unterelemente specialService des Elements operatingPeriod. Die Angabe der Attribute startDate und endDate in operatingDay beschränkt die Anwendung der Bildungsregel des operatingDay-Elements auf diesen Datumsbereich. Beide sind nur gemeinsam zu benutzen und dürfen nur Tage innerhalb der Gültigkeitsperiode der timetablePeriod referenzieren. Bei specialService handelt es sich um eine Aufzählung von Ausnahmeverkehrstagen, an denen von den durch die operatingDay-Elemente definierten Bildungsregeln abgewichen wird. Dabei steht das Attribut type mit Ausprägung =include für Zusatzverkehrstage, =exclude für Ausfalltage. Die Attribute startDate und endDate definieren den ersten und letzten Gültigkeitstag der Ausnahme, sind nur gemeinsam zu benutzen und dürfen nur Tage innerhalb der Gültigkeitsperiode der timetablePeriod referenzieren. Das Attribut singleDate ist im Fall startDate=endDate anstatt dieser beiden zu verwenden. Beispiel 1: verkehrt nur vom 14.12. bis 20.12.

Beispiel 2: verkehrt nicht am 25.12. und nicht am 01.01.

Beispiel 3: verkehrt vom 13.12. bis 31.01. nur Sa und vom 01.07.-31.08. täglich; auch am 25.12. und 01.01, nicht am 15.08.“ (Verzicht auf Darstellung von name, bitMask usw.)

Falls mehrere operatingDay-Elemente in einem operatingPeriod-Element vorkommen, müssen diese durch ihre startDate-endDate-Bereiche oder ihre operatingCode-Bitmaske immer disjunkt sein.

© iRFP

Seite 17

Stand: 08.12.2014

RailML®-Schnittstelle Mitternachtsübergänge

Mitternachtsübergänge Es gibt mehrere Möglichkeiten, Mitternachtsübergänge in RailML korrekt abzubilden: 1. Mit Hilfe der Attribute arrivalDay und departureDay. 2. Durch Aufteilen des Zuglaufs in Zugteile vor und nach Mitternacht sowie Wechsel der operatingPeriod-Referenz zwischen diesen Zugteilen a) und Verwenden des Attributs dayOffset der nach Mitternacht gültigen operatingPeriod 4, b) und durch um einen Tag verschobene Angabe der Verkehrstage der nach Mitternacht gültigen operatingPeriod. Möglichkeit 1 ist die regulär vorgesehene für Mitternachtsübergänge innerhalb eines in RailML abgebildeten Zuglaufs. Es ist ausdrücklich nicht vorgesehen, einen Zuglauf nur wegen des Mitternachtsübergangs in Zugteile aufzuteilen. Möglichkeit 2a kommt dennoch in besonderen des Mitternachtsübergangs vor einem (hier betrachteten) Zuglauf in Betracht. Möglichkeit 2b soll vermieden werden. Mitternachtsübergänge innerhalb des abgebildeten Zuglaufs Für Mitternachtsübergänge innerhalb eines abgebildeten Zuglaufs sind in RailML die Attribute arrivalDay und departureDay vorgesehen. Sie stellen eine Zählung der Anzahl Mitternachtsübergänge relativ zu einem Bezugspunkt (z. B. Abfahrtsort; 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: Beispiel 1: Mitternachtsübergang während eines Zwischenaufenthalts

hier Mitternachtsübergang



Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des Zuges bis zu seinem Laufwegende sind mit arrivalDay=1 und departureDay=1 gekennzeichnet. Beispiel 2: Mitternachtsübergang während der Fahrt hier Mitternachtsübergang

Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des Zuges bis zu seinem Laufwegende sind mit arrivalDay=1 und departureDay=1 gekennzeichnet.

4

Das Attribut dayOffset wird mit RailML 2.2 eingeführt.

© iRFP

Seite 18

Stand: 08.12.2014

RailML®-Schnittstelle Mitternachtsübergänge

Referenzort der Tages-/Mitternachtszählung   



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. 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 Zugläufe (hier in RailML: commercialTrains) von einem Zug auf einen anderen übergehen, kann es zu einem „Rückschritt“ der Tageszählung kommen. (Dies bedeutet, dass der Zuglauf von einem Zug, der bereits über Mitternacht gefahren ist, übergeht auf einen Zug, der noch nicht über Mitternacht gefahren ist.) Auch dies ist kein Fehler.

In diesem Bild gibt es drei Züge (rot, grün, blau), die wegen der RailML-internen Syntax in mind. neun Zugteile unterteilt sein müssen (an den schwarz dargestellten Stationen). Im Zuglauf der Zugteile grün und blau kommt es zum „Rücksprung“ des Tagesindex‘ in Berlin (arrivalDay=1 auf departureDay=0). Der Rücksprung geht i. d. R.* mit einem scheinbaren Verkehrstagewechsel einher (operatingPeriodRef wechselt: Montag auf Dienstag). Beide Effekte zusammen führen zu ‘Monday +1’ auf ‘Tuesday +0’. * Nur „in der Regel“, denn wenn die Züge täglich fahren würden, gäbe es keinen scheinbaren Verkehrstagewechsel. Warum gibt es keinen Rücksprung auf dem Warschauer Abschnitt? In diesem Beispiel wurde unterstellt, dass es einen durchgehenden (betrieblichen) Zug Amsterdam – Warschau gibt. Da dieser in Amsterdam vor Mitternacht beginnt, beziehen sich seine arrival/departureDayAngaben auf die Amsterdamer Abfahrt, und er kommt in Warschau mit arrivalDay=1 an, aber ohne Rücksprung. Im Gegensatz dazu ist für den Prager Zweig unterstellt, dass in Berlin ein neuer (betrieblicher) Zug beginnt. Dessen Abfahrt mit departureDay=0 liegt bereits nach Mitternacht, daher der Rücksprung. Bedeutung der Tages-/Mitternachtszählung 

Die Verkehrstage-Angabe (operatingPeriod) ist allein nicht interpretierbar, sondern immer nur im Zusammenhang mit dem jeweiligen Tagesindex (arrival/departureDay). Um festzustellen, wann ein Zug tatsächlich fährt, muss man z. B. die Bitmaske um die Anzahl Stellen aus (arrival/departureDay + dayIndex) verschieben.

© iRFP

Seite 19

Stand: 08.12.2014

RailML®-Schnittstelle Mitternachtsübergänge



 

Ob ein effektiver Wechsel der Verkehrstage innerhalb des Zuglaufs stattfindet, kann nur durch Vergleichen der verschobenen Bitmasken herausgefunden werden. Ein Wechsel der operatingPeriod allein ist nicht zwingend ein effektiver Verkehrstagewechsel. Es kann beliebig viele Kombinationen aus Verkehrstage-Angabe (operatingPeriod) und Tagesindex (arrival/departureDay) geben, die inhaltlich das gleiche bedeuten. Das schreibende Programm ist frei in der Wahl der Kombination, diese kann auch „unterwegs“ wechseln.

Mitternachtsübergänge außerhalb des abgebildeten Zuglaufs I. d. R. ist es beabsichtigt – bei einigen Anwendungen auch von außen her erforderlich – dass ein Zug mit Tageszählung =0 beginnt, d. h. dass sich die Verkehrstage, mit denen er identifiziert wird, auf den ersten abgebildeten Abfahrtsbahnhof beziehen. Sollte der Zug bereits vor dem ersten abgebildeten Abfahrtsbahnhof – quasi „im Ausland“ – über Mitternacht gefahren sein, besteht damit nicht mehr die Möglichkeit, mit Tagesindex (arrival/departureDay) >0 am ersten abgebildeten Bahnhof zu beginnen. Damit bliebe dann nur noch die Möglichkeit (eingangs dieses Kapitels mit 2b bezeichnet), die Verkehrstage um die Anzahl Tage versetzt anzugeben, wie oft der Zug zuvor über Mitternacht gefahren ist. Diese Lösung ist jedoch ausdrücklich nicht gewollt u. a. aus folgenden Gründen:  Fahrplanperioden sind i. d. R. nicht geschlossen, d. h. auf den letzten Tag einer Fahrplanperiode folgt nicht wieder der erste Tag der gleichen Periode. Ein Zug, der in einer Fahrplanperiode täglich beginnt und über Mitternacht fährt, fährt danach genau genommen nicht mehr täglich (nämlich nicht am ersten Tag der Fahrplanperiode, dafür aber zusätzlich am ersten Tag der nächsten Fahrplanperiode). Die Bitmaske seiner Verkehrstage (operatingPeriod.bitMask) ist gegenüber vor Mitternacht um ein Bit in Richtung aufsteigenden Datums verschoben, d. h. selbst die zuvor nur aus Einsen bestandene Täglich-Bitmaske beginnt danach mit einer Null.  Das um Tage verschobene Angeben der Verkehrstageregelungen (operatingPeriods) ist ausdrücklich zu vermeiden, da wie bereits im Kapitel Abbildung spezieller Verkehrstageregelungen ohne Datumsbezug erwähnt, für viele praktisch vorkommende Verkehrstageregelungen keine exakte Folgetagsentsprechung existiert (z. B. nicht für die in Deutschland recht verbreiteten „werktags außer Samstags“ und „Sonn- und Feiertags“). Aus diesen Gründen wird mit RailML 2.2 neu das Attribut dayOffset im Element operatingPeriod eingeführt:

Die Bitmaske der mit dayOffset≠0 anzugebenden operatingPeriods ist nicht verschoben darzustellen, d. h. die Bitmaske ist identisch wie beim Fall dayOffset=0. Grundsätzlich besteht die an sich gleichwertige Möglichkeit, in den betreffenden Fällen anstatt dayOffset>0 weiterhin mit arrival/departureDay>0 auch am ersten Bahnhof zu beginnen. Ein lesendes Programm sollte beide Varianten verarbeiten können. Die Variante mit dayOffset>0 ist vorgesehen für Fälle, in denen departureDay=0 am ersten Bahnhof aus externen Gründen erzwungen werden muss. Letzteres ist allerdings auch die Empfehlung des RailMLKonsortiums.

© iRFP

Seite 20

Stand: 08.12.2014

RailML®-Schnittstelle Primärschlüssel von Zügen, Mehrfachzugläufe, Ergänzungsfahrpläne

Primärschlüssel von Zügen, Mehrfachzugläufe, Ergänzungsfahrpläne Aus verschiedenen Gründen ist in der Eisenbahnwelt ein Mehrfachverwenden von Zugnummern üblich. In einigen Fällen ist es z. B. organisatorisch nicht gewünscht, z. B. bei geringen Differenzen zweier Lagen eines Zuges zwei unterschiedliche Zugnummern zu verwenden. Gleichzeitig müssen mit zunehmender Verbreitung und konsequenterem Einsatz von Rechentechnik früher intuitiv gehandhabte Zusammenhänge heute „informatorisch sauber“ abgebildet werden – Züge benötigen einen rechentechnisch eindeutigen Primärschlüssel. Innerhalb einer RailML-Datei enthält das Attribut id einen eindeutigen Primärschlüssel, welcher aber ausdrücklich nicht zur allgemeinen Verwendung außerhalb der RailML-Datei vorgesehen ist. Die Zugnummer ist jedoch aus o. g. Gründen ebensowenig als Primärschlüssel geeignet. Der externe Primärschlüssel muss daher i. d. R. aus mehreren Feldern zusammengefasst werden. Um dies zu erleichtern, unterstützt RailML die Attribute scope und additionalTrainNumber. Das Wertetripel aus trainNumber, scope und additionalTrainNumber muss immer eindeutig sein, d. h. ist grundsätzlich als externer Primärschlüssel geeignet. Durch das Attribut scope werden mehrere Züge mit gleicher Zugnummer (die disjunkte Verkehrstage haben müssen) unterschieden. Man kann diese auch als alternative zeitliche Lagen oder „Varianten“ ein und desselben Zuges auffassen. Das Attribut additionalTrainNumber dient der Unterscheidung von Einträgen mit gleicher Zugnummer und gleichem scope-Attribut. In Anwendungsfällen, in denen die Zugnummer selbst immer eindeutig ist, haben scope und additionalTrainNumber keine Bedeutung; hier ist immer scope=primary. Den terminologischen Zusammenhang zwischen RailML-Bezeichnungen, FBS-Bezeichnungen und Bezeichnungen der DB Netz AG gibt folgende Tabelle wieder: in RailML train.scope

in FBS Mehrfachzuglauf

train.scope=primary

Hauptlauf (mit Index=1)

train.scope=secondaryStart train.scope=secondaryEnd train.scope=secondaryInner

Hauptlauf (mit Index>1) Vornebenlauf Nachnebenlauf Zwischennebenlauf

bei DB Netz „Ergänzungsfahrplan“ „Stammfahrplan" oder „Stammzug“ - nicht möglich „Startflügel“ „Zielflügel“ „Doppelfahrplan“

Im Allgemeinen gilt, dass es an einem Verkehrstag jede Zugnummer nur einmal geben darf. Daher müssen die Verkehrstage von Mehrfachzugläufen disjunkt sein. Weiterhin gilt praktisch in den meisten Fällen die Einschränkung, dass ein Zug-Primärschlüssel (o. g. Wertetripel) an einem Verkehrstag und einer Betriebsstelle nur einmal vorkommen darf. Daher muss ein Zuglauf i. d. R. auf Mehrfachzugläufe aufgeteilt werden, sobald er an einer Betriebsstelle mehrfach vorbeikommt. Dies ist jedoch eine praktische Forderung z. B. aus sicherungstechnischen Gründen und derzeit keine RailML-Anforderung. Anmerkung: In den folgenden Beispielen sind vereinfachend nur zeitliche Abweichungen der Mehrfachzugläufe bei gleicher Strecke gezeigt. Ebenso sind jedoch auch räumliche Abweichungen (andere Laufwege / Strecken) möglich.

© iRFP

Seite 21

Stand: 08.12.2014

RailML®-Schnittstelle Primärschlüssel von Zügen, Mehrfachzugläufe, Ergänzungsfahrpläne

typisches Beispiel für „Nachnebenlauf“:

Abbildungsmöglichkeiten:

RB 8765 Hauptlauf: - verkehrt täglich im Abschnitt A-B - verkehrt Sa+S im Abschnitt B-C RB 8765 Nachnebenlauf: - verkehrt nur im Abschnitt B-C und nur an W[Sa] oder: RB 8765 Hauptlauf: - verkehrt täglich im Abschnitt A-B - verkehrt W[Sa] im Abschnitt B-C RB 8765 Nachnebenlauf: - verkehrt nur im Abschnitt B-C und nur an Sa+S oder:

RB 8765 1. Hauptlauf verkehrt W[Sa] A-B-C RB 8765 2. Hauptlauf verkehrt Sa+S A-B-C - beide Hauptläufe überlagern sich im Abschnitt A-B

© iRFP

Seite 22

Stand: 08.12.2014

RailML®-Schnittstelle Primärschlüssel von Zügen, Mehrfachzugläufe, Ergänzungsfahrpläne

typisches Beispiel für „Vornebenlauf“:

Abbildungsmöglichkeiten:

RE 4503 Hauptlauf: - verkehrt Mo-Fr im Abschnitt C-B - verkehrt täglich im Abschnitt B-A RE 4503 Vornebenlauf: - verkehrt nur im Abschnitt C-B und nur an Sa+So oder: RE 4503 Hauptlauf: - verkehrt Sa+So im Abschnitt C-B - verkehrt täglich im Abschnitt B-A RE 4503 Vornebenlauf: - verkehrt nur im Abschnitt C-B und nur an Mo-Fr oder:

RE 4503 1. Hauptlauf verkehrt Mo-Fr C-B-A RE 4503 2. Hauptlauf verkehrt Sa+So C-B-A - beide Hauptläufe überlagern sich im Abschnitt B-A

© iRFP

Seite 23

Stand: 08.12.2014

RailML®-Schnittstelle Primärschlüssel von Zügen, Mehrfachzugläufe, Ergänzungsfahrpläne

typisches Beispiel für „Zwischennebenlauf“:

Abbildungsmöglichkeiten:

RE 4503 Hauptlauf: - verkehrt täglich im Abschnitt D-C - verkehrt Mo-Fr im Abschnitt C-B - verkehrt täglich im Abschnitt B-A RE 4503 Zwischennebenlauf: - verkehrt nur im Abschnitt C-B und nur an Sa+So oder: wie oben, jedoch Hauptlauf und Zwischennebenlauf im Abschnitt C-B getauscht oder:

RE 4503 1. Hauptlauf verkehrt Mo-Fr D-A RE 4503 2. Hauptlauf verkehrt Sa+So D-A - beide Hauptläufe überlagern sich in den Abschnitten D-C und B-A

© iRFP

Seite 24

Stand: 08.12.2014

RailML®-Schnittstelle Umlaufpläne

Umlaufpläne In RailML sind offene und geschlossene Umläufe möglich. Geschlossene Umläufe können (theoretisch beliebig oft) wiederholt werden, da auf die letzte Fahrt im Umlauf wieder die erste Fahrt folgt. Offene Umläufe hingegen müssen nicht wiederholt werden können - bei ihnen folgt auf die letzte Fahrt entweder ein anderer Umlaufplan oder das Ende der Fahrplanperiode. Typischer Weise sind geschlossene Umläufe solche in einem Grund- oder Regelumlaufplan und offene Umläufe solche in einem Sonderumlaufplan. Im Allgemeinen kann man davon ausgehen, dass geschlossene Umläufe über einen längeren Zeitraum gelten (daher die Wiederholung, um nicht jeden Tag des längeren Zeitraums individuell abzubilden), während offene Umläufe über einen kürzeren Zeitraum gelten, in dem keine Wiederholungen möglich oder notwendig sind. Eine typische Zeitgrenze ist eine Woche, denn spätestens nach einer Woche sind Umlaufwiederholungen üblich. Offene Umläufe sind daher meist (fast immer) kürzer als eine Woche. Wichtig für RailML ist, dass auf Grund der Möglichkeit offener Umläufe zu bestimmten Fahrten keine nachfolgende Fahrten angegeben sind. Zur begrifflichen Eindeutigkeit werden im Folgenden als offene Umlaufpläne solche bezeichnet, bei denen nicht an allen Fahrten eine Folgefahrt angegeben ist. Geschlossene Umläufe sind demzufolge solche, bei denen an allen Fahrten eine Folgefahrt angegeben ist - ungeachtet ihrer Gültigkeitsdauer und der Frage, ob sie tatsächlich wiederholt werden sollen.

Beispiel für offene und geschlossene Umläufe: Der durch blaue Zyklen symbolisierte Regeloder Basisumlauf ist geschlossen, d. h. wiederholt sich theoretisch recht häufig. Er wird gelegentlich durch Sonderumläufe ersetzt/überschrieben, die teilweise geschlossen sind (mit Wiederholungen: hier Winterferien, Bauarbeiten, Ostern) und teilweise offen (ohne Wiederholung: hier Weihnachten, Maifeiertag). Ein Umlaufplan kann mehrere Umlaufgruppen enthalten. Umlaufgruppen sind eine Eigenart insbesondere von Eisenbahn-Umlaufplänen: Jede Umlaufgruppe stellt für sich einen eigentlichen Umlauf dar; daher kann es sein, dass in anderen terminologischen Zusammenhängen das als Umlauf bezeichnet wird, was in der (deutschsprachigen) Eisenbahn-Fachwelt nur eine Umlaufgruppe ist. Jede Umlaufgruppe könnte theoretisch in einem eigenen Umlaufplan abgebildet werden. Dies wird in der Praxis aber oft so nicht vorgenommen, weil man u. U. bemüht ist, alle Fahrzeuge einer Baureihe in einem Umlaufplan darzustellen. Beispiel: Auf einer einfachen Strecke pendeln zwei Triebwagen. Sie fahren immer an beiden Streckenenden gleichzeitig ab, begegnen sich in der Mitte und kommen gleichzeitig am anderen Ende an. Die Fahrtenanzahl je Richtung ist gerade, also jeder Triebwagen fährt 10x hin und 10x zurück. Damit kommt jeder am Abend wieder dort an, wo er früh begonnen hat. Macht man jetzt einen Umlaufplan für die Triebwagen, bekommt man eigentlich zwangsläufig zwei Umläufe (für jeden Triebwagen einen – sie können ja nie die rollen tauschen). Der klassische Eisenbahner sagt aber trotzdem „Umlauf Baureihe soundso“ dazu und behauptet, dass das ein Umlauf wäre, obwohl es informatorisch eher zwei sind. © iRFP

Seite 25

Stand: 08.12.2014

RailML®-Schnittstelle Umlaufpläne

Gruppe 1

Gruppe 2 Umlaufplan-Beispiel 1 Der einfachste offene Umlauf könnte theoretisch aus nur einer Fahrt bestehen, wobei sich dann allerdings die zumindest philosophische Frage stellt, ob das wirklich ein Umlauf ist. Der einfachste geschlossene Umlauf sollte mindestens zwei Fahrten haben, sofern wir Züge, die im Kreis fahren, einmal ausschließen wollen. Umlaufpläne von Eisenbahnen sind oft komplex; so ist es auch ihre Darstellung in RailML. Daher ist es gar nicht so einfach, ein einfaches Beispiel und übersichtlich darstellbares zu finden... Um also zunächst mit dem nahezu einfachsten vorstellbaren Umlaufplan beginnen zu können, gehen wir in der Geschichte noch einmal etwas zurück:

Der folgende RailML-Auszug ist vollständig; er wird nur zum Kommentieren unterbrochen. Das RailML-Element rostering definiert einen Umlaufplan für eine Fahrzeugbaureihe (welche über vehicleRef oder formationRef referenziert wird).

Das RailML-Element blockPart enthält einen Einsatz (eine Fahrt oder ein sonstiger Einsatz – z. B. Tanken, Wartung, Rangieren, Vorheizen usw.).

© iRFP

Seite 26

Stand: 08.12.2014

RailML®-Schnittstelle Umlaufpläne

Es sind folgende Ausprägungen von blockPart vorgesehen:  Fahrt als Referenz auf einen Zugteil: mission=timetable; trainPartRef ist anzugeben; die übrigen Attribute (startOcpRef, endOcpRef, begin, end, runLength) sind redundant zu den gleichbedeutenden Eigenschaften der Zugteile bei deren Definition in der RailML-Datei. Das Wiederholen dieser Attribute ist optional; sofern sie wiederholt werden, müssen sie widerspruchsfrei sein.  Fahrt ohne Referenz auf einen Zugteil: mission=fullRun oder emptyRun; trainPartRef darf nicht angegeben sein, startOcpRef, endOcpRef, begin und end müssen angegeben sein.  Dienst (der keine Fahrt ist): mission =shunting (Rangierdienst) =maintenance (Wartungsdienst) =standBy (Bereitschafts- und Reservedienst) =preheating (Vorheizdienst) =refuel (Auffüllen von Vorräten, Tanken usw.)

trainPartRef darf nicht angegeben sein, startOcpRef, endOcpRef, begin und end müssen angegeben sein, startOcpRef= endOcpRef. Im obigen Beispiel bilden die ersten beiden blockParts den Zug 67081; die Trennung beider ist in der Umlauf-Grafik nicht sichtbar. Der dritte blockPart bildet den Zug 67080. Dienste sind in diesem Beispiel nicht enthalten. Das RailML-Element block verkettet blockParts zu (willkürlichen) Abfolgen, die z. B. den üblicherweise in den Umlaufgrafiken dargestellten Blöcken entsprechen. Hier wird ersichtlich, dass der Zug(=Block) 67081 aus zwei blockParts zusammengesetzt ist, der Zug 67080 nur aus einem:

Das RailML-Element circulaiton definiert die Reihenfolge der „Blöcke“ in Bezug auf Verkehrstage über operatingPeriodRef. Es ist je ein circulation-Element für jeden Block an jedem Umlauftag enthalten. Durch die Attribute nextBlockRef und nextOperatingPeriodRef jedes circulation-Elements ergibt sich die Verkettung der Blöcke und damit die eigentliche Umlaufabfolge. Das Attribut operatingPeriodRef jedes circulation-Elements gibt über den Inhalt der referenzierten Verkehrstageregelung (indirekt) an, ob und wie oft ein Umlauftag wiederholt werden muss, um die gesamte Gültigkeit des Umlaufplans abzudecken.


Das erste circulation-Element (bl_67081/opp_9) verweist als Nachfolger auf das zweite Element bl_67080/opp_9. Die Wertepaarung blockRef/operatingPeriodRef stellt einen Primärschlüssel innerhalb der circulations-Liste dar, so dass über den Verweis nextblockRef/nextoperatingPeriodRef immer eindeutig ein Ziel gefunden werden kann. Da das Verweisziel des zweiten Elements (bl_67080/opp_9) wieder das erste ist, ist der Umlauf damit bereits vollständig und geschlossen. © iRFP

Seite 27

Stand: 08.12.2014

RailML®-Schnittstelle Umlaufpläne

Würde das letzte circulation-Element keinen Nachfolger definieren (nextblockRef/nextoperatingPeriodRef sind nicht angegeben), würde es sich um einen offenen Umlauf handeln. Damit die beiden Züge täglich diesen Umlaufplan fahren, müsste in diesem Beispiel die operatingPeriod opp_9 als täglich definiert sein. Falls opp_9 nur einen einzigen Tag definiert, würde der Umlauf auch nur an einem Tag gelten. Im konkreten Beispiel zeigte opp_9 auf die Verkehrstageregelung „W[Sa]“ (=Mo-Fr, außer Feiertags) bei Bedarf, woraus folgte, dass das Fahrzeug an Sa+S zumindest durch diesen Umlauf nicht beansprucht wurde. Die Umlauf-Abfolge von z. B. fünf Wochentagen Mo-Fr ließe sich auch durch Aufzählen der fünf Tage abbilden, was gleichbedeutend mit obigem Beispiel wäre:

Sofern mehr als ein circulation-Element für einen Block existiert, müssen die circulationElemente für diesen Block bezüglich der Verkehrstage disjunkt sein.

Umlaufplan-Beispiel 2 Hier noch ein zusammenhängendes Beispiel mit ein paar mehr Fahrten und mit eingeschobenem Dienst (wobei der Umlauf immernoch „Züge“ von Trivialität hat, wenn es von der „Baureihe“ nur ein einziges Exemplar gibt):

© iRFP

Seite 28

Stand: 08.12.2014

RailML®-Schnittstelle Umlaufpläne

© iRFP

Seite 29

Stand: 08.12.2014

RailML®-Schnittstelle Kopfinformationen (Dublin Core Metadata Element Set)

Kopfinformationen (Dublin Core Metadata Element Set) Die folgende Beschreibung enthält eine Empfehlung für die Verwendung des Dublin Core (DC) Metadata Element Set aus rail:metadata (am Anfang der RailML-Datei). Momentan ist es nicht zwingend erforderlich, die DC-Elemente in der hier beschriebenen Art zu verwenden. Da es aber dem Datenaustausch nicht dienlich ist, gleiche Attribute mit verschiedenen Bedeutungen zu verwenden, wird die hier beschriebene Anwendung dringend empfohlen. 2.0.3 1 1252 (ANSI - Lateinisch I) iPLAN.exe V1.2.0.528 NtzIntf_RailML2.dll V2.0.4.23 2012-03-01T11:14:59 iRFP

Das Attribut railml.version soll die „Nenn-Version“ enthalten, unter der die RailMLSchemendateien veröffentlicht wurden. Typische Werte sind derzeit 2.0, 2.1 und 2.2. Im Dublin Core Metadata Element Set (Namensraum „dc:“, Struktur railml.metadata) lassen sich implementierungsabhängige Versionsnummern und andere Kopfinformationen unterbringen. Das Attribut metadata.format enthält die interne Versionsnummer der SchemenAusprägung (auch RailML-Profil genannt). Diese Versionsnummer ändert sich dann, wenn sich die Interpretation oder die Vollständigkeit der Umsetzung des RailML-Schemas durch die schreibende Software ändert. Ein lesendes Programm sollte prüfen, dass diese Versionsnummer nicht niedriger ist als die Version, mit der das Programm frühestens getestet wurde. Insbesondere kann hiermit vom lesenden Programm einfach geprüft werden, ob bestimmte Daten vorhanden sein werden, die notwendig sind für das lesende Programm, in RailML als optional gekennzeichnet sind, in der konkreten Schemeninstanz obligatorisch sind. Es ist Sache der Programmierung der schreibenden Software, die Werte für metadata.format festzulegen. Diese Werte sind daher nur im Zusammenhang mit metadata.source interpretierbar. Es wird empfohlen, sich dabei an der zugrunde liegenden RailML-Schemenversion zu orientieren. (Im obigen Beispiel: Instanz Nr. 3 von RailML 2.0.) Außerdem ist es Aufgabe der schreibenden Programmierung, nur eindeutige Werte von metadata.format innerhalb eines Wertes metadata.source zuzulassen. Das Attribut metadata.identifier enthält eine Kompatibilitätsnummer als einfachen IntegerWert. Diese Nummer wird nur dann geändert, wenn ein bestehender Datenwert (Attribut oder Element) nachträglich uminterpretiert wird (z. B. in Folge einer Fehlerkorrektur). Ein lesendes Programm sollte dieses Attribut auf exakt den erwarteten Wert prüfen – sonst läuft es Gefahr, dass die auszuwertenden Datenfelder nicht mehr den erwarteten Inhalt enthalten. Beispielsweise könnte ein Geschwindigkeitsfeld bis zu einem bestimmten Zeitpunkt die Geschwindigkeit in km/h enthalten. Es sei angenommen, dass sich das nachträglich als nicht RailML-konform herausstellte. Um die RailML-Konformität wiederherzustellen, müsste des Geschwindigkeitsfeld nachträglich – ohne umbenannt zu werden – auf die Einheit m/s umgestellt werden. In diesem Falle würde metadata.identifier um eins weitergezählt werden, um lesende, nicht aktualisierte Programme davon abzuhalten, den neuen Wert als km/h einzulesen.

© iRFP

Seite 30

Stand: 08.12.2014

RailML®-Schnittstelle Kopfinformationen (Dublin Core Metadata Element Set)

Das Attribut metadata.identifier wird nicht aktualisiert, wenn neue Daten hinzukommen, was es von metadata.format unterscheidet. Es wird erwartet, dass sich metadata.identifier im Gegensatz zu metadata.format nur sehr selten ändert. Das Attribut metadata.source enthält eine Zeichenkette, die eindeutig das schreibende Programm identifiziert. Optionale Versionsnummern können der Fehleranalyse dienen. Das Attribut metadata.language enthält Nummer und (optional) Namen des Zeichensatzes, in dem die Daten im schreibenden Programm vorliegen. Dieser Wert kann z. B. von Bedeutung sein, wenn die in der RailML-Datei enthaltenen UTF-8-Zeichenketten (Bahnhofsnamen usw.) vom lesenden Programm in eine Nicht-Unicode-Zeichenkette umgewandelt werden müssen. Dieser Wert ist nicht zu verwechseln mit , welcher die Codierung der RailML-Datei und damit aller enthaltener Zeichen definiert. Da eine RailML-Datei normalerweise im Zeichensatz UTF-8 codiert ist, ist der Wert metadata.language zum reinen Auslesen der RailML-Datei nicht notwendig. Er ist nur von Bedeutung, wenn die Eigennamen aus der RailML-Datei im Zielprogramm in Nicht-Unicode-Zeichensätze umgewandelt werden müssen. Ein lesendes Programm soll hier nicht erst alle Eigennamen auf eventuell vorhandene Umlaute „scannen“ müssen, um sich auf eher empirische Weise für einen Zeichensatz zu entscheiden. Vielmehr soll das schreibende Programm – wannimmer möglich – quasi die Herkunft oder Zugehörigkeit der Namen zu einer Sprache angeben. Beispielsweise wäre im Falle von 1253 (ANSI - Greek) für ein lesendes Programm ohne diese Angabe erst durch Feststellen eigenartig hoher Unicode(UTF-8-)Werte in den Eigennamen feststellbar, dass es sich offensichtlich um griechische Namen handelt. Sofern ein schreibendes Programm die geografische Zuordnung der Namen nicht feststellen kann, soll es metadata.language auslassen. metadata.language soll als erste Zeichen – bis zu einem trennenden Leerzeichen – die Code-Seite (Codepage) des Zeichensatzes als dezimalen Zahlenwert enthalten. Danach kann optional der Name der Codepage angegeben werden. Das Attribut metadata.date enthält optional Datum und Uhrzeit des Exports (des Erzeugens der RailML-Datei) im xs:dateTime-Format. Das Attribut metadata.creator enthält optional den Anwender- oder Lizenznamen des Anwenders, der die Datei erzeugt hat (z. B. Anmeldename am Betriebssystem oder Firmenname, auf den die Programmlizenz ausgestellt ist.)

© iRFP

Seite 31

Stand: 08.12.2014