**3.1 Semantic knowledge-based framework**

A library of knowledge bases comprise the overall knowledge framework used in our approach for building *SAV* (Miguelanez et al., 2010; Patrón, Miguelanez, Cartwright & Petillot, 2008). Reasoning capabilities allow concept consistency providing reassurance that *SAV* remains stable through the evolution of the mission. Also, inference of concepts and relationships allows new knowledge to be extracted or derived from the observed data. In order to provide with a design that supported maximum reusability (Gruber, 1995; van Heijst et al., 1996), we adopt a three-level segmentation structure that includes the (1) Foundation, (2) Core and (3) Application ontology levels (see Fig. 5).

standard was originally developed for the Unmanned Ground Vehicles (UGVs) environment only but has recently been extended to all other environments, such as air and water, trying to provide a common set of architecture elements and concepts. The JAUS model classifies four different sets of Knowledge Stores: Status, World map, Library and Log. Our experience has shown that overlap exists between these different sets of knowledge stores. The approach proposed in this paper provides more flexibility in the way the information can be accessed and stored, while still providing JAUS 'Message Interoperability' (SAE, 2008b) between

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

Within the proposed framework, JAUS concepts are considered as the Foundation Ontology for the knowledge representation. The Core Ontology developed in this work extends these concepts while remaining focused in the domain of unmanned systems. Some of the

Additionally, the Standard Ontology for Ubiquitous and Pervasive Applications (SOUPA) (Chen et al., 2004) is used as an Utility Ontology. By providing generic context-aware concepts, it enables the spatio-temporal representation of concepts in the

Each service-oriented agent has its own Application Ontology. It represents the agent's awareness of the situation by including concepts that are specific to the expertise of the agent. In the case study presented in this chapter, these agents are the status monitor and the mission planner. Together, they provide the *status monitor* and *mission adapter* components described in Fig. 3 required for closing the OODA-loop and provide on-board decision making adaptation.

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

• Symptom: individuals related to interesting patterns of observations (e.g., low gain levels,

• Data: all internal and external variables (gain levels, water current speed),

• Observation: patterns of data (sequences, outliers, residuals,...),

knowledge concepts identified related with this domain are:

The Path Towards Permanent Presence of Underwater Networks

• Agent: Software with specific capabilities,

**3.3.1 Status Monitoring Application Ontology**

• Platform: Static or mobile (ground, air, underwater vehicles),

• Payload: Hardware with particular properties, sensors or modules,

• Sensor: A device that receives and responds to a signal or stimulus, • Driver: Module for interaction with a specific sensor / actuator,

agents.

Core Ontology.

**3.3 Application Ontology**

status monitoring are:

high average speed),

Fig. 5. Levels of generality of the library of knowledge bases for *SAV*. They include the Foundation Ontology, the Core Ontology, and the Application Ontology levels.

Foundational Ontologies (FOs) represents the very basic principles and includes Upper and Utility Ontologies. Upper ontologies describe generic concepts (e.g., the Suggested Upper Merged Ontology or SUMO (Niles & Pease, 2001)) while Utility ontologies describe support concepts or properties (e.g. OGC\_GML for describing geospatial information (Portele, 2007)). FOs meet the requirement that a model should have as much generality as possible, to ensure reusability across different domains.

The Core Ontology provides a global and extensible model into which data originating from distinct sources can be mapped and integrated. This layer provides a single knowledge base for cross-domain agents and services (e.g., vehicle resource / capabilities discovery, vehicle physical breakdown, and vehicle status). A single model avoids the inevitable combinatorial explosion and application complexities that results from pair-wise mappings between individual metadata formats and ontologies.

In the bottom layer, an Application Ontology provides an underlying formal model for agents that integrate source data and perform a variety of extended functions. As such, higher levels of complexity are tolerable and the design is motivated more by completeness and logical correctness than human comprehension. Target areas of these Application Ontologies are found in the status monitoring of the vehicle and its environment and the planning of the mission.

Figure 6 represents the relationship between the Foundation Ontologies (Upper and Utility), the Core Ontology and the Application Ontology for each service-oriented agent. Raw data gets parsed from sensors into assertions during the mission using a series of adapter modules for each of the sensing capabilities. It also shows that the knowledge handling by the agent during its decision making process is helped by the reasoner and the rule engine process.

Fig. 6. *SAV* representation in the Knowledge Base using Core and Application ontologies supported by Upper and Utility ontologies. Generation of instances from raw data is performed by the Adapter. Handling of knowledge is done by the Reasoner, Rule Engine and the Service-Oriented Agent.

#### **3.2 Foundation and core ontology**

To lay the foundation for the knowledge representation of unmanned vehicles, consideration was placed on the Joint Architecture for Unmanned Systems (JAUS) (SAE, 2008a). This standard was originally developed for the Unmanned Ground Vehicles (UGVs) environment only but has recently been extended to all other environments, such as air and water, trying to provide a common set of architecture elements and concepts. The JAUS model classifies four different sets of Knowledge Stores: Status, World map, Library and Log. Our experience has shown that overlap exists between these different sets of knowledge stores. The approach proposed in this paper provides more flexibility in the way the information can be accessed and stored, while still providing JAUS 'Message Interoperability' (SAE, 2008b) between agents.

Within the proposed framework, JAUS concepts are considered as the Foundation Ontology for the knowledge representation. The Core Ontology developed in this work extends these concepts while remaining focused in the domain of unmanned systems. Some of the knowledge concepts identified related with this domain are:


Additionally, the Standard Ontology for Ubiquitous and Pervasive Applications (SOUPA) (Chen et al., 2004) is used as an Utility Ontology. By providing generic context-aware concepts, it enables the spatio-temporal representation of concepts in the Core Ontology.
