Figure 16 and Figure 17 show sequences of requests and responses with SafetyData for OPC UA Safety using Client/Server and PubSub communication mechanisms, respectively. Please note that the figures show selected scenarios only and are therefore informative.

Figure 16 (informative) – Sequence diagram for OPC UA Safety (Client/Server)

[RQ8.23] In the case of Client/Server communication, a SafetyConsumer’s OPC UA mapper may call a SafetyProvider (either the state machine implementation itself or the SafetyProvider’s OPC UA mapper) with an identical RequestSPDU multiple times in a row. In that case, the SafetyProvider (state machine or OPC UA mapper) shall answer all requests.

NOTE: The returned ResponseSPDUs may contain different values (e.g., currently available process values) or contain the initially returned values.

[RQ8.24] For each SafetyProvider, the implemented choice of behavior according to RQ8.23 (i.e., whether currently available process values or initially returned values will be used) shall be documented in the corresponding safety manual.

NOTE: Since a SafetyConsumer checks for changed MNRs in ResponseSPDUs (see SafetyConsumer state S14_WaitForChangedSPDU in Table 33 and transition T17 in Table 34), and therefore will use only the first evaluated ResponseSPDU for a given MNR. All further ResponseSPDUs with the same MNR will be ignored.

NOTE: The bold arrows represent communication with new data values, whereas dashed arrows contain repeated data values.

Figure 17 (informative) – Sequence diagram for OPC UA Safety (PubSub)

NOTE: the OPC UA state machines do not contain any retry-mechanisms to increase fault tolerance. In contrast, it is assumed that retry is already handled within the OPC UA stack (e.g., when using Client/Server, or by choosing a higher update rate for OPC UA PubSub). The dashed lines therefore are not part of this document, but rather symbolize the repeated sending of data implemented in the OPC UA stack.

The SafetyConsumerTimeout is the watchdog time checked in the SafetyConsumer. The watchdog is restarted whenever a new RequestSPDU is generated (transitions T14 and T26 of the SafetyConsumer in Table 34). If an appropriate ResponseSPDU is received in time, and the checks for data integrity, authenticity, and timeliness are all valid, the timer will not expire before it is restarted.

Otherwise, the watchdog timer expires, and the SafetyConsumer triggers a safe reaction. To duly check its timer, the SafetyConsumer is executed cyclically, with period ConsumerCycleTime. ConsumerCycleTime is expected to be smaller than SafetyConsumerTimeout.

The ConsumerCycleTime is the maximum time for the cyclic update of the SafetyConsumer. It is the timeframe from one execution of the SafetyConsumer to the next execution of the SafetyConsumer. The implementation and error reaction of ConsumerCycleTime is not part of this document; it is vendor-specific.