Annex C (informative) Use of OPC UA FX with OPC UA Safety
C.1 OPC UA Safety Information Model

For the reader’s convenience, some aspects of the OPC UA Safety Information Model are explained in this clause. For normative aspects, please refer to OPC 10000-15.

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.

As defined in OPC 10000-15, the SafetyProvider (representing the source for safety data, such as an emergency stop button) exposes:

The corresponding SafetyConsumer (representing the sink for safety data) mirrors input and output variables, e.g., the safety application data is contained in its input Variable. It exposes:

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.

image083.png

Figure C.1 – SafetyProvider and SafetyConsumer Information Model

C.2 Usage of OPC UA safety Variables in a FunctionalEntity

Figure C.2 indicates a FunctionalEntity, which includes a SafetyProvider. The FunctionalEntity contains safety and non-safety Variables in its InputData and OutputData.

image084.png

Figure C.2 – FunctionalEntity with safety data

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

Safety and non-safety data may be referenced in a preconfigured PublishedDataSet or SubscribedDataSet.

C.3 Usage of OPC UA safety Variables in Connections

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.

image085.png

Figure C.3 – Example of a logical connection with 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 (e.g., Out_X5  IN_A1).

In this example, all output Variables, including the data related to the SafetyProvider and SafetyConsumer, share the same NetworkMessage.

image086.png

Figure C.4 – Example of a logical connection with bidirectional safety data exchange