## 4 Testing of the Solution
### Testing Activities during the SWARMs Demonstrator  
The proposal for middleware architecture that has been described and tested in laboratory-based environments was finally tried on vehicles and facilities during the first demonstrator made possible in the framework of the SWARMs project during July 2017. Among the different tests carried out during the demonstrator, the integration between the semantic middleware architecture and the communications established at the network layer were made with actual pieces of equipment, which were as follows:  
1. An AUV provided by ECA Robotics called A9 [44] used to receive information from the activities that it was carrying out. Figure 11: Round Trip Time for data deliveries. Figure 10: LabVIEW packet publication, as represented by Wireshark. 2. Two acoustic modems provided by Evologics GmbH [45] utilized to communicate the A9 with a USV by means of underwater acoustic waves. 3. A USV tailored for the demonstrator by Leonardo Defence Systems [46] employed to convert and transfer the information received from the acoustic network to the wireless, Over-The-Air one installed by TTI Norte SL [47]. 4. A laptop where the semantic middleware components were up and running. Among those components, the most prominent one for the scope of the manuscript is the Publish/Subscribe Manager, used to send commands to the A9 dealing with the information it was capable of providing. In the procedures that were undertaken, it was tested how information from a State Vector request could be obtained from the AUV and sent back to the laptop running the P/S Manager. By State Vector request, it is meant a request for information formatted as a message that contains the following relevant data:  
1. An identifier of the vehicle used to receive information (in this case, the A9 from ECA). 2. A timestamp to show when messages were delivered. Additionally, this piece of information is also useful to know how long it took for a message to be received after a previous one was delivered. 3. GPS coordinates. They are useful to determine univocally the position of the AUV. 4. Depth. It determines how deep the AUV is diving. 5. Altitude. It determines the vertical distance between the AUV and the seabed of the area where it is diving. 6. Speed. It is used to determine how fast the vehicle is moving through the sea. 7. Yaw, pitch and roll angles. Those parameters are used to know the manoeuvers being carried out by the vehicle under the water. 8. Battery level. It is used to know how much energy the AUV has at its disposal. As far as the length of the information included is concerned, it was formatted as a Protocol Data Unit of the protocol that has been described at [48], so it was guaranteed that the PDU would not be too long and would be challenging to be handled by the acoustic network used to transfer data at a level below the semantic middleware solution. Specifically, the length of the fields that were contained was as follows:  
1. The type of message that was sent was included in the lower 4 bits of the byte that was used to encase both the vehicle identifier and this piece of information. 2. The subtype of message (since there are many different kinds of reports that can be sent to the C & CS where the P/S Manager is running, a subtype is required to determine the kind of information that is being sent). 3. The eight pieces of data previously described. The scenario that was created has been summarized in Figure 12. As it has been explained previously, all the elements involved in a holistic deployment for testing activities have been included: (a) the acoustic and wireless networks used to communicate all the hardware and software elements at the network layer; (b) the CDT and VDT used for data formatting between the networking components and the semantic middleware solution; and (c) the hardware devices used by the system (namely, the AUV, the USV and the C & CS where the Publish/Subscribe Manager is running).