This chapter describes the identifiers, types and structure of the objects and methods that are used to implement the OPC UA mappers defined in this part. This implementation serves three purposes:

  • support of the safe exchange of SPDUs at runtime
  • online browsing, to identify SafetyConsumers and SafetyProviders, and to check their parameters for diagnostic purposes
  • offline engineering: the information model of one controller can be exported in a standardized file on its engineering system, be imported in another engineering system, and finally deployed on another controller. This allows for a vendor-independent exchange of the communication interfaces of safety applications, e.g., for establishing connections between devices.

IMPORTANT NOTE:

Neither online browsing nor offline engineering currently supports any features to detect errors. Hence, no guarantees with respect to functional safety are made. This means that online browsing can only be used for diagnostic purposes, and not for exchanging safety-relevant data. In the context of offline engineering, the programmer of the safety application is responsible for the verification and validation of the safety application. It must be assumed that errors may occur during the transfer of the information model from one engineering system to another.

As a consequence, all type values described in this clause are defined as read-only, i.e., they can not be written by general OPC UA write commands.

[RQ6.1] Each server shall have a singleton folder called SafetyACSet with a fixed NodeId in the namespace of OPC UA Safety. Because all SafetyProviders and SafetyConsumers on this server contain a hierarchical reference from this object to themselves, it can be used to directly access all SafetyProviders and/or SafetyConsumers. SafetyACSet is intended for safety-related purposes only. It should not reference to non-safety-related items.

Table 4 – SafetyACSet definition

Attribute

Value

BrowseName

SafetyACSet

References

NodeClass

BrowseName

Comment

OrganizedBy by the Objects Folder defined in OPC 10000-5.

HasTypeDefinition

ObjectType

FolderType

Entry point for all SafetyProviders and SafetyConsumers

Conformance Units

SafetyACSet

[RQ6.2] In addition, a server shall comprise one OPC UA object derived from type SafetyProviderType for each SafetyProvider it implements, and one OPC UA object derived from type SafetyConsumerType for each SafetyConsumer it implements. The corresponding information model shown in Figure 6 and Figure 7 shall be used.

A description of the graphical notation for the different types of nodes and references (shown in Figure 6, Figure 7, and Figure 9) can be found in OPC 10000-3.

Figure 6 describes the SafetyProvider and the SafetyConsumer.

NOTE: OPC UA Safety assumes (atomic) consistent data exchange between OPC mappers of the two endpoints.

[RQ6.3] For implementations supporting OPC UA Client/Server, the Call Service of the Method Service Set (see OPC 10000-4) shall be used. The Method “ReadSafetyData”" has a set of input arguments that make up the RequestSPDU and a set of output arguments that make up the ResponseSPDU. The SafetyConsumer uses the OPC UA-Client with the OPC UA Service Call.

[RQ6.3a] For implementations supporting OPC UA PubSub, the OPC UA object SafetyPDUs with its properties RequestSPDU and ResponseSPDU shall be used. RequestSPDU is published by the SafetyConsumer and subscribed by the SafetyProvider. ResponseSPDU is published by the SafetyProvider and subscribed by the SafetyConsumer.

NOTE: The terms “request” and “response” refer to the behavior on the layer of OPC UA Safety. Within the PubSub context, both requests and responses are realized by repeatedly publishing and subscribing datagrams, see Figure 17.

[RQ6.4] For diagnostic purposes, the SPDUs received and sent shall be accessible by calling the method ReadSafetyDiagnostics.

image011.png

Figure 6 – Server Objects for OPC UA Safety

NOTE: for the input/output arguments of the methods ReadSafetyData and ReadSafetyDiagnostics, see Clause 6.1.3 and 6.1.4. For the parameters of the SafetyProvider and SafetyConsumer, see Figure 9, Table 13, and Table 14. For RequestSPDU and ResponseSPDU, see Table 8, Table 19, Table 21, and Clause 8.2.1.

Figure 7 shows the instances of server objects for OPC UA Safety. The ObjectType for the SafetyProviderType contains methods having outputs of the abstract data type ”Structure”. Each instance of a SafetyProvider needs its own copy of the methods which contain the concrete DataTypes for “OutSafetyData” and “OutNonSafetyData”.

  • image012.png

