## 4 Testing of the Solution
### Simulated AUV-CCS Performed Tests
#### 4.2.1. Vendor Compatibility, Platform and Language Independency Tests  
1. _Vendor compatibility:_ to carry out the tests, two different implementations of the OMG DDSI-RTPS interoperable wire-protocol were used: Vortex OpenSplice DDS Community Edition which is an open-source DDS solution offered by Prismtech [36], and _CoreDX DDS_ which is a proprietary implementation offered by Twin Oaks [37]. CoreDX was installed in the Publish/Subscription Manager of the Middleware, while OpenSplice DDS was set up in another piece of equipment to manage all DDS communications in the vehicle (i.e., the ROS-DDS Proxy and the two DDS/Acoustic Converters). CoreDX DDS and OpenSplice DDS were configured to share the same partition (e.g., \"swarms\").
2. _Programming Language compatibility:_ to guarantee programming language independency and the progress of developments regardless of the language used to write the software components, all the Middleware Core components were developed in Java, while the components created to be installed in the autonomous maritime vehicles were developed by means of C++.
3. _Platform compatibility:_ the Middleware Core components were installed in a Personal Computer using Windows 8 as the operating system, whereas all the components in the vehicle were installed on ROS and Linux-based hardware. The features of each of the devices have been summarized in Table 2. As it can be seen, neither the hardware requirements are not challenging, nor the middleware components demand a powerful hardware solution or hardware capabilities beyond what is common. Furthermore, the AUV simulated during the tests was done so via virtual machine, yet no problem appeared regarding this feature in terms of performance. This is a major advantage for the project, as autonomous maritime vehicles can be constrained in terms of power and the available energy in their batteries. Specifically, the latter one is meant to be used for their movement and mission tasks rather than for processing operations. Lastly, messages were sent in both directions at very short intervals (every second a new message was sent to the CCS, which is unlikely that will happen in a real world scenario at this high frequency), thus proving that there were no problems regarding latency or data losses.
4. _Results:_ the following compatibility tests were successfully performed: * The CoreDX DDS publisher in Java (Windows/Linux) publishes a message in the topic \"tasks\" and the OpenSplice DDS subscriber in C++ (Linux) receives and reads message. * The OpenSplice DDS publisher in C++ (Linux) publishes a message in the topic \"status\" and the CoreDX DDS subscriber in Java (Windows/Linux) receives and reads message.  
The results that were appreciated in those tests were of critical importance, due to the fact that they add an extra flexibility to the implementation works that are being carried out by the partners involved in the project. Due to their own background and know-how, it might be more useful for them  
\begin{table}
\begin{tabular}{c l} \hline \hline  & **Equipment Features** \\ \hline Simulated Autonomous & Random Access Memory: 2 Gigabytes. \\ Underwater Vehicle & Hard Disk Drive: 20 Gigabytes. \\  & Operating system: Ubuntu 14.04 LTS running on \\  & VMware Player 4.0.6. \\  & Middleware components size: less than 2 Megabytes. \\ \hline Simulated Command and & Random Access Memory: 8 Gigabytes. \\ Control Station & Hard Disk Drive: 1 Terabyte. \\  & Operating system: Windows 8. \\  & Middleware components size: less than 4 Megabytes. \\ \hline \hline \end{tabular}
\end{table}
Table 2: Hardware features of the pieces of equipment used.  
to codify by using either C++ or Java, but since both versions are compatible, these preferences do not suppose a significant challenge.