ANHANG

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

INHALTSVERZEICHNIS:

1.	EINFÜHRUNG

1.1.	Technischer Anwendungsbereich

1.2.	Geografischer Anwendungsbereich

1.3.	Inhalt dieser TSI

2.	DEFINITION DES TEILSYSTEMS/ANWENDUNGSBEREICH

2.1.	In der TSI behandelte Funktionen

2.2.	In der TSI nicht behandelte Funktionen

2.3.	Übersicht über die Beschreibung des Teilsystems

2.3.1.

Beteiligte Unternehmen

2.3.2.

Betrachtete Prozesse

2.3.3.

Allgemeine Anmerkungen

3.	GRUNDLEGENDE ANFORDERUNGEN

3.1.	Einhaltung der grundlegenden Anforderungen

3.2.	Aspekte der grundlegenden Anforderungen

3.3.	Allgemeine Anforderungen

3.3.1.

Sicherheit

3.3.2.

Zuverlässigkeit und Betriebsbereitschaft

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

4.2.	Funktionelle und technische Spezifikationen zum Teilsystem

4.2.1.

Frachtbriefdaten

4.2.2.

Beantragung einer Trasse

4.2.3.

Zugvorbereitung

4.2.4.

Prognose zur Zugfahrt

4.2.5.

Information über Verkehrsunterbrechung

4.2.6.

Abfragen zum Zugstandort

4.2.7.

Ladung PÜZ/PAZ

4.2.8.

Berichtswesen Wagenbewegung

4.2.9.

Berichtswesen Wagenübergang

4.2.10.

Datenaustausch zur Qualitätsverbesserung

4.2.11.

Die Hauptreferenzdaten

4.2.12.

Diverse Referenzdateien und Datenbanken

4.2.13.

Elektronische übertragung von dokumenten

4.2.14.

Vernetzung und kommunikation

4.3.	Funktionelle und technische spezifikationen zu den schnittstellen

4.3.1.

Schnittstellen zum teilsystem infrastruktur

4.3.2.

Schnittstellen zum teilsystem zugsteuerung, zugsicherung und signalgebung

4.3.3.

Schnittstellen zum teilsystem fahrzeuge

4.3.4.

Schnittstellen zum teilsystem betrieb und verkehrssteuerung

4.4.	Betriebsvorschriften

4.4.1.

Datenqualität

4.4.2.

Betrieb des zentralen speichers

4.5.	Wartungsvorschriften

4.6.	Berufliche qualifikationen

4.7.	Bedingungen für Arbeitshygiene und Sicherheit am Arbeitsplatz

4.8.	Infrastruktur- und Fahrzeugregister

5.	INTEROPERABILITÄTSKOMPONENTEN

5.1.	Definition

5.2.	Liste der Komponenten

5.3.	Leistungsmerkmale und spezifikationen der Komponenten

6.	BEWERTUNG DER KONFORMITÄT UND/ODER GEBRAUCHSTAUGLICHKEIT DER KOMPONENTEN UND PRÜFUNG DES TEILSYSTEMS

6.1.	Interoperabilitätskomponenten

6.1.1.

Bewertungsverfahren

6.1.2.

Module

6.2.	Teilsystem Telematikanwendungen für den Güterverkehr

7.

UMSETZUNG

7.1.	Modalitäten der Anwendung dieser TSI

7.1.1.

Einführung

7.1.2.

Europäischer Strategischer Umsetzungsplan (ESUP)

7.1.3.

Modalitäten der Umsetzung

7.2.	Migrationsstrategie

7.3.	Änderungsmanagement

7.3.1.

Einführung

7.3.2.

Festlegung der Baselines

7.3.3.

Herausgabe von Baselines

7.3.4.

Umsetzung neuer Baselines

7.3.5.

Der Prozess des Änderungsmanagements — Anforderungen

7.3.6.

Der Plan für das Konfigurationsmanagement — Anforderungen

7.4.	Sonderfälle

7.4.1.

Einführung

7.4.2.

Verzeichnis der Sonderfälle

ANHANG A:

LISTE DER BEGLEITENDEN DOKUMENTE

ANHANG B:

GLOSSAR

TABELLEN:

Tabelle 1:

Beantragung einer Trasse

Tabelle 2:

Trassenstornierung durch das EVU

Tabelle 3:

Trassenstornierung durch den IB

Tabelle 4:

Empfangsbestätigung

Tabelle 5:

Zugvorbereitung

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:

a)

gibt diese TSI den vorgesehenen Anwendungsbereich der TSI Telematikanwendungen für den Güterverkehr an — Kapitel 2: Definition des Teilsystems/Anwendungsbereich; 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.

b)	nennt diese TSI die grundlegenden Anforderungen an dieses Teilsystem und seine Schnittstellen mit anderen Teilsystemen — Kapitel 3: Grundlegende Anforderungen

c)	legt diese TSI die funktionellen und technischen Spezifikationen fest, denen das Teilsystem und seine Schnittstellen mit anderen Teilsystemen entsprechen müssen — Kapitel 4: Beschreibung des Teilsystems

d)

bestimmt diese TSI die Interoperabilitätskomponenten und Schnittstellen, die Gegenstand europäischer Spezifikationen einschließlich europäischer Normen sind, die zur Verwirklichung der Interoperabilität im konventionellen transeuropäischen Eisenbahnsystem erforderlich sind — Kapitel 5: Interoperabilitätskomponenten

e)

gibt diese TSI für jeden in Betracht kommenden Fall die Verfahren zur Bewertung der Konformität oder der Gebrauchstauglichkeit an. Dies umfasst insbesondere die Module gemäß dem Beschluss 93/465/EWG des Rates (2) oder gegebenenfalls die spezifischen Verfahren, die entweder zur Konformitätsbewertung oder zur Gebrauchstauglichkeitsbewertung der Interoperabilitätskomponenten sowie zur EG-Prüfung der Teilsysteme verwendet werden müssen — Kapitel 6: Bewertung der Konformität und/oder Gebrauchstauglichkeit der Komponenten und Prüfung des Teilsystems

f)	gibt diese TSI die Strategie zur Umsetzung der TSI an. Insbesondere sind die zu erreichenden Phasen festzulegen, damit sich schrittweise ein Übergang vom gegebenen Zustand zum Endzustand, in dem das Einhalten der TSI die Regel ist, ergibt — Kapitel 7: Umsetzung

g)

gibt diese TSI für das betreffende Personal die Bedingungen in Bezug auf die berufliche Qualifikation sowie die Arbeitshygiene und Sicherheit am Arbeitsplatz an, die für den Betrieb und die Wartung des betreffenden Teilsystems sowie für die Umsetzung der TSI erforderlich sind — Kapitel 4: Beschreibung des Teilsystems

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:

—	Anwendungen im Güterverkehr, einschließlich der Informationssysteme (Verfolgung der Güter und der Züge in Echtzeit);

—	Rangier- und Zugbildungssysteme;

—	Buchungssysteme, wobei hier die Buchung von Zugtrassen gemeint ist;

—	Anschlüsse zu anderen Verkehrsträgern und die Erstellung elektronischer Begleitdokumente.

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):

—

Wagen

—	Lokomotiven

—	Triebfahrzeugführer

—	Weichenstellen und Rangieren über Ablaufberg

—	Trassenvertrieb

—	Frachtmanagement

—	Zugbildung

—	Zugbetrieb

—	Zugüberwachung

—	Zugsteuerung

—	Frachtüberwachung

—	Inspektionen und Reparaturen von Wagen und/oder Lokomotiven

—	Zollabfertigung

—	Betrieb von intermodalen Terminals

—	Speditionsmanagement.

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:

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.

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:

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:

—

DEFINIEREN von Dienstleistungen bezüglich Preisen und Transitzeiten, Wagenbereitstellung (soweit zutreffend), Angaben zu Wagen/Intermodaleinheiten (Standort, Status und voraussichtliche Ankunftszeit (PAZ) des Wagens/der Intermodaleinheit), wo Fracht auf leere Wagen, Container verladen werden kann etc.;

—

ERBRINGEN der definierten Leistung auf zuverlässige, reibungslose Art durch Einsatz gemeinsamer Geschäftsprozesse und vernetzter Systeme. Es muss eine Möglichkeit bestehen, dass EVU, IB sowie andere Dienstleister und Beteiligte, wie z. B. der Zoll, Informationen auf elektronischem Weg austauschen können;

—

MESSEN der Qualität der erbrachten Dienstleistung im Vergleich zu vorab getroffenen Festlegungen, z. B. Abrechnungsgenauigkeit im Vergleich zum angebotenen Preis, tatsächliche Transitzeiten im Vergleich zu zugesagten Zeiten, bestellte Wagen im Vergleich zu bereitgestellten, vorhergesagten Ankunftszeiten (PAZ) im Vergleich zu tatsächlichen Ankunftszeiten;

—	BETREIBEN im Sinne einer produktiven Nutzung von Zug-, Infrastruktur- und Flottenkapazität durch den Einsatz von Geschäftsprozessen, Systemen und Datenaustausch, wie sie zur Unterstützung des Wagens/der Intermodaleinheit und des Zugfahrplans erforderlich sind.

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:

