SBN_31_Anlage 14d_Zug_Land_Kommunikation.docx

Anforderungen an die

Zug-Land-Kommunikation

Inhaltsverzeichnis

1 Vorbemerkungen 3

1.1 Regelungsbereiche der automatischen Fahrgastzählung 3

1.2 Gegenstand und Abgrenzung dieses Dokumentes 3

2 Anforderungen an die Zug-Land-Kommunikation 4

2.1 Allgemeine Anforderungen 4

2.2 Anforderung an die Architektur der ZLK 4

2.3 Anforderung an das Gateway 4

3 Zug-Land-Kommunikation per Datenfunk 5

3.1 Grundsätzliche Anforderung 5

3.2 Datenübertragung vom fahrzeugseitiges AFZS an das Hintergrundsystem 5

3.3 Ablauf der Datenübertragung 5

3.4 Datensicherheit 6

3.5 Adressierung 6

3.6 http-Aufruftypen 6

3.7 http-Aufruf 6

3.7.1 http-Aufruf "poll" seitens Hintergrundsystem 6

3.7.2 http-Aufruf "push" seitens fahrzeugseitigem AFZS 7

3.8 http-Antworten 7

3.8.1 http-Antwort auf push 7

3.8.2 http-Antwort auf poll vom Hintergrundsystem 8

4 Projektspezifische Realisierung 9

Anhang: Mitgeltende Dokumente, Abkürzungsverzeichnis und Glossar 10

Vorbemerkungen

Die Erfassung der Ein- und Aussteiger an den Türen der Fahrzeuge bildet die Basis der automatischen Fahrgastzählung (AFZ).

Neben der Ermittlung der Ein- und Aussteiger in den Fahrzeugen umfasst die AFZ, wie nachfolgend dargestellt, auch die Bereiche Zug-Land-Kommunikation und Hintergrundsystem.

1.1 Regelungsbereiche der automatischen Fahrgastzählung

Die AFZ gliedert sich in die nachfolgenden Regelungsbereiche:

• Ermittlung der Ein- und Aussteiger durch die AFZS in den Fahrzeugen
• Zug-Land-KommunikationDie Kommunikation zwischen den AFZS in den Fahrzeugen und dem Hintergrundsystem (Zug-Land-Kommunikation „ZLK“) erfolgt über eine Luftschnittstelle per Datenfunk.
• Hintergrundsystem Ziel dieses Dokumentes

Ziel dieses Dokumentes ist es, einerseits für den Verantwortungsbereich der BEG einen einheitlichen Standard für die AFZS in den Fahrzeugen zu definieren und andererseits den Eisenbahnverkehrsunternehmen (EVU) ein Basislastenheft bereitzustellen, mit dessen Hilfe es ihnen ermöglicht wird, AFZS bzw. Fahrzeuge mit AFZS zu beschaffen, die die für die AFZS definierten Standards erfüllen.

1.2 Gegenstand und Abgrenzung dieses Dokumentes

Gegenstand dieses Dokumentes ist die Kommunikation zwischen den AFZS in den Fahrzeugen und dem Hintergrundsystem (Zug-Land-Kommunikation „ZLK“).

Anforderungen an die Zug-Land-Kommunikation

Allgemeine Anforderungen

Für die Zug-Land-Kommunikation (ZLK) muss ein datenfunkbasiertes Verfahren zur Anwendung kommen, dass

• in der betrieblichen Praxis erprobt ist,
• öffentliche Standards und keine proprietären Kommunikationsprotokolle nutzt,
• die Standards zur IT-Sicherheit erfüllt,
• den Datenversand vom AFZS an das Hintergrundsystem vollautomatisch durchführt und
• sicherstellt, dass die Erhebungsdaten vollständig und zeitnah nach Verlassen des jeweiligen Haltes aus den Fahrzeugen an das Hintergrundsystem übertragen werden.

Darüber hinaus muss sichergestellt werden, dass die gewählte Kommunikationsvariante mindestens für die Nutzungsdauer des AFZS verfügbar ist. Dies betrifft auch die Verfügbarkeit von Übertragungsdiensten der Provider.

