| zurück | |
4.2.9.5. Wagen am Übergangspunkt abgelehnt
| Zweck: | Mit der Meldung "Wagen am Übergangspunkt abgelehnt" informiert EVU 2 das EVU 1, dass es nicht bereit ist, die Verantwortung für den Wagen zu übernehmen. |
| Wichtigste Datenelemente: |
|
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:
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:
Die wichtigsten Meldungen für diese Qualitätsmessung sind:
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:
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:
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:
Die wichtigsten Meldungen für diese Qualitätsmessung sind:
6. IB/EVU: Zugbildungsqualität
Wenn die Zugfertig-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:
4.2.11. Die Hauptreferenzdaten
4.2.11.1. Vorbemerkung
Die Infrastrukturdaten (die Schienennetz-Nutzungsbedingungen und die gespeicherten Daten in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen) und die Fahrzeugdaten (in der Fahrzeugreferenzdatenbank und in der Betriebsdatenbank für Wagen und Intermodaleinheiten) sind die wichtigsten Daten für den Güterzugverkehr im Europäischen Schienennetz. Beide zusammen erlauben eine Bewertung der Kompatibilität der Fahrzeuge mit der Infrastruktur, unterstützen die Vermeidung von mehrfacher Dateneingabe, was insbesondere die Datenqualität erhöht, und geben zu jeder Zeit ein klares Bild über die verfügbaren Installationen und Ausrüstungen für schnelle Entscheidungen während des Betriebes.
4.2.11.2. Die Datenbank für Mitteilungen der Infrastrukturbeschränkungen 12
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.
4.2.11.3. Die Fahrzeugreferenzdatenbanken 12
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:
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:
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:
Der Fahrzeughalter muss dafür sorgen, dass diese Daten verfügbar sind und die zugrunde liegenden Prozesse durchgeführt wurden.
sie müssen alle konstruktiven (physischen) Elemente der Fahrzeuge enthalten, darunter auch die Umwelteigenschaften, und alle Informationen, die voraussichtlich während der gesamten Lebensdauer des Fahrzeugs gültig bleiben - dieser Teil kann eine Historie der größeren Umbauten, größeren Instandhaltungsarbeiten, Überholungen etc. enthalten.
4.2.11.4. Die Fahrzeugbetriebsdaten
Neben den Referenzdaten der Fahrzeuge sind die Daten, die den aktuellen Status des Fahrzeuges aufzeigen, die für den betrieblichen Einsatz wichtigsten Daten.
Diese Daten müssen alle temporären Daten enthalten, z.B. Einschränkungen, laufende und geplante Instandhaltungsarbeiten, Kilometerstand und Fehlerzähler etc. sowie alle Daten, die als "Status" gelten können (vorübergehende Geschwindigkeitsbeschränkungen, isolierte Bremse, Reparaturbedarf und Fehlerbeschreibung etc.).
Beachtet man die verschiedenen Parteien, die während des betrieblichen Einsatzes eines Fahrzeugs verantwortlich sind, so müssen für die Nutzung der betrieblichen Fahrzeugdaten drei verschiedene juristische Personengruppen berücksichtigt werden:
Für alle drei Parteien müssen die betrieblichen Fahrzeugdaten für autorisierte Benutzer auf der Ebene seiner Autorisierung mittels eines einzelnen Schlüssels, der durch die Wagenkennung (Wagennummer) gegeben ist, zugänglich sein.
Die betrieblichen Fahrzeugdaten sind Teil der europaweiten Betriebsdatenbank für Wagen und Intermodaleinheiten, wie in Kapitel 4.2.12.2 (Weitere Datenbanken) beschrieben.
4.2.12. Diverse Referenzdateien und Datenbanken
4.2.12.1. Referenzdateien
Für den Betrieb von Güterzügen auf dem europäischen Streckennetz müssen folgende Referenzdateien vorhanden und für alle Dienstleister (IB, EVU, Logistikanbieter und Fuhrparkbetreiber) zugänglich sein. Die Daten müssen jederzeit den aktuellen Status widerspiegeln.
Lokal gespeichert und verwaltet:
Zentral gespeichert und verwaltet:
Die Codierung von IB, EVU, Transportorganisationen und -unternehmen und Transportkunden sowie die Codierung der Standorte (primäre, alternative ...) einschließlich Kundenstandorte stehen noch aus.
4.2.12.2. Weitere Datenbanken
Für die Verfolgung von Zug- und Wagenbewegungen müssen die folgenden Datenbanken eingerichtet werden, die jeweils sofort nach einem relevanten Ereignis zu aktualisieren sind. Autorisierte Rechtspersonen wie Wagenhalter und Flottenmanager müssen entsprechend den vertraglichen Bedingungen auf die verfügbaren Daten Zugriff haben, soweit diese zur Erfüllung ihrer Funktionen relevant sind.
Die Zugänglichkeit dieser Datenbanken erfolgt über die "gemeinsame Schnittstelle" (4.2.14.1: Vernetzung und Kommunikation und 4.2.14.7: Gemeinsame Schnittstelle).
Betriebsdatenbank für Wagen und Intermodaleinheiten
Die Kommunikation zwischen dem federführenden EVU und den EVU im Kooperationsmodus basiert auf den Nummern der Wagen- und/oder Intermodaleinheiten. Daher muss ein EVU, das auf Zugebene mit den IB kommuniziert, diese Informationen nach Wagen und Intermodaleinheiten aufschlüsseln. Diese aufgeschlüsselten Informationen müssen in der Betriebsdatenbank für Wagen und Intermodaleinheiten gespeichert werden. Die Informationen über Zugbewegungen führen zu neuen Einträgen/Aktualisierungen in der Betriebsdatenbank für Wagen- und Intermodaleinheiten zur Information für den Kunden. Der Bewegungsteil für einen Wagen oder einer Intermodaleinheit in der Datenbank wird spätestens dann erstellt, wenn der Kunde eine Freigabezeit für die Wagen/Intermodaleinheiten übermittelt. Diese Freigabezeit ist der erste Eintrag der Bewegungsdaten bezüglich eines aktuellen Zuglaufes in der Betriebsdatenbank für Wagen und Intermodaleinheiten. Die Meldungen für die Wagenbewegung sind in den Kapiteln 4.2.8 (Berichtswesen Wagenbewegung) und 4.2.9 (Berichtswesen Wagenübergang) definiert. Die Zugänglichkeit dieser Datenbanken erfolgt über die "gemeinsame Schnittstelle" (4.2.14.1: Allgemeine Architektur und 4.2.14.7: Gemeinsame Schnittstelle).
Die Betriebsdatenbank für Wagen- und Intermodaleinheiten ist die wichtigste Datenbank zur Verfolgung der Wagen und somit für die Kommunikation zwischen den beteiligten EVU und dem federführenden EVU. Diese Datenbank zeigt die Bewegung eines Wagens und einer Intermodaleinheit vom Abfahrtsort bis zur endgültigen Lieferung am Abstellgleis des Empfängers mit PÜZ und Istzeiten an den verschiedenen Bahnhöfen bis hin zur endgültigen Auslieferungszeit PAZ beim Empfänger. Die Datenbank enthält zudem verschiedene Statusangaben für die Fahrzeuge, zum Beispiel:
Diese Statusangabe ist für den Informationsaustausch vom EVU zu den IB und den anderen an der Transportfahrt beteiligten Eisenbahnverkehrsunternehmen erforderlich.
Diese Statusangabe ist für den Informationsaustausch zwischen IB und EVU und den anderen an der Transportfahrt beteiligten Infrastrukturbetreibern und Eisenbahnverkehrsunternehmen erforderlich.
Diese Statusangabe ist für den Informationsaustausch zwischen IB und EVU und den anderen an der Transportfahrt beteiligten Infrastrukturbetreibern und Eisenbahnverkehrsunternehmen erforderlich.
Diese Statusangabe ist für den Informationsaustausch zwischen dem EVU auf der Zielseite und dem federführenden EVU für den Transport erforderlich.
Diese Statusangabe wird benötigt, um die Informationen über verfügbare Fahrzeuge mit definierten Eigenschaften abrufen zu können.
Datenbanken der Tourenpläne für Wagen
Züge transportieren normalerweise Wagen von verschiedenen Kunden. Für jeden Wagen muss das federführende EVU (das EVU, das als Dienstintegrator fungiert) einen Tourenplan, der den Zugtrassen auf Zugebene entspricht, erstellen und pflegen. Neue Zugtrassen für einen Zug, z.B. im Fall von Verkehrsunterbrechungen, führen zu neuen Tourenplänen für die betroffenen Wagen. Der Erstellungszeitpunkt für den Tourenplan ist der Empfang des Frachtbriefes vom Kunden.
Der Wagen-Tourenplan muss bei jedem FEVU in einer Datenbank gespeichert werden. Die Zugänglichkeit dieser Datenbanken erfolgt über die "gemeinsame Schnittstelle" (4.2.14.1: Vernetzung und Kommunikation und 4.2.14.7: Gemeinsame Schnittstelle).
Bemerkung:
Zusätzlich zu den oben erwähnten obligatorischen Datenbanken kann bei jedem IB eine Zugdatenbank installiert werden.
Die Zugdatenbank für den Infrastrukturbetreiber entspricht dem Wagenbewegungsanteil in der Betriebsdatenbank für Wagen und Intermodaleinheiten. Die wichtigsten Dateneinträge sind die zugbezogenen Daten aus der Zugbildungsmeldung vom EVU. Alle Zugereignisse führen zu einer Aktualisierung dieser zugspezifischen Datenbank. Eine alternative Speichermöglichkeit für diese Daten besteht in der Trassendatenbank (Kapitel 4.2.2: Beantragung einer Trasse). Die Zugänglichkeit dieser Datenbanken erfolgt über die "gemeinsame Schnittstelle" (4.2.14.1: Allgemeine Architektur und 4.2.14.7: Gemeinsame Schnittstelle).
4.2.12.3. Zusätzliche Anforderungen an die Datenbanken
Unter den folgenden Punkten sind zusätzliche Anforderungen aufgelistet, denen die verschiedenen Datenbanken gerecht werden müssen.
Dies sind:
Bemerkungen:
Die obigen Anforderungen sollten mit Einsatz eines Standard-Datenbank- Managementsystems (DBMS) erfüllt werden.
Die Nutzung der verschiedenen Datenbanken ist in verschiedene Arbeitsabläufe eingebettet, die vorher beschrieben wurden. Der allgemeine Arbeitsablauf ist ein Anfrage-/Antwortmechanismus, bei dem die interessierte Seite Informationen anfordert, und zwar über die gemeinsame Schnittstelle (4.2.14.1: Vernetzung und Kommunikation und 4.2.14.7: Gemeinsame Schnittstelle). Das DBMS antwortet auf diese Anfrage entweder mit der Bereitstellung der geforderten Daten oder damit, dass keine Daten zur Verfügung gestellt werden können (es existieren keine solchen Daten oder der Zugriff wird aufgrund der Zugangskontrolle zurückgewiesen).
4.2.13. Elektronische Übertragung von Dokumenten
Kapitel 4.2.14 (Vernetzung und Kommunikation) beschreibt das Kommunikationsnetz, das für den Datenaustausch zu verwenden ist. Dieses Netz und die beschriebene Sicherheitskonzeption gestatten die Verwendung eines beliebigen Übertragungsverfahrens, z.B. E-Mail, Dateitransfer (ftp, http) usw. Welches Verfahren gewählt wird, entscheiden dann die am Datenaustausch beteiligten Parteien; das heißt, dass die elektronische Übertragung von Dokumenten, beispielsweise durch ftp, gegeben ist.
4.2.14. Vernetzung und Kommunikation
4.2.14.1. Allgemeine Architektur
Dieses Teilsystem wird im Lauf der Zeit das Entstehen, das Wachsen und Zusammenwirken einer großen und komplexen interoperablen Gemeinschaft auf dem Gebiet der Telematik im Bahnbereich mit Hunderten von Akteuren (EVU. IB, ...) erleben, die miteinander konkurrieren und/oder kooperieren, um die Erfordernisse des Marktes abzudecken.
Die Netz- und Kommunikationsinfrastruktur, die einer solchen interoperablen Gemeinschaft auf dem Gebiet der Telematik im Bahnbereich zugrunde liegt, wird auf einer gemeinsamen Informationsaustauscharchitektur beruhen, die allen teilnehmenden Akteuren bekannt ist und von ihnen akzeptiert wird.
Die vorgeschlagene Informationsaustauscharchitektur:
Die Informationsaustauscharchitektur favorisiert eine gleichberechtigte (Peer-to-Peer-) Interaktion zwischen allen Akteuren, und sie garantiert die Gesamtintegrität und -konsistenz der interoperablen Gemeinschaft im Bahnbereich, indem sie eine Reihe zentralisierter Dienste bereitstellt.
Ein Peer-to-Peer-Interaktionsmodell erlaubt die beste Kostenverteilung zwischen den verschiedenen Akteuren auf der Grundlage der tatsächlichen Nutzung; zudem verursacht es wenige Probleme bei der Skalierbarkeit. Eine bildliche Darstellung der allgemeinen Architektur ist im Anhang A Ziffer 5 Kapitel 1.5 zu finden.
4.2.14.2. Netzwerk
Vernetzung bedeutet in diesem Fall die Kommunikationsmethode und -philosophie und bezieht sich nicht auf das physikalische Netzwerk.
Die Interoperabilität im Bahnbereich beruht auf einer "gemeinsamen Informationsaustauscharchitektur", die allen teilnehmenden Akteuren bekannt ist und von ihnen akzeptiert wird, was neue Akteure, insbesondere Kunden, ermutigt und die bestehenden Eintrittsbarrieren senkt.
Die Sicherheitsfrage wird daher nicht im Netz (VPN, Tunnelling, ...) gelöst, sondern durch Austausch und Verwaltung inhärent sicherer Meldungen. Ein VPN-Netzwerk ist daher nicht erforderlich (große VPN-Netze erfordern eine enorm komplexe und kostspielige Verwaltung); so werden Probleme bei Verantwortlichkeiten und Zuordnung der Besitzverhältnisse vermieden. Ein Tunnelling ist nicht erforderlich, um eine angemessene Sicherheitsstufe zu erreichen.
In jedem Fall haben die einzelnen Akteure die Möglichkeit, in ausgewählten Teilbereichen des Netzes mehrere Sicherheitsstufen einzurichten oder fortzuführen, wenn sie diese bereits besitzen.
Über das öffentliche Internet lässt sich ein Peer-to-Peer-Hybridmodell mit einem "zentralen Speicher" und einer "gemeinsamen Schnittstelle" an den Knoten der einzelnen Akteure einrichten.
Der zentrale Speicher wird zuerst angesprochen, um Meta-Informationen einzuholen, beispielsweise die Identität eines Peers (Akteurs), über den Informationen gespeichert werden, oder um Sicherheitsdaten nachzuprüfen. Anschließend wird eine Peer-to-Peer-Kommunikation zwischen den beteiligten Akteuren aufgebaut.
4.2.14.3. Protokolle
Es dürfen nur Protokolle verwendet werden, die zur vollständigen Internet-Protokollsuite gehören.
4.2.14.4. Datensicherheit
Um ein hohes Sicherheitsniveau zu erreichen, müssen alle Meldungen eigenständig sein; das heißt, ihre Inhalte müssen gesichert sein und der Empfänger muss die Authentizität der Meldung nachprüfen können. Dies lässt sich mit einem Verschlüsselungs- und Signatursystem wie bei der E-Mail-Verschlüsselung erreichen. Das gestattet es, eine beliebige Art der Netzwerkübertragung zu verwenden, beispielsweise E-Mail, Dateitransfer (ftp, http) etc. Welcher Typ tatsächlich gewählt wird, liegt dann im Ermessen der am Informationsaustausch beteiligten Parteien.
4.2.14.5. Verschlüsselung
Es ist entweder eine asymmetrische Verschlüsselung oder eine Hybridlösung mit symmetrischer Verschlüsselung in Kombination mit einem öffentlichen Schlüssel zu verwenden, denn die gemeinsame Nutzung eines geheimen Schlüssels durch zahlreiche Akteure ist irgendwann zum Scheitern verurteilt. Ein höheres Sicherheitsniveau lässt sich leichter erreichen, wenn jeder Akteur die Verantwortung für sein eigenes Schlüsselpaar trägt, wenngleich in diesem Fall der zentrale Speicher (als Schlüssel-Server) ein hohes Maß an Integrität aufweisen muss.
4.2.14.6. Zentraler Speicher
Der zentrale Speicher muss folgende Dinge handhaben können:
Die Verwaltung des zentralen Speichers sollte in der Zuständigkeit einer nichtkommerziellen, co-europäischen Stelle liegen.
4.2.14.7. Gemeinsame Schnittstelle
Die "gemeinsame Schnittstelle" ist für jeden Akteur verbindlich, um sich an der interoperablen Gemeinschaft im Bahnbereich zu beteiligen.
Die gemeinsame Schnittstelle muss Folgendes bearbeiten können:
Jede Instanz der gemeinsamen Schnittstelle hat dabei Zugang zu allen entsprechend der TSI erforderlichen Daten innerhalb jedes EVU, IB usw., gleichgültig, ob die relevanten Datenbanken zentral oder individuell sind (siehe auch Anhang A Index 5 Kapitel 1.6).
Aufgrund der Ergebnisse aus der Authentizitätsprüfung eingehender Meldungen kann eine Minimalstufe für die Meldungsbestätigung eingerichtet werden:
Die gemeinsame Schnittstelle verwendet die Informationen im zentralen Speicher, um die oben beschriebenen Aufgaben zu erfüllen.
Ein Akteur kann eine lokale "Spiegelung" des zentralen Speichers einrichten, um die Antwortzeiten zu verkürzen.
4.3. Funktionelle und technische Spezifikationen zu den Schnittstellen
Die funktionellen und technischen Spezifikationen zu den Schnittstellen sind im Hinblick auf die in Kapitel 3 angegebenen grundlegenden Anforderungen Folgende:
4.3.1. Schnittstellen zum Teilsystem Infrastruktur
Das Teilsystem Infrastrukturen umfasst Verkehrssteuerungs-, Ortungs- und Navigationssysteme: technische Datenverarbeitungs- und Telekommunikationseinrichtungen, die für den Personenfernverkehr und den Güterverkehr auf diesem Netz zur Gewährleistung eines sicheren und ausgewogenen Netzbetriebs und einer wirksamen Verkehrssteuerung vorgesehen sind.
Das Teilsystem Telematikanwendungen für den Güterverkehr benutzt die für betriebliche Zwecke erforderlichen Daten, wie sie vom IB bereitgestellt, im Trassenvertrag festgelegt und möglicherweise in der Datenbank für Mitteilungen der Infrastrukturbeschränkungen aktualisiert sind. Es gibt also keine direkte Schnittstelle zwischen dieser TSI und der TSI Infrastruktur.
4.3.2. Schnittstellen zum Teilsystem Zugsteuerung, Zugsicherung und Signalgebung
Die einzige Verbindung zur Zugsteuerung/Zugsicherung und Signalgebung besteht über
4.3.3. Schnittstellen zum Teilsystem Fahrzeuge
Das Teilsystem Telematikanwendungen für den Güterverkehr identifiziert die technischen und die betrieblichen Daten, die für ein Fahrzeug verfügbar sein müssen.
Die TSI Fahrzeuge spezifiziert die Charakteristik eines Wagens. Wenn sich die Charakteristik eines Wagens ändert, so muss dies in der Fahrzeugreferenzdatenbank innerhalb des normalen Prozesses der Datenbankpflege aktualisiert werden. Daher existiert keine direkte Schnittstelle dieser TSI zur TSI Fahrzeuge.
4.3.4. Schnittstellen zum Teilsystem Betrieb und Verkehrssteuerung
Das Teilsystem Betrieb und Verkehrssteuerung definiert die Verfahren und zugehörige Ausrüstungen, die eine kohärente Ausnutzung der verschiedenen strukturellen Teilsysteme erlauben, und zwar sowohl im Normalbetrieb als auch bei Betriebsstörungen, einschließlich insbesondere der Zugführung, der Planung und der Abwicklung des Verkehrsbetriebs.
Das Teilsystem Telematikanwendungen für den Güterverkehr spezifiziert hauptsächlich Anwendungen für Dienstleistungen im Güterverkehr einschließlich Echtzeit-Überwachung der Güter und Züge und die Anschlüsse zu anderen Verkehrsträgern.
Um die Konsistenz zwischen beiden TSI sicherzustellen, gilt folgendes Verfahren:
Wenn die Spezifikationen der TSI Betrieb und Verkehrssteuerung in Bezug auf Anforderungen dieser TSI geschrieben sind und/oder ergänzt werden, dann muss die für diese TSI verantwortliche Stelle befragt werden.
Für den Fall, dass die Spezifikationen dieser TSI in Bezug auf betriebliche Anforderungen in der TSI Betrieb und Verkehrssteuerung eine Erweiterung erfahren sollten, dann muss die für die TSI Betrieb und Verkehrssteuerung verantwortliche Stelle befragt werden.
4.4. Betriebsvorschriften
Angesichts der in Kapitel 3 angegebenen grundlegenden Anforderungen ergeben sich für das von der vorliegenden TSI betroffene Teilsystem folgende Betriebsvorschriften:
4.4.1. Datenqualität
Um die Datenqualität sicherzustellen, ist der Sender jeder TSI-Meldung verantwortlich für die Richtigkeit des Dateninhaltes der Meldung zum Zeitpunkt des Absendens der Meldung. Soweit Quelldaten zur Datenqualitätssicherung aus Datenbanken der TSI verfügbar sind, müssen die Daten dieser Datenbanken zur Sicherstellung der Datenqualität verwendet werden.
Soweit Quelldaten zur Datenqualitätssicherung nicht von Datenbanken der TSI bereitgestellt werden, muss der Absender der Meldung die Überprüfung der Datenqualitätssicherung mit eigenen Mitteln vornehmen.
Datenqualitätssicherung beinhaltet den Vergleich mit Daten aus Datenbanken dieser TSI sowie, soweit anwendbar, zusätzliche logische Prüfungen, um die Rechtzeitigkeit und Kontinuität der Daten und Meldungen zu garantieren.
Daten sind von hoher Qualität, wenn sie für die beabsichtigte Nutzung geeignet sind, was bedeutet, dass sie
Die Datenqualität ist hauptsächlich charakterisiert durch:
Genauigkeit:
Die zu verarbeitenden Informationen (Daten) müssen möglichst ökonomisch erfasst werden. Das ist nur machbar, wenn die Primärdaten, die eine entscheidende Rolle bei der Beförderung einer Fracht, eines Wagens oder Containers spielen, nach Möglichkeit nur ein einziges Mal für den gesamten Transport erfasst werden. Daher sollten die Primärdaten so nahe wie möglich an ihrer Quelle eingegeben werden, z.B. Erstellung der Daten aus dem Frachtbrief, wenn ein Wagen oder eine Fracht zur Beförderung übergeben wird. Nach der Eingabe können die Daten voll in spätere Bearbeitungsgänge integriert werden.
Vollständigkeit:
Vor dem Absenden von Meldungen muss ihre Vollständigkeit und Syntax anhand der Definitionen in den Metadaten geprüft werden. Dadurch wird unnötiger Informationsverkehr im Netz vermieden.
Ebenso müssen alle eingehenden Meldungen auf Vollständigkeit mittels der Metadaten geprüft werden.
Vereinbarkeit:
Um die Vereinbarkeit zu garantieren, müssen Geschäftsregeln (Business Rules) implementiert werden. Doppelte Eingabe sollte vermieden werden, und der Eigentümer der Daten sollte klar feststellbar sein.
Die Art der Implementierung dieser Geschäftsregeln hängt von der Komplexität der Regel ab. Für einfache Regeln sind Datenbankbeschränkungen (Constraints) und Trigger ausreichend. Im Falle komplexerer Regeln, die Daten aus verschiedenen Tabellen benötigen, müssen Gültigkeitserklärungsverfahren (Validation Procedures) implementiert werden, die die Vereinbarkeit der Datenversionen prüfen, bevor Schnittstellendaten erstellt werden und neue Versionen in Betrieb gehen. Es muss sichergestellt werden, dass übertragene Daten auf ihre Gültigkeit gegenüber den definierten Geschäftsregeln überprüft wurden.
Rechtzeitigkeit:
Die rechtzeitige Bereitstellung von Informationen ist ein wichtiger Punkt. Soweit der Anstoß zur Datenspeicherung oder dem Versand von g Meldungen ereignisabhängig direkt vom IT-System ausgelöst wird, sollte die Rechtzeitigkeit kein Problem sein, wenn das System entsprechend den Erfordernissen der Geschäftsprozesse entworfen ist. Doch in den meisten Fällen erfolgt der Versand einer Meldung durch einen Bediener oder ist zumindest von zusätzlichen Eingaben eines Bedieners abhängig (zum Beispiel der Versand der Zugbildungsmeldung oder die Aktualisierung von zug- und wagenspezifischen Daten). Um die Pünktlichkeitsanforderungen zu erfüllen, muss die Aktualisierung der Daten so bald wie möglich erfolgen, auch um zu garantieren, dass die Meldungen aktuelle Inhalte haben, wenn sie automatisch vom System verschickt werden.
Generell müssen folgende Anforderungen erfüllt sein:
Die Antwortzeit bei Abfragen muss unter 5 Minuten liegen. Datenaktualisierung und Datenaustausch müssen so früh wie möglich erfolgen. Die Reaktions- und Übertragungszeit für solche Datenaktualisierungen sollte unter 1 Minute liegen.
Daten-Qualitäts-Metrik
Für die Vollständigkeit (Prozent der Datenfelder, in denen Werte eingetragen sind) von obligatorischen Daten und für die Vereinbarkeit von Daten (Prozent der Datenfelder, die in mehreren Tabellen/Dateien/Datensätzen vorkommen und dort überall gleiche Werte aufzeigen) muss ein Prozentsatz von 100 % erreicht werden.
Für die Rechtzeitigkeit von Daten (Prozent der Daten, die innerhalb eines spezifizierten Schwellen-Zeit-Rahmens verfügbar sein müssen) muss ein Prozentsatz von 98 % erreicht werden. Sofern Schwellenwerte nicht in dieser TSI definiert sind, müssen diese Werte in Verträgen zwischen den beteiligten Parteien festgelegt werden.
Die erforderliche Genauigkeit (Prozent der gespeicherten Daten, die verglichen mit den aktuellen Werten übereinstimmen) muss über 90 % liegen. Der genaue Wert und die Kriterien dafür müssen in den Verträgen zwischen den beteiligten Parteien festgelegt werden.
4.4.2. Betrieb des zentralen Speichers
Die Funktionen des zentralen Speichers sind in Kapitel 4.2.14.6 (Zentraler Speicher) definiert. Zur Sicherstellung der Datenqualität sollte der Betreiber des zentralen Speichers verantwortlich sein für die Aktualisierung und die Qualität der Metadaten und des Verzeichnisses ("Telefonbuch") und auch für die Verwaltung der öffentlichen Zugriffsschlüssel (Public keys). Für die Metadaten muss ein Anteil von 100 % bezüglich Vollständigkeit, Vereinbarkeit, Rechtzeitigkeit und Genauigkeit erreicht werden.
4.5. Wartungsvorschriften
Die funktionellen und technischen Spezifikationen zu den Schnittstellen sind im Hinblick auf die in Kapitel 3 angegebenen grundlegenden Anforderungen Folgende:
Die Qualität des Güterverkehrs muss auch dann erhalten bleiben, wenn die Datenverarbeitungsanlagen ganz oder teilweise ausfallen. Es empfiehlt sich daher, Duplexsysteme oder Rechner mit besonders hoher Zuverlässigkeit zu installieren, für welche der unterbrechungsfreie Betrieb während Wartungsarbeiten sichergestellt ist.
Die Instandhaltungsaspekte hinsichtlich der verschiedenen Datenbanken sind in Kapitel 4.2.12.3 (Zusätzliche Anforderungen an die Datenbanken), Punkte 10 und 21, beschrieben.
4.6. Berufliche Qualifikationen
Für den Betrieb und die Wartung des betreffenden Teilsystems sowie für die Anwendung der TSI ist folgende berufliche Qualifikation erforderlich:
Die Implementierung dieser TSI erfordert kein komplett neues System an Hardware und Software mit neuem Personal. Die Realisierung der Anforderungen der TSI führen lediglich zu Änderungen, Modernisierungen oder funktionalen Erweiterungen der Betriebsabläufe, wie sie bereits vom bestehenden Personal ausgeführt werden. Daher gibt es keine über die bestehenden nationalen und europäischen Regeln hinausgehenden Anforderungen an die berufliche Qualifikation.
Ist eine praktische Schulung erforderlich, so sollte dabei den Beschäftigten nicht nur gezeigt werden, wie die Geräte bedient werden. Die Mitarbeiter müssen auch wissen und verstehen, welche spezifische Rolle sie im Gesamtablauf des Transports spielen. Die Beschäftigten müssen sich insbesondere darüber klar sein, dass sie eine anspruchsvolle Tätigkeit ausüben, die sich entscheidend auf die Qualität der Informationsverarbeitung in den nachfolgenden Schritten auswirkt.
Die berufliche Qualifikation, die für die Zugbildung und den Betrieb der Züge notwendig ist, ist in der TSI Betrieb und Verkehrssteuerung festgelegt.
4.7. Bedingungen für Arbeitshygiene und Sicherheit am Arbeitsplatz
Für das betreffende Personal bestehen hinsichtlich Sicherheit und Gesundheitshygiene am Arbeitsplatz während des Betriebs und der Wartung des betreffenden Teilsystems (bzw. bezüglich des technischen Anwendungsbereichs nach Abschnitt 1.1) sowie bei der Umsetzung der TSI folgende Anforderungen:
Es bestehen keine über die existierenden nationalen und europäischen Regeln hinausgehenden Anforderungen bezüglich Arbeitshygiene und Sicherheit am Arbeitsplatz.
4.8. Infrastruktur- und Fahrzeugregister
Laut Artikel 24, Absatz 1 der Richtlinie 2001/16/EG "müssen die Mitgliedstaaten dafür Sorge tragen, dass Infrastrukturregister und Fahrzeugregister veröffentlicht und jährlich aktualisiert werden. Darin werden für das jeweilige Teilsystem oder Teile davon die Hauptmerkmale und deren Übereinstimmung mit den in den anzuwendenden TSI vorgeschriebenen Merkmalen dargestellt. Zu diesem Zweck ist in jeder TSI genau anzugeben, welche Angaben die Infrastruktur- und Fahrzeugregister enthalten müssen."
Aufgrund der jährlichen Aktualisierung und Veröffentlichung dieser Register sind diese für das Teilsystem "Telematikanwendungen für den Güterverkehr" nicht nutzbar. Daher erfolgen in dieser TSI keine Angaben für diese Register.
5. Interoperabilitätskomponenten
5.1. Definition
Gemäß Artikel 2 Buchstabe d der Richtlinie 2001/16/EG gilt:
Die Interoperabilitätskomponenten sind "Bauteile, Bauteilgruppen, Unterbaugruppen oder komplette Materialbaugruppen, die in ein Teilsystem eingebaut sind oder eingebaut werden sollen und von denen die Interoperabilität des konventionellen transeuropäischen Eisenbahnsystems direkt oder indirekt abhängt. Unter ,Komponenten' sind materielle, aber auch immaterielle Produkte wie Software zu verstehen."
5.2. Liste der Komponenten
Die Interoperabilitätskomponenten sind Gegenstand der maßgebenden Bestimmungen der Richtlinie 2001/16/EG.
Im Teilsystem "Telematikanwendungen für den Güterverkehr" sind keine spezifischen Interoperabilitätskomponenten definiert.
Zur Erfüllung der Anforderungen dieser TSI wird nur herkömmliche IT-Ausrüstung benötigt, die keine spezifischen Aspekte für die Interoperabilität in der Eisenbahnumgebung aufweist. Dies gilt für Hardware-Komponenten und für die Standardsoftware, die bei Betriebssystemen und Datenbanken zum Einsatz kommt. Die Anwendungssoftware ist auf der Benutzerseite jeweils individuell und kann je nach Funktionalität und Bedarf angepasst und verbessert werden. Die vorgeschlagene "Anwendungsintegrationsarchitektur" unterstellt, dass die Anwendungen wahrscheinlich nicht dasselbe interne Informationsmodell benutzen. Anwendungsintegration ist definiert als ein Prozess, in dem unabhängig voneinander konstruierte Anwendungssysteme zu einer Zusammenarbeit gebracht werden.
5.3. Leistungsmerkmale und Spezifikationen der Komponenten
Siehe Kapitel 5.2, für die TSI "Telematikanwendungen für den Güterverkehr" nicht relevant.
6. Bewertung der Konformität und/oder Gebrauchstauglichkeit der Komponenten und Prüfung des Teilsystems
6.1. Interoperabilitätskomponenten
6.1.1. Bewertungsverfahren
Im Falle der Interoperabilitätskomponenten muss das Bewertungsverfahren für die Konformität bzw. die Gebrauchstauglichkeit auf europäischen Spezifikationen oder auf solchen Spezifikationen beruhen, die entsprechend den Regelungen der Richtlinie 2001/16/EG anerkannt sind.
Handelt es sich um die Ermittlung der Gebrauchstauglichkeit, so geben diese Spezifikationen die Gesamtheit der Werte oder physikalischen Größen an, die zu messen, zu kontrollieren oder zu beobachten sind, ferner die dazugehörigen Versuchsmethoden und Messverfahren, sei es bei Versuchen im Labor oder auf der Strecke.
Verfahren für die Bewertung der Konformität und/oder der Gebrauchstauglichkeit: Liste der Spezifikationen, Beschreibung der Versuchsmethoden:
Für die TSI Telematikanwendungen für den Güterverkehr nicht relevant.
6.1.2. Module
Auf Verlangen des Herstellers oder seines in der Gemeinschaft ansässigen Bevollmächtigten hat das Bewertungsverfahren durch eine benannte Stelle entsprechend den Regelungen über die maßgebenden Module laut Entschließung des Rates 93/465/EWG zu erfolgen, wie sie in modifizierter und ergänzter Form im Anhang dieser TSI wiedergegeben sind.
Die Module werden je nach Komponente selektiv miteinander verbunden und benutzt. Für die TSI Telematikanwendungen für den Güterverkehr nicht relevant.
6.2. Teilsystem Telematikanwendungen für den Güterverkehr 12
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:
| weiter . | |