Train Real Time Data Protocol
| Train Real Time Data Protocol | |
|---|---|
| Familie: | Internetprotokollfamilie |
| Einsatzfeld: | Datenübertragung im TCN |
| aufbauend auf | 17224/UDP Process Data (PD), 17225/UDP o. TCP Message Data (MD) (Transport) |
| aktuelle Version: | 2.1.0.0 (2021) |
| Standard: | IEC61375-2-3 (2015) |
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 IP Train Wire Protocol (IPTWP) 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]
Prozessdaten (PD)
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]
-
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
[Bearbeiten | Quelltext bearbeiten]
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
[Bearbeiten | Quelltext bearbeiten]Prozessdaten-Telegramme bestehen aus einem Kopf und den Nutzdaten (inkl. einem optionalen SDT-Trailer (Safe Data Transmission))[4].
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
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)
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]Wird eine 'Notification' gesendet, erwartet der Sender keine Antwort. Ob die Nachricht den Adressaten erreicht hat, kann der Sender (bei UDP) nicht feststellen.
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.
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
[Bearbeiten | Quelltext bearbeiten]Message-Daten-Telegramme bestehen aus einem Kopf und den Nutzdaten (inkl. einem optionalen SDT-Trailer (Safe Data Transmission)).[4]
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,[5] 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
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]- ↑ iec.ch
- ↑ www.tcnopen.eu
- ↑ TCNOpen. In: SourceForge. Abgerufen am 20. März 2019.
- ↑ a b IEC 61375-2-3 (2015-07) Ed. 1.0. In: iec-normen.de. Archiviert vom (nicht mehr online verfügbar) am 23. März 2016; abgerufen am 14. März 2016 (englisch). Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.
- ↑ RFC – A Universally Unique IDentifier (UUID) URN Namespace. Juli 2005 (englisch).
