TABELLEN: VO (EG) 2006/62

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

Das konventionelle transeuropäische Bahnsystem

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

1.

EINFÜHRUNG

1.1.

Technischer Anwendungsbereich

Die vorliegende TSI betrifft das Teilsystem Telematikanwendungen für den Güterverkehr, wie es in der Liste unter Punkt 1B im Anhang II zur Richtlinie 2001/16/EG aufgezeigt ist. Voraussetzung für den kommerziellen Betrieb von Zügen, Wagen und Einheiten für den kombinierten Verkehr im transeuropäischen Eisenbahnnetz ist insbesondere ein effizienter Austausch an Informationen unter den verschiedenen Fahrwegbetreibern, Eisenbahnverkehrsunternehmen und anderen Dienstleistern. Von dieser Kompatibilität und Verknüpfung hängen das Leistungsniveau, die Sicherheit und die Qualität der angebotenen Verkehrsdienste sowie deren Kosten ab, und auf dieser Kompatibilität und Verknüpfung beruht vor allem die Interoperabilität des konventionellen transeuropäischen Eisenbahnsystems. Die technische Spezifikation für die Interoperabilität wirkt sich auch auf die Bedingungen für die Inanspruchnahme der Eisenbahn durch die Benutzer aus. In diesem Kontext bezeichnet der Ausdruck Benutzer nicht nur die Infrastrukturbetreiber oder Eisenbahnverkehrsunternehmen, sondern auch alle anderen Dienstleister wie Waggongesellschaften, Gesellschaften des intermodalen Verkehrs und sogar Kunden. Zu guter Letzt bietet die Interoperabilität des konventionellen Bahnsystems den Vorteil, die Bedingungen für eine größere Interoperabilität zwischen den Verkehrsträgern zu schaffen, insbesondere zwischen dem konventionellen Eisenbahntransport und dem kombinierten Schienentransport. Diese TSI soll auch sicherstellen, dass dieser wirksame Informationsaustausch qualitativ und mengenmäßig jederzeit optimal an veränderte Anforderungen angepasst werden kann, so dass der Transportprozess so wirtschaftlich wie möglich bleibt und der Güterverkehr auf der Schiene seinen Marktanteil gegen einen immer schärferen Wettbewerb verteidigen kann. All dies bedeutet die Schaffung oder die Verbesserung des konventionellen transeuropäischen Eisenbahnsystems für den konventionellen Schienengüterverkehr und für den kombinierten Güterverkehr. Dass eine solche Verbesserung des Schienenanteils des Güterverkehrsystems erforderlich ist, zeigt sich auch im Vergleich der kritischen Punkte (Schnittstellen zwischen den verschiedenen beteiligten Partnern) im Güterverkehr auf der Straße mit den kritischen Punkten im Güterverkehr auf der Schiene, wie es sich bereits aus dem vereinfachten Szenario in Anhang A Ziffer 5 Kapitel 1.1 ersehen lässt. Das Ziel dieser TSI ist es, Transporte unter den Bedingungen der Einbeziehung einer großen Zahl von Schnittstellen mit Hilfe eines Informationsaustauschs auf Grundlage der Richtlinien 2001/14/EG⁽¹⁾ und 2001/16/EG des Europäischen Parlaments und des Rates zu managen. Diese kurze Erklärung für den Anwendungsbereich der TSI Telematikanwendungen für den Güterverkehr zeigt auch den Unterschied zur TSI „Betrieb und Verkehrssteuerung” für das konventionelle Bahnsystem. Die TSI „Betrieb und Verkehrssteuerung” behandelt — insbesondere unter Sicherheitsaspekten — die Verfahren und die zugehörige gerätetechnische Ausstattung für den kohärenten Betrieb der verschiedenen strukturellen Teilsysteme, einschließlich insbesondere der Zugführung, der Planung und der Abwicklung des Verkehrsbetriebs, die definitionsgemäß zu den ursprünglichen Aufgaben eines Eisenbahnverkehrsunternehmens (EVU) gehören (siehe Kapitel 2.3: Übersicht über die Beschreibung des Teilsystems). Die TSI „Telematikanwendungen für den Güterverkehr” behandelt die Anwendungen für den Güterverkehr und das Management der Verknüpfungen mit anderen Verkehrsträgern, was bedeutet, dass sie sich zusätzlich zum reinen Betrieb von Zügen auf die Transportdienstleistungen eines EVU konzentriert. Aspekte der Sicherheit werden nur insoweit betrachtet, als die Existenz von Daten, z. B. falsche oder nicht aktuelle Werte, einen Einfluss auf den sicheren Betrieb eines Zuges haben können.

1.2.
Geografischer Anwendungsbereich

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

1.3.
Inhalt dieser TSI

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

a): gibt diese TSI den vorgesehenen Anwendungsbereich der TSI Telematikanwendungen für den Güterverkehr an — Kapitel 2: Definition des Teilsystems/Anwendungsbereich; Schließlich umfasst diese TSI in Kapitel 4 (Beschreibung des Teilsystems) ebenfalls die geltenden Betriebs- und Wartungsvorschriften für den Anwendungsbereich, der in den oben stehenden Abschnitten 1.1 (Technischer Anwendungsbereich) und 1.2 (Geografischer Anwendungsbereich) genannt wird.
b): nennt diese TSI die grundlegenden Anforderungen an dieses Teilsystem und seine Schnittstellen mit anderen Teilsystemen — Kapitel 3: Grundlegende Anforderungen
c): legt diese TSI die funktionellen und technischen Spezifikationen fest, denen das Teilsystem und seine Schnittstellen mit anderen Teilsystemen entsprechen müssen — Kapitel 4: Beschreibung des Teilsystems
d): bestimmt diese TSI die Interoperabilitätskomponenten und Schnittstellen, die Gegenstand europäischer Spezifikationen einschließlich europäischer Normen sind, die zur Verwirklichung der Interoperabilität im konventionellen transeuropäischen Eisenbahnsystem erforderlich sind — Kapitel 5: Interoperabilitätskomponenten
e): gibt diese TSI für jeden in Betracht kommenden Fall die Verfahren zur Bewertung der Konformität oder der Gebrauchstauglichkeit an. Dies umfasst insbesondere die Module gemäß dem Beschluss 93/465/EWG des Rates⁽²⁾ oder gegebenenfalls die spezifischen Verfahren, die entweder zur Konformitätsbewertung oder zur Gebrauchstauglichkeitsbewertung der Interoperabilitätskomponenten sowie zur EG-Prüfung der Teilsysteme verwendet werden müssen — Kapitel 6: Bewertung der Konformität und/oder Gebrauchstauglichkeit der Komponenten und Prüfung des Teilsystems
f): gibt diese TSI die Strategie zur Umsetzung der TSI an. Insbesondere sind die zu erreichenden Phasen festzulegen, damit sich schrittweise ein Übergang vom gegebenen Zustand zum Endzustand, in dem das Einhalten der TSI die Regel ist, ergibt — Kapitel 7: Umsetzung
g): gibt diese TSI für das betreffende Personal die Bedingungen in Bezug auf die berufliche Qualifikation sowie die Arbeitshygiene und Sicherheit am Arbeitsplatz an, die für den Betrieb und die Wartung des betreffenden Teilsystems sowie für die Umsetzung der TSI erforderlich sind — Kapitel 4: Beschreibung des Teilsystems

Darüber hinaus können gemäß Artikel 5 Absatz 5 für jede TSI Sonderfälle vorgesehen werden; sie sind in Kapitel 7.4: Sonderfälle Schließlich umfasst diese TSI in Kapitel 4 (Beschreibung des Teilsystems) ebenfalls die geltenden Betriebs- und Wartungsvorschriften für den Anwendungsbereich, der in den oben stehenden Abschnitten 1.1 (Technischer Anwendungsbereich) und 1.2 (Geografischer Anwendungsbereich) genannt wird.

2.
DEFINITION DES TEILSYSTEMS/ANWENDUNGSBEREICH

2.1.
In der TSI behandelte Funktionen

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

—: Anwendungen im Güterverkehr, einschließlich der Informationssysteme (Verfolgung der Güter und der Züge in Echtzeit);
—: Rangier- und Zugbildungssysteme;
—: Buchungssysteme, wobei hier die Buchung von Zugtrassen gemeint ist;
—: Anschlüsse zu anderen Verkehrsträgern und die Erstellung elektronischer Begleitdokumente.

2.2.
In der TSI nicht behandelte Funktionen

Abrechnungs- und Fakturierungssysteme für Kunden sowie solche Systeme für Abrechnung und Fakturierung zwischen verschiedenen Dienstleistern, wie zum Beispiel Eisenbahnverkehrsunternehmen oder Infrastrukturbetreibern, sind nicht im Umfang dieser TSI enthalten. Das Systemdesign, auf dem der Datenaustausch entsprechend Kapitel 4.2 (Funktionelle und technische Spezifikationen des Teilsystems) beruht, liefert jedoch die zur Abrechnung von Verkehrsleistungen benötigten Informationen. Auch die langfristige Planung von Fahrplänen gehört nicht zum Umfang dieser TSI Telematikanwendungen für den Güterverkehr. Dennoch wird es an einigen Stellen Hinweise auf die Ergebnisse der langfristigen Planung geben, soweit eine Beziehung zum effizienten Informationsaustausch besteht, wie er für den Betrieb der Züge notwendig ist.

2.3.
Übersicht über die Beschreibung des Teilsystems

2.3.1.
Beteiligte Unternehmen

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

—: Wagen
—: Lokomotiven
—: Triebfahrzeugführer
—: Weichenstellen und Rangieren über Ablaufberg
—: Trassenvertrieb
—: Frachtmanagement
—: Zugbildung
—: Zugbetrieb
—: Zugüberwachung
—: Zugsteuerung
—: Frachtüberwachung
—: Inspektionen und Reparaturen von Wagen und/oder Lokomotiven
—: Zollabfertigung
—: Betrieb von intermodalen Terminals
—: Speditionsmanagement.

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

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

Ausgehend von dieser Definition betrachtet die TSI einen IB als Dienstleister für die Zuweisung der Fahrwege, für die Steuerung/Überwachung der Züge und für das zug-/trassenbezogene Meldewesen. Entsprechend der Richtlinie 2001/14/EG ist die Einrichtung oder das Unternehmen, der bzw. dem der IB eine Zugtrasse zuweist, als Antragsteller definiert.

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

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

Ausgehend von dieser Definition betrachtet die TSI ein EVU als Dienstleister für den Betrieb von Zügen. Hinsichtlich der Zuweisung von Zugtrassen für den Betrieb eines Zuges ist auch die Definition aus Artikel 13 der Richtlinie 2001/14/EG zu berücksichtigen:

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

Was die Szenarien der Kommunikation zwischen Infrastrukturbetreibern und Antragstellern in der Ausführungsphase eines Transports betrifft, brauchen nur der IB und das EVU berücksichtigt zu werden und nicht alle Arten von Antragstellern, was für die Planungsphase jedoch von Bedeutung sein kann. In der Ausführungsphase ist stets eine definierte Beziehung IB — EVU gegeben, für die der Meldungsaustausch und die Informationsspeicherung in dieser TSI spezifiziert sind. Die Definition eines Antragstellers und die sich daraus ergebenden Möglichkeiten der Fahrwegzuweisung bleiben hiervon unberührt. Wie bereits erwähnt, müssen für einen Gütertransport verschiedene Dienste bereitgestellt werden. Einer ist zum Beispiel die Bereitstellung von Güterwagen. Dieser Dienst kann in Beziehung mit einem Fuhrparkbetreiber gesetzt werden. Wenn dieser Dienst für einen Transport zum Leistungsangebot eines EVU gehört, fungiert das EVU gleichzeitig als Fuhrparkbetreiber. Ein Fuhrparkbetreiber kann wiederum seine eigenen Wagen und/oder die Wagen eines anderen Halters (ein weiterer Dienstanbieter für Güterwagen) verwalten. Die Notwendigkeiten dieser Art Dienstleister sind berücksichtigt, unabhängig davon, ob die juristische Person des Fuhrparkbetreibers ein EVU ist oder nicht. Diese TSI schafft keine neuen juristischen Personen und zwingt ein EVU nicht zur Einbindung externer Dienstleister für Dienste, die es selbst anbietet; aber sie benennt, soweit erforderlich, einen Dienst mit dem Namen eines entsprechenden Dienstleisters. Wenn der Dienst von einem EVU angeboten wird, fungiert das EVU als Dienstleister für diesen Dienst. Bei der Berücksichtigung von Kundenbedürfnissen besteht einer der Dienste in der Organisation und dem Management der Transportstrecke entsprechend den Zusagen gegenüber dem Kunden. Dieser Dienst wird vom „Federführenden Eisenbahnverkehrsunternehmen” (FEVU) erbracht. Das FEVU ist die alleinige Kontaktstelle für den Kunden. Wenn mehrere EVU an der Transportkette beteiligt sind, ist das FEVU auch für die Koordination mit den anderen EVU zuständig. Dieser Dienst kann auch von einem Spediteur oder einem anderen Unternehmen übernommen werden. Die Mitwirkung eines EVU als FEVU kann sich von einem Transportablauf zum anderen unterscheiden. Im kombinierten Verkehr kann die Verwaltung der Kapazität in Blockzügen und die Erstellung von Frachtbriefen in den Händen eines Intermodaldienstintegrators liegen, der dann der Kunde des FEVU sein könnte. Der wichtigste Punkt ist jedoch, dass die EVU, die IB und alle anderen Dienstleister (im Sinne der obigen Definitionen) zusammenarbeiten müssen, sowohl im Rahmen einer Kooperation und/oder auch beim freien Netzzugang als auch durch effizienten Informationsaustausch, um dem Kunden nahtlose Dienste bieten zu können.

2.3.2.
Betrachtete Prozesse

Diese TSI für den Eisenbahngüterverkehr beschränkt sich laut Richtlinie 2001/16/EG auf IB und EVU/FEVU mit Bezug auf ihre direkten Kunden. Bei der Ausführung der Dienstleistungen für den Güterverkehr beginnt die Tätigkeit eines FEVU im Hinblick auf eine Ladung mit dem Erhalt des Frachtbriefs von seinem Kunden und, zum Beispiel für Wagenladungen, mit dem Freigabezeitpunkt der Wagen. Das FEVU erstellt einen vorläufigen Tourenplan (aufgrund seiner Erfahrungen und/oder des Vertrags) für die Transportfahrt. Wenn das FEVU beabsichtigt, die Wagenladung in einem Zug im Rahmen des freien Netzzugangs (das FEVU betreibt den Zug über die gesamte Fahrt) selbst zu transportieren, ist der vorläufige Tourenplan per se auch der endgültige. Wenn das FEVU beabsichtigt, die Wagenladung in einen Zug einzustellen, der die Kooperation mit anderen EVU verlangt, muss es zunächst herausfinden, welche EVU zu kontaktieren sind und zu welcher Zeit ein Wechsel zwischen zwei benachbarten EVU erfolgen kann. Das FEVU erstellt dann die vorläufigen Beförderungsaufträge für jedes EVU als Teilformular des vollständigen Frachtbriefs. Die Beförderungsaufträge sind im Kapitel 4.2.1 (Frachtbriefdaten) spezifiziert. Die angesprochenen EVU prüfen die Verfügbarkeit von Ressourcen für den Betrieb der Wagen und die Verfügbarkeit der Zugtrasse. Die Antworten von den verschiedenen EVU geben dem FEVU die Möglichkeit, den Tourenplan zu überarbeiten oder — vielleicht sogar bei anderen EVU — die Anfrage neu zu starten, bis der Tourenplan den Erfordernissen des Kunden gerecht wird. Die EVU/FEVU müssen generell mindestens die Kompetenzen besitzen zum:

—: DEFINIEREN von Dienstleistungen bezüglich Preisen und Transitzeiten, Wagenbereitstellung (soweit zutreffend), Angaben zu Wagen/Intermodaleinheiten (Standort, Status und voraussichtliche Ankunftszeit (PAZ) des Wagens/der Intermodaleinheit), wo Fracht auf leere Wagen, Container verladen werden kann etc.;
—: ERBRINGEN der definierten Leistung auf zuverlässige, reibungslose Art durch Einsatz gemeinsamer Geschäftsprozesse und vernetzter Systeme. Es muss eine Möglichkeit bestehen, dass EVU, IB sowie andere Dienstleister und Beteiligte, wie z. B. der Zoll, Informationen auf elektronischem Weg austauschen können;
—: MESSEN der Qualität der erbrachten Dienstleistung im Vergleich zu vorab getroffenen Festlegungen, z. B. Abrechnungsgenauigkeit im Vergleich zum angebotenen Preis, tatsächliche Transitzeiten im Vergleich zu zugesagten Zeiten, bestellte Wagen im Vergleich zu bereitgestellten, vorhergesagten Ankunftszeiten (PAZ) im Vergleich zu tatsächlichen Ankunftszeiten;
—: BETREIBEN im Sinne einer produktiven Nutzung von Zug-, Infrastruktur- und Flottenkapazität durch den Einsatz von Geschäftsprozessen, Systemen und Datenaustausch, wie sie zur Unterstützung des Wagens/der Intermodaleinheit und des Zugfahrplans erforderlich sind.

