Roles
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
Communication Modes
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).
PD Message Format
The IEC standard defines the MD message format as follows::
|
Field |
Length |
Value |
Description |
|
sequenceCounter |
4 bytes |
Count starting from 0 |
|
|
protocolVersion |
2 bytes |
Fixed |
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 user |
Identifier for user data |
|
etbTopoCnt |
4 bytes |
0..-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 cases |
|
|
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. |
