| 词条 | Draft:Train Real Time Data Protocol | ||
| 释义 |
{{Infobox Netzwerkprotokoll|Logo=|Familie=Internet protocol|Einsatzfeld=Data transfer im TCN|aufbauend auf=17224/UDP Process Data (PD), 17225/UDP o. TCP Message Data (MD) (Transport)|Basis zu=|Einführung=|entwickelt aus=|entwickelt zu=|Version=1.0|Version Datum=2019|Vorabversion=|Vorabversion Datum=|Standard=IEC61375-2-3 (2015)}}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)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 pushThe '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 pullA 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 formatProcess 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)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 patternThe 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 formatProcess 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 InformationPD 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. References1. ^http://www.iec.ch/dyn/www/f?p=103:38:0::::FSP_ORG_ID,FSP_LANG_ID:1248,25# 2. ^www.tcnopen.eu 3. ^{{cite web|title=TCNOpen|periodical=SourceForge|publisher=|url=https://sourceforge.net/projects/tcnopen/?source=directory|deadurl=|format=|accessdate=2019-03-20|archiveurl=|archivedate=|last=|date=|year=|month=|day=|language=|pages=|quote=}} 4. ^{{cite web|title=NewTecTrainsolutions|periodical=www.newtec.de|publisher=|url=https://www.newtec.de/loesungen/railway/|deadurl=|format=|accessdate=2019-03-20|archiveurl=|archivedate=|last=|date=|year=|month=|day=|language=|pages=|quote=}} 5. ^1 {{cite web|title=IEC 61375-2-3 (2015-07) Ed. 1.0 - englisch - IEC Normen Shop|periodical=www.iec-normen.de|publisher=|url=https://www.iec-normen.de/221968/iec-61375-2-3-2015-07-ed-1-0-englisch.html|deadurl=|format=|accessdate=2016-03-14|archiveurl=|archivedate=|last=|date=|year=|month=|day=|language=|pages=|quote=}} https://de.wikipedia.org/wiki/Train_Real_Time_Data_Protocol Category:Internet Protocol{{DEFAULTSORT:Train Real Time Data Protocol}} |
||
| 随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识，基本涵盖了大多数领域的百科知识，是一部内容自由、开放的电子版国际百科全书。