ANHANG

INHALTSVERZEICHNIS

1. EINLEITUNG 443

1.1. Abkürzungen 443

1.2. Referenzdokumente 444

1.3. Technischer Anwendungsbereich 445

1.4. Geografischer Anwendungsbereich 445

1.5. Inhalt der TSI TAF 445

2. DEFINITION DES TEILSYSTEMS/ANWENDUNGSBEREICH 446

2.1. In der TSI behandelte Funktionen 446

2.2. In der TSI nicht behandelte Funktionen 446

2.3. Übersicht über das Teilsystem 446

2.3.1. Beteiligte 446

2.3.2. Behandelte Prozesse 448

2.3.3. Allgemeine Anmerkungen 449

3. GRUNDLEGENDE ANFORDERUNGEN 450

3.1. Erfüllung der grundlegenden Anforderungen 450

3.2. Aspekte der grundlegenden Anforderungen 450

3.3. Aspekte der allgemeinen Anforderungen 451

3.3.1. Sicherheit 451

3.3.2. Zuverlässigkeit und Verfügbarkeit 451

3.3.3. Gesundheit 451

3.3.4. Umweltschutz 451

3.3.5. Technische Kompatibilität 451

3.4. Besondere Aspekte des Teilsystems „Telematikanwendungen für den Güterverkehr“ 451

3.4.1. Technische Kompatibilität 451

3.4.2. Zuverlässigkeit und Verfügbarkeit 451

3.4.3. Gesundheit 452

3.4.4. Sicherheit 452

4. BESCHREIBUNG DES TEILSYSTEMS 452

4.1. Einleitung 452

4.2. Funktionelle und technische Spezifikationen des Teilsystems 452

4.2.1. Frachtbriefdaten 453

4.2.2. Trassenantrag 454

4.2.3. Zugvorbereitung 455

4.2.4. Zuglaufprognose 456

4.2.5. Information über Verkehrsunterbrechungen 457

4.2.6. PÜZ/PAZ Lieferung 458

4.2.7. Wagenbewegung 459

4.2.8. Wagenübergangsmeldungen 460

4.2.9. Datenaustausch zur Qualitätsverbesserung 461

4.2.10. Hauptreferenzdaten 462

4.2.11. Referenzdateien und Datenbanken 463

4.2.12. Vernetzung und Kommunikation 466

4.3. Funktionelle und technische Spezifikationen für die Schnittstellen 468

4.3.1. Schnittstellen zur TSI „Infrastruktur“ 468

4.3.2. Schnittstellen zur TSI „Zugsteuerung, Zugsicherung und Signalgebung“ 468

4.3.3. Schnittstellen zur TSI „Fahrzeuge“ 468

4.3.4. Schnittstellen zur TSI „Verkehrsbetrieb und Verkehrssteuerung“ 468

4.3.5. Schnittstellen zum Teilsystem „Telematikanwendungen für den Personenverkehr“ (TAP) 469

4.4. Betriebsvorschriften 469

4.4.1. Datenqualität 469

4.4.2. Betrieb des Zentralspeichers 471

4.5. Instandhaltungsvorschriften 471

4.6. Berufliche Qualifikationen 471

4.7. Bedingungen für den Gesundheitsschutz und die Sicherheit am Arbeitsplatz 471

5. INTEROPERABILITÄTSKOMPONENTEN 471

5.1. Begriffsbestimmung 471

5.2. Liste der Komponenten 471

5.3. Komponentenleistung und Spezifikationen 472

6. KONFORMITÄTS- UND/ODER GEBRAUCHSTAUGLICHKEITSBEWERTUNG DER KOMPONENTEN UND ÜBERPRÜFUNG DES TEILSYSTEMS 472

6.1. Interoperabilitätskomponenten 472

6.1.1. Bewertungsverfahren 472

6.1.2. Modul 472

6.1.3. Teilsystem „Telematikanwendungen für den Güterverkehr“ 472

7. UMSETZUNG 473

7.1. Modalitäten der Anwendung dieser TSI 473

7.1.1. Einleitung 473

7.1.2. Phase 1 — detaillierte IT-Spezifikationen und Gesamtplan 473

7.1.3. Phasen 2 und 3 — Entwicklung und Einführung 473

7.1.4. Gesamtkoordinierung (Governance), Aufgaben und Zuständigkeiten 473

7.2. Änderungsmanagement 475

7.2.1. Änderungsmanagementverfahren 475

7.2.2. Spezifisches Änderungsmanagementverfahren für die in Anlage I dieser Verordnung aufgeführten Dokumente 475

Anlage I: Liste der technischen Dokumente 476

Anlage II: Glossar 477

Anlage III: Aufgaben der nationalen TAF/TAP-Anlaufstelle 488

1. EINLEITUNG

1.1. Abkürzungen

Tabelle 1

Abkürzungen

Abkürzung Erklärung ANSI American National Standards Institute GS Gemeinsame Schnittstelle CR Änderungsantrag (Change Request) EC Europäische Kommission ERA Europäische Eisenbahnagentur (auch als „Agentur“ bezeichnet) ERTMS Europäisches Eisenbahnverkehrsleitsystem ETCS Europäisches Zugsteuerungs-/Zugsicherungssystem IB Infrastrukturbetreiber ISO Internationale Organisation für Normung LAN Lokales Netz (Local Area Network) LCL Containerteilladung (Less than Container Load) FEVU Federführendes Eisenbahnunternehmen ONC Open Network Computing OTIF Zwischenstaatliche Organisation für den internationalen Eisenbahnverkehr PVC Permanente virtuelle Schaltung (Permanent Virtual Circuit) RISC Ausschuss für Eisenbahninteroperabilität und -sicherheit (Rail Interoperability and Safety Committee) EVU Eisenbahnverkehrsunternehmen TAF Telematikanwendungen für den Güterverkehr (Telematic Applications for Freight) TAP Telematikanwendungen für den Personenverkehr TCP/IP Transmission Control Protocol/Internet Protocol TEN Transeuropäisches Netz TSI Technische Spezifikation für die Interoperabilität WK Wagenhalter (Wagon Keepers) WP ERA-Arbeitsgruppe (Working Party)

1.2. Referenzdokumente

Tabelle 2

Referenzdokumente

1.3. Technischer Anwendungsbereich

Diese technische Spezifikation für die Interoperabilität (nachstehend „TSI TAF“) betrifft das Element „Anwendungen für den Güterverkehr“ des Teilsystems „Telematikanwendungen“, das zu den in Anhang II der Richtlinie 2008/57/EG [1] aufgeführten funktionellen Bereichen gehört.

Zweck dieser TSI ist, durch die Festlegung des technischen Rahmens einen effizienten Informationsaustausch sicherzustellen und die Beförderungsabläufe so wirtschaftlich wie möglich zu gestalten. Die TSI erstreckt sich auf Anwendungen für den Schienengüterverkehr und die Schnittstellen zu anderen Verkehrsträgern, weshalb neben dem reinen Zugbetrieb auch allgemein die Transportdienstleistungen von EVU im Mittelpunkt stehen. Sicherheitsaspekte werden nur insoweit betrachtet, als bestimmte Datenelemente davon betroffen sind; die Werte haben keinen Einfluss auf den sicheren Zugbetrieb, und bei Einhaltung der TSI TAF sind nicht gleichzeitig auch die Sicherheitsanforderungen erfüllt.

Die TSI TAF hat zudem Auswirkungen auf die für die Nutzer geltenden Bedingungen für Eisenbahntransporte. „Nutzer“ bezeichnet in diesem Zusammenhang nicht nur die IB oder EVU, sondern auch alle anderen Dienstleister, z. B. Waggongesellschaften, Intermodalbetreiber und auch die Kunden.

Der technische Anwendungsbereich dieser TSI ist in Artikel 2 Absätze 1 und 3 dieser Verordnung näher beschrieben.

1.4. Geografischer Anwendungsbereich

Der geografische Anwendungsbereich dieser TSI ist das gesamte Eisenbahnnetz, bestehend aus:

— dem konventionellen transeuropäischen Eisenbahnnetz (TEN) gemäß Anhang I Abschnitt 1.1 „Netz“ der Richtlinie 2008/57/EG [1],

— dem transeuropäischen Hochgeschwindigkeitsbahnnetz (TEN) gemäß Anhang I Abschnitt 2.1 „Netz“ der Richtlinie 2008/57/EG [1],

— sonstigen Teilen des Netzes des Eisenbahnsystems entsprechend der Ausweitung des Anwendungsbereichs gemäß Anhang I Abschnitt 4 der Richtlinie 2008/57/EG [1].

Ausgenommen sind die in Artikel 1 Absatz 3 der Richtlinie 2008/57/EG [1] genannten Fälle.

1.5. Inhalt der TSI TAF

Der Inhalt dieser TSI steht mit Artikel 5 der Richtlinie 2008/57/EG [1] im Einklang.

Außerdem enthält die TSI in Kapitel 4 eine Beschreibung des Teilsystems sowie der Betriebs- und Instandhaltungsanforderungen für die Anwendungsbereiche gemäß den Abschnitten 1.1 (Technischer Anwendungsbereich) und 1.2 (Geografischer Anwendungsbereich).

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 2008/57/EG [1] Abschnitt 2.5 Buchstabe b definiert.

Es umfasst insbesondere:

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

— Rangier- und Zugbildungssysteme;

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

— Schnittstellen zu anderen Verkehrsträgern und die Erstellung elektronischer Begleitdokumente.

2.2. In der TSI nicht behandelte Funktionen

Abrechnungs- und Fakturierungssysteme für Kunden sowie Systeme für Abrechnung und Fakturierung zwischen verschiedenen Dienstleistern, z. B. EVU oder IB, sind nicht Gegenstand dieser TSI. Die Systemauslegung für den Datenaustausch gemäß Abschnitt 4.2 (Funktionale und technische Spezifikationen des Teilsystems) liefert jedoch die zur Abrechnung von Verkehrsleistungen benötigten Informationen.

Ebenfalls von dieser TSI TAF ausgenommen ist die Erstellung langfristiger Fahrpläne. Dennoch wird an einigen Stellen auf die Ergebnisse der Langzeitplanung verwiesen, soweit ein Bezug zum effizienten Datenaustausch besteht, wie er für den Zugbetrieb notwendig ist.

2.3. Übersicht über das Teilsystem

2.3.1. Beteiligte

Diese TSI berücksichtigt die aktuellen wie auch etwaigen künftigen Dienstleister im Güterverkehr in folgenden Bereichen (ohne Anspruch auf Vollständigkeit):

— Güterwagen,

— Lokomotiven,

— Fahrer,

— Rangierbetrieb,

— Trassenvertrieb,

— Frachtmanagement,

— Zugbildung,

— Zugbetrieb

— Zugüberwachung,

— Zugsteuerung,

— Frachtüberwachung,

— Inspektion und Instandsetzung von Wagen und/oder Lokomotiven,

— Zollabfertigung,

— Betrieb von Intermodalterminals,

— Speditionsmanagement.

Einige Dienstleister sind explizit in den Richtlinien 2012/34/EU [3], 2008/57/EG [1] und 2004/49/EG [9] definiert. Da diese Richtlinien beachtet werden müssen, sind für diese TSI insbesondere folgende Begriffsbestimmungen von Bedeutung:

„Infrastrukturbetreiber“ (IB) (Richtlinie 2012/34/EU [3]): jede Einrichtung oder jedes Unternehmen, die bzw. das insbesondere für die Einrichtung, Verwaltung und Unterhaltung der Eisenbahninfrastruktur, einschließlich Verkehrssteuerung, Zugsteuerung/Zugsicherung und Signalgebung, zuständig ist; mit den bei einem Netz oder Teilen eines Netzes wahrzunehmenden Aufgaben des IB können verschiedene Einrichtungen oder Unternehmen betraut werden. Ist der IB rechtlich, organisatorisch oder in seinen Entscheidungen nicht von Eisenbahnunternehmen unabhängig, so werden die in Kapitel IV Abschnitte 2 und 3 genannten Aufgaben jeweils von einer entgelterhebenden Stelle und einer Zuweisungsstelle wahrgenommen, die rechtlich, organisatorisch und in ihren Entscheidungen von Eisenbahnunternehmen unabhängig sind.

Ausgehend von dieser Definition gelten IB in dieser TSI als Dienstleister für die Trassenzuweisung, die Steuerung/Überwachung der Zugfahrten und für das zug-/trassenbezogene Meldewesen.

