## 2 Selected Features for a Mission Manager for Underwater Cooperative Robotics Operations
### The Use of Heterogenous Vehicles: Virtualization  
Cooperative underwater operations using multiple AUVs require their mission management capabilities to be taken into account by mission management architectures. A simplistic approach could be that participation in cooperative missions be limited to AUVs with homogeneous capabilities tightly represented within the mission management architecture. However, the increasing interest in the use of AUVs for underwater operations implies the also increasing availability of multiple AUVs with different capabilities. Mission management architectures that want to consider the possibility of using AUVs with heterogeneous capabilities may also rely on using a tightly representation of the AUVs mission management capabilities by restricting the heterogeneity. Another approach is to use a well-defined soft representation of a common mission management capability defined for the architecture, enabling the possibility of using legacy and new AUVs in cooperative missions. A virtual representation of a physical entity can be described as an abstraction mechanism that masks the specifics of such a physical entity, providing a common interface to access to its resources. The use of virtualization for abstracting the capabilities of heterogeneous devices has already been used in other domains. For instance, in [43], [PERSON] et al. described a model for the virtualization of event sources inspired by the IoT-A domain model [44]. This model, as partially illustrated in Figure 6, provides the access to the capabilities of a physical entity by the use of the services and resources exposed through its virtual representation as a virtual entity. With respect to virtualization, this domain model represents the most usual way for virtualizing physical entities, like AUVs. Figure 5: Diagram for the assignment of categories for the self-adaptation feature. \begin{table}
\begin{tabular}{c l} \hline \hline
**Category** & **Description** \\ \hline
**1** & Self-adaptation is not mentioned and has not been identified in the proposed architecture. \\
2 & Self-adaptation is only considered at the vehicles level. \\
3 & Self-adaptation is only considered at the global mission management level. \\
4 & Self-adaptation is considered both at the vehicles and the mission management levels, but \\  & done independently. \\
5 & Self-adaptation is considered both at the vehicles and the mission management levels, in a \\  & cooperative way using a decentralized control pattern. \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Self-adaptation assessment. From the global mission management point of view, the use of AUV virtualization may enable the chance to integrate both legacy and novel AUVs in a cooperative mission, dealing with their heterogeneity regarding their capabilities by using their virtual representations instead of a direct and tightly coupled one. The schema for the assignment of the categories that we have defined for the virtualization feature is shown in Figure 7. The first category is for architectures that do not mention the use of virtualization or abstraction methods in regards of mission management. The second category is for architectures that do not use virtualization or abstraction at all, relying on a tightly coupled integration of the vehicles within the mission. Architectures in this category can use both homogeneous and heterogeneous vehicles, requiring for the specific integration of the capabilities of each vehicle. The third category is for architectures that use virtualization just for homogeneous vehicles using a tightly coupled virtual representation. The fourth category is for architectures that use virtualization for heterogeneous vehicles with a tightly coupled virtual representation. And finally, the fifth category is for architectures that use virtualization for heterogeneous vehicles with a loosely coupled virtual representation.