Figure 7 – Instances of server objects for OPC UA Safety

[RQ6.5] To reduce the number of variations and to alleviate validation testing, the following restrictions apply to instances of SafetyProviderType and SafetyConsumerType (or instances of types derived from SafetyProviderType or SafetyConsumerType):

The references shown in Figure 7 originating at SafetyProviderType or SafetyConsumerType and below shall be of type HasComponent (and shall not be derived from HasComponent) for object references or HasProperty (and shall not be derived from HasProperty) for property references.

As BrowseNames (i.e. name and namespace) are used to find methods, the names of objects and properties shall be locally unique.

The DataType of both Properties and MethodArguments shall be used as specified, and no derived DataTypes shall be used (exception: OutSafetyData and OutNonSafetyData).

In OPC UA, the sequence of MethodArguments is relevant.

Table 5 – SafetyObjectsType Definition

Attribute

Value

BrowseName

SafetyObjectsType

IsAbstract

True

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of BaseObjectType

Conformance Units

SafetySupport

Table 6 – SafetyProviderType Definition

Attribute

Value

BrowseName

SafetyProviderType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of SafetyObjectsType

HasComponent

Method

ReadSafetyData

Optional

HasComponent

Method

ReadSafetyDiagnostics

Optional

HasComponent

Object

SafetyPDUs

SafetyPDUsType

Optional

HasComponent

Object

Parameters

SafetyProviderParametersType

Mandatory

Conformance Units

SafetyProviderParameters

Table 7 – SafetyConsumerType Definition

Attribute

Value

BrowseName

SafetyConsumerType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of SafetyObjectsType

HasComponent

Object

SafetyPDUs

SafetyPDUsType

Optional

HasComponent

Object

Parameters

SafetyConsumerParametersType

Mandatory

Conformance Units

SafetyConsumerParameters

This method is mandatory for the profile SafetyProviderServerMapper (see 13.2.2.1). It is used to read SafetyData from the SafetyProvider. It is in the responsibility of the safety application, that this method is not concurrently called by multiple SafetyConsumers. Otherwise, the SafetyConsumer may receive invalid responses resulting in a safe reaction which may lead to spurious trips and/or system unavailability.

The method argument OutSafetyData has an application-specific type derived from Structure. This type (including the type identifier) is expected to be the same in both the SafetyProvider and the SafetyConsumer. Otherwise, the SafetyConsumer will not accept the transferred data and switch to fail-safe values instead (see state S16 in Table 33 – SafetyConsumer states as well as Clauses 8.2.3.2 and 8.2.3.4).

Signature

ReadSafetyData (

[in]UInt32InSafetyConsumerID,

[in]UInt32InMonitoringNumber,

[in]InFlagsTypeInFlags,

[out] StructureOutSafetyData,

[out]OutFlagsTypeOutFlags,

[out]UInt32OutSPDU_ID_1,

[out]UInt32OutSPDU_ID_2,

[out]UInt32OutSPDU_ID_3,

[out]UInt32OutSafetyConsumerID,

[out]UInt32OutMonitoringNumber,

[out]UInt32OutCRC,

[out] StructureOutNonSafetyData)

;

Table 8 – ReadSafetyData Method Arguments

Argument

Description

InSafetyConsumerID

“Safety Consumer Identifier”, see SafetyConsumerID in Table 24.

InMonitoringNumber

“Monitoring Number of the RequestSPDU”, see Clause 8.2.1.2 and MonitoringNumber in Table 24.

InFlags

“Byte with non-safety-related flags from SafetyConsumer”, see Clause 6.2.1.

OutSafetyData

“Safety Data”, see Clause 8.2.1.4.

OutFlags

“Byte with safety-related flags from SafetyProvider”, see Clause 6.2.2.

OutSPDU_ID_1

“Safety PDU Identifier Part1”, see Clause 8.2.3.2.

OutSPDU_ID_2

“Safety PDU Identifier Part2”, see Clause 8.2.3.2.

OutSPDU_ID_3

“Safety PDU Identifier Part3”, see Clause 8.2.3.2.

OutSafetyConsumerID

“Safety Consumer Identifier”, see SafetyConsumerID in Table 24 and Table 27.

OutMonitoringNumber