„Antragsteller“ (Richtlinie 2012/34/EU [3]): ein Eisenbahnunternehmen oder ein internationaler Zusammenschluss von Eisenbahnunternehmen oder andere natürliche oder juristische Personen wie zuständige Behörden gemäß der Verordnung (EG) Nr. 1370/2007, Verlader, Spediteure und Unternehmen des kombinierten Verkehrs, die ein gemeinwirtschaftliches oder einzelwirtschaftliches Interesse am Erwerb von Fahrwegkapazität haben.

„Eisenbahnunternehmen“ (Richtlinie 2004/49/EG [9]): die Eisenbahnunternehmen im Sinne der Richtlinie 2001/14/EG sowie jedes öffentliche oder private Unternehmen, dessen Tätigkeit im Erbringen von Eisenbahnverkehrsleistungen zur Beförderung von Gütern und/oder Personen besteht, wobei dieses Unternehmen die Traktion sicherstellen muss; dies schließt auch Unternehmen ein, die ausschließlich die Traktionsleistung erbringen.

Ausgehend von dieser Definition werden in dieser TSI Eisenbahnunternehmen als Dienstleister für den Betrieb von Zügen betrachtet.

Hinsichtlich der Zuweisung von Zugtrassen für den Betrieb eines Zuges ist auch Artikel 38 der Richtlinie 2012/34/EU [3] zu berücksichtigen:

Die Fahrwegkapazität wird von einem IB zugewiesen. Nach der Zuweisung an einen Antragsteller kann sie von diesem nicht auf ein anderes Unternehmen oder einen anderen Verkehrsdienst übertragen werden.

Jeder Handel mit Fahrwegkapazitäten ist untersagt und führt zum Ausschluss von der weiteren Zuweisung von Fahrwegkapazitäten.

Die Nutzung von Fahrwegkapazität durch ein Eisenbahnunternehmen, das die Geschäfte eines Antragstellers wahrnimmt, der kein Eisenbahnunternehmen ist, gilt nicht als Übertragung.

Was die Szenarien der Kommunikation zwischen IB und Antragstellern während der Transportdurchführung betrifft, müssen nur der IB und das EVU, nicht aber alle Arten von Antragstellern, die in der Planungsphase von Bedeutung sein können, berücksichtigt werden. 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 Trassenzuweisung bleiben hiervon unberührt.

Für einen Gütertransport müssen verschiedene Dienste bereitgestellt werden. Einer ist zum Beispiel die Bereitstellung von Güterwagen. Dieser Dienst kann von einem Fuhrparkbetreiber erbracht werden. Gehört dieser Transportdienst zum Leistungsangebot eines EVU, so fungiert das EVU gleichzeitig als Fuhrparkbetreiber. Ein Fuhrparkbetreiber kann wiederum seinen eigenen Wagenbestand und/oder den Bestand eines anderen Halters (d. h. eines anderen Dienstanbieters für Güterwagen) verwalten. Die Erfordernisse dieser Art von Dienstleistern werden berücksichtigt, unabhängig davon, ob es sich bei dem Fuhrparkbetreiber rechtlich um ein EVU handelt oder nicht.

Durch diese TSI werden weder neue juristische Personen geschaffen, noch werden EVU dazu verpflichtet, externe Dienstleister für Dienste, die sie selbst anbieten, in Anspruch zu nehmen; die TSI benennt aber, soweit erforderlich, eine Dienstleistung mit der Bezeichnung eines entsprechenden Dienstleisters. Wird der Dienst von einem EVU angeboten, so fungiert das EVU als Dienstleister für diesen Dienst.

Unter Berücksichtigung der Kundenbedürfnisse besteht einer der Dienste darin, die Transportstrecke entsprechend den mit dem Kunden getroffenen Vereinbarungen zu organisieren und zu managen. Dieser Dienst wird vom „federführenden Eisenbahnverkehrsunternehmen“ (FEVU) erbracht. Das FEVU ist die alleinige Kontaktstelle für den Kunden. Sind mehrere EVU an der Transportkette beteiligt, so ist das FEVU auch für die Koordination mit den anderen Eisenbahnverkehrsunternehmen verantwortlich.

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

Die Funktionen eines Eisenbahnunternehmens als FEVU können je nach Transportvorgang unterschiedlich sein. Im kombinierten Verkehr liegen die Verwaltung der Kapazität von Blockzügen und die Ausstellung von Frachtbriefen in den Händen eines Intermodaldienstintegrators, der dann der Kunde des FEVU sein könnte.

Der wichtigste Punkt ist jedoch, dass die EVU, IB und alle sonstigen Dienstleister (wie in diesem Anhang definiert) kooperieren müssen, sowohl durch direkte Zusammenarbeit und/oder offenen Netzzugang wie auch durch effizienten Informationsaustausch, um dem Kunden nahtlose Dienste bieten zu können.

2.3.2. Behandelte Prozesse

Gemäß der Richtlinie 2008/57/EG [1] ist diese TSI für den Schienengüterverkehrssektor auf IB und EVU/FEVU und das Verhältnis zu ihren direkten Kunden beschränkt. Gemäß einer vertraglichen Vereinbarung muss das FEVU dem Kunden insbesondere folgende Informationen mitteilen:

— Trasseninformationen

— Zuglaufmeldungen an vereinbarten Meldepunkten, darunter zumindest Abfahrts-, Wagenübergangs-/Übergabe- und Ankunftspunkte der vereinbarten Verkehrsleistung;

— voraussichtliche Ankunftszeit (PAZ) am Zielbahnhof, einschließlich Rangierbahnhöfen und Intermodalterminals;

— Verkehrsunterbrechungen. Erfährt das FEVU von einer Verkehrsunterbrechung, so muss es dies dem Kunden rechtzeitig mitteilen.

Die betreffenden TAF-konformen Meldungen für die Bereitstellung dieser Informationen sind in Kapitel 4 festgelegt.

Bei der Erbringung von Güterverkehrsdiensten beginnt die Tätigkeit eines FEVU, was die Ladung betrifft, mit dem Empfang des Frachtbriefs von seinem Kunden und, z. B. bei Wagenladungen, mit dem Zeitpunkt der Wagenfreigabe. Das FEVU erstellt für den Transport (aufgrund seiner Erfahrungen und/oder des Vertrags) einen vorläufigen Tourenplan. Beabsichtigt das FEVU, die Wagenladung in einem Zug im Rahmen des offenen Netzzugangs (das FEVU betreibt den Zug über die gesamte Fahrt) selbst zu befördern, so ist der vorläufige Tourenplan per se auch der endgültige. Beabsichtigt das FEVU, die Wagenladung in einen Zug einzustellen, der die Zusammenarbeit mit anderen EVU erfordert, so muss es zunächst die zu kontaktierenden EVU bestimmen und feststellen, wann der Übergang zwischen zwei aufeinanderfolgenden EVU stattfinden kann. Das FEVU erstellt dann die vorläufigen Beförderungsaufträge für jedes EVU als Teilformulare des vollständigen Frachtbriefs. Die Beförderungsaufträge sind im Abschnitt 4.2.1 (Frachtbriefdaten) spezifiziert.

Die kontaktierten EVU prüfen die Verfügbarkeit der 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 — ggf. auch bei anderen EVU — die Anfrage neu zu starten, bis der Tourenplan den Erfordernissen des Kunden gerecht wird.

Generell müssen die EVU/FEVU mindestens die Fähigkeit 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 Weise durch Einsatz gemeinsamer Geschäftsprozesse und vernetzter Systeme. Es müssen Möglichkeiten bestehen, dass EVU, IB sowie andere Dienstleister und Beteiligte, 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/zugesagte Transitzeiten, bestellte/bereitgestellte Wagen, vorhergesagte/tatsächliche Ankunftszeiten (PAZ);

— BETRIEB im Sinne einer produktiven Nutzung von Zug-, Infrastruktur- und Flottenkapazität durch den Einsatz von Geschäftsprozessen, Systemen und Datenaustausch, die zur Unterstützung der Fahrplanerstellung für Wagen, Intermodaleinheiten und Züge 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 IB eine Ad-Hoc-Trasse für den jeweiligen Fahrtabschnitt, auf dem das EVU den Zug betreibt, beantragen. In Anlage I wird der Vorgang eines Trassenantrags an einem Beispiel erläutert.

Der Trassenbesitz ist auch für die Kommunikation zwischen EVU und IB während der Zugfahrt von Bedeutung. Die Kommunikation muss immer auf der Zug- und der Trassennummer basieren, wobei der IB mit dem EVU kommuniziert, das die Zugtrasse auf seiner Infrastruktur gebucht hat (siehe auch Anlage I).

Falls ein EVU die gesamte Fahrt von A nach F anbietet (offener Netzzugang ohne Beteiligung anderer EVU), kommuniziert jeder beteiligte IB direkt nur mit diesem EVU. Dieser „offene Netzzugang“ durch das EVU lässt sich realisieren, indem die Zugtrasse über die einzige Anlaufstelle (One Stop Shop, OSS) oder in einzelnen Abschnitten direkt bei den jeweiligen IB gebucht wird. Die TSI berücksichtigt beide Fälle, wie in Abschnitt 4.2.2.1 (Trassenantrag, Vorbemerkungen) gezeigt wird.

Der Dialogprozess zwischen EVU und IB zur Einrichtung einer Güterzugtrasse ist in Abschnitt 4.2.2 (Trassenantrag) festgelegt. Diese Funktion bezieht sich auf Artikel 48 Absatz 1 der Richtlinie 2012/34/EU [3]. Vom Dialogprozess ausgenommen sind die Erteilung von Genehmigungen für EVU, die ihre Dienste gemäß der Richtlinie 2001/13/EG [10] anbieten, sowie die Zertifizierung und die Zugangsrechte gemäß der Richtlinie 2012/34/EU [3].

In Abschnitt 4.2.3 (Zugvorbereitung) wird der Informationsaustausch in Bezug auf die Zugbildung und das Verfahren bei der Zugabfahrt definiert. Der Datenaustausch während der Zugfahrt im Normalbetrieb ist in Abschnitt 4.2.4 (Zuglaufprognose) und die Meldungen für Ausnahmefälle in Abschnitt 4.2.5 (Information über Verkehrsunterbrechungen) festgelegt. Alle diese Meldungen werden zwischen EVU und IB ausgetauscht und basieren auf Zügen bzw. Zugfahrten.

Die wichtigste Information für den Kunden ist jedoch die voraussichtliche Ankunftszeit (PAZ) seiner Sendung. Die PAZ lässt sich (bei offenem Zugang) anhand des Datenaustauschs zwischen FEVU und IB berechnen. Bei Kooperation verschiedener EVU lassen sich PAZ und ebenso die voraussichtlichen Wagenübergangszeiten (PÜZ) aus dem Meldungsaustausch zwischen EVU und IB und deren Weiterleitung durch die EVU an das FEVU ableiten (Abschnitt 4.2.6 Lieferung PÜZ/PAZ).

Ebenfalls durch den Datenaustausch zwischen IB und EVU erfährt das FEVU beispielsweise,

— wann die Wagen einen Rangierbahnhof oder einen definierten Standort verlassen oder erreicht haben (Abschnitt 4.2.7 Wagenbewegung),

— wann in der Transportkette die Verantwortung für die Wagen von einem EVU auf das nächste EVU übergegangen ist (Abschnitt 4.2.8 Wagenübergangsmeldungen).

Nicht nur aus dem Datenaustausch zwischen IB und EVU, sondern auch aus dem zwischen EVU und FEVU lassen sich verschiedene Statistiken erstellen, nämlich

— zur detaillierteren Planung des Produktionsprozesses (mittelfristig) und

— (langfristig) zur Durchführung strategischer Planungen und Kapazitätsstudien (z. B. Netzanalysen, Festlegung von Abstellgleisen und Rangierbahnhöfen, Fahrzeugplanung), insbesondere aber

— zur Verbesserung der Transportqualität und -produktivität (Abschnitt 4.2.9, Datenaustausch zur Qualitätsverbesserung).

Bei interoperablen Wagen ist die Behandlung leerer Wagen von besonderer Bedeutung. Im Prinzip gibt es keinen Unterschied zwischen der Verwaltung beladener und unbeladener Wagen. Der Transport unbeladener Wagen basiert ebenfalls auf Beförderungsaufträgen, wobei der Flottenmanager für diese Wagen als Kunde anzusehen ist.

2.3.3. Allgemeine Anmerkungen

Ein Informationssystem ist nur so gut wie die Zuverlässigkeit der Daten. Daher müssen die Daten, die beim Transport einer Sendung, eines Wagens oder eines Containers entscheidend sind, korrekt und wirtschaftlich erfasst werden, was bedeutet, dass die Daten nur ein einziges Mal in das System eingegeben werden sollten.

