## 2 Selected Features for a Mission Manager for Underwater Cooperative Robotics Operations
### Use of Self-Adaptive System Models
Concerning underwater cooperative robotics operations, the responses to when, what, why, and how can be answered as follows: whenever an unforeseen event happens preventing the achievement of a goal in a mission plan (when); whatever is possible, needed and has best chances to solve the situation (what); to still have chances of fulfilling the mission goals (why); and by any means available and suitable (how). The response to the \"who\" question, as we are talking about automated systems, is usually answered as the automated system. However, the response to the \"where\" question requires us to know a little more about how underwater interventions are typically managed. In traditional underwater interventions the mission plan was fully loaded into the AUVs to be launched, and once loaded, the AUVs were deployed on the sea surface where they remain waiting for the start command to start the mission [19; 20]. If we just follow this approach, the response to the \"where\" question is clearly that the component responsible to do the required changes must be the AUV. Although, in recent years there has been an improvement in the communications between the AUVs and the control stations where a global mission control can be running [21; 41], enabling other possible responses to the \"where\" question. For instance, the self-adaptation could be considered:  
* Only at the vehicle level. * Only at the global mission control level. * Both at the vehicle and the global mission control level, independently. * Both at the vehicle and the global mission control level, following a decentralized control pattern. The use of self-adaptation loops at different levels matches the MAPE-K proposal, where a hierarchy of autonomic managers is possible. Figure 4 illustrates an example of a two-level hierarchy. In the presented example there is one autonomic manager at the high level, and three autonomic managers at the low-level (keep in mind that there could be any number of levels and autonomic managers per level, as this is just an example). In this example each autonomic manager is able to perform self-adaptation using the MAPE-K loop individually. However, they could also be using a decentralized control pattern enabling the cooperation between managers at different levels [22]. A practical use case for this example could be a global mission manager using self-adaptation at  
Figure 3: Functional description of a MAPE-K autonomic manager implementing the MAPE-K loop. the high level, and a set of AUVs doing their own mission management with self-adaptation at the vehicle level. [PERSON] et al. [42] proposed a set of formal templates for the design of self-adaptive systems, and [PERSON] et al. [22] proposed a graphical notation for patterns of decentralized control for self-adaptive systems, both using MAPE-K as the core base. The patterns introduced by [PERSON] et al. imply the interaction between the functional components of the MAPE-K loop from different autonomic managers in a given hierarchy. The knowledge function in these patterns is considered apart, as each autonomic manager can use its own internal knowledge, and the hierarchical distribution can also provide additional shared knowledge repositories within the different layers, or even across them. The work of [PERSON] et al. also included the identification of five basic patterns:  
* Coordinated control: where the decision of how to adapt is made cooperatively among all the autonomic managers. * Information sharing: where each autonomic manager does the adaptation locally, but requires information from other autonomic managers to know how the locally performed adaptation will affect them. * Slave/master: where the monitor and execution functions are performed at one level (slave), and the analyze and plan functions are performed at another level (master). * Regional planning: where the hierarchical distribution is divided in autonomic regions.