# Proposal of an Automated Mission Manager for Cooperative Autonomous Underwater Vehicles
## 4 Description of the Missions and Tasks Register and Reporter (MTRR)  
In a general sense, the MTRR is responsible for the mission execution and control at the middleware layer. From top-down, the MTRR receives the mission plan generated at the MMT, processes it and dispatches the tasks to the corresponding vehicles, storing the mission-related information in the SWARMs repositories. From bottom-up, the MTRR receives the reports from the vehicles participating in a mission, processes and stores them into the SWARMs repositories, and if required, notifies the MMT about events of interest. In a more detailed description, these are the functionalities defined for the MTRR:  
1. Mission information retrieval. The different parameters that are fixed at the MMT in the mission plan as a way to establish what kind of plan will be executed or what maritime vehicles should be involved are transferred to the MTRR. Those parameters are: coordinates of the area to be inspected or surveyed, stages of the plan to be executed (going to a specific point, having an autonomous vehicle executing a particular trajectory) or transferring back to the MMT data about the mission progress. 2. Mission status collection. The MTRR provides information to the high end of the system regarding what stages of the mission were completed. Depending on the actions to be carried out by the vehicles, high-level tasks such as \"_SURVEY_\" (used by the AUV to maneuver in a land mower pattern), \"_TRANSIT_\" (used to go to a coordinate) or \"_HOVER_\" (used by Autonomous Surface Vehicles to navigate the surface of an area to be surveyed in a circular pattern) will need to be sent. Missions are created following a sequential order for the tasks to be executed, so each of those  
Figure 4: Example of a mission for three autonomous underwater vehicles (AUVs) named NTNU, PORTO 1 and PORTO 2. In this figure \(GW\) refers to the low-level task _GOTO-WAYPOINT_, and \(FR\), refers to the low-level task _FOLLOW_ROW_. tasks will be sent to the vehicles through the MTRR, which will notify when they are completed. Also, the MTRR is in charge of sending the \"_ABORT_\" signal to the vehicles when the mission has to be finished abruptly due to any major reason. 3. Information storage invocation. Data about how vehicles have progressed in a specific mission are retrieved via state vectors that contain, among other pieces of information, their location, speed, depth or altitude from the seabed, according to a data format specifically developed for the project [51]. The MTRR invokes the necessary operations that involve other software components in the middleware responsible for storing the data gathered. In this way, the MTRR makes the information available for all the other applications that require the data to perform their actions, such as the context awareness component (used to assess the level of danger in certain situations) or a plume simulator (which would simulate information about salinity concentration during a pollution leak event). As anticipated in Section 3.1, the MTRR is a software component with close interactions with other parts of the SWARMs architecture. Those that are most notorious are related to the MMT, but there are also other components that make use of the information retrieved to perform their own functionalities. While these other components are usually not directly involved in the execution of missions, they provide several functionalities to the overall middleware architecture and rely in a critical manner on the MTRR. These interactions have been further summarized in Table 1.  
A Unified Modeling Language (UML) perspective of these relations has been depicted in Figure 5. Note that each of the locations of the middleware components that interact with the MTRR has also been included as well so there is a better understanding on the application domain of their functionalities.