Die Anwendungen und Meldungen in dieser TSI verhindern somit, dass Daten mehrfach von Hand eingegeben werden, indem auf bereits gespeicherte Daten, z. B. die Fahrzeugreferenzdaten, zurückgegriffen wird. Die Anforderungen an die Fahrzeugreferenzdaten sind in Abschnitt 4.2.10 (Hauptreferenzdaten) festgelegt. Die spezifizierten Fahrzeugreferenzdatenbanken müssen einen einfachen Zugriff auf die technischen Daten gestatten. Auf der Grundlage strukturierter und abgestufter Zugriffsrechte muss der Inhalt der Datenbanken für alle IB, EVU und Fuhrparkbetreiber zugänglich sein, insbesondere für die Zwecke des Fuhrpark-Managements und der Fahrzeuginstandhaltung. Sie müssen alle für die Beförderung entscheidenden technischen Daten enthalten, z. B.

— Fahrzeugkennung,

— technische Daten/Konstruktionsdaten,

— Bewertung der Kompatibilität mit der Infrastruktur,

— Bewertung der ladungsrelevanten Merkmale,

— bremsrelevante Merkmale,

— Instandhaltungsdaten,

— Umweltmerkmale.

Im intermodalen Verkehr werden Wagen an verschiedenen Punkten (so genannten „Gateways“) nicht nur mit einem anderen Zug verbunden, sondern auch die Intermodaleinheit kann 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 Abschnitt 4.2.11 (Referenzdateien) sind diverse Referenzdateien und Datenbanken aufgeführt, darunter die Betriebsdatenbank für Güterwagen und Intermodaleinheiten. Diese Datenbank enthält die Daten über den Betriebsstatus der Fahrzeuge, Informationen über Gewicht, gefährliche Güter und Intermodaleinheiten sowie Standortangaben.

Die TSI für das Teilsystem „Telematikanwendungen für den Güterverkehr“ legt die notwendigen Informationen fest, die zwischen den verschiedenen Akteuren in einer Transportkette ausgetauscht werden müssen, und ermöglicht die Einrichtung eines verbindlichen Standardverfahrens für den Datenaustausch. Außerdem wird das Architekturkonzept einer solchen Kommunikationsplattform dargestellt. Dies ist in Abschnitt 4.2.12 (Vernetzung und Kommunikation) skizziert, und zwar unter Berücksichtigung

— der Schnittstelle zum Teilsystem „Verkehrsbetrieb und Verkehrssteuerung“ gemäß Artikel 5 Absatz 3 der Richtlinie 2008/57/EG [1],

— der Anforderungen an den Inhalt der Schienennetz-Nutzungsbedingungen gemäß Artikel 27 und Anhang IV der Richtlinie 2012/34/EU [3],

— der zu den Güterwagen verfügbaren Informationen und der in der TSI „Fahrzeuge“ enthaltenen Instandhaltungsanforderungen.

Eine direkte Datenübertragung zwischen dem Teilsystem „Telematikanwendungen für den Güterverkehr“ und dem Fahrzeug, dem Fahrer oder Teilen des Teilsystems „Zugsteuerung, Zugsicherung und Signalgebung“ findet nicht statt; das physische Übertragungsnetz (für Meldungen nach TAF TSI) ist vollkommen unabhängig von dem Netz, das für das Teilsystem „Zugsteuerung, Zugsicherung und Signalgebung“ verwendet wird. Nachrichtlich wird das ERTMS/ETCS mit GSM-R betrieben. Für dieses offene Netz geht aus den ETCS-Spezifikationen hervor, dass die Sicherheit durch ein entsprechendes Risikomanagement in offenen Netzen mit EURORADIO-Protokoll erreicht wird.

Die Schnittstellen zu den strukturellen Teilsystemen Fahr„zeuge“ und „Zugsteuerung, Zugsicherung und Signalgebung“ sind nur über die Fahrzeugreferenzdatenbanken (Abschnitt 4.2.10.2) gegeben, die von den Fahrzeughaltern kontrolliert werden. Die Schnittstellen zu den Teilsystemen Infr„astruktur“, „Zugsteuerung, Zugsicherung und Signalgebung“ und „Energie“ werden vom IB bei der Trassenfestlegung (Abschnitt 4.2.2.3 Trassendetails) und der Spezifizierung infrastrukturabhängiger Zugdaten sowie über die von den IB bereitgestellten Informationen über Beschränkungen der Infrastruktur (Abschnitt 4.2.2 Trassenantrag und Abschnitt 4.2.3 Zugvorbereitung) vorgegeben.

3. GRUNDLEGENDE ANFORDERUNGEN

3.1. Erfüllung der grundlegenden Anforderungen

Nach Artikel 4 Absatz 1 der Richtlinie 2008/57/EG [1] müssen das transeuropäische Eisenbahnsystem, die Teilsysteme und ihre Interoperabilitätskomponenten die grundlegenden Anforderungen erfüllen, die in Anhang III der Richtlinie in allgemeiner Form beschrieben werden.

Im Anwendungsbereich der vorliegenden TSI gelten die grundlegenden Anforderungen in Kapitel 3 dieser TSI dann als erfüllt, wenn das Teilsystem den in Kapitel 4 (Beschreibung des Teilsystems) beschriebenen Spezifikationen entspricht.

3.2. Aspekte der grundlegenden Anforderungen

Die grundlegenden Anforderungen betreffen folgende Aspekte:

— Sicherheit,

— Zuverlässigkeit und Verfügbarkeit,

— Gesundheit,

— Umweltschutz,

— Technische Kompatibilität.

Gemäß der Richtlinie 2008/57/EG [1] können diese grundlegenden Anforderungen allgemein für das gesamte transeuropäische Eisenbahnsystem oder spezifisch für die einzelnen Teilsysteme und ihre Komponenten gelten.

3.3. Aspekte der allgemeinen Anforderungen

Für die Relevanz der allgemeinen Anforderungen an das Teilsystem „Telematikanwendungen für den Güterverkehr“ gilt Folgendes:

3.3.1. Sicherheit

Die grundlegenden Anforderungen 1.1.1, 1.1.2, 1.1.3, 1.1.4 und 1.1.5 in Anhang III der Richtlinie 2008/57/EG [1] sind für das Teilsystem „Telematikanwendungen“ nicht relevant.

3.3.2. Zuverlässigkeit und Verfügbarkeit

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

Dieser grundlegenden Anforderung wird in folgenden Abschnitten Rechnung getragen:

— 4.2.10: Hauptreferenzdaten,

— 4.2.11: Referenzdateien und Datenbanken,

— 4.2.12: Vernetzung und Kommunikation.

3.3.3. Gesundheit

Die grundlegenden Anforderungen 1.3.1 und 1.3.2 in Anhang III der Richtlinie 2008/57/EG [1] sind für das Teilsystem „Telematikanwendungen“ nicht relevant.

3.3.4. Umweltschutz

Die grundlegenden Anforderungen 1.4.1, 1.4.2, 1.4.3, 1.4.4 und 1.4.5 in Anhang III der Richtlinie 2008/57/EG [1] sind für das Teilsystem „Telematikanwendungen“ nicht relevant.

3.3.5. Technische Kompatibilität

Die grundlegende Anforderung 1.5 in Anhang III der Richtlinie 2008/57/EG [1] ist für das Teilsystem „Telematikanwendungen“ nicht relevant.

3.4. Besondere Aspekte des Teilsystems „Telematikanwendungen für den Güterverkehr“

3.4.1. Technische Kompatibilität

Die grundlegende Anforderung 2.7.1 des Anhangs III der Richtlinie 2008/57/EG [1] lautet:

„Die grundlegenden Anforderungen für den Bereich der Telematikanwendungen gewährleisten eine Mindestqualität der Dienstleistung für die Reisenden und die Güterverkehrskunden, insbesondere hinsichtlich der technischen 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 Nutzer einen leichten Zugriff zu den Informationen haben.“

Dieser grundlegenden Anforderung wird in folgenden Abschnitten Rechnung getragen:

— 4.2.10: Hauptreferenzdaten

— 4.2.11: Referenzdateien und Datenbanken

— 4.2.12: Vernetzung und Kommunikation.

3.4.2. Zuverlässigkeit und Verfügbarkeit

Die grundlegende Anforderung 2.7.2 des Anhangs III der Richtlinie 2008/57/EG [1] lautet:

„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 folgenden Abschnitten Rechnung getragen:

— 4.2.10: Hauptreferenzdaten

— 4.2.11: Referenzdateien und Datenbanken

— 4.2.12: Vernetzung und Kommunikation.

Diese grundlegende Anforderung, insbesondere die Nutzungsmethode zur Gewährleistung der Effizienz dieser Telematikanwendungen und der Leistungsqualität, bildet die Grundlage für die gesamte TSI und ist nicht nur auf die Abschnitte 4.2.10, 4.2.11 und 4.2.12 beschränkt.

3.4.3. Gesundheit

Die grundlegende Anforderung 2.7.3 des Anhangs III der Richtlinie 2008/57/EG [1] lautet:

„Die Benutzerschnittstellen dieser Systeme müssen den Mindestregeln für Ergonomie und Gesundheitsschutz entsprechen.“

Diese TSI enthält keine zusätzlichen Anforderungen, die über bestehende nationale und europäische Mindestanforderungen an die Ergonomie und den Gesundheitsschutz an der Schnittstelle zwischen diesen Telematikanwendungen und den Nutzern hinausgehen.

3.4.4. Sicherheit

Die grundlegende Anforderung 2.7.4 des Anhangs III der Richtlinie 2008/57/EG [1] lautet:

„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 folgenden Abschnitten Rechnung getragen:

— 4.2.10: Hauptreferenzdaten

— 4.2.11: Referenzdateien und Datenbanken

— 4.2.12: Vernetzung und Kommunikation.

4. BESCHREIBUNG DES TEILSYSTEMS

4.1. Einleitung

Das Eisenbahnsystem, das Gegenstand der Richtlinie 2008/57/EG ist und zu dem das Teilsystem „Telematikanwendungen“ gehört, ist ein integriertes System, dessen Einheitlichkeit überprüft werden muss. Diese Einheitlichkeit ist insbesondere mit Blick auf die Spezifikationen des Teilsystems, seine Schnittstellen zu dem System, in das es integriert ist, sowie auf die für Betrieb und Instandhaltung geltenden Vorschriften zu überprüfen.

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

4.2. Funktionelle und technische Spezifikationen des Teilsystems

Angesichts der in Kapitel 3 angegebenen grundlegenden Anforderungen beziehen sich die funktionellen und technischen Spezifikationen des Teilsystems auf folgende Kennwerte:

— Frachtbriefdaten,

— Trassenantrag,

— Zugvorbereitung,

— Zuglaufprognose,

— Information über Verkehrsunterbrechungen,

— PÜZ/PAZ Wagen/Intermodaleinheit,

— Wagenbewegung,

— Wagenübergangsmeldungen,

— Datenaustausch zur Qualitätsverbesserung,

— Hauptreferenzdaten,

— Referenzdateien und Datenbanken,

— Vernetzung und Kommunikation.

Im vollständigen Datenverzeichnis sind die Datenspezifikationen im Detail definiert. Das vorgeschriebene Format der Meldungen und die Daten in dieses Verzeichnisses sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert. Zu demselben Zweck können auch andere Standards verwendet werden, sofern die Beteiligten hierüber eine besondere Vereinbarung getroffen haben, insbesondere im Hoheitsgebiet von EU-Mitgliedstaaten, die an Drittländer angrenzen.

Allgemeine Anmerkungen zur Meldungsstruktur:

Die Meldungen sind in zwei Datenbereiche aufgeteilt:

— Kontrolldaten: definiert durch das obligatorische Kopfsegment der Meldungen gemäß Verzeichnis;

— Informationsdaten: definiert durch den obligatorischen/optionalen Inhalt der einzelnen Meldungen und den obligatorischen/optionalen Datensatz gemäß Verzeichnis.

