Figure 11 shows the structure of a RequestSPDU which originates at the SafetyConsumer and contains a SafetyConsumerID, a MonitoringNumber (MNR), and one octet of (non-safety-related) Flags. See 7.2.1.2 to 7.2.1.4 for details. See 6.2.3.3 for details on the RequestSPDUDataType definition.
NOTE 1 The RequestSPDU does not contain a CRC signature.
Figure 12 shows the structure of a ResponseSPDU which originates at the SafetyProvider and contains the SafetyData (1 to 1 500 octets), an additional 25 octet safety code (STrailer) and the NonSafetyData. See 7.2.1.5 to 7.2.1.11 for details. See 6.2.3.4 for details on the ResponseSPDUDataType definition.
NOTE 2 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 SPDUs with timeliness errors, 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 matches 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 SafetyConsumer (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 is comprised of a single or 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 comprised of only 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 shall agree upon the number, type and order of application data transmitted in SafetyData. The sequence of SafetyData is fixed.
SafetyData may contain qualifiers for a fine-grained activation of fail-safe substitute values. For valid process values, the respective qualifiers are set to 1 (good), whereas the value 0 (bad) is used for invalid values. Invalid process values are replaced by fail-safe substitute values in the SafetyConsumer’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 SPDUs received with timeliness error, e.g. 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] The ResponseSPDU CRC shall be used to detect data corruption. See 7.2.3.6 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 NonSafetyData values (e.g. diagnostic information) together with SafetyData consistently. NonSafetyData is not CRC-protected and can 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 colour).
To avoid possible problems with empty structures, the dummy structure NonSafetyDataPlaceholder shall be used when no NonSafetyData is used (see requirement RQ6.8).