## 3 Description of the Selected Proposals
### RAUVI Architecture and the Mission Control System (MCS)  
The Reconfigurable AUV for Intervention missions (RAUVI) [54] was a research project aimed to the development of a new reconfigurable AUV capable of performing underwater operations using a robotic arm [55]. A distributed architecture was proposed [56] and validated through simulations and experiments in controlled scenarios [57]. The proposed architecture was designed to combine two pre-existing architectures with a mission control system (MCS), as shown in Figure 11. These two architectures are the manipulation and the vehicle architectures respectively. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Feature** & **Category** & **Explanation** \\ \hline Plan Specification & 2 MHT & The reviewed literature for T-REX does not provide any insights of how the plan is specified, thus it seems reasonable to assume that the plan specification is done using an ad-hoc format. \\  & & The use of different reactors as agents capable of receiving goals and generating plans seems compatible to a multi-agent \\  & & approach. It also means that the mission plan, seem from the top, \\  & & can be considered as a hierarchical plan, since a plan from a \\  & & reactor can be seen as the lower-level plan for the goals provided \\  & & by another reactor. \\ \hline Adaptation & 5 & As T-REX is based in sense-plan-act, it uses self-adaptation by \\  & & default. The partitioning of the control loops in the executive is \\  & & done using a coordinated pattern. \\ \hline
**Virtualization** & 1 & There is no mention to virtualization or abstraction. \\ \hline Dispatching & 3 & The dispatcher sends the goals to the corresponding reactors one \\  & & by one. It is important to notice that in this case the description \\  & & of the algorithm implies that there is no real supervision made \\  & & from the upper reactor, and that the dispatching of a new goal is \\  & & just ruled by its planned starting time. \\ \hline \hline \end{tabular}
\end{table} 
Table 6: T-REX assessment. The manipulation architecture is aimed to control the robotic arm in the AUV, and consists mainly of two modules: perception and action. On the other hand, the vehicle architecture is in charge of ensuring the functionality of the AUV, and includes three main modules: robot interface, perception and control. The third piece in the proposed distributed architecture is de aforementioned MCS, in charge of defining the task execution flow to fulfill a mission. A detailed functional diagram of the proposed architecture is shown in Figure 12. Four main functional blocks are shown in the diagram. At top sits the MCS, with the Architecture Abstraction Layer. At the bottom, we can find the manipulator architecture on the left, and the vehicle architecture on the right. Finally, in the middle, there is a centralized blackboard used as a communication interface between the manipulator and the vehicle architectures. The mission plan in the RAUVI architecture must be provided by the mission programmer using a graphical user interface to generate a mission file expressed in XML using a mission control language (MCL) [58; 59]. The generated file is then parsed by a MCL compiler that generates a Petri net mission file. The MCS receives this Petri net file, and executes it through the abstraction layer, where every task has the exact same interface, and is dispatched to either the manipulator or the vehicle architecture. The manipulator architecture receives the tasks through the action layer. This module can receive two types of actions: control and perceptual. The control actions are fed to the robot abstraction layer,  
Figure 11: An overview of the RAUVI software architecture. Figure 12: RAUVI proposed architecture. where they are executed by the manipulator robot itself. On the other hand, the perceptual actions are feed to the perception layer, updating the robot internal perception.