Sind Meldungen oder Datenelemente laut dieser Verordnung optional, so können die beteiligten Akteure über deren Verwendung selbst entscheiden. Die Verwendung solcher Meldungen und Datenelemente muss Bestandteil einer vertraglichen Vereinbarung sein. Sind optionale Elemente des Datenverzeichnisses unter bestimmten Umständen obligatorisch, so muss dies im Datenverzeichnis spezifiziert werden.

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 gemäß den Einheitlichen Rechtsvorschriften für den Vertrag über die internationale Eisenbahnbeförderung von Gütern (CIM), den Einheitlichen Rechtsvorschriften für Verträge über die Verwendung von Wagen im internationalen Eisenbahnverkehr (CUV) sowie den geltenden nationalen Vorschriften für den Transport der Fracht vom Absender bis zum Empfänger erforderlich sind. Das FEVU muss diese Daten mit zusätzlichen Angaben ergänzen. Ein Teil der Frachtbriefdaten, einschließlich der Zusatzangaben, ist in den Dokumenten „TAF TSI — Anhang D.2: Anlage A — Fahrtenplanung Wagen/Intermodale Ladeeinheit“ und „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ beschrieben, die in der Tabelle in Anlage I dieser Verordnung aufgeführt 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. Ein Meldungsaustausch mit anderen EVU ist nicht erforderlich. Diese Daten sind auch die Grundlage für kurzfristige Trassenanträge, 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 Grundlage 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 von den FEVU an die an der Transportkette beteiligten EVU weitergeleitet werden. Der Inhalt des Beförderungsauftrages muss alle relevanten Informationen umfassen, die ein EVU für den Transport unter seiner Verantwortung bis zur Übergabe an das nächste EVU benötigt. Der Inhalt richtet sich daher nach der Rolle des EVU: Ursprungs-, Transit- oder Auslieferungs-EVU.

Die vorgeschriebene Datenstruktur des Beförderungsauftrags und Einzelheiten zu den Formaten dieser Meldung sind unter „ConsignmentOrderMessage“ in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ angegeben.

Hauptinhalt dieser Beförderungsaufträge sind:

— Absender- und Empfängerangaben,

— Streckenverlauf,

— Ladungsidentifikation,

— Wageninformation,

— Orts- und Zeitangaben.

Ausgewählte Frachtbriefdaten müssen auch allen Partnern (IB, Wagenhalter u. a.) in der Transportkette, einschließlich des Kunden, zugänglich sein. Hierzu gehören insbesondere pro Wagen:

— Ladungsgewicht (Bruttogewicht der Ladung),

— KN/HS-Nummer,

— Gefahrgutangaben,

— Transporteinheit.

Ist eine Übermittlung dieser Angaben mit Hilfe der oben definierten Meldungen nicht möglich, so kann ausnahmsweise auch die Papierform verwendet werden.

4.2.2. Trassenantrag

4.2.2.1. Vorbemerkungen

Die Zugtrasse definiert sich durch die beantragten, akzeptierten und die tatsächlichen Daten, die bezüglich der Zugtrasse selbst und der Zugmerkmale für die einzelnen Trassenabschnitte zugewiesen sind. Die folgende Beschreibung gibt die Informationen wieder, die dem IB zur Verfügung stehen müssen. Diese Informationen müssen bei jeder Veränderung aktualisiert werden. Anhand der Informationen über die vertraglich gebundenen Netzfahrplantrassen müssen sich daher die Daten für kurzfristige Änderungen abrufen lassen. Insbesondere muss der Kunde, soweit er betroffen ist, vom FEVU unterrichtet werden.

Kurzfristige Trassenanträge

Bei Ausnahmesituationen im Zugbetrieb oder kurzfristigen Transportwünschen muss ein EVU 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 EVU dem IB alle notwendigen Informationen liefern, die angeben, wann und wo der Zug eingesetzt werden soll und über welche physischen Merkmale der Zug verfügt, soweit diese für die Nutzung der Infrastruktur von Bedeutung sind.

Der Eckwert „Kurzfristige Trassenanträge“ sollte zwischen dem EVU und dem IB bearbeitet werden. Bei diesem Eckwert kann „IB“ sich auf Infrastrukturbetreiber und gegebenenfalls auch auf Zuweisungsstellen beziehen (siehe Richtlinie 2012/34/EG [3]).

Diese Anforderungen gelten für alle kurzfristigen Trassenanträge.

Fragen der Verkehrssteuerung sind nicht Gegenstand dieses Eckwertes. Die Frist, ab der zwischen kurzfristigen Trassen und Trassenänderungen im Rahmen der Verkehrssteuerung differenziert wird, unterliegt nationalen Vereinbarungen.

Das EVU muss dem IB alle notwendigen Informationen darüber liefern, wann und wo ein Zug verkehren soll und über welche physischen Merkmale der Zug verfügt, soweit diese für die Nutzung der Infrastruktur relevant sind.

Jeder IB ist für die Passfähigkeit der Zugtrasse auf seiner Infrastruktur verantwortlich, und das EVU ist verpflichtet, die Zugcharakteristik auf ihre Vereinbarkeit mit den Angaben seines Trassenvertrags hin zu überprüfen.

Unbeschadet der Bedingungen für die Nutzung einer Trasse gemäß den Schienennetz-Nutzungsbedingungen oder der Verantwortlichkeiten bei etwaigen Infrastrukturbeschränkungen gemäß der TSI „Verkehrsbetrieb und Verkehrssteuerung“ muss das EVU vor der Zugvorbereitung wissen, ob auf den Trassenabschnitten oder Bahnhöfen (Knoten) Beschränkungen bestehen, die sich auf die im Trassenvertrag beschriebene Zugbildung auswirken.

Trassenverträge für kurzfristige Zugbewegungen werden im Dialog zwischen EVU und IB geschlossen. Anträge auf Zuweisung von Fahrwegkapazität können von Antragstellern gestellt werden. Zwecks Nutzung solcher Fahrwegkapazität benennen die Antragsteller ein EVU, das mit dem IB eine Vereinbarung gemäß der Richtlinie 2012/34/EU [3] schließt. Der Dialog schließt alle EVU und IB ein, die an der Zugbewegung auf der gewünschten Strecke beteiligt sind, auch wenn ihre jeweiligen Beiträge zur Trassenfindung unterschiedlich sein können.

4.2.2.2. Trassenantrag

Für die Beantragung einer Trasse muss diese Meldung vom EVU an den IB gesendet werden.

Der vorgeschriebene Aufbau der Meldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.2.3. Trassendetails

Der IB sendet diese Meldung dem EVU als Antwort auf dessen Trassenantrag.

Der vorgeschriebene Aufbau der Meldung „Trassendetails“ und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.2.4. Trasse bestätigt

Das antragstellende EVU verwendet diese Meldung, um die vom IB vorgeschlagene Trasse zu buchen/bestätigen.

Der vorgeschriebene Aufbau der Meldung „Trasse bestätigt“ und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.2.5. Trassendetails abgelehnt

Das antragstellende EVU verwendet diese Meldung, um die vom IB vorgeschlagenen Trassendetails abzulehnen.

Das vorgeschriebene Format der Meldung „Trassendetails abgelehnt“ und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.2.6. Trasse storniert

Diese Meldung verwendet das EVU zum Stornieren einer gebuchten Trasse oder eines Teils davon.

Der vorgeschriebene Aufbau der Meldung „Trasse storniert“ und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.2.7. Trasse nicht verfügbar

Der IB sendet diese Meldung an das EVU, das die Trasse gebucht hat, wenn eine gebuchte Trasse nicht mehr verfügbar ist.

Der vorgeschriebene Aufbau der Meldung „Trasse nicht verfügbar“ und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.2.8. Empfangsbestätigung

Diese Meldung wird vom Empfänger einer Meldung an ihren Absender geschickt, um zu bestätigen, dass die Meldung innerhalb einer bestimmten Frist von seinem bestehenden System empfangen wurde.

Der vorgeschriebene Aufbau der Empfangsbestätigung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.3. Zugvorbereitung

4.2.3.1. Allgemeine Anmerkungen

Dieser Eckwert beschreibt die Meldungen, die während der Zugvorbereitung bis zur Abfahrt des Zuges ausgetauscht werden müssen.

Zur Zugvorbereitung gehört auch die Prüfung der Kompatibilität zwischen Zug und Strecke. Die Prüfung wird vom EVU anhand der von den betroffenen IB bereitgestellten Informationen über die Infrastruktur und ihre Beschränkungen durchgeführt.

Während der Zugvorbereitung muss das EVU die Zugbildungsinformationen an die nächsten EVU senden. Nach Maßgabe vertraglicher Vereinbarungen muss diese Meldung vom EVU auch an den/die IB gesendet werden, bei dem/denen es Trassenabschnitte gebucht hat.

Wird die Zugbildung an einem Ort geändert, so muss diese Meldung vom zuständigen EVU aktualisiert und erneut versendet werden.

Für die Zugvorbereitung benötigt das EVU Zugang zu Mitteilungen über Infrastrukturbeschränkungen, zu den technischen Daten der Wagen (Abschnitt 4.2.10.2: Fahrzeugreferenzdatenbanken), zu Informationen über gefährliche Güter sowie zu aktuellen Statusangaben der Wagen (Abschnitt 4.2.11.2 Weitere Datenbanken: Betriebsdatenbank für Wagen- und Intermodaleinheiten). Dies gilt für alle Wagen im Zug. Zum Schluss muss das EVU die Zugbildungsinformationen an die nächsten EVU senden. Diese Meldung muss das EVU auch an den/die IB senden, bei dem/denen es einen Trassenabschnitt gebucht hat, soweit dies in der TSI „Verkehrsbetrieb und Verkehrssteuerung des konventionellen Eisenbahnsystems“ vorgesehen ist oder zwischen EVU und IB vertraglich so vereinbart wurde.

Wird die Zugbildung an einem Ort geändert, so muss diese Meldung vom zuständigen EVU aktualisiert und erneut versendet werden.

An jedem Ort, z. B. Abfahrtsorte und Wagenübergangspunkte, an dem die Verantwortung auf ein anderes EVU übergeht, ist der Dialog für die Startprozedur „Zug fertig — Zuglaufmeldung“ zwischen IB und EVU verbindlich vorgeschrieben.

4.2.3.2. Zugbildung

Diese Meldung, die die Zugbildung festlegt, muss vom EVU an das nächste EVU gesendet werden. Soweit in den Schienennetz-Nutzungsbedingungen geregelt, muss das EVU diese Meldung auch an den/die IB senden. Bei jeder Änderung der Zugbildung während der Fahrt muss das EVU, das die Änderung vornimmt, die Meldung aktualisieren und an das FEVU senden, das die übrigen Beteiligten unterrichtet.

Der vorgeschriebene Aufbau der Zugbildungsmeldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

Die Elemente, die die Zugbildungsmeldungen zwischen EVU und IB mindestens enthalten müssen, sind in Abschnitt 4.2.2.7.2 des Beschlusses 2012/757/EU (TSI OPE) festgelegt.

4.2.3.3. Zugfertigmeldung

Das EVU sendet dem IB stets eine Zugfertigmeldung, wenn der Zug nach der Zugvorbereitung zur Abfahrt bereit ist, außer wenn der IB aufgrund nationaler Vorschriften den Fahrplan als Zugfertigmeldung akzeptiert.

Der vorgeschriebene Aufbau der Zugfertigmeldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert. Zu demselben Zweck können auch andere Standards verwendet werden, sofern die Beteiligten eine besondere Vereinbarung getroffen haben, die deren Verwendung zulässt.

4.2.4. Zuglaufprognose

4.2.4.1. Allgemeine Anmerkungen

Dieser Eckwert bestimmt die Zuglaufmeldungen und Zuglaufprognosen. Dabei sind die Modalitäten des Dialogs zwischen IB und EVU zu bestimmen, um den Austausch von Zuglaufmeldungen und Zuglaufprognosen zu gewährleisten.

Der Eckwert bestimmt die Modalitäten, nach denen der IB dem EVU sowie dem nächsten an der Zugfahrt beteiligten IB zur gegebenen Zeit Zuglaufmeldungen senden muss.

Zuglaufmeldungen dienen dazu, an vertraglich vereinbarten Meldepunkten Angaben zum aktuellen Zugstatus zu machen.

Zuglaufprognosen dienen der Meldung der prognostizierten Zeit an vertraglich vereinbarten Prognosepunkten. Diese Meldung muss der IB an das EVU sowie an den nächsten an der Zugfahrt beteiligten IB senden.

Die einzelnen Meldepunkte der Zugbewegung sind vertraglich zu vereinbaren.

Dieser Informationsaustausch zwischen EVU und IB erfolgt immer zwischen dem jeweils zuständigen IB und dem EVU, das die Trasse, auf der sich der Zug aktuell befindet, gebucht hat.

Bei vertraglicher Vereinbarung werden Zuglaufprognosen und Zuglaufmeldungen dem Kunden vom FEVU übermittelt. In der Vereinbarung legen beide Parteien die Meldepunkte gemeinsam fest.

