Fahrplan: EVU-Schnittstelle

Abrechnungsregelungen sind grundsätzlich nicht Gegenstand dieser Dokumentation. Es gelten hierfür die Festlegungen in den NBN und zum Trassenpreissystem.

Abrechnungsregelungen sind grundsätzlich nicht Gegenstand dieser Dokumentation. Es gelten hierfür die Festlegungen in den NBN und zum Trassenpreissystem.

Die Anzahl der insgesamt über die Schnittstelle auszutauschenden Nachrichten erhöht sich vor allem dadurch, dass zukünftig jede empfangene Nachricht mit einer ReceiptConfirmationMessage und jede PathConfirmedMessage durch eine weitere PathDetailsMessage für die Buchungsbestätigung quittiert werden muss. Eine weitere Mehrung entsteht auch bei allen netzausgelösten Änderungen durch das vorherige Versenden einer PathNotAvailableMessage. Da diese Abfolgen verpflichtend sind, ergeben sich keine Reduzierungsmöglichkeiten. 

Eine Mehrung der Trassenbestellungen ist ebenfalls durch den Entfall der verkehrstageabhängigen Angaben im Laufweg einer Fahrlage zu erwarten. Dem entgegen steht eine Reduzierung durch den Entfall der heute notwendigen Aufsplittung einer Trassenbestellung für einen Zug in mehrere Zeitscheiben, z. B. bei bereits in der Bestellung oder Bearbeitung des Netzfahrplans berücksichtigbarer Baumaßnahmen, die derzeit nicht als Ergänzungsfahrplan bestellt  werden können. Insgesamt gehen wir von einer Mehrung bei den Trassenbestellungen von max. 15% im Vergleich zum Status quo aus, die uns aber beherrschbar erscheint. Bei der Anzahl der Trassen wird der prognostizierte Zuwachs wesentlich geringer ausfallen. Die genannten Mehrungen resultieren aus den Vorgaben der Objektdefinitionen und Messagestrukturen durch TAF/TAP-TSI, so dass auch hier keine Maßnahmen zur Reduzierung der Datenmengen möglich sind.

Die Entscheidung zur Bestellung eines Zuges mit mehreren PathRequests (=Fahrlagen) oder mehrerer Züge mit jeweils nur einem PathRequest liegt beim anmeldenden Zugangsberechtigten. In Abhängigkeit davon können durch die Zugangsberechtigten in einer PathRequestMessage Referenzierungen auf die jeweiligen Züge oder PathRequests, für die eine gleiche oder ähnliche Trassierung gewünscht wird, durch Angabe der TrainID bzw. PathRequestID im Attribut RelatedPlannedTransportID mit Angabe des ReasonOfReference-Codes 1000 oder 1001 erfolgen. Nur bei Angabe dieser Referenzierungen ist für die DB InfraGO AG zweifelsfrei eine  Zusammengehörigkeit der Züge oder PathRequests erkennbar und ggf. die Berücksichtigung für eine identische Trassenkonstruktion möglich.  Die Nutzung der ReasonOfReference-Codes setzt jedoch noch die Bestätigung des von der DB InfraGO AG eingereichten ChangeRequests durch die ERA voraus.

Eine ErrorMessage kann vom Empfänger einer Nachricht  verwendet  und an den Absender gesendet werden, wenn die empfangene Nachricht vom Empfänger auf Grund von Fehlern nicht verarbeitet werden kann. In der Regel handelt es sich dabei um Datenfehler, z. B. Verletzung des Datenschemas, fehlende Pflichtangaben, unzulässige Werte, falsches Format, fachlich unlogische Werte (z. B. nicht aufsteigende Fahrplanzeiten), ebenso um eine Verletzung der definierten Messageabfolge (auch fehlerhafte Verwendung der Codierungen für MessageStatus, TypeOfRequest, TypeOfInformation). Die ErrorMessage darf nicht verwendet werden zur Ablehnung eines Angebots, dafür ist ausschließlich die PathDetailsRefusedMessage zu nutzen.

Eine ErrorMessage wird vom Empfänger einer Nachricht an den Absender gesendet, wenn die empfangene Nachricht fehlerhaft ist. Dies kann unmittelbar nach dem Eingang der Nachricht als Ergebnis einer automatisiert ablaufenden fachlichen und technischen Eingangsprüfungen erfolgen, aber auch erst zu einem späteren Zeitpunkt nach Feststellung des Fehlers.

