For cyclic communication, the part of the safety function response time attributable to an OPC UA Safety communication (SFRTOPCSafety) is specified in Equation 1.

Equation 1 Calculation of safety function response time part of OPC UA Safety

SFRTOPCSafety <= 2 x SafetyConsumerTimeOut + ConsumerCycleTime

where

SFRTOPCSafety: Part of the Safety function response time attributable to the OPC UA Safety communication.

SafetyConsumerTimeOut:Watchdog timer running in the SafetyConsumer. It is started whenever a new RequestSPDU is sent (T14 or T26). If the timer runs out while the SafetyConsumer is waiting for the ResponseSPDU (S17), a timeout-error is triggered (T18).

ConsumerCycleTime: the maximum time for the cyclic execution of the SafetyConsumer, see Clause 8.2.2.2.

NOTES:

• Equation 1 assumes that a RequestSPDU is sent in the same consumer cycle as new input data is received via a ResponseSPDU. If this is not the case, and sending the RequestSPDU is delayed, an upper bound for this delay has to be added.
• Equation 1 only addresses the part of the SFRT attributable to OPC UA Safety. The overall SFRT also depends on the implementation of the devices the SafetyProvider and SafetyConsumer are running on. Details on how these fractions of the SFRT are calculated are vendor-specific.
• If multiple OPC UA Safety connections are used within a safety function in series, their respective attributions to the SFRT must be summed up.

Figure 25 – Overview of delay times and watchdogs

Equation 1 is justified by Figure 25 and the following explanation:

1. The SafetyConsumer sends a RequestSPDU. At about the same time, a dangerous event occurs at the SafetyProvider, demanding the safety function to trigger.
2. However, in the worst case, the RequestSPDU is processed at the SafetyProvider just before the dangerous event becomes known.
3. Hence, the ResponseSPDU does not yet contain any information about the dangerous event.
4. In the worst case, the ResponseSPDU is processed in the SafetyConsumer just before the SafetyConsumerTimeout expires.
5. Another error (which may have the same root cause as the dangerous event) leads to a loss or unacceptable delay of either the RequestSPDU or the ResponseSPDU.
6. Hence, the SafetyConsumerTimeout expires.
7. In the worst case, the timer expires immediately after it was checked. Hence, it takes another cycle of the SafetyConsumer to detect the error.

SafetyConsumerTimeOut is a parameter of the SafetyConsumer. ConsumerCycleTime depends on the maximum sample time of the SafetyConsumer application. At commissioning, the integrator should be advised to design it shorter than a quarter of the target SFRTOPCSafety. If the watchdog time SafetyConsumerTimeOut is too small, spurious trips may occur. To avoid this, SafetyConsumerTimeOut should be chosen as shown in Equation 2.

Equation 2 Selection of the watchdog parameter SafetyConsumerTimeOut

SafetyConsumerTimeOut >= T_CD_RequestSPDU + SafetyProviderDelay + T_CD_ResponseSPDU +SafetyConsumerDelay

where

T_CD_RequestSPDU:The worst-case communication delay for the RequestSPDU.

(NOTE: This may include the occurrence of dropped messages in the communication channel).

T_CD_ResponseSPDU:The worst-case communication delay for the ResponseSPDU.

(NOTE: This may include the occurrence of dropped messages in the communication channel).

SafetyProviderDelay: The worst-case SafetyProvider delay. Typically, one scan time period of the SafetyProvider.

SafetyConsumerDelay:The worst-case SafetyConsumer delay. Typically, one scan time period of the SafetyConsumer.

NOTE to Equation 2: the reason why SafetyConsumerDelay is part of the summation is that it may take one cycle after the asynchronous reception of the ResponseSPDU to execute the checks.

[RQ10.1] To support the calculation of SafetyConsumerTimeOut the SafetyProvider shall provide the SafetyProviderDelay as an attribute in the OPC UA information model, see Table 13.

Vendors may provide their individual adapted calculation method if necessary.