4.2.4.2. Zuglaufprognose

Diese Meldung muss der IB an das EVU, das den Zug betreibt, für Übergabe- und Übergangspunkte sowie den Zielort gemäß Abschnitt 4.2.4.1 (Zugfahrtprognose, Allgemeine Anmerkungen) senden.

Darüber hinaus muss der IB dem EVU diese Meldung auch für andere Meldepunkte senden, die vertraglich zwischen IB und EVU festgelegt wurden (z. B. Abfertigungspunkte oder Bahnhöfe).

Zuglaufprognosen können auch vor Beginn der Zugfahrt versandt werden. Bei zusätzlichen Verspätungen zwischen zwei Meldepunkten muss zwischen dem EVU und dem IB ein Schwellenwert vereinbart werden, bei dessen Erreichen eine erste bzw. eine neue Prognose zu versenden ist. Ist die Dauer der Verspätung unbekannt, so muss der IB eine Verkehrsunterbrechungsmeldung senden (siehe Abschnitt 4.2.5 „Information über Verkehrsunterbrechungen“).

In der Zuglaufprognose ist die prognostizierte Zeit an vertraglich vereinbarten Prognosepunkten anzugeben.

Der vorgeschriebene Aufbau der Zuglaufprognosemeldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.4.3. Zuglaufmeldung und Meldung über die Zugverspätungsursache

Diese Meldung ist vom IB an das EVU, das den Zug betreibt, zu senden bei

— Abfahrt vom Abfahrtspunkt und Ankunft am Zielpunkt,

— Ankunft und Abfahrt an Übergabe-, Übergangs- und vertraglich vereinbarten Meldepunkten (z. B. Abfertigungspunkte).

Wird die (zunächst angenommene) Ursache einer Zugverspätung gemeldet, so ist diese separat in der Meldung über die Zugverspätungsursache mitzuteilen.

Der vorgeschriebene Aufbau der Zuglaufmeldung und der Meldung über die Zugverspätungsursache sowie die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.5. Information über Verkehrsunterbrechungen

4.2.5.1. Allgemeine Anmerkungen

Dieser Eckwert bestimmt den Umgang mit Verkehrsunterbrechungsmeldungen zwischen dem Eisenbahnunternehmen und dem IB.

Erfährt das EVU während der Zugfahrt, für die es verantwortlich ist, von einer Verkehrsunterbrechung, so muss es den zuständigen IB unverzüglich unterrichten (z. B. mündlich). Bei einer Fahrtunterbrechung sendet der IB dem EVU, das die Trasse gebucht hat, sowie dem nächsten an der Zugfahrt beteiligten IB eine entsprechende Zuglaufunterbrechungsmeldung.

Ist die Dauer der Verspätung bekannt, so muss der IB stattdessen eine Zuglaufprognosemeldung senden.

4.2.5.2. Zuglaufunterbrechungsmeldung

Bei einer Fahrtunterbrechung sendet der IB diese Meldung dem nächsten an der Zugfahrt beteiligten IB und dem EVU.

Der vorgeschriebene Aufbau der Zuglaufunterbrechungsmeldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.6. PÜZ/PAZ Lieferung

4.2.6.1. Vorbemerkung

In Abschnitt 4.2.2 (Trassenantrag) wurde hauptsächlich die Kommunikation zwischen EVU und IB beschrieben. Die Überwachung von einzelnen Wagen oder Intermodaleinheiten ist durch diesen Informationsaustausch nicht geregelt, sondern erfolgt auf EVU/FEVU-Ebene anhand zugspezifischer Meldungen, die in den folgenden Abschnitten 4.2.6 (Lieferung PÜZ/PAZ) bis 4.2.8 (Wagenübergangsmeldungen) beschrieben werden.

Der Austausch und die Aktualisierung von Informationen über Wagen oder Intermodaleinheiten werden im Wesentlichen durch die Speicherung von „Tourenplänen“ und „Wagenbewegungen“ unterstützt (Abschnitt 4.2.11.2: Weitere Datenbanken).

Wie bereits in Abschnitt 2.3.2 (Behandelte Prozesse) erwähnt, ist die wichtigste Information für einen Kunden immer die voraussichtliche Ankunftszeit (PAZ) seiner Lieferung. Auch in der Kommunikation zwischen FEVU und EVU ist die wagenbezogene PAZ und PÜZ von grundlegender Bedeutung. Diese Informationen sind das wichtigste Instrument für das FEVU, um den physischen Transport einer Lieferung und die Einhaltung der gegenüber dem Kunden getroffenen Zusagen zu überwachen.

Die prognostizierten Zeiten in den zugspezifischen Meldungen beziehen sich auf die Ankunft des Zuges an einem bestimmten Punkt, bei dem es sich um einen Übergabepunkt, einen Wagenübergangspunkt, den Zielort oder einen anderen Meldepunkt handeln kann. Stets handelt sich dabei um die voraussichtliche Ankunftszeit des Zuges (PZAZ). Diese PZAZ kann für die einzelnen Wagen oder Intermodaleinheiten in einem Zug unterschiedliche Bedeutungen haben. Eine für einen Wagenübergangspunkt berechnete PZAZ kann beispielsweise die voraussichtliche Wagenübergangszeit (PÜZ) für bestimmte Wagen oder Intermodaleinheiten sein. Für andere Wagen, die zur weiteren Beförderung durch dasselbe EVU im Zugverband bleiben, ist diese PZAZ unter Umständen ohne Bedeutung. Das EVU, das die PZAZ-Information erhält, hat die Aufgabe, die Information zu identifizieren und zu verarbeiten, sie als Wagenbewegung in der Betriebsdatenbank für Wagen und Intermodaleinheiten zu speichern und sie dem FEVU mitzuteilen, sofern der Zug nicht im Rahmen des offenen Netzzugangs betrieben wird. Dies wird in den folgenden Abschnitten behandelt.

Die voraussichtliche Ankunftszeit (PAZ) und die voraussichtliche Übergangszeit (PÜZ) der Lieferung werden dem Kunden vom FEVU gemäß einer vertraglichen Vereinbarung mitgeteilt. In der Vereinbarung legen beide Parteien die Ausführlichkeit der Meldungen fest.

Im intermodalen Verkehr wird in den Datenmeldungen, die die Kennung der Ladeeinheiten (z. B. Container, Wechselbehälter oder Sattelanhänger) enthalten, entweder ein BIC- oder ein ILU-Code gemäß ISO 6346 bzw. EN 13044 verwendet.

4.2.6.2. Berechnung der PÜZ/PAZ

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

Für die Wagenübergangspunkte oder 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 sich im Zug eines EVU Wagen mit verschiedenen Routen und von verschiedenen FEVU befinden können, kann der Wagenübergangspunkt für die Berechnung der PÜZ der Wagen unterschiedlich sein. Eine bildliche Darstellung dieser Szenarien ist in dem in Anlage I genannten Dokument „TAF TSI — Anhang A.5: Abbildungen und Ablaufdiagramme der TAF-TSI-Meldungen“ Abschnitt 1.4 wiedergegeben. Das Ablaufdiagramm zu Beispiel 1 für den Wagenübergangspunkt C ist in dem in Anlage I genannten Dokument „TAF TSI — Anhang A.5: Abbildungen und Ablaufdiagramme der TAF-TSI-Meldungen“ Kapitel 5 dargestellt.

Anhand der PÜZ-Angaben des vorherigen EVU berechnet das nächste EVU die wagenbezogene PÜZ für den folgenden Wagenübergangspunkt. Diese Schritte werden von jedem nachfolgenden EVU ausgeführt. Wenn das letzte EVU (z. B. EVU n) in der Transportkette eines Wagens die PÜZ vom vorausgehenden EVU (z. B. EVU n-1) für den Wagenübergang von EVU n-1 nach EVU n erhält, muss das letzte EVU (EVU n) die voraussichtliche Ankunftszeit der Wagen am Zielbahnhof errechnen. Auf diese Weise können die Wagen entsprechend dem Beförderungsauftrag und den Verpflichtungen des FEVU gegenüber dem Kunden platziert werden. Es handelt sich dabei um die wagenspezifische PAZ, die an das FEVU gesendet werden muss. Sie muss zusammen mit der Wagenbewegung elektronisch gespeichert werden. Das FEVU muss dem Kunden nach Maßgabe der Vertragsbedingungen Zugang zu seinen relevanten Daten gewähren.

Anmerkung zu Intermodaleinheiten: Für die Intermodaleinheiten auf einem Wagen sind die wagenbezogenen PÜZ zugleich die PÜZ für die Intermodaleinheiten. In Bezug auf die PAZ für Intermodaleinheiten ist darauf hinzuweisen, dass das EVU nur die Zeiten für den Schienentransport berechnen und daher nur die PÜZ am Intermodalterminal liefern kann.

Das FEVU ist verantwortlich für den Vergleich zwischen PAZ und der gegenüber dem Kunden abgegebenen Zusage.

Abweichungen der PAZ von der Zusage gegenüber dem Kunden sind entsprechend den Vertragsbestimmungen zu behandeln und können einen Alarmmanagement-Prozess beim FEVU auslösen. Für die Übertragung der Ergebnisse dieses Prozesses ist die Alarmmeldung vorgesehen.

Für die Abwicklung des Alarmmanagement-Prozesses muss das FEVU die Möglichkeit haben, wagenbezogene Abfragen zu den Abweichungen vorzunehmen. Die Abfrage durch das FEVU sowie die Antwort des EVU werden ebenfalls nachfolgend beschrieben.

4.2.6.3. Wagenspezifische PÜZ/PAZ-Meldung

Diese Meldung dient dazu, die PÜZ bzw. aktualisierte PÜZ von einem EVU an das nächste EVU in der Transportkette zu senden. Das letzte EVU in der Wagentransportkette sendet die PAZ bzw. aktualisierte PAZ an das FEVU. Der vorgeschriebene Aufbau der wagenspezifischen PÜZ/PAZ-Meldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.6.4. Alarmmeldung

Nach dem Abgleich zwischen der PAZ und der Zusage gegenüber dem Kunden kann das FEVU den beteiligten EVU eine Alarmmeldung schicken. Der vorgeschriebene Aufbau der Alarmmeldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

Hinweis: Bei offenem Netzzugang handelt es sich bei der Berechnung der PÜZ und PAZ um einen internen Vorgang des EVU. In diesem Fall ist das EVU selbst das federführende EVU.

4.2.7. Wagenbewegung

4.2.7.1. Vorbemerkungen

Die in den Meldungen über Wagenbewegungen enthaltenen Daten müssen gespeichert werden und elektronisch zugänglich sein. Falls vertraglich vereinbart, müssen diese Meldungen auch mit autorisierten Parteien ausgetauscht werden.

— Wagenfreigabe

— Wagenabfahrt

— Wagenankunft Rangierbahnhof

— Wagenabfahrt Rangierbahnhof

— Wagenausnahme

— Wagenankunft

— Wagenablieferung

— Wagenübergangsmeldungen werden in Abschnitt 4.2.8 gesondert beschrieben.

Gemäß der vertraglichen Vereinbarung muss das FEVU dem Kunden die Informationen über die Wagenbewegungen anhand der nachstehend beschriebenen Meldungen mitteilen.

4.2.7.2. Wagenfreigabemeldung

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.

Diese Daten sind in der Betriebsdatenbank für Wagen und Intermodaleinheiten zu speichern. Der vorgeschriebene Aufbau der Wagenfreigabemeldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.7.3. Wagenabfahrtsmeldung

Das EVU muss dem FEVU Datum und Uhrzeit mitteilen, zu denen der Wagen den Abfahrtsort tatsächlich verlassen hat.

Diese Daten sind in der Betriebsdatenbank für Wagen und Intermodaleinheiten zu speichern. Mit diesem Meldungsaustausch geht die Verantwortung für den Wagen vom Kunden auf das EVU über. Der vorgeschriebene Aufbau der Wagenabfahrtsmeldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.7.4. Wagenankunft Rangierbahnhof

Das EVU muss das FEVU informieren, dass der Wagen am Rangierbahnhof angekommen ist. Diese Meldung kann auf der „Zuglaufmeldung“ gemäß Abschnitt 4.2.4 (Zuglaufprognose) basieren. Der Vorgang ist in der Betriebsdatenbank für Wagen und Intermodaleinheiten zu speichern. Der vorgeschriebene Aufbau der Meldung „Wagenankunft Rangierbahnhof“ und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.7.5. Wagenabfahrt Rangierbahnhof