Die ReceiptConfirmationMessage wird vom Empfänger einer Nachricht an den Absender in allen Fällen gesendet, wenn die automatisiert ablaufenden fachlichen und technischen Eingangsprüfungen erfolgreich waren. Dies wird in der Regel sofort nach dem Eingang erfolgen. Die Nachricht gilt dann als empfangen. Im Negativfall erfolgt der Versand einer ErrorMessage. 

TAF/TAP-TSI kennt nur die Kommunikation über das CommonInterface als einzigen Kommunikationskanal. Die DB InfraGO bietet zusätzlich noch die Möglichkeit der Nutzung einer besonderen Clientoberfläche an. Zur Vermeidung von Dateninkonsistenzen, Parallelaktionen und Fehlleitungen von Rückmeldungen hat daher die DB InfraGO AG die Beibehaltung des gewählten Kommunikationswegs bis zum Abschluss des jeweiligen Basisprozesses vorgeschrieben. 

Der Koordinierungsprozess,  welcher die Kommunikation zwischen EIU und EIU betrifft, ist nicht Gegenstand dieser Dokumentation. Für den Fahrplanbestell- und -zuweisungsprozess erfolgt grundsätzlich nur eine Kommunikation zwischen dem Besteller (ResponsibleApplicant) und dem für die Fahrplanerstellung verantwortlichen EIU (in xsd: ResponsibleIM). In der Betriebsdurchführungsphase erfolgt grundsätzlich nur eine Kommunikation zwischen dem durchführenden EVU (ResponsibleRU) und dem für die Durchführung verantwortlichen EIU (ResponsibleIM).

Eine Betriebsstelle, die eine Fahrplanbearbeitungsgrenze (Handover-Point) ist, kann mehreren Strecken zugeordnet sein. Eine Netzgrenze hingegen ist immer eindeutig nur einer Strecke zugeordnet, die auf der sich anschließenden fremden Infrastruktur ihre Fortsetzung auch immer nur auf einer einzigen Strecke findet. Es gibt jedoch Fälle, bei denen  einer Fahrplanbearbeitungsgrenze mehrere Netzgrenzen, jeweils an unterschiedlichen Strecken, zugeordnet sind. Für das exakte Routing innerhalb der Betriebsstelle, die Fahrplanbearbeitungsgrenze ist, ist die Kenntnis des weiteren gewünschten Trassenverlaufs notwendig. Da es keine Verpflichtung für den anmeldenden Zugangsberechtigten zur Angabe weiterer Zuglaufpunkte im unmittelbaren Grenzbereich innerhalb der Struktur TrainInformation gibt, sieht die DB InfraGO AG die Angabe der Netzgrenze in der TrainInformation der PathRequestMessage vor, um Fehltrassierungen und unnötige Abstimmungen mit dem Nachbar-EIU zu reduzieren.

In vielen Fällen betreffen Änderungen nicht den gesamten Geltungszeitraum des Objekts oder der Verlinkung, sondern nur einen Zeitabschnitt. Es ist dann immer eine Aufsplittung der bestehenden Objekte erforderlich. Die Verwendung der OIM, ggf. in Kombination mit der ULM führt hierbei zu komplexen Messageabfolgen mit erhöhter Komplexität und zusätzlichen Referenzierungen sowie  höheren Anforderungen an die beteiligten Mitarbeiter. Ein Ziel der TAF/TAP-TSI ist jedoch gerade eine Reduzierung solcher Sachverhalte. In der Planungsphase, und nur um diese geht es in der vorliegenden Dokumentation, existiert für diese Änderungen ein allgemein akzeptierter und etablierter Prozess in Form des Modification-Prozesses. Aus unserer Sicht ist es nicht zielführend für den fachlichen Geschäftsfall Trassenänderung bzw. Änderung der Verlinkung mehrere Ausführungsmöglichkeiten und unterschiedliche Prozesse zuzulassen und diese in der IT zu implementieren.

Die Nutzung der OIM für Änderungen an Tagesobjekten bzw.  der ULM für Änderungen von Verlinkungen bei Tagesobjekten in der Operationphase hingegen ist jedoch sinnvoll, da  sich hier die Änderung auf den gesamten Geltungszeitraum (1 Tag) des Objektes auswirkt und keine Aufsplittung des Objekts erforderlich ist, wodurch komplexe Sachverhalte und Referenzierungen nicht auftreten können.