Monitoring Number of the ResponseSPDU, see Clause 8.2.1.8, Clause 8.2.3.1, and

Figure 14.

OutCRC

CRC-checksum over the ResponseSPDU, see Clause 8.2.3.5.

OutNonSafetyData

“Non-safe data” see Clause 8.2.1.10.

Table 9 – ReadSafetyData Method AddressSpace definition

Attribute

Value

BrowseName

ReadSafetyData

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

HasProperty

Variable

OutputArguments

Argument[]

PropertyType

Mandatory

Conformance Units

ReadSafetyData

This method is mandatory for the profile SafetyProviderServerMapper and optional for the profile SafetyProviderPubSubMapper (see 13.2.2.1). It is provided for each SafetyProvider serving as a diagnostic interface, see Clause 9.2.

Signature

ReadSafetyDiagnostics (

[out]UInt32InSafetyConsumerID,

[out]UInt32InMonitoringNumber,

[out]InFlagsTypeInFlags,

[out] StructureOutSafetyData,

[out]OutFlagsTypeOutFlags,

[out]UInt32OutSPDU_ID_1,

[out]UInt32OutSPDU_ID_2,

[out]UInt32OutSPDU_ID_3,

[out]UInt32OutSafetyConsumerID,

[out]UInt32OutMonitoringNumber,

[out]UInt32OutCRC,

[out] StructureOutNonSafetyData)

;

Table 10 – ReadSafetyDiagnostics Method Arguments

Argument

Description

InSafetyConsumerID

see Table 8

InMonitoringNumber

see Table 8

InFlags

see Table 8

OutSafetyData

see Table 8

OutFlags

see Table 8

OutSPDU_ID_1

see Table 8

OutSPDU_ID_2

see Table 8

OutSPDU_ID_3

see Table 8

OutSafetyConsumerID

see Table 8

OutMonitoringNumber

see Table 8

OutCRC

see Table 8

OutNonSafetyData

see Table 8

Table 11 – ReadSafetyDiagnostics Method AddressSpace definition

Attribute

Value

BrowseName

ReadSafetyDiagnostics

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

OutputArguments

Argument[]

PropertyType

Mandatory

Conformance Units

ReadSafetyDiagnostics

[RQ6.7] Instances of SafetyProviderType shall use non-abstract DataTypes for the arguments OutSafetyData and OutNonSafetyData.

This object is mandatory for the profile SafetyProviderPubSubMapper (see 13.2.2.1) and the profile SafetyConsumerPubSubMapper (see 13.2.2.2). It is used by the SafetyProvider to subscribe to the RequestSPDU and to publish the ResponseSPDU. The data type of RequestSPDU is structured in the same way as the input arguments of ReadSafetyData. The data type of ResponseSPDU is structured in the same way as the output arguments of ReadSafetyData.

Both variables have a counterpart within the information model of the SafetyConsumer. The SafetyConsumer publishes the RequestSPDU and subscribes to the ResponseSPDU.

Table 12 – SafetyPDUsType Definition

Attribute

Value

BrowseName

SafetyPDUsType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of BaseObjectType

HasComponent

Variable

<RequestSPDU>

RequestSPDUDataType

BaseDataVariableType

Mandatory Placeholder

HasComponent

Variable

<ResponseSPDU>

ResponseSPDUDataType

BaseDataVariableType

Mandatory Placeholder

Conformance Units

SafetyPDUs

The object SafetyPDUS shall contain exactly one reference to a variable of a type RequestSPDUDataType and exactly one reference to a variable of a subtype of type ResponseSPDUDataType.

For example, Figure 8 shows a distributed safety application with four automation components. It is assumed that Automation Component 1 sends a value to the other three components using three SafetyProviders, each comprising a pair of SafetyPDUs. Note that for each recipient, there is an individual pair of SafetyPDUs.

image013.png

Figure 8 – Safety Multicast with three recipients using OPC UA PubSub

Figure 9 shows the safety parameters for the SafetyProvider and the SafetyConsumer.

image014.png

Figure 9 – OPC UA Safety Parameters for the SafetyProvider and the SafetyConsumer.

Table 13 – SafetyProviderParametersType Definition

Attribute

Value

BrowseName

SafetyProviderParametersType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of BaseObjectType

