The most basic type of communication is unidirectional communication, where a safety application on one device (Controller A) sends data to a safety application on another device (Controller B).

image006.png

Figure 3 – Unidirectional Communication

This is accomplished by placing a SafetyProvider on Controller A, and a SafetyConsumer on Controller B. The connection between SafetyProvider and SafetyConsumer can be established and terminated during runtime, allowing different consumers to connect to the same SafetyProvider at different times. Furthermore, the protocol is designed in such a way, that the consumer needs to know the parametrized set of IDs of the SafetyProvider for being able to safely check whether the received data is coming from the expected source. On the other hand, as safety data flows in one direction only, there is no need for the SafetyProvider to check the ID of the consumers. Hence, controller A can – one after another- serve an arbitrarily large number of consumers, and new consumers can be introduced into the system without having to update controller A.

Bidirectional communication means exchange of data in both directions, which is accomplished by placing a SafetyProvider and a SafetyConsumer on each controller. Hence, bidirectional communication is realized using two OPC UA Safety connections.

image007.png

Figure 4 – Bidirectional Communication

Note: Connections can be established and terminated during runtime.

Multicast is defined as sending the same set of data from one device (Controller A) to several other devices (Controller B1, B2,…,BN) simultaneously.

image008.png

Figure 5 – Safety Multicast

Safety multicast is accomplished by placing multiple SafetyProviders on Controller A, and by connecting each of them to a SafetyConsumer on one of the Controllers B1, B2, … BN, each.

The protocol OPC UA Safety is designed in such a way that:

  • the state machine of the SafetyProvider has a low number of states, and thus very low memory demands,
  • all safety-related telegram-checks are executed on the consumer and, thus, the computational demand on the SafetyProvider is low.

Therefore, even if many SafetyProviders are instantiated on a device, the performance requirements will still be moderate.

The properties of simple unicast are also valid for safety multicast: different sets of consumers can connect to SafetyProviders at different times, and new consumers can be introduced into the system without having to reconfigure the SafetyProvider instances. As all SafetyProvider instances send the same safety application data (same data source), it is irrelevant from a safety point of view to which SafetyProvider instance a given SafetyConsumer is connected. Thus, all SafetyProvider instances can be parametrized with the same set of IDs for the SafetyProvider.

OPC UA Safety supports cyclic and acyclic safety communication.

Most safety functions must react timely on external events, such as an emergency stop button being pressed or a light curtain being interrupted. In these applications, a cyclic safety communication is established. That means the SafetyConsumer is executed cyclically, and the time between two consecutive executions is safely bounded. The maximum time between two executions of the SafetyConsumer will contribute to the safety function response time (SFRT).

Some safety functions, such as the transfer of safe configuration data at startup, do not have to react on external events. In this case, it is not required to execute the SafetyConsumer cyclically.

“Qualifier bits” allow the SafetyProvider to indicate the correctness of values on a fine-grained level. It is good practice to attach a qualifier bit to each individual value sent within an SPDU. The qualifier bits are part of the SafetyData and hence not within the scope of this part.

[RQ5.1] However, whenever qualifier bits are used, the values shown in Table 5 shall be used, i.e. 0x1 for a valid value (“good”), and 0x0 for an invalid value (“bad”).

Table 4 – Example “Application Variables with qualifier”

Value

Qualifier

valid

0x1 (= good)

not valid

0x0 (= bad)

Checking the qualifier is done in the safety application.