The SafetyProvider calculates the CRC signature (ResponseSPDU.CRC) and sends it to the SafetyConsumer as part of SPDU. This enables the SafetyConsumer to check the correctness of the SPDU including the SafetyData, Flags, MNR, SafetyConsumerID and SPDU_ID by recalculating the CRC signature (CRC_calc).
[RQ7.22] The generator polynomial 0x F4ACFB13 shall be used for the 32-Bit CRC signature.
[RQ7.23] If SafetyData is longer than one byte (e.g., if it is of data type UInt16, Int16 or Float32), it shall be decoded and encoded using little endian order in which the least significant byte appears first in the incremental memory address stream.
[RQ7.24] The calculation sequence shall begin with the highest memory address (n) of the STrailer counting back to the lowest memory address (0) and then include also the SafetyData beginning with the highest memory address.
Figure 20 shows the calculation sequence of a CRC_SPDU on a little-endian machine, using an example SafetyData with the following fields:
For the example given above, the STrailer (without CRC) and SafetyData have a combined length of 34 bytes (16 bytes STrailer without CRC, 12 bytes of SafetyData). The calculation of ResponseSPDU.CRC (SafetyProvider) or CRC_calc (SafetyConsumer) is done in reverse order, from bottom to top. In the example shown in Figure 20, CRC calculation starts at byte index 33 (most significant byte of the MNR) and ends at byte index 0.
NOTE The reverse order ensures that the effectiveness of the CRC mechanism remains independent of any CRCs used within the underlying OPC UA channel, even if it would coincidentally use the same CRC polynomial.
An alternative way to calculate the CRC (particularly useful on big-endian machines) is shown in Figure 21. Here, the individual elements of the ResponseSPDU are already arranged in memory in reversed order, and CRC calculation is executed from byte 0 to byte 33.
[RQ7.25] On the SafetyConsumer, CRC_calc shall be calculated using data received in the ResponseSPDU, and not from expected values.