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

Figure 13 (informative) – Sequence diagram for requests and responses (Client/Server)

[RQ7.10] 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 1 The returned ResponseSPDUs may contain different values (e.g., currently available process values) or contain the initially returned values.

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

NOTE 2 Since a SafetyConsumer checks for changed MNRs in ResponseSPDUs (see SafetyConsumer state S14_WaitForChangedSPDU in Table 34 and transition T17 in Table 35), 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 14 (informative) – Sequence diagram for requests and responses (PubSub)

NOTE 3 The state machines according to this document 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 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 immediately before a new RequestSPDU is generated (transitions T14 and T28 of the SafetyConsumer in Table 35). 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 of the monitoring of the ConsumerCycleTime and the reaction in case of exceeding the ConsumerCycleTime are not part of this document; these are vendor-specific.

[RQ7.12] The ConsumerCycleTime shall be monitored in a safety-related way.