The NamespaceUri of OPC UA Safety is http://opcfoundation.org/UA/Safety.

Under this URI the node set plus the list of nodes including the NodeIds can be found.

[RQ6.1] Each server shall have a singleton folder called SafetyDeviceSet with a fixed NodeId in the namespace of OPC UA Safety. Because all SafetyProviders on this server contain a nonhierarchical reference to this variable, it can be used to directly access all SafetyProviders by following the references in backward direction.

Table 5 – SafetyDeviceSet definition

Attribute

Value

BrowseName

SafetyDeviceSet

References

NodeClass

BrowseName

TypeDefinition

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

HasTypeDefinition

ObjectType

FolderType

[RQ6.2] In addition, a server shall comprise one OPC UA object derived from type SafetyProviderType for each SafetyProvider they implement. The corresponding information model shown in Figure 8 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 8) can be found in OPC 10000-3.

Figure 6 shows the Safety Parameters for SafetyProvider.

image009.png

Figure 6 – OPC UA Safety Parameters for SafetyProvider

Figure 7 describes the SafetyProviderType.

Note: OPC UA Safety assumes (atomic) consistent data exchange.

[RQ6.3] For OPC UA Safety V1.0, the Call-Service of the Method Service Set (see OPC 10000-4) shall be used. The Call-Service supports consistent data exchange. The Method "ReadSafetyData" uses the OPC UA-Server with 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.4] For diagnostic purposes, the SPDUs received and sent shall be accessible by calling the method ReadDiagnosticsData.

image010.png

Figure 7 – Server Objects for OPC UA Safety

NOTE: At this stage of the specification, an information model of the SafetyConsumer is not required.

The method argument SafetyData has an application-specific type derived from Structure. This type (including the type identifier) are 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 25 – SafetyConsumer driver states as well as Clauses 8.1.3.2 and 8.1.3.4).

Figure 8 shows the Instances of server objects for OPC UA Safety. There are two things worth mentioning:

  • The ObjectType for the SafetyProvider contains the methods with the abstract DataType BaseDataType. Each instance of a SafetyProvider needs its own copy of the methods which contains the concrete DataType of the SafetyData.
  • The Property SafetyBaseID is shared for all SafetyProviders with the same SafetyBaseID value.

image011.png

Figure 8 – Instances of server objects for OPC UA Safety

Note: if multiple instances of SafetyProviderType are running on the same node, it is a viable optimization that a parameter object is referenced by multiple providers. Likewise, a property may be referenced by multiple providers.

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

The references shown in Figure 8 originating at SafetyProviderType 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 6 – Type Definition of OPC UA Safety Parameters

Attribute

Value

BrowseName

SafetyParametersType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of BaseObjectType

HasProperty

Variable

SafetyProviderLevel

Byte

PropertyType

Mandatory

HasProperty

Variable

SafetyProviderDelay

UInt32

PropertyType

Mandatory

HasProperty

Variable

StructureSignatureVersion

UInt16

PropertyType

Mandatory

HasProperty

Variable

StructureIdentifier

String

PropertyType

Mandatory

HasProperty

Variable

SafetyBaseID

Guid

PropertyType

Mandatory

HasProperty

Variable

SafetyProviderID

UInt32

PropertyType

Mandatory

[RQ6.6] For this V1.0 version of the specification, the value for the StructureSignatureVersion shall be 0x0001.

Table 7 – Type Definition of OPC UA Safety SafetyProvider

Attribute

Value

BrowseName

SafetyProviderType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of SafetyObjectsType

HasComponent

Method

ReadSafetyData

Mandatory

HasComponent

Method

ReadSafetyDiagnostics

Mandatory

HasComponent

Object

Parameters

SafetyParametersType

Mandatory

Table 8 SafetyObjectsType definition

Attribute

Value

BrowseName

SafetyObjectsType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseObjectType defined in OPC 10000-5

This method reads safe data 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.

Signature

