Subclause 6.2 describes the identifiers, types and structure of the Objects and Methods that are used to implement the OPC UA mappers defined in this document. 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.

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. It is assumed that errors can occur during the transfer of the Information Model from one engineering system to another in the context of offline engineering. Therefore, the programmer of the safety application is responsible for the verification and validation of the safety application.

Consequently, all type values described in 6.2 are defined as read-only, i.e. they cannot 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 this document. 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 SafetyConsumers. SafetyACSet is intended for safety-related purposes only. It should not reference non-safety-related items.

See Table 3 for the definition of the SafetyACSet.

Table 3 – 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 DataType SafetyProviderType for each SafetyProvider it implements, and one OPC UA Object derived from DataType SafetyConsumerType for each SafetyConsumer it implements. The corresponding Information Models shown in Figure 3 and Figure 4 shall be used.

A description of the graphical notation for the different types of Nodes and References (shown in Figure 3, Figure 4, and Figure 6) can be found in OPC UA 10000-3.

Figure 3 describes the SafetyProvider and the SafetyConsumer.

NOTE 1 This document assumes (atomic) consistent data exchange between OPC mappers of the two endpoints.

[RQ6.3a] For implementations supporting OPC UA Client/Server, the Call Service of the Method Service Set (see OPC UA 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.3b] 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 2 The terms “request” and “response” refer to the behaviour on the layer of this document. Within the PubSub context, both requests and responses are realized by repeatedly publishing and subscribing Messages, see Figure 14.

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

Figure 3 – Server Objects for OPC UA Safety

NOTE 3 For the input/output arguments of the Methods ReadSafetyData and ReadSafetyDiagnostics, see 6.2.2.3 and 6.2.2.4. For the parameters of the SafetyProvider and SafetyConsumer, see Figure 6, Table 12, and Table 13. For RequestSPDU and ResponseSPDU, see Table 7, Table 18, Table 20, and 7.2.1.

Figure 4 shows the instances of Server Objects for this document. The ObjectType for the SafetyProviderType contains Methods having outputs of the abstract DataType Structure. Each instance of a SafetyProvider requires its own copy of the Methods which contain the concrete DataTypes for OutSafetyData and OutNonSafetyData.

Figure 4 – Instances of Server Objects for this document

[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 DataTypes derived from SafetyProviderType or SafetyConsumerType):

