This chapter gives details about the management of the safety communication layer.
For cyclic communication, the part of the safety function response time attributable to an safety communication according to this document (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 safety communication according to this document.
SafetyConsumerTimeout:Watchdog timer running in the SafetyConsumer. It is started immediately before a new RequestSPDU is sent (T14 or T28). If the timer runs out a timeout error is triggered (T18 or T29).
ConsumerCycleTime:The maximum time for the cyclic execution of the SafetyConsumer, see 7.2.2.2.
NOTE 1 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.
NOTE 2 If multiple safety connections according to this document are used within a safety function in series, their respective attributions to the SFRT must be summed up.
Figure 22 – Overview of delay times and watchdogs
Equation 1 is justified by Figure 22 and the following explanation:
- The SafetyConsumer sends a RequestSPDU. At about the same time, a dangerous event occurs at the SafetyProvider, demanding the safety function to trigger.
- However, in the worst case, the RequestSPDU is processed at the SafetyProvider just before the dangerous event becomes known.
- Hence, the ResponseSPDU does not yet contain any information about the dangerous event.
- In the worst case, the ResponseSPDU is processed in the SafetyConsumer just before the SafetyConsumerTimeout expires.
- An error leads to a loss or unacceptable delay of either the RequestSPDU or the ResponseSPDU.
- Hence, the SafetyConsumerTimeout expires.
- 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 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.
[RQ8.1] To support the calculation of SafetyConsumerTimeout the SafetyProvider shall provide the SafetyProviderDelay as an attribute in the OPC UA information model, see Table 12.
Vendors may provide their individual adapted calculation method if necessary.