The TRDP layer shall provide a service for process data communication to the TRDP user at upper layer. The service primitives listed in Table A.4 shall be provided.
NOTE The service primitives are defined in an abstract way in order not to restrict implementations. The specification of the service interface itself is not in the scope of this part of the standard.
Table A.4 – TRDP service primitives
Role Service primitive Parameter Description
publisher PD.publish TRDP user → TRDP layer
service user hands over a new process data packet
Handle Handle for this publishing, returned by the TRDP layer
etbTopoCnt as defined in Table A.3 opTrnTopoCnt as defined in Table A.3
ComId as defined in Table A.3
DatasetLength Actual user data length to be sent as defined in Table A.3
Role Service primitive Parameter Description
Dataset Buffer with user data to be sent as defined in Table A.3
CycleTime Cycle time (txTime) for sending PD.
Unit: 10–6 s (às)
DestinationIpAddress[] Destination IP address(es) to send the PD to.
redundant FALSE means that the PD are
published immediately, TRUE means that PD are only published if redundant ComIds are activated
PD.unPublish TRDP user → TRDP layer
Stop publishing
Handle Handle which has been given by the
TRDP layer PD.putData
Handle Handle which has been given by the
TRDP layer
DatasetLength Actual user data length to be sent as defined in Table A.3
Dataset Buffer with user data to be sent as defined in Table A.3
PD.activateRed TRDP user → TRDP layer
service user activates the publishing of the ComIds marked as redundant
PD.deactivateRed TRDP user → TRDP layer
service user deactivates the publishing of the ComIds marked as redundant
Requester PD.request TRDP user → TRDP layer
TRDP layer sends a PD- PDU.request to one or multiple publishers. Cyclically called from application.
Handle handle for this subscription of the reply ComId; returned by the TRDP layer
etbTopoCnt as defined in Table A.3 opTrnTopoCnt as defined in Table A.3
ComId ComId to be sent, as defined in
Table A.3
DatasetLength data set length to be sent, as defined in Table A.3
DataSet User data set to be sent, as defined in Table A.3
DestinationIpAddress[] Destination IP address(es) to send the PD request to.
redundant FALSE means that the PD are
published immediately, TRUE means that PD are only published if redundant ComIds are activated
Role Service primitive Parameter Description ReplyComId as defined in Table A.3 ReplyIpAddress as defined in Table A.3
Subscriber PD.subscribe TRDP user → TRDP layer
User subscribes to process data using possible filter for ComId, SourceIpAddress, SourceIpAddress range, DestinationIpAddress.
Handle handle for this subscription;
returned by the TRDP layer etbTopoCnt as defined in Table A.3 opTrnTopoCnt as defined in Table A.3
ComId as defined in Table A.3
DatasetLength as defined in Table A.3
Dataset as defined in Table A.3
SourceIpAddress IP source address, generated out of respective URI’s using DNS.
Defines the lower IP address in case of an IP address range (see 5.4.4.6.2)
Set to 0 if no filtering requested SourceIpAddress2 Defines the upper IP address in case of an IP address range (see 5.4.4.6.2)
IP source address, generated out of respective URI’s using DNS Set to 0 if not used
DestinationIpAddress IP destination address, generated out of respective URI’s using DNS Set to 0 if no filtering requested Subnet Select the subnet(s) to subscribe;
designated one or all of the redundant networks.
Timeout Timeout (rxTime) for PD to be
received Unit: 10–6 s (às)
PD.unsubscribe TRDP user → TRDP layer
User unsubscribes to process data using possible filter for ComId, SourceIpAddress,
DestinationIpAddress.
Handle handle returned by the TRDP layer
in PD.subscribe
PD.indicate TRDP layer → TRDP user
TRDP layer indicates new process data or a timeout. The timeout value is given with PD.subscribe.
Handle handle returned by the TRDP layer
in PD.subscribe
IndType • process data (‘Pd’)
• process data reply (‘Pp’)
• process data request (‘Pr’)
• process data error (‘Pe’)
Role Service primitive Parameter Description
etbTopoCnt Received topo count, as defined in Table A.3
opTrnTopoCnt Received topo count, as defined in Table A.3
ComId Received ComId, as defined in
Table A.3
DatasetLength Received user data size, as defined in Table A.3
Dataset Received user data, as defined in Table A.3
SequenceCounter Received sequence counter, as defined in Table A.3
SourceIpAddress Received source IP address DestinationIpAddress Received destination IP address, as
defined in Table A.3
ReplyIComId Received reply ComId, as defined in Table A.3
ReplyIpAddress Received reply IP address, as defined in Table A.3
Status
In case of a TRDP error (
‘Pe’) the value is supplied by TRDP.
• 1 – timeout
• 6 – no subscription
• 5 – no memory
• 7 – data invalid
0 OK
< 0 NOK
PD.poll TRDP user → TRDP layer
User polls for new PD instead of using the indication
Handle handle returned by the TRDP layer
in PD.subscribe
IndType • process data (‘Pd’)
• process data reply (‘Pp’)
• process data request (‘Pr’)
• process data error (‘Pe’) etbTopoCnt Received topo count, as defined in
Table A.3
opTrnTopoCnt Received topo count, as defined in Table A.3
ComId Received ComId, as defined in
Table A.3
DatasetLength Received user data size, as defined in Table A.3
Dataset Received user data, as defined in Table A.3
SequenceCounter Received sequence counter, as defined in Table A.3
SourceIpAddress Received source IP address DestinationIpAddress Received destination IP
Role Service primitive Parameter Description
ReplyIComId Received reply ComId, as defined in Table A.3
ReplyIpAddress Received reply IP address, as defined in Table A.3
Status
In case of a TRDP error (
‘Pe’) the value is supplied by TRDP.
• 1 – timeout
• 5 – no memory
• 6 – no subscription
• 7 – data invalid
0 OK
< 0 NOK
A.6.6.2 PD User access
The TRDP user shall have two possibilities to retrieve PD: either via a poll mechanism, typically used in cyclic user tasks, or via indication mechanism, where the TRDP layer notifies the user when new data are available or when there is a timeout.
A.6.6.3 Interaction sequence – PD Pull Pattern
The sequence chart in Figure A.12 defines the allowed sequence of the service primitives for the PD pull pattern, PD.request service primitive and related request telegram are only called by a requester.
NOTE 1 Dotted lines in the sequence charts are used to indicate options.
Process data are prepared cyclically by the publisher and shall be given to the TRDP layer calling the PD.putData primitive.
To receive a request, the publisher shall subscribe for it.
Until receiving the first request telegram matching to the filter criteria of the subscription, related data in the receive buffer of the replier shall be marked as invalid.
Also a request for already cyclically published PDU shall be possible.
An incoming request telegram with parameter values ‘etbTopoCnt’ and ‘opTrnTopoCnt’
different to expected (own locally stored) values shall be discarded.
Each incoming request telegram shall be responded by the TRDP layer using the available process data, the reply IP address and the reply ComId given in the request telegram.
If the reply IP address of the request telegram is 0, the source IP address of the request telegram shall be used as destination IP address for the reply.
To receive the related reply for a request, the requester needs to subscribe for it. Destination IP address, source IP address and source IP address range are possible filter criteria.
Until receiving the first reply telegram matching to the filter criteria of the subscription, related data in the receive buffer of the subscriber shall be marked as invalid. Before sending the request telegram, the related reply data in the receive buffer of the subscriber shall be set to invalid.
NOTE 2 This is to prevent that the user fetches outdated reply data after it has requested new reply data.
Timeout supervision at subscriber TRDP layer shall be restarted after sending the request telegram.
The request can contain user data.
Before sending out a request, the TRDP layer shall check the topopology counters submitted with the request against the actual topology counters. At least one of the cases listed in Table A.5 for the topography counters shall be fulfilled.
Figure A.12 – Interaction sequence chart for PD pull pattern A.6.6.4 Interaction sequence – PD Push Pattern
The sequence chart in Figure A.13 defines the allowed sequence of the service primitives for the PD push pattern.
Process data are prepared cyclically by the publisher and shall be given to the TRDP layer calling the PD.putData primitive.
The publisher TRDP layer shall send the data in the configured cycle to the configured address.
The publisher TRDP layer shall send out the data only after checking the locally stored topography counters submitted with the publish against the actual topography counters. At least one of the cases listed in Table A.5 for the topography counters shall be fulfilled.
Any subscriber can subscribe for the process telegram using ComID, destination IP address and source IP address of the process telegram as possible filter criteria.
Timeout supervision at subscriber TRDP layer shall be started after subscription.
Timeout supervision at subscriber TRDP layer shall be restarted after receiving the related PD PDU.
The subscriber TRDP layer shall check the topography counters of the received telegram against the actual topography counters and against the topography counters submitted with the
IEC
TRDPuser TRDP
layer publisher/subscriber
TRDPlayer TRDP
user requester/subscriber
request telegram process data telegram
PD.indicate(data) PD.putData
PD.indicate(data)
PD.request PD.subscribe
PD.putData PD.poll
PD.subscribe
PD.poll
PD.indicate(timeout) PD.indicate(timeout)
PD.publish
subscription. At least one of the cases listed in Table A.5 for the topography counters shall be fulfilled.
Until receiving the first valid telegram matching to the filter criteria the data shall be marked as invalid.
Figure A.13 – Interaction sequence chart for PD push pattern A.6.6.5 PD Redundancy Handling
The sequence chart in Figure A.14 shows the sequence of the service primitives for redundancy handling of the push pattern.
The service primitives for redundancy handling shall be used in the same way by the publisher for the pull and the push pattern.
If a redundant device enters the redundancy leader state it shall call PD.activate to start publishing process data related to ComIds marked as redundant.
If a redundant device enters the redundancy follower state it shall call PD.deactivate to stop publishing process data related to ComIds marked as redundant.
Starting TRDP, publishers of redundant process data (identified by ComId marked as redundant) shall be initialized in redundancy follower mode (publishing deactivated).
IEC
TRDPuser TRDP
layer publisher
TRDPlayer TRDP
user subscriber
process data telegram
PD.indicate(data) PD.publish
PD.indicate(timeout) PD.subscribe
PD.putData PD.poll
PD.putData