----

----

I Veröffentlichungsbedürftige Rechtsakte

----

VERORDNUNG (EG) Nr. 62/2006 DER KOMMISSION

vom 23. Dezember 2005

über die technische Spezifikation für die Interoperabilität (TSI) zum Teilsystem „Telematikanwendungen für den Güterverkehr“ des konventionellen transeuropäischen Eisenbahnsystems

(Text von Bedeutung für den EWR)

DIE KOMMISSION DER EUROPÄISCHEN GEMEINSCHAFTEN —

gestützt auf den Vertrag zur Gründung der Europäischen Gemeinschaft,

gestützt auf die Richtlinie 2001/16/EG des Europäischen Parlaments und des Rates vom 19. März 2001 über die Interoperabilität des konventionellen transeuropäischen Eisenbahnsystems (1), insbesondere auf Artikel 6 Absatz 1,

in Erwägung nachstehender Gründe:

HAT FOLGENDE VERORDNUNG ERLASSEN:

Artikel 1

Die technische Spezifikation für die Interoperabilität („TSI“) des Teilsystems „Telematikanwendungen für den Güterverkehr“ des konventionellen Bahnsystems gemäß Artikel 6 Absatz 1 der Richtlinie 2001/16/EG steht im Anhang dieser Verordnung.

Diese TSI gilt uneingeschränkt für die Infrastruktur und die Fahrzeuge des konventionellen transeuropäischen Eisenbahnsystems nach der Beschreibung in Anhang I der Richtlinie 2001/16/EG.

Artikel 2

Eisenbahnunternehmen und Infrastrukturbetreiber leisten spätestens sechs Monate nach Inkrafttreten dieser Verordnung einen Beitrag durch die Bereitstellung funktioneller und technischer Informationen über bestehende einzelne Telematikanwendungen für den Güterverkehr nach Abschnitt 2 des Anhangs.

Artikel 3

Die auf europäischer Ebene tätigen Fachverbände des Eisenbahnsektors nach Artikel 3 Absatz 2 der Verordnung (EG) Nr. 881/2004 erstellen für die beiliegende TSI einen strategischen europäischen Bereitstellungsplan nach den in Kapitel 7 des Anhangs dieser Verordnung angeführten Kriterien.

Sie übermitteln diesen strategischen Plan den anderen Mitgliedstaaten und der Kommission innerhalb eines Jahres nach Inkrafttreten dieser Verordnung.

Artikel 4

Die Gültigkeit der Bestimmungen der Entscheidung 2004/446/EG der Kommission zu den Eckwerten des konventionellen transeuropäischen Bahnsystems erlischt mit dem Inkrafttreten dieser Verordnung.

Artikel 5

Diese Verordnung tritt am Tag nach ihrer Veröffentlichung im Amtsblatt der Europäischen Union in Kraft.

Diese Verordnung ist in allen ihren Teilen verbindlich und gilt unmittelbar in jedem Mitgliedstaat.

Brüssel, den 23. Dezember 2005

Für die Kommission

Jacques BARROT

Vizepräsident

----

(1)ABl. L 110 vom 20.4.2001, S. 1. Richtlinie geändert durch die Richtlinie 2004/50/EG (ABl. L 164 vom 30.4.2004, S. 114). Berichtigung im ABl. L 220 vom 21.6.2004, S. 40.

(2)ABl. L 155 vom 30.4.2004, S. 1. Berichtigung im ABl. L 193 vom 1.6.2004, S. 1.

(3)ABl. L 235 vom 17.9.1996, S. 6, zuletzt geändert durch die Richtlinie 2004/50/EG.

(4)ABl. L 164 vom 30.4.2004. Berichtigung im ABl. L 220 vom 21.6.2004, S. 3.

----

ANHANG

Technische Spezifikation für die Interoperabilität (TSI) zum Teilsystem „Telematikanwendungen für den Güterverkehr“ des konventionellen transeuropäischen Eisenbahnsystems

INHALTSVERZEICHNIS:

TABELLEN:

Das konventionelle transeuropäische Bahnsystem

Technische Spezifikation für die Interoperabilität Teilsystem Telematikanwendungen für den Güterverkehr

1.   EINFÜHRUNG

1.1.   Technischer Anwendungsbereich

Die vorliegende TSI betrifft das Teilsystem Telematikanwendungen für den Güterverkehr, wie es in der Liste unter Punkt 1B im Anhang II zur Richtlinie 2001/16/EG aufgezeigt ist.

Voraussetzung für den kommerziellen Betrieb von Zügen, Wagen und Einheiten für den kombinierten Verkehr im transeuropäischen Eisenbahnnetz ist insbesondere ein effizienter Austausch an Informationen unter den verschiedenen Fahrwegbetreibern, Eisenbahnverkehrsunternehmen und anderen Dienstleistern. Von dieser Kompatibilität und Verknüpfung hängen das Leistungsniveau, die Sicherheit und die Qualität der angebotenen Verkehrsdienste sowie deren Kosten ab, und auf dieser Kompatibilität und Verknüpfung beruht vor allem die Interoperabilität des konventionellen transeuropäischen Eisenbahnsystems.

Die technische Spezifikation für die Interoperabilität wirkt sich auch auf die Bedingungen für die Inanspruchnahme der Eisenbahn durch die Benutzer aus. In diesem Kontext bezeichnet der Ausdruck Benutzer nicht nur die Infrastrukturbetreiber oder Eisenbahnverkehrsunternehmen, sondern auch alle anderen Dienstleister wie Waggongesellschaften, Gesellschaften des intermodalen Verkehrs und sogar Kunden.

Zu guter Letzt bietet die Interoperabilität des konventionellen Bahnsystems den Vorteil, die Bedingungen für eine größere Interoperabilität zwischen den Verkehrsträgern zu schaffen, insbesondere zwischen dem konventionellen Eisenbahntransport und dem kombinierten Schienentransport.

Diese TSI soll auch sicherstellen, dass dieser wirksame Informationsaustausch qualitativ und mengenmäßig jederzeit optimal an veränderte Anforderungen angepasst werden kann, so dass der Transportprozess so wirtschaftlich wie möglich bleibt und der Güterverkehr auf der Schiene seinen Marktanteil gegen einen immer schärferen Wettbewerb verteidigen kann.

All dies bedeutet die Schaffung oder die Verbesserung des konventionellen transeuropäischen Eisenbahnsystems für den konventionellen Schienengüterverkehr und für den kombinierten Güterverkehr. Dass eine solche Verbesserung des Schienenanteils des Güterverkehrsystems erforderlich ist, zeigt sich auch im Vergleich der kritischen Punkte (Schnittstellen zwischen den verschiedenen beteiligten Partnern) im Güterverkehr auf der Straße mit den kritischen Punkten im Güterverkehr auf der Schiene, wie es sich bereits aus dem vereinfachten Szenario in Anhang A Ziffer 5 Kapitel 1.1 ersehen lässt.

Das Ziel dieser TSI ist es, Transporte unter den Bedingungen der Einbeziehung einer großen Zahl von Schnittstellen mit Hilfe eines Informationsaustauschs auf Grundlage der Richtlinien 2001/14/EG (1) und 2001/16/EG des Europäischen Parlaments und des Rates zu managen.

Diese kurze Erklärung für den Anwendungsbereich der TSI Telematikanwendungen für den Güterverkehr zeigt auch den Unterschied zur TSI „Betrieb und Verkehrssteuerung“ für das konventionelle Bahnsystem. Die TSI „Betrieb und Verkehrssteuerung“ behandelt — insbesondere unter Sicherheitsaspekten — die Verfahren und die zugehörige gerätetechnische Ausstattung für den kohärenten Betrieb der verschiedenen strukturellen Teilsysteme, einschließlich insbesondere der Zugführung, der Planung und der Abwicklung des Verkehrsbetriebs, die definitionsgemäß zu den ursprünglichen Aufgaben eines Eisenbahnverkehrsunternehmens (EVU) gehören (siehe Kapitel 2.3: Übersicht über die Beschreibung des Teilsystems).

Die TSI „Telematikanwendungen für den Güterverkehr“ behandelt die Anwendungen für den Güterverkehr und das Management der Verknüpfungen mit anderen Verkehrsträgern, was bedeutet, dass sie sich zusätzlich zum reinen Betrieb von Zügen auf die Transportdienstleistungen eines EVU konzentriert. Aspekte der Sicherheit werden nur insoweit betrachtet, als die Existenz von Daten, z. B. falsche oder nicht aktuelle Werte, einen Einfluss auf den sicheren Betrieb eines Zuges haben können.

1.2.   Geografischer Anwendungsbereich

Der geografische Anwendungsbereich dieser TSI ist das konventionelle transeuropäische Bahnsystem, das in Anhang I der Richtlinie 2001/16/EG beschrieben ist. Die TSI gilt auch für das gesamte Güterverkehrs-Eisenbahnnetz aller Mitgliedstaaten der EU, allerdings mit der Einschränkung, dass die Anforderungen dieser TSI für Gütertransporte aus einem Drittland oder dorthin nicht obligatorisch sind.

1.3.   Inhalt dieser TSI

Gemäß Artikel 5 Absatz 3 der Richtlinie 2001/16/EG:

Darüber hinaus können gemäß Artikel 5 Absatz 5 für jede TSI Sonderfälle vorgesehen werden; sie sind in Kapitel 7.4: Sonderfälle

Schließlich umfasst diese TSI in Kapitel 4 (Beschreibung des Teilsystems) ebenfalls die geltenden Betriebs- und Wartungsvorschriften für den Anwendungsbereich, der in den oben stehenden Abschnitten 1.1 (Technischer Anwendungsbereich) und 1.2 (Geografischer Anwendungsbereich) genannt wird.

2.   DEFINITION DES TEILSYSTEMS/ANWENDUNGSBEREICH

2.1.   In der TSI behandelte Funktionen

Das Teilsystem Telematikanwendungen für den Güterverkehr ist in Anhang II der Richtlinie 2001/16/EG, Abschnitt 2.5 (b) definiert.

Es umfasst insbesondere:

2.2.   In der TSI nicht behandelte Funktionen

Abrechnungs- und Fakturierungssysteme für Kunden sowie solche Systeme für Abrechnung und Fakturierung zwischen verschiedenen Dienstleistern, wie zum Beispiel Eisenbahnverkehrsunternehmen oder Infrastrukturbetreibern, sind nicht im Umfang dieser TSI enthalten. Das Systemdesign, auf dem der Datenaustausch entsprechend Kapitel 4.2 (Funktionelle und technische Spezifikationen des Teilsystems) beruht, liefert jedoch die zur Abrechnung von Verkehrsleistungen benötigten Informationen.

Auch die langfristige Planung von Fahrplänen gehört nicht zum Umfang dieser TSI Telematikanwendungen für den Güterverkehr. Dennoch wird es an einigen Stellen Hinweise auf die Ergebnisse der langfristigen Planung geben, soweit eine Beziehung zum effizienten Informationsaustausch besteht, wie er für den Betrieb der Züge notwendig ist.

2.3.   Übersicht über die Beschreibung des Teilsystems

2.3.1.   Beteiligte Unternehmen

Diese TSI berücksichtigt die gegenwärtigen Dienstleister und die verschiedenen künftig möglichen Dienstleister im Güterverkehr wie zum Beispiel für (die Liste erhebt keinen Anspruch auf Vollständigkeit):

Einige Dienstleister sind explizit in den Richtlinien 2001/14/EG und 2001/16/EG definiert. Da beide Richtlinien berücksichtigt werden müssen, betrachtet die TSI insbesondere die Definition (siehe auch Anhang A: Glossar dieser TSI) für:

„‚Betreiber der Infrastruktur (IB)‘: Eine Einrichtung oder ein Unternehmen, die bzw. das insbesondere für die Einrichtung und Unterhaltung der Fahrwege der Eisenbahn zuständig ist. Dies kann auch den Betrieb der Steuerungs- und Sicherheitssysteme der Fahrwege einschließen. Mit den bei einem Netz oder einem Teilnetz wahrzunehmenden Aufgaben des Betreibers der Infrastruktur können verschiedene Einrichtungen oder Unternehmen betraut werden“

Ausgehend von dieser Definition betrachtet die TSI einen IB als Dienstleister für die Zuweisung der Fahrwege, für die Steuerung/Überwachung der Züge und für das zug-/trassenbezogene Meldewesen.

Entsprechend der Richtlinie 2001/14/EG ist die Einrichtung oder das Unternehmen, der bzw. dem der IB eine Zugtrasse zuweist, als Antragsteller definiert.

„‚Antragsteller‘ ein zugelassenes Eisenbahnverkehrsunternehmen und/oder eine internationale Gruppierung von Eisenbahnverkehrsunternehmen und — in Mitgliedstaaten, die eine solche Möglichkeit vorsehen — andere natürliche und/oder juristische Personen, die ein einzelwirtschaftliches oder gemeinwirtschaftliches Interesse am Erwerb von Fahrwegkapazität für die Durchführung eines Eisenbahnverkehrsdienstes in ihrem jeweiligen Hoheitsgebiet haben, wie Behörden im Rahmen der Verordnung (EWG) Nr. 1191/69, Verlader, Spediteure und Unternehmen im Rahmen des kombinierten Verkehrs;

Ein ‚Eisenbahnverkehrsunternehmen‘ (EVU) ist jedes nach geltendem Gemeinschaftsrecht zugelassene öffentlich-rechtliche oder private Unternehmen, dessen Haupttätigkeit im Erbringen von Eisenbahnverkehrsleistungen zur Beförderung von Gütern und/oder Personen besteht, wobei dieses Unternehmen die Traktion sicherstellen muss; dies schließt auch Unternehmen ein, die ausschließlich die Traktionsleistung erbringen.“

Ausgehend von dieser Definition betrachtet die TSI ein EVU als Dienstleister für den Betrieb von Zügen.

Hinsichtlich der Zuweisung von Zugtrassen für den Betrieb eines Zuges ist auch die Definition aus Artikel 13 der Richtlinie 2001/14/EG zu berücksichtigen:

„Die Fahrwegkapazität wird von einem Betreiber der Infrastruktur zugewiesen und kann nach der Zuweisung an einen Antragsteller von diesem nicht auf ein anderes Unternehmen oder einen anderen Verkehrsdienst übertragen werden. Jeder Handel mit Fahrwegkapazitäten ist verboten und führt zum Ausschluss von der weiteren Zuweisung von Fahrwegkapazitäten. Die Nutzung von Fahrwegkapazität durch ein Eisenbahnverkehrsunternehmen, das die Geschäfte eines Antragstellers wahrnimmt, der kein Eisenbahnverkehrsunternehmen ist, gilt nicht als Übertragung.“

Was die Szenarien der Kommunikation zwischen Infrastrukturbetreibern und Antragstellern in der Ausführungsphase eines Transports betrifft, brauchen nur der IB und das EVU berücksichtigt zu werden und nicht alle Arten von Antragstellern, was für die Planungsphase jedoch von Bedeutung sein kann. In der Ausführungsphase ist stets eine definierte Beziehung IB — EVU gegeben, für die der Meldungsaustausch und die Informationsspeicherung in dieser TSI spezifiziert sind. Die Definition eines Antragstellers und die sich daraus ergebenden Möglichkeiten der Fahrwegzuweisung bleiben hiervon unberührt.

Wie bereits erwähnt, müssen für einen Gütertransport verschiedene Dienste bereitgestellt werden. Einer ist zum Beispiel die Bereitstellung von Güterwagen. Dieser Dienst kann in Beziehung mit einem Fuhrparkbetreiber gesetzt werden. Wenn dieser Dienst für einen Transport zum Leistungsangebot eines EVU gehört, fungiert das EVU gleichzeitig als Fuhrparkbetreiber. Ein Fuhrparkbetreiber kann wiederum seine eigenen Wagen und/oder die Wagen eines anderen Halters (ein weiterer Dienstanbieter für Güterwagen) verwalten. Die Notwendigkeiten dieser Art Dienstleister sind berücksichtigt, unabhängig davon, ob die juristische Person des Fuhrparkbetreibers ein EVU ist oder nicht.

Diese TSI schafft keine neuen juristischen Personen und zwingt ein EVU nicht zur Einbindung externer Dienstleister für Dienste, die es selbst anbietet; aber sie benennt, soweit erforderlich, einen Dienst mit dem Namen eines entsprechenden Dienstleisters. Wenn der Dienst von einem EVU angeboten wird, fungiert das EVU als Dienstleister für diesen Dienst.

Bei der Berücksichtigung von Kundenbedürfnissen besteht einer der Dienste in der Organisation und dem Management der Transportstrecke entsprechend den Zusagen gegenüber dem Kunden. Dieser Dienst wird vom „Federführenden Eisenbahnverkehrsunternehmen“ (FEVU) erbracht. Das FEVU ist die alleinige Kontaktstelle für den Kunden. Wenn mehrere EVU an der Transportkette beteiligt sind, ist das FEVU auch für die Koordination mit den anderen EVU zuständig.

Dieser Dienst kann auch von einem Spediteur oder einem anderen Unternehmen übernommen werden.

Die Mitwirkung eines EVU als FEVU kann sich von einem Transportablauf zum anderen unterscheiden. Im kombinierten Verkehr kann die Verwaltung der Kapazität in Blockzügen und die Erstellung von Frachtbriefen in den Händen eines Intermodaldienstintegrators liegen, der dann der Kunde des FEVU sein könnte.

Der wichtigste Punkt ist jedoch, dass die EVU, die IB und alle anderen Dienstleister (im Sinne der obigen Definitionen) zusammenarbeiten müssen, sowohl im Rahmen einer Kooperation und/oder auch beim freien Netzzugang als auch durch effizienten Informationsaustausch, um dem Kunden nahtlose Dienste bieten zu können.

