**5.3.2 In mission adaptation**

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 passed to the executive agent that took control of the vehicle for its execution.

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 following question:

<sup>1</sup> RSTA-I i.e., Reconnaissance/Surveillance/Target Acquisition & Identification capability concepts inherited from JAUS (SAE, 2006)

a)

The Path Towards Permanent Presence of Underwater Networks

b)

c)

d)

e)

action from the plan.

(m) during the mission, all plotted against mission time (s).

at the moment of initialising the survey of the areas.

memory usage, network activity and disk usage.

Fig. 15. Vehicle telemetry (top to bottom): a) vehicle velocity (m/s), b) compass heading (degrees), c) altitude (m), d) depth (m) and e) reconstructed profile of the seabed bathymetry

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

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

*plan:hasExecParam( ?Action,?Param)* ∧ *plan:hasStatus( ?Param, ?Status)* }

An incipient *Status* of the action parameters indicates that the action can still be performed by adapting the way it is being executed, an execution repair. If both transducers were down, a critical status of the sidescan sensor is diagnosed and a plan repair adaptation of the mission plan would have been required instead. In that case, the adaptive mission planner would have looked for redundant components or similar capabilities to perform the action or to drop the

The same procedure was used after the transducer recovery was reported to adapt the survey action to the normal pattern during the second lawn mower survey. In a similar process, SAMP adapted the lawnmower pattern survey of the areas to the detected water current *Status*

The timeline of the mission executed using the SAMP approach is described in the following figures: Figure 14 represents the final trajectory of the vehicle in 2D and 3D using a North-East coordinate frame projection with the origin at the starting point of the mission. Figure 15 displays the vehicle's telemetry recorded during the mission. It includes vehicle's velocity, compass heading, altitude, depth measurements and processed bathymetry over time. Figure 16 shows subset of the variables being monitored by the status monitor agent that were relevant to this experiment. These variables include direction of water current, remaining battery power, the availability of the transducers in the sidescan sensor and the mission execution status. Figure 17 represents the system activity of the payload computer recorded during the mission. The system activity logs show percentage of processor usage,

(7)

Fig. 14. Left: Vehicle's track during mission in a North-East coordinate frame projection with the origin at the starting point of the mission. Right: Three-dimensional display of the vehicle's track during the mission (Note that depth coordinates are not to scale).

• *Are the observations coming from the environment affecting the mission currently under execution?*

In order to explain the reasoning process involved during the event detection, diagnosis and response phases of the mission adaptation process, a component fault as an internal event was temporarily simulated in the host vehicle. The fault simulated the gains of the starboard transducer of the sidescan sonar dropping to their minimum levels half way through the lawn mower survey of the first area.

For the detection phase, the low gain signals from the transducer triggered a symptom instance, which had an associated event level. This event level, represented in the Status Monitoring Application Ontology using a value partition pattern, plays a key role in the classification of the instances in the *Event* concept between being critical or incipient. This classification is represented axiomatically in the Eqs. 5 and 6.

$$\begin{array}{l}\text{status:} \text{CriticalEvent} \ \sqsubseteq \text{status:} \text{Event} \sqcap \text{status:} \text{causeedBySympatom} \dots \\\text{(status:} \text{Sympatom} \sqcap \text{status:} \text{hasEventLevel} \dots \\\text{(status:} \text{Level} \sqcap \text{status:} \text{High})\end{array} \tag{5}$$

status:IncipientEvent ... status:Event status:causedBySymptom . . . (status:Symptom status:hasEventLevel . . . (status:Level status:Med)) (6)

After the *Event* individuals were re-classified, the *Status* property of the related component in the Core Ontology was updated.

During the diagnosis event phase, a critical status of a component is only considered to be caused by a critical event. Therefore, due to the fact that the sidescan sonar component is composed of two transducers, port and starboard, one malfunctioned transducer was only diagnosed as an incipient *Status* of the overall sidescan sonar component.

During the response phase, the *Status* property of the Core Ontology components were used by the mission planner to perform the plan diagnosis of the mission under execution. The query to the knowledge base shown in Eq. 7 reported that the two survey actions in the mission plan were affected by the incipient status of the sidescan sonar.

18 Underwater Vehicles

East (m) East North

Fig. 14. Left: Vehicle's track during mission in a North-East coordinate frame projection with the origin at the starting point of the mission. Right: Three-dimensional display of the vehicle's track during the mission (Note that depth coordinates are not to scale).

• *Are the observations coming from the environment affecting the mission currently under execution?* In order to explain the reasoning process involved during the event detection, diagnosis and response phases of the mission adaptation process, a component fault as an internal event was temporarily simulated in the host vehicle. The fault simulated the gains of the starboard transducer of the sidescan sonar dropping to their minimum levels half way through the lawn

For the detection phase, the low gain signals from the transducer triggered a symptom instance, which had an associated event level. This event level, represented in the Status Monitoring Application Ontology using a value partition pattern, plays a key role in the classification of the instances in the *Event* concept between being critical or incipient. This

status:CriticalEvent status:Event status:causedBySymptom . . .

status:Event status:causedBySymptom . . . (status:Symptom status:hasEventLevel . . .

After the *Event* individuals were re-classified, the *Status* property of the related component in

During the diagnosis event phase, a critical status of a component is only considered to be caused by a critical event. Therefore, due to the fact that the sidescan sonar component is composed of two transducers, port and starboard, one malfunctioned transducer was only

During the response phase, the *Status* property of the Core Ontology components were used by the mission planner to perform the plan diagnosis of the mission under execution. The query to the knowledge base shown in Eq. 7 reported that the two survey actions in the

North East

(5)

(6)

Depth

Depth

100 50 0 50 100 150 200

classification is represented axiomatically in the Eqs. 5 and 6.

(status:Level status:High))

(status:Symptom status:hasEventLevel . . .

status:IncipientEvent ...

(status:Level status:Med))

diagnosed as an incipient *Status* of the overall sidescan sonar component.

mission plan were affected by the incipient status of the sidescan sonar.

East (m)

mower survey of the first area.

the Core Ontology was updated.

North (m) North (m)

Fig. 15. Vehicle telemetry (top to bottom): a) vehicle velocity (m/s), b) compass heading (degrees), c) altitude (m), d) depth (m) and e) reconstructed profile of the seabed bathymetry (m) during the mission, all plotted against mission time (s).

