## 3 Description of the Solution
### DDS, DCPS and RTPS  
Data Distribution Service (DDS) is the first open international standard addressing Publish/Subscribe middleware architectures for real-time systems. Developed by the Object Management Group (OMG), this standard is focused on connectivity on the data level that acts as the middleware layer in a distributed system [32]. Unlike Client/Server or Message Oriented Middleware (MOM), which is more oriented to processes or messages, DDS is of data-centric nature. Thus, by prioritizing the information contained in the data, it provides a more efficient transmission of contextual information. It is assumed that this approach allows, (i) the inclusion of contextual information, and (ii) enables developers to codify how and where to share data instead of the code required to send messages. Although the IoT is repeatedly mentioned as one of the main areas of interest for the development and application of DDS there are no limits, except for the constrains that may be found in actual deployments, to implement DDS-based works in any other distributed or Cyber-Physical System. It is assumed that DDS is capable of offering a scalable architecture that guarantees high reliability and low latency for data connectivity. While all these features are welcoming under any circumstance, they make DDS more attractive for the application domain of this manuscript, where the challenges imposed by the transmission medium as far as bit and higher levels are concerned make any improvement to reduce latency or make real-time communications desirable. A central idea of DDS is the existence of topics, or data structures that settle the fields and appearance of the information that is transferred from one location to another. Data publishing is done through a topic that is encased in a DDS domain. This domain is separated from other domains and does not share information with them either. In order to exchange information, data-objects contained in topics are utilized, since a topic becomes defined by its name and the data-object is done so by means of key attributes. In addition, data writers that publish content and data readers subscribed to it can filter the information sent and received by time and content. The overall appearance of a DDS deployment, as well as its location in the layered infrastructure that results from applying it to the underwater environment, has been depicted in Figure 2.  
In addition to topics, the idea of a global data space is also of major importance, since it implies writing and storing information remotely but gives to the writer the impression that the process is done locally. Interactions with that global data space seem to be done via the Application Programming Interface (API) offered by DDS. However, they actually imply DDS messages being sent to update the involved software infrastructure (stores, remote nodes, etc.). At the same time, the applications store locally what they need just for the required timespan. The global data space is described by the authors of DDS to share data between heterogeneous systems, e.g., cloud applications, embedded and mobile systems, and with low latency. Another important feature of DDS is the availability of Quality of Service (QoS). QoS specifications include reliability, security or system health. Reliability might also be implemented if required. Dynamic discovery of publishers and subscribers is another feature to be taken into account, as automatic discovery of those makes the underlying hardware easy to include in any deployment. DDS scalable architecture is described as \"designed to be scalable from small devices to the cloud and  
Figure 2: Location of middleware in the system and its DDS components. for very large systems\" [32]. This approach guarantees that devices of very different features can be integrated in a distributed or Cyber-Physical System. Remote Procedure Calls (RPCs), security and web integration are also central functionalities in this context.