2.3.2.   Betrachtete Prozesse

Diese TSI für den Eisenbahngüterverkehr beschränkt sich laut Richtlinie 2001/16/EG auf IB und EVU/FEVU mit Bezug auf ihre direkten Kunden.

Bei der Ausführung der Dienstleistungen für den Güterverkehr beginnt die Tätigkeit eines FEVU im Hinblick auf eine Ladung mit dem Erhalt des Frachtbriefs von seinem Kunden und, zum Beispiel für Wagenladungen, mit dem Freigabezeitpunkt der Wagen. Das FEVU erstellt einen vorläufigen Tourenplan (aufgrund seiner Erfahrungen und/oder des Vertrags) für die Transportfahrt. Wenn das FEVU beabsichtigt, die Wagenladung in einem Zug im Rahmen des freien Netzzugangs (das FEVU betreibt den Zug über die gesamte Fahrt) selbst zu transportieren, ist der vorläufige Tourenplan per se auch der endgültige. Wenn das FEVU beabsichtigt, die Wagenladung in einen Zug einzustellen, der die Kooperation mit anderen EVU verlangt, muss es zunächst herausfinden, welche EVU zu kontaktieren sind und zu welcher Zeit ein Wechsel zwischen zwei benachbarten EVU erfolgen kann. Das FEVU erstellt dann die vorläufigen Beförderungsaufträge für jedes EVU als Teilformular des vollständigen Frachtbriefs. Die Beförderungsaufträge sind im Kapitel 4.2.1 (Frachtbriefdaten) spezifiziert.

Die angesprochenen EVU prüfen die Verfügbarkeit von Ressourcen für den Betrieb der Wagen und die Verfügbarkeit der Zugtrasse. Die Antworten von den verschiedenen EVU geben dem FEVU die Möglichkeit, den Tourenplan zu überarbeiten oder — vielleicht sogar bei anderen EVU — die Anfrage neu zu starten, bis der Tourenplan den Erfordernissen des Kunden gerecht wird.

Die EVU/FEVU müssen generell mindestens die Kompetenzen besitzen zum:

Die EVU/FEVU in ihrer Eigenschaft als „Antragsteller“ müssen (durch Verträge mit den IB) auch die benötigte Zugtrasse bereitstellen und den Zug auf ihrem jeweiligen Fahrtabschnitt betreiben. Für die Zugtrasse können sie bereits (in der Planungsphase) gebuchte Trassen verwenden, oder sie müssen bei den Infrastrukturbetreibern (IB) eine Ad-Hoc-Trasse für den jeweiligen Fahrtabschnitt, auf dem das EVU den Zug betreibt, beantragen. Im Anhang A Ziffer 5 Kapitel 1.2 wird ein Beispiel für das Szenario der Trassenanforderung gegeben.

Der Trassenbesitz ist auch für die Kommunikation zwischen EVU und IB während der Zugfahrt von Bedeutung. Die Kommunikation während der Zugfahrt zwischen EVU und IB muss immer auf der Zugnummer und der Trassennummer basieren, wobei der IB mit dem EVU kommuniziert, das die Zugtrasse auf seiner Infrastruktur gebucht hat (siehe auch Anhang A Index 5 Kapitel 1.2).

Falls ein EVU die gesamte Fahrt A-F anbietet (Offener Netzzugang durch ein EVU, keine anderen EVU beteiligt), kommuniziert jeder beteiligte IB direkt nur mit diesem EVU. Dieser „offene Netzzugang“ durch das EVU lässt sich realisieren, indem die Zugtrasse über einen „One-Stop-Shop (OSS)“ oder in einzelnen Abschnitten direkt bei den jeweiligen IB gebucht wird. Die TSI berücksichtigt beide Fälle, wie in Kapitel 4.2.2.1 (Beantragung einer Trasse) gezeigt wird.

Der Dialogprozess zwischen EVU und IB zur Einrichtung einer Zugtrasse für einen Güterzug ist in Kapitel 4.2.2 (Beantragung einer Trasse) definiert. Diese Funktion bezieht sich auf Artikel 23 Absatz 1 der Richtlinie 2001/14/EG. Nicht zum Dialogprozess gehören die Beantragung einer Zulassung für ein EVU, das seine Dienste gemäß Richtlinie 2001/13/EG des Europäischen Parlaments und des Rates (3) anbietet, die Zertifizierung gemäß Richtlinie 2001/14/EG und die Zugangsrechte gemäß Richtlinie 91/440/EWG des Rates (4).

Kapitel 4.2.3 (Zugvorbereitung) definiert den Informationsaustausch hinsichtlich der Zugbildung und des Verfahrens bei der Zugabfahrt. Der Datenaustausch während der Zugfahrt im Fall des Normalbetriebs ist in Kapitel 4.2.4 (Prognose zur Zugfahrt) beschrieben; die Meldungen für Ausnahmefälle sind in Kapitel 4.2.5 (Information über Verkehrsunterbrechung) definiert. Informationen zur Standortverfolgung der Züge sind in Kapitel 4.2.6 (Abfragen zum Zugstandort) definiert. Alle diese Meldungen werden zwischen EVU und IB ausgetauscht und basieren auf Zügen.

Für einen Kunden jedoch ist die wichtigste Information immer die voraussichtliche Ankunftszeit (PAZ) seiner Sendung. Eine PAZ lässt sich aus dem Informationsaustausch zwischen FEVU und IB (im Fall des offenen Zugangs) berechnen. Im Fall des Kooperationsmodus mit verschiedenen EVU lassen sich PAZ und ebenso die voraussichtlichen Wagenübergangszeiten (PÜZ) aus dem Meldungsaustausch zwischen EVU und IB und deren Weiterleitung von den EVU an das FEVU berechnen (Kapitel 4.2.7 Ladung PÜZ/PAZ).

Ebenfalls abgeleitet aus dem Informationsaustausch zwischen IB und EVU weiß das FEVU beispielsweise:

Abgeleitet nicht nur vom Datenaustausch zwischen IB und EVU, sondern auch vom Datenaustausch zwischen EVU und FEVU können verschiedene Statistiken erstellt werden:

Die Verwaltung leerer Wagen ist bei der Betrachtung interoperabler Wagen von besonderer Bedeutung. Im Prinzip gibt es keinen Unterschied zwischen der Verwaltung beladener und leerer Wagen. Der Transport leerer Wagen basiert ebenfalls auf Beförderungsaufträgen, wobei der Fuhrparkbetreiber für diese Wagen als Kunde zu betrachten ist.

2.3.3.   Allgemeine Anmerkungen

Ein Informationssystem ist nur so gut wie die Zuverlässigkeit seiner Daten. Daher müssen die Daten, die eine entscheidende Rolle beim Transport einer Sendung, eines Wagens oder eines Containers spielen, genau stimmen, und sie müssen möglichst wirtschaftlich erfasst werden, was bedeutet, dass die Daten möglichst nur ein einziges Mal in das System eingegeben werden sollten.

Auf dieser Grundlage vermeiden daher die Anwendungen und Meldungen in dieser TSI die mehrfache manuelle Dateneingabe, indem sie auf bereits gespeicherte Daten, z. B. auf die Fahrzeugreferenzdaten, zurückgreifen. Die Anforderungen an die Fahrzeugreferenzdaten sind in Kapitel 4.2.11 (Die Hauptreferenzdaten) definiert. Die spezifizierten Datenbanken der Fahrzeugreferenzdaten müssen einen einfachen Zugriff auf die technischen Daten gestatten. Der Inhalt der Datenbanken muss auf der Basis strukturierter Zugriffsrechte in Abhängigkeit von Privilegien für alle IB, EVU und Fuhrparkbetreiber zugänglich sein, insbesondere zum Zwecke des Flottenmanagements und der Fahrzeuginstandhaltung. Sie müssen alle transportkritischen technischen Daten enthalten, wie z. B.:

Im intermodalen Transport wird ein Wagen an verschiedenen Punkten (so genannten „Gateways“) nicht nur an einen anderen Zug gehängt, sondern die Intermodaleinheit kann auch von einem Wagen auf einen anderen umgeladen werden. Folglich reicht es nicht aus, nur mit einem Tourenplan für Wagen zu arbeiten, sondern es muss auch ein Tourenplan für die Intermodaleinheiten erstellt werden.

In Kapitel 4.2.12 (Diverse Referenzdateien und Datenbanken) sind diverse Referenzdateien und Datenbanken aufgeführt, darunter die Betriebsdatenbank für Wagen und Intermodaleinheiten. Diese Datenbank enthält die betrieblichen Statusdaten des Fahrzeugs, Informationen über Gewicht und über gefährliche Güter, Informationen bezüglich der Intermodaleinheiten und die Standortinformation. Im Kapitel 4.2.13 (Elektronische Übertragung von Dokumenten) sind die Anforderungen an die elektronische Übertragung der Dokumente definiert.

Die TSI für das Teilsystem Telematikanwendungen für den Güterverkehr definiert die benötigten Informationen, die zwischen den verschiedenen an der Transportkette beteiligten Partnern ausgetauscht werden müssen, und gestattet die Einrichtung eines standardisierten, verbindlichen Prozesses für den Datenaustausch. Sie zeigt außerdem die Architekturstrategie für eine solche Kommunikationsplattform. Dies ist in Kapitel 4.2.14 (Vernetzung und Kommunikation) skizziert, unter Berücksichtigung:

Es besteht keine direkte Datenübertragung aus dem Teilsystem Telematikanwendungen für den Güterverkehr in das Fahrzeug, zum Fahrer oder zu Teilen des Teilsystems „Zugsteuerung, Zugsicherung und Signalgebung“, und das physikalische Übertragungsnetz ist vollkommen unabhängig von dem, welches vom Teilsystem „Zugsteuerung, Zugsicherung und Signalgebung“ genutzt wird. Das ERTMS/ETCS-System benutzt GSM-R. Für dieses offene Netz stellen die ETCS-Spezifikationen klar, dass die Sicherheit mittels des entsprechenden Managements der Risiken bei offenen Netzen im Euroradio-Protokoll erreicht wird.

Die Schnittstellen zu den strukturellen Teilsystemen „Fahrzeug“ und „Zugsteuerung, Zugsicherung und Signalgebung“ sind nur über die Datenbanken der Fahrzeugreferenzdaten gegeben (Kapitel 4.2.11.3: Die Fahrzeugreferenzdatenbanken), welche der Kontrolle der Fahrzeughalter unterliegen. Die Schnittstellen zu den Teilsystemen „Infrastruktur“, „Zugsteuerung, Zugsicherung und Signalgebung“ und „Energie“ sind über die Festlegung der Trasse (Kapitel 4.2.2.3: Trassendetails) vom IB vorgegeben, womit die schienennetzbezogenen Werte für den Zug festgelegt sind, und über die Information, die die IB bezüglich Beschränkungen in der Infrastruktur bereitstellen (Kapitel 4.2.11.2: Die Datenbank für Mitteilungen der Infrastrukturbeschränkungen).

3.   GRUNDLEGENDE ANFORDERUNGEN

3.1.   Einhaltung der grundlegenden Anforderungen

Laut Artikel 4 Absatz 1 der Richtlinie 2001/16/EG müssen das konventionelle transeuropäische Eisenbahnsystem, die Teilsysteme und ihre Interoperabilitätskomponenten die grundlegenden Anforderungen, die in allgemeiner Form in Anhang III der Richtlinie dargestellt sind, einhalten.

Im Anwendungsbereich der vorliegenden TSI wird die Erfüllung der entsprechenden grundlegenden Anforderungen, die in Kapitel 3 dieser TSI genannt sind, für das Teilsystem durch die Einhaltung der in Kapitel 4 (Beschreibung des Teilsystems) beschriebenen Spezifikationen gewährleistet.

3.2.   Aspekte der grundlegenden Anforderungen

Die grundlegenden Anforderungen betreffen:

Laut Richtlinie 2001/16/EG treffen die grundlegenden Anforderungen allgemein für das gesamte konventionelle transeuropäische Eisenbahnsystem zu oder sind spezifisch für jedes Teilsystem und dessen Komponenten.

3.3.   Allgemeine Anforderungen

Die Bedeutung der grundlegenden Anforderungen für das Teilsystem Telematikanwendungen für den Güterverkehr ist wie folgt:

3.3.1.   Sicherheit

In Übereinstimmung mit Anhang III der Richtlinie 2001/16/EG sind die sicherheitsrelevanten grundlegenden Anforderungen, die für das Teilsystem Telematikanwendungen für den Güterverkehr gelten, die folgenden:

3.3.2.   Zuverlässigkeit und Betriebsbereitschaft

„Die Planung, Durchführung und Häufigkeit der Überwachung und Instandhaltung der festen und beweglichen Teile, die am Zugverkehr beteiligt sind, müssen deren Funktionsfähigkeit unter den vorgegebenen Bedingungen gewährleisten.“

Dieser grundlegenden Anforderung wird in den folgenden Kapiteln Rechnung getragen:

3.3.3.   Gesundheit

3.3.4.   Umweltschutz

3.3.5.   Technische Kompatibilität

3.4.   Besondere Anforderungen an das Teilsystem Telematikanwendungen für den Güterverkehr

3.4.1.   Technische Kompatibilität

3.4.2.   Zuverlässigkeit und Betriebsbereitschaft

3.4.3.   Gesundheit

3.4.4.   Sicherheit

4.   BESCHREIBUNG DES TEILSYSTEMS

4.1.   Einführung

Das konventionelle transeuropäische Eisenbahnsystem, für das die Richtlinie 2001/16/EG gilt und zu dem das Teilsystem gehört, ist ein integriertes System, dessen Einheitlichkeit geprüft werden muss. Diese Einheitlichkeit muss besonders in Bezug auf die Spezifikationen des Teilsystems, seine Schnittstellen mit dem System, in das es integriert wird, sowie die Betriebs- und Wartungsvorschriften geprüft werden.

Unter Berücksichtigung aller anwendbaren grundlegenden Anforderungen ist das Teilsystem Telematikanwendungen für den Güterverkehr gekennzeichnet durch:

4.2.   Funktionelle und technische Spezifikationen zum Teilsystem

Die funktionellen und technischen Spezifikationen sind im Hinblick auf die in Kapitel 3 angegebenen grundlegenden Anforderungen die Folgenden:

Die genauen Spezifikationen sind nachstehend beschrieben. Weitere Einzelheiten und die Formate der Meldungen sind in Anhang A Ziffer 1 definiert.

Allgemeine Anmerkungen zur Meldungsstruktur:

Die Meldungen sind in zwei Datengruppen strukturiert:

Die Kontrolldaten zeigen folgende Elemente auf:

In den folgenden Kapiteln wird hauptsächlich der Status „Neue Meldung“ betrachtet. Im Kapitel 4.2.2 (Beantragung einer Trasse) wird auch auf den Status „Löschung“ hinsichtlich der Meldung „Trassenantrag“ Bezug genommen.

4.2.1.   Frachtbriefdaten

4.2.1.1.   Frachtbrief des Kunden

Der Frachtbrief ist vom Kunden an das „Federführende EVU (FEVU)“ zu schicken. Er muss alle Informationen enthalten, die für den Transport der Fracht vom Absender zum Empfänger erforderlich sind. Das FEVU muss diese Daten um zusätzliche Angaben ergänzen. Diese Daten einschließlich der Zusatzangaben (ausführliche Beschreibung siehe Anhang A Index 3) sind in der Tabelle in Anhang A Index 3 aufgelistet. In der Spalte „Daten im Frachtbrief“ ist angegeben, ob es sich um obligatorische oder optionale Angaben handelt und ob diese vom Absender bereitzustellen oder vom FEVU zu ergänzen sind.

Im Fall des „offenen Netzzugangs“ stehen dem FEVU, das den Vertrag mit dem Kunden schließt, nach der Ergänzung alle erforderlichen Angaben zur Verfügung. Es ist kein Meldungsaustausch mit anderen EVU erforderlich. Diese Daten sind auch die Grundlage für einen kurzfristigen Trassenantrag, wenn dies zur Ausführung des Frachtauftrags erforderlich ist.

Die folgenden Meldungen gelten für den Fall des „nicht offenen Netzzugangs“. Der Inhalt dieser Meldungen ist auch die Basis für kurzfristige Trassenanträge, wenn dies zur Ausführung des Frachtauftrags erforderlich ist.

4.2.1.2.   Beförderungsaufträge

Der Beförderungsauftrag ist im Wesentlichen eine Teilmenge der Frachtbriefinformation. Er muss an die EVU, die an der Transportkette beteiligt sind, weitergeleitet werden, da er die Grundlage für einen eventuellen Ad-hoc-Trassenantrag bildet (Kapitel 4.2.2: Beantragung einer Trasse). Der Inhalt des Beförderungsauftrages muss alle relevanten Informationen umfassen, die ein EVU für den Transport unter seiner Verantwortung bis zur Übergabe auf das nächste EVU benötigt. Der Inhalt richtet sich daher nach der Rolle des EVU: Ursprungs-, Transit- oder Auslieferungs-EVU in der Transportkette (UEVU, TEVU, AEVU).

Die Daten der Beförderungsaufträge entsprechend den verschiedenen Rollen eines EVU sind im Einzelnen in Anhang A Ziffer 3 aufgelistet. Es ist jeweils angegeben, ob die Daten obligatorisch oder optional sind. Die ausführlichen Formate dieser Meldungen sind im Anhang A Index 1 definiert.

Hauptinhalt dieser Beförderungsaufträge sind:

Ausgewählte Frachtbriefdaten müssen auch für alle Partner (z. B. IB, Wagenhalter ...) in der Transportkette, einschließlich des Kunden, zugänglich sein. Hierzu gehören insbesondere pro Wagen:

4.2.2.   Beantragung einer Trasse

4.2.2.1.   Vorbemerkungen

Langfristige Planung

Die Zugtrasse definiert die beantragten, die akzeptierten und die tatsächlichen Daten, die bezüglich einer Zugtrasse und der Zugmerkmale auf den einzelnen Abschnitten einer Trasse zu speichern sind. Die folgende Beschreibung gibt die Informationen wieder, die dem Infrastrukturbetreiber zur Verfügung stehen müssen. Bezüglich einer ausführlicheren Beschreibung siehe Anhang A Ziffer 4.

Diese Informationen müssen bei jeder Veränderung aktualisiert werden.

Die wichtigsten Trassendaten sind (obligatorisch):

Ausführungsphase Trassenvertrag: Vor der Zugfahrt müssen die Daten des Fahrtabschnitts aktualisiert und mit Istwerten ergänzt werden. Die Ausführungsphase ist unabhängig von der Planungsphase.

Kurzfristiger Trassenantrag

Bei Ausnahmesituationen im Zugbetrieb oder kurzfristigen Transportwünschen muss ein Eisenbahnverkehrsunternehmen die Möglichkeit haben, eine Ad-hoc-Trasse im Netz zu erhalten.

Im ersten Fall müssen Sofortmaßnahmen eingeleitet werden, wobei die tatsächliche Zugkonfiguration aufgrund der Zugbildungsliste bekannt ist.

Im zweiten Fall muss das Eisenbahnverkehrsunternehmen dem Infrastrukturbetreiber alle notwendigen Informationen liefern, die angeben, wann und wo der Zug eingesetzt werden soll und über welche physischen Merkmale der Zug verfügt, sofern diese mit der Infrastruktur interagieren. Diese Daten sind hauptsächlich im ergänzten Frachtbrief beziehungsweise in den Beförderungsaufträgen enthalten.

Der Trassenvertrag für eine kurzfristige Zugbewegung beruht auf einem Dialog zwischen EVU und IB. Der Dialog schließt alle EVU und IB ein, die an der Zugbewegung entlang der gewünschten Strecke beteiligt sind, jedoch möglicherweise mit unterschiedlichen Beiträgen bei der Trassenfindung. Nach Artikel 13 der Richtlinie 2001/14/EG können im Wesentlichen zwei allgemein gültige Szenarien für den Güterverkehr auf den Infrastrukturen mehrerer IB unterschieden werden (siehe auch Anhang A Ziffer 5 Kapitel 1.3):

Bemerkung: Wie in Kapitel 2 (Definition des Teilsystems/Anwendungsbereich) erwähnt, kommuniziert der IB in der Ausführungsphase nur mit dem EVU, das die Trasse gebucht hat. Für den Meldungsaustausch unterwegs ist daher die „Trasseninhaberschaft“ von besonderer Bedeutung.

In beiden Szenarien verläuft das Buchungsverfahren für einen kurzfristig gestellten Trassenantrag entsprechend dem Dialog zwischen EVU und beteiligtem IB wie auf der nächsten Seite beschrieben.

Die folgende Tabelle zeigt die Meldungen, die im Dialog für einen Trassenantrag zu verwenden sind:

Tabelle 1

Beantragung einer Trasse

Dieser Dialog wird vom EVU entweder mit der Meldung „Trasse bestätigt“ oder mit Löschen des Trassenantrags beendet (Trassenantrag mit Status „Löschung“, siehe Kapitel 4.2: Funktionelle und technische Spezifikationen zum Teilsystem, Allgemeine Anmerkungen zur Meldungsstruktur). Eine Meldung „Trassendetails abgelehnt“ vom EVU muss immer mit einer erneuten Meldung „Trassendetails“ beantwortet werden. Wenn der IB den Trassenantrag nicht mit einem neuen Vorschlag innerhalb einer Meldung „Trassendetails“ bedienen kann, muss er die Meldung „Trassendetails“ mit der Kennung „Keine Alternativen verfügbar“ senden, womit der Dialog durch den IB beendet wird.

Ganz gleich, ob die Trasse während der langfristigen Planung oder kurzfristig gebucht wurde, das EVU muss stets die Möglichkeit haben, eine gebuchte Trasse zu stornieren. Hierzu muss die folgende Meldung verwendet werden.

Tabelle 2

Trassenstornierung durch das EVU

Aufgrund des Trassenvertrags kann ein EVU erwarten, dass eine gebuchte Trasse auch zur Verfügung steht. Wenn also etwas passiert und die gebuchte Trasse nicht mehr verfügbar ist, muss der IB das EVU unterrichten, sobald er Kenntnis von diesem Sachverhalt erhält. Ein Grund hierfür kann beispielsweise eine Unterbrechung des Fahrweges sein. Dies kann jederzeit zwischen dem Moment der Buchung der Trasse und der Abfahrt des Zuges geschehen. Der IB ist verpflichtet, die Meldung „Trasse nicht verfügbar“ zusammen mit einem Alternativvorschlag zu schicken. Wenn dies nicht möglich ist, muss der IB diesen Vorschlag so schnell wie möglich nachreichen. Mit der Meldung „Trasse nicht verfügbar“ initiiert der IB einen Dialog für einen neuen Trassenvertrag.

Meldungen im Dialog zum Stornieren einer gebuchten Trasse durch den IB.

Tabelle 3

Trassenstornierung durch den IB

Generell gilt: Wenn der Empfänger eines Antrags oder einer Anfrage nicht sofort antworten kann, muss er den Absender der Meldung hierüber unterrichten (zum Beispiel kann die Meldung „Trassendetails“ als Antwort auf einen Trassenantrag nicht sofort geschickt werden). Dies muss mit folgender Meldung geschehen:

Tabelle 4

Empfangsbestätigung

Diese Meldungen werden in den folgenden Abschnitten in ihren wichtigsten Punkten umrissen. Die ausführlichen Formate dieser Meldungen sind im Anhang A Ziffer 1 definiert. Die logische Abfolge dieser Meldungen ist aus den Diagrammen im Anhang A Ziffer 5 Kapitel 2.1 bis 2.3 ersichtlich.

4.2.2.2.   Trassenantrag

Dies ist der Antrag vom EVU an den IB für eine Zugtrasse. Solch ein Antrag muss enthalten:

Als Informationshilfe bei der Formulierung des Trassenantrags können die EVU die entsprechenden Schienennetz-Nutzungsbedingungen zu Rate ziehen, um zu überprüfen, ob die Daten des vorgesehenen Zuges mit den Infrastrukturdaten der gewünschten Trasse harmonieren. Dabei sind auch Angaben über Gefahrgüter und ähnliche Daten zu beachten.

Die Wagenhalter müssen den EVU Zugriff auf die technischen Daten der Wagen gewähren.

Die EVU ihrerseits müssen den Zugang zu den Referenzdateien, z. B. zur Referenzdatei für Gefahrgüter, sicherstellen.

4.2.2.3.   Trassendetails

Diese Meldung ist die Antwort eines IB auf den Trassenantrag eines EVU. Wenn der IB den Trassenantrag nicht bedienen kann, muss er diese Meldung mit der Kennung „Keine Alternativen verfügbar“ senden. Ansonsten muss der IB den Antrag beantworten, indem er dem EVU eine Trassennummer sendet, zusammen mit denselben Angaben, die im Antrag des EVU enthalten waren, jedoch eventuell mit geänderten Werten.

Für eine vom IB vorgeschlagene Alternative müssen folgende Daten gesendet werden:

4.2.2.4.   Trasse bestätigt

Diese Meldung muss vom EVU an den IB geschickt werden, um einen Trassenvorschlag, der vom IB infolge eines Trassenantrags des EVU übermittelt wurde, zu akzeptieren. Mit dieser Meldung wird die Trasse gebucht. Hauptinhalt der Meldung ist:

4.2.2.5.   Trassendetails abgelehnt

Für den Fall der Ablehnung einer vom IB vorgeschlagene Trasse, muss diese Meldung vom EVU zum IB als Antwort auf die Meldung „Trassendetails“ des IB geschickt werden, um den IB darauf hinzuweisen, dass das EVU die mit „Trassendetails“ vorgeschlagene Trasse nicht akzeptiert. Die wichtigsten Daten sind:

Als Zusatzinformationen können folgende Daten gesendet werden:

4.2.2.6.   Trasse storniert

Dies ist die Meldung des EVU zur Stornierung einer zuvor gebuchten Trasse. Zusammen mit der Stornierungsanzeige (entspricht dem Meldungstyp) muss die Trassennummer gesendet werden, um die eindeutige Identifizierung der Trasse sicherzustellen. Dies gilt für geplante und für kurzfristige Trassenbuchungen:

Als Zusatzinformationen können folgende Daten gesendet werden:

4.2.2.7.   Trasse nicht verfügbar

Der IB muss das EVU unterrichten, sobald er davon Kenntnis erlangt, dass eine Zugtrasse nicht verfügbar ist. Die Meldung „Trasse nicht verfügbar“ kann jederzeit zwischen dem Moment der Trassenbuchung und der Abfahrt des Zuges gesendet werden. Ein Grund für diese Meldung kann z. B. die Unterbrechung des Fahrwegs sein. Hauptinhalte dieser Meldung sind:

Zusammen mit dieser Meldung oder so bald wie möglich danach muss der IB ohne weiteren Antrag des EVU einen Alternativvorschlag schicken. Dies erfolgt mit der Meldung „Trassendetails“ mit Bezug auf diese Meldung „Trasse nicht verfügbar“.

4.2.2.8.   Empfangsbestätigung

Diese Information muss vom Empfänger einer Meldung an ihren Absender geschickt werden, wenn die erforderliche Antwort nicht innerhalb des Zeitfensters, wie in Kapitel 4.4 (Betriebsvorschriften) spezifiziert, bereitgestellt werden kann. Die Meldung muss einen Bezug aufweisen, auf den sie sich bezieht (Einträge Datenfeld Bezugsmeldung, siehe Kapitel 4.2: Funktionelle und technische Spezifikationen zum Teilsystem, Allgemeine Anmerkungen zur Meldungsstruktur) sowie die Angabe: (Anwendungsebene)

4.2.3.   Zugvorbereitung

4.2.3.1.   Allgemeine Bemerkungen

Dieser Abschnitt definiert die Meldungen, die beim Normalbetrieb des Zuges, wenn keinerlei Unterbrechungen auftreten, ausgetauscht werden müssen. Die Meldungen sind in Tabelle 5 zusammengefasst.

Für die Zugvorbereitung benötigt das EVU Zugang zu Mitteilungen über Infrastrukturbeschränkungen, zu den technischen Daten der Wagen (in den Datenbanken der Fahrzeugreferenzdaten für die Wagen, Kapitel 4.2.11.3: Die Fahrzeugreferenzdatenbanken), zur Referenzdatei über Gefahrgüter und zu aktuellen Statusangaben der Wagen (Kapitel 4.2.12.2: Weitere Datenbanken: Betriebsdatenbank für Wagen- und Intermodaleinheiten). Dies gilt für alle Wagen im Zug. Am Ende muss das EVU die Zugbildungsinformationen an die nächsten EVU senden. Diese Meldung muss ebenfalls vom EVU an die IB gesendet werden, bei denen es einen Trassenabschnitt gebucht hat, wenn dies in der TSI „Betrieb und Verkehrssteuerung des konventionellen Eisenbahnsystems“ oder in den Verträgen zwischen dem EVU und (den) IB gefordert wird.

Falls die Zugbildung an einem Ort geändert wird, muss diese Meldung mit den vom zuständigen EVU aktualisierten Angaben erneut ausgetauscht werden.

An jedem Ort, z. B. Abfahrtsort und Wagenübergangspunkt, an dem die Verantwortlichkeit auf Seiten der EVU wechselt, ist der Dialog für die Startprozedur „Zug fertig — Zugfahrtmeldung“ zwischen IB und EVU verbindlich vorgeschrieben (obligatorisch).

Bei diesem Dialog der Startprozedur kommen folgende Meldungen zum Einsatz:

Tabelle 5

Zugvorbereitung

Diese Meldungen werden in den folgenden Abschnitten in ihren wichtigsten Punkten umrissen. Die ausführlichen Formate dieser Meldungen sind im Anhang A Ziffer 1 definiert. Die logische Abfolge dieser Meldungen ist aus Anhang A Ziffer 5 Kapitel 3 ersichtlich.

Bemerkung: Während der Zugvorbereitung kann auch die Meldung „Zugtrasse nicht verfügbar“ auftreten, da diese Meldung jederzeit zwischen dem Moment der Trassenbuchung und der Abfahrt des Zuges gesendet werden kann. Das Verfahren hierfür ist in Kapitel 4.2.2 (Beantragung einer Trasse) beschrieben.

4.2.3.2.   Zugbildung

Diese Meldung muss vom EVU an das nächste EVU gesendet werden, sie legt die Zugbildung fest. Diese Meldung muss ebenfalls vom EVU an die IB gesendet werden, wenn dies in der TSI „Betrieb und Verkehrssteuerung des konventionellen Eisenbahnsystems“ oder im Vertrag zwischen dem EVU und IB gefordert wird. Immer wenn sich während der Fahrt eines Zuges die Zugbildung verändert, muss das verantwortliche EVU die Meldung an alle beteiligten Parteien aktualisieren.

Dabei müssen folgende Informationen übermittelt und zugänglich gemacht werden:

Nach Erhalt der Zugbildungsmeldung kann der IB die Einträge mit der gebuchten Trasse vergleichen, wenn der Vertrag zwischen IB und EVU dies ausdrücklich erlaubt. In diesem Fall muss der IB unproblematischen Zugang zu den Informationen über Einschränkungen auf den entsprechenden Infrastrukturanlagen, zu den technischen Wagendaten (Kapitel 4.2.11.3: zur Referenzdatei über Gefahrgüter und zu aktuellen Statusangaben der Wagen (Kapitel 4.2.12.2: Weitere Datenbanken, Betriebsdatenbank für Wagen- und Intermodaleinheiten) haben. Dies gilt für alle Wagen im Zug. In diesem Fall muss auch der IB, der seine Zugtrassen verwaltet und die Trasseninformationen auf dem aktuellen Stand hält, die Zugdetails der Zugbildung in die Trassen- und Zugdaten einpflegen wie in Kapitel 4.2.2.1 (Beantragung einer Trasse, Vorbemerkungen) erwähnt.

4.2.3.3.   Zug akzeptiert

Je nach Vertrag zwischen IB und EVU und aufsichtsrechtlichen Vorschriften kann der IB dem EVU auch mitteilen, ob die Zugbildung für die gebuchte Trasse akzeptabel ist. Das geschieht mit dieser Meldung.

Hauptinhalte dieser Meldung sind:

4.2.3.4.   Zug ungeeignet

Wenn sich der Zug für die zuvor gebuchte Trasse nicht eignet, kann der IB das EVU mit dieser Meldung darüber unterrichten. In diesem Fall muss das EVU die Zugbildung nochmals überprüfen. Hauptinhalte dieser Meldung sind:

4.2.3.5.   Zug fertig

Diese Meldung muss vom EVU an den IB gesendet werden, sie gibt an, dass der Zug fertig zum Einfahren in das Netz ist. Hauptinhalte dieser Meldung sind:

4.2.3.6.   Zugposition

Diese Meldung kann als Antwort auf die Meldung „Zug fertig“ vom IB an das EVU geschickt werden. Sie definiert genau, wann und wo der Zug in das Netz des IB einfahren soll. Die Übertragung dieser Meldung richtet sich nach den vertraglichen Vereinbarungen zwischen EVU und IB. Falls diese Übertragung erforderlich ist, umfasst sie folgende Hauptinhalte:

4.2.3.7.   Zug am Start

Diese Meldung kann als Antwort auf die IB-Meldung „Zugposition“ vom EVU an den IB übertragen werden. Sie gibt an, dass der Zug seine Fahrt begonnen hat. Die Antwort enthält einen Bezug auf die IB-Meldung und die Angabe:

4.2.3.8.   Zugfahrtmeldung

Sobald der Zug in der Infrastruktur des IB präsent ist — das bedeutet, er hat seinen Abfahrtsbahnhof verlassen — sendet der IB diese Meldung an das EVU, das die Trasse gebucht hat. Diese Meldung ist in Kapitel 4.2.4 (Prognose zur Zugfahrt) beschrieben.

4.2.4.   Prognose zur Zugfahrt

4.2.4.1.   Allgemeine Bemerkungen

Dieser Abschnitt definiert die Meldungen, die beim Normalbetrieb des Zuges, wenn keinerlei Unterbrechung auftreten, ausgetauscht werden müssen.

Die relevanten Meldungen sind:

Dieser Informationsaustausch zwischen EVU und IB erfolgt immer zwischen dem aktuell zuständigen IB und dem EVU, das die Trasse gebucht hat, auf der sich der Zug aktuell befindet. Im Fall des offenen Netzzugangs, wenn also die Trassen für die gesamte Fahrt von einem einzigen EVU (dieses EVU betreibt auch den Zug während der gesamten Fahrt) gebucht werden, werden alle Meldungen an dieses EVU gesandt. Dasselbe gilt, wenn die Trassen für die Fahrt von einem EVU über den OSS gebucht werden.

Sie berücksichtigen die verschiedenen Kommunikationsbeziehungen zwischen EVU und IB entsprechend den Trassenbuchungsszenarien in Kapitel 4.2.2.1 (Beantragung einer Trasse, Vorbemerkungen Szenario A, B):

Es wird angenommen, dass der Übergabepunkt nicht gleichzeitig ein Wagenübergangspunkt (nur Szenario B) und auch keine Anschlussstelle ist. Somit ist der Übergabepunkt ein Punkt auf den gebuchten Trassen eines EVU und das EVU hat die Zugbildung bereits an den IB n2 übermittelt, während es gleichzeitig diese Meldung an den IB n1 geschickt hat.

IB n1 muss nach der Abfahrt vom Abfahrtspunkt (5) eine Zugfahrtprognose mit der voraussichtlichen Übergabezeit (PZÜ) an IB n2 übermitteln. Diese Meldung wird gleichzeitig an das EVU geschickt.

Wenn ein Zug die Infrastruktur des IB n1 am Übergabepunkt verlässt, sendet dieser IB eine Zugfahrtmeldung mit der tatsächlichen Übergabezeit an diesem Punkt an das EVU, das die Trasse gebucht hat.

Wenn ein Zug in die Infrastruktur des IB n2 am Übergabepunkt einfährt, sendet dieser IB eine Zugfahrtmeldung mit der tatsächlichen Übergabezeit an diesem Punkt an das EVU, das die Trasse gebucht hat.

Im Trassenvertrag muss ein Wagenübergangspunkt immer als Meldepunkt definiert werden. (PZAZ an den Meldepunkten werden von den IB gemäß den Angaben in ihren Verträgen mit den EVU generiert.)

Für diesen Punkt sendet der zuständige IB, sobald der Zug den auf der Trasse vorher liegenden Meldepunkt verlassen hat, eine Zugfahrtprognosemeldung mit der voraussichtlichen Ankunftszeit des Zuges (PZAZ) an diesem Wagenübergangspunkt an das EVU, das die Trasse gebucht hat (z. B. EVU 1). EVU 1 gibt die Meldung an das nächste EVU (z. B. EVU 2), das den Zug übernehmen soll, weiter. Zusätzlich wird diese Meldung auch an das federführende EVU (FEVU) für den Transport weitergegeben, sofern ein FEVU vorhanden und die Weiterleitung der Meldung im Vertrag zwischen den beiden EVU festgelegt ist.

Ist der Wagenübergangspunkt gleichzeitig ein Übergabepunkt, beispielsweise zwischen IB n1 und IB n2, sendet IB n1 die Zugfahrtprognose bereits nach der Abfahrt vom Abfahrtspunkt oder vom vorigen Wagenübergangspunkt an IB n2 mit Angabe der voraussichtlichen Übergabezeit (PZÜ). Diese Meldung wird gleichzeitig an das EVU geschickt, das die Trasse gebucht hat, z. B. EVU 1. Für das EVU ist die PZÜ identisch mit PZAZ am Wagenübergangspunkt. EVU 1 gibt die Meldung an den Nachbarn EVU 2 und gegebenenfalls an ein federführendes EVU für den Transport weiter, sofern ein FEVU vorhanden und die Weiterleitung der Meldung im Vertrag zwischen den beiden EVU festgelegt ist.

Bei Ankunft des Zuges an einem Wagenübergangspunkt muss der IB eine Zugfahrtmeldung an das EVU senden, das die Trasse gebucht hat (z. B. EVU 1); die Meldung enthält die tatsächliche Ankunftszeit an diesem Punkt.

Vor der Abfahrt eines Zuges vom Wagenübergangspunkt muss EVU 2 eine neue Zugbildungsmeldung an den IB schicken, der ihr die Trasse zugewiesen hat, und es muss das in Kapitel 4.2.3 (Zugvorbereitung) beschriebene Verfahren bei der Abfahrt befolgen.

Eine Anschlussstelle muss immer im Trassenvertrag als Meldepunkt definiert werden.

Für diesen Punkt muss der zuständige IB eine Zugfahrtprognose mit einer PZAZ nur dann schicken, wenn dies im Vertrag zwischen IB und EVU festgelegt ist.

Ist die Anschlussstelle aber gleichzeitig ein Übergabepunkt, beispielsweise zwischen IB n1 und IB n2, muss IB n1 die Zugfahrtprognose bereits nach der Abfahrt vom Abfahrtspunkt oder vom vorigen Wagenübergangspunkt an IB n2 mit Angabe der voraussichtlichen Übergabezeit (PZÜ) senden. Diese Meldung wird auch an das EVU geschickt. Für das EVU ist die PZÜ identisch mit der PZAZ an der Anschlussstelle.

Bei Ankunft des Zuges an der Anschlussstelle muss der IB eine Zugfahrtmeldung mit der tatsächlichen Ankunftszeit an diesem Punkt an das EVU schicken.

Vor Abfahrt des Zuges von der Anschlussstelle müssen das EVU und der IB das in Kapitel 4.2.3 (Zugvorbereitung) beschriebene Verfahren bei der Abfahrt befolgen.

Wenn der Zug an seinem Ziel eintrifft, sendet der zuständige IB die Meldung „Zugfahrtmeldung“ mit der tatsächlichen Ankunftszeit an das EVU, das die Trasse gebucht hat.

Bemerkung: Im Trassenvertrag können auch andere Orte definiert sein, für die eine Zugfahrtprognose mit PZAZ und Zugfahrtmeldungen mit Istzeiten erforderlich sind. Für diese Punkte sendet der zuständige IB diese Meldungen nach Maßgabe des Trassenvertrags. Die weitere Auswertung und Verarbeitung der gesendeten PZÜ und PZAZ wird in den Kapiteln 4.2.7 (Ladung PÜZ/PAZ) bis 4.2.9 (Berichtswesen Wagenübergang) beschrieben.

In den folgenden Kapiteln werden die Meldungen „Zugfahrtprognose“ und „Zugfahrtmeldung“ in ihren wichtigsten Punkten umrissen. Die ausführlichen Formate dieser Meldungen sind im Anhang A Ziffer 1 definiert. Die logische Abfolge dieses Meldungsaustauschs bei den unterschiedlichen Kommunikationsszenarios ist aus Anhang A Ziffer 5 Kapitel 4 ersichtlich. Es sei darauf hingewiesen, dass hinsichtlich der Kommunikationsbeziehung zwischen EVU und IB während der Zugfahrt die beiden Szenarien A(a) und A(b) (Kapitel 4.2.2.1: Beantragung einer Trasse, Vorbemerkungen) zum Trassenantrag identisch sind, denn in beiden Fällen kennen die IB nur ein EVU, z. B. EVU 1, das den Zug über die gesamte Trasse betreibt und auch für die neue Zugbildung an den Anschlussstellen zuständig ist.

4.2.4.2.   Zugfahrtprognose

Diese Meldung muss vom IB für Übergabepunkte, Wagenübergangspunkte und für das Zugziel, wie in Kapitel 4.2.4.1 (Prognose zur Zugfahrt, Allgemeine Bemerkungen) beschrieben, geschickt werden.

Zusätzlich muss diese Meldung durch den IB an das EVU für weitere Meldepunkte entsprechend den EVU/IB-Verträgen erfolgen (z. B. für Anschlussstellen).

Die wichtigsten Datenelemente sind:

4.2.4.3.   Zugfahrtmeldung

Diese Meldung muss erfolgen bei:

4.2.5.   Information über Verkehrsunterbrechung

4.2.5.1.   Allgemeine Bemerkungen

Erfährt das EVU von einer Verkehrsunterbrechung während der Zugfahrt, für die es verantwortlich ist, muss es den zuständigen IB unverzüglich unterrichten (nicht per IT-Meldung, sondern z. B. durch den Triebfahrzeugführer). Falls erforderlich, aktualisiert das EVU die Betriebsdatenbank für Wagen und Intermodaleinheiten. Falls erforderlich, aktualisiert der IB die Infrastrukturdaten in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen und/oder die Trassen- bzw. die Zugdatenbank.

Bei Verspätungen von mehr als x Minuten (dieser Wert ist im Vertrag zwischen EVU und IB zu definieren) muss der betroffene IB dem EVU eine Zugfahrtprognose bezogen auf den nächsten Meldepunkt schicken.

Bei Aussetzung des Zuges sendet der IB eine Meldung über die Fahrtunterbrechung gemäß nachstehender Beschreibung.

In den Ausnahmefällen, in denen das EVU oder der IB den Zug nicht zur veranschlagten Zeit fahren lassen kann, muss eine neue Trasse gemäß Kapitel 4.2.2 (Beantragung einer Trasse) ausgehandelt werden.

4.2.5.2.   Fahrtunterbrechung

Bei Aussetzung des Zuges wird diese Meldung vom IB an den benachbarten IB und an das EVU, das die Trasse gebucht hat, geschickt.

Die wichtigsten Datenelemente in dieser Meldung sind:

4.2.6.   Abfragen zum Zugstandort

4.2.6.1.   Vorbemerkung

Dieser Abschnitt beschreibt die Möglichkeiten der Abfrage, um Informationen über den Standort eines Zuges zu erhalten. Das EVU kann den Status seiner Züge jederzeit beim IB abfragen. Die Abfrage kann sich erstrecken auf:

Der Zugriff auf diese Informationen muss von der Kommunikationsbeziehung EVU/IB während der Zugfahrt unabhängig sein, d. h. das EVU muss eine einzelne Zugangsadresse (6) für diese Informationen haben. Die Informationen basieren hauptsächlich auf den gespeicherten Meldungen, die nach oben beschriebenem Verfahren ausgetauscht wurden.

4.2.6.2.   Abfrage zur Zugfahrt

4.2.6.3.   Abfrage zur Zugverspätung/Fahrleistung

4.2.6.4.   Abfrage der Zugkennung

4.2.6.5.   Abfrage der Zugfahrtprognose beim IB

4.2.6.6.   Abfrage an IB über Züge am Meldepunkt

4.2.7.   Ladung PÜZ/PAZ

4.2.7.1.   Vorbemerkung

In Kapitel 4.2.2 (Trassenantrag) bis 4.2.6 (Zugstandort) wird hauptsächlich die Kommunikation zwischen EVU und IB beschrieben. Da die Aufgabe des Betreibers der Infrastruktur darin besteht, die Züge zu überwachen und zu steuern, ist die Zugnummer das wichtigste Element dieser Kommunikation. Der Wageninformationsteil der Zugbildungsmeldung ist nur für den Abgleich der Zugbildung mit dem Trassenvertrag zwischen IB und EVU und in Ausnahmefällen relevant.

Die Einzelüberwachung von Wagen oder Intermodaleinheiten wird durch diesen Informationsaustausch nicht geregelt. Dies geschieht auf EVU- oder FEVU-Ebene auf Basis der zugspezifischen Meldungen und wird in den folgenden Kapiteln 4.2.7 (Ladung PÜZ/PAZ) bis 4.2.9 (Berichtswesen Wagenübergang) beschrieben.

Der auf Wagen oder Intermodaleinheiten bezogene Informationsaustausch und die Aktualisierung stützen sich im Wesentlichen auf die Speicherung von „Tourenplänen“ und „Wagenbewegungen“ (Kapitel 4.2.12.2: Weitere Datenbanken).

Wie bereits in Kapitel 2.3.2 (Betrachtete Prozesse) erwähnt, ist die wichtigste Information für einen Kunden immer die voraussichtliche Ankunftszeit (PAZ) seiner Ladung. Die wagenbezogene PAZ sowie die PÜZ ist auch die Basisinformation in der Kommunikation zwischen FEVU und EVU. Diese Information ist das Hauptinstrument für das FEVU zur Überwachung des physischen Transports einer Ladung und dient zur Überprüfung mit der Verpflichtung gegenüber dem Kunden.

Die prognostizierten Zeiten in den zugbezogenen Meldungen beziehen sich stets auf die Ankunftszeit eines Zuges an einem bestimmten Punkt. Das kann ein Übergabepunkt, Wagenübergangspunkt, Zielort oder ein anderer Meldepunkt sein. Es handelt sich dabei immer um die voraussichtliche Ankunftszeit des Zuges (PZAZ). Für die verschiedenen Wagen oder Intermodaleinheiten in einem Zug kann diese PZAZ unterschiedliche Bedeutungen haben. Eine für einen Wagenübergangspunkt berechnete PZAZ kann beispielsweise die voraussichtliche Wagenübergangszeit (PÜZ) für einige Wagen oder Intermodaleinheiten sein. Für andere Wagen, die zur weiteren Beförderung durch dasselbe EVU im Zugverband verbleiben, mag dieses PZAZ ohne Bedeutung sein. Die Aufgabe des EVU, das die PZAZ-Information erhält, ist es, die spezifische Interpretation vorzunehmen und auszuwerten, sie als Wagenbewegung in der Betriebsdatenbank für Wagen und Intermodaleinheiten zu speichern und sie dann dem FEVU mitzuteilen, falls der Zug nicht im Modus des offenen Netzzugangs betrieben wird. Dies wird nun in den folgenden Abschnitten betrachtet.

4.2.7.2.   Berechnung der PÜZ/PAZ

Die PÜZ/PAZ-Berechnung basiert auf den Informationen vom zuständigen Infrastrukturbetreiber. Dieser sendet im Rahmen der Zugfahrtprognose die voraussichtliche Ankunftszeit des Zuges (PZAZ) für die definierten Meldepunkte (in jedem Fall für Übergabe-, Wagenübergangs- oder Ankunftspunkte einschließlich Intermodal-Umschlagbahnhöfe) auf der vereinbarten Trasse, z. B. für den Übergabepunkt von einem IB zum nächsten IB (in diesem Fall ist PZAZ gleich PZÜ).

Für die Wagenübergangspunkte oder für andere definierte Meldepunkte auf der vereinbarten Trasse muss das EVU für das nächste EVU in der Transportkette die voraussichtliche Wagenübergangszeit (PÜZ) für die Wagen und/oder Intermodaleinheiten berechnen.

Da ein EVU Wagen mit verschiedenen Fahrten und von verschiedenen FEVU innerhalb des Zugs haben kann, kann der Wagenübergangspunkt für die PÜZ-Berechnung der Wagen verschieden sein. Dies ist in den zwei folgenden vereinfachten Beispielen erklärt (die bildliche Darstellung dieser Szenarien ist im Anhang A Index 5 Kapitel 1.4 wiedergegeben, und das Ablaufdiagramm auf der Basis von Beispiel 1 für den Wagenübergangspunkt C ist in Anhang A Index 5 Kapitel 5 dargestellt).

Das nächste EVU berechnet seinerseits auf Basis der PÜZ-Angaben vom vorigen EVU die wagenbezogene PÜZ für den nächsten Wagenübergangspunkt. Diese Schritte werden von allen folgenden EVU ausgeführt. Wenn das letzte EVU (z. B. EVU n) in der Transportkette eines Wagens die PÜZ von seinem vorausgehenden EVU (z. B. EVU n-1) für den Wechsel des Wagens zwischen EVU n-1 und EVU n erhält, muss das letzte EVU (EVU n) die voraussichtliche Ankunftszeit der Wagen am Endziel errechnen. Diese ist ausgerichtet auf die Platzierung der Wagen gemäß Beförderungsauftrag und im Einklang mit der Verpflichtung des FEVU gegenüber dem Kunden. Dies ist die PAZ für den Wagen; sie muss zum FEVU gesandt werden. Sie muss zusammen mit der Wagenbewegung elektronisch gespeichert werden. Das FEVU muss dem Kunden entsprechend den Vertragsbedingungen Zugang zu dessen relevanten Daten gewähren.

Bemerkung zu Intermodaleinheiten: Für die Intermodaleinheiten auf einem Wagen sind die wagenbezogenen PÜZ zugleich die PÜZ für die Intermodaleinheiten. Bezüglich der PAZ für Intermodaleinheiten sei angemerkt, dass das EVU nicht in der Lage ist, eine solche PAZ über den Schienentransportanteil hinaus zu berechnen. Daher kann das EVU nur PÜZ bezogen auf den Intermodalterminal liefern.

Das federführende EVU ist verantwortlich für den Vergleich der PAZ mit der eingegangenen Verpflichtung gegenüber dem Kunden.

Abweichungen der PAZ von der Verpflichtung gegenüber dem Kunden müssen im Einklang mit dem Vertrag behandelt werden und können zu einem Alarmmanagement-Prozess durch das FEVU führen. Für die Übertragung der Ergebnisse dieses Prozesses ist die Alarmmeldung vorgesehen.

Als Basis für den Alarmmanagement-Prozess muss das FEVU die Möglichkeit zur wagenbezogenen Abfrage von Abweichungen haben. Diese Abfrage eines FEVU und die Antwort vom EVU sind ebenfalls nachfolgend beschrieben.

4.2.7.3.   Wagen PÜZ/PAZ

4.2.7.4.   Alarmmeldung

Bemerkung: Im Fall des offenen Netzzugangs ist die Berechnung der PÜZ und PAZ ein interner Prozess innerhalb des EVU. In diesem Fall ist das EVU selbst das federführende EVU.

4.2.7.5.   Abfrage zu Wagenabweichungen

4.2.8.   Berichtswesen Wagenbewegung

4.2.8.1.   Vorbemerkungen

Für das Berichtswesen von Wagenbewegungen müssen die folgenden Daten gespeichert und elektronisch zugänglich sein. Sie müssen auch, falls vertraglich vereinbart, als Meldung mit autorisierten Parteien ausgetauscht werden. Die genauen Formate sind in Anhang A Index 1 definiert.

4.2.8.2.   Wagenfreigabe

4.2.8.3.   Wagenabfahrt

4.2.8.4.   Wagenankunft Rangierbahnhof

4.2.8.5.   Wagenabfahrt Rangierbahnhof

4.2.8.6.   Wagenausnahme

4.2.8.7.   Wagenausnahme neue PÜZ/PAZ erforderlich

4.2.8.8.   Wagenankunft

4.2.8.9.   Wagenablieferung

Die Wagenablieferungsmeldung kann ein zweites Mal als „Wagenablieferbestätigung“ mit folgender Zusatzangabe geschickt werden:

Bemerkung: Im Fall des offenen Netzzugangs ist das beschriebene Berichtswesen über Wagenbewegungen ein interner Prozess des EVU (FEVU). Dennoch müssen alle Berechnungen und Datenspeicherungen von ihm als FEVU, das einen Vertrag mit und eine Verpflichtung gegenüber dem Kunden hat, durchgeführt werden.

Das Ablaufdiagramm für diese Meldungen basierend auf dem Beispiel 1 der PÜZ-Berechnung für die Wagen der Nummern 1 und 2 (siehe Kapitel 4.2.7.2 Berechnung der PÜZ/PAZ) ist integriert in dem Ablaufdiagramm für Wagenübergangsmeldung Anhang A Ziffer 5 Kapitel 6.

4.2.9.   Berichtswesen Wagenübergang

4.2.9.1.   Vorbemerkung

Das Berichtswesen zum Wagenübergang beschreibt alle Meldungen, die mit einem Wechsel der Verantwortlichkeit, der sich an Wagenübergangspunkten vollzieht, für einen Wagen zwischen zwei Eisenbahnverkehrsunternehmen verbunden sind. Jeder Wechsel verpflichtet das neue EVU, eine PÜZ zu berechnen und das in Kapitel 4.2.7 (Ladung PÜZ/PAZ) beschriebene Verfahren zu befolgen.

Folgende Meldungen müssen ausgetauscht werden:

Die Informationen in diesen Meldungen müssen in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden. Im Fall irgendwelcher Ausnahmen müssen neue PÜZ/PAZ-Zeiten generiert und nach dem in Kapitel 4.2.7 (Ladung PÜZ/PAZ) beschriebenen Verfahren an die anderen Beteiligten übermittelt werden. Das Ablaufdiagramm für diese Meldungen zusammen mit den Meldungen aus dem Berichtswesen der Wagenbewegungen ist im Anhang A Ziffer 5 Kapitel 6 dargestellt.

Die Meldungen „Wagenübergang“ und „Wagenübergang/Sub“ wie auch die Meldungen „Wagen am Übergangspunkt erhalten“ können in Form einer Liste für mehrere Wagen gleichzeitig übertragen werden, insbesondere wenn sich alle Wagen in ein und demselben Zug befinden. In diesem Fall können alle Wagen in einer einzigen Meldung aufgeführt werden.

Im Fall des offenen Netzzugangs gibt es keine Wagenübergangspunkte. An einer Anschlussstelle bleibt die Verantwortung für die Wagen unverändert. Es ist daher kein spezieller Meldungsaustausch erforderlich. Allerdings müssen aus der an diesem Meldepunkt abgesetzten Zugfahrtmeldung die Wagen- oder Intermodaleinheit-Informationen (wie Standort, Ankunftsdatum und -uhrzeit sowie Abfahrtsdatum und -uhrzeit) entnommen, verarbeitet und in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden.

Die Inhalte dieser Meldungen ergeben sich wie folgt:

4.2.9.2.   Wagenübergang

4.2.9.3.   Wagenübergang/Sub

4.2.9.4.   Wagen am Übergangspunkt erhalten

4.2.9.5.   Wagen am Übergangspunkt abgelehnt

4.2.10.   Datenaustausch zur Qualitätsverbesserung

Um wettbewerbsfähig zu sein, muss die europäische Eisenbahnbranche ihren Kunden eine höhere Dienstqualität bieten (siehe auch Anhang III, Artikel 2 Absatz 7 Unterabsatz 1 der Richtlinie 2001/16/EG).

Ein Messprozess ist ein wesentlicher nachlaufender Prozess, um Qualitätsverbesserungen zu erreichen.

Neben der Messung der dem Kunden erbrachten Leistung müssen FEVU, EVU und IB die Qualität der Leistungskomponenten messen, die zusammen das dem Kunden gebotene Produkt darstellen.

Mitwirkende des Verfahrens sind die IB und die EVU (insbesondere, wenn sie federführende EVU sind). Sie wählen einen individuellen Qualitätsparameter, eine Strecke oder einen Ort und einen Erfassungszeitraum, in dem die tatsächlichen Ergebnisse gemessen und mit vorher festgelegten Kriterien, die normalerweise in einem Vertrag aufgeführt sind, verglichen werden.

Die Resultate des Messprozesses müssen verdeutlichen, welches Leistungsniveau im Vergleich zu den zwischen den Vertragsparteien vereinbarten Zielen erreicht wurde.

Die Messprotokolle müssen so detailliert sein, dass sie eine Analyse gestatten, wo und warum Qualitätsminderungen, z. B. Verspätungen, aufgetreten sind. Bei wiederkehrenden Qualitätsmängeln ist eine Ursachenforschung zu betreiben, damit die Vertragsparteien für Abhilfe sorgen können.

IB und EVU sind verpflichtet, Daten bereitzustellen, sich, auch mit Drittparteien, an der Ursachenforschung zu beteiligen und vereinbarte Abhilfemaßnahmen zu ergreifen.

Der Messprozess ist laufend zu wiederholen.

Wie unter den folgenden sechs Überschriften aufgeführt, können zur Qualitätsmessung die bereits definierten Meldungen dienen:

1.   FEVU/Kunde: Transitzeit, PAZ, Alarmbehebung

In Verträgen zwischen EVU, die als Dienstintegratoren fungieren (FEVU), und Kunden können (je nach Vertrag) Verpflichtungen bezüglich Transitzeit, PAZ und Störungsbehebung eingegangen werden. Die wichtigsten Meldungen für diese Qualitätsmessung sind:

Wagenfreigabe,

Wagenabfahrt,

Wagenablieferung.

2.   FEVU/Dienstleister: Transit- und Anschlusszeiten, PAZ, PÜZ, Ursachencodes

In Verträgen zwischen einem FEVU und anderen Dienstleistern können Verpflichtungen, z. B. auf festgelegte Transitzeiten (Stunden), eingegangen werden. Mit einzelnen Dienstleistern können Verpflichtungen eingegangen werden bezüglich:

Freigabe-/Rangierzeit bis Ablieferung an einem Wagenübergangspunkt,

Abholung bis Einfahrtspunkt,

Einfahrtspunkt bis zur Ladung,

Annahme am Wagenübergangspunkt bis Ablieferung am Wagenübergangspunkt,

Annahme am Wagenübergangspunkt bis Abstellen/Umschlagen,

Rangieren bis Ablieferung.

Die wichtigsten Meldungen für diese Qualitätsmessung sind:

Wagenfreigabe,

Wagenabfahrt,

Wagenankunft am Rangierbahnhof,

Wagenabfahrt am Rangierbahnhof,

Wagenankunft,

Wagenübergang erfolgt,

Wagen am Wagenübergangspunkt erhalten,

Wagen am Wagenübergangspunkt abgelehnt.

3.   EVU/IB: Zugleistung, Zug-PAZ (PZAZ), PZÜ

In den Verträgen zwischen EVU und IB können Pünktlichkeitsstufen für die Fahrplaneinhaltung an spezifizierten Meldepunkten oder Genauigkeitsvorgaben für PZAZ und PZÜ vereinbart werden. Die wichtigsten Meldungen für diese Qualitätsmessung sind:

Zugfahrtprognose,

Zugfahrtmeldung,

Abfrage/Antwort über Zugverspätungen/Fahrleistung.

4.   EVU/IB: Verfügbarkeit geplanter Trassen

Die Verfügbarkeit von Trassen zum Betrieb von Zügen ist in den Verträgen zwischen EVU und IB zu regeln. Auch die Zugspezifikationen (maximale Länge, maximales Bruttogewicht, Begrenzungslinie etc.) sind in den Verträgen zu definieren. Dieser Aspekt wird unter Nummer 6 angesprochen (IB/EVU: Zugbildungsqualität).

Die Verfahren und Zeitrahmen zur Bestätigung der Trassennutzung, zur Stornierung einer geplanten Trasse und zur Bestimmung, inwieweit eine Trasse außerhalb (früher oder später) der definierten Zeiten genutzt werden kann, sind ebenfalls vertraglich zu regeln. Die wichtigsten Meldungen für diese Qualitätsmessung sind:

Trasse storniert,

Trasse nicht verfügbar.

5.   EVU/IB: Kurzfristiger Trassenantrag

Wenn ein EVU einen Zug außerhalb des Zeitfensters einer geplanten Trasse betreiben möchte, muss es einen kurzfristigen Trassenantrag an den (die) beteiligten IB stellen (gemäß Richtlinie 2001/14/EG).

Das EVU vergleicht regelmäßig die Daten des Trassenantrags und der Antwort miteinander und erstellt daraus folgende Berichte:

Antwortzeit für Trassenantrag im Vergleich zum Rahmenvertrag,

Anzahl der Trassen, die innerhalb gewisser Zeitintervalle nach der Antragstellung gewährt wurden,

Anzahl abgelehnter Trassenanträge.

Die wichtigsten Meldungen für diese Qualitätsmessung sind:

Trassenantrag,

Trassendetails,

Trassendetails abgelehnt,

Trasse storniert,

Trasse nicht verfügbar.

6.   IB/EVU: Zugbildungsqualität

Wenn die Zug-fertig-Meldungen und/oder die Listen der Zugbildung vom EVU an den (die) IB oder andere EVU geschickt werden, müssen sie den Zugspezifikationen entsprechen, die im jeweiligen Vertrag enthalten sind. Die wichtigsten Meldungen für die Überprüfung der Übereinstimmung und damit für die Qualitätsmessung der Zugbildung sind:

Zugbildung,

Zug ungeeignet.

4.2.11.   Die Hauptreferenzdaten

4.2.11.1.   Vorbemerkung

Die Infrastrukturdaten (die Schienennetz-Nutzungsbedingungen und die gespeicherten Daten in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen) und die Fahrzeugdaten (in der Fahrzeugreferenzdatenbank und in der Betriebsdatenbank für Wagen und Intermodaleinheiten) sind die wichtigsten Daten für den Güterzugverkehr im Europäischen Schienennetz. Beide zusammen erlauben eine Bewertung der Kompatibilität der Fahrzeuge mit der Infrastruktur, unterstützen die Vermeidung von mehrfacher Dateneingabe, was insbesondere die Datenqualität erhöht, und geben zu jeder Zeit ein klares Bild über die verfügbaren Installationen und Ausrüstungen für schnelle Entscheidungen während des Betriebes.

4.2.11.2.   Die Datenbank für Mitteilungen der Infrastrukturbeschränkungen

Jeder IB ist für die Eignung einer Trasse auf seiner Infrastruktur verantwortlich, und das EVU ist verpflichtet, die Zugmerkmale in Bezug auf die Werte zu überprüfen, die in den Trassendetails seines Trassenvertrages aufgeführt sind.

Unbeschadet der Bedingungen für die Nutzung einer Trasse in den Schienennetz-Nutzungsbedingungen oder der Verantwortlichkeiten bei Einschränkungen in der Infrastruktur, die in der TSI Betrieb und Verkehrsmanagement erläutert sind, muss das EVU vor der Zugvorbereitung wissen, ob es Beschränkungen auf den Trassenabschnitten oder Bahnhöfen (Knoten) gibt, die seine Zugzusammenstellung, wie im Trassenvertrag beschrieben, beeinflussen.

Dazu müssen die IB Datenbanken für die Mitteilungen über Beschränkungen in der Infrastruktur erstellen und auffüllen: Die Struktur einer solchen Datenbank ist im Anhang A Ziffer 2 skizziert. Die Einträge dieser Datenbanken beruhen auf Segmenten entsprechend den Schienennetz-Nutzungsbedingungen unter Zusatz von Beschränkungsinformationen. Die Zugänglichkeit dieser Datenbanken erfolgt über die „gemeinsame Schnittstelle“ (4.2.14.1: Vernetzung und Kommunikation und 4.2.14.7: Gemeinsame Schnittstelle).

Das EVU ist verpflichtet, alle Beschränkungen in den Datenbanken für Mitteilungen der Infrastrukturbeschränkungen, die seinen Zuglauf beeinflussen, bis zum Beginn der „Vor-Abfahrt-Periode“ zu berücksichtigen. Wenn nichts anderes im Vertrag zwischen IB und EVU vereinbart ist, dann beginnt diese „Vor-Abfahrt-Periode“ eine Stunde vor der planmäßigen Abfahrt.

In der „Vor-Abfahrt-Periode“ muss der IB das EVU direkt über jegliche relevanten Änderungen in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen benachrichtigen.

4.2.11.3.   Die Fahrzeugreferenzdatenbanken

Der Fahrzeughalter ist für die Speicherung der Fahrzeugdaten in einer Fahrzeugreferenzdatenbank verantwortlich.

Die Informationen, die in den individuellen Fahrzeugreferenzdatenbanken enthalten sein müssen, sind in Anhang A Ziffer 2 ausführlich beschrieben. Sie beinhalten alle Elemente zur:

Die Fahrzeugreferenzdatenbank muss einen leichten Zugriff (ein einziger gemeinsamer Zugriff, über die „gemeinsame Schnittstelle“ bereitgestellt) auf die technischen Daten gestatten, um so das für jeden Vorgang zu übertragende Datenvolumen zu minimieren. Der Inhalt der Datenbank muss auf der Basis strukturierter Zugriffsrechte in Abhängigkeit von den Privilegien aller Dienstleister (IB, EVU, Logistikanbieter und Fuhrparkbetreiber) zugänglich sein, insbesondere für Zwecke des Flottenmanagements und der Fahrzeuginstandhaltung.

Die Einträge in der Fahrzeugdatenbank können folgendermaßen gruppiert werden:

4.2.11.4.   Die Fahrzeugbetriebsdaten

Neben den Referenzdaten der Fahrzeuge sind die Daten, die den aktuellen Status des Fahrzeuges aufzeigen, die für den betrieblichen Einsatz wichtigsten Daten.

Diese Daten müssen alle temporären Daten enthalten, z. B. Einschränkungen, laufende und geplante Instandhaltungsarbeiten, Kilometerstand und Fehlerzähler etc. sowie alle Daten, die als „Status“ gelten können (vorübergehende Geschwindigkeitsbeschränkungen, isolierte Bremse, Reparaturbedarf und Fehlerbeschreibung etc.).

Beachtet man die verschiedenen Parteien, die während des betrieblichen Einsatzes eines Fahrzeugs verantwortlich sind, so müssen für die Nutzung der betrieblichen Fahrzeugdaten drei verschiedene juristische Personengruppen berücksichtigt werden:

Für alle drei Parteien müssen die betrieblichen Fahrzeugdaten für autorisierte Benutzer auf der Ebene seiner Autorisierung mittels eines einzelnen Schlüssels, der durch die Wagenkennung (Wagennummer) gegeben ist, zugänglich sein.

Die betrieblichen Fahrzeugdaten sind Teil der europaweiten Betriebsdatenbank für Wagen und Intermodaleinheiten, wie in Kapitel 4.2.12.2 (Weitere Datenbanken) beschrieben.

4.2.12.   Diverse Referenzdateien und Datenbanken

4.2.12.1.   Referenzdateien

Für den Betrieb von Güterzügen auf dem europäischen Streckennetz müssen folgende Referenzdateien vorhanden und für alle Dienstleister (IB, EVU, Logistikanbieter und Fuhrparkbetreiber) zugänglich sein. Die Daten müssen jederzeit den aktuellen Status widerspiegeln.

Lokal gespeichert und verwaltet:

Zentral gespeichert und verwaltet:

Die Codierung von IB, EVU, Transportorganisationen und -unternehmen und Transportkunden sowie die Codierung der Standorte (primäre, alternative ...) einschließlich Kundenstandorte stehen noch aus.

4.2.12.2.   Weitere Datenbanken

Für die Verfolgung von Zug- und Wagenbewegungen müssen die folgenden Datenbanken eingerichtet werden, die jeweils sofort nach einem relevanten Ereignis zu aktualisieren sind. Autorisierte Rechtspersonen wie Wagenhalter und Flottenmanager müssen entsprechend den vertraglichen Bedingungen auf die verfügbaren Daten Zugriff haben, soweit diese zur Erfüllung ihrer Funktionen relevant sind.

Die Zugänglichkeit dieser Datenbanken erfolgt über die „gemeinsame Schnittstelle“ (4.2.14.1: Vernetzung und Kommunikation und 4.2.14.7: Gemeinsame Schnittstelle).

Betriebsdatenbank für Wagen und Intermodaleinheiten

Die Kommunikation zwischen dem federführenden EVU und den EVU im Kooperationsmodus basiert auf den Nummern der Wagen- und/oder Intermodaleinheiten. Daher muss ein EVU, das auf Zugebene mit den IB kommuniziert, diese Informationen nach Wagen und Intermodaleinheiten aufschlüsseln. Diese aufgeschlüsselten Informationen müssen in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden. Die Informationen über Zugbewegungen führen zu neuen Einträgen/Aktualisierungen in der Betriebsdatenbank für Wagen- und Intermodaleinheiten zur Information für den Kunden. Der Bewegungsteil für einen Wagen oder einer Intermodaleinheit in der Datenbank wird spätestens dann erstellt, wenn der Kunde eine Freigabezeit für die Wagen/Intermodaleinheiten übermittelt. Diese Freigabezeit ist der erste Eintrag der Bewegungsdaten bezüglich eines aktuellen Zuglaufes in der Betriebsdatenbank für Wagen und Intermodaleinheiten. Die Meldungen für die Wagenbewegung sind in den Kapiteln 4.2.8 (Berichtswesen Wagenbewegung) und 4.2.9 (Berichtswesen Wagenübergang) definiert. Die Zugänglichkeit dieser Datenbanken erfolgt über die „gemeinsame Schnittstelle“ (4.2.14.1: Allgemeine Architektur und 4.2.14.7: Gemeinsame Schnittstelle).

Die Betriebsdatenbank für Wagen- und Intermodaleinheiten ist die wichtigste Datenbank zur Verfolgung der Wagen und somit für die Kommunikation zwischen den beteiligten EVU und dem federführenden EVU. Diese Datenbank zeigt die Bewegung eines Wagens und einer Intermodaleinheit vom Abfahrtsort bis zur endgültigen Lieferung am Abstellgleis des Empfängers mit PÜZ und Istzeiten an den verschiedenen Bahnhöfen bis hin zur endgültigen Auslieferungszeit PAZ beim Empfänger. Die Datenbank enthält zudem verschiedene Statusangaben für die Fahrzeuge, zum Beispiel:

Diese Statusangabe ist für den Informationsaustausch vom EVU zu den IB und den anderen an der Transportfahrt beteiligten Eisenbahnverkehrsunternehmen erforderlich.

Diese Statusangabe ist für den Informationsaustausch zwischen IB und EVU und den anderen an der Transportfahrt beteiligten Infrastrukturbetreibern und Eisenbahnverkehrsunternehmen erforderlich.

Diese Statusangabe ist für den Informationsaustausch zwischen IB und EVU und den anderen an der Transportfahrt beteiligten Infrastrukturbetreibern und Eisenbahnverkehrsunternehmen erforderlich.

Diese Statusangabe ist für den Informationsaustausch zwischen dem EVU auf der Zielseite und dem federführenden EVU für den Transport erforderlich.

Diese Statusangabe wird benötigt, um die Informationen über verfügbare Fahrzeuge mit definierten Eigenschaften abrufen zu können.

Datenbanken der Tourenpläne für Wagen

Züge transportieren normalerweise Wagen von verschiedenen Kunden. Für jeden Wagen muss das federführende EVU (das EVU, das als Dienstintegrator fungiert) einen Tourenplan, der den Zugtrassen auf Zugebene entspricht, erstellen und pflegen. Neue Zugtrassen für einen Zug, z. B. im Fall von Verkehrsunterbrechungen, führen zu neuen Tourenplänen für die betroffenen Wagen. Der Erstellungszeitpunkt für den Tourenplan ist der Empfang des Frachtbriefes vom Kunden.

Der Wagen-Tourenplan muss bei jedem FEVU in einer Datenbank gespeichert werden. Die Zugänglichkeit dieser Datenbanken erfolgt über die „gemeinsame Schnittstelle“ (4.2.14.1: Vernetzung und Kommunikation und 4.2.14.7: Gemeinsame Schnittstelle).

Bemerkung:

Zusätzlich zu den oben erwähnten obligatorischen Datenbanken kann bei jedem IB eine Zugdatenbank installiert werden.

Die Zugdatenbank für den Infrastrukturbetreiber entspricht dem Wagenbewegungsanteil in der Betriebsdatenbank für Wagen und Intermodaleinheiten. Die wichtigsten Dateneinträge sind die zugbezogenen Daten aus der Zugbildungsmeldung vom EVU. Alle Zugereignisse führen zu einer Aktualisierung dieser zugspezifischen Datenbank. Eine alternative Speichermöglichkeit für diese Daten besteht in der Trassendatenbank (Kapitel 4.2.2: Beantragung einer Trasse). Die Zugänglichkeit dieser Datenbanken erfolgt über die „gemeinsame Schnittstelle“ (4.2.14.1: Allgemeine Architektur und 4.2.14.7: Gemeinsame Schnittstelle).

4.2.12.3.   Zusätzliche Anforderungen an die Datenbanken

Unter den folgenden Punkten sind zusätzliche Anforderungen aufgelistet, denen die verschiedenen Datenbanken gerecht werden müssen.

Dies sind:

Bemerkungen:

Die obigen Anforderungen sollten mit Einsatz eines Standard-Datenbank- Managementsystems (DBMS) erfüllt werden.

Die Nutzung der verschiedenen Datenbanken ist in verschiedene Arbeitsabläufe eingebettet, die vorher beschrieben wurden. Der allgemeine Arbeitsablauf ist ein Anfrage-/Antwortmechanismus, bei dem die interessierte Seite Informationen anfordert, und zwar über die gemeinsame Schnittstelle (4.2.14.1: Vernetzung und Kommunikation und 4.2.14.7: Gemeinsame Schnittstelle). Das DBMS antwortet auf diese Anfrage entweder mit der Bereitstellung der geforderten Daten oder damit, dass keine Daten zur Verfügung gestellt werden können (es existieren keine solchen Daten oder der Zugriff wird aufgrund der Zugangskontrolle zurückgewiesen).

4.2.13.   Elektronische Übertragung von Dokumenten

Kapitel 4.2.14 (Vernetzung und Kommunikation) beschreibt das Kommunikationsnetz, das für den Datenaustausch zu verwenden ist. Dieses Netz und die beschriebene Sicherheitskonzeption gestatten die Verwendung eines beliebigen Übertragungsverfahrens, z. B. E-Mail, Dateitransfer (ftp, http) usw. Welches Verfahren gewählt wird, entscheiden dann die am Datenaustausch beteiligten Parteien; das heißt, dass die elektronische Übertragung von Dokumenten, beispielsweise durch ftp, gegeben ist.

4.2.14.   Vernetzung und Kommunikation

4.2.14.1.   Allgemeine Architektur

Dieses Teilsystem wird im Lauf der Zeit das Entstehen, das Wachsen und Zusammenwirken einer großen und komplexen interoperablen Gemeinschaft auf dem Gebiet der Telematik im Bahnbereich mit Hunderten von Akteuren (EVU. IB, ...) erleben, die miteinander konkurrieren und/oder kooperieren, um die Erfordernisse des Marktes abzudecken.

Die Netz- und Kommunikationsinfrastruktur, die einer solchen interoperablen Gemeinschaft auf dem Gebiet der Telematik im Bahnbereich zugrunde liegt, wird auf einer gemeinsamen Informationsaustauscharchitektur beruhen, die allen teilnehmenden Akteuren bekannt ist und von ihnen akzeptiert wird.

Die vorgeschlagene Informationsaustauscharchitektur:

Die Informationsaustauscharchitektur favorisiert eine gleichberechtigte (Peer-to-Peer-) Interaktion zwischen allen Akteuren, und sie garantiert die Gesamtintegrität und -konsistenz der interoperablen Gemeinschaft im Bahnbereich, indem sie eine Reihe zentralisierter Dienste bereitstellt.

Ein Peer-to-Peer-Interaktionsmodell erlaubt die beste Kostenverteilung zwischen den verschiedenen Akteuren auf der Grundlage der tatsächlichen Nutzung; zudem verursacht es wenige Probleme bei der Skalierbarkeit. Eine bildliche Darstellung der allgemeinen Architektur ist im Anhang A Ziffer 5 Kapitel 1.5 zu finden.

4.2.14.2.   Netzwerk

Vernetzung bedeutet in diesem Fall die Kommunikationsmethode und -philosophie und bezieht sich nicht auf das physikalische Netzwerk.

Die Interoperabilität im Bahnbereich beruht auf einer „gemeinsamen Informationsaustauscharchitektur“, die allen teilnehmenden Akteuren bekannt ist und von ihnen akzeptiert wird, was neue Akteure, insbesondere Kunden, ermutigt und die bestehenden Eintrittsbarrieren senkt.

Die Sicherheitsfrage wird daher nicht im Netz (VPN, Tunnelling, ...) gelöst, sondern durch Austausch und Verwaltung inhärent sicherer Meldungen. Ein VPN-Netzwerk ist daher nicht erforderlich (große VPN-Netze erfordern eine enorm komplexe und kostspielige Verwaltung); so werden Probleme bei Verantwortlichkeiten und Zuordnung der Besitzverhältnisse vermieden. Ein Tunnelling ist nicht erforderlich, um eine angemessene Sicherheitsstufe zu erreichen.

In jedem Fall haben die einzelnen Akteure die Möglichkeit, in ausgewählten Teilbereichen des Netzes mehrere Sicherheitsstufen einzurichten oder fortzuführen, wenn sie diese bereits besitzen.

Über das öffentliche Internet lässt sich ein Peer-to-Peer-Hybridmodell mit einem „zentralen Speicher“ und einer „gemeinsamen Schnittstelle“ an den Knoten der einzelnen Akteure einrichten.

Der zentrale Speicher wird zuerst angesprochen, um Meta-Informationen einzuholen, beispielsweise die Identität eines Peers (Akteurs), über den Informationen gespeichert werden, oder um Sicherheitsdaten nachzuprüfen. Anschließend wird eine Peer-to-Peer-Kommunikation zwischen den beteiligten Akteuren aufgebaut.

4.2.14.3.   Protokolle

Es dürfen nur Protokolle verwendet werden, die zur vollständigen Internet-Protokollsuite gehören.

4.2.14.4.   Datensicherheit

Um ein hohes Sicherheitsniveau zu erreichen, müssen alle Meldungen eigenständig sein; das heißt, ihre Inhalte müssen gesichert sein und der Empfänger muss die Authentizität der Meldung nachprüfen können. Dies lässt sich mit einem Verschlüsselungs- und Signatursystem wie bei der E-Mail-Verschlüsselung erreichen. Das gestattet es, eine beliebige Art der Netzwerkübertragung zu verwenden, beispielsweise E-Mail, Dateitransfer (ftp, http) etc. Welcher Typ tatsächlich gewählt wird, liegt dann im Ermessen der am Informationsaustausch beteiligten Parteien.

4.2.14.5.   Verschlüsselung

Es ist entweder eine asymmetrische Verschlüsselung oder eine Hybridlösung mit symmetrischer Verschlüsselung in Kombination mit einem öffentlichen Schlüssel zu verwenden, denn die gemeinsame Nutzung eines geheimen Schlüssels durch zahlreiche Akteure ist irgendwann zum Scheitern verurteilt. Ein höheres Sicherheitsniveau lässt sich leichter erreichen, wenn jeder Akteur die Verantwortung für sein eigenes Schlüsselpaar trägt, wenngleich in diesem Fall der zentrale Speicher (als Schlüssel-Server) ein hohes Maß an Integrität aufweisen muss.

4.2.14.6.   Zentraler Speicher

Der zentrale Speicher muss folgende Dinge handhaben können:

Die Verwaltung des zentralen Speichers sollte in der Zuständigkeit einer nichtkommerziellen, co-europäischen Stelle liegen.

4.2.14.7.   Gemeinsame Schnittstelle

Die „gemeinsame Schnittstelle“ ist für jeden Akteur verbindlich, um sich an der interoperablen Gemeinschaft im Bahnbereich zu beteiligen.

Die gemeinsame Schnittstelle muss Folgendes bearbeiten können:

Jede Instanz der gemeinsamen Schnittstelle hat dabei Zugang zu allen entsprechend der TSI erforderlichen Daten innerhalb jedes EVU, IB usw., gleichgültig, ob die relevanten Datenbanken zentral oder individuell sind (siehe auch Anhang A Index 5 Kapitel 1.6).

Aufgrund der Ergebnisse aus der Authentizitätsprüfung eingehender Meldungen kann eine Minimalstufe für die Meldungsbestätigung eingerichtet werden:

Die gemeinsame Schnittstelle verwendet die Informationen im zentralen Speicher, um die oben beschriebenen Aufgaben zu erfüllen.

Ein Akteur kann eine lokale „Spiegelung“ des zentralen Speichers einrichten, um die Antwortzeiten zu verkürzen.

4.3.   Funktionelle und technische Spezifikationen zu den Schnittstellen

Die funktionellen und technischen Spezifikationen zu den Schnittstellen sind im Hinblick auf die in Kapitel 3 angegebenen grundlegenden Anforderungen Folgende:

4.3.1.   Schnittstellen zum Teilsystem Infrastruktur

Das Teilsystem Infrastrukturen umfasst Verkehrssteuerungs-, Ortungs- und Navigationssysteme: technische Datenverarbeitungs- und Telekommunikationseinrichtungen, die für den Personenfernverkehr und den Güterverkehr auf diesem Netz zur Gewährleistung eines sicheren und ausgewogenen Netzbetriebs und einer wirksamen Verkehrssteuerung vorgesehen sind.

Das Teilsystem Telematikanwendungen für den Güterverkehr benutzt die für betriebliche Zwecke erforderlichen Daten, wie sie vom IB bereitgestellt, im Trassenvertrag festgelegt und möglicherweise in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen aktualisiert sind. Es gibt also keine direkte Schnittstelle zwischen dieser TSI und der TSI Infrastruktur.

4.3.2.   Schnittstellen zum Teilsystem Zugsteuerung, Zugsicherung und Signalgebung

Die einzige Verbindung zur Zugsteuerung/Zugsicherung und Signalgebung besteht über

4.3.3.   Schnittstellen zum Teilsystem Fahrzeuge

Das Teilsystem Telematikanwendungen für den Güterverkehr identifiziert die technischen und die betrieblichen Daten, die für ein Fahrzeug verfügbar sein müssen.

Die TSI Fahrzeuge spezifiziert die Charakteristik eines Wagens. Wenn sich die Charakteristik eines Wagens ändert, so muss dies in der Fahrzeugreferenzdatenbank innerhalb des normalen Prozesses der Datenbankpflege aktualisiert werden. Daher existiert keine direkte Schnittstelle dieser TSI zur TSI Fahrzeuge.

4.3.4.   Schnittstellen zum Teilsystem Betrieb und Verkehrssteuerung

Das Teilsystem Betrieb und Verkehrssteuerung definiert die Verfahren und zugehörige Ausrüstungen, die eine kohärente Ausnutzung der verschiedenen strukturellen Teilsysteme erlauben, und zwar sowohl im Normalbetrieb als auch bei Betriebsstörungen, einschließlich insbesondere der Zugführung, der Planung und der Abwicklung des Verkehrsbetriebs.

Das Teilsystem Telematikanwendungen für den Güterverkehr spezifiziert hauptsächlich Anwendungen für Dienstleistungen im Güterverkehr einschließlich Echtzeit-Überwachung der Güter und Züge und die Anschlüsse zu anderen Verkehrsträgern.

Um die Konsistenz zwischen beiden TSI sicherzustellen, gilt folgendes Verfahren:

Wenn die Spezifikationen der TSI Betrieb und Verkehrssteuerung in Bezug auf Anforderungen dieser TSI geschrieben sind und/oder ergänzt werden, dann muss die für diese TSI verantwortliche Stelle befragt werden.

Für den Fall, dass die Spezifikationen dieser TSI in Bezug auf betriebliche Anforderungen in der TSI Betrieb und Verkehrssteuerung eine Erweiterung erfahren sollten, dann muss die für die TSI Betrieb und Verkehrssteuerung verantwortliche Stelle befragt werden.

4.4.   Betriebsvorschriften

Angesichts der in Kapitel 3 angegebenen grundlegenden Anforderungen ergeben sich für das von der vorliegenden TSI betroffene Teilsystem folgende Betriebsvorschriften:

4.4.1.   Datenqualität

Um die Datenqualität sicherzustellen, ist der Sender jeder TSI-Meldung verantwortlich für die Richtigkeit des Dateninhaltes der Meldung zum Zeitpunkt des Absendens der Meldung. Soweit Quelldaten zur Datenqualitätssicherung aus Datenbanken der TSI verfügbar sind, müssen die Daten dieser Datenbanken zur Sicherstellung der Datenqualität verwendet werden.

Soweit Quelldaten zur Datenqualitätssicherung nicht von Datenbanken der TSI bereitgestellt werden, muss der Absender der Meldung die Überprüfung der Datenqualitätssicherung mit eigenen Mitteln vornehmen.

Datenqualitätssicherung beinhaltet den Vergleich mit Daten aus Datenbanken dieser TSI sowie, soweit anwendbar, zusätzliche logische Prüfungen, um die Rechtzeitigkeit und Kontinuität der Daten und Meldungen zu garantieren.

Daten sind von hoher Qualität, wenn sie für die beabsichtigte Nutzung geeignet sind, was bedeutet, dass sie

Die Datenqualität ist hauptsächlich charakterisiert durch:

Genauigkeit:

Die zu verarbeitenden Informationen (Daten) müssen möglichst ökonomisch erfasst werden. Das ist nur machbar, wenn die Primärdaten, die eine entscheidende Rolle bei der Beförderung einer Fracht, eines Wagens oder Containers spielen, nach Möglichkeit nur ein einziges Mal für den gesamten Transport erfasst werden. Daher sollten die Primärdaten so nahe wie möglich an ihrer Quelle eingegeben werden, z. B. Erstellung der Daten aus dem Frachtbrief, wenn ein Wagen oder eine Fracht zur Beförderung übergeben wird. Nach der Eingabe können die Daten voll in spätere Bearbeitungsgänge integriert werden.

Vollständigkeit:

Vor dem Absenden von Meldungen muss ihre Vollständigkeit und Syntax anhand der Definitionen in den Metadaten geprüft werden. Dadurch wird unnötiger Informationsverkehr im Netz vermieden.

Ebenso müssen alle eingehenden Meldungen auf Vollständigkeit mittels der Metadaten geprüft werden.

Vereinbarkeit:

Um die Vereinbarkeit zu garantieren, müssen Geschäftsregeln (Business Rules) implementiert werden. Doppelte Eingabe sollte vermieden werden, und der Eigentümer der Daten sollte klar feststellbar sein.

Die Art der Implementierung dieser Geschäftsregeln hängt von der Komplexität der Regel ab. Für einfache Regeln sind Datenbankbeschränkungen (Constraints) und Trigger ausreichend. Im Falle komplexerer Regeln, die Daten aus verschiedenen Tabellen benötigen, müssen Gültigkeitserklärungsverfahren (Validation Procedures) implementiert werden, die die Vereinbarkeit der Datenversionen prüfen, bevor Schnittstellendaten erstellt werden und neue Versionen in Betrieb gehen. Es muss sichergestellt werden, dass übertragene Daten auf ihre Gültigkeit gegenüber den definierten Geschäftsregeln überprüft wurden.

Rechtzeitigkeit:

Die rechtzeitige Bereitstellung von Informationen ist ein wichtiger Punkt. Soweit der Anstoß zur Datenspeicherung oder dem Versand von Meldungen ereignisabhängig direkt vom IT-System ausgelöst wird, sollte die Rechtzeitigkeit kein Problem sein, wenn das System entsprechend den Erfordernissen der Geschäftsprozesse entworfen ist. Doch in den meisten Fällen erfolgt der Versand einer Meldung durch einen Bediener oder ist zumindest von zusätzlichen Eingaben eines Bedieners abhängig (zum Beispiel der Versand der Zugbildungsmeldung oder die Aktualisierung von zug- und wagenspezifischen Daten). Um die Pünktlichkeitsanforderungen zu erfüllen, muss die Aktualisierung der Daten so bald wie möglich erfolgen, auch um zu garantieren, dass die Meldungen aktuelle Inhalte haben, wenn sie automatisch vom System verschickt werden.

Generell müssen folgende Anforderungen erfüllt sein:

Die Antwortzeit bei Abfragen muss unter 5 Minuten liegen. Datenaktualisierung und Datenaustausch müssen so früh wie möglich erfolgen. Die Reaktions- und Übertragungszeit für solche Datenaktualisierungen sollte unter 1 Minute liegen.

Daten-Qualitäts-Metrik

Für die Vollständigkeit (Prozent der Datenfelder, in denen Werte eingetragen sind) von obligatorischen Daten und für die Vereinbarkeit von Daten (Prozent der Datenfelder, die in mehreren Tabellen/Dateien/Datensätzen vorkommen und dort überall gleiche Werte aufzeigen) muss ein Prozentsatz von 100 % erreicht werden.

Für die Rechtzeitigkeit von Daten (Prozent der Daten, die innerhalb eines spezifizierten Schwellen-Zeit-Rahmens verfügbar sein müssen) muss ein Prozentsatz von 98 % erreicht werden. Sofern Schwellenwerte nicht in dieser TSI definiert sind, müssen diese Werte in Verträgen zwischen den beteiligten Parteien festgelegt werden.

Die erforderliche Genauigkeit (Prozent der gespeicherten Daten, die verglichen mit den aktuellen Werten übereinstimmen) muss über 90 % liegen. Der genaue Wert und die Kriterien dafür müssen in den Verträgen zwischen den beteiligten Parteien festgelegt werden.

4.4.2.   Betrieb des zentralen Speichers

Die Funktionen des zentralen Speichers sind in Kapitel 4.2.14.6 (Zentraler Speicher) definiert. Zur Sicherstellung der Datenqualität sollte der Betreiber des zentralen Speichers verantwortlich sein für die Aktualisierung und die Qualität der Metadaten und des Verzeichnisses („Telefonbuch“) und auch für die Verwaltung der öffentlichen Zugriffsschlüssel (Public keys). Für die Metadaten muss ein Anteil von 100 % bezüglich Vollständigkeit, Vereinbarkeit, Rechtzeitigkeit und Genauigkeit erreicht werden.

4.5.   Wartungsvorschriften

Die funktionellen und technischen Spezifikationen zu den Schnittstellen sind im Hinblick auf die in Kapitel 3 angegebenen grundlegenden Anforderungen Folgende:

Die Qualität des Güterverkehrs muss auch dann erhalten bleiben, wenn die Datenverarbeitungsanlagen ganz oder teilweise ausfallen. Es empfiehlt sich daher, Duplexsysteme oder Rechner mit besonders hoher Zuverlässigkeit zu installieren, für welche der unterbrechungsfreie Betrieb während Wartungsarbeiten sichergestellt ist.

Die Instandhaltungsaspekte hinsichtlich der verschiedenen Datenbanken sind in Kapitel 4.2.12.3 (Zusätzliche Anforderungen an die Datenbanken), Punkte 10 und 21, beschrieben.

4.6.   Berufliche Qualifikationen

Für den Betrieb und die Wartung des betreffenden Teilsystems sowie für die Anwendung der TSI ist folgende berufliche Qualifikation erforderlich:

Die Implementierung dieser TSI erfordert kein komplett neues System an Hardware und Software mit neuem Personal. Die Realisierung der Anforderungen der TSI führen lediglich zu Änderungen, Modernisierungen oder funktionalen Erweiterungen der Betriebsabläufe, wie sie bereits vom bestehenden Personal ausgeführt werden. Daher gibt es keine über die bestehenden nationalen und europäischen Regeln hinausgehenden Anforderungen an die berufliche Qualifikation.

Ist eine praktische Schulung erforderlich, so sollte dabei den Beschäftigten nicht nur gezeigt werden, wie die Geräte bedient werden. Die Mitarbeiter müssen auch wissen und verstehen, welche spezifische Rolle sie im Gesamtablauf des Transports spielen. Die Beschäftigten müssen sich insbesondere darüber klar sein, dass sie eine anspruchsvolle Tätigkeit ausüben, die sich entscheidend auf die Qualität der Informationsverarbeitung in den nachfolgenden Schritten auswirkt.

Die berufliche Qualifikation, die für die Zugbildung und den Betrieb der Züge notwendig ist, ist in der TSI Betrieb und Verkehrssteuerung festgelegt.

4.7.   Bedingungen für Arbeitshygiene und Sicherheit am Arbeitsplatz

Für das betreffende Personal bestehen hinsichtlich Sicherheit und Gesundheitshygiene am Arbeitsplatz während des Betriebs und der Wartung des betreffenden Teilsystems (bzw. bezüglich des technischen Anwendungsbereichs nach Abschnitt 1.1) sowie bei der Umsetzung der TSI folgende Anforderungen:

Es bestehen keine über die existierenden nationalen und europäischen Regeln hinausgehenden Anforderungen bezüglich Arbeitshygiene und Sicherheit am Arbeitsplatz.

4.8.   Infrastruktur- und Fahrzeugregister

Laut Artikel 24, Absatz 1 der Richtlinie 2001/16/EG „müssen die Mitgliedstaaten dafür Sorge tragen, dass Infrastrukturregister und Fahrzeugregister veröffentlicht und jährlich aktualisiert werden. Darin werden für das jeweilige Teilsystem oder Teile davon die Hauptmerkmale und deren Übereinstimmung mit den in den anzuwendenden TSI vorgeschriebenen Merkmalen dargestellt. Zu diesem Zweck ist in jeder TSI genau anzugeben, welche Angaben die Infrastruktur- und Fahrzeugregister enthalten müssen.“

Aufgrund der jährlichen Aktualisierung und Veröffentlichung dieser Register sind diese für das Teilsystem „Telematikanwendungen für den Güterverkehr“ nicht nutzbar. Daher erfolgen in dieser TSI keine Angaben für diese Register.

5.   Interoperabilitätskomponenten

5.1.   Definition

Gemäß Artikel 2 Buchstabe d der Richtlinie 2001/16/EG gilt:

Die Interoperabilitätskomponenten sind „Bauteile, Bauteilgruppen, Unterbaugruppen oder komplette Materialbaugruppen, die in ein Teilsystem eingebaut sind oder eingebaut werden sollen und von denen die Interoperabilität des konventionellen transeuropäischen Eisenbahnsystems direkt oder indirekt abhängt. Unter ‚Komponenten‘ sind materielle, aber auch immaterielle Produkte wie Software zu verstehen.“

5.2.   Liste der Komponenten

Die Interoperabilitätskomponenten sind Gegenstand der maßgebenden Bestimmungen der Richtlinie 2001/16/EG.

Im Teilsystem „Telematikanwendungen für den Güterverkehr“ sind keine spezifischen Interoperabilitätskomponenten definiert.

Zur Erfüllung der Anforderungen dieser TSI wird nur herkömmliche IT-Ausrüstung benötigt, die keine spezifischen Aspekte für die Interoperabilität in der Eisenbahnumgebung aufweist. Dies gilt für Hardware-Komponenten und für die Standardsoftware, die bei Betriebssystemen und Datenbanken zum Einsatz kommt. Die Anwendungssoftware ist auf der Benutzerseite jeweils individuell und kann je nach Funktionalität und Bedarf angepasst und verbessert werden. Die vorgeschlagene „Anwendungsintegrationsarchitektur“ unterstellt, dass die Anwendungen wahrscheinlich nicht dasselbe interne Informationsmodell benutzen. Anwendungsintegration ist definiert als ein Prozess, in dem unabhängig voneinander konstruierte Anwendungssysteme zu einer Zusammenarbeit gebracht werden.

5.3.   Leistungsmerkmale und Spezifikationen der Komponenten

Siehe Kapitel 5.2, für die TSI „Telematikanwendungen für den Güterverkehr“ nicht relevant.

6.   Bewertung der Konformität und/oder Gebrauchstauglichkeit der Komponenten und Prüfung des Teilsystems

6.1.   Interoperabilitätskomponenten

6.1.1.   Bewertungsverfahren

Im Falle der Interoperabilitätskomponenten muss das Bewertungsverfahren für die Konformität bzw. die Gebrauchstauglichkeit auf europäischen Spezifikationen oder auf solchen Spezifikationen beruhen, die entsprechend den Regelungen der Richtlinie 2001/16/EG anerkannt sind.

Handelt es sich um die Ermittlung der Gebrauchstauglichkeit, so geben diese Spezifikationen die Gesamtheit der Werte oder physikalischen Größen an, die zu messen, zu kontrollieren oder zu beobachten sind, ferner die dazugehörigen Versuchsmethoden und Messverfahren, sei es bei Versuchen im Labor oder auf der Strecke.

Verfahren für die Bewertung der Konformität und/oder der Gebrauchstauglichkeit:

Liste der Spezifikationen, Beschreibung der Versuchsmethoden:

6.1.2.   Module

Auf Verlangen des Herstellers oder seines in der Gemeinschaft ansässigen Bevollmächtigten hat das Bewertungsverfahren durch eine benannte Stelle entsprechend den Regelungen über die maßgebenden Module laut Entschließung des Rates 93/465/EWG zu erfolgen, wie sie in modifizierter und ergänzter Form im Anhang dieser TSI wiedergegeben sind.

Die Module werden je nach Komponente selektiv miteinander verbunden und benutzt.

6.2.   Teilsystem Telematikanwendungen für den Güterverkehr

Auf Verlangen des Auftraggebers oder seines in der Gemeinschaft ansässigen Bevollmächtigten führt die benannte Stelle entsprechend den Regelungen in Anhang VI der Richtlinie 2001/16/EG die EG-Prüfung durch.

Entsprechend Anhang II der Richtlinie 2001/16/EG sind die Teilsysteme aufgeteilt in Teilsysteme des strukturellen Bereichs und Teilsysteme des operativen Bereichs.

Die Konformitätsbewertung ist für TSI des strukturellen Bereichs verbindlich. Das Teilsystem Telematikanwendungen für den Güterverkehr gehört zum funktionellen Bereich, daher sind in dieser TSI keine Module zur Konformitätsbewertung erstellt.

Jedoch bilden der zentrale Speicher und eine gemeinsame Schnittstelle zu den Knoten der jeweiligen Akteure das Rückgrat der Anwendungsintegration. Das Modell für den Informationsaustausch ist im zentralen Anwendungsintegrationsspeicher hinterlegt, der die Schnittstellen-Metadaten an einem physischen Ort enthält. Die Metadaten enthalten Informationen über den Kommunikationsinhalt (was sich in den gesendeten Daten befindet), die Kennungen der Absender und Empfänger sowie die Mechanik des Interaktionsprozesses der Geschäftsprotokolle auf Anwendungsebene.

Folgende Punkte sind von Bedeutung:

7.   UMSETZUNG

7.1.   Modalitäten der Anwendung dieser TSI

7.1.1.   Einführung

Mit dieser TSI soll der Prozess des Transports von Gütern auf der Schiene informationsseitig unterstützt werden, um zu einer spürbaren Verbesserung der Qualität der Transportleistungen zu gelangen. Somit ist ihre Anwendung unabhängig vom Konzept der Neu-, Modernisierungs- oder Altanlagen im Bereich Infrastruktur bzw. Fahrzeuge, wie es in anderen, nach der Richtlinie 2001/16/EG erforderlichen TSI üblich ist.

Angesichts ihres umfassenden Charakters wird diese TSI tief greifende Auswirkungen auf die wirtschaftlichen und betrieblichen Vorgänge in allen Bereichen der europäischen Eisenbahnindustrie haben. Darüber hinaus erfordert die stetige Zunahme des Bedarfs an grenzüberschreitenden Güterverkehrsleistungen ein europaweites Konzept für das Informationsmanagement. Angesichts dieser Sachlage ist die Erstellung eines transeuropäischen Umsetzungsplans für diese TSI unumgänglich. Ein solcher Plan sollte sowohl ein klares Bild dessen vermitteln, was bei der Umsetzung der TSI erreicht werden soll, als auch den Weg und den zeitlichen Ablauf aufzeigen, um den Übergang von der derzeitigen Situation einer Vielzahl einzelner Informationssysteme zu einer umfassenden europaweiten Informationsautobahn zu bewerkstelligen, von der alle am Schienenverkehr Beteiligten (Betreiber der Infrastruktur, Eisenbahnverkehrsunternehmen, Spediteure und letztlich auch der Kunde) profitieren können.

Vor diesem Hintergrund wird das Konzept eines Europäischen Strategischen Umsetzungsplans (ESUP) befürwortet. Im ESUP wird das zu erreichende Zielsystem festgelegt, damit diese TSI und der zugrunde liegende Umsetzungsplan so verwirklicht werden können, wie dies im folgenden Abschnitt beschrieben wird.

7.1.2.   Europäischer Strategischer Umsetzungsplan (ESUP)

7.1.2.1.   Zielsetzungen des ESUP

Mit dem Europäischen Strategischen Umsetzungsplan (ESUP) werden Absichten in dreierlei Hinsicht verfolgt:

Abgesehen von der Aufstellung eines die Transparenz des gesamten Umsetzungsprozesses fördernden Zeitplans für die Erfüllung der TAF TSI sind mit dem ESUP geeignete Anhaltspunkte für die Überwachung der Fortschritte zu schaffen, die die Beteiligten (Betreiber der Infrastruktur, Eisenbahnverkehrsunternehmen, Spediteure und letztlich auch der Kunde) erzielen. Dabei ist so vorzugehen, dass es der Wahrung der Interessen der Beteiligten am besten entspricht. Das betrifft vornehmlich die Mittel, die die Betreiber der Infrastruktur und die Eisenbahnverkehrsunternehmen für die möglicherweise erforderliche Modernisierung und Integration ihrer alten IT-Systeme aufbringen müssen, und die Fähigkeit der TAF-TSI-basierten Systeme, den sich ständig erhöhenden Informationsbedürfnissen der Spediteure und Kunden nachzukommen.

Vor diesem Hintergrund muss es sich beim ESUP letztlich um ein Instrument handeln, mit dem die gesamte europäische Bahnindustrie auf das Ziel der Schaffung eines gesamteuropäischen Informationssystems ausgerichtet wird, wobei ausreichend Spielraum bestehen sollte, um Synergieeffekte zu nutzen, eine Zersplitterung zu vermeiden und die in begrenztem Umfang zur Verfügung stehenden Ressourcen auf die vorrangigen Aufgaben zu lenken, mit denen die Qualitätsziele für die Erbringung von Transportleistungen am besten erreicht werden können.

7.1.2.2.   ESUP-Anforderungen

Die Ausarbeitung eines solchen Plans erfordert eine systematische Analyse der entsprechenden technischen, betrieblichen, wirtschaftlichen und institutionellen Aspekte, die dem Umsetzungsprozess der TAF TSI zugrunde liegen. Das umfasst insbesondere:

Anstatt eine bestimmte Abfolge von Schritten zu wählen, sollte während der Analyse ein iterativer Weg beschritten und so die optimale Systemeinsatzstrategie gefunden werden. Am Ende dieses Abklärungszyklus sollten folgende konkrete Ergebnisse stehen:

7.1.3.   Modalitäten der Umsetzung

Die Modalitäten für die Anwendung dieser TSI unterliegen den Erfordernissen des bereits erläuterten Europäischen Strategischen Umsetzungsplans (ESUP).

An die Ausarbeitung des ESUP werden die folgenden Anforderungen gestellt.

7.2.   Migrationsstrategie

Für den Übergangszeitraum zwischen den derzeitigen Gegebenheiten der Nutzung unterschiedlicher Informationssysteme und der Erfüllung dieser TSI, wie im ESUP verlangt, müssen Migrationsstrategien entworfen werden.

Daher wurden in dieser TSI zur Erleichterung des Übergangs entsprechende Informationshandhabungskonzepte entwickelt. Sie ermöglichen die stufenweise Errichtung des angestrebten gesamteuropäischen Systems der Telematikanwendungen für den Güterverkehr, und zwar insbesondere durch Einrichtungen wie die Peer-to-Peer-Kommunikation auf der Basis beispielsweise des Konzepts der Speicher für aggregierte Daten (einschließlich Metadaten zu den Meldungen, Datenverzeichnis und Zertifizierung).

Wie der Informationsaustausch zwischen einem EVU und einem IB sich in der Praxis gestalten könnte, soll anhand eines Beispiels erläutert werden. Das Beispiel zeigt nur die logischen Kommunikationsabhängigkeiten zwischen den Systemen. Es erfolgt eine Unterteilung in einzelne Schritte, ohne dass dabei spezielle Migrationserfordernisse berücksichtigt werden, die bei einzelnen Systemen auftreten können. Diese Erfordernisse sind bei der Aufstellung des ESUP angemessen zu berücksichtigen.

Schritt 1: Die in Kapitel 4.2.14 (Vernetzung und Kommunikation) beschriebene allgemeine Architektur sieht einen „zentralen Speicher“ vor, der von einer noch zu definierenden neutralen und unabhängigen Gesellschaft betrieben wird. Am Standort jedes Teilnehmers im Kommunikationsnetz wird eine Schnittstellenebene für die Interoperabilität spezifiziert, die eventuell einen Meldungsformat-Konverter einschließt und die zentral oder individuell erstellt werden kann. Diese Teile sind im Hinblick auf „Vernetzung und Kommunikation“ die einzigen betrieblichen Aspekte, die für die Interoperabilität erforderlich sind. Sie sind zugleich die Grundvoraussetzungen für den europaweiten Datenaustausch. Daher müssen sie realisiert und installiert werden, bevor irgendeine andere Funktion in Betrieb gehen kann.

Nach diesem Schritt kann bereits die elektronische Übertragung der Dokumente (Kapitel 4.2.13: Elektronische Übertragung von Dokumenten) erfolgen, unabhängig von der logischen Abfolge der anderen Schritte.

Schritt 2: Gleichzeitig oder kurz nach Schritt 1 müssen die Fahrzeugreferenzdatenbanken (Kapitel 4.2.11.3: Die Fahrzeugreferenzdatenbank und Kapitel 4.2.12.2: Weitere Datenbanken) zur Verfügung stehen. Sollten noch nicht alle Daten bereits in den Datenbanken vorhanden sein, so muss es zumindest möglich sein, die Daten für jeden einzelnen Wagen eines Zuges manuell in die Betriebsdatenbank für Wagen und Intermodaleinheiten einzugeben, die gemäß Anhang A Ziffer 2 für den Bahntransport mindestens benötigt werden.

Schritt 3: Gleichzeitig oder kurz nach Schritt 2 muss für den Zugriff von außen auf die verschiedenen Datenbanken die gemeinsame Schnittstelle realisiert und implementiert werden.

Für den nächsten Schritt muss erwähnt werden, dass die vorgeschlagene Architektur eine reibungslose Inbetriebnahme der verschiedenen Funktionen, mit denen die Anforderungen des Teilsystems Telematikanwendungen für den Güterverkehr erfüllt werden, erlaubt. Auf der Grundlage des zentralen Speichers (Metadaten für Meldungen, Telefonbuch und Autorisierung) ist es möglich, den Datenaustausch zwischen zwei Partnern individuell in Abhängigkeit vom Meldungstyp zu ermöglichen.

Schritt 4: Die Meldungen der Zugtrassenanträge können unabhängig von den nächsten Schritten implementiert werden, für Schritt 6 muss die Trasse jedoch bereits mit einer Trassennummer versehen sein.

Schritt 5: Die Beförderungsauftragsdaten liefern Basisinformationen für die Zugbildung, daher können diese Meldungen vor Schritt 6 in Betrieb gehen.

Schritt 6: Die Inbetriebnahme von Zugvorbereitungsmeldungen ist der nächste Schritt, wobei der Versand von Zugbildungsmeldungen der wichtigste Teil ist und zuerst realisiert werden sollte.

Schritt 7: Spätestens vor Schritt 8 sollten die Wagenbewegungsfunktionen „Wagenfreigabe- und -abfahrtmeldung, Wagenankunft Rangierbahnhof, Wagenabfahrt Rangierbahnhof, Wagenankunft und Wagenablieferung/Bestätigung“ zusammen mit der Tourenplanungsfunktionalität auf EVU-Ebene realisiert werden.

Schritt 8: Im nächsten Schritt sollten „Zugfahrtmeldung“ und „Zugfahrtprognose“ realisiert werden. Mit der Meldung „Zugfahrtprognose“ kann die „Voraussichtliche Ankunftszeit des Zuges (PZAZ bzw. PZÜ)“ gesendet werden. Diese bildet die Basis für die Berechnung der wagen-/ladungsbezogenen PÜZ und der PAZ. Dieser Schritt enthält auch die Realisierung der Abfrage/Antwort „Zugfahrtmeldung“ und „Zugfahrtprognose“.

Schritt 9: Wagenübergangsmeldung (Kapitel 4.2.9: Berichtswesen Wagenübergang) und die Funktionalität von Kapitel 4.2.7 (Ladung PÜZ/PAZ) sollten gleichzeitig mit oder kurz nach Schritt 8 in Betrieb gehen. Dies ist besonders für die EVU von Bedeutung.

Schritt 10: Die Realisierung der Funktionalität „Verkehrsunterbrechungsmeldung“ ist ein Teil von Schritt 10, zusammen mit der Realisierung von Abfrage/Antwort für „Zugverspätung“, „Zugkennung“ und „Zug am Meldepunkt“. Basierend auf der Verkehrsunterbrechungsinformation kann die Ausnahmemeldung auf EVU-Ebene (Kapitel 4.2.8.6: Wagenausnahme und Kapitel 4.2.8.7: Wagenausnahme neue PÜZ/PAZ erforderlich) in Betrieb gehen.

Schritt 11: Nach einer Konsolidierungsphase kann die Auswertung übertragener und gespeicherter Daten zur Qualitätssteigerung in Betrieb gehen.

7.3.   Änderungsmanagement

7.3.1.   Einführung

Dass an computerbasierten Systemen Änderungen vorgenommen werden, ist ein alltäglich anzutreffender Vorgang. Änderungen entstehen durch das Auftreten neuer Anforderungen oder durch Veränderungen an bestehenden Anforderungen aufgrund von Fehlern während des Betriebs oder die Notwendigkeit von Verbesserungen an den Leistungs- bzw. nichtfunktionellen Merkmalen.

Änderung ohne gezieltes Management ist nicht denkbar, sollen doch Betriebskontinuität und Rückwärtskompatibilität aufrechterhalten werden, damit der Betrieb bestehender IT-Anlagen mit TAF-Funktionalität (so genannter IT-Altanlagen) mit einem Minimum an Zeitverlust und Kosten verbunden ist. Somit kommt es darauf an, eine klare Strategie für die Art und Weise festzulegen, wie Änderungen an bestehenden IT-Anlagen zu verwalten sind, ohne dass der Eisenbahnbetrieb unterbrochen und den grundlegenden Zielen der Gewährleistung der Kontinuität des Dienstes und der Interoperabilität geschadet wird. Die Festlegung einer solchen Strategie stützt sich auf zwei Hauptpunkte:

7.3.2.   Festlegung der Baselines

Systemstabilität ist für eine realistische Umsetzung und Anwendung von wesentlicher Bedeutung. Der Stabilitätsbedarf betrifft alle Parteien:

Kurz gesagt, umfasst eine Baseline das Konzept der Gewährleistung eines stabilen Kerns bezüglich Systemfunktionalität, Leistung und sonstiger nicht funktioneller Merkmale (z. B. RAM) (9). Wie die Erfahrung mit dieser Art von Systemen jedoch gezeigt hat, muss erst eine ganze Reihe von Versionen (10) herausgegeben werden, um eine stabile und für die Umsetzung geeignete Baseline vorzulegen. Dies kann als folgender Kaskadenprozess veranschaulicht werden:

Durch seine Rückkopplungsschleifen ist ein solcher Prozess in hohem Maße verwoben. Somit ist eine Parallelschaltung mehrerer dieser Prozesse ausgeschlossen, eine Herangehensweise, die zu Instabilität, Chaos und Behinderung des Betriebs führen würde. Baselines müssen dementsprechend nacheinander und nicht parallel verarbeitet werden:

7.3.3.   Herausgabe von Baselines

Auf der Grundlage aktueller Erfahrungen kann gesagt werden, dass zwischen der Herausgabe jeweils neuer Baselines etwa vier bis fünf Jahre liegen sollten.

Eine neue Baseline sollte stets an größere Veränderungen der Systemfunktionalität oder der Systemleistung gebunden sein. Dazu können folgende Aspekte gehören:

Jede Baseline sollte auch die Funktionalität der vorhergehenden Baseline besitzen. Fehlersuchversionen zur Behebung von Systemfehlern oder Sicherheitsmängeln sollten als Version einer bestimmten Baseline behandelt werden. Sofern dies nicht von Sicherheitsmaßnahmen verhindert wird, müssen die Versionen innerhalb ein und derselben Baseline rückwärtskompatibel sein.

Sind Baselines mit zusätzlicher Funktionalität ausgestattet, so ergibt sich zwangsläufig, dass sie nicht rückwärtskompatibel sind. Zur Ermöglichung der Migration und in dem aus technischer Sicht möglichen Umfang sollten die Baselines einen gemeinsamen Funktionalitätskern aufweisen, für den Rückwärtskompatibilität gewährleistet werden muss. Mit dem gemeinsamen Kern sollte ein Mindestkern zur Verfügung stehen, der bei akzeptabler Leistung interoperable Datendienste ermöglicht.

7.3.4.   Umsetzung neuer Baselines

Für die Betreiber der Infrastruktur und die Eisenbahnverkehrsunternehmen ist es unmöglich, über Nacht von einer Baseline auf die nächste umzustellen. Daher muss künftig jede Baseline zusammen mit einer geeigneten Migrationsstrategie entwickelt werden. Das bedeutet, dass Probleme betrachtet werden müssen, zu denen u. a. Folgendes gehört: das Nebeneinanderbestehen von TAF-Einrichtungen, die unterschiedlichen Versionen der TAF-Spezifikationen entsprechen, bevorzugte Migrationspfade (nämlich Trassenpriorität, Wagenpriorität oder beides parallel) sowie die Informationszeitrahmen und die Prioritäten für die Migration.

7.3.5.   Der Prozess des Änderungsmanagements — Anforderungen

Wie bereits erwähnt, ist der Vorgang der Änderung eng mit großen softwarebasierten Systemen verbunden. Künftig sollten Änderungsmanagementverfahren so konzipiert werden, dass Kosten und Nutzen der Änderung richtig analysiert und Änderungen kontrolliert umgesetzt werden. Das erfordert einen festgelegten Änderungsmanagementprozess und damit verbundene Tools, damit sichergestellt wird, dass Änderungen protokolliert und kostengünstig auf die Spezifikationen angewandt werden. Unabhängig davon, welche spezifischen Details ein solcher Prozess letztlich umfasst, sollte er folgendermaßen allgemein auf einem gegliederten Ansatz beruhen:

Ein Konfigurationsmanagementplan, in dem die Standards und Verfahrensweisen für das Änderungsmanagement festgelegt sind, sollte als Grundlage für den gesamten Änderungsmanagementprozess dienen. Die allgemeingültigen Anforderungen an einen solchen Plan werden in nachstehendem Abschnitt 7.3.6 erläutert. Die Umsetzungsstrategie für bestätigte Änderungen sollte (basierend auf einem ordnungsgemäßen Prozess und ordnungsgemäßer Dokumentierung) in einem Änderungsmanagementplan formalisiert werden, der insbesondere Folgendes umfasst:

Ein wichtiger Teil des Änderungsmanagementprozesses ist die Festlegung der Verantwortlichkeiten für die Vorlage der Spezifikationen sowie für die Qualitätssicherung und das Konfigurationsmanagement. Die meisten dieser Aufgaben sollen durch die Europäische Eisenbahnagentur (errichtet mit der Verordnung 881/2004/EG) übernommen oder kontrolliert werden, sobald diese ihre Arbeit aufnimmt. Der Änderungsmanagementprozess sollte in den Dokumentationen formalisiert werden, auf die in Anlage A Bezug genommen wird.

Schließlich ist es wichtig, dass dem Änderungskontrollausschuss (Change Control Board — CCB), der eines Tages als Gesamtsystembehörde agieren wird, ein repräsentativer Querschnitt aller betroffenen Parteien (Betreiber der Infrastruktur, Eisenbahnverkehrsunternehmen, Zulieferindustrie, benannte Stellen und Regulierungsbehörden) angehört. Die Mitgliedschaft der Parteien in dieser Form müsste sicherstellen, dass die durchzuführenden Änderungen aus der Sicht des Systems betrachtet und ihre Auswirkungen umfassend bewertet werden. Der CCB wird letzten Endes unter die Schirmherrschaft der Europäischen Eisenbahnagentur gestellt.

7.3.6.   Der Plan für das Konfigurationsmanagement — Anforderungen

Im Konfigurationsmanagementplan werden die Standards und Verfahrensweisen für das Änderungsmanagement, das vor allem Folgendes umfasst, beschrieben:

Die konkreten Details des Konfigurationsmanagementprozesses sind mit Spezifikationen, die in die Spezifikationsliste in Anlage A zu dieser TSI aufzunehmen sind, auf eine formale Grundlage zu stellen.

7.4.   Sonderfälle

7.4.1.   Einführung

In den nachstehenden spezifischen Fällen sind folgende Sonderbestimmungen zulässig.

Sonderfälle werden in zwei Kategorien eingeteilt: die Bestimmungen gelten entweder permanent (Fall „P“) oder temporär (Fall „T“). In den temporären Fällen wird den betreffenden Mitgliedstaaten empfohlen, sich dem Zielteilsystem anzupassen, und zwar entweder bis zum Jahr 2010 (Fall „T1“), gemäß der Entscheidung Nr. 1692/96/EG des Europäischen Parlaments und des Rates vom 23. Juli 1996 über die gemeinschaftlichen Leitlinien für den Aufbau des transeuropäischen Verkehrsnetzes (11), oder bis zum Jahr 2020 (Fall „T2“). „T offen“ wird als nicht bestimmter Zeitraum definiert, der in einer künftigen Revision dieser TSI festgelegt wird.

7.4.2.   Verzeichnis der Sonderfälle

7.4.2.1.   Sonderfall für EU-Mitgliedstaaten mit Grenzen zu Drittländern

Auf dem Hoheitsgebiet von EU-Mitgliedstaaten, die an Drittländer angrenzen, sind die Anforderungen dieser TSI für Transporte, die direkt aus diesen Drittländern kommen oder in diese gehen (Fall „T offen“), nicht bindend.

Wenn jedoch der Transportweg in einem anderen EU-Mitgliedsstaat weitergeführt wird, müssen die Anforderungen dieser TSI vollständig erfüllt werden, vorausgesetzt, dass zwischen den betreffenden Staaten oder zwischen Eisenbahnverkehrsunternehmen und Infrastrukturbetreibern, die im Hoheitsgebiet dieser Mitgliedstaaten tätig sind, kein bilaterales oder multilaterales Abkommen besteht.

7.4.2.2.   Sonderfall für Griechenland

Bei Transportfahrten auf Strecken mit Spurweite 1 000 mm gelten die einzelstaatlichen Vorschriften.

----

(1)ABl. L 75 vom 15.3.2001, S. 29. Richtlinie zuletzt geändert durch die Richtlinie 2004/49/EG (ABl. L 164 vom 30.4.2004, S. 44). Berichtigung im ABl. L 220 vom 21.6.2004, S. 16.

(2)ABl. L 220 vom 30.8.1993, S. 23.

(3)ABl. L 75 vom 15.3.2001, S. 26.

(4)ABl. L 237 vom 28.4.1991, S. 25. Richtlinie zuletzt geändert durch die Richtlinie 2004/51/EG des Europäischen Parlaments und des Rates (ABl. L 164 vom 30.4.2004, S. 164). Berichtigung im ABl. L 220 vom 21.6.2004, S. 58.

(5)  Unter Abfahrtspunkt ist der Anfangspunkt der Trasse zu verstehen; dies kann entweder der Abfahrtsort des Zuges für die Gesamtfahrt oder ein Wagenübergangspunkt sein. Der Übergabepunkt ist der Endpunkt der Trasse.

(6)  Der Zugang zu dieser Information muss unabhängig sein davon, welcher IB die Informationen bzw. Teile der Information abgespeichert hat.

(7)  z.B. Qualitätssicherungsstandards, Methodik für die Systementwicklung, Prüfmethodik, Planung der Dokumentation.

(8)  Bestehende Telematikanwendungen für den Güterverkehr sind Telematikanwendungen für den Güterverkehr, die bereits vor Inkrafttreten dieser TSI in Betrieb sind.

(9)  Eine Baseline dient als Referenzausgangspunkt für ein kontrolliertes Management der Systementwicklung.

(10)  Eine Version ist eine Version des betreffenden Systems, die dem Eisenbahnkunden übergeben wird. Systemversionen weisen Unterschiede hinsichtlich Funktionalität und Leistung auf oder können der Behebung von Systemfehlern oder Sicherheitsmängeln dienen.

(11)ABl. L 228 vom 9.9.1996, S. 1. Entscheidung zuletzt geändert durch die Entscheidung Nr. 884/2004/EG (ABl. L 167 vom 30.4.2004). Berichtigung im ABl. L 201 vom 7.6.2004, S. 1.

ANHANG A

LISTE DER BEGLEITENDEN DOKUMENTE

Liste der verbindlichen Spezifikationen

ANHANG B

GLOSSAR

----

(1)ABl. L 156 vom 28.6.1969, S. 1. Verordnung zuletzt geändert durch die Verordnung (EWG) Nr. 1893/91 (ABl. L 169 vom 29.6.1991, S. 1).

----