Making Communication as Simple as Building Blocks.
Making Communication as Simple as Building Blocks.
Technical Documents
TRDP Process Data
In the process of Process Data interaction, there are three roles:
• Publisher: The source device of Process Data
• Subscriber: The receiving device of Process Data
• Requester: The device that requests the publisher to publish Process Data
PD supports two major communication modes: Push and Pull. Meanwhile, according to the number of source devices and receiving devices, they can be further divided into more detailed categories.
Communication modes supported by Push: (In this mode, there are only two roles: Publisher and Subscriber)
• Point-to-point, cyclic transmission without response. The Publisher knows the Subscriber (the Publisher sends PD via unicast IP)
• Point-to-multipoint, cyclic transmission without response. The Publisher knows the Subscribers (the Publisher sends PD via multicast IP)
• Point-to-multipoint, cyclic transmission without response. The Publisher doesn't know the Subscribers (the Publisher sends PD via multicast IP)
Explanation: From the perspective of communication, when it comes to point-to-multipoint communication, there is no difference whether the Publisher knows the Subscribers or not.
Communication modes supported by Pull: (In this mode, one of the Subscribers may be the Requester)
• Point-to-point, without response, the Requester knows the Publisher (The Requester sends a request message via unicast IP).
• Multipoint-to-point, without response, the Requester doesn't know the Publisher (The Requester sends a request message via multicast IP).
• Point-to-multipoint, without response, the Requester knows the Publisher. (One of the Subscribers, that is, the Requester, sends a request message via unicast IP).
• Multipoint-to-multipoint, without response, the Requester doesn't know the other Requesters. (One of the Subscribers, that is, the Requester, sends a request message via multicast IP).
The IEC standard defines the MD message format as follows::
Field | Length | Value | Description |
| SequenceCounter | 4 bytes | Counting starts from 0 | |
| ProtocolVersion | 2 bytes | Fixed value | High byte：MainVersion Low byte：SubVersion For example: '0102' = Version 1.2 |
| MsgType | 2 bytes | 5072: Pr 5070: Pp 5064: Pd 5065: Pe | 'Pr' = PD Request 'Pp' = PD Reply 'Pd' = PD Data 'Pe' = PD Data (Error) Reserved, not currently in use |
| comId | 4 bytes | Set by the user | Identifier of user data |
| etbTopoCnt | 4 bytes | 0..232-1 | The ETB topography counter: • Used as the train's address in IEC 61375-2-5 (parameter 'etbTopoCnt') • Set by the user • Must be set for all ETB-based communications • If a valid opTrnTopoCnt is set, this field must also be set • Set to 0 in other cases |
| opTrnTopoCnt | 4 bytes | The operational train topography counter: • Refer to the description in Section 5.3.3 for usage • Set by the user • Set this field when information in the operational train directory is required (e.g., routing operations) • Set this field when the source device uses the operational train dictionary to resolve the destination IP (e.g., resolving the URI 'vcu.leadVeh.anyCst.anyClTrn.lTrn') • Set to 0 in other cases | |
| DatasetLength | 4 bytes | 0 ..1432 | |
| reserved01 | 4 bytes | 0 | Reserved |
| replyComId | 4 bytes | Used in Request; fill with 0 in other cases | • Only used in PD request • Used as the ComId for PD reply • If it is 0, use the ComId of the PD request as the ComId for the PD reply • If it is 0 and the ComId of the PD request is also 0, the PD reply sends an unspecified PDU |
| replyIpAddress | 4 bytes | Used in Request; fill with 0 in other case | |
| HeaderFCS | 4 bytes | • Calculated based on the PD-PDU header • Exclude the headerFcs itself during calculation | |
| Dataset | 0..1432 bytes | Must be an integer multiple of 4 bytes. Pad with zeros if insufficient. |
Related Products