HasProperty

Variable

SafetyProviderIDConfigured

UInt32

PropertyType

Mandatory

HasProperty

Variable

SafetyProviderIDActive

UInt32

PropertyType

Mandatory

HasProperty

Variable

SafetyBaseIDConfigured

Guid

PropertyType

Mandatory

HasProperty

Variable

SafetyBaseIDActive

Guid

PropertyType

Mandatory

HasProperty

Variable

SafetyProviderLevel

Byte

PropertyType

Mandatory

HasProperty

Variable

SafetyStructureSignature

UInt32

PropertyType

Mandatory

HasProperty

Variable

SafetyStructureSignatureVersion

UInt16

PropertyType

Mandatory

HasProperty

Variable

SafetyStructureIdentifier

String

PropertyType

Mandatory

HasProperty

Variable

SafetyProviderDelay

UInt32

PropertyType

Mandatory

HasProperty

Variable

SafetyServerImplemented

Boolean

PropertyType

Mandatory

HasProperty

Variable

SafetyPubSubImplemented

Boolean

PropertyType

Mandatory

Conformance Units

SafetyProviderParameters

NOTE: Refer to Clause 7.3.2. for more details on the Safety Parameter Interface (SPI) of the SafetyProvider.

NOTE: The parameters for SafetyProviderID and SafetyBaseID exist in pairs for “Configured” and “Active” states:

  • SafetyProviderIDConfigured and SafetyProviderIDActive,
  • SafetyBaseIDConfigured and SafetyBaseIDActive.

The “[...]Configured” parameters shall always deliver the values as configured via the SPI. The “[...]Active” parameters shall deliver

  • the corresponding “[...]Configured” values if the system is still offline;
  • the values which have been set during runtime via the SAPI parameters (SafetyProviderID, SafetyBaseID);
  • the corresponding “[...]Configured” values if the active values have been set to zero via the SAPI parameters (SafetyProviderID, SafetyBaseID).

The Property SafetyBaseIDConfigured is shared for all SafetyProviders with the same SafetyBaseIDConfigured value. If multiple instances of SafetyObjectsType are running on the same node, it is a viable optimization that a property “SafetyBaseIDConfigured” is referenced by multiple SafetyProviders and/or SafetyConsumers.

For releases up to Release 2.0 of the specification, the value for the SafetyStructureSignatureVersion shall be 0x0001 (see RQ8.18 in 8.2.3.4).

Table 14 – SafetyConsumerParametersType Definition

Attribute

Value

BrowseName

SafetyConsumerParametersType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of BaseObjectType

HasProperty

Variable

SafetyProviderIDConfigured

UInt32

PropertyType

Mandatory

HasProperty

Variable

SafetyProviderIDActive

UInt32

PropertyType

Mandatory

HasProperty

Variable

SafetyBaseIDConfigured

Guid

PropertyType

Mandatory

HasProperty

Variable

SafetyBaseIDActive

Guid

PropertyType

Mandatory

HasProperty

Variable

SafetyConsumerIDConfigured

UInt32

PropertyType

Mandatory

HasProperty

Variable

SafetyConsumerIDActive

UInt32

PropertyType

Mandatory

HasProperty

Variable

SafetyProviderLevel

Byte

PropertyType

Mandatory

HasProperty

Variable

SafetyStructureSignature

UInt32

PropertyType

Mandatory

HasProperty

Variable

SafetyStructureSignatureVersion

UInt16

PropertyType

Optional

HasProperty

Variable

SafetyStructureIdentifier

String

PropertyType

Optional

HasProperty

Variable

SafetyConsumerTimeout

UInt32

PropertyType

Mandatory

HasProperty

Variable

SafetyOperatorAckNecessary

Boolean

PropertyType

Mandatory

HasProperty

Variable

SafetyErrorIntervalLimit

UInt16

PropertyType

Mandatory

HasProperty

Variable

SafetyClientImplemented

Boolean

PropertyType

Mandatory

HasProperty

Variable

SafetyPubSubImplemented

Boolean

PropertyType

Mandatory

Conformance Units

SafetyConsumerParameters

NOTE: Refer to Clause 7.4.3. for more details on the Safety Parameter Interface (SPI) of the SafetyConsumer.

