In case it is necessary to ensure that a given SafetyData (e.g. a safety demand or a command value) that originates in the SafetyProvider’s safety application is being received by a SafetyConsumer and forwarded to the SafetyConsumer’s safety application, i.e. if no SafetyData in a series of SafetyData is to be missed, the following two cases shall be considered.

In case A, repeated identical RequestSPDUs are being answered by the SafetyProvider with ResponseSPDUs which contain the initially returned value. This is the case for PubSub communication and is a choice for Client/Server communication, see RQ7.11. In this case, the SafetyProvider’s safety application shall provide the respective SafetyData at the SafetyProvider’s SAPI until at least one change of the MNR is detected.

In case B, repeated identical RequestSPDUs are being answered by the SafetyProvider with the currently available SafetyData. This is a choice for Client/Server communication, see RQ7.11. In this case, the SafetyProvider’s safety application shall provide the respective SafetyData at the SafetyProvider’s SAPI until at least two changes of the MNR have been detected.

Figure 15 and Figure 16 show examples justifying case B by depicting two sequences of ResponseSPDUs as sent by a SafetyProvider. Due to the cycles of SafetyProvider and SafetyConsumer not being synchronized, a SafetyConsumer can evaluate any one of a given number of ResponseSPDUs for a given RequestSPDU.

In the examples, the SafetyData is made up of two components: the “respective safety data”, i.e. a safety demand that is not to be missed (one of the values “A”, “B” or “C”) and non-demand numerical measurement values for which it does not matter whether some are not received by the SafetyConsumer.

The worst-case time to make sure that the respective safety data from the SafetyProvider is made available to the SafetyConsumer is two times the SafetyConsumerTimeout. This worst-case time occurs when the two transmissions of a RequestSPDU and its corresponding ResponseSPDU, which are necessary according to the descriptions above, each take a time of just slightly under one SafetyConsumerTimeout.

If the SafetyConsumer’s SafetyConsumerTimeout is known at the SafetyProvider, the SafetyProvider may alternatively provide the respective safety data for at least two times the SafetyConsumerTimeout to ensure that the respective safety data reaches the SafetyConsumer.

Since NonSafetyData is consistently transmitted with SafetyData, the same considerations apply for NonSafetyData.

Figure 15 – Duration of demand example for missed demand value in case of currently available SafetyData not being provided until second change of MNR

Figure 16 – Duration of demand example for received demand value in case of currently available SafetyData being provided