Die ZLK muss so realisiert werden, dass bei einem Wechsel des Hintergrundsystems ein neues Hintergrundsystem in die bestehende ZLK integriert werden kann ohne Änderungen an den fahrzeugseitigen Kommunikationseinrichtungen vornehmen zu müssen.

Anforderung an die Architektur der ZLK

Vor dem Hintergrund der vorstehenden Anforderungen wird gefordert, dass die ZLK aus

• der Fahrzeugkomponente,
• einem landseitigen Gateway und
• einer Komponente im Hintergrundsystem

bestehen muss.

Anforderung an das Gateway

Für das Gateway wird gefordert, dass es grundsätzlich in der Lage sein muss, die aus den fahrzeugseitigen AFZS empfangenen Erhebungs- und Statusdatensätze (AFZ-Daten) im Fall eines Ausfalls des Hintergrundsystems für mindestens 120 Tage in einer Queue zwischenzuspeichern.

Zug-Land-Kommunikation per Datenfunk

Grundsätzliche Anforderung

Für die ZLK kann das EVU die nachfolgend spezifizierte Kommunikationsvariante nutzen. Alternativ kann das EVU aber auch ein anderes Kommunikationsverfahren nutzen, das die vorstehenden Anforderungen erfüllt. Dieses ist aber im Rahmen der Pflichtenheftabstimmung zwischen dem Auftragnehmer und dem EVU mit seiner projektspezifischen Realisierung zu dokumentieren, offen zu legen und für die uneingeschränkte Nutzung durch das EVU und die BEG freizugeben.

Datenübertragung vom fahrzeugseitiges AFZS an das Hintergrundsystem

Aus den fahrzeugseitigen AFZS werden nach jedem Halt AFZ-Daten an das Hintergrundsystem übertragen. Hierfür kann die im Folgenden spezifizierte Datenübertragung per http genutzt werden. Dabei ist zu beachten, dass die Kommunikation vom fahrzeugseitigen AFZS an das Hintergrundsystem über ein zwischengeschaltetes landseitiges Gateway (Gateway) als Client-Server-Kommunikation realisiert wird, bei der sowohl das fahrzeugseitige AFZS als auch das Hintergrundsystem als Clients und das Gateway als Server definiert sind. Die fachliche Architektur ist in der folgenden Abbildung 1 dargestellt.

Abbildung 1: Fachliche Architektur für die Datenübertragung vom fahrzeugseitigen AFZS an das Hintergrundsystem

Über die Datenübertragung per http können sowohl Dateien als auch Kurznachrichten übertragen werden, wobei die zu übertragenden AFZ-Daten auf Grund der geringen Größe (< 1.000 Byte) grundsätzlich als Kurznachrichten übertragen werden sollen.

Ablauf der Datenübertragung

Die Datenübertragung zwischen dem fahrzeugseitigen AFZS und dem Hintergrundsystem erfolgt über http-Transaktionen über das Gateway. Dazu muss sowohl das fahrzeugseitige AFZS als auch das Hintergrundsystem eine TCP/IP-Verbindung als Socket-Verbindung zum Gateway aufbauen.

Ist die Datenverbindung aufgebaut, erfolgt die Datenübertragung vom fahrzeugseitigen AFZS an das Hintergrundsystem per http-push-Transaktion. Dabei gilt, dass:

• die Daten von fahrzeugseitigen AFZS (Client) mit http-post zum Gateway (Server) gesendet und
• vom Hintergrundsystem (Client) vom Gateway (Server) mit http-get geholt werden.

Dabei wird der Datenkanal dem jeweils anderen Client über das Gateway verfügbar gemacht, so dass die Datenübertragung grundsätzlich von einem Client des Gateways (fahrzeugseitiges AFZS) zum anderen Client des Gateways (Hintergrundsystem) oder umgekehrt aus einem http-post von der einen Seite und einem gleichzeitigen http-get von der anderen Seite besteht. Die für die Datenübertragung genutzten http-Aufruftypen und http-Antworten sind unter dem nachfolgenden Punkt 3.7 definiert.