NOTE: The parameters for SafetyProviderID, SafetyBaseID and SafetyConsumerID exist in pairs for “Configured” and “Active” states:

  • SafetyProviderIDConfigured and SafetyProviderIDActive,
  • SafetyBaseIDConfigured and SafetyBaseIDActive,
  • SafetyConsumerIDConfigured and SafetyConsumerIDActive.

The “[...]Configured” parameters shall always deliver the values as configured via the SPI. The “[...]Active” parameters shall deliver

  • the corresponding “[...]Configured” values if the system is still offline;
  • the values which have been set during runtime via the SAPI parameters (SafetyProviderID, SafetyBaseID, SafetyConsumerID);
  • the corresponding “[...]Configured” values if the active values have been set to zero via the SAPI parameters (SafetyProviderID, SafetyBaseID, SafetyConsumerID).

NOTE: The nodes SafetyStructureIdentifier and SafetyStructureSignatureVersion are optional, because SafetyStructureSignature is typically calculated in an offline engineering tool. For small devices, it might be beneficial to only upload the SafetyStructureSignature to the device, but not SafetyStructureIdentifier and SafetyStructureSignatureVersion in order to save bandwidth and/or memory.

This is a subtype of the Byte DataType with the OptionSetValues Property defined. The InFlagsType is formally defined in Table 15.

Table 15 – InFlagsType Values

Value

Bit No.

Description

CommunicationError

0

0: No error

1: An error was detected in the previous ResponseSPDU.

OperatorAckRequested

1

Used to inform the SafetyProvider that operator acknowledgment is requested.

FSV_Activated

2

Is used for conformance test of SafetyConsumer.SAPI.FSV_Activated

Bits 3..7 are reserved for future use shall be set to zero by the SafetyConsumer and shall not be evaluated by the SafetyProvider.

The InFlagsType representation in the AddressSpace is defined in Table 16.

Table 16 – InFlagsType Definition

Attribute

Value

BrowseName

InFlagsType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the Byte DataType defined in OPC 10000-5

0:HasProperty

Variable

0:OptionSetValues

0:LocalizedText []

0:PropertyType

Conformance Units

SafetySupport

NOTE: CommunicationError can be used as a trigger, e.g., for a communication analysis tool. It is not forwarded to the safety application by the SafetyProvider. If CommunicationError is needed in the safety application, bidirectional communication can be implemented and the value of CommunicationError can be put into the user data.

This is a subtype of the Byte DataType with the OptionSetValues Property defined. The OutFlagsType is formally defined in Table 17.

Table 17 – OutFlagsType Values

Value

Bit No.

Description

OperatorAckProvider

0

Operator acknowledgment at the provider, hereby forwarded to the SafetyConsumer, see OperatorAckProvider in the SAPI of the SafetyProvider, Clause 7.3.1.

ActivateFSV

1

Activation of fail-safe values by the safety application at the SafetyProvider, hereby forwarded to the SafetyConsumer, see ActivateFSV in the SAPI of the SafetyProvider, Clause 7.3.1

TestModeActivated

2

Enabling and disabling of test mode in the SafetyProvider, hereby forwarded to the SafetyConsumer, see EnableTestMode in the SAPI of the SafetyProvider, Clause 7.3.1

Bits 3..7 are reserved for future use shall be set to zero by the SafetyProvider and shall not be evaluated by the SafetyConsumer.

The OutFlagsType representation in the AddressSpace is defined in Table 18.

Table 18 – OutFlagsType Definition

Attribute

Value

BrowseName

OutFlagsType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the Byte DataType defined in OPC 10000-5

0:HasProperty

Variable

0:OptionSetValues

0:LocalizedText []

0:PropertyType

Conformance Units

SafetySupport

Table 19 – RequestSPDUDataType Structure

Name

Type

Description

RequestSPDUDataType

structure

InSafetyConsumerID

UInt32

See corresponding method argument in Table 8.

InMonitoringNumber

UInt32

See corresponding method argument in Table 8.

InFlags

InFlagsType

See corresponding method argument in Table 8.

NOTE: The Prefix “In” should be interpreted from the SafetyProvider’s point of view and is used in a consistent manner to the parameters of the method ReadSafetyData (see 6.1.3).

