### 6.1 ObjectType Definition

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

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

References NodeClass BrowseName TypeDefinition
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.

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.

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. 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.

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 Object Parameters   SafetyParametersType Mandatory

Table 8 – SafetyObjectsType definition

Attribute Value
BrowseName SafetyObjectsType
IsAbstract True

Subtype of the BaseObjectType defined in OPC 10000-5

References NodeClass BrowseName DataType TypeDefinition ModellingRule

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]	UInt32	InSafetyConsumerID
[in]	UInt32	InMonitoringNumber
[in]	Byte	InFlags
[out]	Structure	OutSafetyData
[out]	Byte	OutFlags
[out]	UInt32	OutSPDU_ID_1
[out]	UInt32	OutSPDU_ID_2
[out]	UInt32	OutSPDU_ID_3
[out]	UInt32	OutSafetyConsumerID
[out]	UInt32	OutMonitoringNumber
[out]	UInt32	OutCRC
[out]	Structure	OutNonSafetyData)
;


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.