*SELECT ?Mission ?Action ?Param ?Status WHERE* { *plan:hasAction( ?Mission, ?Action)* ∧ *plan:hasExecParam( ?Action,?Param)* ∧ *plan:hasStatus( ?Param, ?Status)* } (7)

An incipient *Status* of the action parameters indicates that the action can still be performed by adapting the way it is being executed, an execution repair. If both transducers were down, a critical status of the sidescan sensor is diagnosed and a plan repair adaptation of the mission plan would have been required instead. In that case, the adaptive mission planner would have looked for redundant components or similar capabilities to perform the action or to drop the action from the plan.

The same procedure was used after the transducer recovery was reported to adapt the survey action to the normal pattern during the second lawn mower survey. In a similar process, SAMP adapted the lawnmower pattern survey of the areas to the detected water current *Status* at the moment of initialising the survey of the areas.

The timeline of the mission executed using the SAMP approach is described in the following figures: Figure 14 represents the final trajectory of the vehicle in 2D and 3D using a North-East coordinate frame projection with the origin at the starting point of the mission. Figure 15 displays the vehicle's telemetry recorded during the mission. It includes vehicle's velocity, compass heading, altitude, depth measurements and processed bathymetry over time. Figure 16 shows subset of the variables being monitored by the status monitor agent that were relevant to this experiment. These variables include direction of water current, remaining battery power, the availability of the transducers in the sidescan sensor and the mission execution status. Figure 17 represents the system activity of the payload computer recorded during the mission. The system activity logs show percentage of processor usage, memory usage, network activity and disk usage.

Also, a peak on the CPU usage can be noted as this is the point where the mission partial plan

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

Symbol represents the point where the vehicle arrives to perform the survey of the area. At this point, the action survey gets instantiated based on the properties of the internal elements and external factors. Although the Loch waters where the trials were performed were very still (see Figure 16.b), note how the vehicle heading during the lawnmower pattern performed to survey the areas follows the water current direction sensed at the arrival (approx. 12*o*, Symbol - Figure 16.a) in order to minimize drag and maximise battery efficiency. The heading of the vehicle during the survey can be observed in Figure 14 and Figure 15.b. The link between the vehicle heading in relation to the water current direction and its effect on the battery consumption was expert orientation knowledge captured by a relationship property between

Symbol ♦ represents the point when the status monitor agent detects and reports a critical status in the starboard transducer of the sidescan sonar (Figure 16.d). It can be seen how the lawnmower pattern was adapted to cope with the change and to use the port transducer to cover the odd and even spacing of the survey. This pattern avoids gaps in the sidescan data under the degraded component configuration and maximises sensor coverage for the survey

Symbol � indicates the point where the starboard transducer recovery is diagnosed. It can be observed how the commands executing the action are modified in order to optimise the survey pattern and minimise distance travelled. Although also being monitored, the power status does not report any critical status during the mission that requires modification of the

Symbol � shows the location where all the mission goals are considered achieved and the control is given back to the mission control of the host vehicle (see Symbol � - Figure 16.e shows the mission is still active but the payload is not longer in control (0x01) ). From this point the host vehicle's control module takes the control back and drives the vehicle to the

