User:DUBAELE MATHEU/Train Real Time Data Protocol

Train Real Time Data Protocol (TRDP) is a communication protocol based on IP network for trains. It is a part of the Train Communication Network (TCN). Based on UDP and optionnaly on TCP, it allows to transmit Process Data (PD) and Message Data (MD) between devices on train (Door Control Unit, displays, HVAC, etc.). TRDP is a connectionless, frame-oriented protocol and forms the basis for communication on future trains. The forerunner is Bombardier Transportation's proprietary IPTCom protocol, of which TRDP handles many features.

The protocol was developed by the TC9 / WG43 Working Group of the IEC as part of the TCN and standardized in IEC61375-2-3.1. Participating in the development and standardization are well-known manufacturers and suppliers of rolling stock for rail traffic. 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 rail industry partners, with the goal of jointly developing key components for upcoming rail communication standards.2 A reference implementation in 'C' is available under the open source license Mozilla MPL2 as "TRDP Light" on the SourceForge platform.

Process Data (PD)
The data from the TRDP process is sent cyclically at 10 ms intervals as UDP packets on port 17224. Senders are referred to as "publisher" or "source", recipients as "subscriber" or "receiver". Various communication patterns are supported.

PD push


The  sender  regularly sends a  subscriber . If no data is received within a defined period of time, for example B. in the event of a network outage, a 'timeout' is triggered and the received data is marked stale or reset to zero. Also, the subscriber can use a sequence number in the message to see if the packet is new or a duplicate from a redundant sender, which is then ignored.

Using IP Multicast, senders can reach many subscribers who have subscribed to a multicast group. This allows complete groups of devices to be controlled in sync from one transmitter.

PD pull


A  request telegram  can be used to force the transmission of process data. The sender must also send the data outside of the established cycle times. The  telegrams  requested by the  pull  mechanism have a different identifier ('Pp' instead of 'Pd', see).

Multicast addressing allows multiple editors to address simultaneously; the answering address can also be a multicast group.

PD Telegramm Format


Process data telegrams consist of a header and user data (including an optional SDT trailer (Secure Data Transmission)).


 *  'SequenceCounter:'  Increments with each transmitted telegram


 *  'MsgType:' 
 * *  'PR'  = PD Request
 * *  'PP'  = PD Reply
 * *  'PD'  = PD Data


 *  'ComId:'  Application specific, defines data content, interval and telegram timeout  'etbTopoCnt:'  0 for constant internal communication. In the case of remote communication, this is the CRC through the 'Directory of the train network' and its validity is verified on both the sender and the recipient.


 *  'opTrnTopoCnt:'  Required for telegrams with directional information. This is the CRC on 'Operational Train Directory'.


 *  'DatasetLength:'  0 to 1432 Bytes


 *  'ReplyComID'  /  'ReplyIpAddress:'  For extraction telegrams, to determine the send reply PD


 *  'HeaderFCS:'  CRC32 according to IEEE802.3, starts the value 0xFFFFFFFF, inverse and always in little endian format


 *  'Dataset:'  Max. 1432 Bytes of data

All data is transmitted in 'Network Byte Order' (Big Endian), except for FCS.

Message Data (MD)
The TRDP message data is event driven via UDP or TCP on port 17225. The channels are called 'requestor' or 'caller', receiver 'listener' or 'receiver'. Various communication patterns are supported.

MD communication pattern


When a 'notification' is sent, the sender does not expect a response. The sender cannot determine whether the message has reached the recipient (in the case of UDP). When a request is made, the caller learns with the response, if the message arrived (or when a timer expires the absence of the response). The response may request that the caller confirm receipt of the message. This is important if the response has caused a change in the response state and may need to be rolled back.

If you frequently exchange messages with the same devices, it makes sense to use a TCP connection instead of UDP for message data communication.

The maximum size of data to transfer is limited to 64k (even for TCP connections).

For message data traffic in UDP, multicast addresses are also possible:

The caller can specify how many responses to expect.

MD Telegramm Format
Process data telegrams consist of a header and user data (including an optional trailer SDT (Safe Data Transmission)). *  'SequenceCounter:'  Increments with each transmitted telegram *  '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:'  Application specific, defines data content, interval and telegram timeout *  'etbTopoCnt:'  0 for internal communication Consist. In the case of remote communication, this is the CRC through the 'Directory of the train network' and its validity is verified in both the sender and the recipient *  'opTrnTopoCnt:'  Required for telegrams with directional information. This is the CRC on 'Operational Train Directory'. *  'DatasetLength:'  0 to 65388 Bytes *  'ReplyStatus'  *  'SessionId:'  UUID according to RFC 4122, uniquely identifies an MD session *  'ReplyTimeOut:'  in µs *  'SourceURI:'  User part of source URI (part before @) *  'DestinationURI:'  User part of target URI (part before @) *  'HeaderFCS:'  CRC32 according to IEEE802.3, start value 0xFFFFFFFF, reverse and always in little endian format *  'Dataset:'  Max. 65388 Bytes of data All data is transmitted in 'Network Byte Order' (Big Endian), except for FCS.

General information
The PD and MD telegrams can optionally be used for "safe" communication according to SIL2 with a data link layer. In IEC61375-2-3, Annex B defines the Secure Data Transmission Protocol SDTv2.

The use of TRDP is mandatory (normative) for communication between Consists over Ethernet according to IEC61375-2-3, optional for use within Consists.

RFC references

 * – User Datagram Protocol