Die EVU/FEVU in ihrer Eigenschaft als „Antragsteller” müssen (durch Verträge mit den IB) auch die benötigte Zugtrasse bereitstellen und den Zug auf ihrem jeweiligen Fahrtabschnitt betreiben. Für die Zugtrasse können sie bereits (in der Planungsphase) gebuchte Trassen verwenden, oder sie müssen bei den Infrastrukturbetreibern (IB) eine Ad-Hoc-Trasse für den jeweiligen Fahrtabschnitt, auf dem das EVU den Zug betreibt, beantragen. Im Anhang A Ziffer 5 Kapitel 1.2 wird ein Beispiel für das Szenario der Trassenanforderung gegeben. Der Trassenbesitz ist auch für die Kommunikation zwischen EVU und IB während der Zugfahrt von Bedeutung. Die Kommunikation während der Zugfahrt zwischen EVU und IB muss immer auf der Zugnummer und der Trassennummer basieren, wobei der IB mit dem EVU kommuniziert, das die Zugtrasse auf seiner Infrastruktur gebucht hat (siehe auch Anhang A Index 5 Kapitel 1.2). Falls ein EVU die gesamte Fahrt A-F anbietet (Offener Netzzugang durch ein EVU, keine anderen EVU beteiligt), kommuniziert jeder beteiligte IB direkt nur mit diesem EVU. Dieser „offene Netzzugang” durch das EVU lässt sich realisieren, indem die Zugtrasse über einen „One-Stop-Shop (OSS)” oder in einzelnen Abschnitten direkt bei den jeweiligen IB gebucht wird. Die TSI berücksichtigt beide Fälle, wie in Kapitel 4.2.2.1 (Beantragung einer Trasse) gezeigt wird. Der Dialogprozess zwischen EVU und IB zur Einrichtung einer Zugtrasse für einen Güterzug ist in Kapitel 4.2.2 (Beantragung einer Trasse) definiert. Diese Funktion bezieht sich auf Artikel 23 Absatz 1 der Richtlinie 2001/14/EG. Nicht zum Dialogprozess gehören die Beantragung einer Zulassung für ein EVU, das seine Dienste gemäß Richtlinie 2001/13/EG des Europäischen Parlaments und des Rates⁽³⁾ anbietet, die Zertifizierung gemäß Richtlinie 2001/14/EG und die Zugangsrechte gemäß Richtlinie 91/440/EWG des Rates⁽⁴⁾. Kapitel 4.2.3 (Zugvorbereitung) definiert den Informationsaustausch hinsichtlich der Zugbildung und des Verfahrens bei der Zugabfahrt. Der Datenaustausch während der Zugfahrt im Fall des Normalbetriebs ist in Kapitel 4.2.4 (Prognose zur Zugfahrt) beschrieben; die Meldungen für Ausnahmefälle sind in Kapitel 4.2.5 (Information über Verkehrsunterbrechung) definiert. Informationen zur Standortverfolgung der Züge sind in Kapitel 4.2.6 (Abfragen zum Zugstandort) definiert. Alle diese Meldungen werden zwischen EVU und IB ausgetauscht und basieren auf Zügen. Für einen Kunden jedoch ist die wichtigste Information immer die voraussichtliche Ankunftszeit (PAZ) seiner Sendung. Eine PAZ lässt sich aus dem Informationsaustausch zwischen FEVU und IB (im Fall des offenen Zugangs) berechnen. Im Fall des Kooperationsmodus mit verschiedenen EVU lassen sich PAZ und ebenso die voraussichtlichen Wagenübergangszeiten (PÜZ) aus dem Meldungsaustausch zwischen EVU und IB und deren Weiterleitung von den EVU an das FEVU berechnen (Kapitel 4.2.7 Ladung PÜZ/PAZ). Ebenfalls abgeleitet aus dem Informationsaustausch zwischen IB und EVU weiß das FEVU beispielsweise:

—: wann die Wagen einen Rangierbahnhof oder einen definierten Standort verlassen oder erreicht haben (Kapitel 4.2.8 Berichtswesen Wagenbewegung
—: wann in der Transportkette die Verantwortung für die Wagen von einem EVU auf das nächste EVU übergegangen ist (Kapitel 4.2.9 Berichtswesen Wagenübergang

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

—: zur — mittelfristig — detaillierteren Planung des Produktionsprozesses und
—: zur — auf lange Sicht — Durchführung strategischer Planungsübungen und Kapazitätsstudien (z. B. Netzanalysen, Festlegung von Abstellgleisen und Rangierbahnhöfen, Fahrzeugplanung), aber vor allem
—: zur Verbesserung der Transportqualität und Produktivität (Kapitel 4.2.10 (Datenaustausch zur Qualitätsverbesserung).

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

2.3.3.
Allgemeine Anmerkungen

Ein Informationssystem ist nur so gut wie die Zuverlässigkeit seiner Daten. Daher müssen die Daten, die eine entscheidende Rolle beim Transport einer Sendung, eines Wagens oder eines Containers spielen, genau stimmen, und sie müssen möglichst wirtschaftlich erfasst werden, was bedeutet, dass die Daten möglichst nur ein einziges Mal in das System eingegeben werden sollten. Auf dieser Grundlage vermeiden daher die Anwendungen und Meldungen in dieser TSI die mehrfache manuelle Dateneingabe, indem sie auf bereits gespeicherte Daten, z. B. auf die Fahrzeugreferenzdaten, zurückgreifen. Die Anforderungen an die Fahrzeugreferenzdaten sind in Kapitel 4.2.11 (Die Hauptreferenzdaten) definiert. Die spezifizierten Datenbanken der Fahrzeugreferenzdaten müssen einen einfachen Zugriff auf die technischen Daten gestatten. Der Inhalt der Datenbanken muss auf der Basis strukturierter Zugriffsrechte in Abhängigkeit von Privilegien für alle IB, EVU und Fuhrparkbetreiber zugänglich sein, insbesondere zum Zwecke des Flottenmanagements und der Fahrzeuginstandhaltung. Sie müssen alle transportkritischen technischen Daten enthalten, wie z. B.:

—: Identifizierung des Fahrzeugs,
—: Technische/Konstruktionsdaten,
—: Bewertung der Kompatibilität mit der Infrastruktur,
—: Bewertung der relevanten Beladungsmerkmale,
—: Bremsrelevante Merkmale,
—: Instandhaltungsdaten,
—: Umwelteigenschaften.

Im intermodalen Transport wird ein Wagen an verschiedenen Punkten (so genannten „Gateways” ) nicht nur an einen anderen Zug gehängt, sondern die Intermodaleinheit kann auch von einem Wagen auf einen anderen umgeladen werden. Folglich reicht es nicht aus, nur mit einem Tourenplan für Wagen zu arbeiten, sondern es muss auch ein Tourenplan für die Intermodaleinheiten erstellt werden. In Kapitel 4.2.12 (Diverse Referenzdateien und Datenbanken) sind diverse Referenzdateien und Datenbanken aufgeführt, darunter die Betriebsdatenbank für Wagen und Intermodaleinheiten. Diese Datenbank enthält die betrieblichen Statusdaten des Fahrzeugs, Informationen über Gewicht und über gefährliche Güter, Informationen bezüglich der Intermodaleinheiten und die Standortinformation. Im Kapitel 4.2.13 (Elektronische Übertragung von Dokumenten) sind die Anforderungen an die elektronische Übertragung der Dokumente definiert. Die TSI für das Teilsystem Telematikanwendungen für den Güterverkehr definiert die benötigten Informationen, die zwischen den verschiedenen an der Transportkette beteiligten Partnern ausgetauscht werden müssen, und gestattet die Einrichtung eines standardisierten, verbindlichen Prozesses für den Datenaustausch. Sie zeigt außerdem die Architekturstrategie für eine solche Kommunikationsplattform. Dies ist in Kapitel 4.2.14 (Vernetzung und Kommunikation) skizziert, unter Berücksichtigung:

—: der Schnittstelle zum Teilsystem Betrieb und Verkehrssteuerung des transeuropäischen konventionellen Eisenbahnsystems, auf das in Artikel 5 Absatz 3 der Richtlinie 2001/16/EG Bezug genommen wird;
—: der Anforderungen an den Inhalt der Schienennetz-Nutzungsbedingungen, die in Richtlinie 2001/14/EG, Artikel 3 und Anhang I genannt sind;
—: der zu einem Güterwagen verfügbaren Informationen und der Instandhaltungsanforderungen aus der TSI „Fahrzeuge” .

Es besteht keine direkte Datenübertragung aus dem Teilsystem Telematikanwendungen für den Güterverkehr in das Fahrzeug, zum Fahrer oder zu Teilen des Teilsystems „Zugsteuerung, Zugsicherung und Signalgebung” , und das physikalische Übertragungsnetz ist vollkommen unabhängig von dem, welches vom Teilsystem „Zugsteuerung, Zugsicherung und Signalgebung” genutzt wird. Das ERTMS/ETCS-System benutzt GSM-R. Für dieses offene Netz stellen die ETCS-Spezifikationen klar, dass die Sicherheit mittels des entsprechenden Managements der Risiken bei offenen Netzen im Euroradio-Protokoll erreicht wird. Die Schnittstellen zu den strukturellen Teilsystemen „Fahrzeug” und „Zugsteuerung, Zugsicherung und Signalgebung” sind nur über die Datenbanken der Fahrzeugreferenzdaten gegeben (Kapitel 4.2.11.3: Die Fahrzeugreferenzdatenbanken), welche der Kontrolle der Fahrzeughalter unterliegen. Die Schnittstellen zu den Teilsystemen „Infrastruktur” , „Zugsteuerung, Zugsicherung und Signalgebung” und „Energie” sind über die Festlegung der Trasse (Kapitel 4.2.2.3: Trassendetails) vom IB vorgegeben, womit die schienennetzbezogenen Werte für den Zug festgelegt sind, und über die Information, die die IB bezüglich Beschränkungen in der Infrastruktur bereitstellen (Kapitel 4.2.11.2: Die Datenbank für Mitteilungen der Infrastrukturbeschränkungen).

3.
GRUNDLEGENDE ANFORDERUNGEN

3.1.
Einhaltung der grundlegenden Anforderungen

Laut Artikel 4 Absatz 1 der Richtlinie 2001/16/EG müssen das konventionelle transeuropäische Eisenbahnsystem, die Teilsysteme und ihre Interoperabilitätskomponenten die grundlegenden Anforderungen, die in allgemeiner Form in Anhang III der Richtlinie dargestellt sind, einhalten. Im Anwendungsbereich der vorliegenden TSI wird die Erfüllung der entsprechenden grundlegenden Anforderungen, die in Kapitel 3 dieser TSI genannt sind, für das Teilsystem durch die Einhaltung der in Kapitel 4 (Beschreibung des Teilsystems) beschriebenen Spezifikationen gewährleistet.

3.2.
Aspekte der grundlegenden Anforderungen

Die grundlegenden Anforderungen betreffen:

—: Sicherheit,
—: Zuverlässigkeit und Betriebsbereitschaft,
—: Gesundheit,
—: Umweltschutz,
—: Technische Kompatibilität.

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

3.3.
Allgemeine Anforderungen

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

3.3.1.
Sicherheit

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

—

Grundlegende Anforderung 1.1.1 laut Anhang III der Richtlinie 2001/16/EG:

„Die Planung, der Bau oder die Herstellung, die Instandhaltung und die Überwachung der sicherheitsrelevanten Bauteile, insbesondere derjenigen, die am Zugverkehr beteiligt sind, müssen die Sicherheit auch unter bestimmten Grenzbedingungen auf dem für das Netz festgelegten Niveau halten.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.1.2 laut Anhang III der Richtlinie 2001/16/EG:

„Die Kennwerte für das Rad-Schiene-System müssen die Kriterien der Laufstabilität erfüllen, damit bei der zulässigen Höchstgeschwindigkeit eine sichere Fahrt gewährleistet ist.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.1.3 laut Anhang III der Richtlinie 2001/16/EG:

„Die verwendeten Bauteile müssen während ihrer gesamten Betriebsdauer den spezifizierten gewöhnlichen oder Grenzbeanspruchungen standhalten. Durch geeignete Mittel ist sicherzustellen, dass sich die Sicherheitsauswirkungen eines unvorhergesehenen Versagens in Grenzen halten.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.1.4 laut Anhang III der Richtlinie 2001/16/EG:

„Die Auslegung der ortsfesten Anlagen und der Fahrzeuge und die Auswahl der Werkstoffe müssen das Entstehen, die Ausbreitung und die Auswirkungen von Feuer und Rauch im Fall eines Brandes in Grenzen halten.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.1.5 laut Anhang III der Richtlinie 2001/16/EG:

„Die für die Betätigung durch die Fahrgäste vorgesehenen Einrichtungen müssen so konzipiert sein, dass das sichere Funktionieren der Einrichtungen oder die Gesundheit und Sicherheit der Benutzer nicht beeinträchtigt werden, wenn sie in einer voraussehbaren Weise betätigt werden, die den angebrachten Hinweisen nicht entspricht.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

3.3.2.
Zuverlässigkeit und Betriebsbereitschaft

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

Dieser grundlegenden Anforderung wird in den folgenden Kapiteln Rechnung getragen:

Kapitel 4.2.11: Die Hauptreferenzdaten,

Kapitel 4.2.12: Diverse Referenzdateien und Datenbanken,

Kapitel 4.2.14: Vernetzung und Kommunikation.

3.3.3.
Gesundheit

—

Grundlegende Anforderung 1.3.1 laut Anhang III der Richtlinie 2001/16/EG:

„Werkstoffe, die aufgrund ihrer Verwendungsweise die Gesundheit von Personen, die Zugang zu ihnen haben, gefährden können, dürfen in Zügen und Infrastruktureinrichtungen nicht verwendet werden.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.3.2 laut Anhang III der Richtlinie 2001/16/EG:

„Die Auswahl, die Verarbeitung und die Verwendung dieser Werkstoffe müssen eine gesundheitsschädliche oder -gefährdende Rauch- und Gasentwicklung insbesondere im Fall eines Brandes in Grenzen halten.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

3.3.4.
Umweltschutz

—

Grundlegende Anforderung 1.4.1 laut Anhang III der Richtlinie 2001/16/EG:

„Die Umweltauswirkungen des Baus und Betriebs des konventionellen transeuropäischen Eisenbahnsystems sind bei der Planung dieses Systems entsprechend den geltenden Gemeinschaftsbestimmungen zu berücksichtigen.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.4.2 laut Anhang III der Richtlinie 2001/16/EG:

„In Zügen und Infrastruktureinrichtungen verwendete Werkstoffe müssen eine umweltschädliche oder -gefährdende Rauch- und Gasentwicklung insbesondere im Fall eines Brandes verhindern.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.4.3 laut Anhang III der Richtlinie 2001/16/EG:

„Fahrzeuge und Energieversorgungsanlagen sind so auszulegen und zu bauen, dass sie mit Anlagen, Einrichtungen und öffentlichen oder privaten Netzen, bei denen Interferenzen möglich sind, elektromagnetisch verträglich sind.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.4.4 laut Anhang III der Richtlinie 2001/16/EG:

„Beim Betrieb des konventionellen transeuropäischen Eisenbahnsystems müssen die vorgeschriebenen Lärmgrenzen eingehalten werden.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

—

Grundlegende Anforderung 1.4.5 laut Anhang III der Richtlinie 2001/16/EG:

„Der Betrieb des konventionellen transeuropäischen Eisenbahnsystems darf in normalem Instandhaltungszustand für die in der Nähe des Fahrwegs gelegenen Einrichtungen und Bereiche keine unzulässigen Bodenschwingungen verursachen.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

3.3.5.
Technische Kompatibilität

—

Grundlegende Anforderung 1.5 laut Anhang III der Richtlinie 2001/16/EG:

„Die technischen Merkmale der Infrastrukturen und ortsfesten Anlagen müssen untereinander und mit denen der Züge, die im konventionellen transeuropäischen Eisenbahnsystem verkehren sollen, kompatibel sein. Erweist sich die Einhaltung dieser Merkmale auf bestimmten Teilen des Netzes als schwierig, so könnten Zwischenlösungen, die eine künftige Kompatibilität gewährleisten, eingeführt werden.”

Diese grundlegende Anforderung ist für das Teilsystem Telematikanwendungen für den Güterverkehr nicht relevant.

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

3.4.1.
Technische Kompatibilität

—

Grundlegende Anforderung 2.7.1 laut Anhang III der Richtlinie 2001/16/EG:

Die grundlegenden Anforderungen für den Bereich der Telematikanwendungen, die eine Mindestqualität der Dienstleistung für die Reisenden und die Güterverkehrskunden gewährleisten, betreffen insbesondere die technische Kompatibilität.

Bei diesen Anwendungen ist sicherzustellen,

—: dass die Datenbanken, die Software und die Datenübertragungsprotokolle so erstellt werden, dass ein möglichst vielfältiger Datenaustausch zwischen verschiedenen Anwendungen und zwischen verschiedenen Betreibern gewährleistet ist, wobei vertrauliche Geschäftsdaten hiervon ausgeschlossen sind,
—: dass die Benutzer einen leichten Zugriff zu den Informationen haben.

Dieser grundlegenden Anforderung wird in den folgenden Kapiteln Rechnung getragen:

Kapitel 4.2.11: Die Hauptreferenzdaten,

Kapitel 4.2.12: Diverse Referenzdateien und Datenbanken,

Kapitel 4.2.14: Vernetzung und Kommunikation.

3.4.2.
Zuverlässigkeit und Betriebsbereitschaft

—

Grundlegende Anforderung 2.7.2 laut Anhang III der Richtlinie 2001/16/EG:

„Die Methoden der Nutzung, Verwaltung, Aktualisierung und Pflege dieser Datenbanken, Software und Datenübertragungsprotokolle müssen die Effizienz der Systeme und die Leistungsqualität gewährleisten.”

Dieser grundlegenden Anforderung wird in den folgenden Kapiteln Rechnung getragen:

Kapitel 4.2.11: Die Hauptreferenzdaten,

Kapitel 4.2.12: Diverse Referenzdateien und Datenbanken,

Kapitel 4.2.14: Vernetzung und Kommunikation.

Diese grundlegende Anforderung, insbesondere die Methode der Nutzung, um die Wirksamkeit dieser Telematikanwendungen und die Qualität des Dienstes zu garantieren, ist das grundlegende Element, das sich über die gesamte TSI erstreckt und nicht nur auf die oben erwähnten Kapitel beschränkt ist.

3.4.3.
Gesundheit

—

Grundlegende Anforderung 2.7.3 laut Anhang III der Richtlinie 2001/16/EG:

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

Diese TSI spezifiziert keinerlei zusätzliche Anforderungen zu nationalen und europäischen Regeln in Bezug auf Mindestregeln für Ergonomie und Gesundheitsschutz an der Schnittstelle zwischen dieser TSI und den Anwendern.

3.4.4.
Sicherheit

—

Grundlegende Anforderung 2.7.4 laut Anhang III der Richtlinie 2001/16/EG:

„Im Hinblick auf die Speicherung oder Übertragung sicherheitsrelevanter Daten ist für angemessene Integrität und Zuverlässigkeit zu sorgen.”

Dieser grundlegenden Anforderung wird in den folgenden Kapiteln Rechnung getragen:

Kapitel 4.2.11: Die Hauptreferenzdateien,

Kapitel 4.2.12: Diverse Referenzdateien und Datenbanken,

Kapitel 4.2.14: Vernetzung und Kommunikation.

4.
BESCHREIBUNG DES TEILSYSTEMS

4.1.
Einführung

Das konventionelle transeuropäische Eisenbahnsystem, für das die Richtlinie 2001/16/EG gilt und zu dem das Teilsystem gehört, ist ein integriertes System, dessen Einheitlichkeit geprüft werden muss. Diese Einheitlichkeit muss besonders in Bezug auf die Spezifikationen des Teilsystems, seine Schnittstellen mit dem System, in das es integriert wird, sowie die Betriebs- und Wartungsvorschriften geprüft werden. Unter Berücksichtigung aller anwendbaren grundlegenden Anforderungen ist das Teilsystem Telematikanwendungen für den Güterverkehr gekennzeichnet durch:

4.2.
Funktionelle und technische Spezifikationen zum Teilsystem

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

—: Frachtbriefdaten,
—: Trassenantrag,
—: Zugvorbereitung,
—: Zugfahrtprognose,
—: Verkehrsunterbrechungsinformationen,
—: Zugstandort,
—: Wagen/Intermodaleinheit PÜZ/PAZ,
—: Wagenbewegung,
—: Wagenübergangsmeldungen,
—: Datenaustausch zur Qualitätsverbesserung,
—: Die Hauptreferenzdaten,
—: Diverse Referenzdateien und Datenbanken,
—: Elektronische Übertragung von Dokumenten,
—: Vernetzung und Kommunikation.

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

Allgemeine Anmerkungen zur Meldungsstruktur:

Die Meldungen sind in zwei Datengruppen strukturiert:

—: Kontrolldaten: Erläuterung nachfolgend
—: Informationsdaten: die Nutzinformation

Die Kontrolldaten zeigen folgende Elemente auf:

—

Status: Der Status einer Meldung kann sein:

„Neue Meldung” , falls dies eine neue Meldung ist,

„Änderung” , falls dies die Modifizierung einer vorhergehenden Meldung ist,

„Löschung” , falls die früher gesendete Meldung gelöscht werden soll.

—

Meldungsreferenz mit:

Meldungstyp: z. B. „Trassenantrag” oder „Abfrage zur Zugfahrt” ,

Datum und Uhrzeit: Datum und Uhrzeit, zu der die Meldung gesendet wurde,

Meldungsnummer: Nummer, die vom Sender der Meldung generiert wird.

—

Bezugsreferenz, nur wenn die Meldung die Antwort auf eine früher erhaltene Meldung ist (identisch zur Meldungsreferenz der erhaltenen Meldung) mit:

Bezugstyp: Typ der erhaltenen Meldung,

Bezugsdatum und -uhrzeit: Datum und Uhrzeit der erhaltenen Meldung,

Bezugsnummer: Nummer der erhaltenen Meldung.

—

Sender der Meldung

—

Empfänger der Meldung

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

4.2.1.
Frachtbriefdaten

Der Frachtbrief ist vom Kunden an das „Federführende EVU (FEVU)” zu schicken. Er muss alle Informationen enthalten, die für den Transport der Fracht vom Absender zum Empfänger erforderlich sind. Das FEVU muss diese Daten um zusätzliche Angaben ergänzen. Diese Daten einschließlich der Zusatzangaben (ausführliche Beschreibung siehe Anhang A — Anlagen A, B und F sowie Anlage B Anhang 1) sind in der Tabelle in Anhang A — Anlage B Anhang 1 — aufgelistet; in der Spalte „Daten im Frachtbrief” ist angegeben, ob es sich um obligatorische oder optionale Angaben handelt und ob diese vom Absender bereitzustellen oder vom FEVU zu ergänzen sind. Im Fall des „offenen Netzzugangs” stehen dem FEVU, das den Vertrag mit dem Kunden schließt, nach der Ergänzung alle erforderlichen Angaben zur Verfügung. Es ist kein Meldungsaustausch mit anderen EVU erforderlich. Diese Daten sind auch die Grundlage für einen kurzfristigen Trassenantrag, wenn dies zur Ausführung des Frachtauftrags erforderlich ist. Die folgenden Meldungen gelten für den Fall des „nicht offenen Netzzugangs” . Der Inhalt dieser Meldungen ist auch die Basis für kurzfristige Trassenanträge, wenn dies zur Ausführung des Frachtauftrags erforderlich ist. Der Beförderungsauftrag ist im Wesentlichen eine Teilmenge der Frachtbriefinformation. Er muss an die EVU, die an der Transportkette beteiligt sind, weitergeleitet werden, da er die Grundlage für einen eventuellen Ad-hoc-Trassenantrag bildet (Kapitel 4.2.2: Beantragung einer Trasse). Der Inhalt des Beförderungsauftrages muss alle relevanten Informationen umfassen, die ein EVU für den Transport unter seiner Verantwortung bis zur Übergabe auf das nächste EVU benötigt. Der Inhalt richtet sich daher nach der Rolle des EVU: Ursprungs-, Transit- oder Auslieferungs-EVU in der Transportkette (UEVU, TEVU, AEVU).

—: Beförderungsauftrag für das Ursprungs-Eisenbahnverkehrsunternehmen (UEVU),
—: Beförderungsauftrag für das Transit-Eisenbahnverkehrsunternehmen (TEVU),
—: Beförderungsauftrag für das Auslieferungs-Eisenbahnverkehrsunternehmen (AEVU).

Die Daten der Beförderungsaufträge entsprechend den verschiedenen Rollen eines EVU sind im Einzelnen in Anhang A — Anlagen A und B sowie in Anlage B Anhang 1 — aufgelistet; es ist jeweils angegeben, ob die Daten obligatorisch oder optional sind. Die ausführlichen Formate dieser Meldungen sind in Anhang A Anlage F definiert. Hauptinhalt dieser Beförderungsaufträge sind:

—: Absender- und Empfängerangaben,
—: Streckenverlauf,
—: Ladungsidentifikation,
—: Wageninformation,
—: Orts- und Zeitangaben.

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

—: Ladungsgewicht (Bruttogewicht der Ladung),
—: CN/HS-Nummer,
—: Gefahrgutangaben,
—: Transporteinheit.

4.2.2.
Beantragung einer Trasse

Die Zugtrasse definiert die beantragten, die akzeptierten und die tatsächlichen Daten, die bezüglich einer Zugtrasse und der Zugmerkmale auf den einzelnen Abschnitten einer Trasse zu speichern sind. Die folgende Beschreibung gibt die Informationen wieder, die dem Infrastrukturbetreiber zur Verfügung stehen müssen. Bezüglich einer ausführlicheren Beschreibung siehe Anhang A Anlage F. Diese Informationen müssen bei jeder Veränderung aktualisiert werden. Die wichtigsten Trassendaten sind (obligatorisch):

—

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

—

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

—

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

—

Beschreibung des Fahrtabschnitts. Sie definiert die Daten, die vom IB für jeden akzeptierten Fahrtabschnitt bereitzustellen sind — vom Start bis zum ersten Zwischenhalt, zwischen den Zwischenhalten und vom letzten Zwischenhalt bis zum Ende der akzeptierten Fahrt. Die Beschreibung kann umfassen:

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

Ausführungsphase Trassenvertrag: Vor der Zugfahrt müssen die Daten des Fahrtabschnitts aktualisiert und mit Istwerten ergänzt werden. Die Ausführungsphase ist unabhängig von der Planungsphase. Bei Ausnahmesituationen im Zugbetrieb oder kurzfristigen Transportwünschen muss ein Eisenbahnverkehrsunternehmen die Möglichkeit haben, eine Ad-hoc-Trasse im Netz zu erhalten. Im ersten Fall müssen Sofortmaßnahmen eingeleitet werden, wobei die tatsächliche Zugkonfiguration aufgrund der Zugbildungsliste bekannt ist. Im zweiten Fall muss das Eisenbahnverkehrsunternehmen dem Infrastrukturbetreiber alle notwendigen Informationen liefern, die angeben, wann und wo der Zug eingesetzt werden soll und über welche physischen Merkmale der Zug verfügt, sofern diese mit der Infrastruktur interagieren. Diese Daten sind hauptsächlich im ergänzten Frachtbrief beziehungsweise in den Beförderungsaufträgen enthalten. Der Trassenvertrag für eine kurzfristige Zugbewegung beruht auf einem Dialog zwischen EVU und IB. Der Dialog schließt alle EVU und IB ein, die an der Zugbewegung entlang der gewünschten Strecke beteiligt sind, jedoch möglicherweise mit unterschiedlichen Beiträgen bei der Trassenfindung. Nach Artikel 13 der Richtlinie 2001/14/EG können im Wesentlichen zwei allgemein gültige Szenarien für den Güterverkehr auf den Infrastrukturen mehrerer IB unterschieden werden (siehe auch Anhang A Ziffer 5 Kapitel 1.3):

—: Szenario A: Das EVU kontaktiert alle beteiligten IB direkt (Fall A) oder über den OSS (Fall B), um die Trassen für die gesamte Fahrt zu organisieren. In diesem Fall muss das EVU laut Artikel 13 der Richtlinie 2001/14/EG den Zug auch über die gesamte Strecke betreiben.
—: Szenario B: Jedes an der Transportfahrt beteiligte EVU kontaktiert die lokalen IB direkt oder über den OSS und beantragt eine Trasse für den Fahrtabschnitt, auf dem es den Zug betreiben will.

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

In beiden Szenarien verläuft das Buchungsverfahren für einen kurzfristig gestellten Trassenantrag entsprechend dem Dialog zwischen EVU und beteiligtem IB wie auf der nächsten Seite beschrieben. Die folgende Tabelle zeigt die Meldungen, die im Dialog für einen Trassenantrag zu verwenden sind:

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

Dieser Dialog wird vom EVU entweder mit der Meldung „Trasse bestätigt” oder mit Löschen des Trassenantrags beendet (Trassenantrag mit Status „Löschung” , siehe Kapitel 4.2: Funktionelle und technische Spezifikationen zum Teilsystem, Allgemeine Anmerkungen zur Meldungsstruktur). Eine Meldung „Trassendetails abgelehnt” vom EVU muss immer mit einer erneuten Meldung „Trassendetails” beantwortet werden. Wenn der IB den Trassenantrag nicht mit einem neuen Vorschlag innerhalb einer Meldung „Trassendetails” bedienen kann, muss er die Meldung „Trassendetails” mit der Kennung „Keine Alternativen verfügbar” senden, womit der Dialog durch den IB beendet wird. Ganz gleich, ob die Trasse während der langfristigen Planung oder kurzfristig gebucht wurde, das EVU muss stets die Möglichkeit haben, eine gebuchte Trasse zu stornieren. Hierzu muss die folgende Meldung verwendet werden.

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

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

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

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

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

Diese Meldungen werden in den folgenden Abschnitten in ihren wichtigsten Punkten umrissen. Die ausführlichen Formate dieser Meldungen sind im Anhang A Anlage F definiert. Die logische Abfolge dieser Meldungen ist aus den Diagrammen im Anhang A Ziffer 5 Kapitel 2.1 bis 2.3 ersichtlich. Dies ist der Antrag vom EVU an den IB für eine Zugtrasse. Solch ein Antrag muss enthalten:

—

Trassenausgangspunkt: Startpunkt der Trasse,

—

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

—

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

—

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

—

Beantragter Fahrtabschnitt:

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

Als Informationshilfe bei der Formulierung des Trassenantrags können die EVU die entsprechenden Schienennetz-Nutzungsbedingungen zu Rate ziehen, um zu überprüfen, ob die Daten des vorgesehenen Zuges mit den Infrastrukturdaten der gewünschten Trasse harmonieren. Dabei sind auch Angaben über Gefahrgüter und ähnliche Daten zu beachten. Die Wagenhalter müssen den EVU Zugriff auf die technischen Daten der Wagen gewähren. Die EVU ihrerseits müssen den Zugang zu den Referenzdateien, z. B. zur Referenzdatei für Gefahrgüter, sicherstellen. Diese Meldung ist die Antwort eines IB auf den Trassenantrag eines EVU. Wenn der IB den Trassenantrag nicht bedienen kann, muss er diese Meldung mit der Kennung „Keine Alternativen verfügbar” senden. Ansonsten muss der IB den Antrag beantworten, indem er dem EVU eine Trassennummer sendet, zusammen mit denselben Angaben, die im Antrag des EVU enthalten waren, jedoch eventuell mit geänderten Werten. Für eine vom IB vorgeschlagene Alternative müssen folgende Daten gesendet werden:

—

Neue Trassennummer,

—

Trassenausgangspunkt: Startpunkt der Trasse,

—

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

—

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

—

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

—

Geänderter Fahrtabschnitt:

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

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

—: Trassennummer zur Identifizierung der Trasse,
—: Trassenausgangspunkt: Abfahrtsort des Zuges auf der Trasse,
—: Abfahrtsdatum/-zeit am Startpunkt der Trasse: Datum und Uhrzeit, für die die Trasse beantragt wird,
—: Endpunkt der Trasse: Zielort des Zuges auf der beantragten Trasse,
—: Ankunftsdatum/-zeit am Endpunkt der Trasse: Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,
—: Angabe, dass das EVU die vorgeschlagene Trasse akzeptiert.

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

—: Trassennummer zur Identifizierung der Trasse,
—: Angabe, dass die Trassendetails abgelehnt werden,

Als Zusatzinformationen können folgende Daten gesendet werden:

—: Trassenausgangspunkt: Abfahrtsort des Zuges auf der Trasse,
—: Abfahrtsdatum/-zeit am Startpunkt der Trasse: Datum und Uhrzeit, für die die Trasse beantragt wird,
—: Endpunkt der Trasse: Zielort des Zuges auf der beantragten Trasse,
—: Ankunftsdatum/-zeit am Endpunkt der Trasse: Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll.

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

—: Trassennummer zur Identifizierung der Trasse,
—: Zugnummer (wenn sie dem IB bereits bekannt ist),
—: Angabe, dass die gebuchte Trasse storniert werden soll.

Als Zusatzinformationen können folgende Daten gesendet werden:

—: Trassenausgangspunkt: Abfahrtsort des Zuges auf der Trasse,
—: Abfahrtsdatum/-zeit am Startpunkt der Trasse: Datum und Uhrzeit, für die die Trasse beantragt wird,
—: Endpunkt der Trasse: Zielort des Zuges auf der beantragten Trasse,
—: Ankunftsdatum/-zeit am Endpunkt der Trasse: Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll.

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

—: Trassennummer der nicht verfügbaren Trasse,
—: Zugnummer des für die stornierte Trasse vorgesehenen Zuges (falls sie dem IB bereits bekannt ist),
—: Startpunkt sowie Datum und Uhrzeit, für die die Trasse gebucht war,
—: Endpunkt sowie Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen sollte,
—: Angabe, dass die Trasse nicht verfügbar ist,
—: Angabe des Grundes.

Zusammen mit dieser Meldung oder so bald wie möglich danach muss der IB ohne weiteren Antrag des EVU einen Alternativvorschlag schicken. Dies erfolgt mit der Meldung „Trassendetails” mit Bezug auf diese Meldung „Trasse nicht verfügbar” . Diese Information muss vom Empfänger einer Meldung an ihren Absender geschickt werden, wenn die erforderliche Antwort nicht innerhalb des Zeitfensters, wie in Kapitel 4.4 (Betriebsvorschriften) spezifiziert, bereitgestellt werden kann. Die Meldung muss einen Bezug aufweisen, auf den sie sich bezieht (Einträge Datenfeld Bezugsmeldung, siehe Kapitel 4.2: Funktionelle und technische Spezifikationen zum Teilsystem, Allgemeine Anmerkungen zur Meldungsstruktur) sowie die Angabe: (Anwendungsebene)

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

4.2.3.
Zugvorbereitung

Dieser Abschnitt definiert die Meldungen, die beim Normalbetrieb des Zuges, wenn keinerlei Unterbrechungen auftreten, ausgetauscht werden müssen. Die Meldungen sind in Tabelle 5 zusammengefasst. Für die Zugvorbereitung benötigt das EVU Zugang zu Mitteilungen über Infrastrukturbeschränkungen, zu den technischen Daten der Wagen (in den Datenbanken der Fahrzeugreferenzdaten für die Wagen, Kapitel 4.2.11.3: Die Fahrzeugreferenzdatenbanken), zur Referenzdatei über Gefahrgüter und zu aktuellen Statusangaben der Wagen (Kapitel 4.2.12.2: Weitere Datenbanken: Betriebsdatenbank für Wagen- und Intermodaleinheiten). Dies gilt für alle Wagen im Zug. Am Ende muss das EVU die Zugbildungsinformationen an die nächsten EVU senden. Diese Meldung muss ebenfalls vom EVU an die IB gesendet werden, bei denen es einen Trassenabschnitt gebucht hat, wenn dies in der TSI „Betrieb und Verkehrssteuerung des konventionellen Eisenbahnsystems” oder in den Verträgen zwischen dem EVU und (den) IB gefordert wird. Falls die Zugbildung an einem Ort geändert wird, muss diese Meldung mit den vom zuständigen EVU aktualisierten Angaben erneut ausgetauscht werden. An jedem Ort, z. B. Abfahrtsort und Wagenübergangspunkt, an dem die Verantwortlichkeit auf Seiten der EVU wechselt, ist der Dialog für die Startprozedur „Zug fertig — Zugfahrtmeldung” zwischen IB und EVU verbindlich vorgeschrieben (obligatorisch). Bei diesem Dialog der Startprozedur kommen folgende Meldungen zum Einsatz:

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

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

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

—: Zugnummer und Trassennummer zur Identifizierung der Trasse,
—: Startpunkt auf der Trasse sowie Datum und Uhrzeit, für die die Trasse gebucht wurde,
—: Zielpunkt auf der Trasse sowie Datum und Uhrzeit, zu der der Zug an seinem Ziel ankommen soll,
—: Kennung der Lokomotive(n) und Position der Lokomotive(n) im Zug,
—: Zuglänge, Zuggewicht, max. Zuggeschwindigkeit,
—: Zugbildung mit Reihenfolge der Fahrzeugkennungen,
—: Zugsteuerungs-/Zugsicherungssystem einschließlich Art der Funkausrüstung,
—: Informationen über außergewöhnliches Lichtraumprofil,
—: UN-/RID-Nummern von Gefahrgütern,
—: Angabe, ob der Zug Vieh oder Menschen (außer Zugbegleitpersonal) befördert,
—: Zu verwendende Bremsart,
—: Wagendaten.

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

—: Trassennummer und Zugnummer,
—: Startpunkt sowie Datum und Uhrzeit, für die die Trasse beantragt wurde,
—: Zielpunkt sowie Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,
—: Angabe, dass der IB die Zugbildung für die vereinbarte Trasse als geeignet akzeptiert hat.

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

—: Trassennummer und Zugnummer,
—: Startpunkt sowie Datum und Uhrzeit, für die die Trasse beantragt wurde,
—: Zielpunkt sowie Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,
—: Angabe, dass der Zug für die zugeteilte Trasse nicht geeignet ist und daher nicht fahren darf,
—: Angabe des Grundes.

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

—: Trassennummer und Zugnummer,
—: Startpunkt sowie Datum und Uhrzeit, für die die Trasse beantragt wurde,
—: Zielpunkt sowie Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,
—: Angabe, dass der Zug fertig ist. Sie gibt an, dass der Zug vorbereitet wurde und betriebsbereit ist,
—: Kennung der Kontaktperson in der Leitstelle für die gesamte Mobil-Stationär-Kommunikation,
—: Wenn der Vertrag zwischen EVU und IB festlegt, dass der Meldungsaustausch „Zugposition/Zug am Start” verzichtbar ist, müssen Anfangsdatum und -uhrzeit der Zugfahrt in dieser Meldung definiert sein. Sie informieren den IB darüber, wann und wo der Zug voraussichtlich in das Netz einfahren wird. Falls hingegen der Meldungsaustausch „Zugposition/Zug am Start” vorgeschrieben ist, darf diese Information nicht übertragen werden.

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

—: Trassennummer und Zugnummer,
—: Abfahrtspunkt auf der Trasse sowie Datum und Uhrzeit, für die die Trasse beantragt wurde,
—: Zielpunkt sowie Datum und Uhrzeit, zu der der vorgeschlagene Zug an seinem Ziel ankommen soll,
—: Gleiskennung; sie unterrichtet das EVU, auf welchem Gleis der Zug in das Netz des IB einfahren soll,
—: Anfangsdatum/-uhrzeit der Zugfahrt; sie teilt dem EVU genau mit, wann der Zug in das Netz des IB einfahren soll,
—: Kennung der Kontaktperson in der Leitstelle.

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

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

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

4.2.4.
Prognose zur Zugfahrt

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

Zugfahrtprognose,

Zugfahrtmeldung.

Dieser Informationsaustausch zwischen EVU und IB erfolgt immer zwischen dem aktuell zuständigen IB und dem EVU, das die Trasse gebucht hat, auf der sich der Zug aktuell befindet. Im Fall des offenen Netzzugangs, wenn also die Trassen für die gesamte Fahrt von einem einzigen EVU (dieses EVU betreibt auch den Zug während der gesamten Fahrt) gebucht werden, werden alle Meldungen an dieses EVU gesandt. Dasselbe gilt, wenn die Trassen für die Fahrt von einem EVU über den OSS gebucht werden. Sie berücksichtigen die verschiedenen Kommunikationsbeziehungen zwischen EVU und IB entsprechend den Trassenbuchungsszenarien in Kapitel 4.2.2.1 (Beantragung einer Trasse, Vorbemerkungen Szenario A, B):

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

Es wird angenommen, dass der Übergabepunkt nicht gleichzeitig ein Wagenübergangspunkt (nur Szenario B) und auch keine Anschlussstelle ist. Somit ist der Übergabepunkt ein Punkt auf den gebuchten Trassen eines EVU und das EVU hat die Zugbildung bereits an den IB n2 übermittelt, während es gleichzeitig diese Meldung an den IB n1 geschickt hat. IB n1 muss nach der Abfahrt vom Abfahrtspunkt⁽⁵⁾ eine Zugfahrtprognose mit der voraussichtlichen Übergabezeit (PZÜ) an IB n2 übermitteln. Diese Meldung wird gleichzeitig an das EVU geschickt. Wenn ein Zug die Infrastruktur des IB n1 am Übergabepunkt verlässt, sendet dieser IB eine Zugfahrtmeldung mit der tatsächlichen Übergabezeit an diesem Punkt an das EVU, das die Trasse gebucht hat. Wenn ein Zug in die Infrastruktur des IB n2 am Übergabepunkt einfährt, sendet dieser IB eine Zugfahrtmeldung mit der tatsächlichen Übergabezeit an diesem Punkt an das EVU, das die Trasse gebucht hat.

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

Im Trassenvertrag muss ein Wagenübergangspunkt immer als Meldepunkt definiert werden. (PZAZ an den Meldepunkten werden von den IB gemäß den Angaben in ihren Verträgen mit den EVU generiert.) Für diesen Punkt sendet der zuständige IB, sobald der Zug den auf der Trasse vorher liegenden Meldepunkt verlassen hat, eine Zugfahrtprognosemeldung mit der voraussichtlichen Ankunftszeit des Zuges (PZAZ) an diesem Wagenübergangspunkt an das EVU, das die Trasse gebucht hat (z. B. EVU 1). EVU 1 gibt die Meldung an das nächste EVU (z. B. EVU 2), das den Zug übernehmen soll, weiter. Zusätzlich wird diese Meldung auch an das federführende EVU (FEVU) für den Transport weitergegeben, sofern ein FEVU vorhanden und die Weiterleitung der Meldung im Vertrag zwischen den beiden EVU festgelegt ist. Ist der Wagenübergangspunkt gleichzeitig ein Übergabepunkt, beispielsweise zwischen IB n1 und IB n2, sendet IB n1 die Zugfahrtprognose bereits nach der Abfahrt vom Abfahrtspunkt oder vom vorigen Wagenübergangspunkt an IB n2 mit Angabe der voraussichtlichen Übergabezeit (PZÜ). Diese Meldung wird gleichzeitig an das EVU geschickt, das die Trasse gebucht hat, z. B. EVU 1. Für das EVU ist die PZÜ identisch mit PZAZ am Wagenübergangspunkt. EVU 1 gibt die Meldung an den Nachbarn EVU 2 und gegebenenfalls an ein federführendes EVU für den Transport weiter, sofern ein FEVU vorhanden und die Weiterleitung der Meldung im Vertrag zwischen den beiden EVU festgelegt ist. Bei Ankunft des Zuges an einem Wagenübergangspunkt muss der IB eine Zugfahrtmeldung an das EVU senden, das die Trasse gebucht hat (z. B. EVU 1); die Meldung enthält die tatsächliche Ankunftszeit an diesem Punkt. Vor der Abfahrt eines Zuges vom Wagenübergangspunkt muss EVU 2 eine neue Zugbildungsmeldung an den IB schicken, der ihr die Trasse zugewiesen hat, und es muss das in Kapitel 4.2.3 (Zugvorbereitung) beschriebene Verfahren bei der Abfahrt befolgen.

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

Eine Anschlussstelle muss immer im Trassenvertrag als Meldepunkt definiert werden. Für diesen Punkt muss der zuständige IB eine Zugfahrtprognose mit einer PZAZ nur dann schicken, wenn dies im Vertrag zwischen IB und EVU festgelegt ist. Ist die Anschlussstelle aber gleichzeitig ein Übergabepunkt, beispielsweise zwischen IB n1 und IB n2, muss IB n1 die Zugfahrtprognose bereits nach der Abfahrt vom Abfahrtspunkt oder vom vorigen Wagenübergangspunkt an IB n2 mit Angabe der voraussichtlichen Übergabezeit (PZÜ) senden. Diese Meldung wird auch an das EVU geschickt. Für das EVU ist die PZÜ identisch mit der PZAZ an der Anschlussstelle. Bei Ankunft des Zuges an der Anschlussstelle muss der IB eine Zugfahrtmeldung mit der tatsächlichen Ankunftszeit an diesem Punkt an das EVU schicken. Vor Abfahrt des Zuges von der Anschlussstelle müssen das EVU und der IB das in Kapitel 4.2.3 (Zugvorbereitung) beschriebene Verfahren bei der Abfahrt befolgen.

—: Ankunft des Zugs am Ziel

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

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

In den folgenden Kapiteln werden die Meldungen „Zugfahrtprognose” und „Zugfahrtmeldung” in ihren wichtigsten Punkten umrissen. Die ausführlichen Formate dieser Meldungen sind im Anhang A Anlage F definiert. Die logische Abfolge dieses Meldungsaustauschs bei den unterschiedlichen Kommunikationsszenarios ist aus Anhang A Ziffer 5 Kapitel 4 ersichtlich. Es sei darauf hingewiesen, dass hinsichtlich der Kommunikationsbeziehung zwischen EVU und IB während der Zugfahrt die beiden Szenarien A(a) und A(b) (Kapitel 4.2.2.1: Beantragung einer Trasse, Vorbemerkungen) zum Trassenantrag identisch sind, denn in beiden Fällen kennen die IB nur ein EVU, z. B. EVU 1, das den Zug über die gesamte Trasse betreibt und auch für die neue Zugbildung an den Anschlussstellen zuständig ist. Diese Meldung muss vom IB für Übergabepunkte, Wagenübergangspunkte und für das Zugziel, wie in Kapitel 4.2.4.1 (Prognose zur Zugfahrt, Allgemeine Bemerkungen) beschrieben, geschickt werden. Zusätzlich muss diese Meldung durch den IB an das EVU für weitere Meldepunkte entsprechend den EVU/IB-Verträgen erfolgen (z. B. für Anschlussstellen). Die wichtigsten Datenelemente sind:

—: Trassennummer und Zugnummer,
—: Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am Standort des IB (oder planmäßige Übergabezeit an den nächsten IB),
—: Kennung des Meldepunkts,
—: Prognostizierte(s) Datum/Zeit am Meldepunkt.

Diese Meldung muss erfolgen bei:

—

Abfahrt vom Startpunkt, Ankunft am Zielpunkt,

—

Ankunft und Abfahrt an Übergabe-, Wagenübergangs- und an vertraglich vereinbarten Meldepunkten (zum Beispiel an Anschlussstellen).

Die wichtigsten Datenelemente sind:

—

Trassennummer und Zugnummer,

—

Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort,

—

Identifizierung des zuletzt passierten Meldepunkts,

—

Istzeit am Meldepunkt,

—

Status des Zuges am Meldepunkt (Ankunft, Abfahrt, Durchfahrt, Nicht angegeben, Abfahrt ab Ausgangsbahnhof, Ankunft am Ziel),

—

Ankunftsgleis am Meldepunkt,

—

Abfahrtsgleis vom Meldepunkt,

—

Abweichung von der gebuchten fahrplanmäßigen Zeit in Minuten,

—

aktueller Fahrplan (bei mehrfacher Neuplanung),

—

Für jede Abweichung von der gebuchten fahrplanmäßigen Zeit an diesem Meldepunkt:

—: Ursachencode (eventuell mehrere),
—: Abweichungszeit für diesen Ursachencode (pro Meldepunkt können mehrere Ursachen angegeben werden),
—: Eventuell freier Text über die Abweichung.

4.2.5.
Information über Verkehrsunterbrechung

Erfährt das EVU von einer Verkehrsunterbrechung während der Zugfahrt, für die es verantwortlich ist, muss es den zuständigen IB unverzüglich unterrichten (nicht per IT-Meldung, sondern z. B. durch den Triebfahrzeugführer). Falls erforderlich, aktualisiert das EVU die Betriebsdatenbank für Wagen und Intermodaleinheiten. Falls erforderlich, aktualisiert der IB die Infrastrukturdaten in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen und/oder die Trassen- bzw. die Zugdatenbank. Bei Verspätungen von mehr als x Minuten (dieser Wert ist im Vertrag zwischen EVU und IB zu definieren) muss der betroffene IB dem EVU eine Zugfahrtprognose bezogen auf den nächsten Meldepunkt schicken. Bei Aussetzung des Zuges sendet der IB eine Meldung über die Fahrtunterbrechung gemäß nachstehender Beschreibung. In den Ausnahmefällen, in denen das EVU oder der IB den Zug nicht zur veranschlagten Zeit fahren lassen kann, muss eine neue Trasse gemäß Kapitel 4.2.2 (Beantragung einer Trasse) ausgehandelt werden. Bei Aussetzung des Zuges wird diese Meldung vom IB an den benachbarten IB und an das EVU, das die Trasse gebucht hat, geschickt. Die wichtigsten Datenelemente in dieser Meldung sind:

—: Trassennummer und Zugnummer,
—: Ortsangabe,
—: Planmäßige(s) Abfahrtsdatum und Abfahrtszeit an diesem Ort,
—: Unterbrechungsgrund,
—: Beschreibung der Unterbrechung.

4.2.6.
Abfragen zum Zugstandort

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

—: die Zugfahrt (letzter gemeldeter Standort, Verspätungen, Verspätungsgründe),
—: die Fahrleistung eines Zuges (Verspätungen, Verspätungsgründe, Verspätungsorte),
—: alle Kennungen eines bestimmten Zuges,
—: die Zugfahrtprognose eines Zuges für einen bestimmten Ort,
—: alle Zugfahrtprognosen für einen bestimmten Ort.

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

Zweck:

EVU erfragt den letzten gemeldeten Status (Standort, Verspätungen und Verspätungsgründe) eines bestimmten Zuges auf der Infrastruktur eines bestimmten IB.

Abfrage:

Wichtigste Datenelemente:

—: Zugnummer,
—: IB-Kennung,
—: Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort.

Antwort:

Informationsdaten:

—

Zuletzt gemeldeter Meldepunkt,

—

Istzeit am Meldepunkt,

—

Status am Meldepunkt (Ankunft, Abfahrt, Durchfahrt, Nicht angegeben, Abfahrt ab Ausgangsbahnhof, Ankunft am Ziel),

—

Ankunftsgleis am Meldepunkt,

—

Abfahrtsgleis vom Meldepunkt,

—

Gebuchte fahrplanmäßige Zeit,

—

Verspätung gegenüber der gebuchten fahrplanmäßigen Zeit,

—

Neu geplante Zeit (im Vergleich zum aktuellen Fahrplan, falls mehrfach umgeplant),

—

Für jede Verspätung am betreffenden Meldepunkt:

—: Code für die Ursache und Verspätungszeit aufgrund dieser Ursache.

Zweck:

EVU erfragt alle Verspätungen bei einem bestimmten IB.

Abfrage:

Wichtigste Datenelemente

—: Zugnummer,
—: IB-Kennung,
—: Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort.

Antwort:

Informationsdaten (dieselben Informationen wie bei der „Abfrage zur Zugfahrt” , jedoch nicht nur für den zuletzt gemeldeten Meldepunkt, sondern für alle Meldepunkte des Zuges auf der Infrastruktur des spezifizierten IB):

—

Für jeden Meldepunkt:

—

Zuletzt gemeldeter Meldepunkt,

—

Istzeit am Meldepunkt,

—

Status des Zuges am Meldepunkt (Ankunft, Abfahrt, Durchfahrt, Nicht angegeben, Abfahrt ab Ausgangsbahnhof, Ankunft am Ziel),

—

Ankunftsgleis am Meldepunkt,

—

Abfahrtsgleis vom Meldepunkt,

—

Gebuchte fahrplanmäßige Zeit,

—

Verspätung gegenüber der gebuchten fahrplanmäßigen Zeit,

—

Neu geplante Zeit (im Vergleich zum aktuellen Fahrplan, falls mehrfach umgeplant),

—

Für jede Verspätung am betreffenden Meldepunkt:

—: Code für die Ursache und Verspätungszeit aufgrund dieser Ursache.

Zweck:

EVU erfragt die aktuelle Zugkennung und die vorigen Zugkennungen. Für einen spezifischen Zug kann jede der Zugkennungen für die Abfrage verwendet werden.

Abfrage:

Wichtigste Datenelemente:

—: Bekannte Zugnummer,
—: IB-Kennung,
—: Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort.

Antwort:

Informationsdaten:

—

Aktuelle Zugkennung:

—: Zugnummer,
—: Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort.

—

Für alle anderen Zugkennungen:

—: Zugnummer,
—: Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort.

Zweck:

EVU fragt nach der prognostizierten Zeit eines bestimmten Zuges an einem bestimmten Meldepunkt, oder bei Auslassen des Meldepunkts erfolgt die Frage nach der prognostizierten Zeit am Übergabepunkt vom IB.

Abfrage:

Wichtigste Datenelemente:

—: Zugnummer,
—: Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort,
—: Meldepunktkennung (Der Meldepunkt, für den die Prognose gewünscht wird. Die Angabe ist optional. Wird keine Kennung angegeben, bezieht sich die Antwort auf den letzten Meldepunkt für diesen IB für diesen Zug.)

Antwort:

Informationsdaten:

—: IB-Kennung,
—: Meldepunktkennung,
—: Prognostizierte(s) Datum/Zeit am Meldepunkt.

Zweck:

EVU fragt nach allen seinen Zügen an einem bestimmten Meldepunkt auf der Infrastruktur eines speziellen IB.

Abfrage:

Wichtigste Datenelemente:

—: IB-Kennung,
—: Meldepunktkennung (Der Meldepunkt, für den die Prognose gewünscht wird. Die Angabe ist optional. Wird keine Kennung angegeben, bezieht sich die Antwort auf den letzten Meldepunkt für diesen IB für diesen Zug.).

Antwort:

Informationsdaten:

—

Für jeden Zug des anfragenden EVU:

—: Zugnummer,
—: Planmäßige(s) Abfahrtsdatum und Abfahrtszeit am IB-Standort oder planmäßige Übergabezeit,
—: IB-Kennung,
—: Meldepunktkennung,
—: Prognostizierte(s) Datum/Zeit am Meldepunkt.

4.2.7.
Ladung PÜZ/PAZ

In Kapitel 4.2.2 (Trassenantrag) bis 4.2.6 (Zugstandort) wird hauptsächlich die Kommunikation zwischen EVU und IB beschrieben. Da die Aufgabe des Betreibers der Infrastruktur darin besteht, die Züge zu überwachen und zu steuern, ist die Zugnummer das wichtigste Element dieser Kommunikation. Der Wageninformationsteil der Zugbildungsmeldung ist nur für den Abgleich der Zugbildung mit dem Trassenvertrag zwischen IB und EVU und in Ausnahmefällen relevant. Die Einzelüberwachung von Wagen oder Intermodaleinheiten wird durch diesen Informationsaustausch nicht geregelt. Dies geschieht auf EVU- oder FEVU-Ebene auf Basis der zugspezifischen Meldungen und wird in den folgenden Kapiteln 4.2.7 (Ladung PÜZ/PAZ) bis 4.2.9 (Berichtswesen Wagenübergang) beschrieben. Der auf Wagen oder Intermodaleinheiten bezogene Informationsaustausch und die Aktualisierung stützen sich im Wesentlichen auf die Speicherung von „Tourenplänen” und „Wagenbewegungen” (Kapitel 4.2.12.2: Weitere Datenbanken). Wie bereits in Kapitel 2.3.2 (Betrachtete Prozesse) erwähnt, ist die wichtigste Information für einen Kunden immer die voraussichtliche Ankunftszeit (PAZ) seiner Ladung. Die wagenbezogene PAZ sowie die PÜZ ist auch die Basisinformation in der Kommunikation zwischen FEVU und EVU. Diese Information ist das Hauptinstrument für das FEVU zur Überwachung des physischen Transports einer Ladung und dient zur Überprüfung mit der Verpflichtung gegenüber dem Kunden. Die prognostizierten Zeiten in den zugbezogenen Meldungen beziehen sich stets auf die Ankunftszeit eines Zuges an einem bestimmten Punkt. Das kann ein Übergabepunkt, Wagenübergangspunkt, Zielort oder ein anderer Meldepunkt sein. Es handelt sich dabei immer um die voraussichtliche Ankunftszeit des Zuges (PZAZ). Für die verschiedenen Wagen oder Intermodaleinheiten in einem Zug kann diese PZAZ unterschiedliche Bedeutungen haben. Eine für einen Wagenübergangspunkt berechnete PZAZ kann beispielsweise die voraussichtliche Wagenübergangszeit (PÜZ) für einige Wagen oder Intermodaleinheiten sein. Für andere Wagen, die zur weiteren Beförderung durch dasselbe EVU im Zugverband verbleiben, mag dieses PZAZ ohne Bedeutung sein. Die Aufgabe des EVU, das die PZAZ-Information erhält, ist es, die spezifische Interpretation vorzunehmen und auszuwerten, sie als Wagenbewegung in der Betriebsdatenbank für Wagen und Intermodaleinheiten zu speichern und sie dann dem FEVU mitzuteilen, falls der Zug nicht im Modus des offenen Netzzugangs betrieben wird. Dies wird nun in den folgenden Abschnitten betrachtet. Die PÜZ/PAZ-Berechnung basiert auf den Informationen vom zuständigen Infrastrukturbetreiber. Dieser sendet im Rahmen der Zugfahrtprognose die voraussichtliche Ankunftszeit des Zuges (PZAZ) für die definierten Meldepunkte (in jedem Fall für Übergabe-, Wagenübergangs- oder Ankunftspunkte einschließlich Intermodal-Umschlagbahnhöfe) auf der vereinbarten Trasse, z. B. für den Übergabepunkt von einem IB zum nächsten IB (in diesem Fall ist PZAZ gleich PZÜ). Für die Wagenübergangspunkte oder für andere definierte Meldepunkte auf der vereinbarten Trasse muss das EVU für das nächste EVU in der Transportkette die voraussichtliche Wagenübergangszeit (PÜZ) für die Wagen und/oder Intermodaleinheiten berechnen. Da ein EVU Wagen mit verschiedenen Fahrten und von verschiedenen FEVU innerhalb des Zugs haben kann, kann der Wagenübergangspunkt für die PÜZ-Berechnung der Wagen verschieden sein. Dies ist in den zwei folgenden vereinfachten Beispielen erklärt (die bildliche Darstellung dieser Szenarien ist im Anhang A Index 5 Kapitel 1.4 wiedergegeben, und das Ablaufdiagramm auf der Basis von Beispiel 1 für den Wagenübergangspunkt C ist in Anhang A Index 5 Kapitel 5 dargestellt).

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

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

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

Das federführende EVU ist verantwortlich für den Vergleich der PAZ mit der eingegangenen Verpflichtung gegenüber dem Kunden. Abweichungen der PAZ von der Verpflichtung gegenüber dem Kunden müssen im Einklang mit dem Vertrag behandelt werden und können zu einem Alarmmanagement-Prozess durch das FEVU führen. Für die Übertragung der Ergebnisse dieses Prozesses ist die Alarmmeldung vorgesehen. Als Basis für den Alarmmanagement-Prozess muss das FEVU die Möglichkeit zur wagenbezogenen Abfrage von Abweichungen haben. Diese Abfrage eines FEVU und die Antwort vom EVU sind ebenfalls nachfolgend beschrieben.

Zweck:

Übermittlung der PÜZ oder einer aktualisierten PÜZ von einem EVU zum nächsten EVU in der Transportkette. Das letzte EVU in der Transportkette der Wagen übermittelt die PAZ oder eine aktualisierte PAZ an das FEVU.

Wichtigste Datenelemente:

—: Kennung des EVU, das die PÜZ oder PAZ errechnet hat,
—: Abfahrt- oder vorheriger Wagenübergangspunkt (PÜZ oder Abfahrtszeit am Ursprungsbahnhof),
—: Zugnummer bei Abfahrt vom Abfahrts- oder vorigen Wagenübergangspunkt (PÜZ oder Abfahrtszeit vom Ursprungsbahnhof),
—: Tatsächliche(s) Abfahrtsdatum und -uhrzeit des Zuges,
—: Ankunfts- oder nächster Wagenübergangspunkt (PÜZ/PAZ-Endbahnhof),
—: Zugnummer bei Ankunft am PÜZ/PAZ-Endbahnhof (Ankunfts- oder nächster Wagenübergangspunkt),
—: Ankunftsdatum und -uhrzeit des Wagens (PÜZ oder PAZ).

Zweck:

Als Folge des Abgleichs zwischen PAZ und der Verpflichtung gegenüber dem Kunden kann das FEVU eine Alarmmeldung an die beteiligten EVU schicken.

Wichtigste Datenelemente:

—: Wagennummer,
—: Verpflichtung gegenüber dem Kunden: Ankunftsdatum und -uhrzeit,
—: Derzeitige PAZ: Datum und Uhrzeit.

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

Zweck:

FEVU erfragt die Abweichungen bezogen auf einen bestimmten Wagen.

Abfrage:

Wichtigste Datenelemente

—: Wagennummer,
—: FEVU-Kennung.

Antwort:

Informationsdaten:

—

Für jeden Meldepunkt

—

Kennung des Meldepunkts,

—

Wagenstatus am Meldepunkt (Abfahrt, Ankunft am Rangierbahnhof, Abfahrt ab Rangierbahnhof, Ankunft am Wagenübergangspunkt, Ankunft am Ziel),

—

Zuständiges EVU am Meldepunkt und gemäß Wagenstatus am Meldepunkt,

—

Neu geplante Zeit (Vergleich zum aktuellen Fahrplan bei mehrfachen Umplanungen),

—

PÜZ, falls Meldepunkt ein Wagenübergangspunkt ist,

—

Istzeit am Meldepunkt,

—

Für jede Abweichung am betreffenden Meldepunkt

—: Code für die Ursache und Verspätungszeit aufgrund dieser Ursache.

4.2.8.
Berichtswesen Wagenbewegung

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

—: Wagenfreigabe
—: Wagenabfahrt
—: Wagenankunft Rangierbahnhof
—: Wagenabfahrt Rangierbahnhof
—: Wagenausnahme
—: Wagenankunft
—: Wagenablieferung
—: Wagenablieferbestätigung
—: Wagenübergangsmeldungen werden separat in Kapitel 4.2.9 (Berichtswesen Wagenübergang) beschrieben.

Zweck:

FEVU an EVU: Das federführende EVU ist nicht unbedingt das erste EVU in der Transportkette. In diesem Fall muss das FEVU dem zuständigen EVU mitteilen, dass der Wagen auf dem Abstellgleis des Kunden (Abfahrtsort gemäß Vertrag zwischen FEVU und Kunde) zum gegebenen Freigabezeitpunkt (Datum und Uhrzeit der Abfahrt) zur Abholung bereit steht.

Der Vorgang muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden.

Wichtigste Datenelemente:

—: Wagennummer,
—: Ort, Datum und Uhrzeit der Abfahrt (der Ort, von dem der Transport abgehen soll).

Die folgenden Daten müssen für EVU und FEVU leicht aus den Datenbanken abrufbar sein:

—: Transporteinheit, Kennung, Größe und Art,
—: Auslastung der Transporteinheit,
—: Gesamtgewicht (Gebuchtes/tatsächliches Gesamtgewicht (Masse) der Güter, einschließlich Verpackung und Transportvorrichtungen),
—: Angabe von Gefahrgütern.

Zweck:

EVU an FEVU: Das EVU muss dem FEVU das tatsächliche Datum und die tatsächliche Uhrzeit mitteilen, zu der der Wagen vom Abfahrtsort gezogen wurde.

Der Vorgang muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden. Mit diesem Meldungsaustausch geht die Verantwortung für den Wagen vom Kunden auf das EVU über.

Wichtigste Datenelemente:

—: Wagennummer,
—: Ort, Datum und Uhrzeit der Abfahrt (der Ort, von dem der Transport abgehen soll).

Die folgenden Daten müssen für EVU und FEVU leicht aus den Datenbanken abrufbar sein:

—: Transporteinheit, Kennung, Größe und Art,
—: Auslastung der Transporteinheit,
—: Gesamtgewicht (Gebuchtes/tatsächliches Gesamtgewicht (Masse) der Güter, einschließlich Verpackung und Transportvorrichtungen),
—: Angabe von Gefahrgütern.

Zweck:

Das EVU muss das FEVU informieren, dass der Wagen am Rangierbahnhof angekommen ist. Diese Meldung kann aufgrund einer „Zugfahrtmeldung” aus Kapitel 4.2.4 (Prognose zur Zugfahrt) erfolgen. Der Vorgang muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden.

Wichtigste Datenelemente:

—: Wagennummer,
—: Kennung des Rangierbahnhofs,
—: Datum und Uhrzeit der Ankunft am Rangierbahnhof.

Zweck:

Das EVU muss das FEVU informieren, dass der Wagen den Rangierbahnhof verlassen hat. Diese Meldung kann aufgrund einer „Zugfahrtmeldung” aus Kapitel 4.2.4 (Prognose zur Zugfahrt) erfolgen. Der Vorgang muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden.

Wichtigste Datenelemente:

—: Wagennummer,
—: Kennung des Rangierbahnhofs,
—: Datum und Uhrzeit der Abfahrt vom Rangierbahnhof.

Zweck:

Das EVU muss das FEVU informieren, sobald etwas Unerwartetes mit dem Wagen auftritt, das möglicherweise eine Auswirkung auf PÜZ/PAZ haben kann oder das zusätzliche Aktivitäten erforderlich macht. Diese Meldung bedingt in den meisten Fällen auch die Berechnung einer neuen PÜZ/PAZ. Wenn das FEVU beschließt, eine neue PÜZ/PAZ zu benötigen, sendet es eine Meldung zusammen mit der Angabe „Neue PÜZ/PAZ erforderlich” zurück an das EVU, das die Meldung geschickt hat. (Meldung: Wagenausnahme neue PÜZ/PAZ erforderlich). Die Berechnung der neuen PÜZ/PAZ muss nach dem Verfahren in Kapitel 4.2.7 (Ladung PÜZ/PAZ) erfolgen.

Diese Information muss in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden.

Wichtigste Datenelemente:

—: Wagennummer,
—: Ort, Datum und Uhrzeit der Störung (der Ort, an dem während des Transports etwas Unvorhergesehenes geschieht),
—: Ursachen-/Störungscode.

Zusätzlich müssen folgende Daten leicht aus den Datenbanken abrufbar sein:

—: Kennung der Transporteinheit,
—: Angabe von Gefahrgütern.

Zweck:

Das FEVU kann diese Meldung an das aktuelle EVU senden, das die „Ausnahmemeldung” geschickt hat, um eine Neuberechnung der PÜZ/PAZ anzufordern. Das FEVU sendet diese Meldung an alle folgenden EVU, um sie über die Abweichung zu informieren. Ob eine Neuberechnung der PÜZ/PAZ erforderlich ist, entscheidet das FEVU; sie ist nicht in allen Fällen erforderlich.

Wichtigste Datenelemente:

—: Wagennummer,
—: Ort, Datum und Uhrzeit der Störung (der Ort, an dem während des Transports etwas Unvorhergesehenes geschieht),
—: Ursachen-/Störungscode,
—: Neue PÜZ/PAZ erforderlich.

Zusätzlich müssen folgende Daten leicht aus den Datenbanken abrufbar sein:

—: Kennung der Transporteinheit,
—: Angabe von Gefahrgütern.

Zweck:

Das letzte EVU in der Transportkette eines Wagens oder einer Intermodaleinheit muss das FEVU informieren, dass der Wagen auf seinem Rangierbahnhof angekommen ist (EVU-Standort).

Wichtigste Datenelemente:

—: Wagennummer,
—: Kennung des Rangierbahnhofs des EVU,
—: Datum und Uhrzeit der Ankunft.

Zweck:

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

Wichtigste Datenelemente:

—: Wagennummer,
—: Genaue Ortsangabe auf Empfängergleis (Standort, Bereich, Gleis, Stelle),
—: Datum und Uhrzeit des Abstellens.

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

—: Kundenkennung.

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

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

4.2.9.
Berichtswesen Wagenübergang

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

—: Wagenübergang,
—: Wagenübergang/Sub,
—: Wagen am Übergangspunkt erhalten,
—: Wagen am Übergangspunkt abgelehnt.

Die Informationen in diesen Meldungen müssen in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden. Im Fall irgendwelcher Ausnahmen müssen neue PÜZ/PAZ-Zeiten generiert und nach dem in Kapitel 4.2.7 (Ladung PÜZ/PAZ) beschriebenen Verfahren an die anderen Beteiligten übermittelt werden. Das Ablaufdiagramm für diese Meldungen zusammen mit den Meldungen aus dem Berichtswesen der Wagenbewegungen ist im Anhang A Ziffer 5 Kapitel 6 dargestellt. Die Meldungen „Wagenübergang” und „Wagenübergang/Sub” wie auch die Meldungen „Wagen am Übergangspunkt erhalten” können in Form einer Liste für mehrere Wagen gleichzeitig übertragen werden, insbesondere wenn sich alle Wagen in ein und demselben Zug befinden. In diesem Fall können alle Wagen in einer einzigen Meldung aufgeführt werden. Im Fall des offenen Netzzugangs gibt es keine Wagenübergangspunkte. An einer Anschlussstelle bleibt die Verantwortung für die Wagen unverändert. Es ist daher kein spezieller Meldungsaustausch erforderlich. Allerdings müssen aus der an diesem Meldepunkt abgesetzten Zugfahrtmeldung die Wagen- oder Intermodaleinheit-Informationen (wie Standort, Ankunftsdatum und -uhrzeit sowie Abfahrtsdatum und -uhrzeit) entnommen, verarbeitet und in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden. Die Inhalte dieser Meldungen ergeben sich wie folgt:

Zweck:

Mit der Meldung „Wagenübergang” fragt ein EVU (EVU 1) beim nächsten EVU (EVU 2) in der Transportkette an, ob es bereit ist, die Verantwortung für einen Wagen zu übernehmen. Mit der Meldung „Wagenübergang/Sub” informiert EVU 2 seinen IB, dass es die Verantwortung für den Wagen übernommen hat.

Wichtigste Datenelemente:

—: Wagennummer,
—: Zugnummer (nur wenn der Wagen Teil eines Zuges ist),
—: Ort, Datum und Uhrzeit des Wagenübergangs.

Zusätzlich müssen folgende Daten leicht aus den Datenbanken abrufbar sein.

—: Kennung der Transporteinheit (Anzahl, Größe und Art),
—: Gesamtgewicht (Gebuchtes/tatsächliches Gesamtgewicht (Masse) der Güter, einschließlich Verpackung und Transportvorrichtungen),
—: Auslastung der Transporteinheit,
—: Details zu Gefahrgütern, Kennung.

Zweck:

Mit der Meldung „Wagenübergang/Sub” informiert das EVU 2 seinen IB, dass es die Verantwortung für den Wagen übernommen hat.

Wichtigste Datenelemente:

—: Wagennummer,
—: Zugnummer (nur wenn der Wagen Teil eines Zuges ist),
—: Ort, Datum und Uhrzeit des Wagenübergangs.

Zusätzlich müssen folgende Daten leicht aus den Datenbanken abrufbar sein:

—: Einzelheiten zu Gefahrgütern, Kennung.

Zweck:

Mit der Meldung „Wagen am Übergangspunkt erhalten” informiert EVU 2 das EVU 1, dass es die Verantwortung für den Wagen übernimmt.

Wichtigste Datenelemente:

—: Wagennummer,
—: Ort, Datum und Uhrzeit des Wagenübergangs.

Zweck:

Mit der Meldung „Wagen am Übergangspunkt abgelehnt” informiert EVU 2 das EVU 1, dass es nicht bereit ist, die Verantwortung für den Wagen zu übernehmen.

Wichtigste Datenelemente:

—: Wagennummer,
—: Ort, Datum und Uhrzeit des Wagenübergangs,
—: Ursachencode für die Ablehnung,
—: Weitere Beschreibung (optional).

4.2.10.
Datenaustausch zur Qualitätsverbesserung

Um wettbewerbsfähig zu sein, muss die europäische Eisenbahnbranche ihren Kunden eine höhere Dienstqualität bieten (siehe auch Anhang III, Artikel 2 Absatz 7 Unterabsatz 1 der Richtlinie 2001/16/EG). Ein Messprozess ist ein wesentlicher nachlaufender Prozess, um Qualitätsverbesserungen zu erreichen. Neben der Messung der dem Kunden erbrachten Leistung müssen FEVU, EVU und IB die Qualität der Leistungskomponenten messen, die zusammen das dem Kunden gebotene Produkt darstellen. Mitwirkende des Verfahrens sind die IB und die EVU (insbesondere, wenn sie federführende EVU sind). Sie wählen einen individuellen Qualitätsparameter, eine Strecke oder einen Ort und einen Erfassungszeitraum, in dem die tatsächlichen Ergebnisse gemessen und mit vorher festgelegten Kriterien, die normalerweise in einem Vertrag aufgeführt sind, verglichen werden. Die Resultate des Messprozesses müssen verdeutlichen, welches Leistungsniveau im Vergleich zu den zwischen den Vertragsparteien vereinbarten Zielen erreicht wurde. Die Messprotokolle müssen so detailliert sein, dass sie eine Analyse gestatten, wo und warum Qualitätsminderungen, z. B. Verspätungen, aufgetreten sind. Bei wiederkehrenden Qualitätsmängeln ist eine Ursachenforschung zu betreiben, damit die Vertragsparteien für Abhilfe sorgen können. IB und EVU sind verpflichtet, Daten bereitzustellen, sich, auch mit Drittparteien, an der Ursachenforschung zu beteiligen und vereinbarte Abhilfemaßnahmen zu ergreifen. Der Messprozess ist laufend zu wiederholen. Wie unter den folgenden sechs Überschriften aufgeführt, können zur Qualitätsmessung die bereits definierten Meldungen dienen:

1. FEVU/Kunde:

Transitzeit, PAZ, Alarmbehebung

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

—: Wagenfreigabe,
—: Wagenabfahrt,
—: Wagenablieferung.

2. FEVU/Dienstleister:

Transit- und Anschlusszeiten, PAZ, PÜZ, Ursachencodes

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

—: Freigabe-/Rangierzeit bis Ablieferung an einem Wagenübergangspunkt,
—: Abholung bis Einfahrtspunkt,
—: Einfahrtspunkt bis zur Ladung,
—: Annahme am Wagenübergangspunkt bis Ablieferung am Wagenübergangspunkt,
—: Annahme am Wagenübergangspunkt bis Abstellen/Umschlagen,
—: Rangieren bis Ablieferung.

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

—: Wagenfreigabe,
—: Wagenabfahrt,
—: Wagenankunft am Rangierbahnhof,
—: Wagenabfahrt am Rangierbahnhof,
—: Wagenankunft,
—: Wagenübergang erfolgt,
—: Wagen am Wagenübergangspunkt erhalten,
—: Wagen am Wagenübergangspunkt abgelehnt.

3. EVU/IB:

Zugleistung, Zug-PAZ (PZAZ), PZÜ

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

—: Zugfahrtprognose,
—: Zugfahrtmeldung,
—: Abfrage/Antwort über Zugverspätungen/Fahrleistung.

4. EVU/IB:

Verfügbarkeit geplanter Trassen

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

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

—: Trasse storniert,
—: Trasse nicht verfügbar.

5. EVU/IB:

Kurzfristiger Trassenantrag

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

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

—: Antwortzeit für Trassenantrag im Vergleich zum Rahmenvertrag,
—: Anzahl der Trassen, die innerhalb gewisser Zeitintervalle nach der Antragstellung gewährt wurden,
—: Anzahl abgelehnter Trassenanträge.

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

—: Trassenantrag,
—: Trassendetails,
—: Trassendetails abgelehnt,
—: Trasse storniert,
—: Trasse nicht verfügbar.

6. IB/EVU:

Zugbildungsqualität

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

—: Zugbildung,
—: Zug ungeeignet.

4.2.11.
Die Hauptreferenzdaten

Die Infrastrukturdaten (die Schienennetz-Nutzungsbedingungen und die gespeicherten Daten in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen) und die Fahrzeugdaten (in der Fahrzeugreferenzdatenbank und in der Betriebsdatenbank für Wagen und Intermodaleinheiten) sind die wichtigsten Daten für den Güterzugverkehr im Europäischen Schienennetz. Beide zusammen erlauben eine Bewertung der Kompatibilität der Fahrzeuge mit der Infrastruktur, unterstützen die Vermeidung von mehrfacher Dateneingabe, was insbesondere die Datenqualität erhöht, und geben zu jeder Zeit ein klares Bild über die verfügbaren Installationen und Ausrüstungen für schnelle Entscheidungen während des Betriebes. Jeder IB ist für die Eignung einer Trasse auf seiner Infrastruktur verantwortlich, und das EVU ist verpflichtet, die Zugmerkmale in Bezug auf die Werte zu überprüfen, die in den Trassendetails seines Trassenvertrages aufgeführt sind. Unbeschadet der Bedingungen für die Nutzung einer Trasse in den Schienennetz-Nutzungsbedingungen oder der Verantwortlichkeiten bei Einschränkungen in der Infrastruktur, die in der TSI Betrieb und Verkehrsmanagement erläutert sind, muss das EVU vor der Zugvorbereitung wissen, ob es Beschränkungen auf den Trassenabschnitten oder Bahnhöfen (Knoten) gibt, die seine Zugzusammenstellung, wie im Trassenvertrag beschrieben, beeinflussen. Dazu müssen die IB Datenbanken für die Mitteilungen über Beschränkungen in der Infrastruktur erstellen und auffüllen: Die Struktur einer solchen Datenbank ist im Anhang A Anlagen D und F skizziert. Die Einträge dieser Datenbanken beruhen auf Segmenten entsprechend den Schienennetz-Nutzungsbedingungen unter Zusatz von Beschränkungsinformationen. Die Zugänglichkeit dieser Datenbanken erfolgt über die „gemeinsame Schnittstelle” (4.2.14.1: Vernetzung und Kommunikation und 4.2.14.7: Gemeinsame Schnittstelle). Das EVU ist verpflichtet, alle Beschränkungen in den Datenbanken für Mitteilungen der Infrastrukturbeschränkungen, die seinen Zuglauf beeinflussen, bis zum Beginn der „Vor-Abfahrt-Periode” zu berücksichtigen. Wenn nichts anderes im Vertrag zwischen IB und EVU vereinbart ist, dann beginnt diese „Vor-Abfahrt-Periode” eine Stunde vor der planmäßigen Abfahrt. In der „Vor-Abfahrt-Periode” muss der IB das EVU direkt über jegliche relevanten Änderungen in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen benachrichtigen. Der Fahrzeughalter ist für die Speicherung der Fahrzeugdaten in einer Fahrzeugreferenzdatenbank verantwortlich. Die Informationen, die in den individuellen Fahrzeugreferenzdatenbanken enthalten sein müssen, sind in Anhang A Anlagen A, B und F sowie Anlage B Anhang 1 ausführlich beschrieben. Sie beinhalten alle Elemente zur:

—: Identifizierung des Fahrzeugs,
—: Bewertung der Kompatibilität mit der Infrastruktur,
—: Bewertung der relevanten Beladungsmerkmale,
—: Bremsrelevante Merkmale,
—: Instandhaltungsdaten,
—: Umwelteigenschaften.

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

—

Administrative Daten,

beziehen sich auf Zertifizierungs- und Zulassungsaspekte, z. B. Verweis auf die EG-Zulassungsdatei, Kennung der benannten Stelle usw.; sie können historische Daten über Besitz- und Mietverhältnisse usw. enthalten. Folgende Schritte sind zu berücksichtigen:

—: EG-Konformitätsbescheinigung,
—: Zulassung im Heimatland,
—: Datum der Indienststellung im Zulassungsland,
—: Zulassung in anderen Ländern für den Einsatz auf deren nationalem Streckennetz,
—: Sicherheitsbescheinigung für alle Fahrzeuge, die nicht der TSI Fahrzeuge entsprechen.

Der Fahrzeughalter muss dafür sorgen, dass diese Daten verfügbar sind und die zugrunde liegenden Prozesse durchgeführt wurden.

—

Konstruktionsdaten,

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

Neben den Referenzdaten der Fahrzeuge sind die Daten, die den aktuellen Status des Fahrzeuges aufzeigen, die für den betrieblichen Einsatz wichtigsten Daten. Diese Daten müssen alle temporären Daten enthalten, z. B. Einschränkungen, laufende und geplante Instandhaltungsarbeiten, Kilometerstand und Fehlerzähler etc. sowie alle Daten, die als „Status” gelten können (vorübergehende Geschwindigkeitsbeschränkungen, isolierte Bremse, Reparaturbedarf und Fehlerbeschreibung etc.). Beachtet man die verschiedenen Parteien, die während des betrieblichen Einsatzes eines Fahrzeugs verantwortlich sind, so müssen für die Nutzung der betrieblichen Fahrzeugdaten drei verschiedene juristische Personengruppen berücksichtigt werden:

—: Eisenbahnverkehrsunternehmen als Gefahrenhalter während der Transportsteuerung,
—: Fahrzeughalter und
—: Nutzer (Mieter) eines Fahrzeugs.

Für alle drei Parteien müssen die betrieblichen Fahrzeugdaten für autorisierte Benutzer auf der Ebene seiner Autorisierung mittels eines einzelnen Schlüssels, der durch die Wagenkennung (Wagennummer) gegeben ist, zugänglich sein. Die betrieblichen Fahrzeugdaten sind Teil der europaweiten Betriebsdatenbank für Wagen und Intermodaleinheiten, wie in Kapitel 4.2.12.2 (Weitere Datenbanken) beschrieben.

4.2.12.
Diverse Referenzdateien und Datenbanken

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

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

—: Referenzdatei mit Codierung für alle IB, EVU und Dienstleistungsunternehmen,
—: Referenzdatei mit Codierung für Transportkunden,
—: Referenzdatei mit Codierungen aller Standorte (primäre, alternative und Bereichs-/Gleis-/Stelle-Angaben (ZTS)),
—: Referenzdatei mit Codierung für Kundenstandorte,
—: Referenzdatei aller bestehenden Zugsteuerungssysteme,
—: Referenzdatei der Gefahrgüter, UN- und RID-Nummern,
—: Referenzdatei aller verschiedenen Lokomotiventypen,
—: Referenzdatei aller CN- und HS-Codes für Güter,
—: Referenzdatei aller europäischen Instandhaltungswerke,
—: Referenzdatei aller europäischen Auditstellen,
—: Referenzdatei aller zugelassenen europäischen Betreiber einschließlich der entsprechenden Liste nationaler Sicherheitszertifikate.

Die Codierung von IB, EVU, Transportorganisationen und -unternehmen und Transportkunden sowie die Codierung der Standorte (primäre, alternative …) einschließlich Kundenstandorte stehen noch aus. Für die Verfolgung von Zug- und Wagenbewegungen müssen die folgenden Datenbanken eingerichtet werden, die jeweils sofort nach einem relevanten Ereignis zu aktualisieren sind. Autorisierte Rechtspersonen wie Wagenhalter und Flottenmanager müssen entsprechend den vertraglichen Bedingungen auf die verfügbaren Daten Zugriff haben, soweit diese zur Erfüllung ihrer Funktionen relevant sind.

—: Betriebsdatenbank für Wagen- und Intermodaleinheiten,
—: Datenbanken der Tourenpläne für Wagen/Intermodaleinheit.

Die Zugänglichkeit dieser Datenbanken erfolgt über die „gemeinsame Schnittstelle” (4.2.14.1: Vernetzung und Kommunikation und 4.2.14.7: Gemeinsame Schnittstelle). Die Kommunikation zwischen dem federführenden EVU und den EVU im Kooperationsmodus basiert auf den Nummern der Wagen- und/oder Intermodaleinheiten. Daher muss ein EVU, das auf Zugebene mit den IB kommuniziert, diese Informationen nach Wagen und Intermodaleinheiten aufschlüsseln. Diese aufgeschlüsselten Informationen müssen in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden. Die Informationen über Zugbewegungen führen zu neuen Einträgen/Aktualisierungen in der Betriebsdatenbank für Wagen- und Intermodaleinheiten zur Information für den Kunden. Der Bewegungsteil für einen Wagen oder einer Intermodaleinheit in der Datenbank wird spätestens dann erstellt, wenn der Kunde eine Freigabezeit für die Wagen/Intermodaleinheiten übermittelt. Diese Freigabezeit ist der erste Eintrag der Bewegungsdaten bezüglich eines aktuellen Zuglaufes in der Betriebsdatenbank für Wagen und Intermodaleinheiten. Die Meldungen für die Wagenbewegung sind in den Kapiteln 4.2.8 (Berichtswesen Wagenbewegung) und 4.2.9 (Berichtswesen Wagenübergang) definiert. Die Zugänglichkeit dieser Datenbanken erfolgt über die „gemeinsame Schnittstelle” (4.2.14.1: Allgemeine Architektur und 4.2.14.7: Gemeinsame Schnittstelle). Die Betriebsdatenbank für Wagen- und Intermodaleinheiten ist die wichtigste Datenbank zur Verfolgung der Wagen und somit für die Kommunikation zwischen den beteiligten EVU und dem federführenden EVU. Diese Datenbank zeigt die Bewegung eines Wagens und einer Intermodaleinheit vom Abfahrtsort bis zur endgültigen Lieferung am Abstellgleis des Empfängers mit PÜZ und Istzeiten an den verschiedenen Bahnhöfen bis hin zur endgültigen Auslieferungszeit PAZ beim Empfänger. Die Datenbank enthält zudem verschiedene Statusangaben für die Fahrzeuge, zum Beispiel:

—: Status: Beladung des Fahrzeugs

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

—: Status: Beladener Wagen ist unterwegs

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

—: Status: Leerer Wagen ist unterwegs

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

—: Status: Entladung des Fahrzeugs

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

—: Status: leerer Wagen unter Kontrolle eines Fuhrparkbetreibers

Diese Statusangabe wird benötigt, um die Informationen über verfügbare Fahrzeuge mit definierten Eigenschaften abrufen zu können. Züge transportieren normalerweise Wagen von verschiedenen Kunden. Für jeden Wagen muss das federführende EVU (das EVU, das als Dienstintegrator fungiert) einen Tourenplan, der den Zugtrassen auf Zugebene entspricht, erstellen und pflegen. Neue Zugtrassen für einen Zug, z. B. im Fall von Verkehrsunterbrechungen, führen zu neuen Tourenplänen für die betroffenen Wagen. Der Erstellungszeitpunkt für den Tourenplan ist der Empfang des Frachtbriefes vom Kunden. Der Wagen-Tourenplan muss bei jedem FEVU in einer Datenbank gespeichert werden. Die Zugänglichkeit dieser Datenbanken erfolgt über die „gemeinsame Schnittstelle” (4.2.14.1: Vernetzung und Kommunikation und 4.2.14.7: Gemeinsame Schnittstelle).

Bemerkung:

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

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

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

1.

Authentifizierung

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

2.

Datensicherheit

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

3.

Konsistenz

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

4.

Zugangskontrolle

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

5.

Protokollierung

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

6.

Sperrstrategie

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

7.

Mehrfachzugriff

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

8.

Zuverlässigkeit

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

9.

Verfügbarkeit

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

10.

Wartbarkeit

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

11.

Sicherheit

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

12.

Kompatibilität

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

13.

Importfunktion

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

14.

Exportfunktion

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

15.

Pflichtfelder

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

16.

Plausibilitätsprüfungen

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

17.

Antwortzeiten

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

18.

Leistungsaspekte

Eine Datenbank muss die Abfragen ermöglichen, die den effektiven Betrieb von 60000 Zugfahrten in 24 Stunden gestatten. Etwa 50 % dieser Zugfahrten dürfte sich innerhalb von zwei Stunden abspielen.

Anzahl und Art der Abfragen oder Aktualisierungen pro Zug richten sich nach dem Gesamtprozess für Planung und Betrieb eines Zuges.

19.

Kapazitätsaspekte

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

20.

Historische Daten

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

21.

Backup-Strategie

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

22.

Kaufmännische Aspekte

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

Bemerkungen:

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

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

4.2.13.
Elektronische Übertragung von Dokumenten

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

4.2.14.
Vernetzung und Kommunikation

Dieses Teilsystem wird im Lauf der Zeit das Entstehen, das Wachsen und Zusammenwirken einer großen und komplexen interoperablen Gemeinschaft auf dem Gebiet der Telematik im Bahnbereich mit Hunderten von Akteuren (EVU. IB, ...) erleben, die miteinander konkurrieren und/oder kooperieren, um die Erfordernisse des Marktes abzudecken. Die Netz- und Kommunikationsinfrastruktur, die einer solchen interoperablen Gemeinschaft auf dem Gebiet der Telematik im Bahnbereich zugrunde liegt, wird auf einer gemeinsamen Informationsaustauscharchitektur beruhen, die allen teilnehmenden Akteuren bekannt ist und von ihnen akzeptiert wird. Die vorgeschlagene Informationsaustauscharchitektur:

—: ist so ausgelegt, dass sie heterogene Informationsmodelle in Einklang bringt, indem sie die Semantik der zwischen den Systemen ausgetauschten Daten transformiert und Unterschiede zwischen den Geschäftsprozessen und den Anwendungsprotokollen ausgleicht;
—: hat minimale Auswirkungen auf die bestehenden IT-Architekturen bei den einzelnen Akteuren;
—: trägt zum Schutz bisheriger IT-Investitionen bei.

Die Informationsaustauscharchitektur favorisiert eine gleichberechtigte (Peer-to-Peer-) Interaktion zwischen allen Akteuren, und sie garantiert die Gesamtintegrität und -konsistenz der interoperablen Gemeinschaft im Bahnbereich, indem sie eine Reihe zentralisierter Dienste bereitstellt. Ein Peer-to-Peer-Interaktionsmodell erlaubt die beste Kostenverteilung zwischen den verschiedenen Akteuren auf der Grundlage der tatsächlichen Nutzung; zudem verursacht es wenige Probleme bei der Skalierbarkeit. Eine bildliche Darstellung der allgemeinen Architektur ist im Anhang A Ziffer 5 Kapitel 1.5 zu finden. Vernetzung bedeutet in diesem Fall die Kommunikationsmethode und -philosophie und bezieht sich nicht auf das physikalische Netzwerk. Die Interoperabilität im Bahnbereich beruht auf einer „gemeinsamen Informationsaustauscharchitektur” , die allen teilnehmenden Akteuren bekannt ist und von ihnen akzeptiert wird, was neue Akteure, insbesondere Kunden, ermutigt und die bestehenden Eintrittsbarrieren senkt. Die Sicherheitsfrage wird daher nicht im Netz (VPN, Tunnelling, ...) gelöst, sondern durch Austausch und Verwaltung inhärent sicherer Meldungen. Ein VPN-Netzwerk ist daher nicht erforderlich (große VPN-Netze erfordern eine enorm komplexe und kostspielige Verwaltung); so werden Probleme bei Verantwortlichkeiten und Zuordnung der Besitzverhältnisse vermieden. Ein Tunnelling ist nicht erforderlich, um eine angemessene Sicherheitsstufe zu erreichen. In jedem Fall haben die einzelnen Akteure die Möglichkeit, in ausgewählten Teilbereichen des Netzes mehrere Sicherheitsstufen einzurichten oder fortzuführen, wenn sie diese bereits besitzen. Über das öffentliche Internet lässt sich ein Peer-to-Peer-Hybridmodell mit einem „zentralen Speicher” und einer „gemeinsamen Schnittstelle” an den Knoten der einzelnen Akteure einrichten. Der zentrale Speicher wird zuerst angesprochen, um Meta-Informationen einzuholen, beispielsweise die Identität eines Peers (Akteurs), über den Informationen gespeichert werden, oder um Sicherheitsdaten nachzuprüfen. Anschließend wird eine Peer-to-Peer-Kommunikation zwischen den beteiligten Akteuren aufgebaut. Es dürfen nur Protokolle verwendet werden, die zur vollständigen Internet-Protokollsuite gehören.

Um ein hohes Sicherheitsniveau zu erreichen, müssen alle Meldungen eigenständig sein; das heißt, ihre Inhalte müssen gesichert sein und der Empfänger muss die Authentizität der Meldung nachprüfen können. Dies lässt sich mit einem Verschlüsselungs- und Signatursystem wie bei der E-Mail-Verschlüsselung erreichen. Das gestattet es, eine beliebige Art der Netzwerkübertragung zu verwenden, beispielsweise E-Mail, Dateitransfer (ftp, http) etc. Welcher Typ tatsächlich gewählt wird, liegt dann im Ermessen der am Informationsaustausch beteiligten Parteien. Es ist entweder eine asymmetrische Verschlüsselung oder eine Hybridlösung mit symmetrischer Verschlüsselung in Kombination mit einem öffentlichen Schlüssel zu verwenden, denn die gemeinsame Nutzung eines geheimen Schlüssels durch zahlreiche Akteure ist irgendwann zum Scheitern verurteilt. Ein höheres Sicherheitsniveau lässt sich leichter erreichen, wenn jeder Akteur die Verantwortung für sein eigenes Schlüsselpaar trägt, wenngleich in diesem Fall der zentrale Speicher (als Schlüssel-Server) ein hohes Maß an Integrität aufweisen muss. Der zentrale Speicher muss folgende Dinge handhaben können:

—: Metadaten — strukturierte Daten, die den Inhalt der Meldungen beschreiben;
—: Infrastruktur mit öffentlich hinterlegtem Schlüssel (PKI);
—: Zertifizierungsbehörde (CA);
—: Verzeichnis ( „Telefonbuch” ) — es enthält alle für den Meldungsaustausch benötigten Informationen über die teilnehmenden Akteure.

Die Verwaltung des zentralen Speichers sollte in der Zuständigkeit einer nichtkommerziellen, co-europäischen Stelle liegen. Die „gemeinsame Schnittstelle” ist für jeden Akteur verbindlich, um sich an der interoperablen Gemeinschaft im Bahnbereich zu beteiligen. Die gemeinsame Schnittstelle muss Folgendes bearbeiten können:

—: Formatierung abgehender Meldungen anhand der Metadaten,
—: Signatur und Verschlüsselung abgehender Meldungen,
—: Adressierung abgehender Meldungen,
—: Überprüfung der Authentizität eingehender Meldungen,
—: Entschlüsselung eingehender Meldungen,
—: Konformitätsprüfungen eingehender Meldungen anhand der Metadaten,
—: Behandlung des gemeinsamen Zugangs zu den verschiedenen Datenbanken.

Jede Instanz der gemeinsamen Schnittstelle hat dabei Zugang zu allen entsprechend der TSI erforderlichen Daten innerhalb jedes EVU, IB usw., gleichgültig, ob die relevanten Datenbanken zentral oder individuell sind (siehe auch Anhang A Index 5 Kapitel 1.6). Aufgrund der Ergebnisse aus der Authentizitätsprüfung eingehender Meldungen kann eine Minimalstufe für die Meldungsbestätigung eingerichtet werden:

i): positive Sendung: ACK
ii): negative Sendung: NACK.

Die gemeinsame Schnittstelle verwendet die Informationen im zentralen Speicher, um die oben beschriebenen Aufgaben zu erfüllen. Ein Akteur kann eine lokale „Spiegelung” des zentralen Speichers einrichten, um die Antwortzeiten zu verkürzen.

4.3.
Funktionelle und technische Spezifikationen zu den Schnittstellen

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

4.3.1.
Schnittstellen zum Teilsystem Infrastruktur

Das Teilsystem Infrastrukturen umfasst Verkehrssteuerungs-, Ortungs- und Navigationssysteme: technische Datenverarbeitungs- und Telekommunikationseinrichtungen, die für den Personenfernverkehr und den Güterverkehr auf diesem Netz zur Gewährleistung eines sicheren und ausgewogenen Netzbetriebs und einer wirksamen Verkehrssteuerung vorgesehen sind. Das Teilsystem Telematikanwendungen für den Güterverkehr benutzt die für betriebliche Zwecke erforderlichen Daten, wie sie vom IB bereitgestellt, im Trassenvertrag festgelegt und möglicherweise in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen aktualisiert sind. Es gibt also keine direkte Schnittstelle zwischen dieser TSI und der TSI Infrastruktur.

4.3.2.
Schnittstellen zum Teilsystem Zugsteuerung, Zugsicherung und Signalgebung

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

—: den Trassenvertrag, wo die einschlägigen Informationen über einsetzbare Zugsteuerungs-, Zugsicherungs- und Signalgebungstechnik in der Streckenabschnittsbeschreibung dargelegt sind, und über die
—: verschiedenen Fahrzeugreferenzdatenbanken, wo die Informationen über die fahrzeugseitige Zugsteuerungs-, Zugsicherungs- und Signalgebungstechnik gespeichert sein müssen.

4.3.3.
Schnittstellen zum Teilsystem Fahrzeuge

Das Teilsystem Telematikanwendungen für den Güterverkehr identifiziert die technischen und die betrieblichen Daten, die für ein Fahrzeug verfügbar sein müssen. Die TSI Fahrzeuge spezifiziert die Charakteristik eines Wagens. Wenn sich die Charakteristik eines Wagens ändert, so muss dies in der Fahrzeugreferenzdatenbank innerhalb des normalen Prozesses der Datenbankpflege aktualisiert werden. Daher existiert keine direkte Schnittstelle dieser TSI zur TSI Fahrzeuge.

4.3.4.
Schnittstellen zum Teilsystem Betrieb und Verkehrssteuerung

Das Teilsystem Betrieb und Verkehrssteuerung definiert die Verfahren und zugehörige Ausrüstungen, die eine kohärente Ausnutzung der verschiedenen strukturellen Teilsysteme erlauben, und zwar sowohl im Normalbetrieb als auch bei Betriebsstörungen, einschließlich insbesondere der Zugführung, der Planung und der Abwicklung des Verkehrsbetriebs. Das Teilsystem Telematikanwendungen für den Güterverkehr spezifiziert hauptsächlich Anwendungen für Dienstleistungen im Güterverkehr einschließlich Echtzeit-Überwachung der Güter und Züge und die Anschlüsse zu anderen Verkehrsträgern. Um die Konsistenz zwischen beiden TSI sicherzustellen, gilt folgendes Verfahren: Wenn die Spezifikationen der TSI Betrieb und Verkehrssteuerung in Bezug auf Anforderungen dieser TSI geschrieben sind und/oder ergänzt werden, dann muss die für diese TSI verantwortliche Stelle befragt werden. Für den Fall, dass die Spezifikationen dieser TSI in Bezug auf betriebliche Anforderungen in der TSI Betrieb und Verkehrssteuerung eine Erweiterung erfahren sollten, dann muss die für die TSI Betrieb und Verkehrssteuerung verantwortliche Stelle befragt werden.

4.4.
Betriebsvorschriften

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

4.4.1.
Datenqualität

Um die Datenqualität sicherzustellen, ist der Sender jeder TSI-Meldung verantwortlich für die Richtigkeit des Dateninhaltes der Meldung zum Zeitpunkt des Absendens der Meldung. Soweit Quelldaten zur Datenqualitätssicherung aus Datenbanken der TSI verfügbar sind, müssen die Daten dieser Datenbanken zur Sicherstellung der Datenqualität verwendet werden. Soweit Quelldaten zur Datenqualitätssicherung nicht von Datenbanken der TSI bereitgestellt werden, muss der Absender der Meldung die Überprüfung der Datenqualitätssicherung mit eigenen Mitteln vornehmen. Datenqualitätssicherung beinhaltet den Vergleich mit Daten aus Datenbanken dieser TSI sowie, soweit anwendbar, zusätzliche logische Prüfungen, um die Rechtzeitigkeit und Kontinuität der Daten und Meldungen zu garantieren. Daten sind von hoher Qualität, wenn sie für die beabsichtigte Nutzung geeignet sind, was bedeutet, dass sie

—: fehlerfrei sind: zugänglich, genau, zeitgerecht, vollständig, übereinstimmend mit anderen Quellen usw., und
—: die gewünschten Eigenschaften besitzen: sachbezogen, umfassend, genügend detailliert, leicht zu lesen, leicht zu verstehen usw.

Die Datenqualität ist hauptsächlich charakterisiert durch:

—: Genauigkeit,
—: Vollständigkeit,
—: Konsistenz,
—: Rechtzeitigkeit.

Die zu verarbeitenden Informationen (Daten) müssen möglichst ökonomisch erfasst werden. Das ist nur machbar, wenn die Primärdaten, die eine entscheidende Rolle bei der Beförderung einer Fracht, eines Wagens oder Containers spielen, nach Möglichkeit nur ein einziges Mal für den gesamten Transport erfasst werden. Daher sollten die Primärdaten so nahe wie möglich an ihrer Quelle eingegeben werden, z. B. Erstellung der Daten aus dem Frachtbrief, wenn ein Wagen oder eine Fracht zur Beförderung übergeben wird. Nach der Eingabe können die Daten voll in spätere Bearbeitungsgänge integriert werden. Vor dem Absenden von Meldungen muss ihre Vollständigkeit und Syntax anhand der Definitionen in den Metadaten geprüft werden. Dadurch wird unnötiger Informationsverkehr im Netz vermieden. Ebenso müssen alle eingehenden Meldungen auf Vollständigkeit mittels der Metadaten geprüft werden. Um die Vereinbarkeit zu garantieren, müssen Geschäftsregeln (Business Rules) implementiert werden. Doppelte Eingabe sollte vermieden werden, und der Eigentümer der Daten sollte klar feststellbar sein. Die Art der Implementierung dieser Geschäftsregeln hängt von der Komplexität der Regel ab. Für einfache Regeln sind Datenbankbeschränkungen (Constraints) und Trigger ausreichend. Im Falle komplexerer Regeln, die Daten aus verschiedenen Tabellen benötigen, müssen Gültigkeitserklärungsverfahren (Validation Procedures) implementiert werden, die die Vereinbarkeit der Datenversionen prüfen, bevor Schnittstellendaten erstellt werden und neue Versionen in Betrieb gehen. Es muss sichergestellt werden, dass übertragene Daten auf ihre Gültigkeit gegenüber den definierten Geschäftsregeln überprüft wurden. Die rechtzeitige Bereitstellung von Informationen ist ein wichtiger Punkt. Soweit der Anstoß zur Datenspeicherung oder dem Versand von Meldungen ereignisabhängig direkt vom IT-System ausgelöst wird, sollte die Rechtzeitigkeit kein Problem sein, wenn das System entsprechend den Erfordernissen der Geschäftsprozesse entworfen ist. Doch in den meisten Fällen erfolgt der Versand einer Meldung durch einen Bediener oder ist zumindest von zusätzlichen Eingaben eines Bedieners abhängig (zum Beispiel der Versand der Zugbildungsmeldung oder die Aktualisierung von zug- und wagenspezifischen Daten). Um die Pünktlichkeitsanforderungen zu erfüllen, muss die Aktualisierung der Daten so bald wie möglich erfolgen, auch um zu garantieren, dass die Meldungen aktuelle Inhalte haben, wenn sie automatisch vom System verschickt werden. Generell müssen folgende Anforderungen erfüllt sein: Die Antwortzeit bei Abfragen muss unter 5 Minuten liegen. Datenaktualisierung und Datenaustausch müssen so früh wie möglich erfolgen. Die Reaktions- und Übertragungszeit für solche Datenaktualisierungen sollte unter 1 Minute liegen. Für die Vollständigkeit (Prozent der Datenfelder, in denen Werte eingetragen sind) von obligatorischen Daten und für die Vereinbarkeit von Daten (Prozent der Datenfelder, die in mehreren Tabellen/Dateien/Datensätzen vorkommen und dort überall gleiche Werte aufzeigen) muss ein Prozentsatz von 100 % erreicht werden. Für die Rechtzeitigkeit von Daten (Prozent der Daten, die innerhalb eines spezifizierten Schwellen-Zeit-Rahmens verfügbar sein müssen) muss ein Prozentsatz von 98 % erreicht werden. Sofern Schwellenwerte nicht in dieser TSI definiert sind, müssen diese Werte in Verträgen zwischen den beteiligten Parteien festgelegt werden. Die erforderliche Genauigkeit (Prozent der gespeicherten Daten, die verglichen mit den aktuellen Werten übereinstimmen) muss über 90 % liegen. Der genaue Wert und die Kriterien dafür müssen in den Verträgen zwischen den beteiligten Parteien festgelegt werden.

4.4.2.
Betrieb des zentralen Speichers

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

4.5.
Wartungsvorschriften

Die funktionellen und technischen Spezifikationen zu den Schnittstellen sind im Hinblick auf die in Kapitel 3 angegebenen grundlegenden Anforderungen Folgende: Die Qualität des Güterverkehrs muss auch dann erhalten bleiben, wenn die Datenverarbeitungsanlagen ganz oder teilweise ausfallen. Es empfiehlt sich daher, Duplexsysteme oder Rechner mit besonders hoher Zuverlässigkeit zu installieren, für welche der unterbrechungsfreie Betrieb während Wartungsarbeiten sichergestellt ist. Die Instandhaltungsaspekte hinsichtlich der verschiedenen Datenbanken sind in Kapitel 4.2.12.3 (Zusätzliche Anforderungen an die Datenbanken), Punkte 10 und 21, beschrieben.

4.6.
Berufliche Qualifikationen

Für den Betrieb und die Wartung des betreffenden Teilsystems sowie für die Anwendung der TSI ist folgende berufliche Qualifikation erforderlich: Die Implementierung dieser TSI erfordert kein komplett neues System an Hardware und Software mit neuem Personal. Die Realisierung der Anforderungen der TSI führen lediglich zu Änderungen, Modernisierungen oder funktionalen Erweiterungen der Betriebsabläufe, wie sie bereits vom bestehenden Personal ausgeführt werden. Daher gibt es keine über die bestehenden nationalen und europäischen Regeln hinausgehenden Anforderungen an die berufliche Qualifikation. Ist eine praktische Schulung erforderlich, so sollte dabei den Beschäftigten nicht nur gezeigt werden, wie die Geräte bedient werden. Die Mitarbeiter müssen auch wissen und verstehen, welche spezifische Rolle sie im Gesamtablauf des Transports spielen. Die Beschäftigten müssen sich insbesondere darüber klar sein, dass sie eine anspruchsvolle Tätigkeit ausüben, die sich entscheidend auf die Qualität der Informationsverarbeitung in den nachfolgenden Schritten auswirkt. Die berufliche Qualifikation, die für die Zugbildung und den Betrieb der Züge notwendig ist, ist in der TSI Betrieb und Verkehrssteuerung festgelegt.

4.7.
Bedingungen für Arbeitshygiene und Sicherheit am Arbeitsplatz

Für das betreffende Personal bestehen hinsichtlich Sicherheit und Gesundheitshygiene am Arbeitsplatz während des Betriebs und der Wartung des betreffenden Teilsystems (bzw. bezüglich des technischen Anwendungsbereichs nach Abschnitt 1.1) sowie bei der Umsetzung der TSI folgende Anforderungen: Es bestehen keine über die existierenden nationalen und europäischen Regeln hinausgehenden Anforderungen bezüglich Arbeitshygiene und Sicherheit am Arbeitsplatz.

4.8.
Infrastruktur- und Fahrzeugregister

Laut Artikel 24, Absatz 1 der Richtlinie 2001/16/EG „müssen die Mitgliedstaaten dafür Sorge tragen, dass Infrastrukturregister und Fahrzeugregister veröffentlicht und jährlich aktualisiert werden. Darin werden für das jeweilige Teilsystem oder Teile davon die Hauptmerkmale und deren Übereinstimmung mit den in den anzuwendenden TSI vorgeschriebenen Merkmalen dargestellt. Zu diesem Zweck ist in jeder TSI genau anzugeben, welche Angaben die Infrastruktur- und Fahrzeugregister enthalten müssen.” Aufgrund der jährlichen Aktualisierung und Veröffentlichung dieser Register sind diese für das Teilsystem „Telematikanwendungen für den Güterverkehr” nicht nutzbar. Daher erfolgen in dieser TSI keine Angaben für diese Register.

5.
Interoperabilitätskomponenten

5.1.
Definition

Gemäß Artikel 2 Buchstabe d der Richtlinie 2001/16/EG gilt: Die Interoperabilitätskomponenten sind Bauteile, Bauteilgruppen, Unterbaugruppen oder komplette Materialbaugruppen, die in ein Teilsystem eingebaut sind oder eingebaut werden sollen und von denen die Interoperabilität des konventionellen transeuropäischen Eisenbahnsystems direkt oder indirekt abhängt. Unter „Komponenten” sind materielle, aber auch immaterielle Produkte wie Software zu verstehen.

5.2.
Liste der Komponenten

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

5.3.
Leistungsmerkmale und Spezifikationen der Komponenten

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

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

6.1.
Interoperabilitätskomponenten

6.1.1.
Bewertungsverfahren

Im Falle der Interoperabilitätskomponenten muss das Bewertungsverfahren für die Konformität bzw. die Gebrauchstauglichkeit auf europäischen Spezifikationen oder auf solchen Spezifikationen beruhen, die entsprechend den Regelungen der Richtlinie 2001/16/EG anerkannt sind. Handelt es sich um die Ermittlung der Gebrauchstauglichkeit, so geben diese Spezifikationen die Gesamtheit der Werte oder physikalischen Größen an, die zu messen, zu kontrollieren oder zu beobachten sind, ferner die dazugehörigen Versuchsmethoden und Messverfahren, sei es bei Versuchen im Labor oder auf der Strecke. Verfahren für die Bewertung der Konformität und/oder der Gebrauchstauglichkeit: Liste der Spezifikationen, Beschreibung der Versuchsmethoden:

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

6.1.2.
Module

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

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

6.2.
Teilsystem Telematikanwendungen für den Güterverkehr

Auf Verlangen des Auftraggebers oder seines in der Gemeinschaft ansässigen Bevollmächtigten führt die benannte Stelle entsprechend den Regelungen in Anhang VI der Richtlinie 2001/16/EG die EG-Prüfung durch. Entsprechend Anhang II der Richtlinie 2001/16/EG sind die Teilsysteme aufgeteilt in Teilsysteme des strukturellen Bereichs und Teilsysteme des operativen Bereichs. Die Konformitätsbewertung ist für TSI des strukturellen Bereichs verbindlich. Das Teilsystem Telematikanwendungen für den Güterverkehr gehört zum funktionellen Bereich, daher sind in dieser TSI keine Module zur Konformitätsbewertung erstellt. Jedoch bilden der zentrale Speicher und eine gemeinsame Schnittstelle zu den Knoten der jeweiligen Akteure das Rückgrat der Anwendungsintegration. Das Modell für den Informationsaustausch ist im zentralen Anwendungsintegrationsspeicher hinterlegt, der die Schnittstellen-Metadaten an einem physischen Ort enthält. Die Metadaten enthalten Informationen über den Kommunikationsinhalt (was sich in den gesendeten Daten befindet), die Kennungen der Absender und Empfänger sowie die Mechanik des Interaktionsprozesses der Geschäftsprotokolle auf Anwendungsebene. Folgende Punkte sind von Bedeutung:

—: Der zentrale Speicher enthält das Verzeichnis (Telefonbuch) aller am Meldungsaustausch teilnehmenden Akteure. Dieses Verzeichnis muss jederzeit auf aktuellem Stand sein. Falsche Einträge fallen sofort auf. Kein Bewertungsverfahren erforderlich.
—: Der zentrale Speicher enthält auch die Certification Authority (Open CA PKI). Dies ist im Wesentlichen ein administrativer Akt, der physisch implementiert ist. Falsche Einträge fallen sofort auf. Kein Bewertungsverfahren erforderlich.
—: Der zentrale Speicher enthält die Metadaten zu den Meldungen (gemäß Anhang A Anlagen E und F) als Basis für den Meldungsaustausch in einer heterogenen Informationsumgebung. Die Metadaten müssen im zentralen Speicher verwaltet und gepflegt werden. Eine Inkompatibilität in der Meldungsstruktur oder im Inhalt der Meldungen zum Senden und Empfangen der Daten wird sofort erkannt, und die Übertragung wird verweigert. Kein Bewertungsverfahren erforderlich.
—: Die gemeinsame Schnittstelle zu den Netzknoten der jeweiligen Akteure enthält jeweils eine lokale „Spiegelung” des zentralen Speichers zur Verkürzung der Antwortzeiten und Entlastung des Zentralspeichers. Es muss sichergestellt sein, dass die Datenversionen im zentralen Speicher und der gemeinsamen Schnittstelle immer identisch sind. Daher muss die Datenpflege im zentralen Speicher erfolgen, und die neuen Versionen müssen von dort heruntergeladen werden. Kein Bewertungsverfahren erforderlich.

7.
UMSETZUNG

7.1.
Modalitäten der Anwendung dieser TSI

7.1.1.
Einführung

Diese TSI betrifft das Teilsystem „Telematikanwendungen für den Güterverkehr” (im Folgenden „TAF TSI” ). Nach Anhang II der Richtlinie 2008/57/EG handelt es sich dabei um ein funktionales 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 bestimmt ist. Die TSI wird stufenweise implementiert:

— Phase 1:: detaillierte IT-Spezifikationen und Gesamtplan
— Phase 2:: Entwicklung
— Phase 3:: Einführung (deployment)

7.1.2.
Phase 1 — detaillierte IT-Spezifikationen und Gesamtplan

Die Spezifikationen für funktionale Anforderungen (Functional Requirement Specifications), die der oben genannten technischen Architektur bei Entwicklung und Einführung des Computersystems zugrunde gelegt werden, befinden sich in Anhang A Anlagen A bis F. Der obligatorische Gesamtplan vom Konzept bis zur Übergabe 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, Infrastrukturbetreiber und Wagenhalter entwickeln und führen gemäß den Bestimmungen von Kapitel 7 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. Aufgaben und Zuständigkeiten des Lenkungsausschusses:

1.

Der Lenkungsausschuss stellt die für eine effiziente Verwaltung und Koordinierung der Arbeiten zur Implementierung der TAF TSI 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, von neuen Marktteilnehmern und von Eisenbahnunternehmen, die besondere Dienste anbieten.

2.

Der Lenkungsausschuss überwacht den Stand der Implementierung. Er berichtet der Europäischen Kommission regelmäßig, jedoch mindestens viermal pro Jahr, über die Fortschritte im Vergleich zum Gesamtplan. Der Lenkungsausschuss leitet die erforderlichen Schritte ein, um die oben genannte Entwicklung im Fall der Abweichung vom Gesamtplan anzupassen.

3.

Der Lenkungsausschuss setzt sich zusammen aus

—: den auf europäischer Ebene tätigen Fachverbänden des Eisenbahnsektors gemäß Artikel 3 Absatz 2 der Verordnung (EG) Nr. 881/2004 ( „Fachverbände des Eisenbahnsektors” ),
—: der Europäischen Eisenbahnagentur und
—: der Kommission.

4.

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.

5.

Auf Vorschlag der Mitglieder des Lenkungsausschusses können weitere Organisationen als Beobachter hinzugezogen werden, wenn dies aus technischen und organisatorischen Gründen gerechtfertigt ist.

Eisenbahnunternehmen, Infrastrukturbetreiber und Wagenhalter richten eine leistungsfähige 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 Akteure:

—: Einleitung der erforderlichen Schritte zur Durchführung dieser Verordnung und Bereitstellung der dafür benötigten Ressourcen,
—: Einhaltung der Grundsätze für den Zugang zu den gemeinsamen Komponenten der TAF TSI, 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 funktionalen Anforderungen der TAF TSI benötigen,
—: Wahrung der Vertraulichkeit in Bezug auf Kundenbeziehungen,
—: Einrichtung einer Struktur, die 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 Akteure 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 Implementierungsplänen. Bei dieser Berichterstattung ist gegebenenfalls auch auf Abweichungen gegenüber dem Gesamtplan einzugehen.

Aufgaben und Zuständigkeiten der auf europäischer Ebene tätigen Fachverbände des Eisenbahnsektors im Sinne von Artikel 3 Absatz 2 der Verordnung (EG) Nr. 881/2004:

—: Vertretung der einzelnen Mitglieder im TAF-TSI-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 Akteure auf Informationen über den Stand der Arbeit des Lenkungsausschusses und etwaiger anderer Gruppen, um die Wahrung der Interessen jedes einzelnen Vertreters bei der Implementierung der TAF TSI sicherzustellen,
—: Gewährleistung eines effizienten Informationsflusses zwischen den einzelnen Mitgliedern und dem TAF-Lenkungsausschuss, damit die Interessen der Akteure bei Entscheidungen über die Entwicklung und Einführung der TAF gebührend berücksichtigt werden,
—: Gewährleistung eines effizienten Informationsflusses zwischen dem TAF-Lenkungsausschuss und den einzelnen Mitgliedern, damit die Akteure gebührend von den Entscheidungen über die Entwicklung und Einführung der TAF unterrichtet werden.

7.2.
Change Management

7.2.1.
Change-Management-Verfahren

Change-Management-Verfahren 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 für Change Management, Freigabe, Migration und Durchsetzung zu verfolgende Strategie,
—: die Zuständigkeitsverteilung für das Management der detaillierten Spezifikationen sowie für die Qualitätssicherung und das Konfigurationsmanagement.

Dem Änderungskontrollausschuss gehören die Europäische Eisenbahnagentur, Fachverbände des Eisenbahnsektors und nationale Sicherheitsbehörden an. Die Einbeziehung der Beteiligten in dieser Form soll sicherstellen, dass die durchzuführenden Änderungen systemisch betrachtet und ihre Auswirkungen umfassend bewertet werden. Die Kommission kann den Änderungskontrollausschuss erweitern, wenn dies für erforderlich gehalten wird. Der Änderungskontrollausschuss wird letzten Endes bei der Europäischen Eisenbahnagentur angesiedelt sein.

7.2.2.
Spezifisches Change-Management-Verfahren für die in Anhang A dieser Verordnung aufgeführten Dokumente

Die Änderungskontrolle für die in Anhang A dieser Verordnung aufgeführten Unterlagen wird von der Europäischen Eisenbahnagentur (ERA) anhand folgender Kriterien festgelegt:

1.: Die Änderungsanträge für die Unterlagen werden entweder von den nationalen Sicherheitsbehörden (NSA), den auf europäischer Ebene tätigen Fachverbänden des Eisenbahnsektors im Sinne von Artikel 3 Absatz 2 der Verordnung (EG) Nr. 881/2004 oder vom TAF-TSI-Lenkungsausschuss eingereicht. Die Kommission kann den Kreis der Antragsteller erweitern, wenn dies für erforderlich gehalten wird.
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 einen gegebenenfalls mit einer wirtschaftlichen Bewertung versehenen Vorschlag ausarbeitet.
4.: Anschließend legt die Europäische Eisenbahnagentur den Änderungsantrag und den damit verbundenen Vorschlag dem Änderungskontrollausschuss 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 sie 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 von Anhang A 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 der validierte Änderungsantrag werden von der Europäischen Eisenbahnagentur auf ihrer Website veröffentlicht.
9.: Nach der Veröffentlichung der Aktualisierung von Anhang A im Amtsblatt der Europäischen Union veröffentlicht die Europäische Eisenbahnagentur die neue Fassung des Dokuments auf ihrer Website.

Sind von der Änderungskontrolle allgemein gebräuchliche Elemente der TAF TSI betroffen, so sind die Änderungen so eng wie möglich an die TAF TSI anzulehnen, um optimale Synergien zu erzielen.

7.4.
Sonderfälle

7.4.1.
Einführung

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

7.4.2.
Verzeichnis der Sonderfälle

Auf dem Hoheitsgebiet von EU-Mitgliedstaaten, die an Drittländer angrenzen, sind die Anforderungen dieser TSI für Transporte, die direkt aus diesen Drittländern kommen oder in diese gehen (Fall „T offen” ), nicht bindend. Wenn jedoch der Transportweg in einem anderen EU-Mitgliedsstaat weitergeführt wird, müssen die Anforderungen dieser TSI vollständig erfüllt werden, vorausgesetzt, dass zwischen den betreffenden Staaten oder zwischen Eisenbahnverkehrsunternehmen und Infrastrukturbetreibern, die im Hoheitsgebiet dieser Mitgliedstaaten tätig sind, kein bilaterales oder multilaterales Abkommen besteht. Bei Transportfahrten auf Strecken mit Spurweite 1000 mm gelten die einzelstaatlichen Vorschriften.

Fußnote(n):

(1): ABl. L 75 vom 15.3.2001, S. 29. Richtlinie zuletzt geändert durch die Richtlinie 2004/49/EG (ABl. L 164 vom 30.4.2004, S. 44). Berichtigung im ABl. L 220 vom 21.6.2004, S. 16.
(2): ABl. L 220 vom 30.8.1993, S. 23.
(3): ABl. L 75 vom 15.3.2001, S. 26.
(4): ABl. L 237 vom 28.4.1991, S. 25. Richtlinie zuletzt geändert durch die Richtlinie 2004/51/EG des Europäischen Parlaments und des Rates (ABl. L 164 vom 30.4.2004, S. 164). Berichtigung im ABl. L 220 vom 21.6.2004, S. 58.
(5): Unter Abfahrtspunkt ist der Anfangspunkt der Trasse zu verstehen; dies kann entweder der Abfahrtsort des Zuges für die Gesamtfahrt oder ein Wagenübergangspunkt sein. Der Übergabepunkt ist der Endpunkt der Trasse.
(6): Der Zugang zu dieser Information muss unabhängig sein davon, welcher IB die Informationen bzw. Teile der Information abgespeichert hat.
(7): ABl. L 228 vom 9.9.1996, S. 1. Entscheidung zuletzt geändert durch die Entscheidung Nr. 884/2004/EG (ABl. L 167 vom 30.4.2004). Berichtigung im ABl. L 201 vom 7.6.2004, S. 1.

Schlussformel (nicht amtlich)ANHANG A

Tipp: Verwenden Sie die Pfeiltasten der Tastatur zur Navigation zwischen Normen.

TABELLEN: VO (EG) 2006/62

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

Das konventionelle transeuropäische Bahnsystem

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

1. EINFÜHRUNG

1.1. Technischer Anwendungsbereich

1.2.Geografischer Anwendungsbereich

1.3.Inhalt dieser TSI

2.DEFINITION DES TEILSYSTEMS/ANWENDUNGSBEREICH

2.1.In der TSI behandelte Funktionen

2.2.In der TSI nicht behandelte Funktionen

2.3.Übersicht über die Beschreibung des Teilsystems

2.3.1.Beteiligte Unternehmen

2.3.2.Betrachtete Prozesse

2.3.3.Allgemeine Anmerkungen

3.GRUNDLEGENDE ANFORDERUNGEN

3.1.Einhaltung der grundlegenden Anforderungen

3.2.Aspekte der grundlegenden Anforderungen

3.3.Allgemeine Anforderungen

3.3.1.Sicherheit

3.3.2.Zuverlässigkeit und Betriebsbereitschaft

3.3.3.Gesundheit

3.3.4.Umweltschutz

3.3.5.Technische Kompatibilität

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

3.4.1.Technische Kompatibilität

3.4.2.Zuverlässigkeit und Betriebsbereitschaft

3.4.3.Gesundheit

3.4.4.Sicherheit

4.BESCHREIBUNG DES TEILSYSTEMS

4.1.Einführung

4.2.Funktionelle und technische Spezifikationen zum Teilsystem

Allgemeine Anmerkungen zur Meldungsstruktur:

4.2.1.Frachtbriefdaten

4.2.2.Beantragung einer Trasse

4.2.3.Zugvorbereitung

4.2.4.Prognose zur Zugfahrt

4.2.5.Information über Verkehrsunterbrechung

4.2.6.Abfragen zum Zugstandort

4.2.7.Ladung PÜZ/PAZ

4.2.8.Berichtswesen Wagenbewegung

4.2.9.Berichtswesen Wagenübergang

4.2.10.Datenaustausch zur Qualitätsverbesserung

4.2.11.Die Hauptreferenzdaten

4.2.12.Diverse Referenzdateien und Datenbanken

4.2.13.Elektronische Übertragung von Dokumenten

4.2.14.Vernetzung und Kommunikation

4.3.Funktionelle und technische Spezifikationen zu den Schnittstellen

4.3.1.Schnittstellen zum Teilsystem Infrastruktur

4.3.2.Schnittstellen zum Teilsystem Zugsteuerung, Zugsicherung und Signalgebung

4.3.3.Schnittstellen zum Teilsystem Fahrzeuge

4.3.4.Schnittstellen zum Teilsystem Betrieb und Verkehrssteuerung

4.4.Betriebsvorschriften

4.4.1.Datenqualität

4.4.2.Betrieb des zentralen Speichers

4.5.Wartungsvorschriften

4.6.Berufliche Qualifikationen

4.7.Bedingungen für Arbeitshygiene und Sicherheit am Arbeitsplatz

4.8.Infrastruktur- und Fahrzeugregister

5.Interoperabilitätskomponenten

5.1.Definition

5.2.Liste der Komponenten

5.3.Leistungsmerkmale und Spezifikationen der Komponenten

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

6.1.Interoperabilitätskomponenten

6.1.1.Bewertungsverfahren

6.1.2.Module

6.2.Teilsystem Telematikanwendungen für den Güterverkehr

7.UMSETZUNG

7.1.Modalitäten der Anwendung dieser TSI

7.1.1.Einführung

7.1.2.Phase 1 — detaillierte IT-Spezifikationen und Gesamtplan

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

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

7.2.Change Management

7.2.1.Change-Management-Verfahren

7.2.2.Spezifisches Change-Management-Verfahren für die in Anhang A dieser Verordnung aufgeführten Dokumente

7.4.Sonderfälle

7.4.1.Einführung

7.4.2.Verzeichnis der Sonderfälle

1.

EINFÜHRUNG

1.1.

Technischer Anwendungsbereich

1.2.
Geografischer Anwendungsbereich

1.3.
Inhalt dieser TSI

2.
DEFINITION DES TEILSYSTEMS/ANWENDUNGSBEREICH

2.1.
In der TSI behandelte Funktionen

2.2.
In der TSI nicht behandelte Funktionen

2.3.
Übersicht über die Beschreibung des Teilsystems

2.3.1.
Beteiligte Unternehmen

2.3.2.
Betrachtete Prozesse

2.3.3.
Allgemeine Anmerkungen

3.
GRUNDLEGENDE ANFORDERUNGEN

3.1.
Einhaltung der grundlegenden Anforderungen

3.2.
Aspekte der grundlegenden Anforderungen

3.3.
Allgemeine Anforderungen

3.3.1.
Sicherheit

3.3.2.
Zuverlässigkeit und Betriebsbereitschaft

3.3.3.
Gesundheit

3.3.4.
Umweltschutz

3.3.5.
Technische Kompatibilität

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

3.4.1.
Technische Kompatibilität

3.4.2.
Zuverlässigkeit und Betriebsbereitschaft

3.4.3.
Gesundheit

3.4.4.
Sicherheit

4.
BESCHREIBUNG DES TEILSYSTEMS

4.1.
Einführung

4.2.
Funktionelle und technische Spezifikationen zum Teilsystem

4.2.1.
Frachtbriefdaten

4.2.2.
Beantragung einer Trasse

4.2.3.
Zugvorbereitung

4.2.4.
Prognose zur Zugfahrt

4.2.5.
Information über Verkehrsunterbrechung

4.2.6.
Abfragen zum Zugstandort

4.2.7.
Ladung PÜZ/PAZ

4.2.8.
Berichtswesen Wagenbewegung

4.2.9.
Berichtswesen Wagenübergang

4.2.10.
Datenaustausch zur Qualitätsverbesserung

4.2.11.
Die Hauptreferenzdaten

4.2.12.
Diverse Referenzdateien und Datenbanken

4.2.13.
Elektronische Übertragung von Dokumenten

4.2.14.
Vernetzung und Kommunikation

4.3.
Funktionelle und technische Spezifikationen zu den Schnittstellen

4.3.1.
Schnittstellen zum Teilsystem Infrastruktur

4.3.2.
Schnittstellen zum Teilsystem Zugsteuerung, Zugsicherung und Signalgebung

4.3.3.
Schnittstellen zum Teilsystem Fahrzeuge

4.3.4.
Schnittstellen zum Teilsystem Betrieb und Verkehrssteuerung

4.4.
Betriebsvorschriften

4.4.1.
Datenqualität

4.4.2.
Betrieb des zentralen Speichers

4.5.
Wartungsvorschriften

4.6.
Berufliche Qualifikationen

4.7.
Bedingungen für Arbeitshygiene und Sicherheit am Arbeitsplatz

4.8.
Infrastruktur- und Fahrzeugregister

5.
Interoperabilitätskomponenten

5.1.
Definition

5.2.
Liste der Komponenten

5.3.
Leistungsmerkmale und Spezifikationen der Komponenten

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

6.1.
Interoperabilitätskomponenten

6.1.1.
Bewertungsverfahren

6.1.2.
Module

6.2.
Teilsystem Telematikanwendungen für den Güterverkehr

7.
UMSETZUNG

7.1.
Modalitäten der Anwendung dieser TSI

7.1.1.
Einführung

7.1.2.
Phase 1 — detaillierte IT-Spezifikationen und Gesamtplan

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

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

7.2.
Change Management

7.2.1.
Change-Management-Verfahren

7.2.2.
Spezifisches Change-Management-Verfahren für die in Anhang A dieser Verordnung aufgeführten Dokumente

7.4.
Sonderfälle

7.4.1.
Einführung

7.4.2.
Verzeichnis der Sonderfälle