The most basic type of communication is unidirectional communication, where a safety application on one device (Figure 29: Controller A) sends data to a safety application on another device (Figure 29: Controller B).
Figure 29 – 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 SafetyConsumer needs to know the parametrized set of IDs of the SafetyProvider such that it is 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 SafetyConsumers. Hence, Controller A can – one after another – serve an arbitrarily large number of SafetyConsumers, and new SafetyConsumers can be introduced into the system without having to update controller A.
Bidirectional communication means the 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 safety connections according to this document.
Figure 30 – 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 one SafetyConsumer on each of the Controllers B1, B2, … BN. Each of the SafetyProviders running on Controller A is connecting to one of the SafetyConsumers running on one of the Controllers B1, B2, … BN.
The safety protocol in this document 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 message-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 SafetyConsumers can be introduced into the system without having to reconfigure the SafetyProvider instances. As all SafetyProvider instances send the same safety application data (the 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.