Das EVU muss das FEVU informieren, dass der Wagen den Rangierbahnhof verlassen hat. Diese Meldung kann auf der „Zuglaufmeldung“ gemäß Abschnitt 4.2.4 (Zuglaufprognose) basieren. Der Vorgang ist in der Betriebsdatenbank für Wagen und Intermodaleinheiten zu speichern. Der vorgeschriebene Aufbau der Meldung „Wagenabfahrt Rangierbahnhof“ und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.7.6. Wagenausnahme

Das EVU muss das FEVU über unerwartete Vorkommnisse informieren, die sich möglicherweise auf die PÜZ/PAZ des Wagens auswirken oder zusätzliche Maßnahmen erfordern. In den meisten Fällen erfordert diese Meldung auch eine Neuberechnung der PÜZ/PAZ. Beschließt das FEVU, eine neue PÜZ/PAZ anzufordern, so sendet es eine Meldung zusammen mit der Angabe „Neue PÜZ/PAZ erforderlich“ zurück an das EVU, das die Meldung geschickt hat. Die neue PÜZ/PAZ ist nach dem Verfahren in Abschnitt 4.2.6 (Lieferung PÜZ/PAZ) zu berechnen.

Diese Information muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden. Der vorgeschriebene Aufbau der Wagenausnahmemeldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.7.7. Wagenankunftsmeldung

Das letzte EVU in der Transportkette eines Wagens oder einer Intermodaleinheit muss das FEVU informieren, dass der Wagen am Rangierbahnhof angekommen ist (EVU-Standort). Der vorgeschriebene Aufbau der Wagenankunftsmeldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.7.8. Wagenablieferungsmeldung

Das letzte EVU in der Transportkette eines Wagens muss das FEVU informieren, dass der Wagen auf dem Gleis des Empfängers abgestellt wurde.

Hinweis: Bei offenem Netzzugang handelt es sich bei den beschriebenen Wagenbewegungen um interne Vorgänge des EVU (FEVU). Trotzdem sind von ihm alle Berechnungen und Datenspeicherungen als FEVU vorzunehmen, das einen Vertrag mit dem Kunden und Verpflichtungen ihm gegenüber hat.

Das Ablaufdiagramm für diese Meldungen — basierend auf Beispiel 1 der PÜZ-Berechnung für die Wagen 1 und 2 (siehe Abschnitt 4.2.6.2 Berechnung der PÜZ/PAZ) — ist in das Ablaufdiagramm für die Wagenübergangsmeldung in dem in Anlage I genannten Dokument „TAF TSI — Anhang A.5: Abbildungen und Ablaufdiagramme der TAF-TSI-Meldungen“ integriert.

4.2.8. Wagenübergangsmeldungen

4.2.8.1. Vorbemerkung

Das Berichtswesen zum Wagenübergang beschreibt die Meldungen, die mit der Übertragung der Verantwortung für einen Wagen von einem EVU an das nächste verbunden sind; diese Übertragung findet an Wagenübergangspunkten statt. Es verpflichtet das neue EVU, eine PÜZ zu berechnen und das in Abschnitt 4.2.6 (Lieferung PÜZ/PAZ) beschriebene Verfahren anzuwenden.

Folgende Meldungen müssen ausgetauscht werden:

— Wagenübergang,

— Wagenübergang/Sub,

— Wagen am Übergangspunkt erhalten,

— Wagen am Übergangspunkt abgelehnt.

Die Informationen in diesen Meldungen sind in der Betriebsdatenbank für Wagen und Intermodaleinheiten zu speichern. Bei etwaigen Verspätungen müssen neue PÜZ/PAZ generiert und nach dem in Abschnitt 4.2.6 (Lieferung PÜZ/PAZ) beschriebenen Verfahren mitgeteilt werden. Das Ablaufdiagramm für diese Meldungen zusammen mit den Meldungen über die Wagenbewegungen ist in dem in Anlage I genannten Dokument „TAF TSI — Anhang A.5: Abbildungen und Ablaufdiagramme der TAF-TSI-Meldungen“ dargestellt.

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

Beim offenen Netzzugang gibt es keine Wagenübergangspunkte. An Abfertigungspunkten bleibt die Verantwortung für die Wagen unverändert, sodass kein spezieller Meldungsaustausch erforderlich ist. Allerdings müssen aus der an diesem Meldepunkt abgesetzten Zugfahrtmeldung die Informationen über den Wagen bzw. die Intermodaleinheit (Standort, Datum/Uhrzeit der Ankunft/Abfahrt) entnommen, verarbeitet und in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden.

Gemäß der vertraglichen Vereinbarung muss das FEVU dem Kunden die Wagenübergangsinformationen anhand der nachstehend beschriebenen Meldungen mitteilen.

Der vorgeschriebene Aufbau dieser Meldungen ist in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.8.2. Wagenübergangsmeldung

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“ teilt das EVU 2 seinem IB mit, dass es die Verantwortung übernommen hat. Der vorgeschriebene Aufbau der Wagenübergangsmeldung und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.8.3. Wagenübergang/Sub

Mit der Meldung „Wagenübergang/Sub“ teilt das EVU 2 dem IB mit, dass es die Verantwortung für einen bestimmten Wagen übernommen hat. Der vorgeschriebene Aufbau der Meldung „Wagenübergang/Sub“ und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.8.4. Wagen am Übergangspunkt erhalten

Mit der Meldung „Wagen am Übergangspunkt erhalten“ teilt das EVU 2 dem EVU 1 mit, dass es die Verantwortung für den Wagen übernimmt. Der vorgeschriebene Aufbau der Meldung „Wagen am Übergangspunkt erhalten“ und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.8.5. Wagen am Übergangspunkt abgelehnt

Mit der Meldung „Wagen am Übergangspunkt abgelehnt“ teilt das EVU 2 dem EVU 1 mit, dass es nicht bereit ist, die Verantwortung für den Wagen zu übernehmen. Der vorgeschriebene Aufbau der Meldung „Wagen am Übergangspunkt abgelehnt“ und die zu beachtenden Elemente sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.9. Datenaustausch zur Qualitätsverbesserung

Um wettbewerbsfähig zu sein, muss die europäische Eisenbahnbranche ihren Kunden Dienste von höherer Qualität anbieten (siehe auch Anhang III Nummer 2.7.1 der Richtlinie 2008/57/EG [1]). Ein Messprozess ist ein wesentlicher nachlaufender Prozess, um Qualitätsverbesserungen zu erreichen. Neben der Messung der Qualität der für den Kunden erbrachten Leistung müssen FEVU, EVU und IB auch die Qualität der einzelnen Bestandteile der Leistung messen, die zusammen das dem Kunden gelieferte Produkt darstellen. An dem Verfahren beteiligt sind die IB und die EVU (insbesondere wenn es federführende EVU sind). Sie wählen einen individuellen Qualitätsparameter, eine Strecke oder einen Ort und einen Erfassungszeitraum aus, in dem die tatsächlichen Ergebnisse gemessen und mit zuvor, in der Regel vertraglich festgelegten Kriterien verglichen werden. Aus den Ergebnissen der Messung muss klar hervorgehen, inwieweit die zwischen den Vertragsparteien vereinbarten Zielen erreicht wurden.

4.2.10. Hauptreferenzdaten

4.2.10.1. Vorbemerkung

Die Infrastrukturdaten (Schienennetz-Nutzungsbedingungen und Mitteilungen über Infrastrukturbeschränkungen) und die Fahrzeugdaten (in der Fahrzeugreferenzdatenbank und der Betriebsdatenbank für Wagen und Intermodaleinheiten) sind die wichtigsten Daten für den Güterzugverkehr im europäischen Schienennetz. Beide zusammen ermöglichen es, die Kompatibilität zwischen Fahrzeugen und Infrastruktur zu bewerten und mehrfache Dateneingaben zu verhindern, wodurch sich insbesondere die Datenqualität verbessert. Darüber hinaus geben sie jederzeit ein klares Bild über die verfügbaren Anlagen und Ausrüstungen, um während des Betriebs rasche Entscheidungen treffen zu können.

4.2.10.2. Fahrzeugreferenzdatenbanken

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

Die Informationen, die in den einzelnen Fahrzeugreferenzdatenbanken enthalten sein müssen, sind in der in Anlage I genannten Anlage C ausführlich beschrieben und beziehen sich auf Folgendes:

— Fahrzeugkennung,

— Bewertung der Kompatibilität mit der Infrastruktur,

— Bewertung der ladungsrelevanten Merkmale,

— bremsrelevante Merkmale,

— Instandhaltungsdaten,

— Umweltmerkmale.

Die Fahrzeugreferenzdatenbank muss einen leichten Zugriff (einziger gemeinsamer Zugriff über die gemeinsame Schnittstelle) auf die technischen Daten ermöglichen, um das bei jedem Vorgang zu übertragende Datenvolumen zu begrenzen. Auf der Grundlage strukturierter und abgestufter Zugriffsrechte muss der Inhalt der Datenbanken allen Dienstleistern (IB, EVU, Logistikanbieter und Fuhrparkbetreiber) zugänglich sein, insbesondere zu Zwecken des Fuhrpark-Managements und der Fahrzeuginstandhaltung.

Die Einträge in der Fahrzeugreferenzdatenbank lassen sich wie folgt einteilen:

— Verwaltungsdaten: Diese beziehen sich auf Zertifizierungs- und Zulassungsaspekte, z. B. Verweise auf die EG-Zulassungsdatei, Kennung der benannten Stelle usw., und können auch historische Daten über Eigentumsverhältnisse, Vermietungen u. a. beinhalten. Darüber hinaus können die Wagenhalter nach Artikel 5 der Verordnung (EU) Nr. 445/2011 der Kommission die Nummer der ECM-Bescheinigung in den Fahrzeugreferenzdatenbanken speichern. Folgende Aspekte sind dabei zu berücksichtigen: — EG-Bescheinigung, — Zulassung im Heimatland, — Datum der Indienststellung im Zulassungsland, — Zulassung in anderen Ländern für den Betrieb im nationalen 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 diesbezüglichen Verfahren durchgeführt wurden.

— Konstruktionsdaten: Diese müssen alle baulichen (physischen) Elemente der Fahrzeuge enthalten, einschließlich Umweltmerkmalen und aller Informationen, die voraussichtlich über die gesamte Lebensdauer des Fahrzeugs gültig sind; dieser Teil kann auch eine Historie größerer Umbauten, Instandhaltungen, Überholungen usw. enthalten.

4.2.10.3. Fahrzeugbetriebsdaten

Neben den Fahrzeugreferenzdaten sind die Daten, die den aktuellen Status des Fahrzeuges angeben, die für den betrieblichen Einsatz wichtigsten Daten.

Diese Daten müssen temporäre Daten umfassen, z. B. Beschränkungen, laufende und geplante Instandhaltung, Kilometerstand und Fehlerzähler etc., sowie alle als „Statusdaten“ anzusehende Angaben (vorübergehende Geschwindigkeitsbeschränkungen, isolierte Bremse, Reparaturbedarf, Fehlerbeschreibung u. a.).

Von den verschiedenen Akteuren, die während des Transports für die Fahrzeuge verantwortlich sind, müssen im Hinblick auf die Nutzung der betrieblichen Fahrzeugdaten drei Parteien berücksichtigt werden:

— das EVU als Gefahrenhalter während der Transportsteuerung,

— der Fahrzeughalter und

— der Nutzer (Mieter) eines Fahrzeugs.

Den autorisierten Nutzern der drei Parteien müssen die betrieblichen Fahrzeugdaten entsprechend ihrer Autorisierung mit einem einzigen, durch die Wagenkennung (Wagennummer) gegebenen Schlüssel zugänglich sein.

Die betrieblichen Fahrzeugdaten sind Teil der Betriebsdatenbank für Wagen und Intermodaleinheiten, die in Abschnitt 4.2.11.2 (Weitere Datenbanken) beschrieben ist.

4.2.11. Referenzdateien und Datenbanken

4.2.11.1. Referenzdateien

Für den Betrieb von Güterzügen im 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. Wird eine Referenzdatei in Verbindung mit der TSI TAP [2] verwendet, so sind Entwicklung und Änderungen an die TSI TAP [2] anzulehnen, um optimale Synergien zu erzielen.

Lokal gespeichert und verwaltet:

a) Referenzdatei der Notrufzentralen für die verschiedenen Gefahrgüter.

Zentral gespeichert und verwaltet:

b) Referenzdatei mit der Codierung aller IB, EVU und Dienstleistungsunternehmen

