Figure 11 shows the structure of a RequestSPDU which originates at the SafetyConsumer and contains a SafetyConsumerID, a MonitoringNumber (MNR), and one byte of (non-safety-related) flags.
NOTE The RequestSPDU does not contain a CRC checksum.
Figure 12 shows the structure of a ResponseSPDU which originates at the SafetyProvider and contains the safety data (1 – 1500 Bytes), an additional 25 Byte safety code (STrailer) as described in the subsequent clauses, and the non-safety related data (see also 6.2.3.4 for details).
NOTE To avoid spurious trips, the ResponseSPDU is transmitted in an atomic (consistent) way from the OPC UA platform interface of the SafetyProvider to the OPC UA platform interface of the SafetyConsumer. This is the task of the respective OPC UA mapper, see Figure 2.
Identifier of the SafetyConsumer instance, for diagnostic purposes, see 9.1.2.
The SafetyConsumer uses the MNR to detect mis-timed SPDUs, e.g., such SPDUs which are continuously repeated by an erroneous network element which stores data. A different MNR is used in every RequestSPDU of a given SafetyConsumer, and a ResponseSPDU will only be accepted if its MNR is matching the MNR of the corresponding RequestSPDU.
The checking for correctness of the MNR is only performed by the SafetyConsumer.
[RQ7.1] The flags of the Safety Consumer (RequestSPDU.Flags) shall be used as shown in 6.2.3.1.
[RQ7.2] SafetyData shall contain the safety-related application data transmitted from the SafetyProvider to the SafetyConsumer. It may comprise multiple basic OPC UA variables (see 6.2.5). For the sake of reducing distinctions of cases, SafetyData shall always be a structure, even if it only contains a single basic OPC UA variable.
For the calculation of the CRC Signature, the order in which this data is processed by the calculation is important. SafetyProvider and SafetyConsumer must agree upon the number, type and order of application data transmitted in SafetyData. The sequence of SafetyData is fixed.
NOTE SafetyData may contain qualifier bits for a fine-grained activation of fail-safe substitute values. For a valid process value, the respective qualifier is set to 1 (good), whereas the value 0 (bad) is used for invalid values. Invalid process values are replaced by a fail-safe substitute value in the consumer’s safety application. See 6.3.6.
[RQ7.3] The flags of the SafetyProvider (ResponseSPDU.Flags) shall be used as shown in 6.2.3.2.
[RQ7.4] Flags in the ResponseSPDU.Flags which are reserved for future use shall be set to zero by the SafetyProvider and shall not be evaluated by the SafetyConsumer.
This field is used by the SafetyConsumer to check whether the ResponseSPDU is coming from the correct SafetyProvider. For details, see 7.2.3.1.
[RQ7.5] The SafetyConsumerID in the ResponseSPDU shall be a copy of the SafetyConsumerID received in the corresponding RequestSPDU. See 7.2.3.1.
[RQ7.6] The MonitoringNumber in the ResponseSPDU shall be a copy of the MonitoringNumber received in the corresponding RequestSPDU. See 7.2.3.1.
NOTE The SafetyConsumer uses the ResponseSPDU.MonitoringNumber to detect mis-timed SPDUs, e.g., such SPDUs which are continuously repeated by an erroneous network element which stores data. A different MonitoringNumber is used in every RequestSPDU of a given SafetyConsumer, and a ResponseSPDU will only be accepted if its MonitoringNumber matches the MonitoringNumber in the corresponding RequestSPDU.
[RQ7.7] This CRC-checksum shall be used to detect data corruption. See 7.2.3.5 on how it is calculated in the SafetyProvider and how it is checked in the SafetyConsumer.
[RQ7.8] This structure shall be used to transmit non-safety data values (e.g., diagnostic information) together with safe data consistently. Non-safety data is not CRC-protected and may stem from an unsafe source.
[RQ7.9] When presented to the safety application (e.g., at an output of the SafetyConsumer), non-safety values shall clearly be indicated as “non-safety”, by an appropriate vendor-specific mechanism (e.g. by using a different color).
To avoid possible problems with empty structures, the dummy structure NonSafetyDataPlaceholder shall be used when no non-safety data is used (see requirement RQ6.8).