Primär dienen die neuen Identifikatoren TrainID und PathID zur eindeutigen Identifikation der Objekte Train bzw. Path, insbesondere für IT-technisch unterstützte Vorgänge. Für die manuelle Kommunikation wird die Zugnummer (OTN) auch weiterhin als Kommunikations- und Identifikationsmittel dienen. In einem PathRequest kann, sofern dem Zugangsberechtigten zuvor eine Zugnummer zugewiesen wurde, vom Zugangsberechtigten eine Zugnummer angegeben werden. Anderenfalls erfolgt eine Vergabe einer Zugnummer durch die DB InfraGO AG unmittelbar nach dem Eingang der PathRequestMessage. Diese ist vorläufig, identifiziert den Zug bzw. den oder die PathRequests und unterstützt alle manuellen Prozessschritte. Erst mit der Trassenzuweisung wird die Zugnummer endgültig und identifiziert einen konkreten Path gesamthaft oder auch nur auf einem Teilabschnitt und ebenso zeitlich und räumlich den Zug, der mit dem Path verlinkt ist. In der operativen Phase wird während der Durchführung der Zugfahrt im Betrieb die Zugnummer in ihrer Rolle als betriebliche Zugnummer neben TrainID und PathID zu einem führenden Identifikator der Zugtrasse.

Auch weiterhin werden den Zugangsberechtigten insbesondere für die Trassenanmeldungen zum Netzfahrplan oder für internationale Züge (UIC-Merkblatt 419 - 1&2) Zugnummern bzw. Zugnummernbereiche zugewiesen, die eigenverantwortlich von den Zugangsberechtigten genutzt werden können. Erfolgt keine Vorabzuweisung bestellt der Zugangsberechtigte seine Trasse ohne Angabe einer Zugnummer. In diesem Fall und insbesondere im kurzfristigen Gelegenheitsverkehr weist die DB InfraGO AG nach Eingang der Trassenanmeldung automatisch eine Zugnummer zu. Die durch der Zugangsberechtigte angegebene bzw. die durch die DB InfraGO AG nach Eingang der Trassenbestellung zugewiesene Zugnummer ist zunächst vorläufig, identifiziert den Zug bzw. den oder die PathRequests und unterstützt alle manuellen Prozessschritte. Erst mit der Trassenzuweisung wird die Zugnummer endgültig und identifiziert einen konkreten Path gesamthaft oder auch nur auf einem Teilabschnitt und ebenso zeitlich und räumlich den Zug, der mit dem Path verlinkt ist. Sofern es aus betrieblichen Gründen erforderlich ist, kann die DB InfraGO AG in Einzelfällen auch eine abweichende Zugnummer für die gesamte Trasse oder einen Teilabschnitt zuweisen.

Jede abweichende Trassierung (Abweichungen bei: Betriebsstellenfolge, Fahrplanzeiten, benutzter Strecke/Streckengleis,  Gleisangaben oder zusätzliche betriebliche Halte) bedingt einen neuen Path und somit eine weitere PathDetailsMessage zu einem PathRequest.

Nach der NBN (Ziffer 3.2.1.1 c) muss der anmeldende Zugangsberechtigte – sofern er eine internationale Gruppierung oder ein Spediteur ist – der DB InfraGO AG bereits bei der Anmeldung das den Verkehr tatsächlich durchführende EVU benennen. Ist der Zugangsberechtigte eine Behörde bzw. Aufgabenträger, so muss dieser bis Vorlage des endgültigen Netzfahrplan-Entwurfes der DB InfraGO AG anzeigen, welches EVU ab wann die Fahrten durchführen wird. Die Angabe des durchführenden EVU erfolgt am ersten konstruktionsrelevanten Zuglaufpunkt.

Sofern durch den anmeldenden Zugangsberechtigten (ResponsibleApplicant) ein Wechsel des durchführenden EVU (ResponsibleRU) innerhalb des Zuglaufs vorgesehen ist, so sind die betreffende Betriebsstelle als Interchange-Point und die ggf. erforderliche höhere Mindestaufenthaltszeit sowie die entsprechende TrainActivity  bereits mitzubestellen, damit dies bei der Trassierung berücksichtigt werden kann. Bei einer späteren Bestellung des Interchange-Points handelt es sich dann immer um eine Trassenänderung mit dem Risiko, dass der Trassenänderung nicht mehr entsprochen werden kann.

