**5.1 Architecture**

The combination of the status monitor agent, the adaptive mission planner, the mission executive and the semantic knowledge-based framework is termed as the Semantic-based Adaptive Mission Planning system (SAMP). The SAMP system implements the four stages of the OODA-loop. Figure 9 represents the customised version of Figure 3 for SAMP.

The status monitor agent reports to the knowledge base the different changes occurring in the environment and the modifications of the internal status of the platform. The knowledge base stores the ontology-based knowledge containing the expert orientation provided *a priori* and the observations reported by the status monitor. A mission planner agent generates and

repair approaches (light grey bars). Note that a logarithmic scale is used for the time values. Figure 10 right displays the Plan Proximity to the original plan of the replan strategy result versus the repair strategy result. It can be seen that plans adapted using the mission repair strategy tend to be closer to the original plan than using the mission replan strategy. In these results, 14 out of 15 scenarios were computed faster by using mission plan repair. This computation was on average 9.1*x* times faster. Also, 14 out of 15 scenarios showed that mission plan repair had greater or equal Plan Proximity values as compared to mission replan. In general, our mission repair approach improves performance and time response while at the same time finds a solution that is closer to the original mission plan available

<sup>213</sup> Embedded Knowledge and Autonomous Planning:

This section shows the performance of the SAMP system inside the real MCM application using a REMUS 100 UUV platform (see Fig. 11.left) in a set of integrated in-water field trial demonstration days at Loch Earn, Scotland (56*o*23.1N,4*o*12.0W). The REMUS UUV had a resident guest PC/104 1.4GHz payload computer where the SAMP system was installed. SAMP was capable of communicating with the vehicle's control and status modules and taking control of it by using an interface module that translated the ALI protocol into the

area 1

area 2

Fig. 11. Left: REMUS UUV deployment before starting one of its missions. Right: Procedural mission uploaded to the vehicle control module and *a priori* seabed classification information stored in the knowledge base. The two dark grey areas correspond to the classified seabed

Figure 11.right shows the procedural waypoint-based mission as it was described to the vehicle's control module. This was known as the baseline mission. It was only used to start the vehicle's control module with a mission in the area of operation before taking control of it using the SAMP system. The baseline mission plan consisted on a start waypoint and two waypoints describing a North to South mission leg at an approximate constant Longitude (4*o*16.2W). This leg was approximately 250 meters long and it was followed by a loiter pattern at the recovery location. The track obtained after executing this baseline mission using the vehicle control module is shown in Fig. 11 with a dark line. A small adjustment of the vehicle's location can be observed on the top trajectory after the aided navigation module corrects its solution to the fixes received from the Long Baseline (LBL) transponders previously deployed

before adaptation.

regions.

in the area of operations.

**5.3 Experimental results**

manufacturer's *Remote Control* protocol (REM, 2008).

The Path Towards Permanent Presence of Underwater Networks

Fig. 9. Architecture of the SAMP system. The embedded agents are the planner, executive, monitor, and knowledge base. These agents interconnect via set of messages. The system integrates to the functional layer of a generic host platform by an abstract layer interface (ALI).

adapts mission plans based on the situation awareness stored in the knowledge base. The mission executive agent executes mission commands in the functional layer based on the sequence of ground actions received from the mission planner. An Abstract Layer Interface (ALI) based on JAUS-like messages (SAE, 2008a) over UDP/IP packages implemented using the OceanSHELL protocol (Oce, 2005) provides independence from the platform's functional layer making the system generic and platform independent.

#### **5.2 Simulation results**

A set of synthetic simulated scenarios have been implemented to test the performance of the SAMP system. The tests are based on the mine counter measure (MCM) operation, where UUVs support and provide solutions for mine-hunting and neutralisation.

A set of 15 selected MCM scenarios were simulated covering the variability of missions described by the concepts of operations for unmanned underwater vehicles presented in the UUV (2004) and the JRP (2005). For each scenario, the detection of a failure in one of the components of the system was simulated. The mission plan was adapted to the new constraints using replanning methods and the mission plan repair approach based on partial plans introduced in Section 4.

Fig. 10. Left: A semi-log plot displaying the computational time in miliseconds for replan (dark grey bars) and repair approaches (light grey bars). Right: Comparison of Plan Proximity (*PP*0.5) of the replan and repair approaches to the original plan.

The performance of the two approaches was compared by looking at the computation time and the Plan Proximity (Patrón & Birch, 2009) of the adaptive mission plan provided to the original reference mission plan. Figure 10 left shows the computation time in milliseconds required for adapting the mission to the new constraints for replan (dark grey bars) and repair approaches (light grey bars). Note that a logarithmic scale is used for the time values. Figure 10 right displays the Plan Proximity to the original plan of the replan strategy result versus the repair strategy result. It can be seen that plans adapted using the mission repair strategy tend to be closer to the original plan than using the mission replan strategy. In these results, 14 out of 15 scenarios were computed faster by using mission plan repair. This computation was on average 9.1*x* times faster. Also, 14 out of 15 scenarios showed that mission plan repair had greater or equal Plan Proximity values as compared to mission replan. In general, our mission repair approach improves performance and time response while at the same time finds a solution that is closer to the original mission plan available before adaptation.
