## 3 Description of the Solution
### Description of a Middleware for Underwater Environments
Besides, all communications related to command and control data from the swarm of vehicles, such as information that may affect the behavior of the swarm (e.g., battery level of a vehicle) or the planning of missions (e.g., status of an AUV, to determine whether it is occupied or not), must go through the middleware in order to build a shared common information space that enables interoperability and information exchanges between MMT and heterogeneous vehicles in a cost effective manner. This requirement must not prevent vehicles from communicating directly with each other, e.g., two vehicles could share an anti-collision plan (safety related plans), or even forward data from a destination to a source (play the role of a forwarder). The middleware may also support the MMT with useful semantic information for decision-making that should be obtained through semantic queries made to an ontology that has been created to gather and unify information. Contextual awareness is provided through the collection of useful information in order to understand the environment surrounding the available vehicles. Figure 4 represents in detail the functional components of SWARMs semantic middleware and its communication links. Note that, regardless of the vehicle type (tethered or untethered) and position (on surface or underwater), taking part in the communication will require different channels. An acoustic channel is used to transmit information to/from untethered vehicles (e.g., AUVs) when they are underwater and an IP channel (e.g., Wi-Fi) both when untethered vehicles are overwater (e.g., AUVs/USVs) and when tethered vehicles (e.g., ROVs) are the receivers or emitters of the communication. For the acoustic case, DDS communications should be translated to an acoustic format. This translation is accomplished by a _DDS-Acoustic Converter_, needed by both the middleware and each of the robots involved. So, there will be a direct communication between the Publish/Subscription Manager of the middleware and the DDS Proxy of the vehicle when using an IP channel, whereas the DDS-Acoustic Converter will act as an intermediary between both ends when using an acoustic channel. The rest of modules of the Semantic Middleware are explained as follows:  
Figure 3: Functional and physical components of the proposed middleware architecture and other related components of the SWARMs. 1. _Data management_: it is performed by means of a Data Access Manager, a Publish/Subscription Manager and two repositories, namely the SWARMs Ontology and a Relational Database for historical data: \(\circ\) By means of the _SWARMs Ontology_, the middleware defines a Common Information Model to unambiguously represent a swarm of vehicles. The SWARMs ontology consists of a set of sub-ontologies which provide descriptions of different domains of interests to model all information that is necessarily exchanged between any underwater vehicle and architecture component. This ontology is in charge of storing the information obtained from different domains (mission and planning, environment recognition and sensing, communication and networking and robotic vehicles). \(\circ\) A _Relational Database_ will store historical information related to past events, such as the different positions where a certain vehicle has been operating. Such a kind of information is not convenient to be represented in the ontology given that could be inefficient to access and query. This kind of data is stored in the database each time it has been updated in the ontology. \(\circ\) The _Data Access Manager_ provides an interface able to insert/retrieve information in the SWARMs ontology or in the relational database. Its functionalities will be invoked when new data are received and have to be included in the database (in case they are historical data that become characterized by its timestamps) or the latest piece of information is included in the SWARMs ontology.