## 4 Testing of the Solution
### Discussion and Comparison of the Performance Results  
Overall, testing activities can be regarded as satisfactory. The interoperability between different vendors, programming languages and operating systems was guaranteed after the first set of tests done by means of non-robot based machines. Additionally, communications at different layers were proven functional despite all the challenges that can be found in the application domain described by this manuscript. Finally, testing carried out by means of communications with the LabVIEW system conclude that the system can be ported with success to hardware environments like the ones to be expected in Autonomous Underwater Vehicles. These results will be further expanded when the middleware architecture is incorporated to the other robots that are going to be used in the project whenever new deployments are done in further testing activities. If this proposal is compared to other tested solutions already present, performance results are comparable with them. For example, [PERSON] et al. [49] mention that machines of 4 cores, 3.4 GHz and 8 GB of RAM were used to realize scaling for testing of their middleware solution. Their performance results show that delay remains low when the number of subscriptions gradually increases, which mirrors the capabilities of our systems, capable of handling 15 packets per second in a Publish/Subscribe connection with negligible delays. Additionally, [PERSON] et al. [50] deal with Elastic Publish subscribe systems that follow a performance modeling-based approach. According to the authors, they get average times for job executions that are in the range of seconds, which again is aligned with the results obtained in our proposal. However, if compared to other solutions that offer information about their performance, the middleware architecture that has been presented in this manuscript has been developed with underwater environments in mind where Publish/Subscribe systems have either not applied or have been done so to a lesser extent than the components and procedures that are described in this manuscript. Other proposals show similar performance results. For example, in the performance evaluation carried out for the proposal of Publish/Subscribe middleware done by [PERSON] et al. [51], it can be seen how the inclusion of a Publish/Subscribe middleware with an underlying IPv6 network for a multicast scenario results in just a small increase of the memory footprint (1.3%) and dynamic memory (4.7%) of the system, with a progressive increase in the use of bandwidth for a higher number of nodes (tests have been made with up to 20 nodes using unicast and multicast solutions). Furthermore, in the study made by [PERSON] et al. [52], it is shown how a Publish/Subscribe architecture oriented to the IoT shows an average delay in the order of seconds when messages are transmitted via IP network. Average loss rates  
Figure 13: Timespan values between receptions of Status Vector information. are kept between 0 and 6.41%. Finally, [PERSON] et al. study secure Publish/Subscribe protocols for Body Area Networks [53]. Execution of cyphered information is the most important feature treated in this latter scientific paper; setup, encryption and decryption activities increase the amount of time required when the number of attributes gets higher, and then stabilizes at 10-15 of them, but the time required for the execution is never higher than 5 s in the worst case scenario (decryption with 30 attributes). Overall, even though they show the same kind of performance, the proposal described here has more services and software components integrated in it, along with functionalities that are not present in the other ones. What is more, it has integrated both different kinds of vehicles and manufacturers (an AUV and a USV from different companies) as well as network communications that rely on very different kinds of technology to transfer the data.