Mit dem Element "StartDate" im Identifier erfolgt die Kennzeichnung des aus dem Kalenderobjekt abgeleiteten Tagesobjekts. Das Tagesobjekt stellt nach dessen Ableitung ein eigenständiges Objekt dar. Die PathRequestMessage wird nur in der Planungsphase verwendet und enthält generell nur Kalenderobjekte. Eine Trassenbestellung für nur einen einzigen Verkehrstag enthält im Kalender eine ValidityPeriod für den Zeitraum eines Tages, die Bitleiste enthält genau einen Wert "1". Das Element "StartDate" im Identifier wird in diesem Fall nicht genutzt und bleibt leer.

Grundsätzlich ist der Nachweis der Funktionsfähigkeit aller Messageabfolgen sowohl für den Positiv- als auch für den Negativfall zu erbringen. Ein Indiz für den Umfang geben die Abbildungen 5 bis 14 in der Schnittstellendokumentation, die die möglichen Geschäftsvorfallabfolgen für die einzelnen Prozesse beinhalten. Zusätzlich dazu sind weitere, sehr vielfältige Testfälle durch Variation spezieller fachlicher Informationen denkbar, die bei Bedarf bilateral zu vereinbaren sind.

Zur Planung der Testarbeiten können wir heute noch keine konkreten Aussagen treffen. In welchem Umfang wir Testarbeiten und die dafür notwendigen Ressourcen planen müssen, können wir erst einschätzen, wenn uns bekannt ist, wie viele IT-Verfahren von Zugangsberechtigten Testbedarf anmelden. Wenn mehrere Zugangsberechtigte das gleiche IT-Verfahren eines Herstellers verwenden, erfolgen die Tests in der Regel mit dem Softwarehersteller und nicht mit den Zugangsberechtigten. Analog gilt das für Zugangsberechtigte, die ihre Kommunikation aus dem EVU-System über PCS abwickeln möchten. Hier wird die DB InfraGO AG ohnehin selbst Tests in der Kommunikation zwischen PCS und dem Bestellsystem der DB InfraGO AG vornehmen, so dass weitere Tests mit einzelnen Zugangsberechtigten nicht erforderlich sind. Erfahrungsgemäß ist die Dauer der Tests sehr stark abhängig von der Qualität der Software der Zugangsberechtigten. Empfehlenswert ist jedoch, den Beginn der Tests ca. 6 Monate vor Beginn der produktiven Nutzung einzuplanen.

In einer PathDetailsMessage, mit der eine gebuchte Trasse durch die DB InfraGO AG geändert werden soll, erfolgt die Angabe der unveränderten TrainID in der Struktur PlannedTransportIdentifier. Die PathID der bisher gebuchten Trasse, die durch die DB InfraGO AG mit dem netzausgelösten Angebot verändert werden soll, wird in der Struktur RelatedPlannedTransportIdentifier übergeben. Da bei netzausgelösten Angeboten  jedoch nie eine PathRequestMessage existiert, erfolgt auch keine Angabe einer PathRequestID.

Weiterentwicklungen und somit Änderungen an der EVU-Schnittstelle resultieren primär aus Änderungen der TAF/TAP-TSI xsd durch RailNetEurope (RNE). RNE sieht max. 2 Änderungen pro Jahr vor, sofern Bedarf dafür besteht. Alle Änderungen werden wir prüfen und bei Auswirkungen auf die in der EVU-Schnittstelle verwendeten Nachrichten den sich daraus ergebenden Anpassungsbedarf identifizieren und eine neue Versionen der Schnittstellendokumentation erarbeiten. 

Änderungen an Pflichtattributen in den von der DB InfraGO AG verwendeten Nachrichten werden selbstverständlich vollständig umgesetzt. Änderungen an optionalen Elementen werden wir nur berücksichtigen, wenn sie die von der DB InfraGO AG im Datenaustausch verwendeten Nachrichten betreffen und diese Änderungen für die Kommunikation zwischen den Zugangsberechtigten und der DB InfraGO AG relevant sind.