The references shown in Figure 4 originating at SafetyProviderType or SafetyConsumerType and below shall be of ReferenceType HasComponent (and shall not be derived from ReferenceType HasComponent) for Object References or ReferenceType HasProperty (and shall not be derived from ReferenceType 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 IEC 62541, the order of Method arguments is relevant.

See Table 4 for the definition of the SafetyObjectsType.

Table 4 – SafetyObjectsType definition

Attribute	Value
BrowseName	SafetyObjectsType
IsAbstract	True
References	Node class	BrowseName	DataType	TypeDefinition	Modelling rule
Subtype of BaseObjectType
Conformance units
SafetySupport

See Table 5 for the definition of the SafetyProviderType.

Table 5 – 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

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

See Table 6 for the definition of the SafetyConsumerType.

Table 6 – 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 Facet SafetyProviderServerMapper. 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 can receive invalid responses resulting in a safe reaction which can lead to either spurious trips or system unavailability, or both.

See Table 7 for Method ReadSafetyData’s arguments and Table 8 for its AdressSpace definition.

The Method argument OutSafetyData has an application-specific DataType derived from Structure. This DateType (including the DataTypeID) 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 substitute values instead (see state S16 in Table 34 as well as 7.2.3.2 and 7.2.3.5). The Method argument OutNonSafetyData has an application-specific DataType derived from Structure.

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 7 – ReadSafetyData Method arguments

Argument	Description
InSafetyConsumerID	“Safety Consumer Identifier”, see SafetyConsumerID in Table 23.
InMonitoringNumber	“MonitoringNumber of the RequestSPDU”, see 7.2.1.3 and MonitoringNumber in Table 23.
InFlags	“Octet with non-safety-related flags from SafetyConsumer”, see 6.2.3.1.
OutSafetyData	“SafetyData”, see 7.2.1.5.
OutFlags	“Octet with safety-related flags from SafetyProvider”, see 6.2.3.2.
OutSPDU_ID_1	“Safety PDU Identifier Part1”, see 7.2.3.2.
OutSPDU_ID_2	“Safety PDU Identifier Part2”, see 7.2.3.2.
OutSPDU_ID_3	“Safety PDU Identifier Part3”, see 7.2.3.2.
OutSafetyConsumerID	“Safety Consumer Identifier”, see SafetyConsumerID in Table 23 and Table 26.
OutMonitoringNumber	MonitoringNumber of the ResponseSPDU, see 7.2.1.9, 7.2.3.1, and Figure 11.
OutCRC	CRC over the ResponseSPDU, see 7.2.3.6.
OutNonSafetyData	“Non-safe data” see 7.2.1.11.

Table 8 – 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 Facet SafetyProviderServerMapper and optional for the Facet SafetyProviderPubSubMapper. It is provided for each SafetyProvider serving as a Diagnostic Interface, see 6.4.3.

See Table 9 for the arguments of Method ReadSafetyDiagnostics and Table 10 for its AddressSpace definition.

The Method arguments OutSafetyData and OutNonSafetyData are application-specific types derived from Structure.

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 9 – ReadSafetyDiagnostics Method arguments

Argument	Description
InSafetyConsumerID	see Table 7
InMonitoringNumber	see Table 7
InFlags	see Table 7
OutSafetyData	see Table 7
OutFlags	see Table 7
OutSPDU_ID_1	see Table 7
OutSPDU_ID_2	see Table 7
OutSPDU_ID_3	see Table 7
OutSafetyConsumerID	see Table 7
OutMonitoringNumber	see Table 7
OutCRC	see Table 7
OutNonSafetyData	see Table 7

Table 10 – ReadSafetyDiagnostics Method AddressSpace definition

Attribute	Value
BrowseName	ReadSafetyDiagnostics
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	OutputArguments	Argument[]	PropertyType	Mandatory
Conformance units
ReadSafetyDiagnostics

This Object is mandatory for the Facet SafetyProviderPubSubMapper and the Facet SafetyConsumerPubSubMapper It is used by the SafetyProvider to subscribe to the RequestSPDU and to publish the ResponseSPDU. The DataType of RequestSPDU is structured in the same way as the input arguments of ReadSafetyData. The DataType of ResponseSPDU is structured in the same way as the output arguments of ReadSafetyData.

See Table 11 for the definition of the SafetyPDUsType.

Both variables in the SafetyPDUsType have a counterpart within the Information Model of the SafetyConsumer. The SafetyConsumer publishes the RequestSPDU and subscribes to the ResponseSPDU.

Table 11 – 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 DataType RequestSPDUDataType and exactly one Reference to a Variable of a subtype of DataType ResponseSPDUDataType.

For example, Figure 5 shows a distributed safety application with four SafetyAutomationComponents. It is assumed that SafetyAutomationComponent 1 sends a value to the other three SafetyAutomationComponents using three SafetyProviders, each comprising a pair of SPDUs. For each recipient, there is an individual pair of SPDUs.

Figure 5 – Safety multicast with three recipients using IEC 62541 PubSub

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

Figure 6 – Safety parameters for the SafetyProvider and the SafetyConsumer

Table 12 shows the definition for the SafetyProviderParametersType. Refer to 6.3.3.3 for more details on the Safety Parameter Interface (SPI) of the SafetyProvider.

Table 12 – 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

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 either multiple SafetyProviders or SafetyConsumers, or both.

For releases up to Release 2.0 of the document, the value for the SafetyStructureSignatureVersion shall be 0x0001 (see RQ7.21 in 7.2.3.5).

Table 13 shows the definition of the SafetyConsumerParametersType. The Properties SafetyStructureIdentifier and SafetyStructureSignatureVersion are optional, because SafetyStructureSignature is typically calculated in an offline engineering tool. For small devices, it could be beneficial to only upload the SafetyStructureSignature to the device, but not SafetyStructureIdentifier and SafetyStructureSignatureVersion in order to save either bandwidth or memory, or both. Refer to 6.3.4.4 for more details on the Safety Parameter Interface (SPI) of the SafetyConsumer.

Table 13 – 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

The parameters for SafetyProviderID, SafetyBaseID and SafetyConsumerID exist in pairs for “Configured” and “Active” states: SafetyProviderIDConfigured and SafetyProviderIDActive, SafetyBaseIDConfigured and SafetyBaseIDActive, and 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).

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

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 necessary in the safety application, bidirectional communication can be implemented and the value of CommunicationError can be put into the user data.

Table 14 – 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	Used for conformance test of SafetyConsumer.SAPI.FSV_Activated.

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

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

Table 15 – InFlagsType dDefinition

Attribute		Value
BrowseName		InFlagsType
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	Other
Subtype of the Byte DataType defined in OPC 10000-3
0:HasProperty	Variable		0:OptionSetValues	0:LocalizedText []	0:PropertyType
Conformance units
SafetySupport

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

