## 3 Description of the Selected Proposals
### SWARMs Architecture
Regarding the mission planning and management, the mission plan in SWARMs was generated by a deterministic automated planning algorithm executed from the MMT. The mission plan, specified  
Figure 16: SWARMs middleware architecture. in an ad-hoc format, consists of a sequence of actions, each one assigned to its corresponding vehicle, allowing for a multi-agent specification. Also, from the point of view of mission planning, the vehicles in SWARMs can be classified in two categories: those able to plan by themselves how to achieve a goal, and those that require to be provided with the specific primitive for the action. Therefore, the mission plan also includes a hierarchical decomposition of the plan, so the MTRR can decide to dispatch to the vehicles either a high-level mission plan or a low-level one depending on their capabilities. The MTRR is in essence responsible for the mission management within the SWARMs middleware architecture, and it has been validated during the SWARMs final trials [71]. Figure 17 illustrates the relations between the MTRR and other SWARMs components. As explained before, the MTRR receives the mission plan generated at the MMT. Using a tightly coupled virtualization, the MTRR parses the mission plan, and divides it into vehicle plans, using either the high-level actions or the low-level ones depending on the capabilities of the assigned vehicles. The MTRR is capable of dispatching the full plan to the vehicles, or doing it task by task. Indeed, within the SWARMs project, the dispatching was done task by task due to the restrictions of the on-board system loaded into the vehicles. To avoid problems with the latency between the ending of an action, and the dispatching of the next one in the vehicle plan, a pre-buffering technique was used, where the next action to the current one was also dispatched to the vehicles. Figure 17: Relations between the mission manager (MTRR) and other SWARMs components. The MTRR was also responsible for handling the status, events, and environmental reports received from the vehicles. Whenever an event prevented the execution of part of a plan, the MTRR notified the MMT so a human operator could decide whether to abort the mission or re-plan it with the new information sent by the vehicles. Regarding the assessment of the features considered in this survey, the mission plan specification in the SWARMs architecture is done using an ad-hoc format that includes capabilities for multi-agent plans and uses a hierarchical task representation. It also includes temporal estimations for the tasks durations, but they are not provided as temporal constraints. Consequently, we have assigned it a category 2 MH for the plan specification feature. With respect to the use of adaptation, each vehicle integrated in SWARMs is capable of performing certain degree of adaptation during the execution of a mission plan. At the same time the mission manager can abort a vehicle plan at any time, and re-plan just its part of the mission plan, following a decentralized hierarchical control pattern for vehicle plan adaptation. Therefore, we have assigned it a category 4 for the adaptation feature. The MTRR uses internally a virtualization of the vehicle capabilities with regards to their onboard planning capabilities. This use of the virtualization paradigm is done using a tightly coupled design, where the specific capabilities of the vehicles are modeled into their internal virtual representation. For that reason, we have assigned it a category 4 for the virtualization feature. Finally, the MTRR can dispatch the mission plan either by sending it a task-by-task to the vehicles, or sending them the full mission. Hence, we have assigned it a category 4 for the dispatching feature. A summary of the categorization for the measured features is included in Table 9.