Train Real Time Data Protocol
Template:Infobox Netzwerkprotokoll
Train Real Time Data Protocol was developed by the IEC Working Group TC9 / WG43 as part of the TCN and standardized in IEC61375-2-3.[1].Well-known manufacturers and suppliers of rolling stock for rail traffic are involved in the development and standardization.The activities are coordinated by the 'Train Communication Network Open Source Special Interest Group' under the abbreviation TCNOpen. TCNOpen is an open-source initiative founded by the railway industry partners, with the aim of jointly developing key components for the upcoming railway communication standards.[2]A reference implementation in 'C' is available under the open source Mozilla license MPL2 as "TRDP Light" on the platform SourceForge.[3][4]
Process Data (PD)[edit]
TRDP process data are sent cyclically at minimum 10 ms intervals as UDP packets on port 17224. Senders are referred to as 'Publishers' or 'Sources', Receivers as 'Subscribers' or 'Sinks'. Various communication patterns are supported.
PD push[edit]
-
Process Data push point-to-point
-
TRDP Process Data Push point-to-multipoint
The 'Publisher' sends regularly to a 'Subscriber'. If no more data is received within a defined time period (e.g. in case of a network outage, a 'timeout' is triggered and the received data is either marked as obsolete or reset to zero. In addition, the subscriber can recognize from a sequence number in the message whether the packet is new or a duplicate of a redundant transmitter, which is then ignored.
Using IP-Multicast, publishers can reach many subscribers who have subscribed to a multicast group. This allows entire groups of devices to be synchronously controlled by a sender.
PD pull[edit]
A request telegram can be used to force the transmission of process data. The publisher must then also send the data outside of the set cycle times. The telegrams requested by the pull mechanism have a different identifier ('Pp' instead of 'Pd').
Multicast addressing allows multiple publishers to be addressed simultaneously. The reply address can also be a multicast group.
PD telegram format[edit]
Process data telegrams consist of a header and the user data (including an optional SDT trailer (Safe Data Transmission))[5]
SequenceCounter: Will be incremented with each transmitted telegram.
MsgType: 'Pr' = PD Request, 'Pp' = PD Reply, 'Pd' = PD Data.
ComId: Application-specific, defines content of the data, interval and timeout of the telegram.
etbTopoCnt: 0 for Consist internal communication. In case of train-wide communication, it is the CRC over the 'Train Network Directory' and it is checked for validity both at the sender and at the receiver.
opTrnTopoCnt: Necessary for telegrams with direction related information. It is the CRC via the 'Operational Train Directory'.
DatasetLength: 0...1432 Bytes.
ReplyComID / ReplyIpAddress: For pull telegrams, to specify the PD Reply to be sent.
HeaderFCS: CRC32 according to IEEE802.3, start value 0xFFFFFFFF, inverse and always in Little Endian Format.
Dataset: Max. 1432 bytes of data.
All data are transmitted in 'Network byte order' (Big Endian), with exception of the FCS.
Message Data (MD)[edit]
TRDP message data are event driven via UDP or TCP on port 17225. Senders are called 'Requesters' or 'Callers'. Receivers are called 'Listeners' or 'Repliers'. Various communication patterns are supported.
MD communication pattern[edit]
The sender does not expect any response when sending a 'notification'. Whether the message has reached the addressee or not, cannot be verified by the sender (with UDP).
In case of a 'request' the caller can verify when receiving a 'reply' whether the message arrived or not (verification also through the expiration of a timer when an answer is missing). The replier may request the caller to confirm the receipt of the message. This is important if the reply has caused a change in the status of the replier which may need to be undone. 
If messages are exchanged more frequently with the same end-devices, it makes sense to use a TCP connection instead of UDP for message data communication.
The maximum data size to be transferred is limited to 64k (even for TCP connections).
Multicast addresses can be used for message data traffic over UDP:
The caller can specify how many replies he expects.
MD telegramm format[edit]
Process data telegrams consist of a header and the user data (including an optional SDT trailer (Safe Data Transmission)).[5]
SequenceCounter: Will be incremented with each transmitted telegram.
MsgType: 'Mn' = MD Notification, 'Mr' = MD Request with Reply, 'Mp' = MD Reply without Confirmation, 'Mq' = MD Reply with Confirmation, 'Mc' = MD Confirmation, 'Me' = MD Error.
ComId: Application-specific, defines content of the data, interval and timeout of the telegram.
etbTopoCnt: 0 for Consist internal communication. In case of train-wide communication, it is the CRC over the 'Train Network Directory' and it is checked for validity both at the sender and at the receiver.
opTrnTopoCnt: Necessary for telegrams with direction related information. It is the CRC via the 'Operational Train Directory'.
DatasetLength: 0...65388 Bytes.
ReplyStatus: shall be set by the replier to report the execution result of a request message or by the caller sending a confirmation.
SessionId: UUID according to RFC 4122, uniquely identifies an MD session.
ReplyTimeOut: in µs.
SourceURI: User part of the source URI (part before the @).
DestinationURI: User part of the target URI (part before @).
HeaderFCS: CRC32 according to IEEE802.3, start value 0xFFFFFFFF, inverse and always in Little Endian Format.
Dataset: Max. 65388 Bytes an Daten.
All data are transmitted in 'Network byte order' (Big Endian), with exception of the FCS.
General Information[edit]
PD as MD telegrams can optionally be used for "secure" communication according to SIL2 with a safe data layer. The IEC61375-2-3 Annex B defines the Safe Data Transmission protocol SDTv2.
The use of TRDP via Ethernet according to IEC61375-2-3 is obligatory (normative) for the communication between consists and optional for the use within Consists.
References[edit]
- ↑ http://www.iec.ch/dyn/www/f?p=103:38:0::::FSP_ORG_ID,FSP_LANG_ID:1248,25#
- ↑ www.tcnopen.eu
- ↑ "TCNOpen". SourceForge. Retrieved 2019-03-20.
- ↑ "NewTecTrainsolutions". www.newtec.de. Retrieved 2019-03-20.
- ↑ 5.0 5.1 "IEC 61375-2-3 (2015-07) Ed. 1.0 - englisch - IEC Normen Shop". www.iec-normen.de. Retrieved 2016-03-14.
https://de.wikipedia.org/wiki/Train_Real_Time_Data_Protocol
This article "Train Real Time Data Protocol" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Train Real Time Data Protocol. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.
