OPC UA Safety defines how to exchange safety data between AutomationComponents using either Client / Server or PubSub as the underlying OPC UA communication model. Client / Server support for logical connections will be specified in a future version of this document. The usage of PubSub is assumed for the following text.
- a structured input Variable of DataType RequestSPDUDataType, containing safety protocol elements (monitoring number, SafetyConsumer ID, etc.).
- a structured output Variable of a DataType derived from the ResponseSPDUDataType, containing as a structured sub-element the safety application data (e.g., button pressed/released), safety protocol elements (monitoring number, CRC, etc.), and optionally additional non-safety related data.
- a structured input Variable of a DataType derived from the ResponseSPDUDataType. Note that SafetyProvider and SafetyConsumer have identical definitions of this DataType.
- a structured output Variable of DataType RequestSPDUDataType.
Refer to OPC 10000-15 for the ResponseSPDUDataType definition and on how to calculate the value of OutCRC. Figure C.1 illustrates an Information Model for a SafetyProvider and its corresponding SafetyConsumer. Safety Variables are represented as dashed yellow boxes.
From a FunctionalEntity’s perspective, the safety Variables CtrARequest and CtrAResponse are organized within the InputData and OutputData. In addition, these Variables are referenced by HasComponent References from the SafetyPDUs Object of the SafetyProvider (see also OPC 10000-15).
OPC UA Safety provides an application protocol using safety Variables, which is implemented by the SafetyProvider / SafetyConsumer. The communication layer is completely unaware that safety data is being transported.
Any logical connection may therefore reference any number of safety and non-safety Variables, even from different SafetyProviders or SafetyConsumers. There is nothing special in establishing a connection containing safety Variables. In fact, the connection establishment is unaware of safety data being transported.
Figure C.3 shows an example of a logical connection between FunctionalEntity_A and FunctionalEntity_B. The exchange of data is represented as dotted lines. The logical connection contains the unidirectional safety data exchange between the SafetyProvider on Controller A and the SafetyConsumer on Controller B (CtrBRequest à CtrARequest, CtrAResponse à CtrBResponse) and, in addition, data exchange between other Variables of these FunctionalEntities (e.g., Out_X5 IN_A1).
OPC 10000-15 uses the terms unidirectional and bidirectional from a safety application’s point of view, referring to the flow of safety application data. From a communication perspective, however, data exchange is always bidirectional (ResponseSPDU containing the safety application data in one direction and RequestSPDU in the other direction), even for a unidirectional safety data exchange.
In many cases, safety communication between two controllers is a bidirectional safety data exchange. This data exchange may also be organized in one logical connection, as indicated in Figure C.4. It contains the bidirectional safety data exchange and additional data exchange of other Variables of (e.g., Out_X5 IN_A1).