# Proposal of an Automated Mission Manager for Cooperative Autonomous Underwater Vehicles
## 4 Description of the Missions and Tasks Register and Reporter (MTRR)
### Activities Performed by the MTRR
#### 4.2.1 Starting a Mission  
Figure 9 shows the functional overview of the start of a mission within the SWARMs architecture. From the MTRR point of view, the start of a mission begins when it receives a new mission plan from the MMT (step 1). After verifying that the plan is valid and parsing it into the corresponding vehicle plans, the MTRR stores the information in the SWARMs repository (both historic data at the relational database and semantic data at the ontology) through the Semantic Query component (step 2). Then the MTRR publishes the mission plan to the DDS through the Publish/Subscription Manager component (step 3), and it is finally delivered to the vehicles (step 4). Internally, when the MTRR receives a new mission from the MMT, it performs the following actions in the given order. 1. Validation of the mission plan. 2. Storage of the reference coordinates into the semantic repository (that is, the ontology via Fuseki server). 3. Storage of the mission plan into the semantic repository. 4. Parsing the vehicles assigned to the mission plan. 5. Storage of assigned vehicles into the semantic repository. 6. Subscription to vehicles events. 7. Parsing the actions assigned to each vehicle in the mission plan. 8. Publication of the first assigned action for each vehicle in the SWARMs DDS partition. Figure 8: Overview of the vehicle virtualization used at the MTRR. The validation of the mission plan (activity 1) is just the sequence of verifications depicted in Figure 10. In essence, the validation just checks if there is no other active mission, if the mission is not empty, if it has a plan, and finally if it has assigned vehicles. If the validation is passed, then the corresponding new mission ID is stored in the P/S Manager. Once the validation result has been positive, the MTRR stores the relevant information in the ontology using the methods provided by the Semantic Query component (activities 2 and 3). Afterwards, the MTRR checks if the vehicles statuses have been updated, and if not, it requests them for an update. Usually this request has been made previously by the MMT, just before making a new plan and through the proper MTRR service created for that. After the MTRR confirms that the vehicles statuses are updated, it subscribes itself to the events from them (activity 6). This part of the _startMission_ method is depicted in Figure 11.  
Finally, the MTRR assigns the actions in the plan to each vehicle (activities 7 and 8). Each vehicle is able to perform high-level actions (if they have an onboard planner) or low-level actions (if they do not have an onboard planner), and the MTRR is responsible for sending them the adequate action list according to their capabilities. This is supported by a _MissionParser_ as part of the MTRR component. Also the assignment of the plan to each vehicle can be done in two ways:  
1. Sending the full plan to each vehicle. 2. Sending just the first action in the plan to each vehicle. Subsequent actions will be sent from the _TaskReport_ whenever requested by the vehicle. The second style of assignment was added to the _startMission_ in the MTRR as requested by some vehicle providers in the SWARMs project. Figures 12 and 13 show the diagrams for both ways of assignment, respectively. Finally, the MTRR assigns the actions in the plan to each vehicle (activities 7 and 8). Each vehicle is able to perform high-level actions (if they have an onboard planner) or low-level actions (if they do not have an onboard planner), and the MTRR is responsible for sending them the adequate action list according to their capabilities. This is supported by a _MissionParser_ as part of the MTRR component. Also the assignment of the plan to each vehicle can be done in two ways:  
Figure 9: Functional overview of the start of a mission. Figure 11: Flow diagram for mission data extraction and storage done at the MTRR. The full sequence diagram is detailed in Figure 14.  
Figure 12: Flow diagram for the task assignment when done by wait for completion.