—	wann die Wagen einen Rangierbahnhof oder einen definierten Standort verlassen oder erreicht haben (Kapitel 4.2.8 Berichtswesen Wagenbewegung

—	wann in der Transportkette die Verantwortung für die Wagen von einem EVU auf das nächste EVU übergegangen ist (Kapitel 4.2.9 Berichtswesen Wagenübergang

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

—	zur — mittelfristig — detaillierteren Planung des Produktionsprozesses und

—	zur — auf lange Sicht — Durchführung strategischer Planungsübungen und Kapazitätsstudien (z. B. Netzanalysen, Festlegung von Abstellgleisen und Rangierbahnhöfen, Fahrzeugplanung), aber vor allem

—	zur Verbesserung der Transportqualität und Produktivität (Kapitel 4.2.10 (Datenaustausch zur Qualitätsverbesserung).

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.:

—	Identifizierung des Fahrzeugs,

—	Technische/Konstruktionsdaten,

—	Bewertung der Kompatibilität mit der Infrastruktur,

—	Bewertung der relevanten Beladungsmerkmale,

—	Bremsrelevante Merkmale,

—	Instandhaltungsdaten,

—	Umwelteigenschaften.

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:

—	der Schnittstelle zum Teilsystem Betrieb und Verkehrssteuerung des transeuropäischen konventionellen Eisenbahnsystems, auf das in Artikel 5 Absatz 3 der Richtlinie 2001/16/EG Bezug genommen wird;

—	der Anforderungen an den Inhalt der Schienennetz-Nutzungsbedingungen, die in Richtlinie 2001/14/EG, Artikel 3 und Anhang I genannt sind;

—	der zu einem Güterwagen verfügbaren Informationen und der Instandhaltungsanforderungen aus der TSI „Fahrzeuge“.

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:

—	Sicherheit,

—	Zuverlässigkeit und Betriebsbereitschaft,

—	Gesundheit,

—	Umweltschutz,

—	Technische Kompatibilität.

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:

—

Grundlegende Anforderung 1.1.1 laut Anhang III der Richtlinie 2001/16/EG: „Die Planung, der Bau oder die Herstellung, die Instandhaltung und die Überwachung der sicherheitsrelevanten Bauteile, insbesondere derjenigen, die am Zugverkehr beteiligt sind, müssen die Sicherheit auch unter bestimmten Grenzbedingungen auf dem für das Netz festgelegten Niveau halten.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.1.2 laut Anhang III der Richtlinie 2001/16/EG: „Die Kennwerte für das Rad-Schiene-System müssen die Kriterien der Laufstabilität erfüllen, damit bei der zulässigen Höchstgeschwindigkeit eine sichere Fahrt gewährleistet ist.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.1.3 laut Anhang III der Richtlinie 2001/16/EG: „Die verwendeten Bauteile müssen während ihrer gesamten Betriebsdauer den spezifizierten gewöhnlichen oder Grenzbeanspruchungen standhalten. Durch geeignete Mittel ist sicherzustellen, dass sich die Sicherheitsauswirkungen eines unvorhergesehenen Versagens in Grenzen halten.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.1.4 laut Anhang III der Richtlinie 2001/16/EG: „Die Auslegung der ortsfesten Anlagen und der Fahrzeuge und die Auswahl der Werkstoffe müssen das Entstehen, die Ausbreitung und die Auswirkungen von Feuer und Rauch im Fall eines Brandes in Grenzen halten.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.1.5 laut Anhang III der Richtlinie 2001/16/EG: „Die für die Betätigung durch die Fahrgäste vorgesehenen Einrichtungen müssen so konzipiert sein, dass das sichere Funktionieren der Einrichtungen oder die Gesundheit und Sicherheit der Benutzer nicht beeinträchtigt werden, wenn sie in einer voraussehbaren Weise betätigt werden, die den angebrachten Hinweisen nicht entspricht.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

3.3.2.   Zuverlässigkeit und Betriebsbereitschaft

Dieser grundlegenden Anforderung wird in den folgenden Kapiteln Rechnung getragen:

Kapitel 4.2.11: Die Hauptreferenzdaten,

Kapitel 4.2.12: Diverse Referenzdateien und Datenbanken,

Kapitel 4.2.14: Vernetzung und Kommunikation.

3.3.3.   Gesundheit

—

Grundlegende Anforderung 1.3.1 laut Anhang III der Richtlinie 2001/16/EG: „Werkstoffe, die aufgrund ihrer Verwendungsweise die Gesundheit von Personen, die Zugang zu ihnen haben, gefährden können, dürfen in Zügen und Infrastruktureinrichtungen nicht verwendet werden.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.3.2 laut Anhang III der Richtlinie 2001/16/EG: „Die Auswahl, die Verarbeitung und die Verwendung dieser Werkstoffe müssen eine gesundheitsschädliche oder -gefährdende Rauch- und Gasentwicklung insbesondere im Fall eines Brandes in Grenzen halten.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

3.3.4.   Umweltschutz

—

Grundlegende Anforderung 1.4.1 laut Anhang III der Richtlinie 2001/16/EG: „Die Umweltauswirkungen des Baus und Betriebs des konventionellen transeuropäischen Eisenbahnsystems sind bei der Planung dieses Systems entsprechend den geltenden Gemeinschaftsbestimmungen zu berücksichtigen.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.4.2 laut Anhang III der Richtlinie 2001/16/EG: „In Zügen und Infrastruktureinrichtungen verwendete Werkstoffe müssen eine umweltschädliche oder -gefährdende Rauch- und Gasentwicklung insbesondere im Fall eines Brandes verhindern.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.4.3 laut Anhang III der Richtlinie 2001/16/EG: „Fahrzeuge und Energieversorgungsanlagen sind so auszulegen und zu bauen, dass sie mit Anlagen, Einrichtungen und öffentlichen oder privaten Netzen, bei denen Interferenzen möglich sind, elektromagnetisch verträglich sind.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.4.4 laut Anhang III der Richtlinie 2001/16/EG: „Beim Betrieb des konventionellen transeuropäischen Eisenbahnsystems müssen die vorgeschriebenen Lärmgrenzen eingehalten werden.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.4.5 laut Anhang III der Richtlinie 2001/16/EG: „Der Betrieb des konventionellen transeuropäischen Eisenbahnsystems darf in normalem Instandhaltungszustand für die in der Nähe des Fahrwegs gelegenen Einrichtungen und Bereiche keine unzulässigen Bodenschwingungen verursachen.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

3.3.5.   Technische Kompatibilität

—

Grundlegende Anforderung 1.5 laut Anhang III der Richtlinie 2001/16/EG: „Die technischen Merkmale der Infrastrukturen und ortsfesten Anlagen müssen untereinander und mit denen der Züge, die im konventionellen transeuropäischen Eisenbahnsystem verkehren sollen, kompatibel sein. Erweist sich die Einhaltung dieser Merkmale auf bestimmten Teilen des Netzes als schwierig, so könnten Zwischenlösungen, die eine künftige Kompatibilität gewährleisten, eingeführt werden.“ Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

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

3.4.1.   Technische Kompatibilität

—

Grundlegende Anforderung 2.7.1 laut Anhang III der Richtlinie 2001/16/EG: „Die grundlegenden Anforderungen für den Bereich der Telematikanwendungen, die eine Mindestqualität der Dienstleistung für die Reisenden und die Güterverkehrskunden gewährleisten, betreffen insbesondere die technische Kompatibilität. Bei diesen Anwendungen ist sicherzustellen, — dass die Datenbanken, die Software und die Datenübertragungsprotokolle so erstellt werden, dass ein möglichst vielfältiger Datenaustausch zwischen verschiedenen Anwendungen und zwischen verschiedenen Betreibern gewährleistet ist, wobei vertrauliche Geschäftsdaten hiervon ausgeschlossen sind, — dass die Benutzer einen leichten Zugriff zu den Informationen haben.“ Dieser grundlegenden Anforderung wird in den folgenden Kapiteln Rechnung getragen: — Kapitel 4.2.11: Die Hauptreferenzdaten, — Kapitel 4.2.12: Diverse Referenzdateien und Datenbanken, — Kapitel 4.2.14: Vernetzung und Kommunikation.

3.4.2.   Zuverlässigkeit und Betriebsbereitschaft

—

Grundlegende Anforderung 2.7.2 laut Anhang III der Richtlinie 2001/16/EG: „Die Methoden der Nutzung, Verwaltung, Aktualisierung und Pflege dieser Datenbanken, Software und Datenübertragungsprotokolle müssen die Effizienz der Systeme und die Leistungsqualität gewährleisten.“ Dieser grundlegenden Anforderung wird in den folgenden Kapiteln Rechnung getragen: — Kapitel 4.2.11: Die Hauptreferenzdaten, — Kapitel 4.2.12: Diverse Referenzdateien und Datenbanken, — Kapitel 4.2.14: Vernetzung und Kommunikation. Diese grundlegende Anforderung, insbesondere die Methode der Nutzung, um die Wirksamkeit dieser Telematikanwendungen und die Qualität des Dienstes zu garantieren, ist das grundlegende Element, das sich über die gesamte TSI erstreckt und nicht nur auf die oben erwähnten Kapitel beschränkt ist.

3.4.3.   Gesundheit

—

Grundlegende Anforderung 2.7.3 laut Anhang III der Richtlinie 2001/16/EG: „Die Benutzerschnittstellen dieser Systeme müssen den Mindestregeln für Ergonomie und Gesundheitsschutz entsprechen.“ Diese TSI spezifiziert keinerlei zusätzliche Anforderungen zu nationalen und europäischen Regeln in Bezug auf Mindestregeln für Ergonomie und Gesundheitsschutz an der Schnittstelle zwischen dieser TSI und den Anwendern.

3.4.4.   Sicherheit

—

Grundlegende Anforderung 2.7.4 laut Anhang III der Richtlinie 2001/16/EG: „Im Hinblick auf die Speicherung oder Übertragung sicherheitsrelevanter Daten ist für angemessene Integrität und Zuverlässigkeit zu sorgen.“ Dieser grundlegenden Anforderung wird in den folgenden Kapiteln Rechnung getragen: — Kapitel 4.2.11: Die Hauptreferenzdateien, — Kapitel 4.2.12: Diverse Referenzdateien und Datenbanken, — Kapitel 4.2.14: Vernetzung und Kommunikation.

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:

—	Frachtbriefdaten,

—	Trassenantrag,

—	Zugvorbereitung,

—	Zugfahrtprognose,

—	Verkehrsunterbrechungsinformationen,

—	Zugstandort,

—	Wagen/Intermodaleinheit PÜZ/PAZ,

—	Wagenbewegung,

—	Wagenübergangsmeldungen,

—	Datenaustausch zur Qualitätsverbesserung,

—	Die Hauptreferenzdaten,

—	Diverse Referenzdateien und Datenbanken,

—	Elektronische Übertragung von Dokumenten,

—	Vernetzung und Kommunikation.

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:

—	Kontrolldaten: Erläuterung nachfolgend

—	Informationsdaten: die Nutzinformation

Die Kontrolldaten zeigen folgende Elemente auf:

—	Status: Der Status einer Meldung kann sein: — „Neue Meldung“, falls dies eine neue Meldung ist, — „Änderung“, falls dies die Modifizierung einer vorhergehenden Meldung ist, — „Löschung“, falls die früher gesendete Meldung gelöscht werden soll.

—	Meldungsreferenz mit: — Meldungstyp: z. B. „Trassenantrag“ oder „Abfrage zur Zugfahrt“, — Datum und Uhrzeit: Datum und Uhrzeit, zu der die Meldung gesendet wurde, — Meldungsnummer: Nummer, die vom Sender der Meldung generiert wird.

—

Bezugsreferenz, nur wenn die Meldung die Antwort auf eine früher erhaltene Meldung ist (identisch zur Meldungsreferenz der erhaltenen Meldung) mit: — Bezugstyp: Typ der erhaltenen Meldung, — Bezugsdatum und -uhrzeit: Datum und Uhrzeit der erhaltenen Meldung, — Bezugsnummer: Nummer der erhaltenen Meldung.

—	Sender der Meldung

—	Empfänger der Meldung

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).

—	Beförderungsauftrag für das Ursprungs-Eisenbahnverkehrsunternehmen (UEVU),

—	Beförderungsauftrag für das Transit-Eisenbahnverkehrsunternehmen (TEVU),

—	Beförderungsauftrag für das Auslieferungs-Eisenbahnverkehrsunternehmen (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:

—	Absender- und Empfängerangaben,

—	Streckenverlauf,

—	Ladungsidentifikation,

—	Wageninformation,

—	Orts- und Zeitangaben.

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:

—	Ladungsgewicht (Bruttogewicht der Ladung),

—	CN/HS-Nummer,

—	Gefahrgutangaben,

—	Transporteinheit.

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):

—

Kennzeichnung der Zugtrasse (Trassennummer). Eine Trasse kann entweder die geplante Kapazitätsnutzung auf einem Streckenabschnitt oder der aktuelle Lauf eines Zuges über einen spezifizierten Abschnitt innerhalb einer Strecke sein. Die genaue Art der vorstehenden Angabe richtet sich nach den beim IB üblichen Verfahren.

—	Startpunkt der Trasse. Dies bezeichnet den Ort, an dem die Trasse beginnt, mit Angabe von Datum und Uhrzeit, zu der der Zug dort abfahren soll.

—	Endpunkt der Trasse. Bezeichnet den Ort, an dem die Trasse endet, mit Angabe von Datum und Uhrzeit, zu der der Zug dort ankommen soll.

—

Beschreibung des Fahrtabschnitts. Sie definiert die Daten, die vom IB für jeden akzeptierten Fahrtabschnitt bereitzustellen sind — vom Start bis zum ersten Zwischenhalt, zwischen den Zwischenhalten und vom letzten Zwischenhalt bis zum Ende der akzeptierten Fahrt. Die Beschreibung kann umfassen: — Zwischenhalte oder andere ausgewiesene Punkte entlang der vorgeschlagenen Trasse mit Datum und Uhrzeit für Ankunft, Abfahrt oder Durchfahrt an diesen Zwischenpunkten sowie Angabe eines Aktionscodes, der definiert, welche Aktivität an diesem Zwischenhalt auf der Strecke stattfinden soll; — Angabe des IB, der auf dem aktuellen Fahrtabschnitt für die Verkehrsleitung zuständig ist, und des IB, der für die Verkehrsleitung auf dem nächsten Fahrtabschnitt verantwortlich ist; — Beschreibung der Zugausrüstung (Zugsteuerungs-/Zugsicherungssystem, Funksystem usw.); sie muss mit der Infrastruktur kompatibel sein, um Traktion, Steuerung und Kommunikation vom Zug zur Leitstelle des IB zu ermöglichen; — Zugspezifische Daten für den Fahrtabschnitt: Höchstgewicht, max. Länge, max. Geschwindigkeit, max. Achslast, min. Bremskraft, max. Metergewicht, Angaben über außergewöhnliches Lichtraumprofil, Kennzeichnungen unzulässiger Gefahrgüter; — Trassennummer; — Zuschlagzeiten auf dem Streckenabschnitt, um die Wiederherstellung nach Trassierungsproblemen usw. zu ermöglichen.

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):

—	Szenario A: Das EVU kontaktiert alle beteiligten IB direkt (Fall A) oder über den OSS (Fall B), um die Trassen für die gesamte Fahrt zu organisieren. In diesem Fall muss das EVU laut Artikel 13 der Richtlinie 2001/14/EG den Zug auch über die gesamte Strecke betreiben.

—	Szenario B: Jedes an der Transportfahrt beteiligte EVU kontaktiert die lokalen IB direkt oder über den OSS und beantragt eine Trasse für den Fahrtabschnitt, auf dem es den Zug betreiben will.

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

Meldung	Erläuterung
Meldungen, die im Dialog für den Trassenantrag zu verwenden sind
Beantragung einer Trasse	EVU an den/die beteiligten IB, diese Meldung muss für einen kurzfristigen Trassenantrag gesendet werden.
Trassendetails	Diese Meldung muss vom IB(s) an das EVU geschickt werden, um die Details der Trasse als Antwort auf den „Trassenantrag“ des EVU, eventuell mit geänderten Werten zu bestätigen. Wenn der IB den Trassenantrag nicht weiter befriedigen kann, muss der IB diese Meldung mit der Kennung „Keine Alternativen verfügbar“ schicken.
Trasse bestätigt	Diese Meldung muss vom EVU an den IB geschickt werden, um die „Trassendetails“ zu bestätigen, die das EVU als Antwort auf seinen ursprünglichen Trassenantrag vom IB erhalten hat.
Trassendetails abgelehnt	Diese Meldung muss vom EVU an den IB geschickt, wenn es die „Trassendetails“, die das EVU als Antwort auf seinen ursprünglichen Trassenantrag vom IB erhalten hat, zum Beispiel wegen geänderter Werte, nicht akzeptieren kann.

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

Meldung	Erläuterung
Meldung zum Stornieren einer gebuchten Trasse durch das EVU
Trasse storniert	Meldung vom EVU an den IB zur Stornierung einer zuvor gebuchten Trasse oder eines Teils dieser Trasse.

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

Meldung	Erläuterung
Meldungen zum Stornieren einer gebuchten Trasse durch den IB
Trasse nicht verfügbar	Meldung vom IB an das EVU, dass eine gebuchte Trasse nicht mehr verfügbar ist.
Trassendetails	Diese Meldung muss vom (von den) IB an das EVU geschickt werden und enthält einen Vorschlag für eine Alternativtrasse, nachdem der IB dem EVU mitgeteilt hat, dass eine gebuchte Trasse nicht mehr verfügbar ist.
Trasse bestätigt	Diese Meldung muss vom EVU an den IB geschickt werden; sie bestätigt die Annahme des Alternativvorschlags, der mit der Meldung „Trasse bestätigt“ geschickt wurde.
Trassendetails abgelehnt	Diese Meldung muss vom EVU an den IB geschickt werden, wenn es den Alternativvorschlag, der mit der Meldung „Trasse nicht verfügbar“ geschickt wurde, ablehnt. In diesem Fall muss der IB einen neuen Vorschlag schicken. Dieser Dialog endet durch das EVU mit der Meldung „Trasse storniert“ mit Bezug auf die Meldung „Trasse nicht verfügbar“ vom 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

Meldung	Erläuterung
Diese Meldung gilt generell
Empfangsbestätigung	Diese Meldung muss vom Empfänger einer Meldung an den Absender geschickt werden, wenn die erforderliche Antwort nicht innerhalb des Zeitfensters, wie in Kapitel 4.4 (Betriebsvorschriften) Abschnitt „Rechtzeitigkeit“ definiert, erfolgen kann.

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:

—	Trassenausgangspunkt: Startpunkt der Trasse,

—	Abfahrtsdatum/-zeit am Startpunkt der Trasse: Datum und Uhrzeit, für die die Trasse beantragt wird,

—	Endpunkt der Trasse: Zielort des Zuges auf der beantragten Trasse,

—	Ankunftsdatum/-zeit am Endpunkt der Trasse: Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,

—

Beantragter Fahrtabschnitt: — Zwischenhalte oder andere ausgewiesene Punkte entlang der vorgeschlagenen Trasse mit Datum und Uhrzeit für Ankunft sowie Datum und Uhrzeit für Abfahrt an einem Zwischenpunkt. Falls dieses Feld nicht ausgefüllt wird, bedeutet dies, dass der Zug an diesem Punkt nicht hält, — Verfügbare Zugausrüstung: Traktionsart, Zugsteuerungs-/Zugsicherungssystem (einschließlich der fahrzeugseitigen Funkausrüstung), — Zuggewicht, — Zuglänge, — Zu verwendende Bremsart und Bremsleistung, — Maximale Zuggeschwindigkeit, — Maximale Achslast des Zuges, — Maximale Last pro Meter, — Informationen über außergewöhnliches Lichtraumprofil, — UN-/RID-Nummern von Gefahrgütern, — Definitionen, welche Aktivitäten am Zwischenpunkt auf der Strecke erfolgen sollen, — Verantwortliches EVU: Angabe des EVU, das auf dem aktuellen Fahrtabschnitt für den Zug verantwortlich ist, — Verantwortlicher IB: Angabe des IB, der auf dem aktuellen Fahrtabschnitt für den Zug verantwortlich ist, — Nächster verantwortlicher IB: Angabe des IB, der auf dem nächsten Fahrtabschnitt für den Zug verantwortlich ist (sofern zutreffend).

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:

—	Neue Trassennummer,

—	Trassenausgangspunkt: Startpunkt der Trasse,

—	Abfahrtsdatum/-zeit am Startpunkt der Trasse: Datum und Uhrzeit, für die die Trasse beantragt wird,

—	Endpunkt der Trasse: Zielort des Zuges auf der beantragten Trasse,

—	Ankunftsdatum/-zeit am Endpunkt der Trasse: Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,

—

Geänderter Fahrtabschnitt: — Zwischenhalte oder andere ausgewiesene Punkte entlang der vorgeschlagenen Trasse mit Datum und Uhrzeit für Ankunft sowie Datum und Uhrzeit für Abfahrt an einem Zwischenpunkt. Falls dieses Feld nicht ausgefüllt wird, bedeutet dies, dass der Zug an diesem Punkt nicht hält, — Erforderliche Zugausrüstung: Traktionsart, Zugsteuerungs-/Zugsicherungssystem (einschließlich der fahrzeugseitigen Funkausrüstung), — Zuggewicht, — Zuglänge, — Zu verwendende Bremsart und Bremsleistung, — Maximale Zuggeschwindigkeit, — Maximale Achslast des Zuges, — Maximale Last pro Meter, — Informationen über außergewöhnliches Lichtraumprofil, — UN-/RID-Nummern von Gefahrgütern, — Definitionen, welche Aktivitäten am Zwischenpunkt auf der Strecke erfolgen sollen, — Verantwortliches EVU: Angabe des EVU, das auf dem aktuellen Fahrtabschnitt für den Zug verantwortlich ist, — Verantwortlicher IB: Angabe des IB, der auf dem aktuellen Fahrtabschnitt für den Zug verantwortlich ist, — Nächster verantwortlicher IB: Angabe des IB, der auf dem nächsten Fahrtabschnitt für den Zug verantwortlich ist (sofern zutreffend).

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:

—	Trassennummer zur Identifizierung der Trasse,

—	Trassenausgangspunkt: Abfahrtsort des Zuges auf der Trasse,

—	Abfahrtsdatum/-zeit am Startpunkt der Trasse: Datum und Uhrzeit, für die die Trasse beantragt wird,

—	Endpunkt der Trasse: Zielort des Zuges auf der beantragten Trasse,

—	Ankunftsdatum/-zeit am Endpunkt der Trasse: Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,

—	Angabe, dass das EVU die vorgeschlagene Trasse akzeptiert.

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:

—	Trassennummer zur Identifizierung der Trasse,

—	Angabe, dass die Trassendetails abgelehnt werden,

Als Zusatzinformationen können folgende Daten gesendet werden:

—	Trassenausgangspunkt: Abfahrtsort des Zuges auf der Trasse,

—	Abfahrtsdatum/-zeit am Startpunkt der Trasse: Datum und Uhrzeit, für die die Trasse beantragt wird,

—	Endpunkt der Trasse: Zielort des Zuges auf der beantragten Trasse,

—	Ankunftsdatum/-zeit am Endpunkt der Trasse: Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll.

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:

—	Trassennummer zur Identifizierung der Trasse,

—	Zugnummer (wenn sie dem IB bereits bekannt ist),

—	Angabe, dass die gebuchte Trasse storniert werden soll.

Als Zusatzinformationen können folgende Daten gesendet werden:

—	Trassenausgangspunkt: Abfahrtsort des Zuges auf der Trasse,

—	Abfahrtsdatum/-zeit am Startpunkt der Trasse: Datum und Uhrzeit, für die die Trasse beantragt wird,

—	Endpunkt der Trasse: Zielort des Zuges auf der beantragten Trasse,

—	Ankunftsdatum/-zeit am Endpunkt der Trasse: Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll.

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:

—	Trassennummer der nicht verfügbaren Trasse,

—	Zugnummer des für die stornierte Trasse vorgesehenen Zuges (falls sie dem IB bereits bekannt ist),

—	Startpunkt sowie Datum und Uhrzeit, für die die Trasse gebucht war,

—	Endpunkt sowie Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen sollte,

—	Angabe, dass die Trasse nicht verfügbar ist,

—	Angabe des Grundes.

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)