c) Referenzdatei mit der Codierung von Güterverkehrskunden

d) Referenzdatei mit den (Primär- und Alternativ-)Codierungen aller Standorte.

Die Europäische Eisenbahnagentur bewahrt eine Kopie der Referenzdatei mit den Standort- und Unternehmenscodes auf. Auf individuelle Anforderung und unbeschadet der Rechte an geistigem Eigentum müssen diese Daten öffentlich zugänglich gemacht werden.

Sonstige Codierungslisten sind in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ definiert.

4.2.11.2. Weitere Datenbanken

Für die Verfolgung von Zug- und Wagenbewegungen müssen die folgenden Datenbanken eingerichtet werden, die bei jedem relevanten Ereignis in Echtzeit zu aktualisieren sind. Autorisierte Rechtspersonen wie Wagenhalter und Fuhrparkbetreiber müssen entsprechend den bilateralen Vereinbarungen Zugriff auf die zur Erfüllung ihrer Funktionen relevanten Daten haben.

— Betriebsdatenbank für Wagen- und Intermodaleinheiten,

— Tourenplan-Datenbank für Wagen/Intermodaleinheiten.

Diese Datenbanken müssen über die gemeinsame Schnittstelle zugänglich sein (4.2.12.1: Allgemeine Architektur und 4.2.12.6: Gemeinsame Schnittstelle).

Im intermodalen Verkehr wird in den Datenmeldungen, die die Kennung der Ladeeinheiten (z. B. Container, Wechselbehälter oder Sattelanhänger) enthalten, entweder ein BIC- oder ein ILU-Code gemäß ISO 6346 bzw. EN 13044 verwendet.

Betriebsdatenbank für Wagen und Intermodaleinheiten

Die Kommunikation zwischen dem FEVU und den EVU im Kooperationsmodus beruht auf den Nummern der Wagen und/oder Intermodaleinheiten. Die EVU, die mit den IB auf Zugebene kommunizieren, müssen diese Informationen deshalb nach Wagen und Intermodaleinheiten aufschlüsseln. Diese aufgeschlüsselten Informationen müssen in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden. Durch die Zugbewegungsdaten werden neue Einträge/Aktualisierungen in der Betriebsdatenbank für Wagen- und Intermodaleinheiten zur Information des Kunden generiert. Der die Bewegung der Wagen oder Intermodaleinheiten betreffende Teil der Datenbank wird spätestens dann erstellt, wenn der Kunde die Freigabezeit für die Wagen/Intermodaleinheiten mitteilt. Diese Freigabezeit ist der erste Eintrag in der Betriebsdatenbank für Wagen und Intermodaleinheiten, der die Bewegungsdaten einer Fahrt betrifft. Die Meldungen für die Wagenbewegung sind in den Abschnitten 4.2.8 (Wagenbewegung) und 4.2.9 (Wagenübergangsmeldungen) definiert. Diese Datenbank muss über die gemeinsame Schnittstelle zugänglich sein (4.2.12.1: Allgemeine Architektur und 4.2.12.6: 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 FEVU. Sie dokumentiert die Bewegung der Wagen und Intermodaleinheiten vom Abfahrtsort bis zur Übergabe am Abstellgleis des Kunden, einschließlich der PÜZ und Ist-Zeiten an verschiedenen Meldepunkten bis zur voraussichtlichen Ankunftszeit (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 zwischen dem EVU, den IB und den anderen an der Fahrt beteiligten EVU erforderlich.

— Status: Beladener Wagen ist unterwegs Diese Statusangabe ist für den Informationsaustausch zwischen IB und EVU sowie den anderen an der Fahrt beteiligten IB und EVU erforderlich.

— Status: Leerer Wagen ist unterwegs Diese Statusangabe ist für den Informationsaustausch zwischen IB und EVU sowie den anderen an der Fahrt beteiligten IB und EVU erforderlich.

— Status: Entladung des Fahrzeugs Diese Statusangabe ist für den Informationsaustausch zwischen dem EVU am Zielpunkt und dem für den Transport verantwortlichen FEVU erforderlich.

— Status: leerer Wagen unter Kontrolle eines Fuhrparkbetreibers Diese Statusangabe wird benötigt, um Informationen über die Verfügbarkeit von Fahrzeugen mit bestimmten Eigenschaften abrufen zu können.

Tourenplan-Datenbanken

Züge können aus Wagen verschiedener Kunden zusammengestellt sein. Das FEVU (das als Dienstintegrator agierende EVU) muss für jeden Wagen einen Tourenplan erstellen und aktualisieren, der auf Zugebene der Zugtrasse entspricht. Neue Trassen für einen Zug, z. B. bei Verkehrsunterbrechungen, erfordern auch neue Tourenpläne für die betroffenen Wagen. Der Tourenplan wird erstellt, wenn der Frachtbrief des Kunden eingeht.

Der Wagen-Tourenplan muss bei jedem FEVU in einer Datenbank gespeichert werden. Diese Datenbanken müssen über die gemeinsame Schnittstelle zugänglich sein (4.2.14.1: Allgemeine Architektur und 4.2.12.6: Gemeinsame Schnittstelle).

Hinweis:

Zusätzlich zu den zuvor genannten obligatorischen Datenbanken kann jeder IB eine Zugdatenbank installieren.

Eine Zugdatenbank des IB entspricht dem Bewegungsteil in der Betriebsdatenbank für Wagen und Intermodaleinheiten. Die wichtigsten Dateneinträge sind die zugspezifischen Daten in der Zugbildungsmeldung des EVU. Jedes Zugereignis hat eine Aktualisierung dieser zugspezifischen Datenbank zur Folge. Alternativ können diese Daten auch in der Trassendatenbank gespeichert werden (Abschnitt 4.2.2: Trassenantrag). Diese Datenbanken müssen über die gemeinsame Schnittstelle zugänglich sein (4.2.14.1: Allgemeine Architektur und 4.2.12.6: Gemeinsame Schnittstelle).

4.2.11.3. Zusätzliche Datenbankanforderungen

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

Diese sind:

1. Authentifizierung Vor dem Zugriff auf eine Datenbank muss eine Authentifizierung der Systembenutzer erfolgen.

2. Sicherheit Datenbanken müssen Sicherheitsaspekte unterstützen, d. h. über Zugangskontrollmöglichkeiten verfügen. Eine Verschlüsselung der eigentlichen Datenbankinhalte ist nicht erforderlich.

3. Konsistenz Eine gewählte Datenbank muss nach dem AKID-Prinzip (Atomarität, Konsistenzerhaltung, Isolation, Dauerhaftigkeit) arbeiten.

4. Zugangskontrolle Datenbanken müssen 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 Datenbanken müssen eine Protokollierung aller darin vorgenommenen Aktionen ermöglichen, um die Details der Dateneingabe verfolgbar zu machen (Wer/Was/Wann hat/wurde geändert?).

6 Sperrstrategie Datenbanken müssen mit einer Sperrstrategie arbeiten, die einen Lesezugriff auf die Daten erlaubt, während die Datensätze von anderen Benutzern bearbeitet werden.

7. Mehrfachzugriff Die Daten der Datenbanken müssen von mehreren Benutzern und Systemen gleichzeitig aufgerufen werden können.

8. Zuverlässigkeit Datenbanken müssen so zuverlässig sein, wie es für die geforderte Verfügbarkeit notwendig ist.

9. Verfügbarkeit Datenbanken müssen für Anfragen eine Verfügbarkeit von mindestens 99,9 % bieten.

10. Wartbarkeit Die Wartbarkeit von Datenbanken muss so ausgelegt sein, dass die geforderte Verfügbarkeit erzielt werden kann.

11. Sicherheit Die Datenbanken selbst erfordern keine spezifischen Sicherheitsmaßnahmen, sodass Sicherheitsaspekte keine Rolle spielen. Dies ist jedoch nicht mit der Tatsache zu verwechseln, dass sich die Daten — z. B. falsche oder überholte Daten — auf den sicheren Zugbetrieb auswirken können.

12. Kompatibilität Datenbanken müssen mit einer gängigen Datenverarbeitungssprache wie SQL oder XQL arbeiten.

13. Importfunktion Datenbanken müssen die Möglichkeit bieten, formatierte Daten zu importieren und einzufügen, anstatt sie von Hand einzugeben.

14. Exportfunktion Datenbanken müssen die Möglichkeit bieten, den gesamten Inhalt oder Teile davon als formatierte Daten zu exportieren.

15. Pflichtfelder Datenbanken müssen Pflichtfelder unterstützen, die auszufüllen sind, bevor ein Datensatz in die Datenbank aufgenommen wird.

16. Plausibilitätsprüfungen Datenbanken müssen konfigurierbare Plausibilitätsprüfungen unterstützen, die durchzuführen sind, bevor der Eintrag, die Aktualisierung oder Löschung eines Datensatzes akzeptiert wird.

17. Antwortzeiten Datenbanken müssen über Antwortzeiten verfügen, die eine zeitgerechte Eingabe, Aktualisierung und Löschung von Datensätzen ermöglichen.

18. Leistungsaspekte Die Referenzdateien und Datenbanken müssen auf wirtschaftliche Weise die Abfragen unterstützen, die zur Gewährleistung eines effizienten Zug- und Wagenbetriebs im Rahmen dieser TSI notwendig sind.

19. Kapazitätsaspekte Datenbanken müssen die Möglichkeit bieten, die relevanten Daten für alle Güterwagen bzw. das Netz zu speichern. Die Kapazität muss sich mit einfachen Mitteln (d. h. durch Hinzufügen weiterer Speichermedien und Computer) erweitern lassen. Die Kapazitätserweiterung muss ohne Austausch des Teilsystems möglich sein.

20. Historische Daten Datenbanken müssen die Verwaltung historischer Daten ermöglichen, d. h. Daten verfügbar machen können, die bereits in ein Archiv überstellt wurden.

21. Datensicherungsstrategie Es muss eine Strategie für die Datensicherung bestehen, die es ermöglicht, den gesamten Datenbestand der letzten maximal 24 Stunden wiederherzustellen.

22. Kommerzielle Aspekte Das verwendete Datenbanksystem muss ein COTS-Produkt oder öffentlich erhältlich (Open Source) sein.

Hinweise:

Die obigen Anforderungen sind mit einem dem Standard entsprechenden Datenbank-Managementsystem (DBMS) zu erfüllen.

Die Nutzung der verschiedenen Datenbanken ist in die einzelnen zuvor beschriebenen Arbeitsabläufe eingebettet. Der allgemeine Arbeitsablauf ist ein Anfrage-/Antwortmechanismus, bei dem ein Beteiligter über die gemeinsame Schnittstelle Informationen anfordert (4.2.12.1: Allgemeine Architektur und 4.2.12.6: 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 (keine Daten vorhanden oder Zugriff wird aufgrund der Zugangskontrolle abgelehnt).

4.2.12. Vernetzung und Kommunikation

4.2.12.1. Allgemeine Architektur

Mit diesem Teilsystem wird im Laufe der Zeit eine große und komplexe Gemeinschaft für die Interoperabilität im Bereich der Bahntelematik mit Hunderten von Akteuren (EVU, IB usw.) entstehen, die miteinander konkurrieren und/oder kooperieren, um die Erfordernisse des Marktes abzudecken.

Die Netz- und Kommunikationsinfrastruktur, auf die sich diese Gemeinschaft für die Interoperabilität im Bahnbereich stützt, wird auf einer gemeinsamen Architektur für den Informationsaustausch beruhen, die alle beteiligte Akteure kennen und akzeptieren.

Die vorgeschlagene Architektur zum Austausch der Informationen

— ist so ausgelegt, dass sie heterogene Informationsmodelle in Einklang bringt, indem sie die zwischen den Systemen ausgetauschten Daten semantisch 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 Architektur zum Informationsaustausch favorisiert eine gleichberechtigte (Peer-to-Peer) Interaktion zwischen allen Akteuren, und sie garantiert die Gesamtintegrität und -konsistenz der Interoperabilitätsgemeinschaft, indem sie eine Reihe zentralisierter Dienste bereitstellt.

Ein Peer-to-Peer-Interaktionsmodell ermöglicht die beste Kostenaufteilung zwischen den verschiedenen Akteuren, die sich an der tatsächlichen Nutzung orientiert, und verursacht zudem weniger Probleme bei der Skalierbarkeit. Eine grafische Darstellung der allgemeinen Architektur ist in dem in Anlage I genannten Dokument „TAF TSI — Anhang A.5: Abbildungen und Ablaufdiagramme der TAF-TSI-Meldungen“ Abschnitt 1.5 zu finden.

4.2.12.2. Vernetzung

Vernetzung bezeichnet in diesem Fall die Kommunikationsmethode und -philosophie und bezieht sich nicht auf das physische Netz.

Die Interoperabilität im Bahnbereich beruht auf einer gemeinsamen Architektur zum Austausch der Informationen, 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 etc.) gelöst, sondern durch Austausch und Verwaltung inhärent sicherer Meldungen. Ein VPN-Netzwerk ist daher nicht erforderlich (große VPN-Netze erfordern eine komplexe und kostspielige Verwaltung); so werden Probleme bei der Zuordnung von Zuständigkeiten und Besitzverhältnissen 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 hybrides Peer-to-Peer-Modell mit einer gemeinsamen Schnittstelle an den Knoten der einzelnen Akteure und einer zentralen Zertifizierungsbehörde einrichten.

Anschließend wird eine Peer-to-Peer-Kommunikation zwischen den beteiligten Akteuren aufgebaut.

Die Peer-to-Peer-Kommunikation beruht auf den technischen Standards für die gemeinsame Schnittstelle, die in dem in Anlage I genannten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“ beschrieben sind.

4.2.12.3. Sicherheit

Um ein hohes Sicherheitsniveau zu erreichen, müssen alle Meldungen eigenständig sein, d. h., ihre Inhalte müssen gesichert sein, und der Empfänger muss die Authentizität der Meldung nachprüfen können. Dies kann mit einem Verschlüsselungs- und Signatursystem wie bei der Verschlüsselung von E-Mails erreicht werden.

4.2.12.4. 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, da die gemeinsame Nutzung eines geheimen Schlüssels durch zahlreiche Akteure über kurz oder lang scheitern würde. Ein höheres Sicherheitsniveau lässt sich leichter erreichen, wenn jeder Akteur für sein eigenes Schlüsselpaar verantwortlich ist, auch wenn in diesem Fall der Zentralspeicher (als Schlüssel-Server) ein hohes Maß an Integrität aufweisen muss.

4.2.12.5. Zentralspeicher

Der zentrale Datenspeicher muss folgende Daten verarbeiten können:

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

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

— Zertifizierungsbehörde (CA).

Der Zentralspeicher sollte von einer nichtkommerziellen europäischen Stelle verwaltet werden. Wird der Zentralspeicher in Verbindung mit der TSI TAP [2] verwendet, so sind Entwicklung und Änderungen an die TSI TAP [2] anzulehnen, um optimale Synergien zu erzielen.

4.2.12.6. Gemeinsame Schnittstelle

Die Nutzung einer gemeinsamen Schnittstelle ist für jeden Akteur verbindlich, der an der Gemeinschaft für die Interoperabilität im Bahnbereich mitwirken möchte.

Eine gemeinsame Schnittstelle muss Folgendes verarbeiten 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 in der TSI geforderten Daten innerhalb jedes Fahrzeughalters, FEVU, EVU, IB usw., gleichgültig, ob die betreffenden Datenbanken zentral oder individuell sind (siehe auch Abschnitt 1.6 des in Anlage I genannten Dokuments „TAF TSI — Anhang A.5: Abbildungen und Ablaufdiagramme der TAF-TSI-Meldungen“).

Wird eine gemeinsame Schnittstelle in Verbindung mit der TSI TAP [2] verwendet, so sind Entwicklung und Änderungen an die TSI TAP [2] anzulehnen, um optimale Synergien zu erzielen. Anhand der Ergebnisse der Authentizitätsprüfung eingehender Meldungen kann ein Mindestumfang für Meldungsbestätigungen bestimmt werden:

i) positiv: ACK senden

ii) negativ: NACK senden.

