# TalkRoBots: A Middleware for Robotic Systems in Industry 4.0 +
## 6 Experimentation
### Experimentation Results  
In our demonstration, the scenario includes five robots, one sensor and nine tasks. The results in Figure 16 show that 284 messages have been exchanged during the experimentation. Moreover, considering the theoretical analysis in Equation (12) and the considered scenario, one can estimate an upper and lower bound of the number messages according to the possible faulty behavior and the involved actors (robots, sensors, etc.). In fact, in the best case (251 messages from Equation (12)), there is no faulty behavior, the sensor request is locale and all tasks are performed by the same actor and sent using the ROS or direct modes. In the worst case (297 messages from Equation (12)), the sensor request is externale: One robot will have faulty behavior (since we only have one spare here) and all tasks are sequentially performed by different actors and sent field by field. In every case, we consider that the sensor sends an update every seconds and that the total duration of the scenario is about three minutes. Therefore, the results are still coherent with the analytical study. In our scenario, the data field is almost always empty except in the forward messages and the acknowledgments sent to the Cloud. Therefore, we only have seven messages with a significant size superior to 32 bytes (an acknowledgment is about 52 bytes). Actually, the first forward message has an initial size of 769 bytes since it must transmit the eight tasks left to the second actor. The experimental results show that 15.1 kbytes has been exchanged in approximately 3 min, producing a bandwidth of 83 B.s\({}^{-1}\), which is very low in the industrial context. This shows that the overhead induced by TalkRoBots is very limited. Figure 16: Number of messages exchanged during a scenario. Another parameter that has been evaluated concerns the impact of the security mechanism on the transmission's delay. Before presenting the results for this indicator, let us show that the security involves two processes: a signature and a send/receive TLS encrypted tunnel. Contrary to the signature, TLS encryption is only performed once on the communication channel when it is created. Thus, this operation is not performed again every time a message has to be sent. Thus, to evaluate the impact of security, we measure the transmission delay between sending and receiving a message when we have to sign it on an encrypted canal and when it is not signed. As shown in Figure 17, adding a signature and using encrypted communications only slightly increases the delay between the time a message is sent and when it is received. To produce these results, we start measuring time before signing a serialized message; then, we send it. We stopped measuring only when the message has been received and validated (signature matched). All exchanged messages had a size of 32 or 48 bytes (depending on data type). The analysis of this figure shows that processing a non-signed message takes at least 0.8 ms and a signed one takes no more than 1.4 ms. Thus, the maximum observed delay is 0.6 ms. This could be largely accepted compared to all benefits of such security mechanisms. Note here that this delay is obtained by using cheap embedded computers and, thus, can be significantly reduced by using more powerful ones. Finally, some experimentation has been confirmed in order to study the impact of the transmission mode on transmission delay, while including the security mechanism. The delay between receiving an external message by the middleware and forwarding it to the robot may change according to the message transmission mode. As we can see in Figure 18, this delay is more important when we transmit field by field in the interpreter mode, as previously stated. Indeed, in order to send multiple fields using TCP and to prevent some fields being concatenated into the same buffer, we add a slight delay between each sent field.