SafetyStructureSignature is used to check the number, DataTypes, and order of application data transmitted in SafetyData. If the SafetyConsumer is expecting anything different than what the SafetyProvider actually provides, SafetyStructureSignature will differ, allowing the SafetyConsumer to enable fail-safe substitute values.
In addition, the identifier of the Structure DataType (SafetyStructureIdentifier) is also taken into account when calculating SafetyStructureSignature. This ensures that the SafetyProvider and the SafetyConsumer are using the same identifier for the Structure DataType, effectively avoiding any confusion.
For instance, if a SafetyProvider defines a Structure with identifier “vec3D_m” comprising three Floats containing a three-dimensional vector in the metric system, this Structure could not be used by a SafetyConsumer expecting a Structure of DataType “vec3D_in” where the vector components are given in inches, or even at a SafetyConsumer expecting a Structure of DataType “orientation”, containing three Floats to define an orientation using Euler angles.
[RQ7.19] SafetyStructureSignature shall be calculated as a 32 bit CRC signature (polynomial: 0x F4ACFB13, see Clause B.1) over SafetyStructureIdentifier (encoding: UTF-8), SafetyStructureSignatureVersion and the sequence of the DataTypeEncodingIDs. After each DataTypeEncodingID, a 16-bit zero-value (0x0000) shall be inserted. All integers shall be encoded using little endian octet ordering. Data shall be processed in reverse order, see Clause B.1. The value “0” shall not be used as a signature. Instead, the value “1” shall be used in this case.
The terminating zero of SafetyStructureIdentifier shall not be considered when calculating the CRC.
[RQ7.20] SafetyStructureIdentifier may be visible in the OPC UA Information Model for diagnostic purposes but shall not be evaluated by the SafetyConsumer during runtime.
[RQ7.21] For all releases up to Release 2.0 of the specification, the value for SafetyStructureSignatureVersion shall be 0x0001.
Example:
SafetyStructureIdentifier,e.g. “Motörhead” = 0x4d 0x6f 0x74 0xc3 0xb6 0x72 0x68 0x65 0x61 0x64
SafetyStructureSignatureVersion:= 0x0001
1. DataType Int16: (DataTypeEncodingId = 0x0004), // see 6.2.5
2. DataType Boolean: (DataTypeEncodingId = 0x0001),
3. DataType Float: (DataTypeEncodingId =0x000a)
= CRC32_Backward(0x4d, 0x6f, 0x74, 0xc3, 0xb6, 0x72, 0x68, 0x65, 0x61, 0x64,
0x01,0x00,
0x04,0x00, 0x00,0x00,
0x01,0x00, 0x00,0x00,
0x0A, 0x00, 0x00, 0x00)
= CRC32_Forward(
0x00, 0x00, 0x00, 0x0A,
0x00, 0x00, 0x00, 0x01,
0x00, 0x00, 0x00, 0x04,
0x00,0x01,
0x64, 0x61, 0x65, 0x68, 0x72, 0xb6, 0xc3, 0x74, 0x6f, 0x4d)
= 0xe2e86173
NOTE 1 The insertion of 0x0000 values after each DataTypeEncodingID allows for introducing arrays in later versions of this document.
NOTE 2 SafetyStructureSignatureVersion is the version of the procedure used to calculate the signature, as defined in requirement RQ7.19. If future releases of this document define an alternative procedure, they will indicate this by using a different version number.
OPC 10000-3, 5.8.2 defines different categories of DataTypes. Regarding the DataTypeEncodingID which is to be used within the SafetyStructureSignature, the following holds:
- For Built-in DataTypes, the ID from Table 1 of OPC 10000-6 is used as DataTypeEncodingID.
- For Simple DataTypes, the DataTypeEncodingID of the Built-in DataType from which they are derived is used.
- As of now, Structured DataTypes (including OptionSets) shall not be used within SafetyData. Arrays are not supported. Instead, multiple variables of the same type are used.
- Enumeration DataTypes are encoded on the wire as Int32 and therefore shall use the DataTypeEncodingID of the Int32 Built-in DataType.