—	Meldung Empfangsbestätigung: Zeigt an, dass der Empfänger die Meldung erhalten hat und entsprechend reagieren wird.

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

Meldung		Erläuterung
Zugbildung		EVU an IB, diese Meldung muss entsprechend obiger Beschreibung gesendet werden.
	Für den Fall, dass der IB eine vom EVU obligatorisch gesendete Zugbildungsmeldung erhalten hat, kann der IB folgende Meldungen senden:
	Zug akzeptiert	IB an das EVU: Diese Meldung ist optional, wenn zwischen IB und EVU nichts anderes vereinbart ist.	Zugvorbereitung kann abgeschlossen werden.
	Zug ungeeignet	IB an das EVU: Diese Meldung kann vom IB gesendet werden, wenn er diesen Sachverhalt feststellt.	EVU-Möglichkeiten:   Änderung der Zugbildung oder   Stornierung der Trasse und Antrag auf neue Trasse.
Zug fertig		EVU an IB, diese Meldung muss versandt werden.
Zugposition		IB an EVU, legt genau fest, wann und wo der Zug in das Netz einfahren soll. Diese Meldung kann in Abhängigkeit von der nationalen Regelung gesendet werden.
Zug am Start		EVU an IB. Diese Nachricht kann gesendet werden, um zu melden, dass der Zug die Fahrt angetreten hat, und zwar als Antwort auf die Nachricht: Zugposition. Diese Meldung kann in Abhängigkeit von der nationalen Regelung gesendet werden.
Zugfahrtmeldung		IB an EVU, diese Meldung muss geschickt werden, um anzuzeigen, dass der Zug auf der Infrastruktur angekommen ist.

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:

—	Zugnummer und Trassennummer zur Identifizierung der Trasse,

—	Startpunkt auf der Trasse sowie Datum und Uhrzeit, für die die Trasse gebucht wurde,

—	Zielpunkt auf der Trasse sowie Datum und Uhrzeit, zu der der Zug an seinem Ziel ankommen soll,

—	Kennung der Lokomotive(n) und Position der Lokomotive(n) im Zug,

—	Zuglänge, Zuggewicht, max. Zuggeschwindigkeit,

—	Zugbildung mit Reihenfolge der Fahrzeugkennungen,

—	Zugsteuerungs-/Zugsicherungssystem einschließlich Art der Funkausrüstung,

—	Informationen über außergewöhnliches Lichtraumprofil,

—	UN-/RID-Nummern von Gefahrgütern,

—	Angabe, ob der Zug Vieh oder Menschen (außer Zugbegleitpersonal) befördert,

—	Zu verwendende Bremsart,

—	Wagendaten.

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:

—	Trassennummer und Zugnummer,

—	Startpunkt sowie Datum und Uhrzeit, für die die Trasse beantragt wurde,

—	Zielpunkt sowie Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,

—	Angabe, dass der IB die Zugbildung für die vereinbarte Trasse als geeignet akzeptiert hat.

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:

—	Trassennummer und Zugnummer,

—	Startpunkt sowie Datum und Uhrzeit, für die die Trasse beantragt wurde,

—	Zielpunkt sowie Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,

—	Angabe, dass der Zug für die zugeteilte Trasse nicht geeignet ist und daher nicht fahren darf,

—	Angabe des Grundes.

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:

—	Trassennummer und Zugnummer,

—	Startpunkt sowie Datum und Uhrzeit, für die die Trasse beantragt wurde,

—	Zielpunkt sowie Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,

—	Angabe, dass der Zug fertig ist. Sie gibt an, dass der Zug vorbereitet wurde und betriebsbereit ist,

—	Kennung der Kontaktperson in der Leitstelle für die gesamte Mobil-Stationär-Kommunikation,

—

Wenn der Vertrag zwischen EVU und IB festlegt, dass der Meldungsaustausch „Zugposition/Zug am Start“ verzichtbar ist, müssen Anfangsdatum und -uhrzeit der Zugfahrt in dieser Meldung definiert sein. Sie informieren den IB darüber, wann und wo der Zug voraussichtlich in das Netz einfahren wird. Falls hingegen der Meldungsaustausch „Zugposition/Zug am Start“ vorgeschrieben ist, darf diese Information nicht übertragen werden.

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:

—	Trassennummer und Zugnummer,

—	Abfahrtspunkt auf der Trasse sowie Datum und Uhrzeit, für die die Trasse beantragt wurde,

—	Zielpunkt sowie Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,

—	Gleiskennung; sie unterrichtet das EVU, auf welchem Gleis der Zug in das Netz des IB einfahren soll,

—	Anfangsdatum/-uhrzeit der Zugfahrt; sie teilt dem EVU genau mit, wann der Zug in das Netz des IB einfahren soll,

—	Kennung der Kontaktperson in der Leitstelle.

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:

—	Zug am Start: Datum/Uhrzeit, zu der der Zug seine Fahrt tatsächlich begonnen hat.

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:

Zugfahrtprognose,

Zugfahrtmeldung.

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):

—	Zug nähert sich einem Übergabepunkt zwischen IB n1 und seinem Nachbarn IB n2

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.

—	Zug nähert sich einem Wagenübergangspunkt zwischen EVU 1 und dem nächsten EVU 2 (nur Szenario B)

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.

—	Zug nähert sich einer Anschlussstelle eines EVU (Szenario A)

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.

—	Ankunft des Zugs am Ziel

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:

—	Trassennummer und Zugnummer,

—	Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am Standort des IB (oder planmäßige Übergabezeit an den nächsten IB),

—	Kennung des Meldepunkts,

—	Prognostizierte(s) Datum/Zeit am Meldepunkt.

4.2.4.3.   Zugfahrtmeldung

Diese Meldung muss erfolgen bei:

—	Abfahrt vom Startpunkt, Ankunft am Zielpunkt,

—

Ankunft und Abfahrt an Übergabe-, Wagenübergangs- und an vertraglich vereinbarten Meldepunkten (zum Beispiel an Anschlussstellen). Die wichtigsten Datenelemente sind: — Trassennummer und Zugnummer, — Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort, — Identifizierung des zuletzt passierten Meldepunkts, — Istzeit am Meldepunkt, — Status des Zuges am Meldepunkt (Ankunft, Abfahrt, Durchfahrt, Nicht angegeben, Abfahrt ab Ausgangsbahnhof, Ankunft am Ziel), — Ankunftsgleis am Meldepunkt, — Abfahrtsgleis vom Meldepunkt, — Abweichung von der gebuchten fahrplanmäßigen Zeit in Minuten, — aktueller Fahrplan (bei mehrfacher Neuplanung), — Für jede Abweichung von der gebuchten fahrplanmäßigen Zeit an diesem Meldepunkt: — Ursachencode (eventuell mehrere), — Abweichungszeit für diesen Ursachencode (pro Meldepunkt können mehrere Ursachen angegeben werden), — Eventuell freier Text über die Abweichung.

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:

—	Trassennummer und Zugnummer,

—	Ortsangabe,

—	Planmäßige(s) Abfahrtsdatum und Abfahrtszeit an diesem Ort,

—	Unterbrechungsgrund,

—	Beschreibung der Unterbrechung.

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:

—	die Zugfahrt (letzter gemeldeter Standort, Verspätungen, Verspätungsgründe),

—	die Fahrleistung eines Zuges (Verspätungen, Verspätungsgründe, Verspätungsorte),

—	alle Kennungen eines bestimmten Zuges,

—	die Zugfahrtprognose eines Zuges für einen bestimmten Ort,

—	alle Zugfahrtprognosen für einen bestimmten Ort.

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

Zweck	:	EVU erfragt den letzten gemeldeten Status (Standort, Verspätungen und Verspätungsgründe) eines bestimmten Zuges auf der Infrastruktur eines bestimmten IB.
Abfrage	:	Wichtigste Datenelemente: — Zugnummer, — IB-Kennung, — Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort.
Antwort	:	Informationsdaten: — Zuletzt gemeldeter Meldepunkt, — Istzeit am Meldepunkt, — Status am Meldepunkt (Ankunft, Abfahrt, Durchfahrt, Nicht angegeben, Abfahrt ab Ausgangsbahnhof, Ankunft am Ziel), — Ankunftsgleis am Meldepunkt, — Abfahrtsgleis vom Meldepunkt, — Gebuchte fahrplanmäßige Zeit, — Verspätung gegenüber der gebuchten fahrplanmäßigen Zeit, — Neu geplante Zeit (im Vergleich zum aktuellen Fahrplan, falls mehrfach umgeplant), — Für jede Verspätung am betreffenden Meldepunkt: — Code für die Ursache und Verspätungszeit aufgrund dieser Ursache.

4.2.6.3.   Abfrage zur Zugverspätung/Fahrleistung