Datensicherheit

Zur Sicherung des Transportkanals soll Transport Layer Security (TLS) mit Zwei-Wege-Authentifizierung (Client- und Server-Zertifikat) zum Einsatz kommen. Entsprechend sind das TLS Handshake Protocol und das TLS Alert Protocol unter Beachtung der in der TLS spezifizierten Warnungen und Fehlertypen zu beachten.

Adressierung

Da die fahrzeugseitigen AFZS nur AFZ-Daten an das Hintergrundsystem versenden, ist zur Unterscheidung von ggf. vorhandenen anderen Hintergrundsystemen das Anwendungsschlüsselwort "AFZ-BO" zu verwenden.

http-Aufruftypen

Die Kommunikation wird über folgende http-Aufruftypen umgesetzt:

"poll" seitens Hintergrundsystem:

Zum Empfang von Daten soll das Hintergrundsystem poll verwenden

"push" seitens fahrzeugseitigem AFZS:

Zum Senden von AFZ-Daten an das Hintergrundsystem wird immer push verwendet.

http-Aufruf

http-Aufruf "poll" seitens Hintergrundsystem

http-Aufruf - URLs

Je nach Realisierung im Gateway kann es vorkommen, dass für die Unterscheidung der http-Transaktionstypen verschiedene Server-URLs benötigt werden. Dies sind im vorliegenden Fall:

• Server-Adresse (zwingend) und ggf. Einstiegspunkt der Anwendung
• URL-Erweiterung Aufruftyp (zulässiger Wert "poll")
• URL-Erweiterung Absender (zwingend eindeutige ID des Clients)
• URL-Erweiterungen und URL-Parameter für Adressierung und Steuerung.

URL-Erweiterungen werden durch "/" getrennt an Server-URL und ggf. Servlet-Namen angehängt.

http-Aufruf - Acknowledge-ID

Je nach Realisierung im Gateway kann es vorkommen, dass beim Polling eine vorangegangene erfolgreiche Übertragung vom Server an den Client mit einer ID bestätigt werden muss, die der Server dem Client vorher mit dem Datensatz übergeben hat. Sollte diese ID im realisierten Gateway benötigt werden, muss diese bei einem neuen poll, wenn zuvor ein erfolgreicher Datenempfang per poll stattgefunden hat, übertragen werden. Der Wert wird durch das Gateway festgelegt.

http-Aufruf - Abbruchzeit ("künstlicher" Timeout)

Wurde eine verschlüsselte Verbindung für poll aufgebaut, so sollte sie für mehrere Aufrufe in Serie verwendet werden, um Systemressourcen für Neuaufbau sowie Zeit einzusparen. Die Weiterverwendung ist aber nur möglich, wenn die Verbindung noch steht. Um dies sicher festzustellen, wird jede poll-Verbindung mit einem definierten "künstlichen" Timeout beendet, d.h. eine Rückmeldung vom Server am Ende des Intervalls, die gleichzeitig signalisiert, dass die Verbindung noch steht.

Nach Ablauf des Timeout bricht das Gateway Poll-Anfragen mit http-Code größer oder gleich 400 ab. Der Client kann dann einen neuen Aufruf durchführen ohne bei https die verschlüsselte Verbindung neu aufbauen zu müssen. Der Wert muss im Client konfigurierbar gestaltet werden. Die URL-Parameter "Timeout" enthält die Zeit in Sekunden.

http-Aufruf - Nicht-protokollspezifische Header-Parameter

• http-Aufruf - Content-Length Obligatorischer Teil des Protokolls. Die Länge muss mit der tatsächlichen Länge des Daten-Body in seiner Byterepräsentation übereinstimmen, sonst ist ein korrekter Empfang der Daten nicht gewährleistet.
• http-Aufruf - Content-Type Vorgegebener Wert: "application/octet-stream" Die Nachrichten sind prinzipiell als Binärdaten anzusehen, die nur durch die als Adressat angegebene Anwendung ausgewertet werden. Die Nachrichten im Textformat werden aber generell mit Codierung UTF-8 übertragen.