ReadSafetyData (

[in]UInt32InSafetyConsumerID

[in]UInt32InMonitoringNumber

[in]ByteInFlags

[out] StructureOutSafetyData

[out]ByteOutFlags

[out]UInt32OutSPDU_ID_1

[out]UInt32OutSPDU_ID_2

[out]UInt32OutSPDU_ID_3

[out]UInt32OutSafetyConsumerID

[out]UInt32OutMonitoringNumber

[out]UInt32OutCRC

[out] StructureOutNonSafetyData)

;

Table 9 –ReadSafetyData Method Arguments

Argument

Description

InSafetyConsumerID

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

InMonitoringNumber

“Monitoring Number of the RequestSPDU”, see Clause 8.1.1.2 and MonitoringNumber in Table 13.

InFlags

“Byte with Non safety Flags from SafetyConsumer“, see Flags in Table 18.

OutSafetyData

“Safety Data”, see Clause 8.1.1.4.

OutFlags

“Byte with Safety Flags from SafetyProviderSafetyProvider“, see Flags in Table 19.

OutSPDU_ID_1

“Safety PDU Identifier Part1”, see Clause  8.1.3.2.

OutSPDU_ID_2

“Safety PDU Identifier Part2”, see Clause  8.1.3.2.

OutSPDU_ID_3

“Safety PDU Identifier Part3”, see Clause  8.1.3.2.

OutSafetyConsumerID

“Safety Consumer Identifier”, see SafetyConsumerID in Table 13 and Table 17Table 13.

OutMonitoringNumber

Monitoring Number of the ResponseSPDU, see Clause 8.1.1.8, Clause  8.1.3.1, and Figure 13.

OutCRC

CRC-checksum over the ResponseSPDU, see Clause 8.1.3.5.

OutNonSafetyData

“Non-safe data” see Clause 8.1.1.10.

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

This method (as part of the OPC UA Mapper) is provided for each SafetyProvider serving as a diagnostic interface, see Clause 9.2.

Signature

ReadSafetyDiagnostics (

[out]UInt32InSafetyConsumerID [out]UInt32InMonitoringNumber

[out]ByteInFlags

[out] StructureOutSafetyData

[out]ByteOutFlags

[out]UInt32OutSPDU_ID_1

[out]UInt32OutSPDU_ID_2

[out]UInt32OutSPDU_ID_3

[out]UInt32OutSafetyConsumerID

[out]UInt32OutMonitoringNumber

[out]UInt32OutCRC

[out] StructureOutNonSafetyData)

;

Table 11 – ReadSafetyDiagnostics Method Arguments

Argument

Description

InSafetyConsumerID

see Table 9

InMonitoringNumber

see Table 9

InFlags

see Table 9

OutSafetyData

see Table 9

OutFlags

see Table 9

OutSPDU_ID_1

see Table 9

OutSPDU_ID_2

see Table 9

OutSPDU_ID_3

see Table 9

OutSafetyConsumerID

see Table 9

OutMonitoringNumber

see Table 9

OutCRC

see Table 9

OutNonSafetyData

see Table 9

Table 12 – ReadSafetyDiagnostics Method AddressSpace definition

Attribute

Value

BrowseName

ReadSafetyDiagnostics

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

OutputArguments

Argument[]

PropertyType

Mandatory

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

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

NonSafetyDataPlaceholderDataType Structure

Name

Type

Description

NonSafetyDataPlaceholderDataType

structure

dummy

Boolean

Dummy variable to avoid empty structures.

Future versions may use different identifiers (such as ReadSafetyDataV2), 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 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 not supported.

The supported maximum length of the user data is vendor specific. Typical values for the maximum length include 1,16,64,256,1024, and 1500 octets.

[RQ6.10] For controller-like devices, the supported data types and the maximum length of the user data 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’.

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 at engineering time, only. This means that the parameters defined in the SPI (see Clauses 7.3.2 and 7.4.1) cannot be configured at runtime.