Zur Erfüllung der oben beschriebenen Aufgaben verwendet die gemeinsame Schnittstelle die Informationen im Zentralspeicher.

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

4.3. Funktionelle und technische Spezifikationen für die Schnittstellen

Angesichts der in Kapitel 3 angegebenen grundlegenden Anforderungen unterliegen die Schnittstellen den folgenden funktionellen und technischen Spezifikationen:

4.3.1. Schnittstellen zur TSI „Infrastruktur“

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

Im Teilsystem „Telematikanwendungen für den Güterverkehr“ werden die für betriebliche Zwecke erforderlichen Daten verwendet, die im Trassenvertrag festgelegt sind und durch Daten über Infrastrukturbeschränkungen vervollständigt werden können; diese werden vom IB bereitgestellt. Es gibt somit keine direkte Schnittstelle zwischen dieser TSI und der TSI „Infrastruktur“.

4.3.2. Schnittstellen zur TSI „Zugsteuerung, Zugsicherung und Signalgebung“

Die beiden alleinigen Verbindungen zur Zugsteuerung/Zugsicherung und Signalgebung bestehen über

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

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

4.3.3. Schnittstellen zur TSI „Fahrzeuge“

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

Die TSI „Fahrzeuge“ spezifiziert die Merkmale eines Wagens. Wenn sich die Merkmale eines Wagens ändern, 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 zur TSI „Verkehrsbetrieb und Verkehrssteuerung“

Im Teilsystem „Verkehrsbetrieb und Verkehrssteuerung“ werden die Verfahren und zugehörige Ausrüstungen definiert, die eine kohärente Ausnutzung der verschiedenen strukturellen Teilsysteme erlauben, und zwar sowohl im normalen als auch im eingeschränkten Betrieb, einschließlich insbesondere der Zugführung sowie der Planung und Abwicklung des Verkehrsbetriebs.

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

Zur Gewährleistung der Kohärenz zwischen beiden TSI gilt folgendes Verfahren:

Wenn die Spezifikationen der TSI „Verkehrsbetrieb und Verkehrssteuerung“ im Zusammenhang mit Anforderungen dieser TSI erstellt und/oder geändert werden, dann muss die für diese TSI verantwortliche Stelle befragt werden.

Ebenso muss die für die TSI „Verkehrsbetrieb und Verkehrssteuerung“ verantwortliche Stelle befragt werden, falls die Spezifikationen der vorliegenden TSI in Bezug auf betriebliche Anforderungen in der TSI „Verkehrsbetrieb und Verkehrssteuerung“ geändert werden.

4.3.5. Schnittstellen zum Teilsystem „Telematikanwendungen für den Personenverkehr“ (TAP)

Schnittstelle Nummer in der TSI „Telematikanwendungen für den Güterverkehr“ Nummer in der TSI „Telematikanwendungen für den Personenverkehr“ Zug fertig 4.2.3.3 Zugfertigmeldung 4.2.14.1 Zugfertigmeldung für alle Züge Zuglaufprognose 4.2.4.2 Zuglaufprognosemeldung 4.2.15.2 Zuglaufprognosemeldung für alle Züge Zugfahrtmeldung 4.2.4.3 Zuglaufmeldung 4.2.15.1 Zuglaufmeldung für alle Züge „Fahrtunterbrechung“ an das Eisenbahnunternehmen 4.2.5.2 Zuglaufunterbrechung 4.2.16.2 Zuglaufunterbrechungsmeldung für alle Züge Verarbeitung kurzfristiger Fahrplandaten 4.2.2 Trassenantrag 4.2.17 Verarbeitung kurzfristiger Fahrplandaten Gemeinsame Schnittstelle 4.2.12.6 Gemeinsame Schnittstelle 4.2.21.7 Gemeinsame Kommunikationsschnittstelle zwischen Eisenbahnunternehmen und IB Zentralspeicher 4.2.12.5 Zentralspeicher 4.2.21.6 Zentralspeicher Referenzdateien 4.2.11.1 Referenzdateien 4.2.19.1 Referenzdateien

4.4. Betriebsvorschriften

Angesichts der in Kapitel 3 angegebenen grundlegenden Anforderungen gelten für das von dieser TSI erfasste Teilsystem folgende Betriebsvorschriften:

4.4.1. Datenqualität

Zur Sicherstellung der Datenqualität ist der Sender jeder TSI-Meldung verantwortlich für die Richtigkeit des Dateninhalts der Meldung zum Zeitpunkt ihres Versands. Soweit Quelldaten aus Datenbanken im Rahmen der vorliegenden TSI zur Datenqualitätssicherung verfügbar sind, müssen die Daten dieser Datenbanken zur Sicherstellung der Datenqualität verwendet werden.

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

Die Datenqualitätssicherung beinhaltet den Vergleich mit Daten aus Datenbanken dieser TSI sowie gegebenenfalls 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 (zugänglich, genau, zeitgerecht, vollständig, übereinstimmend mit anderen Quellen usw.) sind und

— die gewünschten Eigenschaften (relevant, umfassend, ausreichend detailliert, leicht zu lesen, leicht zu verstehen usw.) besitzen.

Die wesentlichen Merkmale der Datenqualität sind:

— Genauigkeit,

— Vollständigkeit,

— Kohärenz,

— Aktualität.

Genauigkeit:

Die zu verarbeitenden Informationen (Daten) müssen möglichst ökonomisch erfasst werden. Das ist nur dann möglich, wenn die Primärdaten für den gesamten Transport nach Möglichkeit nur ein einziges Mal erfasst werden. Daher sollten die Primärdaten so nahe wie möglich an ihrer Quelle eingegeben werden, sodass sie anschließend in spätere Bearbeitungsgänge voll integriert werden können.

Vollständigkeit:

Vor dem Versand von Meldungen muss ihre Vollständigkeit und Syntax anhand der Metadaten geprüft werden. Dadurch wird auch ein unnötiger Datenverkehr im Netz vermieden.

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

Kohärenz:

Zur Gewährleistung der Kohärenz müssen Geschäftsregeln (Business Rules) umgesetzt werden. Doppeleingaben sind zu vermeiden, und der Eigentümer der Daten sollte klar feststellbar sein.

Die Art der Umsetzung 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) umgesetzt werden, die die Kohärenz 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.

Aktualität:

Die rechtzeitige Bereitstellung von Informationen ist ein wichtiger Punkt. Soweit der Anstoß zur Datenspeicherung oder zum 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 ausgelegt 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 tatsächlich den Inhalt haben, wenn sie automatisch vom System versandt werden.

Datenqualitätsmetrik

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

Für die Aktualität der Daten (Prozent der Daten, die innerhalb eines spezifizierten Schwellen-Zeitrahmens verfügbar sein müssen) muss ein Prozentsatz von 98 % erreicht werden. Soweit 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 mit den tatsächlichen 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 Zentralspeichers

Die Funktionen des Zentralspeichers sind in Abschnitt 4.2.12.5 (Zentralspeicher) festgelegt. Zur Gewährleistung der Datenqualität ist der Betreiber des Zentralspeichers für die Aktualisierung und die Qualität der Metadaten sowie für die Verwaltung der öffentlichen Zugriffsrechte verantwortlich. Die Qualität der Metadaten bezüglich Vollständigkeit, Kohärenz, Aktualität und Genauigkeit muss einen reibungslosen Ablauf im Sinne dieser TSI ermöglichen.

4.5. Instandhaltungsvorschriften

Angesichts der in Kapitel 3 angegebenen grundlegenden Anforderungen gelten folgende Instandhaltungsvorschriften für das von dieser TSI erfasste Teilsystem:

Die Qualität des Güterverkehrs muss auch dann gewährleistet sein, wenn die Datenverarbeitungsanlagen ganz oder teilweise ausfallen. Es empfiehlt sich daher, Duplexsysteme oder Rechner mit besonders hoher Zuverlässigkeit zu installieren, und deren unterbrechungsfreien Betrieb während Instandhaltungsarbeiten sicherzustellen.

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

4.6. Berufliche Qualifikationen

Für die beruflichen Qualifikationen, die für den Betrieb und die Instandhaltung des Teilsystems sowie für die Umsetzung der TSI erforderlich sind, gilt Folgendes:

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

Ist eine zusätzliche 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 im Klaren sein, dass sie bei ihrer Arbeit ein hohes Niveau aufrechterhalten müssen, da sich dies entscheidend auf die Zuverlässigkeit der in den nachfolgenden Schritten zu verarbeitenden Informationen auswirkt.

Die für die Zugbildung und den Betrieb der Züge erforderlichen beruflichen Qualifikationen sind in der TSI „Verkehrsbetrieb und Verkehrssteuerung“ festgelegt.

4.7. Bedingungen für den Gesundheitsschutz und die Sicherheit am Arbeitsplatz

Für die Anforderungen an Sicherheit und Gesundheitsschutz am Arbeitsplatz während des Betriebs und der Instandhaltun