Train Real Time Data Protocol
| Train Real Time Data Protocol | |
|---|---|
| Family: | Internet protocol family |
| Field of application: | Data transfer in the TCN |
| Based on | 17224 / UDP Process Data (PD), 17225 / UDP or TCP Message Data (MD) (transport) |
| current version: | 1.0 (2015) |
| Default: | IEC61375-2-3 ( 2015 ) |
The Train Real Time Data Protocol (TRDP) is a network protocol for communication via IP-based networks in trains and is part of the TCN (Train Communication Network). It is based on UDP and optionally on TCP and enables the exchange of process data (PD) and message data (MD) between devices such as door controls, displays, air conditioning systems, etc. TRDP is a connectionless, frame-oriented protocol and forms the basis for communication in future trains. The proprietary IPTCom protocol from Bombardier Transportation, from which TRDP adopts many features, is considered to be the forerunner.
The protocol was developed by the Working Group TC9 / WG43 of the IEC as part of the TCN and standardized in IEC61375-2-3. Well-known manufacturers and suppliers of rolling stock for rail transport are involved in the development and standardization.
The activities are coordinated by the 'Train Communication Network Open Source Special Interest Group' under the acronym TCNOpen. TCNOpen is an open source initiative founded by partners in the railway industry with the aim of jointly developing key components for the upcoming communication standards in the railway sector.
A reference implementation in 'C' is available under the open source Mozilla license MPL2 as "TRDP Light" on the SourceForge platform .
Process data (PD)
TRDP process data are sent cyclically as UDP packets on port 17224 with a minimum of 10 ms intervals. Senders are called 'Publisher' or 'Source', receivers are called 'Subscriber' or 'Sink'. Various communication patterns are supported.
PD push
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 period, e.g. B. in the event of a network failure, a 'timeout' is triggered and the received data is either marked as out of date or reset to zero. In addition, the subscriber can use a sequence number in the message to identify whether the packet is new or a duplicate of a redundant sender, 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 controlled synchronously from one transmitter.
PD pull
The sending of process data can be forced by means of a request telegram. The publisher must then also send the data outside the set cycle times. The telegrams requested by the 'pull' mechanism have a different identifier ('Pp' instead of 'Pd', see).
Several publishers can be addressed simultaneously using multicast addressing; the reply address can also be a multicast group.
PD telegram format
Process data telegrams consist of a header and the user data (including an optional SDT trailer (Safe Data Transmission)).
SequenceCounter: Is increased with each telegram sent
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 the case of train-wide communication, this is the CRC via the 'Train Network Directory' and is checked for validity at both the sender and the recipient.
opTrnTopoCnt: Necessary for telegrams with direction-dependent information. This is the CRC via the 'Operational Train Directory'.
DatasetLength: 0 ... 1432 bytes
ReplyComID / ReplyIpAddress: For pull telegrams to determine 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 is transmitted in 'Network byte order' (Big Endian), with the exception of the FCS.
Message data (MD)
TRDP message data are event-driven transmitted via UDP or TCP on port 17225. Senders are referred to as 'Requester' or 'Caller', receivers as 'Listener' or 'Replier'. Various communication patterns are supported.
MD communication pattern
If a 'notification' is sent, the sender does not expect a response. The sender (with UDP) cannot determine whether the message has reached the addressee.
In the case of a 'request', the caller learns with the reply whether the message has arrived (or the lack of a response due to the expiry of a timer). The replier can request confirmation of receipt of the message from the caller. This is important if the reply caused a status change in the replica and this may have to be reversed.
If messages are exchanged 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 (also with TCP connections).
Multicast addresses are also possible for message data traffic via UDP:
The caller can indicate how many replies he expects.
MD telegram format
Message data telegrams consist of a header and the user data (including an optional SDT trailer (Safe Data Transmission)).
SequenceCounter: Is increased with each telegram sent
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 the case of train-wide communication, this is the CRC via the 'Train Network Directory' and is checked for validity at both the sender and the recipient.
opTrnTopoCnt: Necessary for telegrams with direction-dependent information. This is the CRC via the 'Operational Train Directory'.
DatasetLength: 0 ... 65388 bytes
ReplyStatus:
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 destination URI (part before the @)
HeaderFCS: CRC32 according to IEEE802.3, start value 0xFFFFFFFF, inverse and always in little endian format
Dataset: Max. 65388 bytes of data
All data is transmitted in 'Network byte order' (Big Endian), with the exception of the FCS.
General information
PD and MD telegrams can optionally be used for "safe" communication in accordance with SIL2 with a data link layer. In Annex B of IEC61375-2-3, the Safe Data Transmission Protocol SDTv2 is defined.
The use of TRDP is mandatory (normative) for communication between train parts (Consists) via Ethernet according to IEC61375-2-3, and optional for use within Consists.
Individual evidence
- ↑ http://www.iec.ch/dyn/www/f?p=103:38:0::::FSP_ORG_ID,FSP_LANG_ID:1248,25#
- ↑ www.tcnopen.eu
- ↑ TCNOpen. In: SourceForge. Retrieved March 20, 2019 .
- ↑ NewTecTrainsolutions. In: www.newtec.de. Retrieved March 20, 2019 .
- ↑ a b IEC 61375-2-3 (2015-07) Ed. 1.0 - English - IEC Standards Shop. In: www.iec-normen.de. Retrieved March 14, 2016 .