Table 16 – 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, 6.3.3.2.
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, 6.3.3.2.
TestModeActivated	2	Enabling and disabling of test mode in the SafetyProvider, hereby forwarded to the SafetyConsumer, see EnableTestMode in the SAPI of the SafetyProvider, 6.3.3.2.

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

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

Table 17 – OutFlagsType dDefinition

Attribute		Value
BrowseName		OutFlagsType
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	Other
Subtype of the Byte DataType defined in OPC 10000-3
0:HasProperty	Variable		0:OptionSetValues	0:LocalizedText []	0:PropertyType
Conformance units
SafetySupport

Table 18 shows the definition of the RequestSPDUDataType. The Prefix “In” is interpreted from the SafetyProvider’s point of view and is used in a consistent manner to the parameters of the Method ReadSafetyData (see 6.2.2.3).

Table 18 – RequestSPDUDataType structure

Name	Type	Description
RequestSPDUDataType	structure
InSafetyConsumerID	UInt32	See corresponding Method argument in Table 7.
InMonitoringNumber	UInt32	See corresponding Method argument in Table 7.
InFlags	InFlagsType	See corresponding Method argument in Table 7.

The representation in the AddressSpace of the RequestSPDUDataType is defined in Table 19.

Table 19 – RequestSPDUDataType definition

Attributes	Value
BrowseName	RequestSPDUDataType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of Structure defined in OPC 10000-3.
Conformance units
SafetyPDUs

Table 20 shows the ResponseSPDUDataType Structure. The Prefix “Out” is interpreted from the SafetyProvider’s point of view and is used in a consistent manner to the parameters of the Method ReadSafetyData (see 6.2.2.3).

Table 20 – ResponseSPDUDataType structure

Name	Type	Description
ResponseSPDUDataType	structure
OutFlags	OutFlagsType	See corresponding Method argument in Table 7.
OutSPDU_ID_1	UInt32	See corresponding Method argument in Table 7.
OutSPDU_ID_2	UInt32	See corresponding Method argument in Table 7.
OutSPDU_ID_3	UInt32	See corresponding Method argument in Table 7.
OutSafetyConsumerID	UInt32	See corresponding Method argument in Table 7.
OutMonitoringNumber	UInt32	See corresponding Method argument in Table 7.
OutCRC	UInt32	See corresponding Method argument in Table 7.

[RQ6.7] To define the concrete DataType for the ResponseSPDU (which specifies the concrete DataTypes for SafetyData and NonSafetyData, respectively), proceed as follows: (1) Derive a concrete DataType 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 DataType for the SafetyData (see 7.2.1.5). (b) Second, field NonSafetyData with the concrete Structure DataType for the NonSafetyData (or a placeholder DataType, 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 NonSafetyData is used. The DataType Node defining this Structure has a fixed NodeID and contains a single Boolean.

The representation in the AddressSpace of the ResponseSPDUDataType is defined in Table  21.

Table  21 – ResponseSPDUDataType definition

Attributes	Value
BrowseName	ResponseSPDUDataType
IsAbstract	True
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of Structure defined in OPC 10000-3
Conformance units
SafetyPDUs

Table 22 shows the definition of the NonSafetyDataPlaceholderDataType. The receiver shall not evaluate the value of ‘dummy’.

Table 22 – NonSafetyDataPlaceholderDataType structure

Name	Type	Description
NonSafetyDataPlaceholderDataType	Structure
Dummy	Boolean	Dummy Variable to avoid empty structures.

Future versions may use different identifiers (such as ReadSafetyDataV2 for the Method when using Client/Server communication or RequestSPDUV2DataType and ResponseSPDUV2DataType for the SPDU DataTypes when using PubSub communication), allowing a SafetyProvider to implement multiple versions of this document at the same time. Hence, the same SafetyProvider can be accessed by SafetyConsumers of different versions.

This document supports sending of the Built-in and Simple DataTypes specified in OPC UA (see OPC 10000-3 and OPC 10000-6) within SafetyData. The supported DataTypes are vendor-specific.

[RQ6.9] Only scalar DataTypes shall be used. Arrays are currently not supported by this document.

The supported maximum length of the SafetyData is vendor-specific but still limited to 1 500 octets. Typical values for the maximum length include 1 octet, 16 octets, 64 octets, 256 octets, 1 024 octets, and 1 500 octets.

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

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

It is recommended to send multiple Booleans in separate variables. However, in small devices, it can be necessary to combine a set of 8 Booleans in one Variable for performance reasons. In this case, the DataType Byte can be used.

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

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