http-Aufruf "push" seitens fahrzeugseitigem AFZS

http-Aufruf - URLs

• Server-Adresse (zwingend) und ggf. Einstiegspunkt der Anwendung
• URL-Erweiterung Aufruftyp (zwingender Wert "push")
• URL-Erweiterung Absender (UIC-Fahrzeugnummer des führenden Fahrzeuges)
• URL-Erweiterungen und URL-Parameter für Adressierung und Steuerung.

http-Aufruf - Absender-Geräte-ID

Eindeutige Kennzeichnung des sendenden Rechners. Zwingend für alle push und poll.

• Absender fahrzeugseitiges AFZS

Als Absender-Geräte-ID sollte die Fahrzeugnummer des sendenden Fahrzeugs verwendet werden.

http-Aufruf - Parameter für die Adressierung Client an Server

http-Aufruf - Ziel-Geräte-ID

Eindeutige Kennzeichnung des adressierten Rechners (URL-Parameter "Recipient"). Zwingend für alle push.

• Empfänger Backoffice-System: „AFZ-BO"

http-Antworten

http-Antwort auf push

http-Header-Code 200 für "Ok"

• ohne Daten
• Content-Length 0, d.h. es ist auch kein Text oder dgl. im Daten-Body enthalten.

Sind entgegen der Vorschrift Daten enthalten, werden diese vom Client entgegengenommen, um den Socket frei zu machen, aber sofort verworfen. Die Übertragung wird in dem Fall als misslungen angesehen und wie "Nicht Ok" behandelt.

http-Header-Code größer oder gleich 400 für "Nicht Ok"

• ohne Daten
• Content-Lenght 0, d.h. es ist auch kein Text oder dgl. im Daten-Body enthalten.

http-Antwort auf poll vom Hintergrundsystem

http-Header-Code 200 für "Ok, Nutzdatenübertragung"

• mit Daten
• mit passender Content-Length
• mit Acknowledge-Id

Danach wird fortgesetzt:

• mit poll

Die ggf. empfangene Acknowledge-Id wird mit dem nächsten poll und allen weiteren mitgesendet, bis ein neuer Datenempfang eintritt.

http-Header-Code größer oder gleich 400 für "Keine Nutzdatenübertragung"

• ohne Daten
• Content-Lenght 0
• keine Acknowledge-Id, d.h. es wird auch kein Fehlertext oder dgl. im Daten-Body gesendet.

Projektspezifische Realisierung

Für die projektspezifische Realisierung der Zug-Land-Kommunikation ist durch den Auftragnehmer ein Pflichtenheft zu erstellen und mit dem EVU und dem Betreiber des zur Anwendung kommenden Gateways abzustimmen. Im Rahmen dieser Abstimmung sind auch die spezifischen Antwortcodes und die spezifischen Besonderheiten abzustimmen. Nach erfolgter Abstimmung ist das Pflichtenheft im Rahmen der Übergabe der Dokumentation der BEG zur uneingeschränkten Nutzung zu übergeben.

Anhang: Mitgeltende Dokumente, Abkürzungsverzeichnis und Glossar

A 1 Mitgeltende Dokumente

Dieses Basislastenheft gilt nur zusammen mit einen Projektbasislastenheft, in dem die zu erfüllenden Anforderungen dieses Basislastenheftes festgelegt werden, und einer weiteren Anlage zum Projektbasislastenheft, die die Anforderungen an die Datenfunk-Kommunikation spezifiziert.

Darüber hinaus sind die nachfolgenden Normen und Vorschriften einzuhalten.

A 2 Glossar

Folgende Begriffe bedeuten u. a. in diesem Dokument:

A 3 Abkürzungsverzeichnis

Folgende Abkürzungen wurden in diesem Dokument verwandt: