Train Real Time Data Protocol

Das Train Real Time Data Protocol (TRDP) ist ein Netzwerkprotokoll für die Kommunikation über IP-basierte Netzwerke in Zügen und ist Teil des TCN (Train Communication Network). Es setzt auf UDP und optional auf TCP auf und ermöglicht den Austausch von Prozessdaten (PD) und Message-Daten (MD) zwischen Geräten wie Türsteuerungen, Displays, Klimaanlagen usw. TRDP ist ein verbindungsloses, rahmenorientiertes Protokoll und bildet die Basis für die Kommunikation in zukünftigen Zügen. Als Vorläufer gilt das proprietäre IPTCom-Protokoll der Firma Bombardier Transportation, von dem TRDP viele Merkmale übernimmt.

Das Protokoll wurde von der Working Group TC9/WG43 des IEC als Teil des TCN entwickelt und in IEC61375-2-3 standardisiert^[1]. Beteiligt an der Entwicklung und Standardisierung sind namhaften Hersteller und Zulieferer von rollendem Material für den Bahnverkehr.
Die Aktivitäten werden von der 'Train Communication Network Open Source Special Interest Group' unter dem Kürzel TCNOpen koordiniert. TCNOpen ist eine von den Partnern der Eisenbahn-Industrie gegründete Open-Source Initiative, die als Ziel die gemeinsame Entwicklung von Schlüsselkomponenten für die kommenden Kommunikationsstandards im Bahnbereich hat.^[2]
Eine Referenzimplementierung in 'C' steht unter der quelloffenen Mozilla Lizenz MPL2 als "TRDP Light" auf der Plattform SourceForge zur Verfügung.^[3][4]

Prozessdaten (PD)

TRDP-Prozessdaten werden mit minimal 10-ms-Intervallen als UDP-Pakete auf Port 17224 zyklisch gesendet. Sender werden als 'Publisher' oder 'Source' bezeichnet, Empfänger als 'Subscriber' oder 'Sink'. Verschiedene Kommunikations-Muster (Communication Pattern) werden unterstützt.

PD push

Process Data push point-to-point

Process Data push point to multipoint

• 

  Process Data push point-to-point

• 

  TRDP Process Data Push point-to-multipoint

Der 'Publisher' sendet regelmäßig an einen 'Subscriber'. Wenn innerhalb eines definierten Zeitraums keine Daten mehr empfangen werden, z. B. bei einem Netzwerkausfall, wird ein 'Timeout' ausgelöst und die empfangenen Daten als entweder veraltet gekennzeichnet oder auf null zurückgesetzt. Zusätzlich kann der Subscriber anhand einer Sequenznummer in der Nachricht erkennen, ob das Paket neu ist oder ein Duplikat eines redundanten Senders, welches dann ignoriert wird.

Mittels IP-Multicast können Publisher viele Subscriber erreichen, die eine Multicast-Gruppe abonniert haben. Damit können ganze Gruppen von Geräten von einem Sender aus synchron gesteuert werden.

PD pull

Process Data pull point-to-point

Process Data pull point-to-multipoint

Mittels eines Request-Telegramms kann das Senden von Prozessdaten erzwungen werden. Der Publisher muss die Daten dann auch außerhalb der eingestellten Zykluszeiten senden. Die Telegramme, die durch den 'Pull'-Mechanismus angefordert wurden, tragen eine andere Kennung ('Pp' anstatt 'Pd', siehe).

Mittels Multicast-Adressierung können mehrere Publisher gleichzeitig angesprochen werden; die Reply-Adresse kann auch wiederum eine Multicast-Gruppe sein.

PD Telegramm Format

Prozessdaten-Telegramme bestehen aus einem Kopf und den Nutzdaten (inkl. einem optionalen SDT-Trailer (Safe Data Transmission))^[5].

SequenceCounter: Wird mit jedem gesendeten Telegramm erhöht

MsgType: 'Pr' = PD Request, 'Pp' = PD Reply, 'Pd' = PD Data

ComId: Applikations-Spezifisch, definiert Inhalt der Daten, Intervall und Timeout des Telegramms

TRDP Process Data Format

etbTopoCnt: 0 für Consist-interne Kommunikation. Bei zugweiter Kommunikation ist dies der CRC über das 'Train Network Directory' und wird sowohl beim Sender wie auch beim Empfänger auf Gültigkeit überprüft.

opTrnTopoCnt: Notwendig für Telegramme mit richtungsabhängigen Informationen. Dies ist der CRC über das 'Operational Train Directory'.

DatasetLength: 0...1432 Bytes

ReplyComID / ReplyIpAddress: Für Pull-Telegramme, zum Bestimmen des zusendenden PD Reply

HeaderFCS: CRC32 nach IEEE802.3, Startwert 0xFFFFFFFF, invers und immer im Little Endian Format

Dataset: Max. 1432 Bytes an Daten

Alle Daten werden in 'Network byte order' (Big Endian) übertragen, mit Ausnahme des FCS.

Message-Daten (MD)

TRDP Message-Daten werden ereignisgesteuert über UDP oder TCP auf Port 17225 übertragen. Sender werden als 'Requester' oder 'Caller' bezeichnet, Empfänger als 'Listener' oder 'Replier'. Verschiedene Kommunikations-Muster (Communication Pattern) werden unterstützt.

MD communication pattern

Wird eine 'Notification' gesendet, erwartet der Sender keine Antwort. Ob die Nachricht den Adressaten erreicht hat, kann der Sender (bei UDP) nicht feststellen.

Message-Daten Kommunikation Point-to-Point

Bei einem 'Request' erfährt der Caller mit dem Reply, ob die Nachricht ankam (oder durch den Ablauf eines Timers das Fehlen der Antwort). Der Replier kann vom Caller eine Bestätigung über den Erhalt der Nachricht anfordern. Dies ist wichtig, falls der Reply eine Statusänderung des Repliers verursacht hat und diese eventuell rückgängig gemacht werden muss.

Message-Daten Kommunikation Multipoint

Werden häufiger Nachrichten mit denselben Endgeräten ausgetauscht, macht es Sinn, eine TCP-Verbindung anstatt UDP für die Message-Daten-Kommunikation zu verwenden.

Die maximale zu übertragende Datengröße ist auf 64k beschränkt (auch bei TCP-Verbindungen).

Bei Message-Daten Verkehr über UDP sind auch Multicast-Adressen möglich:

Der Caller kann angeben, wie viele Replies er erwartet.

MD Telegramm Format

Message-Daten-Telegramme bestehen aus einem Kopf und den Nutzdaten (inkl. einem optionalen SDT-Trailer (Safe Data Transmission))^[5].

TRDP Message Data Header Format

SequenceCounter: Wird mit jedem gesendeten Telegramm erhöht

MsgType: 'Mn' = MD Notification, 'Mr' = MD Request mit Reply, 'Mp' = MD Reply ohne Confirmation, 'Mq' = MD Reply mit Confirmation, 'Mc' = MD Confirmation, 'Me' = MD Error

ComId: Applikations-Spezifisch, definiert Inhalt der Daten, Intervall und Timeout des Telegramms

etbTopoCnt: 0 für Consist-interne Kommunikation. Bei zugweiter Kommunikation ist dies der CRC über das 'Train Network Directory' und wird sowohl beim Sender wie auch beim Empfänger auf Gültigkeit überprüft.

opTrnTopoCnt: Notwendig für Telegramme mit richtungsabhängigen Informationen. Dies ist der CRC über das 'Operational Train Directory'.

DatasetLength: 0...65388 Bytes

ReplyStatus:

SessionId: UUID nach RFC 4122, identifiziert eine MD Session eindeutig

ReplyTimeOut: in µs

SourceURI: User part der Quell-URI (Teil vor dem @)

DestinationURI: User part der Ziel-URI (Teil vor dem @)

HeaderFCS: CRC32 nach IEEE802.3, Startwert 0xFFFFFFFF, invers und immer im Little Endian Format

Dataset: Max. 65388 Bytes an Daten

Alle Daten werden in 'Network byte order' (Big Endian) übertragen, mit Ausnahme der FCS.

Allgemeine Informationen

PD wie MD Telegramme können optional zur "sicheren" Kommunikation gemäß SIL2 mit einer Sicherungsschicht verwendet werden. In der IEC61375-2-3 wird dazu im Annex B das Safe Data Transmission Protokoll SDTv2 definiert.

Die Verwendung von TRDP ist für die Kommunikation zwischen Zugteilen (Consists) über Ethernet nach IEC61375-2-3 obligatorisch (normativ), für die Verwendung innerhalb Consists optional.

Einzelnachweise

1. ↑ http://www.iec.ch/dyn/www/f?p=103:38:0::::FSP_ORG_ID,FSP_LANG_ID:1248,25#
2. ↑ www.tcnopen.eu
3. ↑ TCNOpen. In: SourceForge. Abgerufen am 20. März 2019. 
4. ↑ NewTecTrainsolutions. In: www.newtec.de. Abgerufen am 20. März 2019. 
5. ↑ ^{a b} IEC 61375-2-3 (2015-07) Ed. 1.0 - englisch - IEC Normen Shop. In: www.iec-normen.de. Abgerufen am 14. März 2016.