Zweck	:	EVU erfragt alle Verspätungen bei einem bestimmten IB.
Abfrage	:	Wichtigste Datenelemente — Zugnummer, — IB-Kennung, — Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort.
Antwort	:	Informationsdaten (dieselben Informationen wie bei der „Abfrage zur Zugfahrt“, jedoch nicht nur für den zuletzt gemeldeten Meldepunkt, sondern für alle Meldepunkte des Zuges auf der Infrastruktur des spezifizierten IB): — Für jeden Meldepunkt: — Zuletzt gemeldeter Meldepunkt, — Istzeit am Meldepunkt, — Status des Zuges am Meldepunkt (Ankunft, Abfahrt, Durchfahrt, Nicht angegeben, Abfahrt ab Ausgangsbahnhof, Ankunft am Ziel), — Ankunftsgleis am Meldepunkt, — Abfahrtsgleis vom Meldepunkt, — Gebuchte fahrplanmäßige Zeit, — Verspätung gegenüber der gebuchten fahrplanmäßigen Zeit, — Neu geplante Zeit (im Vergleich zum aktuellen Fahrplan, falls mehrfach umgeplant), — Für jede Verspätung am betreffenden Meldepunkt: — Code für die Ursache und Verspätungszeit aufgrund dieser Ursache.

4.2.6.4.   Abfrage der Zugkennung

Zweck	:	EVU erfragt die aktuelle Zugkennung und die vorigen Zugkennungen. Für einen spezifischen Zug kann jede der Zugkennungen für die Abfrage verwendet werden.
Abfrage	:	Wichtigste Datenelemente: — Bekannte Zugnummer, — IB-Kennung, — Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort.
Antwort	:	Informationsdaten: — Aktuelle Zugkennung: — Zugnummer, — Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort. — Für alle anderen Zugkennungen: — Zugnummer, — Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort.

4.2.6.5.   Abfrage der Zugfahrtprognose beim IB

Zweck	:	EVU fragt nach der prognostizierten Zeit eines bestimmten Zuges an einem bestimmten Meldepunkt, oder bei Auslassen des Meldepunkts erfolgt die Frage nach der prognostizierten Zeit am Übergabepunkt vom IB.
Abfrage	:	Wichtigste Datenelemente: — Zugnummer, — Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort, — Meldepunktkennung (Der Meldepunkt, für den die Prognose gewünscht wird. Die Angabe ist optional. Wird keine Kennung angegeben, bezieht sich die Antwort auf den letzten Meldepunkt für diesen IB für diesen Zug.)
Antwort	:	Informationsdaten: — IB-Kennung, — Meldepunktkennung, — Prognostizierte(s) Datum/Zeit am Meldepunkt.

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

Zweck	:	EVU fragt nach allen seinen Zügen an einem bestimmten Meldepunkt auf der Infrastruktur eines speziellen IB.
Abfrage	:	Wichtigste Datenelemente: — IB-Kennung, — Meldepunktkennung (Der Meldepunkt, für den die Prognose gewünscht wird. Die Angabe ist optional. Wird keine Kennung angegeben, bezieht sich die Antwort auf den letzten Meldepunkt für diesen IB für diesen Zug.).
Antwort	:	Informationsdaten: — Für jeden Zug des anfragenden EVU: — Zugnummer, — Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort oder planmäßige Übergabezeit, — IB-Kennung, — Meldepunktkennung, — Prognostizierte(s) Datum/Zeit 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).

Beispiel 1	:	EVU1 hat innerhalb ein und desselben Zuges die Wagen Nummer 1 und 2 vom FEVU1 und die Wagen mit den Nummern 3 bis 5 vom FEVU2. Am Wagenübergangspunkt C erfolgt der weitere Transport vom Wagen 1 und 2 durch EVU2 und für die Wagen 3 bis 5 durch EVU3. In diesem Fall muss EVU1 bezogen auf den Wagenübergangspunkt C die PÜZ für den Wagen 1 und 2 berechnen und diese Werte an das FEVU1 schicken. EVU1 muss auch, bezogen auf den gleichen Wagenübergangspunkt C, die PÜZ für die Wagen 3 bis 5 berechnen und diese Werte dem FEVU2 schicken.
Beispiel 2	:	EVU1 hat innerhalb ein und desselben Zuges die Wagen Nummer 1 und 2 vom FEVU1 und die Wagen mit den Nummern 3 bis 5 vom FEVU2. Am Wagenübergangspunkt C erfolgt der weitere Transport von Wagen 3 bis 5 durch EVU3, während die Wagen 1 und 2 im Zug des EVU1 bis zum Wagenübergangspunkt E verbleiben, wo die Verantwortung für diese Wagen an EVU2 übergeht. In diesem Fall muss EVU1 bezogen auf den Wagenübergangspunkt C nur die PÜZ für die Wagen 3 bis 5 berechnen und diese Werte dem EVU2 schicken. Für die Wagen 1 und 2 ist der Wagenübergangspunkt C nicht relevant. Der nächste relevante Wagenübergangspunkt für diese Wagen ist E, und EVU1 muss bezogen auf diesen Punkt die PÜZ berechnen und diese Werte an FEVU1 schicken.

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

Zweck	:	Übermittlung der PÜZ oder einer aktualisierten PÜZ von einem EVU zum nächsten EVU in der Transportkette. Das letzte EVU in der Transportkette der Wagen übermittelt die PAZ oder eine aktualisierte PAZ an das FEVU.
Wichtigste Datenelemente	:	— Kennung des EVU, das die PÜZ oder PAZ errechnet hat, — Abfahrt- oder vorheriger Wagenübergangspunkt (PÜZ oder Abfahrtszeit am Ursprungsbahnhof), — Zugnummer bei Abfahrt vom Abfahrts- oder vorigen Wagenübergangspunkt (PÜZ oder Abfahrtszeit vom Ursprungsbahnhof), — Tatsächliche(s) Abfahrtsdatum und -uhrzeit des Zuges, — Ankunfts- oder nächster Wagenübergangspunkt (PÜZ/PAZ-Endbahnhof), — Zugnummer bei Ankunft am PÜZ/PAZ-Endbahnhof (Ankunfts- oder nächster Wagenübergangspunkt), — Ankunftsdatum und -uhrzeit des Wagens (PÜZ oder PAZ).

4.2.7.4.   Alarmmeldung

Zweck	:	Als Folge des Abgleichs zwischen PAZ und der Verpflichtung gegenüber dem Kunden kann das FEVU eine Alarmmeldung an die beteiligten EVU schicken.
Wichtigste Datenelemente	:	— Wagennummer, — Verpflichtung gegenüber dem Kunden: Ankunftsdatum und -uhrzeit, — Derzeitige PAZ: Datum und Uhrzeit.

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

Zweck	:	FEVU erfragt die Abweichungen bezogen auf einen bestimmten Wagen.
Abfrage	:	Wichtigste Datenelemente — Wagennummer, — FEVU-Kennung.
Antwort	:	Informationsdaten: — Für jeden Meldepunkt — Kennung des Meldepunkts, — Wagenstatus am Meldepunkt (Abfahrt, Ankunft am Rangierbahnhof, Abfahrt ab Rangierbahnhof, Ankunft am Wagenübergangspunkt, Ankunft am Ziel), — Zuständiges EVU am Meldepunkt und gemäß Wagenstatus am Meldepunkt, — Neu geplante Zeit (Vergleich zum aktuellen Fahrplan bei mehrfachen Umplanungen), — PÜZ, falls Meldepunkt ein Wagenübergangspunkt ist, — Istzeit am Meldepunkt, — Für jede Abweichung am betreffenden Meldepunkt — Code für die Ursache und Verspätungszeit aufgrund dieser Ursache.

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.

—	Wagenfreigabe

—	Wagenabfahrt

—	Wagenankunft Rangierbahnhof

—	Wagenabfahrt Rangierbahnhof

—	Wagenausnahme

—	Wagenankunft

—	Wagenablieferung

—	Wagenablieferbestätigung

—	Wagenübergangsmeldungen werden separat in Kapitel 4.2.9 (Berichtswesen Wagenübergang) beschrieben.

4.2.8.2.   Wagenfreigabe

Zweck	:	FEVU an EVU: Das federführende EVU ist nicht unbedingt das erste EVU in der Transportkette. In diesem Fall muss das FEVU dem zuständigen EVU mitteilen, dass der Wagen auf dem Abstellgleis des Kunden (Abfahrtsort gemäß Vertrag zwischen FEVU und Kunde) zum gegebenen Freigabezeitpunkt (Datum und Uhrzeit der Abfahrt) zur Abholung bereit steht. Der Vorgang muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden.
Wichtigste Datenelemente	:	— Wagennummer, — Ort, Datum und Uhrzeit der Abfahrt (der Ort, von dem der Transport abgehen soll). Die folgenden Daten müssen für EVU und FEVU leicht aus den Datenbanken abrufbar sein: — Transporteinheit, Kennung, Größe und Art, — Auslastung der Transporteinheit, — Gesamtgewicht (Gebuchtes/tatsächliches Gesamtgewicht (Masse) der Güter, einschließlich Verpackung und Transportvorrichtungen), — Angabe von Gefahrgütern.

4.2.8.3.   Wagenabfahrt

Zweck	:	EVU an FEVU: Das EVU muss dem FEVU das tatsächliche Datum und die tatsächliche Uhrzeit mitteilen, zu der der Wagen vom Abfahrtsort gezogen wurde. Der Vorgang muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden. Mit diesem Meldungsaustausch geht die Verantwortung für den Wagen vom Kunden auf das EVU über.
Wichtigste Datenelemente	:	— Wagennummer, — Ort, Datum und Uhrzeit der Abfahrt (der Ort, von dem der Transport abgehen soll). Die folgenden Daten müssen für EVU und FEVU leicht aus den Datenbanken abrufbar sein: — Transporteinheit, Kennung, Größe und Art, — Auslastung der Transporteinheit, — Gesamtgewicht (Gebuchtes/tatsächliches Gesamtgewicht (Masse) der Güter, einschließlich Verpackung und Transportvorrichtungen), — Angabe von Gefahrgütern.

4.2.8.4.   Wagenankunft Rangierbahnhof

Zweck	:	Das EVU muss das FEVU informieren, dass der Wagen am Rangierbahnhof angekommen ist. Diese Meldung kann aufgrund einer „Zugfahrtmeldung“ aus Kapitel 4.2.4 (Prognose zur Zugfahrt) erfolgen. Der Vorgang muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden.
Wichtigste Datenelemente	:	— Wagennummer, — Kennung des Rangierbahnhofs, — Datum und Uhrzeit der Ankunft am Rangierbahnhof.

4.2.8.5.   Wagenabfahrt Rangierbahnhof

