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