SafetyStructureSignature is used to check the number, data types, 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 type (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 type, 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 type “vec3D_in” where the vector components are given in inch, or even at a SafetyConsumer expecting a structure of type “orientation”, containing three floats to define an orientation using Euler angles.

[RQ8.16] SafetyStructureSignature shall be calculated as CRC32-signature (polynomial: 0x F4ACFB13, see Annex B.1) over SafetyStructureIdentifier (encoding: UTF-8), SafetyStructureSignatureVersion and the sequence of the DataType IDs. After each datatype ID, a 16-bit zero-value (0x0000) shall be inserted. All integers shall be encoded using little endian byte ordering. Data shall be processed in reverse order, see Annex B.1. The value “0” shall not be used as signature. Instead, the value “1” shall be used in this case.

The terminating zero of SafetyStructureIdentifier shall not be considered when calculating the CRC.

[RQ8.17] SafetyStructureIdentifier may be visible in the OPC UA information model for diagnostic purposes but shall not be evaluated by the SafetyConsumer during runtime.

[RQ8.18] For all releases up to Release 2.0 of the specification, the value for SafetyStructureSignatureVersion shall be 0x0001.


SafetyStructureIdentifier,e.g. “Motörhead” = 0x4d 0x6f 0x74 0xc3 0xb6 0x72 0x68 0x65 0x61 0x64

SafetyStructureSignatureVersion := 0x0001

1. DataType Int16: (Id = 0x0004), // see Clause 6.4

2. DataType Boolean: (Id = 0x0001),

3. DataType Float32: (Id =0x000A)

SafetyStructureSignature =

= CRC32_Backward(0x4d, 0x6f, 0x74, 0xc3, 0xb6, 0x72, 0x68, 0x65, 0x61, 0x64,


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,


= 0xe2e86173

NOTE: The insertion of 0x0000 values after the DataType ID, allows for introducing arrays in later version of OPC UA Safety.

NOTE: SafetyStructureSignatureVersion is the version of the procedure used to calculate the signature, as defined in [RQ8.16]. If future releases of this specification define an alternative procedure, they will indicate this by using a different version number.

OPC 10000-3, clause 5.8.2 defines different categories of DataTypes. Regarding the DataType ID which is to be used within the StructureSignature, the following holds:

  • For Built-in DataTypes, the ID from Table 1 of OPC 10000-6 is used as DataType ID.
  • For Simple DataTypes, the ID of the Built-in DataType from which they are derived is used.
  • As of now, Structured DataTypes (including OptionSets) shall not be used within Safety Data. 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 ID of the Int32 Built-in DataType.