Zweck	:	Das EVU muss das FEVU informieren, dass der Wagen den Rangierbahnhof verlassen hat. Diese Meldung kann aufgrund einer „Zugfahrtmeldung“ aus Kapitel 4.2.4 (Prognose zur Zugfahrt) erfolgen. Der Vorgang muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden.
Wichtigste Datenelemente	:	— Wagennummer, — Kennung des Rangierbahnhofs, — Datum und Uhrzeit der Abfahrt vom Rangierbahnhof.

4.2.8.6.   Wagenausnahme

Zweck	:	Das EVU muss das FEVU informieren, sobald etwas Unerwartetes mit dem Wagen auftritt, das möglicherweise eine Auswirkung auf PÜZ/PAZ haben kann oder das zusätzliche Aktivitäten erforderlich macht. Diese Meldung bedingt in den meisten Fällen auch die Berechnung einer neuen PÜZ/PAZ. Wenn das FEVU beschließt, eine neue PÜZ/PAZ zu benötigen, sendet es eine Meldung zusammen mit der Angabe „Neue PÜZ/PAZ erforderlich“ zurück an das EVU, das die Meldung geschickt hat. (Meldung: Wagenausnahme neue PÜZ/PAZ erforderlich). Die Berechnung der neuen PÜZ/PAZ muss nach dem Verfahren in Kapitel 4.2.7 (Ladung PÜZ/PAZ) erfolgen. Diese Information muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden.
Wichtigste Datenelemente	:	— Wagennummer, — Ort, Datum und Uhrzeit der Störung (der Ort, an dem während des Transports etwas Unvorhergesehenes geschieht), — Ursachen-/Störungscode. Zusätzlich müssen folgende Daten leicht aus den Datenbanken abrufbar sein: — Kennung der Transporteinheit, — Angabe von Gefahrgütern.

4.2.8.7.   Wagenausnahme neue PÜZ/PAZ erforderlich

Zweck	:	Das FEVU kann diese Meldung an das aktuelle EVU senden, das die „Ausnahmemeldung“ geschickt hat, um eine Neuberechnung der PÜZ/PAZ anzufordern. Das FEVU sendet diese Meldung an alle folgenden EVU, um sie über die Abweichung zu informieren. Ob eine Neuberechnung der PÜZ/PAZ erforderlich ist, entscheidet das FEVU; sie ist nicht in allen Fällen erforderlich.
Wichtigste Datenelemente	:	— Wagennummer, — Ort, Datum und Uhrzeit der Störung (der Ort, an dem während des Transports etwas Unvorhergesehenes geschieht), — Ursachen-/Störungscode, — Neue PÜZ/PAZ erforderlich. Zusätzlich müssen folgende Daten leicht aus den Datenbanken abrufbar sein: — Kennung der Transporteinheit, — Angabe von Gefahrgütern.

4.2.8.8.   Wagenankunft

Zweck	:	Das letzte EVU in der Transportkette eines Wagens oder einer Intermodaleinheit muss das FEVU informieren, dass der Wagen auf seinem Rangierbahnhof angekommen ist (EVU-Standort).
Wichtigste Datenelemente	:	— Wagennummer, — Kennung des Rangierbahnhofs des EVU, — Datum und Uhrzeit der Ankunft.

4.2.8.9.   Wagenablieferung

Zweck	:	Das letzte EVU in der Transportkette eines Wagens muss das FEVU informieren, dass der Wagen auf das Abstellgleis des Empfängers gestellt wurde.
Wichtigste Datenelemente	:	— Wagennummer, — Genaue Ortsangabe auf Empfängergleis (Standort, Bereich, Gleis, Stelle), — Datum und Uhrzeit des Abstellens.

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

—	Kundenkennung.

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:

—	Wagenübergang,

—	Wagenübergang/Sub,

—	Wagen am Übergangspunkt erhalten,

—	Wagen am Übergangspunkt abgelehnt.

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

Zweck	:	Mit der Meldung „Wagenübergang“ fragt ein EVU (EVU 1) beim nächsten EVU (EVU 2) in der Transportkette an, ob es bereit ist, die Verantwortung für einen Wagen zu übernehmen. Mit der Meldung „Wagenübergang/Sub“ informiert EVU 2 seinen IB, dass es die Verantwortung für den Wagen übernommen hat.
Wichtigste Datenelemente	:	— Wagennummer, — Zugnummer (nur wenn der Wagen Teil eines Zuges ist), — Ort, Datum und Uhrzeit des Wagenübergangs. Zusätzlich müssen folgende Daten leicht aus den Datenbanken abrufbar sein. — Kennung der Transporteinheit (Anzahl, Größe und Art), — Gesamtgewicht (Gebuchtes/tatsächliches Gesamtgewicht (Masse) der Güter, einschließlich Verpackung und Transportvorrichtungen), — Auslastung der Transporteinheit, — Details zu Gefahrgütern, Kennung.

4.2.9.3.   Wagenübergang/Sub

Zweck	:	Mit der Meldung „Wagenübergang/Sub“ informiert das EVU 2 seinen IB, dass es die Verantwortung für den Wagen übernommen hat.
Wichtigste Datenelemente	:	— Wagennummer, — Zugnummer (nur wenn der Wagen Teil eines Zuges ist), — Ort, Datum und Uhrzeit des Wagenübergangs. Zusätzlich müssen folgende Daten leicht aus den Datenbanken abrufbar sein: — Einzelheiten zu Gefahrgütern, Kennung.

4.2.9.4.   Wagen am Übergangspunkt erhalten

Zweck	:	Mit der Meldung „Wagen am Übergangspunkt erhalten“ informiert EVU 2 das EVU 1, dass es die Verantwortung für den Wagen übernimmt.
Wichtigste Datenelemente	:	— Wagennummer, — Ort, Datum und Uhrzeit des Wagenübergangs.

4.2.9.5.   Wagen am Übergangspunkt abgelehnt

Zweck	:	Mit der Meldung „Wagen am Übergangspunkt abgelehnt“ informiert EVU 2 das EVU 1, dass es nicht bereit ist, die Verantwortung für den Wagen zu übernehmen.
Wichtigste Datenelemente	:	— Wagennummer, — Ort, Datum und Uhrzeit des Wagenübergangs, — Ursachencode für die Ablehnung, — Weitere Beschreibung (optional).

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:

—	Identifizierung des Fahrzeugs,

—	Bewertung der Kompatibilität mit der Infrastruktur,

—	Bewertung der relevanten Beladungsmerkmale,

—	Bremsrelevante Merkmale,

—	Instandhaltungsdaten,

—	Umwelteigenschaften.

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:

—

Administrative Daten, beziehen sich auf Zertifizierungs- und Zulassungsaspekte, z. B. Verweis auf die EG-Zulassungsdatei, Kennung der benannten Stelle usw.; sie können historische Daten über Besitz- und Mietverhältnisse usw. enthalten. Folgende Schritte sind zu berücksichtigen: — EG-Konformitätsbescheinigung, — Zulassung im Heimatland, — Datum der Indienststellung im Zulassungsland, — Zulassung in anderen Ländern für den Einsatz auf deren nationalem Streckennetz, — Sicherheitsbescheinigung für alle Fahrzeuge, die nicht der TSI Fahrzeuge entsprechen. Der Fahrzeughalter muss dafür sorgen, dass diese Daten verfügbar sind und die zugrunde liegenden Prozesse durchgeführt wurden.

—

Konstruktionsdaten, sie müssen alle konstruktiven (physischen) Elemente der Fahrzeuge enthalten, darunter auch die Umwelteigenschaften, und alle Informationen, die voraussichtlich während der gesamten Lebensdauer des Fahrzeugs gültig bleiben — dieser Teil kann eine Historie der größeren Umbauten, größeren Instandhaltungsarbeiten, Überholungen etc. enthalten.

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:

—	Eisenbahnverkehrsunternehmen als Gefahrenhalter während der Transportsteuerung,

—	Fahrzeughalter und

—	Nutzer (Mieter) eines Fahrzeugs.

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:

—	Referenzdatei der Notrufzentralen für die verschiedenen Gefahrgüter.

Zentral gespeichert und verwaltet:

—	Referenzdatei mit Codierung für alle IB, EVU und Dienstleistungsunternehmen,

—	Referenzdatei mit Codierung für Transportkunden,

—	Referenzdatei mit Codierungen aller Standorte (primäre, alternative und Bereichs-/Gleis-/Stelle-Angaben (ZTS)),

—	Referenzdatei mit Codierung für Kundenstandorte,

—	Referenzdatei aller bestehenden Zugsteuerungssysteme,

—	Referenzdatei der Gefahrgüter, UN- und RID-Nummern,

—	Referenzdatei aller verschiedenen Lokomotiventypen,

—	Referenzdatei aller CN- und HS-Codes für Güter,

—	Referenzdatei aller europäischen Instandhaltungswerke,

—	Referenzdatei aller europäischen Auditstellen,

—	Referenzdatei aller zugelassenen europäischen Betreiber einschließlich der entsprechenden Liste nationaler Sicherheitszertifikate.

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.

—	Betriebsdatenbank für Wagen- und Intermodaleinheiten,

—	Datenbanken der Tourenpläne für Wagen/Intermodaleinheit.

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:

—	Status: Beladung des Fahrzeugs

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

—	Status: Beladener Wagen ist unterwegs

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

—	Status: Leerer Wagen ist unterwegs

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

—	Status: Entladung des Fahrzeugs

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

—	Status: leerer Wagen unter Kontrolle eines Fuhrparkbetreibers

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:

1.	Authentifizierung Eine Datenbank muss eine Authentifizierung der Systembenutzer durchführen, bevor diese den Zugriff auf die Datenbank erhalten.

2.	Datensicherheit Eine Datenbank muss Sicherheitsaspekte unterstützen, d. h. sie muss über Zugangskontrollmöglichkeiten verfügen. Eine Verschlüsselung der Datenbankinhalte selbst ist nicht erforderlich.

3.	Konsistenz Eine gewählte Datenbank muss nach dem ACID-Prinzip (Atomicity, Consistency, Isolation, Durability) arbeiten.

4.

Zugangskontrolle Eine Datenbank muss den Zugang zu Daten auf Benutzer und Systeme beschränken, denen der Zugang ausdrücklich gewährt wurde. Die Zugangskontrolle muss bis hinunter zu einzelnen Attributen eines Datensatzes möglich sein. Die Datenbank muss eine konfigurierbare, rollenabhängige Zugangskontrolle für Eintragungen, Aktualisierungen und Löschungen von Datensätzen ermöglichen.

5.	Protokollierung Eine Datenbank muss eine Protokollierung aller Aktionen in der Datenbank ermöglichen, um die Details der Dateneingabe verfolgbar zu machen (Wer, Was, Wann hat/wurde geändert?).

6.	Sperrstrategie Eine Datenbank muss mit einer Sperrstrategie arbeiten, die einen Lesezugriff auf die Daten erlaubt, während die Datensätze von anderen Benutzern bearbeitet werden.

7.	Mehrfachzugriff Eine Datenbank muss es ermöglichen, dass die Daten von mehreren Benutzern und Systemen gleichzeitig aufgerufen werden können.

8.	Zuverlässigkeit Die Zuverlässigkeit der Datenbank muss ausreichen, um die geforderte Verfügbarkeit zu erzielen.

9.	Verfügbarkeit Eine Datenbank muss für Anfragen eine Verfügbarkeit von mindestens 99,9 % bieten.

10.	Wartbarkeit Die Wartbarkeit der Datenbank muss so ausgelegt sein, dass die geforderte Verfügbarkeit erzielbar ist.

11.

Sicherheit Die Datenbanken selbst sind nicht sicherheitsrelevant. Sicherheitsaspekte spielen daher keine vorrangige Rolle. Dies darf jedoch nicht mit der Tatsache verwechselt werden, dass sich die Daten — z. B. falsche oder nicht aktuelle Daten — auf den sicheren Betrieb eines Zuges auswirken können.

12.	Kompatibilität Eine Datenbank muss mit einer gängigen Datenverarbeitungssprache wie SQL oder XQL arbeiten.

13.	Importfunktion Eine Datenbank muss es ermöglichen, formatierte Daten zu importieren und in die Datenbank einzufügen, anstatt diese von Hand einzugeben.

14.	Exportfunktion Eine Datenbank muss es ermöglichen, den gesamten Datenbankinhalt oder Teile davon als formatierte Daten zu exportieren.

15.	Pflichtfelder Eine Datenbank muss Pflichtfelder unterstützen, die unbedingt auszufüllen sind, bevor ein Datensatz in die Datenbank aufgenommen wird.

16.	Plausibilitätsprüfungen Eine Datenbank muss konfigurierbare Plausibilitätsprüfungen unterstützen, die durchzuführen sind, bevor die Eintragung, Aktualisierung oder Löschung eines Datensatzes akzeptiert wird.

17.	Antwortzeiten Eine Datenbank muss über Antwortzeiten verfügen, die eine zeitgerechte Eingabe, Aktualisierung oder Löschung von Datensätzen gestatten.

18.

Leistungsaspekte Eine Datenbank muss die Abfragen ermöglichen, die den effektiven Betrieb von 60 000 Zugfahrten in 24 Stunden gestatten. Etwa 50 % dieser Zugfahrten dürfte sich innerhalb von zwei Stunden abspielen. Anzahl und Art der Abfragen oder Aktualisierungen pro Zug richten sich nach dem Gesamtprozess für Planung und Betrieb eines Zuges.

19.

Kapazitätsaspekte Die Datenbank muss die Speicherung der relevanten Daten für alle Güterwagen bzw. für das Netz unterstützen. Die Kapazität muss sich mit einfachen Mitteln (d. h. durch Hinzufügen weiterer Speichermedien und Computer) erweitern lassen. Die Kapazitätserweiterung darf nicht zu einem Austausch des Teilsystems führen.

20.	Historische Daten Eine Datenbank muss den Zugriff auf historische Daten gestatten, d. h. sie muss Daten verfügbar machen können, die bereits in ein Archiv überstellt wurden.

21.	Backup-Strategie Es muss eine Strategie für die Datensicherung vorhanden sein, die es erlaubt, den gesamten Datenbankinhalt für Zeiträume von bis zu 24 Stunden wiederherzustellen.

22.	Kaufmännische Aspekte Das verwendete Datenbanksystem muss ein handelsübliches Produkt oder öffentlich erhältlich (Open Source) sein.

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:

—	ist so ausgelegt, dass sie heterogene Informationsmodelle in Einklang bringt, indem sie die Semantik der zwischen den Systemen ausgetauschten Daten transformiert und Unterschiede zwischen den Geschäftsprozessen und den Anwendungsprotokollen ausgleicht;

—	hat minimale Auswirkungen auf die bestehenden IT-Architekturen bei den einzelnen Akteuren;

—	trägt zum Schutz bisheriger IT-Investitionen bei.

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:

—	Metadaten — strukturierte Daten, die den Inhalt der Meldungen beschreiben;

—	Infrastruktur mit öffentlich hinterlegtem Schlüssel (PKI);

—	Zertifizierungsbehörde (CA);

—	Verzeichnis („Telefonbuch“) — es enthält alle für den Meldungsaustausch benötigten Informationen über die teilnehmenden Akteure.

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:

—	Formatierung abgehender Meldungen anhand der Metadaten,

—	Signatur und Verschlüsselung abgehender Meldungen,

—	Adressierung abgehender Meldungen,

—	Überprüfung der Authentizität eingehender Meldungen,

—	Entschlüsselung eingehender Meldungen,

—	Konformitätsprüfungen eingehender Meldungen anhand der Metadaten,

—	Behandlung des gemeinsamen Zugangs zu den verschiedenen Datenbanken.

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:

i)	positive Sendung: ACK

ii)	negative Sendung: NACK.

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

—	den Trassenvertrag, wo die einschlägigen Informationen über einsetzbare Zugsteuerungs-, Zugsicherungs- und Signalgebungstechnik in der Streckenabschnittsbeschreibung dargelegt sind, und über die

—	verschiedenen Fahrzeugreferenzdatenbanken, wo die Informationen über die fahrzeugseitige Zugsteuerungs-, Zugsicherungs- und Signalgebungstechnik gespeichert sein müssen.

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

—	fehlerfrei sind: zugänglich, genau, zeitgerecht, vollständig, übereinstimmend mit anderen Quellen usw., und

—	die gewünschten Eigenschaften besitzen: sachbezogen, umfassend, genügend detailliert, leicht zu lesen, leicht zu verstehen usw.

Die Datenqualität ist hauptsächlich charakterisiert durch:

—	Genauigkeit,

—	Vollständigkeit,

—	Konsistenz,

—	Rechtzeitigkeit.

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:

Für die TSI Telematikanwendungen für den Güterverkehr nicht relevant.

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.

Für die TSI Telematikanwendungen für den Güterverkehr nicht relevant.

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:

—	Der zentrale Speicher enthält das Verzeichnis (Telefonbuch) aller am Meldungsaustausch teilnehmenden Akteure. Dieses Verzeichnis muss jederzeit auf aktuellem Stand sein. Falsche Einträge fallen sofort auf. Kein Bewertungsverfahren erforderlich.

—	Der zentrale Speicher enthält auch die Certification Authority (Open CA PKI). Dies ist im Wesentlichen ein administrativer Akt, der physisch implementiert ist. Falsche Einträge fallen sofort auf. Kein Bewertungsverfahren erforderlich.

—

Der zentrale Speicher enthält die Metadaten zu den Meldungen (gemäß Anhang A Ziffer 1) als Basis für den Meldungsaustausch in einer heterogenen Informationsumgebung. Die Metadaten müssen im zentralen Speicher verwaltet und gepflegt werden. Eine Inkompatibilität in der Meldungsstruktur oder im Inhalt der Meldungen zum Senden und Empfangen der Daten wird sofort erkannt, und die Übertragung wird verweigert. Kein Bewertungsverfahren erforderlich.

—

Die gemeinsame Schnittstelle zu den Netzknoten der jeweiligen Akteure enthält jeweils eine lokale „Spiegelung“ des zentralen Speichers zur Verkürzung der Antwortzeiten und Entlastung des Zentralspeichers. Es muss sichergestellt sein, dass die Datenversionen im zentralen Speicher und der gemeinsamen Schnittstelle immer identisch sind. Daher muss die Datenpflege im zentralen Speicher erfolgen, und die neuen Versionen müssen von dort heruntergeladen werden. Kein Bewertungsverfahren erforderlich.

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:

1.	Vermittlung einer Zielvorgabe für die Umsetzung der TAF TSI in der europäischen Bahnindustrie;

2.	Einordnung der Zielvorgabe aus technisch-wirtschaftlicher Sicht;

3.	Aufstellung eines Zeitplans für die Maßnahmen, die im Interesse der Umsetzung der Zielvorgabe ergriffen werden müssen.

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:

1.	Die Erfassung des Bestands an IT-Altanwendungen als mögliche Grundlage für den Aufbau eines gesamteuropäischen Systems, mit dem die Anforderungen der TAF TSI erfüllt werden können (im Folgenden als „TAF-System“ bezeichnet).

2.	Die Festlegung der für die Erfüllung der TAF TSI erforderlichen funktionellen und sonstigen Daten- und Leistungsanforderungen.

3.

Skizzierung der Architektur des TAF-Systems. Grundlage hierfür sollte eine Analyse der Systemkonfigurationen sein, mit denen sich die IT-Altanlagen so integrieren lassen, dass sie die erforderliche Funktionalität aufweisen und die geforderte Leistung erbringen — z. B. zentrale oder dezentrale Client-Server-Architektur, agentenbasierte Architektur;

4.	Aufstellung der technischen und der Schnittstellen-Anforderungen an das TAF-System und seine potenziellen Teil-/Client-Systeme;

5.

Aufstellung eines Gesamtplans für die Entwicklung eines TAF-Systems vom Konzept bis zur Übergabe: Hierzu gehören auch Leitlinien für den Prozess und die Planung einer möglichen Integration von Altsystemen sowie die Risikoabschätzung für die entscheidenden Phasen eines solchen Plans. Ferner sind der bereits im Gang befindliche und der geplante Ausbau der Altanlagen zu berücksichtigen.

6.	Bestimmung geeigneter Verwaltungsstrukturen, die der Entwicklung des TAF-Systems sowie seines Betriebs während der gesamten Nutzungsdauer zugrunde liegen.

7.	Abschätzung der Kosten, die im Zusammenhang mit der Durchsetzung und dem Betrieb des TAF-Systems über den gesamten Lebenszyklus hinweg (LCC) entstehen, sowie anschließend Vorlage eines Investitionsplans.

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:

—	ein vollständiger Satz funktions-, leistungs- und systembezogener sowie technischer Spezifikationen für die Beschaffung des TAF-Systems;

—	ein Einsatzplan vom Konzept bis zur Übergabe. Das Programm muss eine detaillierte Planung der Projektphasen und der wichtigen Einzelmaßnahmen enthalten, die zum Erreichen der Endziele beitragen;

—	Festlegung der Verwaltungsstruktur und der entsprechenden Methoden und Verfahren (7) für die Entwicklung, die Validierung und den Betrieb des Systems;

—	Investitionsplan und daran anschließend ein finanztechnisches Konzept zu dessen Umsetzung.

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.

—	Eisenbahnverkehrsunternehmen und Betreiber der Infrastruktur leisten einen Beitrag durch Bereitstellung funktioneller und technischer Informationen über bestehende einzelne Telematikanwendungen für den Güterverkehr (8).

—

Die auf europäischer Ebene tätigen Fachverbände des Eisenbahnsektors nach Artikel 3 Absatz 2 der Verordnung (EG) Nr. 881/2004 erstellen einen im vorherigen Abschnitt beschriebenen Europäischen Strategischen Umsetzungsplan. Sie übermitteln diesen strategischen Plan den Mitgliedstaaten und der Kommission spätestens ein Jahr nach dem Tag der Veröffentlichung dieser Verordnung. Wird nach dieser Zeit kein deutlicher Fortschritt festgestellt, übernimmt die Europäische Kommission die Aufgabe und legt in der Folge Legislativvorschläge zur Umsetzung der angefügten TSI vor.

—

Sobald der strategische Plan fertig gestellt ist, sind alle Aktivitäten bei der Umsetzung des Teilsystems Telematikanwendungen im Güterverkehr an diesem Plan auszurichten. Alle von einem EVU oder IB vorgeschlagenen Abweichungen sind im Umsetzungsdossier zu begründen, das dem Mitgliedstaat, der Europäischen Eisenbahnagentur und der EK vorzulegen ist.

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.

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Die Grundlage für den Informationsaustausch ist gelegt. Vorteil:   Elektronische Übertragung von Dokumenten in der Endumgebung ist möglich.   Tests für die diversen weiteren Schritte können in realer Umgebung durchgeführt werden.

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.

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Die grundlegenden Informationen in der Betriebsdatenbank für Wagen und Intermodaleinheiten und in den Fahrzeugreferenzdatenbanken sind zugänglich. Eine manuelle Pflege der relevanten Daten ist möglich. Vorteil:   IT-Unterstützung für Zugtrassenantrag und Zugbildung ist gegeben.   Für Dritte, z. B. Fuhrparkbetreiber, kann ein einfacher Zugriff auf die Fahrzeugdaten realisiert 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.

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Eine Datenbank zur Speicherung von Trassen-/Zuginformationen steht bereit. Die Dateneingabe kann manuell beginnen, die Online-Verbindung zu den bestehenden IB-Systemen zur automatischen Eingabe und Pflege steht zur Verfügung. Vorteil:   Daten eingehender Meldungen können so gespeichert werden wie für die Endversion.	Die Datenbank(en) für die Bewegungsdaten der Wagen/Intermodaleinheiten und für die Ladung (Gewicht, Gefahrgüter) ist zusammen mit den benötigten Referenzdateien erstellt. Von nun an können die relevanten Daten von den gelieferten Frachtbriefen (Beförderungsauftrag) und/oder der bestehenden Zugbildung manuell oder bereits automatisch über EVU-interne Verbindung zu bestehenden Systemen zur Erfassung der Frachtbriefe und zur Erfassung der Zugbildung eingegeben werden. Der Abgleich der Wagendaten mit den Fahrzeugreferenzdatenbanken ist ebenso möglich wie die Bewertung der Zugdaten in Bezug zu den Infrastrukturdaten. Vorteil:   Unterstützung bei der Erstellung der Zugbildung.   Daten eingehender Meldungen können so gespeichert werden wie für die Endversion.

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.

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Automatische Dateneingabe in die Datenbank zur Speicherung von Trassen-/Zuginformationen. Telematikgestützte Trassendefinition in Kombination mit der Datenbank für Mitteilungen der Infrastrukturbeschränkungen. Vorteil:   Schnellere Reaktionen auf Trassenanträge, bessere bedarfsorientierte Trassennutzung, zuverlässigere Trassenmerkmalsdaten (aktueller Status in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen), verbesserte Nutzung der Infrastruktur.	Kurzfristige Trassenanträge sind möglich. Vorteil:   Stärker auf den Bedarf ausgerichtete Trassenanträge sind möglich. Schnellere Reaktion des IB auf Trassenanträge, zuverlässigere Trassenmerkmalsdaten. Beschleunigung der Wagenumlaufzeiten.

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

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Keine neuen Merkmale.	Automatische Übernahme der Frachtbriefdaten in die Datenspeicherung von Schritt 3. Automatische Erzeugung und Absendung von Beförderungsaufträgen an kooperierende EVU. Vorteil:   Schnellere Verteilung der Beförderungsaufträge, kürzere Anschlusszeiten an Wagenübergangspunkten.   Unterstützung im Einsatz internationaler Kauf-/Verkaufsverträge.

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.

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Empfang von Zugbildungsmeldungen im Voraus. Zuverlässigere Daten. Klarer Zeitstempel der Startzeit für die Trassennutzung. Automatische Aktualisierung der Datenbank zur Speicherung von Trassen-/Zuginformationen. Vorteil:   Optimierung der Trassennutzung, klare Zuständigkeit zum Startzeitpunkt.	Versand der Zugbildung erfolgt weitgehend automatisch, hohe Zuverlässigkeit der Daten, automatisches Einpflegen in die Datenspeicherung von Schritt 3. Vorteil:   Klare Zuständigkeit bei Startzeit für die IB-Leistung, zuverlässige Startzeit für Wagen/Ladungen.   Unterstützung der Kostensenkung durch reduzierte Datenerfassung an Grenzen.   Unterstützung der Beschleunigung von Transportzeiten durch garantierte Übernahme der Züge durch EVU und IB.   Unterstützung zur Minimierung von Risiken bei Wagenübergabe.

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.

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Keine neuen Merkmale.	IT-unterstützte Tourenplanung auf Wagen- und Intermodaleinheit-Ebene ist möglich. Das System ist vorbereitet, um Bewegungsmeldungen für Wagen und Intermodaleinheiten zu berechnen, zu senden und zu empfangen. Vorteil:   Der erste Schritt zur Auffindung und Verfolgung von Wagen und Ladungen auf internationaler Ebene.

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“.

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Meldungen „Zugfahrtmeldung“ und „Zugfahrtprognosemeldung“ werden in Echtzeit an benachbarte IB und an die EVU geschickt. Vorteil:   Erweiterte und zuverlässigere Planungsmöglichkeiten zur Unterstützung effizienter Trassennutzung.   Reduziert die Aufenthalte an Grenzen, unterstützt eine bedarfsorientierte Trassennutzung.	Standorte und voraussichtliche Zeiten der Züge als Basis für Berechnung der wagen- und ladungsbezogenen PÜZ/PAZ verfügbar. Vorteil:   Tool zur Erfüllung des Wunsches des Kunden, bei Auftreten von Beförderungsproblemen informiert zu werden.   Zusammen mit der Beendigung von Schritt 4 Unterstützung der Kostensenkung durch bedarfsorientierte Trassennutzung.   Erweiterte und zuverlässigere Planungsmöglichkeiten.   Unterstützung schnellerer Transportzeiten durch weniger Aufenthalte an Grenzen.   Unterstützung der Minimierung von Risiken bei Zugübergabe.

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.

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Kenntnis des Wagenstandorts auf der IB-Infrastruktur und welches EVU zuständig ist, selbst wenn der Wagen nicht in einen Zug eingestellt ist. Vorteil:   Kenntnis des Wagenstandorts und des zuständigen Unternehmens auf einem Rangierbahnhof.	PÜZ- und PAZ-Berechnung auf Basis der PZAZ-Werte, automatische Pflege der Bewegungsdaten in der Betriebsdatenbank für Wagen und Intermodaleinheiten. Internationales Management leerer Wagen vollständig realisiert. Internationale Tourenplanung vervollständigt. Vorteil:   Auffindung und Verfolgung von Ladungen auf internationaler Ebene.   Beschleunigung der Wagenumlaufzeiten.   Unterstützung internationales Management leerer Wagen.   Unterstützung Auslandsfrachten und Buchung der angebotenen Leistungen.   Unterstützung Qualitätsverbesserung internationaler Transporte.   Unterstützung internationale Tourenplanung.

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.

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Management von Verkehrsunterbrechungen und noch ausstehende Berichte für EVU realisiert. Vorteil:   Qualitätssteigerung des Dienstes.	Management von Ausnahmen und noch ausstehende Berichte realisiert. Vorteil:   Internationale Auffindung und Verfolgung von Ladungen.   Beschleunigung der Wagenumlaufzeiten.

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

Nach diesem Schritt verfügbare Merkmale für
IB	EVU
Es steht eine umfangreiche statistische Datenbasis zur Verfügung. Vorteil:   Konkrete Grundlagen zur Qualitätssteigerung und Optimierung der Dienste.

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:

—

die Erstellung eines Konfigurationsmanagementrahmens, der die Standards und Verfahren für die Weiterentwicklung des Managementsystems festlegt. Dazu ist zu bestimmen, wie vorgeschlagene Systemänderungen erfasst und verarbeitet werden sollen, wie diese Änderungen an den Systemkomponenten vorzunehmen sind und wie Systemversionen verfolgt werden sollen;

—	eine Strategie zur Herausgabe von Baselines.

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:

—	die Betreiber der Infrastruktur und die Eisenbahnverkehrsunternehmen, die unterschiedliche Versionen von Systemen mit TAF-Funktionalität einsetzen werden;

—	die Industrie, die Zeit für die Spezifizierung, Entwicklung und den Nachweis weiterhin bestehender Interoperabilität benötigt.

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:

—	die Einbeziehung bestimmter Funktionen, die heute auf nationaler Ebene realisiert sind, in den Interoperabilitätskern, sofern sie allgemein verwendbar sind;

—	sonstige künftige Mehrwertdienste.

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:

—	die Feststellung der technischen Zwänge, die bei der Änderung zu berücksichtigen sind;

—	eine Angabe dazu, wer die Verantwortung für die Verfahren zur Änderungsumsetzung übernimmt;

—	das Validierungsverfahren für die umzusetzenden Änderungen;

—	die für Änderungsmanagement, Freigabe, Migration und Durchsetzung zu verfolgende Strategie.

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 Festlegung, welche Einheiten zu managen sind, sowie ein formales Schema zur Identifizierung dieser Einheiten;

—	eine Angabe dazu, wer die Verantwortung für die Verfahren des Konfigurationsmanagements und die Eingliederung der kontrollierten Einheiten in die Entscheidungsstruktur des Konfigurationsmanagements übernimmt;

—	die Konfigurationsmanagement — Grundsätze, die für Änderungskontrolle und Versionsmanagement anzuwenden sind;

—	eine Beschreibung der für den Konfigurationsmanagementprozess zu führenden Unterlagen;

—	eine Beschreibung der Instrumente, die für das Konfigurationsmanagement zu nutzen sind, und das bei ihrer Nutzung anzuwendende Verfahren;

—	eine Definition der Konfigurationsdatenbank, die zur Aufzeichnung der Konfigurationsinformationen genutzt wird.

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.