The underwater domain is a challenging environment in which to maintain the operability of an UUV. Operability can be improved with the embedded adaptation of the mission plan. We implement a system capable of adapting mission plans autonomously in the face of events while during a mission. We do this by using a combination of ontological hierarchical representation of knowledge and adaptive mission plan repair techniques. The advantage of this approach is that it maximises robustness, system performance and response time. The system performance has been demonstrated in simulation. Additionally, the mission

• *Knowledge based framework:* We have presented a semantic-based framework that provides the core architecture for knowledge representation for service oriented agents in UUVs. The framework combines the initial expert orientation and the observations acquired during mission in order to improve the situation awareness in the vehicle. This is currently

• *Goal-oriented plan vs. waypoint-based plan:* The system uses a goal-oriented approach in which the mission is described in terms of 'what to do' instead of a 'how to do' it. The

adaptation capability is shown during an in-water field trial demonstration.

In our fully integrated experiments we achieved the following:

gets generated (Figure 17.a).

The Path Towards Permanent Presence of Underwater Networks

the two concepts in the Core Ontology.

while the transducer is down.

loiter at the recovery location.

unavailable in UUVs.

**6. Conclusion and future work**

actions (Figure 16.c).

Fig. 16. Status monitoring (top to bottom): a) direction of water current (degrees), b) speed of water current (m/s), c) battery power (Wh), d) sidescan sensor port and e) starboard transducers availability (on/off) and f) mission status binary flag, all plotted against mission time (s).

Fig. 17. System activity (top to bottom): a) % processor usage, b) % memory usage, c) network activity (packets/s) and d) disk usage (I/O sectors/s), all plotted against mission time (s).

Each of the symbols �, , ♦, � and � on the aforementioned figures represents a point during the mission where an event occurred. Symbol � represents the point where SAMP takes control of the vehicle. Note a change on the host platform mission status binary flag that becomes 0x05, i.e. the mission is active (0x01) and the payload is in control (0x04) (Figure 16.e). 20 Underwater Vehicles

0 500 1000 1500 2000

0 500 1000 1500 2000

Fig. 16. Status monitoring (top to bottom): a) direction of water current (degrees), b) speed of

transducers availability (on/off) and f) mission status binary flag, all plotted against mission

0 500 1000 1500 2000

Fig. 17. System activity (top to bottom): a) % processor usage, b) % memory usage, c) network activity (packets/s) and d) disk usage (I/O sectors/s), all plotted against mission

Each of the symbols �, , ♦, � and � on the aforementioned figures represents a point during the mission where an event occurred. Symbol � represents the point where SAMP takes control of the vehicle. Note a change on the host platform mission status binary flag that becomes 0x05, i.e. the mission is active (0x01) and the payload is in control (0x04) (Figure 16.e).

water current (m/s), c) battery power (Wh), d) sidescan sensor port and e) starboard

a)

b)

c)

d)

e)

f)

a)

b)

c)

d)

time (s).

time (s).

0.0 0.4 0.8

Also, a peak on the CPU usage can be noted as this is the point where the mission partial plan gets generated (Figure 17.a).

Symbol represents the point where the vehicle arrives to perform the survey of the area. At this point, the action survey gets instantiated based on the properties of the internal elements and external factors. Although the Loch waters where the trials were performed were very still (see Figure 16.b), note how the vehicle heading during the lawnmower pattern performed to survey the areas follows the water current direction sensed at the arrival (approx. 12*o*, Symbol - Figure 16.a) in order to minimize drag and maximise battery efficiency. The heading of the vehicle during the survey can be observed in Figure 14 and Figure 15.b. The link between the vehicle heading in relation to the water current direction and its effect on the battery consumption was expert orientation knowledge captured by a relationship property between the two concepts in the Core Ontology.

Symbol ♦ represents the point when the status monitor agent detects and reports a critical status in the starboard transducer of the sidescan sonar (Figure 16.d). It can be seen how the lawnmower pattern was adapted to cope with the change and to use the port transducer to cover the odd and even spacing of the survey. This pattern avoids gaps in the sidescan data under the degraded component configuration and maximises sensor coverage for the survey while the transducer is down.

Symbol � indicates the point where the starboard transducer recovery is diagnosed. It can be observed how the commands executing the action are modified in order to optimise the survey pattern and minimise distance travelled. Although also being monitored, the power status does not report any critical status during the mission that requires modification of the actions (Figure 16.c).

Symbol � shows the location where all the mission goals are considered achieved and the control is given back to the mission control of the host vehicle (see Symbol � - Figure 16.e shows the mission is still active but the payload is not longer in control (0x01) ). From this point the host vehicle's control module takes the control back and drives the vehicle to the loiter at the recovery location.
