## 3 Description of the Solution
### Description of a Middleware for Underwater Environments
The modules in charge of this responsibility are the Tasks Reporter, the Event Reporter and the Environment Reporter: * The Tasks Reporter tracks and reports the status of different tasks of a mission. Typically, it will send information to the Mission Tasks Register and Reporter of what has been received from the Publish/Subscribe Manager depending on the request that was executed previously (features of the autonomous vehicle such as battery level, GPS coordinates, etc.). * The Event Reporter collects events (task status, alarms, detections, etc.) coming from the vehicles. When they are sent to the higher levels (namely, Mission Management Tool, which is behaving as the application layer of the system) they are displayed for the human operator of the system. * The Environment Reporter tracks and periodically reports any environmental data relevant for the mission, to which the MMT has subscribed. As it was done in previous cases, the report will be sent towards the MMT. All these modules implement a simplistic behavior, collecting and storing specific information in the ontology and informing the MMT later. However, the responsibility to analyze such information and act accordingly is relegated to the MMT. * _Cross Layer Services_: these are services available both to the components belonging to the High Level Layer and the Low Level Layer of the middleware. The modules offering cross layer services to the rest of the modules of the middleware are the Semantic Reasoner, the Data Pre-Processor, the Security module, and finally the QoS module: * The _Semantic Reasoner_ is responsible for inferring a higher level of processing or context awareness on the context information stored in the SWARMs ontology. The semantic reasoner processes the gathered context information, and in case semantic rules have been defined, it filters the output previously obtained to achieve all the possible allowable options to support the middleware towards decision making. * The _Data Pre-Processor_ allows the middleware to validate data coming from vehicles to ensure that this information is clean and its format is correct, accordingly to the data formats defined and expected, e.g., a temperature must be a numeric value. This module will use the historical data stored in the relational database in order to avoid uncertainties. * The _Security_ module covers different kind of security schemes, i.e., data integrity, authentication, authorization, and access identity management. A Public Key Infrastructure (PKI) will be implemented to provide entity and message authentication, and message integrity in overwater communications, while a symmetric key based message signing scheme will provide authentication and integrity in underwater communications. * QoS policies specified by the MMT will be implemented in the designed middleware by means of the QoS features built-in by the DDS protocol. If the available services present in the architecture are compared to the ones present in the reviewed literature, it can be checked that the semantic middleware architecture put forward in this manuscript has more services than the ones that have been reviewed before. Some of the proposals contain semantic capabilities, hardware abstraction components, security or access for the application layer, but only the one presented as part of the SWARMs project has all the attributes required to perform the functionalities that have been defined as mandatory for semantic middleware architectures in this kind of environment. Figure 4: Middleware architecture used in SWARMs.