**5.3 Experimental results**

14 Underwater Vehicles

ALI Action

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

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

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

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

> Replan

Repair

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

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

0.0 0.2 0.4 0.6 0.8 1.0

Command Query

Acknowledgment

Status Monitor

Status

layer making the system generic and platform independent.

Time (ms)

UUVs support and provide solutions for mine-hunting and neutralisation.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # Problem

Proximity (*PP*0.5) of the replan and repair approaches to the original plan.

(ALI).

**5.2 Simulation results**

plans introduced in Section 4.

Mission Executive

Event

Planner Functional

Mission

Notification

Domain Capabilities

Knowledge Base

Repair

Replan

0.0 0.2 0.4 0.6 0.8 1.0

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 manufacturer's *Remote Control* protocol (REM, 2008).

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 regions.

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 in the area of operations.

• *Is this platform configuration suitable to successfully perform this mission?*

The Path Towards Permanent Presence of Underwater Networks

capabilities to the platform is represented in Eq. 2.

of the mission (see Eq. 4).

experiment were1:

**5.3.2 In mission adaptation**

following question:

inherited from JAUS (SAE, 2006)

In order to answer this question, new knowledge could be inferred from the initial Core Ontology orientation. The Core Ontology rule engine was executed providing with additional knowledge. A set of predefined rules helped orienting the knowledge base into inferring new relationships between instances. An example of a rule dealing with the transfer of payload

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

*core* : *isCapabilityO f*(?*Capability*, ?*Payload*)∧ *core* : *isPayloadO f*(?*Payload*, ?*Platf orm*) → *core* : *isCapabilityO f*(?*Capability*, ?*Platf orm*)

Once all the possible knowledge was extracted, it was possible to query the knowledge base in order to extract the list of capabilities of the platform (see Eq. 3) and the list of requirements

*SELECT ?Platform ?Cap WHERE* { *rdf:type( ?Platform, core:Platform)* ∧

*SELECT ?Mission ?Req WHERE* { *plan:hasAction( ?Mission, ?Action)* ∧

This way, it was possible to autonomously extract that the requirements of the mission of the

which were a subset of the platform capabilities. Therefore, for this particular case, the

For these experiments, SAMP was given a static location in which to take control of the host vehicle. At this point, the mission planner agent generated a mission plan based on the knowledge available and the mission requirements. The instantiation of this mission plan is described in Fig. 13 using Planning Application Ontology concepts. The mission was then

While the mission was executed the status monitor agent maintained the knowledge base updated (in the OODA-loop sense) by reporting changes in the status of hardware components, such as batteries and sensors, and external parameters, such as water currents. When observations indicated that some of these changes were affecting the mission under execution, the mission planner was activated in order to adapt the mission to the changes. This indication was detected by the planner agent by querying the knowledge base with the

<sup>1</sup> RSTA-I i.e., Reconnaissance/Surveillance/Target Acquisition & Identification capability concepts

*• core:ComputerAidedClassification\_Capability* ∈ *jaus:Autonomous\_RSTA-I\_Capability • core:ComputerAidedDetection\_Capability* ∈ *jaus:Autonomous\_RSTA-I\_Capability*

*• core:WaypointManeuver\_Capability* ∈ *jaus:Maneuver\_Capability*

platform configuration suited the mission requirements.

*• core:SidescanSensor\_Capability* ∈ *jaus:Environmental\_Sensing\_Capability*

passed to the executive agent that took control of the vehicle for its execution.

*core:hasCapability(?Platform,?Cap)* } (3)

*plan:hasRequirement( ?Action,?Req )* } (4)

(2)

Fig. 12. Core Ontology instances for the demonstration scenario. The diagram represents the main platform, its components and their capabilities.

Fig. 13. Plan Application Ontology concepts representing the mission planning actions and their execution parameters and relationships.

On the payload side, the SAMP system was oriented (in the OODA-loop sense) using *a priori* information about the environment and the platform and a declarative description of the goals of the mission. The *a priori* knowledge and the platform configuration capabilities was represented using Core Ontology concepts (see Fig. 12). Knowledge about the environment was provided based on automatic computer-aided seabed classification information generated from previous existent data (Reed et al., 2006). The two classified seabed areas are shown in Fig. 11. The declarative description of the mission requirements was represented using concepts from the Planning Application Ontology. They could be resumed as 'survey all known areas maximizing efficiency'.

#### **5.3.1 Pre-mission reasoning**

Please note that the previously described separation between Core knowledge and Planning knowledge gracefully aligns with the separation between platform engineers and mission scientists on current UUV operations. If the platform capabilities were described in Core Ontology terms by the engineers that manufactured the platform, it can be seen how, by using the SAMP approach, a scientific operator that only cares about the data should be able to describe the mission to the platform without knowing anything about the custom properties of the platform. It is, therefore, important to assist the operator in knowing if the platform capabilities can match the mission requirements before starting the mission:

16 Underwater Vehicles

Fig. 12. Core Ontology instances for the demonstration scenario. The diagram represents the

Fig. 13. Plan Application Ontology concepts representing the mission planning actions and

On the payload side, the SAMP system was oriented (in the OODA-loop sense) using *a priori* information about the environment and the platform and a declarative description of the goals of the mission. The *a priori* knowledge and the platform configuration capabilities was represented using Core Ontology concepts (see Fig. 12). Knowledge about the environment was provided based on automatic computer-aided seabed classification information generated from previous existent data (Reed et al., 2006). The two classified seabed areas are shown in Fig. 11. The declarative description of the mission requirements was represented using concepts from the Planning Application Ontology. They could be resumed

Please note that the previously described separation between Core knowledge and Planning knowledge gracefully aligns with the separation between platform engineers and mission scientists on current UUV operations. If the platform capabilities were described in Core Ontology terms by the engineers that manufactured the platform, it can be seen how, by using the SAMP approach, a scientific operator that only cares about the data should be able to describe the mission to the platform without knowing anything about the custom properties of the platform. It is, therefore, important to assist the operator in knowing if the platform

capabilities can match the mission requirements before starting the mission:

main platform, its components and their capabilities.

their execution parameters and relationships.

as 'survey all known areas maximizing efficiency'.

**5.3.1 Pre-mission reasoning**

• *Is this platform configuration suitable to successfully perform this mission?*

In order to answer this question, new knowledge could be inferred from the initial Core Ontology orientation. The Core Ontology rule engine was executed providing with additional knowledge. A set of predefined rules helped orienting the knowledge base into inferring new relationships between instances. An example of a rule dealing with the transfer of payload capabilities to the platform is represented in Eq. 2.

> *core* : *isCapabilityO f*(?*Capability*, ?*Payload*)∧ *core* : *isPayloadO f*(?*Payload*, ?*Platf orm*) → *core* : *isCapabilityO f*(?*Capability*, ?*Platf orm*) (2)

Once all the possible knowledge was extracted, it was possible to query the knowledge base in order to extract the list of capabilities of the platform (see Eq. 3) and the list of requirements of the mission (see Eq. 4).

> *SELECT ?Platform ?Cap WHERE* { *rdf:type( ?Platform, core:Platform)* ∧ *core:hasCapability(?Platform,?Cap)* } (3)

$$\text{SELECT ??Mision ?eq WHERE } \{ \text{ plan:} \text{has} \text{Action}(\text{ ?Mission, ?Ation}) \land \\ \text{plan:} \text{has} \text{Requiredment}(\text{ ?Aaction, ?Req}) \}$$

This way, it was possible to autonomously extract that the requirements of the mission of the experiment were1:


which were a subset of the platform capabilities. Therefore, for this particular case, the platform configuration suited the mission requirements.
