**3.3.1 Status Monitoring Application Ontology**

The Status Monitoring Application Ontology is used to express the *SAV* of the status monitor agent. To model the behaviour of all components and subsystems considering from sensor data to possible model outputs, the Status Monitoring Application Ontology is designed and built based on ontology design patterns (Blomqvist & Sandkuhl, 2005). Ontology patterns facilitate the construction of the ontology and promote re-use and consistency if it is applied to different environments. In this work, the representation of the monitoring concepts are based on a system observation design pattern. Some of the most important concepts identified for status monitoring are:






 

**4.2 Mission plan adaptation agent**

Π*<sup>q</sup>* =

planning.

Σ*q*, Ω*<sup>q</sup>*   

The Path Towards Permanent Presence of Underwater Networks


processes using partial plan representation of the mission plans.

πq−<sup>1</sup>

<sup>ψ</sup>0Π<sup>0</sup> <sup>Π</sup>q−<sup>1</sup> <sup>Π</sup><sup>q</sup> <sup>Π</sup>q−<sup>1</sup>

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

Fig. 7. Schematic representation of the autonomous mission generation, replan and repair

This section describes the mission environment model used by the mission plan repair techniques presented in this chapter. We continue using the mission environment model previously described. We generalise this model to any step *q* in the mission execution timeline. An instance of an UUV mission environment at a given step *q* can be simply defined as

the available resources in the system *PV* and the set of actions or capabilities *AV*. The mission problem model Ω*<sup>q</sup>* contains the current platform state *xq* and the mission requirements *QO*. Based on this model, we analyse how to calculate mission plans on the plan space (Sacerdoti, 1975). A plan space is an implicit directed graph whose vertices are partially specified plans and whose edges correspond to refinement operations. In a real environment where optimality can be sacrificed by operability, partial plans are seen as a suitable representation

A partial plan *ψ* is a tuple containing a set of partially instantiated actions and a set of constraints over these partially grounded actions. Constraints can be of the form of ordering constraints, interval preservation constraints, point truth constraints and binding constraints. Ordering constraints indicate the ordering in which the actions should be executed. Interval preservation constraints link preconditions and effects over actions already ordered. Point truth constraints assure the existence of precondition facts at certain points of the plan. Binding constraints on the variables of actions are used to ground the actions to variables of the domain. Figure 8 shows a partial plan representation of an UUV mission. Partial plans are flexible to modification. They provide an open approach for handling extensions such as temporal and resource constraints. Due to nature of the constraints, it is easy to explain a partial plan to a user. Additionally, it is easily extensible to distributed multi-agent mission

Figure 7 explains the processes of mission plan repair and mission plan replan for mission plan adaptation for UUVs using a partial plan representation of the mission plans. At the initial step, a partial ordered plan *ψ*<sup>0</sup> is generated satisfying the original mission environment Π0. The *ψ*<sup>0</sup> is then grounded into the minimal mission plan *π*<sup>0</sup> including all constraints in *ψ*0. At step *q*, the semantic knowledge-based framework is updated by the diagnosis information Π˙ *<sup>q</sup>* providing a modified awareness of the mission environment Π*q*. From here, two mission adaptation processes are possible: *Mission replan* generates a new partial plan *ψq*, as done at the first stage, based only on the knowledge of Π*q*. On the other hand, *mission plan repair* re-validates the original plan by ensuring minimal perturbation of it. Given the partial plan at the previous step *<sup>ψ</sup>q*−<sup>1</sup> and the diagnosis information <sup>Π</sup>˙ *<sup>q</sup>*, the mission repair problem produces a solution partial plan *ψ<sup>q</sup>* that satisfies the updated mission problem Π*q*, by modifying *ψq*−1. The final step for both approaches is to ground *ψ<sup>q</sup>* to its minimal mission plan

because they are a flexible constrained-based structure capable of being adapted.

 

<sup>ψ</sup>q−<sup>1</sup> <sup>ψ</sup><sup>q</sup> <sup>ψ</sup>q−<sup>1</sup> <sup>ψ</sup><sup>q</sup>

Π˙ <sup>q</sup> Π˙ <sup>q</sup> <sup>q</sup> <sup>−</sup> <sup>1</sup> q <sup>q</sup> <sup>−</sup> <sup>1</sup> q


π<sup>0</sup> π<sup>q</sup> π<sup>q</sup>


. The mission domain model Σ*<sup>q</sup>* contains the set of propositions defining

πq−<sup>1</sup>

Π<sup>q</sup>



Please note how some of these concepts are related to concepts of the Core Ontology (e.g. an *observation* comes from a *sensor*). These Core Ontology elements are the enablers for the knowledge exchange between service-oriented agents. This will be shown in the demonstration scenario of Section 5.3.
