This document is an excerpt from the EUR-Lex website
Document 32014R1305
Commission Regulation (EU) No 1305/2014 of 11 December 2014 on the technical specification for interoperability relating to the telematics applications for freight subsystem of the rail system in the European Union and repealing the Regulation (EC) No 62/2006 Text with EEA relevance
Verordnung (EU) Nr. 1305/2014 der Kommission vom 11. Dezember 2014 über die technische Spezifikation für die Interoperabilität zum Teilsystem „Telematikanwendungen für den Güterverkehr“ des Eisenbahnsystems in der Europäischen Union und zur Aufhebung der Verordnung (EG) Nr. 62/2006 der Kommission Text von Bedeutung für den EWR
Verordnung (EU) Nr. 1305/2014 der Kommission vom 11. Dezember 2014 über die technische Spezifikation für die Interoperabilität zum Teilsystem „Telematikanwendungen für den Güterverkehr“ des Eisenbahnsystems in der Europäischen Union und zur Aufhebung der Verordnung (EG) Nr. 62/2006 der Kommission Text von Bedeutung für den EWR
ABl. L 356 vom 12.12.2014, p. 438–488
(BG, ES, CS, DA, DE, ET, EL, EN, FR, HR, IT, LV, LT, HU, MT, NL, PL, PT, RO, SK, SL, FI, SV)
In force: This act has been changed. Current consolidated version: 18/04/2021
12.12.2014 |
DE |
Amtsblatt der Europäischen Union |
L 356/438 |
VERORDNUNG (EU) Nr. 1305/2014 DER KOMMISSION
vom 11. Dezember 2014
über die technische Spezifikation für die Interoperabilität zum Teilsystem „Telematikanwendungen für den Güterverkehr“ des Eisenbahnsystems in der Europäischen Union und zur Aufhebung der Verordnung (EG) Nr. 62/2006 der Kommission
(Text von Bedeutung für den EWR)
DIE EUROPÄISCHE KOMMISSION —
gestützt auf den Vertrag über die Arbeitsweise der Europäischen Union,
gestützt auf die Richtlinie 2008/57/EG des Europäischen Parlaments und des Rates vom 17. Juni 2008 über die Interoperabilität des Eisenbahnsystems in der Gemeinschaft (1), insbesondere auf Artikel 6 Absatz 1,
in Erwägung nachstehender Gründe:
(1) |
Gemäß Artikel 2 Buchstabe e der Richtlinie 2008/57/EG ist das Eisenbahnsystem in Teilsysteme struktureller und funktioneller Art unterteilt. Für jedes Teilsystem sollte eine technische Spezifikation für die Interoperabilität (TSI) erstellt werden. |
(2) |
In der Verordnung (EG) Nr. 62/2006 der Kommission (2) ist die technische Spezifikation für die Interoperabilität zum Teilsystem „Telematikanwendungen für den Güterverkehr“ des transeuropäischen Eisenbahnsystems festgelegt. |
(3) |
Die Europäische Eisenbahnagentur (die „Agentur“) wurde im Jahr 2010 beauftragt, die technische Spezifikation für die Interoperabilität (TSI) zum Teilsystem „Telematikanwendungen für den Güterverkehr“ (TAF) gemäß Artikel 6 Absatz 1 der Richtlinie 2008/57/EG zu überarbeiten. |
(4) |
Am 10. Dezember 2013 gab die Agentur die Empfehlung ERA/REC/106 — 2013/REC zur Aktualisierung des Anhangs A der Verordnung (EG) Nr. 62/2006 ab. |
(5) |
Die TSI TAF sollte keine Verpflichtung zur Anwendung bestimmter Technologien oder technischer Lösungen enthalten, soweit dies für die Interoperabilität des europäischen Eisenbahnsystems nicht erforderlich ist. |
(6) |
Die Fachverbände des Eisenbahnsektors haben den Gesamtplan für die Umsetzung der TSI TAF festgelegt. In diesem Gesamtplan sind die Schritte angegeben, die erforderlich sind, um von einem fragmentierten nationalen Ansatz zu einem nahtlosen Informationsaustausch im gesamten europäischen Eisenbahnsystem zu gelangen. |
(7) |
Die TSI TAF beruht auf aktuellem Expertenwissen. Technische und betriebliche Entwicklungen könnten jedoch weitere Änderungen an der TSI TAF erforderlich machen. Daher sollte ein Änderungsmanagementverfahren entwickelt werden, mit dem die Anforderungen der TSI TAF konsolidiert und aktualisiert werden können. |
(8) |
Alle Marktteilnehmer, insbesondere kleine Güterverkehrsunternehmen, die nicht in den auf europäischer Ebene tätigen Fachverbänden des Eisenbahnsektors vertreten sind, sollten über ihre Verpflichtungen im Zusammenhang mit der TSI TAF unterrichtet werden. |
(9) |
Die Verordnung (EG) Nr. 62/2006 sollte daher aufgehoben werden. |
(10) |
Die in dieser Verordnung vorgesehenen Maßnahmen entsprechen der Stellungnahme des nach Artikel 29 Absatz 1 der Richtlinie 2008/57/EG eingesetzten Ausschusses — |
HAT FOLGENDE VERORDNUNG ERLASSEN:
Artikel 1
Gegenstand
Die im Anhang dargelegte technische Spezifikation für die Interoperabilität (TSI) zum Teilsystem „Telematikanwendungen für den Güterverkehr“ des europäischen Eisenbahnsystems wird angenommen.
Artikel 2
Geltungsbereich
(1) Diese TSI gilt für das Teilsystem „Telematikanwendungen“ des Eisenbahnsystems in der Europäischen Union gemäß Anhang II Nummer 2.6 Buchstabe b der Richtlinie 2008/57/EG.
(2) Die TSI gilt für folgende Netze:
a) |
das konventionelle transeuropäische Eisenbahnnetz gemäß Anhang I Nummer 1.1 der Richtlinie 2008/57/EG; |
b) |
das transeuropäische Hochgeschwindigkeitsbahnnetz gemäß Anhang I Nummer 2.1 der Richtlinie 2008/57/EG; |
c) |
sonstige Teile des Netzes des Eisenbahnsystems in der Europäischen Union. |
Die TSI gilt nicht für die in Artikel 1 Absatz 3 der Richtlinie 2008/57/EG genannten Fälle.
(3) Die TSI gilt für Netze mit den folgenden Regelspurweiten: 1 435 mm, 1 520 mm, 1 524 mm, 1 600 mm und 1 668 mm.
Artikel 3
Aktualisierung und Berichterstattung über technische Unterlagen
Die Agentur stellt die Standortcodes und Unternehmenscodes gemäß Abschnitt 4.2.11.1 (Buchstaben b und d) sowie die in Abschnitt 7.2 des Anhangs genannten technischen Dokumente auf ihrer Website zur Verfügung und berichtet der Kommission über die Fortschritte bei deren Erstellung.
Die Kommission informiert die Mitgliedstaaten über diese Fortschritte durch den nach Artikel 29 Absatz 1 der Richtlinie 2008/57/EG eingesetzten Ausschuss.
Artikel 4
Erfüllung der Anforderungen durch Netze außerhalb der EU
Bei Schienengüterverkehrsdiensten von oder nach Drittländern setzt die Erfüllung der Anforderungen der im Anhang dargelegten TSI die Informationsbereitstellung durch Akteure außerhalb der Europäischen Union voraus, sofern bilaterale Abkommen keinen Informationsaustausch im Einklang mit dieser TSI vorsehen.
Artikel 5
Durchführung
(1) Die Agentur bewertet und beaufsichtigt die Durchführung dieser Verordnung, um zu bestimmen, ob die vereinbarten Ziele und Fristen eingehalten wurden, und legt dem in Abschnitt 7.1.4 des Anhangs genannten TAF-Lenkungsausschuss einen Bewertungsbericht vor.
(2) Der TAF-Lenkungsausschuss bewertet die Durchführung dieser Verordnung auf der Grundlage des von der Agentur vorgelegten Bewertungsberichts und trifft entsprechende Entscheidungen über weitere Maßnahmen des Sektors.
(3) Die Mitgliedstaaten sorgen dafür, dass alle in ihrem Hoheitsgebiet registrierten Eisenbahnunternehmen, Infrastrukturbetreiber und Wagenhalter über diese Verordnung unterrichtet werden, und benennen gemäß Anlage III eine nationale Anlaufstelle für die Überwachung der Durchführung der Verordnung.
(4) Die Mitgliedstaaten legen der Kommission bis zum 31. Dezember 2018 einen Bericht über die Durchführung dieser Verordnung vor. Dieser Bericht wird in dem nach Artikel 29 Absatz 1 der Richtlinie 2008/57/EG eingesetzten Ausschuss erörtert. Soweit erforderlich, wird die im Anhang dieser Verordnung dargelegte TSI angepasst.
Artikel 6
Aufhebung
Die Verordnung (EG) Nr. 62/2006 wird mit Inkrafttreten der vorliegenden Verordnung aufgehoben.
Artikel 7
Inkrafttreten und Anwendung
Diese Verordnung tritt am zwanzigsten Tag nach ihrer Veröffentlichung im Amtsblatt der Europäischen Union in Kraft.
Sie gilt ab dem 1. Januar 2015.
Diese Verordnung ist in allen ihren Teilen verbindlich und gilt unmittelbar in jedem Mitgliedstaat.
Brüssel, den 11. Dezember 2014
Für die Kommission
Der Präsident
Jean-Claude JUNCKER
(1) ABl. L 191 vom 18.7.2008, S. 1.
(2) Verordnung (EG) Nr. 62/2006 der Kommission vom 23. Dezember 2005 über die technische Spezifikation für die Interoperabilität (TSI) zum Teilsystem Telematikanwendungen für den Güterverkehr des konventionellen transeuropäischen Eisenbahnsystems (ABl. L 13 vom 18.1.2006, S. 1).
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
Ref. Nr. |
Referenz |
Titel |
Letzte Fassung |
[1] |
Richtlinie 2008/57/EG |
Richtlinie 2008/57/EG des Europäischen Parlaments und des Rates vom 17. Juni 2008 über die Interoperabilität des Eisenbahnsystems in der Gemeinschaft (Neufassung) (ABl. L 191 vom 18.7.2008, S. 1) |
17.6.2008 |
[2] |
Verordnung (EU) Nr. 454/2011 „TSI TAP“ |
Verordnung (EU) Nr. 454/2011 der Kommission vom 5. Mai 2011 über die Technische Spezifikation für die Interoperabilität (TSI) zum Teilsystem „Telematikanwendungen für den Personenverkehr“ des transeuropäischen Eisenbahnsystems (ABl. L 123 vom 12.5.2011, S. 11) |
5.5.2011 |
[3] |
Richtlinie 2012/34/EU |
Richtlinie 2012/34/EU des Europäischen Parlaments und des Rates vom 21. November 2012 zur Schaffung eines einheitlichen europäischen Eisenbahnraums (ABl. L 343 vom 14.12.2012, S. 32) |
21.11.2012 |
[4] |
ERA-TD-105 |
TSI TAF — ANHANG D.2: ANLAGE F — MODELL FÜR TAF TSI-DATEN UND -MELDUNGEN |
22.3.2013 |
[5] |
Verordnung (EG) Nr. 62/2006 „TSI TAF“ |
Verordnung (EG) Nr. 62/2006 der Kommission vom 23. Dezember 2005 über die technische Spezifikation für die Interoperabilität (TSI) zum Teilsystem „Telematikanwendungen für den Güterverkehr“ des konventionellen transeuropäischen Eisenbahnsystems (ABl. L 13 vom 18.1.2006, S. 1) |
18.1.2006 |
[6] |
Verordnung (EU) Nr. 280/2013 der Kommission |
Verordnung (EU) Nr. 280/2013 der Kommission vom 22. März 2013 zur Änderung der Verordnung (EG) Nr. 62/2006 über die technische Spezifikation für die Interoperabilität (TSI) zum Teilsystem „Telematikanwendungen für den Güterverkehr“ des konventionellen transeuropäischen Eisenbahnsystems (ABl. L 84 vom 23.3.2013, S. 17) |
22.3.2013 |
[7] |
Verordnung (EU) Nr. 328/2012 der Kommission |
Verordnung (EU) Nr. 328/2012 der Kommission vom 17. April 2012 zur Änderung der Verordnung (EG) Nr. 62/2006 über die technische Spezifikation für die Interoperabilität (TSI) zum Teilsystem „Telematikanwendungen für den Güterverkehr“ des konventionellen transeuropäischen Eisenbahnsystems (ABl. L 106 vom 18.4.2012, S. 14) |
17.4.2012 |
[8] |
K(2010) 2576 endgültig |
Beschluss der Kommission vom 29. April 2010 über ein Mandat an die Europäische Eisenbahnagentur zur Ausarbeitung und Überprüfung technischer Spezifikationen für die Interoperabilität im Hinblick auf die Ausweitung ihres Geltungsbereichs auf das gesamte Eisenbahnsystem in der Europäischen Union |
29.4.2010 |
[9] |
Richtlinie 2004/49/EG |
Richtlinie 2004/49/EG des Europäischen Parlaments und des Rates vom 29. April 2004 über Eisenbahnsicherheit in der Gemeinschaft und zur Änderung der Richtlinie 95/18/EG des Rates über die Erteilung von Genehmigungen an Eisenbahnunternehmen und der Richtlinie 2001/14/EG über die Zuweisung von Fahrwegkapazität der Eisenbahn, die Erhebung von Entgelten für die Nutzung von Eisenbahninfrastruktur und die Sicherheitsbescheinigung (Richtlinie über die Eisenbahnsicherheit) (ABl. L 164 vom 30.4.2004, S. 44) |
28.11.2009 |
[10] |
Richtlinie 2001/13/EG |
Richtlinie 2001/13/EG des Europäischen Parlaments und des Rates vom 26. Februar 2001 zur Änderung der Richtlinie 95/18/EG des Rates über die Erteilung von Genehmigungen an Eisenbahnunternehmen (ABl. L 75 vom 15.3.2001, S. 26) |
26.2.2001 |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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 |
|
|
||||
Zuglaufprognose |
|
|
||||
Zugfahrtmeldung |
|
|
||||
„Fahrtunterbrechung“ an das Eisenbahnunternehmen |
|
|
||||
Verarbeitung kurzfristiger Fahrplandaten |
|
|
||||
Gemeinsame Schnittstelle |
|
|
||||
Zentralspeicher |
|
|
||||
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 Instandhaltung des betreffenden Teilsystems (bzw. bezüglich des technischen Anwendungsbereichs nach Abschnitt 1.1) sowie bei der Umsetzung der TSI gilt Folgendes:
Es bestehen keine über die existierenden nationalen und europäischen Regeln hinausgehenden Anforderungen bezüglich Gesundheitsschutz und Sicherheit am Arbeitsplatz.
5. INTEROPERABILITÄTSKOMPONENTEN
5.1. Begriffsbestimmung
Nach Artikel 2 Buchstabe f der Richtlinie 2008/57/EG [1] gilt:
Interoperabilitätskomponenten sind „Bauteile, Bauteilgruppen, Unterbaugruppen oder komplette Materialbaugruppen, die in ein Teilsystem eingebaut sind oder eingebaut werden sollen und von denen die Interoperabilität des Eisenbahnsystems direkt oder indirekt abhängt. Unter ‚Komponenten‘ sind materielle, aber auch immaterielle Produkte wie Software zu verstehen.“
5.2. Liste der Komponenten
Die Interoperabilitätskomponenten sind von den entsprechenden Bestimmungen in der Richtlinie 2008/57/EG [1] abgedeckt.
Für das Teilsystem „Telematikanwendungen für den Güterverkehr“ sind keine spezifischen Interoperabilitätskomponenten definiert.
Zur Erfüllung der Anforderungen dieser TSI wird nur herkömmliche IT-Ausrüstung benötigt, die keine spezifischen Aspekte für die Interoperabilität in der Eisenbahnumgebung aufweist. Dies gilt für Hardware-Komponenten und für die eingesetzte Standardsoftware wie Betriebssysteme und Datenbanken. Die Anwendungssoftware ist auf der Benutzerseite jeweils individuell und kann je nach Funktionalität und Bedarf angepasst und verbessert werden. Bei der vorgeschlagenen „Anwendungsintegrationsarchitektur“ wird davon ausgegangen, dass die Anwendungen unter Umständen nicht dasselbe interne Informationsmodell benutzen. Anwendungsintegration ist definiert als ein Prozess, der dazu dient, eine Zusammenarbeit zwischen unabhängig voneinander konstruierten Anwendungssystemen zu erreichen.
5.3. Komponentenleistung und Spezifikationen
Siehe Kapitel 5.2; für die TSI „Telematikanwendungen für den Güterverkehr“ nicht relevant.
6. KONFORMITÄTS- UND/ODER GEBRAUCHSTAUGLICHKEITSBEWERTUNG DER KOMPONENTEN UND ÜBERPRÜFUNG DES TEILSYSTEMS
6.1. Interoperabilitätskomponenten
6.1.1. Bewertungsverfahren
Im Falle der Interoperabilitätskomponenten muss das Bewertungsverfahren für die Konformität bzw. die Gebrauchstauglichkeit auf europäischen Spezifikationen oder auf Spezifikationen beruhen, die entsprechend der Richtlinie 2008/57/EG [1] anerkannt sind.
Hinsichtlich der Ermittlung der Gebrauchstauglichkeit geben diese Spezifikationen alle Kennwerte an, die zu messen, zu kontrollieren oder zu beobachten sind, ferner die dazugehörigen Versuchsmethoden und Messverfahren, sowohl bei Versuchen im Labor als auch auf der Strecke.
Verfahren für die Bewertung der Konformität und/oder der Gebrauchstauglichkeit:
Liste der Spezifikationen, Beschreibung der Versuchsmethoden:
Für die TSI „Telematikanwendungen für den Güterverkehr“ nicht relevant.
6.1.2. Modul
Auf Verlangen des Herstellers oder seines in der Union ansässigen Bevollmächtigten hat das Bewertungsverfahren durch eine benannte Stelle entsprechend den Bestimmungen über die maßgebenden Module gemäß dem Beschluss 2010/713/EU der Kommission zu erfolgen, die in der Anlage dieser TSI in modifizierter und ergänzter Form wiedergegeben sind.
Die Module werden je nach Komponente selektiv miteinander verbunden und benutzt.
Für die TSI „Telematikanwendungen für den Güterverkehr“ nicht relevant.
6.1.3. Teilsystem „Telematikanwendungen für den Güterverkehr“
Auf Verlangen des öffentlichen Auftraggebers oder seines in der Union ansässigen Bevollmächtigten führt die benannte Stelle entsprechend Anhang VI der Richtlinie 2008/57/EG [1] die EG-Prüfung durch.
Gemäß Anhang II der Richtlinie 2008/57/EG [1] sind die Teilsysteme in strukturelle und funktionelle Bereiche untergliedert.
Für die TSI des strukturellen Bereichs ist die Konformitätsbewertung verbindlich vorgeschrieben. Das Teilsystem „Telematikanwendungen für den Güterverkehr“ gehört zum funktionellen Bereich, weshalb in dieser TSI keine Module zur Konformitätsbewertung vorgesehen sind.
Jedoch bilden der Zentralspeicher und eine gemeinsame Schnittstelle zu den Knoten der jeweiligen Akteure das Rückgrat der Anwendungsintegration. Das Modell für den Informationsaustausch ist im zentralen Anwendungsintegrationsspeicher hinterlegt, der die Schnittstellen-Metadaten an einem einzigen physischen Ort enthält. Die Metadaten enthalten Informationen über den Kommunikationsinhalt (Inhalt der gesendeten Daten), die Kennungen der Absender und Empfänger sowie die Mechanik des Interaktionsprozesses der Geschäftsprotokolle auf Anwendungsebene.
Folgende Punkte sind von besonderer Bedeutung:
— |
Der Zentralspeicher enthält auch die Zertifizierungsbehörde (Open CA PKI). Dabei handelt es sich um einen administrativen Vorgang, der physisch implementiert ist. Falsche Einträge fallen sofort auf. Es ist kein Bewertungsverfahren erforderlich. |
— |
Der Zentralspeicher enthält die Metadaten zu den Meldungen (gemäß dem in Anlage I aufgeführten Dokument „TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen“) als Basis für den Meldungsaustausch in einer heterogenen Informationsumgebung. Die Metadaten müssen im Zentralspeicher verwaltet und aktualisiert werden. Eine Inkompatibilität in der Meldungsstruktur oder im Inhalt der Meldungen zum Senden und Empfangen der Daten wird sofort erkannt, und die Übertragung wird verweigert. Es ist kein Bewertungsverfahren erforderlich. |
— |
Die gemeinsame Schnittstelle zu den Netzknoten der jeweiligen Akteure enthält jeweils eine lokale „Spiegelung“ des Zentralspeichers zur Verkürzung der Antwortzeiten und Entlastung des Zentralspeichers. Es muss sichergestellt sein, dass die Datenversionen im Zentralspeicher und der gemeinsamen Schnittstelle immer identisch sind. Daher müssen die Daten im Zentralspeicher aktualisiert und neue Versionen von dort heruntergeladen werden. Es ist kein Bewertungsverfahren erforderlich. |
7. UMSETZUNG
7.1. Modalitäten der Anwendung dieser TSI
7.1.1. Einleitung
Diese TSI (im Folgenden „TSI TAF“) betrifft das Teilsystem „Telematikanwendungen für den Güterverkehr“. Nach Anhang II der Richtlinie 2008/57/EG [1] handelt es sich dabei um ein funktionelles Teilsystem. Die Anwendung dieser TSI ist somit vom Konzept neuer/erneuerter oder umgerüsteter Teilsysteme, wie es in den TSI für strukturelle Teilsysteme üblich ist, unabhängig, sofern in der TSI nichts anderes angegeben ist.
Die TSI wird stufenweise umgesetzt:
— |
Phase 1: detaillierte IT-Spezifikationen und Gesamtplan; |
— |
Phase 2: Entwicklung; |
— |
Phase 3: Einführung. |
7.1.2. Phase 1 — detaillierte IT-Spezifikationen und Gesamtplan
Die Spezifikationen für funktionelle Anforderungen, die der oben genannten technischen Architektur bei Entwicklung und Einführung des Computersystems zugrunde gelegt werden, sind in den in Anlage I genannten Anlagen A bis F aufgeführt.
Der obligatorische Gesamtplan vom Konzept bis zur Lieferung des Computersystems, der sich auf den vom Eisenbahnsektor ausgearbeiteten Europäischen Strategischen Umsetzungsplan (ESUP) stützt, umfasst die wichtigsten Bestandteile der Systemarchitektur und die wichtigsten durchzuführenden Arbeitsschritte.
7.1.3. Phasen 2 und 3 — Entwicklung und Einführung
Eisenbahnunternehmen, IB und Wagenhalter entwickeln und führen gemäß den Bestimmungen dieses Kapitels das TAF-Computersystem ein.
7.1.4. Gesamtkoordinierung (Governance), Aufgaben und Zuständigkeiten
Entwicklung und Einführung erfolgen im Rahmen einer Gesamtkoordinierung mit den nachfolgend genannten Akteuren.
Lenkungsausschuss
Aufgaben und Zuständigkeiten des Lenkungsausschusses:
Der Lenkungsausschuss stellt die für eine effiziente Verwaltung und Koordinierung der Arbeiten zur Umsetzung der TSI TAF notwendige strategische Verwaltungsstruktur bereit. Hierunter fallen die Ausarbeitung der Gesamtstrategie, die strategische Ausrichtung und die Prioritätensetzung. Dabei berücksichtigt der Lenkungsausschuss auch die Interessen von kleinen Unternehmen, neuen Marktteilnehmern und Eisenbahnunternehmen, die besondere Dienste anbieten.
Der Lenkungsausschuss überwacht den Stand der Umsetzung. Er berichtet der Europäischen Kommission regelmäßig, mindestens jedoch viermal pro Jahr, über die Fortschritte im Vergleich zum Gesamtplan. Der Lenkungsausschuss leitet die erforderlichen Schritte ein, um die oben genannte Entwicklung im Fall einer Abweichung vom Gesamtplan anzupassen.
1. |
Der Lenkungsausschuss umfasst Vertreter
|
2. |
Den gemeinsamen Vorsitz im Lenkungsausschuss führen a) die Kommission und b) eine von den Fachverbänden des Eisenbahnsektors benannte Person. Mit Unterstützung der Mitglieder des Lenkungsausschusses erstellt die Kommission den Entwurf einer Geschäftsordnung, dem der Lenkungsausschuss zustimmen muss. |
3. |
Auf Vorschlag der Mitglieder des Lenkungsausschusses können weitere Organisationen als Beobachter hinzugezogen werden, wenn dies aus technischen und organisatorischen Gründen gerechtfertigt ist. |
Beteiligte
Eisenbahnunternehmen, IB und Wagenhalter richten eine effiziente Struktur für die Gesamtkoordinierung (Governance) des Projekts ein, die eine effiziente Entwicklung und Einführung des TAF-Systems ermöglicht.
Aufgaben der oben genannten Beteiligten:
— |
Durchführung der erforderlichen Schritte und Bereitstellung der erforderlichen Ressourcen zur Durchführung dieser Verordnung, |
— |
Einhaltung der Grundsätze für den Zugang zu den gemeinsamen Komponenten der TSI TAF, der allen Marktteilnehmern zu einheitlichen, transparenten und möglichst geringen Kosten für die Bereitstellung der Dienste offensteht, |
— |
Gewährleistung, dass alle Marktteilnehmer Zugriff auf alle ausgetauschten Daten haben, die sie zur Erfüllung ihrer rechtlichen Verpflichtungen und zur Ausführung der ihnen obliegenden Aufgaben gemäß den funktionellen Anforderungen der TSI TAF benötigen, |
— |
Wahrung der Vertraulichkeit in Bezug auf Kundenbeziehungen, |
— |
Einrichtung eines Mechanismus, der es „Nachzüglern“ ermöglicht, sich den TAF-Entwicklungen anzuschließen und auf eine Weise Nutzen aus diesen Entwicklungen bei den gemeinsamen Komponenten zu ziehen, die sowohl für die genannten Beteiligten als auch für die „Nachzügler“ zufriedenstellend ist, insbesondere im Hinblick auf eine ausgewogene gemeinsame Kostenübernahme, |
— |
Berichterstattung an den TAF-Lenkungsausschuss über den Stand der Dinge im Vergleich zu den Umsetzungsplänen. Bei dieser Berichterstattung ist gegebenenfalls auch auf Abweichungen gegenüber dem Gesamtplan einzugehen. |
Fachverbände
Aufgaben und Zuständigkeiten der auf europäischer Ebene tätigen Fachverbände des Eisenbahnsektors im Sinne des Artikels 3 Absatz 2 der Verordnung (EG) Nr. 881/2004:
— |
Vertretung der einzelnen Mitglieder im TSI-TAF-Lenkungsausschuss, |
— |
Sensibilisierung ihrer Mitglieder für die Verpflichtungen im Zusammenhang mit der Durchführung der vorliegenden Verordnung, |
— |
zeitnahe Gewährleistung eines laufenden und vollständigen Zugriffs aller oben genannten Beteiligten auf Informationen über den Stand der Arbeit des Lenkungsausschusses und etwaiger anderer Gruppen, um die Wahrung der Interessen der Vertreter bei der Umsetzung der TSI TAF sicherzustellen, |
— |
Gewährleistung eines effizienten Informationsflusses zwischen den einzelnen Mitgliedern und dem TAF-Lenkungsausschuss, damit die Interessen der Beteiligten bei Entscheidungen über die Entwicklung und Einführung des TAF gebührend berücksichtigt werden, |
— |
Gewährleistung eines effizienten Informationsflusses zwischen dem TAF-Lenkungsausschuss und den einzelnen Mitgliedern, damit die Beteiligten gebührend von den Entscheidungen über die Entwicklung und Einführung des TAF unterrichtet werden. |
7.2. Änderungsmanagement
7.2.1. Änderungsmanagementverfahren
Änderungsmanagementverfahren sind so zu konzipieren, dass Kosten und Nutzen der Änderung sorgfältig analysiert und Änderungen kontrolliert umgesetzt werden. Diese Verfahren werden von der Europäischen Eisenbahnagentur festgelegt, eingeführt, unterstützt und verwaltet und beinhalten Folgendes:
— |
Bestimmung der technischen Sachzwänge, die bei der Änderung zu berücksichtigen sind, |
— |
Angaben darüber, wer für die Verfahren zur Umsetzung der Änderungen verantwortlich ist, |
— |
das Validierungsverfahren für die umzusetzenden Änderungen, |
— |
die in Bezug auf Änderungsmanagement, Freigabe, Migration und Einführung zu verfolgende Strategie, |
— |
die Zuständigkeitsverteilung für das Management der detaillierten Spezifikationen sowie für die Qualitätssicherung und das Konfigurationsmanagement. |
Dem Änderungsmanagementausschuss gehören Vertreter der Europäischen Eisenbahnagentur, der Fachverbände des Eisenbahnsektors und der nationalen Sicherheitsbehörden an. Die Einbeziehung der Beteiligten in dieser Form soll sicherstellen, dass die durchzuführenden Änderungen perspektivisch betrachtet und ihre Auswirkungen umfassend bewertet werden. Die Kommission kann den Änderungsmanagementausschuss bei Bedarf erweitern. Der Änderungsmanagementausschuss wird letztlich bei der Europäischen Eisenbahnagentur angesiedelt sein.
7.2.2. Spezifisches Änderungsmanagementverfahren für die in Anlage I dieser Verordnung aufgeführten Dokumente
Das Änderungsmanagement für die in Anlage I dieser Verordnung aufgeführten Dokumente wird von der Europäischen Eisenbahnagentur (ERA) anhand folgender Kriterien festgelegt:
1. |
Die Änderungsanträge für die Dokumente werden entweder über die nationalen Sicherheitsbehörden (NSA), die auf europäischer Ebene tätigen Fachverbände des Eisenbahnsektors im Sinne des Artikels 3 Absatz 2 der Verordnung (EG) Nr. 881/2004 oder über den TSI-TAF-Lenkungsausschuss eingereicht. Die Kommission kann den Kreis der Antragsteller bei Bedarf erweitern. |
2. |
Die Änderungsanträge werden von der Europäischen Eisenbahnagentur gesammelt und gespeichert. |
3. |
Die Europäische Eisenbahnagentur legt die Änderungsanträge der zuständigen ERA-Arbeitsgruppe vor, die sie beurteilt und gegebenenfalls einen mit einer wirtschaftlichen Bewertung versehenen Vorschlag ausarbeitet. |
4. |
Anschließend legt die Europäische Eisenbahnagentur den Änderungsantrag und den damit verbundenen Vorschlag dem Änderungsmanagementausschuss vor, der den Antrag validiert oder ablehnt bzw. die Behandlung des Änderungsantrags vertagt. |
5. |
Bei Nichtvalidierung teilt die Europäische Eisenbahnagentur dem Antragsteller die Gründe für die Ablehnung mit oder bittet ihn um zusätzliche Angaben zum Entwurf der beantragten Änderung. |
6. |
Der validierte Änderungsantrag dient als Grundlage für die Änderung des betreffenden Dokuments. |
7. |
Die Europäische Eisenbahnagentur übermittelt der Kommission eine Empfehlung hinsichtlich der Aktualisierung der in Anlage I aufgeführten Dokumente sowie den Entwurf einer neuen Fassung des Dokuments, die Änderungsanträge und die wirtschaftliche Bewertung. |
8. |
Die im Entwurf vorgelegte neue Fassung des Dokuments und die validierten Änderungsanträge werden von der Europäischen Eisenbahnagentur auf ihrer Website veröffentlicht. |
9. |
Nach der Veröffentlichung der Aktualisierung der Dokumente in Anlage I im Amtsblatt der Europäischen Union veröffentlicht die Europäische Eisenbahnagentur die neue Fassung des Dokuments auf ihrer Website. Sind vom Änderungsmanagement allgemein gebräuchliche Elemente der TSI TAP [2] betroffen, so sind die Änderungen so eng wie möglich an die umgesetzte TSI TAP [2] anzulehnen, um optimale Synergien zu erzielen. |
(1) Verordnung (EG) Nr. 881/2004 des Europäischen Parlaments und des Rates vom 29. April 2004 zur Errichtung einer Europäischen Eisenbahnagentur („Agenturverordnung“) (ABl. L 164 vom 30.4.2004, S. 1).
Anlage I
Liste der technischen Dokumente
Nr. |
Referenz |
Titel |
Version |
Datum |
1 |
ERA-TD-100 |
TAF TSI — Anhang A.5: Abbildungen und Ablaufdiagramme der TSI-TAF-Meldungen |
2.0 |
17.10.2013 |
2 |
ERA-TD-101 |
TAF TSI — Anhang D.2: Anlage A (Fahrtenplanung Wagen/Intermodale Ladeeinheit) |
2.0 |
17.10.2013 |
3 |
ERA-TD-102 |
TAF TSI — Anhang D.2: Anlage B — Betriebsdatenbank für Wagen und Intermodaleinheiten (WIMO) |
2.0 |
17.10.2013 |
4 |
ERA-TD-103 |
TAF TSI — Anhang D.2: Anlage C — Referenzdateien |
2.0 |
17.10.2013 |
5 |
ERA-TD-104 |
TAF TSI — Anhang D.2: Anlage E — Gemeinsame Schnittstelle |
2.0 |
17.10.2013 |
6 |
ERA-TD-105 |
TAF TSI — Anhang D.2: Anlage F — Modell für TSI-TAF-Daten und -Meldungen |
2.0 |
17.10.2013 |
Anlage II
Glossar
Ausdruck |
Beschreibung |
||||||||||||||||||||||||||||||||||||||||||||||||||
Abfahrtsdatum/-zeit, tatsächliche(s) |
Datum (und Uhrzeit) der tatsächlichen Abfahrt des Transportmittels. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Abfahrtsort |
Ort, von dem ein Transportmittel abfahren soll oder abgefahren ist. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Abfertigungspunkt |
Bahnhof, an dem das EVU die Zugzusammensetzung ändern kann, wobei es aber weiter verantwortlich für die Wagen bleibt; keine Änderung der Verantwortung. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Absender |
Partei, die durch Vertrag mit einem Dienstintegrator Güter mit dem Güterverkehrsunternehmen verschickt oder von ihm transportieren lässt. Synonyme: Versender, Warenversender. |
||||||||||||||||||||||||||||||||||||||||||||||||||
ACID |
Atomicity, Consistency, Isolation, Durability (Deutsch auch: AKID, Atomarität, Konsistenzerhaltung, Isolation, Dauerhaftigkeit) Dies sind die vier Grundprinzipien einer Transaktion: Atomarität: In einer aus zwei oder mehreren Einzelinformationen bestehenden Transaktion werden entweder alle Teile oder überhaupt keine übergeben. Konsistenzerhaltung: Eine Transaktion schafft entweder einen neuen, gültigen Status der Daten, oder, wenn Fehler auftreten, alle Daten nehmen wieder den Status ein, den sie vor dem Start der Transaktion hatten. Isolation: Eine in Bearbeitung befindliche und noch nicht übergebene Transaktion muss von anderen Transaktionen isoliert bleiben. Dauerhaftigkeit: Übergebene Daten werden vom System gesichert, sodass die Daten auch im Fall eines Fehlers und Systemneustarts wieder in korrektem Zustand verfügbar sind. Das AKID-Konzept wird in ISO/IEC 10026-1:1992 Abschnitt 4 beschrieben. Jede dieser Eigenschaften kann anhand eines Vergleichswertes gemessen werden. Im Allgemeinen sind jedoch Transaktionsmanager oder -monitore für die Realisierung des AKID-Konzepts vorhanden. In einem verteilten System besteht eine Möglichkeit der Realisierung von AKID in der Zweiphasen-Zustimmung (2PC), die sicherstellt, dass entweder alle beteiligten Seiten dem Transaktionsabschluss zustimmen oder keine, wobei die Transaktion in letzterem Fall wieder zurückgenommen wird. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Antragsteller |
bezeichnet ein Eisenbahnunternehmen oder eine internationale Gruppierung von Eisenbahnunternehmen oder andere natürliche oder juristische Personen wie zuständige Behörden im Rahmen 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 (Richtlinie 2012/34/EU [3]); Zuweisungsstelle: siehe Begriffsbestimmung zu IB. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Auslastung der Transporteinheit |
Code zur Angabe, in welchem Maß die Transporteinheit beladen/unbeladen ist (z. B. voll, leer, Stückgut). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Beförderungsauftrag |
Eine Untermenge der Frachtbriefdaten, die alle relevanten Informationen umfasst, die ein EVU für den Transport unter seiner Verantwortung bis zur Übergabe an das nächste EVU benötigt. Anweisung zur Beförderung einer Wagenfracht. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Benannte Stellen |
Die Stellen, die damit betraut sind, die Konformität oder Gebrauchstauglichkeit von Interoperabilitätskomponenten zu bewerten bzw. das EG-Prüfverfahren für Teilsysteme durchzuführen (Richtlinie 91/440/EG (1)). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Beteiligte |
Jede Person oder Organisation mit einem Interesse an der Bereitstellung von Zugverkehrsleistungen, z. B.
Für Intermodalverkehr zusätzlich:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
Bruttogewicht |
Gebuchtes/tatsächliches Gesamtgewicht (Masse) der Güter, einschließlich Verpackung, jedoch ohne Transportvorrichtungen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Buchung |
Z. B. der Prozess zur Reservierung von Frachtraum in einem Transportmittel für Güter. |
||||||||||||||||||||||||||||||||||||||||||||||||||
CA |
Zertifizierungsbehörde |
||||||||||||||||||||||||||||||||||||||||||||||||||
COTS-Produkt |
Auf dem Markt erhältliches Standardprodukt („Commercially off the shelf product“) |
||||||||||||||||||||||||||||||||||||||||||||||||||
DARF NICHT |
Dieser Ausdruck oder das Wort „UNZULÄSSIG“ bedeutet, dass die betreffende Definition ein absolutes Verbot ist. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Dienstleister |
Für die jeweilige Transportphase verantwortliches Güterverkehrsunternehmen. Die Partei, die die Buchung entgegennimmt und bearbeitet. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Direktzug |
Zug mit zugehörigen Wagen, der ohne zwischenzeitliches Rangieren zwischen zwei Umschlagspunkten (Herkunftsort — Bestimmungsort) verkehrt. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Einheitszug |
Ein aus einheitlichen Wagen bestehender Güterzug, der mit einem einzigen Frachtbrief und einer einzigen Güterart auf die Fahrt geht und ohne zwischenzeitliches Rangieren direkt vom Absender zum Empfänger fährt. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Eisenbahnverkehrsunternehmen (EVU) |
„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. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Empfänger |
Partei, die die Güter empfangen soll. Synonym: Warenempfänger |
||||||||||||||||||||||||||||||||||||||||||||||||||
EVU |
Siehe Eisenbahnverkehrsunternehmen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Fahrplan |
Chronologisch definierte Belegung der Eisenbahninfrastruktur für eine Zugbewegung auf offener Strecke oder in Bahnhöfen. Fahrplanänderungen werden vom IB mindestens zwei Tage vor Beginn des Tages, an dem der Zug von seinem Abfahrtsort abfahren soll, vorgelegt. Dieser Fahrplan gilt für einen bestimmten Tag. In einigen Ländern auch als Betriebsfahrplan bezeichnet. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Fahrplanmäßige Abfahrtszeit |
Datum und Uhrzeit, für die die Trasse beantragt wird. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Fahrt |
„Fahrt“ bezeichnet die Beförderung eines beladenen oder leeren Wagens vom Abfahrtsbahnhof zum Zielbahnhof. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Fahrtabschnitt |
Der Teil einer Fahrt, der auf dem Infrastrukturabschnitt eines IBs stattfindet, oder der Teil einer Fahrt, der vom Übernahmepunkt bis zum Übergabepunkt auf der Infrastruktur eines IBs verläuft. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Federführendes Eisenbahnverkehrsunternehmen (FEVU) |
Verantwortliches EVU, das die Transportstrecke gemäß Verpflichtung gegenüber dem Kunden organisiert und managt. Das FEVU ist die einzige Kontaktstelle für den Kunden. Wenn mehrere EVU an der Transportkette beteiligt sind, ist das FEVU auch für die Koordination der diversen EVU zuständig. Ein Kunde kann speziell für den Intermodaltransport ein Intermodaldienstintegrator sein. |
||||||||||||||||||||||||||||||||||||||||||||||||||
FEVU |
Siehe Federführendes Eisenbahnverkehrsunternehmen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Frachtbrief |
Ein Dokument, das die Existenz eines Vertrages eines Güterverkehrsunternehmens für den Transport einer Fracht von einem bestimmten Übernahmeort bis zu einem bestimmten Lieferort belegt. Es enthält detaillierte Angaben über die zu befördernde Fracht. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Frachtkarte |
Das vom Güterverkehrsunternehmen oder im Namen des Güterverkehrsunternehmens ausgestellte Dokument, aus dem hervorgeht, dass ein Vertrag für den Transport einer Ladung besteht. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Freigabedatum/-zeit |
Datum/Uhrzeit, an dem/zu der die Güter versandbereit sein werden oder gemacht wurden. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Freigabezeit für Wagen |
Datum/Uhrzeit, an dem/zu der die Wagen zur Abholung auf dem Abfertigungsgleis des Kunden bereitstehen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
FTP |
Dateiübertragungsprotokoll (File Transfer Protocol). Ein Protokoll zur Übertragung von Dateien zwischen zwei Computern im TCP/IP-Netzwerk. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Ganzzug |
Spezifische Form eines Direktzuges, der zwischen einem Absender und einem Empfänger verkehrt. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Gateway |
Bahnhof innerhalb der Zugfahrt mit Intermodaleinheiten, in dem die Ladung den Wagen wechselt. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Gefahrenhalter |
Natürliche oder juristische Person, die das von ihr in das Netz eingebrachte Risiko trägt, z. B. das EVU. |
||||||||||||||||||||||||||||||||||||||||||||||||||
GGP |
Gateway-to-Gateway-Protokoll. Siehe auch IP. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Grundlegende Anforderungen |
Alle Bedingungen nach Anhang III der Richtlinie 2001/16/EG des Europäischen Parlaments und des Rates (*1), die das transeuropäische Bahnsystem, seine Teilsysteme und die Interoperabilitätskomponenten, einschließlich der Schnittstellen, erfüllen müssen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Halter |
Person, die als Eigentümer oder Verfügungsberechtigter ein Fahrzeug dauerhaft wirtschaftlich als Transportmittel nutzt, wozu sie im Fahrzeugregister eingetragen ist. |
||||||||||||||||||||||||||||||||||||||||||||||||||
HS-Code |
Vom Zoll verwendeter sechsstelliger Code für Waren, identisch mit den ersten sechs Stellen des KN-Codes. |
||||||||||||||||||||||||||||||||||||||||||||||||||
HTTP |
Hypertext Transfer Protocol (Hypertext-Übertragungsprotokoll) Das Client/Server-Protokoll, das zum Anschluss von Servern im World Wide Web dient. |
||||||||||||||||||||||||||||||||||||||||||||||||||
IB |
„Infrastrukturbetreiber“ bezeichnet jede Stelle oder jedes Unternehmen, die bzw. das insbesondere für die Einrichtung, die Verwaltung und die Unterhaltung der Fahrwege der Eisenbahn, einschließlich Verkehrsmanagement, Zugsteuerung/Zugsicherung und Signalgebung, zuständig ist; mit den bei einem Netz oder Teilen eines Netzes wahrzunehmenden Funktionen des IBs können verschiedene Stellen 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 (Richtlinie 2012/34/EG [3]). |
||||||||||||||||||||||||||||||||||||||||||||||||||
ICMP |
Internet Control Message Protocol (ICMP). Gelegentlich nimmt ein Gateway (siehe GGP) oder ein Destination-Host (siehe IP) die Kommunikation mit einem Source-Host auf, um ihm z. B. einen Fehler bei der Verarbeitung der Datagramme zu melden. Für diese Zwecke wird das Internet Control Message Protocol (ICMP) verwendet. ICMP stützt sich in gewisser Weise so auf das IP, als wäre es ein höher angeordnetes Protokoll; tatsächlich ist ICMP jedoch ein untrennbarer Bestandteil des IP und muss in jedem IP-Modul implementiert sein. ICMP-Meldungen werden in verschiedenen Situationen verschickt: zum Beispiel wenn ein Datagramm sein Ziel nicht erreichen kann, wenn der Gateway nicht genügend Pufferkapazität hat, um ein Datagramm weiterzuleiten, und wenn ein Gateway den Host anweisen kann, die Datagramme über eine kürzere Route zu schicken. Das Internet Protocol bietet keine absolute Zuverlässigkeit. Diese Kontrollmeldungen dienen nicht dazu, das IP zuverlässig zu machen, sondern sollen Probleme in der Kommunikationsumgebung aufzeigen. Es gibt dennoch keine Garantie, dass ein Datagramm zugestellt oder eine Kontrollmeldung zurückgeschickt wird. Einige Datagramme können unzugestellt verschwinden, ohne als verloren gemeldet zu werden. Die höher angeordneten Protokolle, die auf IP aufsetzen, müssen über eigene Zuverlässigkeitsverfahren verfügen, wenn eine zuverlässige Kommunikation gefordert ist. Die ICMP-Meldungen verweisen in der Regel auf Fehler bei der Verarbeitung der Datagramme. Um eine endlose Schleife von Meldungen über Meldungen etc. auszuschließen, werden keine ICMP-Meldungen über ICMP-Meldungen generiert. Zudem werden ICMP-Meldungen nur dann geschickt, wenn bei der Abfertigung fragmentierter Datagramme Fehler in der Erkennung des Fragments Null auftreten. (Fragment Null hat einen Fragment-Offset von Null.) |
||||||||||||||||||||||||||||||||||||||||||||||||||
Inbetriebnahme |
Ein von der technischen Zulassung und einem Nutzungsvertrag mit einem EVU abhängiges Verfahren, das den kommerziellen Betrieb eines Wagens erlaubt. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Infrastrukturbetreiber (IB) |
Siehe IB |
||||||||||||||||||||||||||||||||||||||||||||||||||
Intermodalbetreiber |
Juristische Person, die einen Vertrag über den intermodalen Verkehr schließt und die Gesamtverantwortung für die intermodalen Ladeeinheiten übernimmt. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Intermodaldienstintegrator |
Jede(s) Stelle oder Unternehmen, die (das) mit den Kunden Verträge zum Transport von Intermodaleinheiten schließt. Erstellt die Frachtkarten, verwaltet die Kapazität von Blockzügen etc. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Intermodaleinheit |
Ladeeinheit, die auf verschiedenen Verkehrsträgern transportiert werden kann, z. B. Container, Wechselbehälter, Sattelanhänger, Anhänger. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Intermodalterminal |
Ort, der den Platz, die Ausrüstung und die Betriebsumgebung für den Transfer von Ladeeinheiten (Frachtcontainer, Wechselbehälter, Sattelanhänger oder Anhänger) bietet. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Intermodaltransport |
Bewegung von Gütern in ein und derselben Ladeeinheit oder ein und demselben Fahrzeug, die/das nacheinander mehrere Verkehrsträger nutzt, ohne dass ein direkter Umgang mit den Gütern beim Wechsel der Verkehrsträger erfolgt. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Internet |
|
||||||||||||||||||||||||||||||||||||||||||||||||||
Interoperabilitätskomponente |
bezeichnet Grundbauteile, Bauteilgruppen, Unterbaugruppen oder komplette Materialbaugruppen, die in ein Teilsystem eingebaut sind oder eingebaut werden sollen und von denen die Interoperabilität des Eisenbahnsystems direkt oder indirekt abhängt. Unter „Komponenten“ sind materielle, aber auch immaterielle Produkte wie Software zu verstehen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
IP |
Internet Protocol (Internet-Protokoll) Das Internet Protocol (IP) dient in einem System miteinander verbundener Netzwerke für den Datagramm-Dienst von Host zu Host. Die Netzwerkverbindungsrechner heißen Gateways. Diese Gateways verständigen sich untereinander zu Steuerungszwecken mit Hilfe des Gateway-to-Gateway-Protokolls (GGP). |
||||||||||||||||||||||||||||||||||||||||||||||||||
KANN |
Dieses Wort oder das Adjektiv „OPTIONAL“ gibt an, dass ein Element wirklich optional ist. Ein Anbieter kann sich entschließen, das Element mit aufzunehmen, weil es auf einem bestimmten Markt benötigt wird oder weil es nach Meinung des Anbieters das Gesamtprodukt verbessert, während ein anderer Anbieter darauf verzichtet. Eine Implementierung, die eine bestimmte Option nicht enthält, MUSS mit jeder anderen Implementierung, die die betreffende Option enthält, zusammenarbeiten können, wenngleich möglicherweise mit eingeschränkter Funktionalität. Ebenso MUSS eine Implementierung, die eine bestimmte Option enthält, mit jeder anderen Implementierung, die die betreffende Option nicht enthält, zusammenarbeiten können (ausgenommen natürlich die Funktion, die mit der Option erfüllt wird). |
||||||||||||||||||||||||||||||||||||||||||||||||||
KN-Code |
Vom Zoll verwendeter achtstelliger Code für Waren. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Kombinierter Verkehr Straße/Schiene |
Intermodaltransport, bei dem die Fahrt innerhalb Europas zum größten Teil im Eisenbahnverkehr erfolgt und der Vorlauf und/oder Nachlauf auf der Straße möglichst kurz ist. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Kooperationsmodus |
Eine Art des Zugbetriebs, bei der verschiedene EVU unter der Federführung eines EVU (FEVU) zusammenarbeiten. Jedes beteiligte EVU bestellt die für die Transportfahrt erforderlichen Zugtrassen eigenständig. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Kunde |
Partei, die den Frachtbrief für das federführende EVU (FEVU) erstellt hat. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Kurzfristiger Trassenantrag |
Antrag auf Zuweisung einzelner Zugtrassen gemäß Artikel 23 der Richtlinie 2001/14/EG, der aufgrund von zusätzlichem Transportbedarf oder betrieblichen Erfordernissen gestellt wird. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Ladeeinheit |
Mehrere Einzelpakete, die zur effizienteren Handhabung beim Laden in einer Umverpackung, auf Paletten oder in Bündeln zu einer größeren Einheit zusammengefasst sind. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Lieferort |
Ort, an dem die Ablieferung erfolgt (Abfahrtsbahnhof ist anzugeben). Ein Ort, an dem die Zuständigkeit für den Wagen wechselt. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Lieferung |
Eine Warensendung, die von einem Absender an einen Empfänger geschickt und dazu in eine oder mehrere ganze Intermodaleinheiten oder auf einen oder mehrere ganze Wagen geladen wird. Beispiele:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
Meldepunkt |
Ort im Verlauf einer Zugfahrt, an dem der zuständige IB eine „Zugfahrtprognosemeldung“ mit TETA an das EVU, das die Trasse gebucht hat, absetzen muss. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Metadaten |
Einfach ausgedrückt sind Metadaten Daten über Daten. Metadaten beschreiben Daten, Software-Dienste und andere Komponenten in unternehmensweiten Informationssystemen. Beispiele für Metadaten sind u. a. Definitionen von Standarddaten, Ortsangaben und Zustellinformationen, Synchronisationsmanagement für die Verteilung gemeinsam genutzter Daten. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Mieter |
Natürliche oder juristische Person, die vom Halter/Besitzer eines Wagens als Mieter ausgewiesen ist. |
||||||||||||||||||||||||||||||||||||||||||||||||||
MUSS |
Dieses Wort oder die Ausdrücke „ERFORDERLICH“ oder „VORGESCHRIEBEN“ bedeuten, dass die betreffende Definition eine absolute Verpflichtung ist. |
||||||||||||||||||||||||||||||||||||||||||||||||||
NFS |
Das Network File System (NFS) ist ein Protokoll für dezentrale Dateisysteme. Das Network File System (NFS) ermöglicht einen transparenten Fernzugriff auf Dateisysteme, die über Netzwerke hinweg gemeinsam genutzt werden. Das NFS-Protokoll arbeitet unabhängig von Maschinen, Betriebssystemen, Netzarchitektur, Sicherheitsmechanismen und Transportprotokollen. Diese Unabhängigkeit wird erreicht durch den Einsatz von Routinen mit der Bezeichnung Remote Procedure Call (RPC), die auf einer so genannten eXternal Data Representation (XDR) aufbauen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Offener Netzzugang |
Eine Art des Zugbetriebs, bei der nur ein EVU beteiligt ist, das den Zug über verschiedene Infrastrukturen betreibt. Dieses EVU bestellt die erforderlichen Zugtrassen bei allen beteiligten IB. |
||||||||||||||||||||||||||||||||||||||||||||||||||
One Stop Shop (OSS) |
Eine internationale Partnerschaft zwischen Eisenbahninfrastrukturbetreibern; sie bietet den Bahnkunden eine einzige Anlaufstelle für folgende Zwecke:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
OSI |
Open Systems Interconnection Beschreibt ein Kommunikationsprotokoll für offene Systeme, das auf dem OSI-Schichtenmodell basiert. Offene Systeme können unabhängig von proprietären Lösungen miteinander kommunizieren. |
||||||||||||||||||||||||||||||||||||||||||||||||||
OSI-Schichtenmodell |
Standardbeschreibung, wie Meldungen zwischen zwei Punkten in einem Netzwerk übertragen werden sollten. Das OSI-Modell definiert 7 Schichten von Funktionen, die an jedem Ende einer Kommunikation stattfinden. Diese Schichten sind der einzige international anerkannte Standard für die Kommunikation. |
||||||||||||||||||||||||||||||||||||||||||||||||||
OSS |
One Stop Shop |
||||||||||||||||||||||||||||||||||||||||||||||||||
PAZ |
Voraussichtliche Ankunftszeit |
||||||||||||||||||||||||||||||||||||||||||||||||||
Peer-to-Peer |
Der Ausdruck „Peer-to-Peer“ bezieht sich auf eine Klasse von Systemen und Anwendungen, die mit verteilten Ressourcen arbeiten, um eine kritische Funktion dezentral durchzuführen. Die Ressourcen bestehen aus Rechenleistung, Daten (Speicherung und Inhalt), Netzbandbreite und Präsenz (Computer, Menschen und andere Ressourcen). Kritische Funktionen sind beispielsweise dezentrale Rechenleistungen, Bereitstellung von Daten/Inhalten zur gemeinsamen Nutzung sowie Kommunikation und Zusammenarbeit oder Plattformdienste. Die Dezentralisierung kann sich auf Algorithmen, Daten, Metadaten oder alle diese Elemente erstrecken. Dies schließt nicht aus, dass in einigen Teilen der Systeme und Anwendungen ein zentrales System beibehalten wird, wenn es den Erfordernissen gerecht wird. |
||||||||||||||||||||||||||||||||||||||||||||||||||
PKI |
Public Key Infrastructure — Infrastruktur mit öffentlich hinterlegtem Schlüssel |
||||||||||||||||||||||||||||||||||||||||||||||||||
Primärdaten |
Basisdaten, die als Referenzdaten für Meldungen oder als Grundlage für die Funktionalität und Berechnung abgeleiteter Daten dienen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Prognostizierte Zeit |
Beste Schätzung der Ankunfts-, Abfahrts- oder Durchfahrtszeit eines Zuges. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Protokollierung |
Aktivität bei einem Nachforschungsauftrag zum Suchen und Rekonstruieren des Transportverlaufs einer/eines definierten Fracht, Fahrzeugs, Anlage, Pakets oder Ladung. |
||||||||||||||||||||||||||||||||||||||||||||||||||
PÜZ |
Voraussichtliche Wagenübergangszeit von einem EVU zu einem anderen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
PZAZ |
Siehe Voraussichtliche Ankunftszeit des Zuges (Train Estimated Time of Arrival) |
||||||||||||||||||||||||||||||||||||||||||||||||||
PZÜ |
Voraussichtliche Zeit der Übergabe eines Zuges von einem IB an einen anderen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
RAMS (Reliability, Availability, Maintainability, Safety) |
siehe Zuverlässigkeit, Verfügbarkeit, Wartbarkeit, Sicherheit. |
||||||||||||||||||||||||||||||||||||||||||||||||||
RARP |
Reverse Address Resolution Protocol (RARP) |
||||||||||||||||||||||||||||||||||||||||||||||||||
RIV |
Übereinkommen über die gegenseitige Benutzung von Fahrzeugen im internationalen Verkehr. Übereinkommen über die gegenseitige Benutzung von Ladegeräten, Containern und Paletten im internationalen Verkehr. |
||||||||||||||||||||||||||||||||||||||||||||||||||
RPC |
Remote Procedure Call Das RPC-Protokoll ist spezifiziert in der Remote Procedure Call Protocol Specification Version 2 [RFC1831]. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Sendung |
Güter, die im Rahmen eines einzigen Beförderungsvertrages versandt werden. Im kombinierten Verkehr kann dieser Begriff zu statistischen Zwecken als Maß für Ladeeinheiten oder Straßenfahrzeuge verwendet werden. |
||||||||||||||||||||||||||||||||||||||||||||||||||
SMTP |
Simple Mail Transfer Protocol |
||||||||||||||||||||||||||||||||||||||||||||||||||
SNMP |
Simple Network Management Protocol |
||||||||||||||||||||||||||||||||||||||||||||||||||
SOLLTE |
Dieses Wort oder das Adjektiv „EMPFOHLEN“ bedeutet, dass es stichhaltige Gründe geben kann, unter bestimmten Umständen ein bestimmtes Element zu ignorieren; die Konsequenzen müssen jedoch hinreichend verstanden und sorgfältig abgewogen werden, bevor die Entscheidung für eine Abweichung von der empfohlenen Vorgehensweise getroffen wird. |
||||||||||||||||||||||||||||||||||||||||||||||||||
SOLLTE NICHT |
Dieser Ausdruck oder der Ausdruck „NICHT EMPFOHLEN“ bedeutet, dass es stichhaltige Gründe geben kann, ein bestimmtes Verhalten unter bestimmten Umständen als akzeptabel oder sogar sinnvoll anzusehen; die Konsequenzen müssen jedoch hinreichend verstanden und sorgfältig abgewogen werden, bevor die Entscheidung für eine nicht empfohlene Vorgehensweise getroffen wird. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Speditionstransport |
Transport auf der Straße. |
||||||||||||||||||||||||||||||||||||||||||||||||||
SQL |
Structured Query Language Eine von IBM entwickelte und von ANSI und ISO standardisierte Sprache zur Erstellung, Pflege und zum Abruf von Daten in relationalen Datenbanken. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Strecke |
Der geografische Weg von einem Anfangspunkt zu einem Zielpunkt. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Streckenabschnitt |
Teil einer Strecke. |
||||||||||||||||||||||||||||||||||||||||||||||||||
TCP |
Transmission Control Protocol (TCP) |
||||||||||||||||||||||||||||||||||||||||||||||||||
Technische Spezifikation für die Interoperabilität |
Bezeichnet die Spezifikationen, die für jedes Teilsystem oder dessen Teile im Hinblick auf die Erfüllung der grundlegenden Anforderungen gelten und die Interoperabilität des konventionellen transeuropäischen Eisenbahnsystems gewährleisten. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Tourenplan |
Für Wagen- oder Intermodaleinheiten; zeigt die für einen Wagen oder eine Intermodaleinheit geplante Tour. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Transeuropäisches Bahnnetz |
Das in Anhang 1 der Richtlinie 2001/16/EG (*1) beschriebene Eisenbahnnetz. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Trasse |
„Trasse“ bezeichnet die Infrastrukturkapazität, die für den Betrieb eines Zuges zwischen zwei Orten innerhalb eines gegebenen Zeitraums erforderlich ist (zeitlich und räumlich definierte Strecke). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Trassennummer |
Nummer einer definierten Zugtrasse. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Trassenverbund |
Zusammenschluss einzelner Trassen zur zeitlichen und räumlichen Erweiterung der Trasse. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Triebfahrzeug-ID |
Eindeutige Kennung eines Triebfahrzeugs. |
||||||||||||||||||||||||||||||||||||||||||||||||||
TSI |
Siehe „Technische Spezifikation für die Interoperabilität“. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Tunnelling |
Prozess, bei dem private IP-Pakete in einem öffentlichen IP-Paket eingekapselt werden. |
||||||||||||||||||||||||||||||||||||||||||||||||||
UDP |
User Datagram Protocol „Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs) (STUN)“ ist ein abgespecktes Protokoll, mit dem Anwendungen erkennen können, ob und welche NATs und Firewalls sich zwischen ihnen und dem öffentlichen Internet befinden. Es gibt den Anwendungen auch die Möglichkeit, die öffentliche Internet-Protocol-Adresse (IP-Adresse) zu bestimmen, die ihnen vom NAT zugewiesen wurde. STUN arbeitet mit vielen bestehenden NATs und erfordert kein spezielles Verhalten. So können zahlreiche Anwendungen problemlos mit bestehenden NAT-Infrastrukturen arbeiten. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Übergabepunkt |
Punkt, an dem die Verantwortung von einem IB auf einen anderen übergeht. |
||||||||||||||||||||||||||||||||||||||||||||||||||
UIC |
Internationaler Eisenbahnverband. |
||||||||||||||||||||||||||||||||||||||||||||||||||
UITP |
Internationaler Verband für öffentliches Verkehrswesen. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Umschlag, Umladung |
Der Vorgang der Umladung von Intermodaleinheiten von einem Transportmittel auf ein anderes. |
||||||||||||||||||||||||||||||||||||||||||||||||||
UNIFE |
UNIFE ist ein Verband, der die Interessen der Eisenbahnzulieferer vertritt. Derzeit sind etwa 100 Zulieferer und deren Auftragnehmer direkt in der UNIFE organisiert; rund 1 000 weitere sind über nationale Organisationen vertreten. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Verfolgung (Tracking) |
Systematische Überwachung und Aufzeichnung des jeweiligen Standorts einer/eines definierten Fracht, Fahrzeugs, Anlage, Pakets oder Ladung. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Verschlüsselung |
Codierung von Meldungen. Entschlüsselung: Rückverwandlung verschlüsselter Daten in ihre ursprüngliche Form. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Vor-Abfahrt-Periode |
ist die Delta-Zeit vor der geplanten Abfahrt. Die Vor-Abfahrt-Periode beginnt mit der fahrplanmäßigen Abfahrtszeit minus der Delta-Zeit und endet zur fahrplanmäßigen Abfahrtszeit. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Voraussichtliche Ankunftszeit des Zuges |
Geschätzte Ankunftszeit eines Zuges an einem spezifischen Punkt, z. B. Übergabepunkt, Wagenübergangspunkt, Zielort des Zuges. |
||||||||||||||||||||||||||||||||||||||||||||||||||
VPN |
Virtual Private Network Der Ausdruck Virtual Private Network wird verwendet, um nahezu jede Art von Netz mit angeschlossenen Fernteilnehmern zu beschreiben, vom öffentlichen Telefonnetz bis hin zu Großrechner-Netzen. Mit der Einführung des Internet wurde VPN zum Synonym für dezentrale Datennetze auf IP-Basis. Einfach ausgedrückt besteht ein VPN aus zwei oder mehr privaten Netzen, die über ein öffentliches Netz sicher miteinander kommunizieren. Ein VPN kann zwischen einem Einzelrechner und einem privaten Netz (Client-Server) oder zwischen einem fernen LAN und einem privaten Netz (Server-Server) bestehen. Die privaten Netze können die Verbindung mit Hilfe der Tunnelling-Technik aufnehmen. Ein VPN nutzt gewöhnlich das Internet als Transportnetz, verschlüsselt seine Daten vor dem Versand zwischen einem VPN-Client und einem VPN-Gateway jedoch so, dass sie nicht gelesen werden können, selbst wenn sie unterwegs abgefangen werden. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Wagenladung |
Eine Ladeeinheit, bei der der Wagen die Einheit bildet. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Wagenübergang |
Der Wechsel der betrieblichen und sicherheitstechnischen Verantwortung von einem EVU zu einem anderen. Beispiele:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
Wagenübergangspunkt |
Punkt, an dem die Verantwortung für die Wagen eines Zuges von einem EVU auf ein anderes übergeht. Bezogen auf eine Zugfahrt bedeutet dies, dass der Zug von einem EVU an ein anderes übergeben wird, das nun die Trasse für den nächsten Fahrtabschnitt besitzt. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Web |
World Wide Web: Ein Dienst innerhalb des Internet, der Dokumente verknüpft, indem er Hypertext-Links von Server zu Server liefert, sodass der Benutzer von einem Dokument zu einem damit verbundenen Dokument springen kann, das sich an anderer Stelle im Internet befindet. |
||||||||||||||||||||||||||||||||||||||||||||||||||
XDR |
External Data Representation Das XDR-Protokoll ist spezifiziert im External Data Representation Standard [RFC1832]. XDR ist ein Standard zur Beschreibung und Codierung von Daten. Es dient der Übertragung von Daten zwischen verschiedenen Computerarchitekturen. XDR passt in die ISO-Darstellungsschicht und ähnelt von seinem Zweck her dem Protokoll X.409, ISO Abstract Syntax Notation. Der Hauptunterschied zwischen diesen beiden liegt darin, dass XDR implizite Typen und X.409 explizite Typen verwendet. XDR verwendet eine Sprache zur Beschreibung von Datenformaten. Die Sprache dient nur zur Beschreibung der Daten, sie ist keine Programmiersprache. Mit dieser Sprache ist es möglich, komplexe Datenformate kurz und knapp zu beschreiben. Die Alternative einer grafischen Darstellung (die eine informelle Sprache darstellt) wird schnell unübersichtlich, wenn es um komplexe Sachverhalte geht. Die XDR-Sprache selbst ähnelt der Sprache „C“. Protokolle wie ONC RPC (Remote Procedure Call) und NFS (Network File System) verwenden XDR zur Beschreibung des Formats ihrer Daten. Der XDR-Standard beruht auf der Annahme, dass Bytes (oder Oktette) portabel sind, wobei ein Byte als eine Menge von 8 Datenbits definiert ist. Ein Hardwaregerät sollte die Bytes so auf die verschiedenen Medien codieren, dass andere Hardwaregeräte die Bytes ohne Sinnverlust decodieren können. |
||||||||||||||||||||||||||||||||||||||||||||||||||
XML-RPC |
XML-RPC ist ein im Internet genutztes Protokoll mit der Bezeichnung Extensible Markup Language-Remote Procedure Call. Es definiert ein XML-Format für Mitteilungen, die über HTTP zwischen Clients und Servern übertragen werden. Eine XML-RPC-Mitteilung codiert entweder ein von einem Server aufzurufendes Verfahren (mitsamt den dabei zu verwendenden Parametern) oder das Ergebnis eines solchen Verfahrensaufrufs. Die Verfahrensparameter und -ergebnisse können Skalare, Zahlen, Textfolgen, Datumsangaben usw. sein; sie können aber auch komplexe Datensätze oder Listenstrukturen sein. Dieses Dokument spezifiziert, wie das Blocks Extensible Exchange Protocol (BEEP) zur Übertragung von im XML-RPC-Format codierten Meldungen zwischen Client und Server verwendet werden kann. |
||||||||||||||||||||||||||||||||||||||||||||||||||
XQL |
Extended Structured Query Language |
||||||||||||||||||||||||||||||||||||||||||||||||||
Zentralspeicher (Repository) |
Ein Repository oder zentraler Datenspeicher ähnelt einer Datenbank oder einem Datenwörterbuch, besitzt jedoch zusätzlich ein umfassendes Informationsmanagementsystem. Er muss nicht nur die Beschreibungen der Datenstrukturen (d. h. Einheiten und Elemente) enthalten, sondern auch die für das Unternehmen wichtigen Metadaten, Datenmasken, Berichte, Programme und Systeme. Er verfügt in der Regel über eine Reihe interner Software-Tools, ein Datenbankmanagementsystem, ein Metamodell, Stamm-Metadaten sowie Lade- und Abruf-Software für den Zugriff auf die gespeicherten Daten. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Zielort |
Ort, an dem das Transportmittel ankommen soll oder angekommen ist. Synonym: Ankunftsort. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Zugtrasse |
Zeitlich und räumlich definierte Fahrtstrecke eines Zuges. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Zugtrasse/Slot |
Definition einer Zugstrecke mit Nennung des Zeitrahmens, der Orte (Markierungspunkte), an denen der Zug beginnt und endet, und mit Angaben zu Orten entlang der Strecke, an denen der Zug durchfährt oder einen Zwischenhalt einlegt. Zu den detaillierten Angaben gehören auch etwaige Aktivitäten, die entlang der Strecke am Zug vorgenommen werden, z. B. Wechsel des Zugpersonals, des Triebfahrzeugs oder Änderungen der Zugbildung. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Zuverlässigkeit, Verfügbarkeit, Wartbarkeit, Sicherheit (RAMS) |
Zuverlässigkeit— mathematisch ausgedrückte Fähigkeit, unter vorgegebenen Betriebsbedingungen in einem vorgegebenen Zeitraum den Betrieb aufzunehmen und fortzusetzen; Verfügbarkeit— mathematisch ausgedrückter Vergleich zwischen der Zeit, die ein System in Betrieb ist, und der Zeit, die das System außer Betrieb ist; Wartbarkeit— mathematisch ausgedrückte Fähigkeit, ein System nach einem Ausfall wieder in Betrieb zu setzen; Sicherheit— mathematisch ausgedrückte Wahrscheinlichkeit, dass von einem System ein gefährliches Ereignis ausgeht. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Zuweisungsstelle |
siehe IB |
||||||||||||||||||||||||||||||||||||||||||||||||||
Zwischenpunkt |
Ort, der den Anfangs- oder Endpunkt eines Fahrtabschnitts definiert. Dies kann z. B. ein Übergangs-, Übergabe- oder Abfertigungspunkt sein. |
(*1) Richtlinie 2001/16/EG des Europäischen Parlaments und des Rates vom 19. März 2001 über die Interoperabilität des konventionellen transeuropäischen Eisenbahnsystems (ABl. L 110 vom 20.4.2001, S. 1).
(1) Richtlinie 91/440/EWG des Rates vom 29. Juli 1991 zur Entwicklung der Eisenbahnunternehmen der Gemeinschaft (ABl. L 237 vom 24.8.1991, S. 25).
Anlage III
Aufgaben der nationalen TAF/TAP-Anlaufstelle
(1)
Herstellung des Kontakts zwischen ERA, TAF/TAP-Lenkungsausschuss und den Bahnakteuren des Mitgliedstaats (Infrastrukturbetreiber, Eisenbahnverkehrsunternehmen, Wagenhalter, Bahnhofsbetreiber, Fahrkartenverkäufer, Intermodalbetreiber, Frachtkunden und einschlägige Organisationen), um das Engagement der Bahnakteure an TAF und TAP sicherzustellen und dafür zu sorgen, dass sie über die allgemeinen Entwicklungen und die Entscheidungen des Lenkungsausschusses unterrichtet sind.
(2)
Unterrichtung des TAF/TAP-Lenkungsausschusses über Anliegen und Fragen der Bahnakteure des Mitgliedstaats durch die gemeinsamen Vorsitzenden.
(3)
Verbindung zum nationalen Vertreter im Ausschuss für Eisenbahninteroperabilität und -sicherheit (RISC), damit der RISC-Vertreter vor jeder RISC-Sitzung über nationale TAF/TAP-Themen informiert wird und TAF/TAP betreffende Entscheidungen des RISC den betroffenen Bahnakteuren in geeigneter Weise mitgeteilt werden.
(4)
Der Mitgliedstaat sorgt dafür, dass alle zugelassenen Eisenbahnverkehrsunternehmen und sonstigen Bahnakteure (Infrastrukturbetreiber, Eisenbahnverkehrsunternehmen, Wagenhalter, Bahnhofsbetreiber, Intermodalbetreiber, Frachtkunden und einschlägige Organisationen) kontaktiert und über die nationale Anlaufstelle informiert werden und ihnen empfohlen wird, Verbindung zu der Anlaufstelle aufzunehmen, soweit dies noch nicht geschehen ist.
(5)
Unterrichtung der Bahnakteure des Mitgliedstaats, soweit sie bekannt sind, über ihre Verpflichtungen im Rahmen der TAF/TAP-Verordnungen.
(6)
Zusammenarbeit mit dem Mitgliedstaat zur Benennung einer Stelle, die für die Einspeisung primärer Standortcodes in die zentrale Referenzdomäne verantwortlich ist. Die Identität der benannten Stelle ist der GD MOVE zur entsprechenden Weitergabe mitzuteilen.
(7)
Förderung des Informationsaustauschs zwischen den Bahnakteuren der Mitgliedstaaten (Infrastrukturbetreiber, Eisenbahnverkehrsunternehmen, Wagenhalter, Bahnhofsbetreiber, Fahrkartenverkäufer, Intermodalbetreiber, Frachtkunden und einschlägige Organisationen) in dem Mitgliedstaat.