The representation in the AddressSpace of the RequestSPDUDataType DataType is defined in Table 20.

Table 20 – RequestSPDUDataType definition

Attributes

Value

BrowseName

RequestSPDUDataType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of Structure defined in OPC 10000-5.

Conformance Units

SafetyPDUs

Table 21 – ResponseSPDUDataType Structure

Name

Type

Description

ResponseSPDUDataType

structure

OutFlags

OutFlagsType

See corresponding method argument in Table 8.

OutSPDU_ID_1

UInt32

See corresponding method argument in Table 8.

OutSPDU_ID_2

UInt32

See corresponding method argument in Table 8.

OutSPDU_ID_3

UInt32

See corresponding method argument in Table 8.

OutSafetyConsumerID

UInt32

See corresponding method argument in Table 8.

OutMonitoringNumber

UInt32

See corresponding method argument in Table 8.

OutCRC

UInt32

See corresponding method argument in Table 8.

NOTE: The Prefix “Out” should be interpreted from the SafetyProvider’s point of view and is used in a consistent manner to the parameters of the method ReadSafetyData (see 6.1.3).

[RQ6.12] To define the concrete data type for the ResponseSPDU (which specifies the concrete data types for SafetyData and NonSafetyData, respectively), proceed as follows: (1) Derive a concrete data type from the abstract ResponseSPDUDataType. (2) In doing so, add the following fields to the structure in the given order: (a) First, field OutSafetyData with the concrete structure data type for the SafetyData (which has to be a concrete structure data type, see clause 8.2.1.4). (b) Second, field NonSafetyData with the concrete structure data type for the NonSafetyData (or a placeholder data type, see requirement RQ6.8).

[RQ6.8] To avoid possible problems with empty structures, the dummy structure NonSafetyDataPlaceholder shall be used as DataType for OutNonSafetyData when no non-safety data is used. The datatype-node defining this structure has a fixed node-ID and contains a single Boolean.

The representation in the AddressSpace of the ResponseSPDUDataType DataType is defined in Table 22.

Table 22 – ResponseSPDUDataType definition

Attributes

Value

BrowseName

ResponseSPDUDataType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of Structure defined in OPC 10000-5

Conformance Units

SafetyPDUs

Table 23 – NonSafetyDataPlaceholderDataType Structure

Name

Type

Description

NonSafetyDataPlaceholderDataType

structure

Dummy

Boolean

Dummy variable to avoid empty structures.

NOTE: The receiver should not evaluate the value of ‘Dummy’.

Future versions may use different identifiers (such as “ReadSafetyDataV2” for the method when using Client/Server communication or “RequestSPDUV2DataType” and “ResponseSPDUV2DataType” for the SPDU data types when using PubSub communication), allowing a SafetyProvider to implement multiple versions of OPC UA Safety at the same time. Hence, the same SafetyProvider can be accessed by SafetyConsumers of different versions.

OPC UA Safety supports sending of the basic data types listed in OPC UA within SafetyData (see OPC 10000-3 and OPC 10000-6). The supported data types are vendor-specific.

[RQ6.9] Only scalar data types shall be used. Arrays are currently not supported by this part.

The supported maximum length of the SafetyData is vendor-specific but still limited to 1500 bytes. Typical values for the maximum length include 1,16, 64, 256, 1024, and 1500 bytes.

[RQ6.10] For controller-like devices, the supported data types and the maximum length of the SafetyData shall be listed in the user manual.

[RQ6.11] For the data type Boolean, the value 0x01 shall be used for ‘true’ and the value 0x00 shall be used for ‘false’.

NOTE: It is recommended to send multiple Booleans in separate variables. However, in small devices, it may be necessary to combine a set of 8 Booleans in one variable for performance reasons. In this case, the datatype ‘unsigned Byte’ can be used.

OPC UA Safety uses the OPC UA services for connection establishment, it poses no additional requirement to these services.

NOTE: This version of the specification describes configuration only at engineering time. This means that the parameters defined in the SPI (see Clauses 7.3.2 and 7.4.1) are read-only via the interface described in this specification. Changing of parameters are expected to be done in a safety-related way, using the respective tools and interfaces provided by the vendor. Future versions of this part may specify a vendor-independent interface for configuration.