## 3 Description of the Selected Proposals
### SWARMs Architecture  
The primary goal of the SWARMs project [66] is to expand the use of underwater and surface vehicles (AUVs, ROVs, USVs) to facilitate the conception, planning and execution of maritime and offshore operations and missions. As part of this project a semantic middleware architecture has been defined, implemented [67], and validated with simulations and real scenarios [68; 69; 70]. Figure 16 shows a detailed functional description of the components that constitute the aforementioned architecture. The SWARMs middleware components are distributed in four main groups:  
* Data management: The components in this group are related to the management of the information handled in the middleware. They are: \[\bigcirc\] Two repositories, one for historical data and the other for the SWARMs ontology \[\bigcirc\] A data access manager for managing the access to the repositories \[\bigcirc\] A publish/subscription manager for providing access to the Data Distribution Service (DDS) based communications used in the project. * High level services: The components in this group are essentially those components accessible from the application layer, and specifically within the SWARMs project, from the application known as the mission management tool (MMT). They are: \[\bigcirc\] The missions and tasks register and reporter (MTRR), that receives the mission plan from the mission management tool and is in charge of the mission management from within the middleware. \[\bigcirc\] The vehicle and service register, that provides information about the available vehicles and services. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Feature** & **Category** & **Explanation** \\ \hline \multirow{4}{*}{
\begin{tabular}{c} Plan \\ Specification \\ \end{tabular} } & \multirow{4}{*}{2 MH} & From the architectural overview it is clear that the mission specification is provided as a hierarchical set of goals used to generate agent plans that are in essence a sequence of commands without following or proposing a formal description, and thus using an ad-hoc one. As the agent plans can be assigned to different agents, we consider that ICA provides a multi-agent view. & ICA includes an OODA loop approach for the situation awareness performed by an AUV agent. \\ \cline{1-1} \cline{2-3}  & \multirow{2}{*}{1} & There is no mention to virtualization or abstraction of the agents in the ICA proposal. & ICA proposal. \\ \cline{1-1} \cline{2-3}  & & Although the internal structure of an ICA agent includes a component named “Mission Spoeler” that feeds the “Service Matchmaker” with the agent plans, there is no mention to how this agent plans are really dispatched to the AUV agents. \\ \hline \hline \end{tabular}
\end{table} 
Table 8: ICA assessment. The semantic query, which processes the semantic queries made by the MMT. The rules and policies creator, that allows the insertion of rules and policies by users. Low level services: The components in this group represent the interface between the middleware and the vehicles, and they are:  
The tasks reporter, which tracks and reports the status of the tasks in a mission. The event reporter, which collects the events that occur during a mission. The environment reporter, that tracks and periodically reports collected environmental data relevant for the mission. Cross layer services: The components in this group provide services for all the other components in the middleware, and they are:  
The semantic reasoner, responsible for processing higher level inferences and context awareness from the context information available in the SWARMs ontology. The data pre-processor, that validates the data gathered from the vehicles. The security component, responsible for providing a number of security schemes, like data integrity, authentication, authorization and access identity management. The quality of service component, responsible for enabling the quality of service policies specified by the MMT.