Robotic Ontology and Modelling - 3rd version...ARPEGE PROGRAM 2009 EDITION ANR-09-SEGI-010 ROBOTIC ONTOLOGY AND MODELLING - 3RD VERSION Revision Date Author Modification Draft 1 12/11/09

ARPEGE PROGRAM

2009 EDITION

ANR-09-SEGI-010 ROBOTIC ONTOLOGY AND

MODELLING - 3RD VERSION

Platform for RObotic Modelling and Transformation for End-

Users and Scientific communities

Robotic Ontology and Modelling - 3rdversion

Intellectual Property Rights are governed by PROTEUS Contract and PROTEUS consortium agreements. Before using, reproducing, modifying or disclosing the information contained in that document, it is under the user responsibility to check its rights and if mandatory ask to the Intellectual Property Owner the authorisation to use, reproduce, modify or disclose the information

Les droits de propriété intellectuelle de ce document sont décrits par le contrat PROTEUS et l'accord de coopération s'y rattachant. Il est de la responsabilité de l'utilisateur de vérifier ses droits avant d'utiliser, de reproduire, de modifier ou de divulguer les informations contenus dans ce document. Si cela est nécessaire, il est obligatoire que l'utilisateur demande aux propriétaires l'autorisation afin de pouvoir utiliser, reproduire, modifier ou divulguer lesdites informations.

ARPEGE PROGRAM

2009 EDITION



Title: PROTEUS - Robotic Ontology and Modelling - 3rdversion

PROTEUS reference: R1.1.4.3

Date : 23/03/2012

Partner in charge: Onera

Author: Jean-Loup Farges

WP: 1

Sub-WP:

Task: 1

Status: Delivered

Issue: 14

Dissemination level: RE

File name: R1.1.4.3-RoboticOntology_and_Modelling_3rdVersion.odm

Dassault Aviation ref.


R1.1.4.3 - Robotic Ontology andModelling - 3rd version

Delivered 14

23/03/2012

Page 2 of 83

ARPEGE PROGRAM

2009 EDITION



Revision Date Author Modification

Draft 1 12/11/09 Bruno Patin Creation.

Draft 2 09/03/10 Bruno Patin Update.

Draft 3 17/09/10 Bruno Patin Update.

Draft 4 30/03/11 Jean-Loup Farges Definition of namespace prefix at beginning of chapter 3.

Draft 5 13/12/11 Jean-Loup Farges Suppression of the double DEVS inclusion. Paragraphs for rules and explanation of warnings.

Draft 6 18/12/11 Bruno Patin Almost final review

Draft 7 23/12/11 Jean-Loup Farges Finalization of the robot section.

Draft 8 and 9 28/12/11 Bruno Patin Introduction of correct schematics and consolidation

Approved 10 02/01/12 Bruno Patin Draft to approved following finalisation and conclusion redaction

Approved 11 06/01/12 Jean-Loup Farges Section for systems extension.

Approved 12 13/01/12 Jean-Loup Farges Sub-sections of on-line access to ontologies

Approved 13 15/01/12 Bruno Patin Renaming of external Mission.odt to SystemAndMission.odt

slight style sheet issue

Delivered 14 23/03/12 Jean-Loup Farges

Bruno Patin

Taking into account revision file.



Delivered 14

23/03/2012

Page 3 of 83

ARPEGE PROGRAM

2009 EDITION



TABLE OF CONTENTS

1. PURPOSE OF THIS DOCUMENT..............................................................................101.1.Tooling used to develop the ontology......................................................................121.2.Local version...........................................................................................................131.3.Online version.........................................................................................................14

1.3.1 Accessing the Proteus ontology through Protégé............................................................14

1.3.2 Exploring the description of the challenges provided through the Proteus Platform........14

2. GENERAL STRUCTURE.......................................................................................163.ONTOLOGY DETAILED DESCRIPTION.........................................................................18

3.1. The kernel module..................................................................................................213.1.1Composition of systems...................................................................................................21

3.1.2System boundaries........................................................................................................... 21

3.1.3System evolution............................................................................................................. 23

3.1.4 Abstract versus actual information..................................................................................24

3.1.5Description of the objects of the world / environment......................................................25

3.1.6 Some other classes......................................................................................................... 26

3.2. The information module.........................................................................................273.2.1 Atomic versus Composite nature of kern:data.................................................................27

3.2.2 Details of kern:Abstraction..............................................................................................28

3.3. The environment module.......................................................................................293.3.1 Introduction..................................................................................................................... 29

3.3.2 Different types of environment.......................................................................................30

3.3.3Surface............................................................................................................................. 32

3.3.4Agent capability and environment....................................................................................34

3.3.5Physics............................................................................................................................. 35

3.4. The system module................................................................................................363.4.1 Specialisation of system..................................................................................................36

3.4.2 Systems with hardware and drivers................................................................................37

3.4.3 Other specific hardware..................................................................................................38

3.4.4 Specific interactions........................................................................................................ 39

3.4.5 Specific software............................................................................................................. 39

3.5. The mission module...............................................................................................403.5.1 Composition of mission...................................................................................................40

3.5.2 Mission Planning and Execution......................................................................................44

3.5.3 Multi Agent Missions........................................................................................................46

3.6. The robot module...................................................................................................483.6.1 Classes............................................................................................................................ 48

3.6.2 Properties........................................................................................................................ 49



Delivered 14

23/03/2012

Page 4 of 83

ARPEGE PROGRAM

2009 EDITION



3.7. The simulation module...........................................................................................513.7.1“Simulator” concept......................................................................................................... 51

3.7.2Simulator software and parts...........................................................................................53

3.8. The Experiment Module..........................................................................................553.8.1Schematics....................................................................................................................... 55

3.8.2Definitions........................................................................................................................ 57

3.8.3Implementation................................................................................................................58

3.9.Rules.......................................................................................................................613.10.Explanation of warnings........................................................................................62

4. SYNTHESIS AND CONCLUSION..............................................................................645.ANNEXES.....................................................................................................67

5.1. Acronyms...............................................................................................................685.2. Class glossary.........................................................................................................695.3.Scenarios.................................................................................................................71

5.3.1 Urban scenario................................................................................................................72

5.3.2 Air-ground scenario......................................................................................................... 77



Delivered 14

23/03/2012

Page 5 of 83

ARPEGE PROGRAM

2009 EDITION



LIST OF TABLESTable 1: Informal definition of some other classes of kernel........................................26Table 2: definitions used to introduce some of the concepts.......................................51Table 3: definitions used to introduce some of the concepts.......................................58Table 4: Association between AutomataState and FSMActivity....................................75



Delivered 14

23/03/2012

Page 6 of 83

ARPEGE PROGRAM

2009 EDITION



LIST OF FIGURESFigure 1: tree organisation and content.......................................................................13Figure 2: ontologies stack.............................................................................................16Figure 3: links between the core parts of the ontology................................................17Figure 4: Components of an OWL ontology..................................................................18Figure 5: composition of system...................................................................................21Figure 6: system boundaries........................................................................................22Figure 7: Evolution of kern:system...............................................................................23Figure 8: Relationship between abstraction and actual implementation......................24Figure 9: objects of the world.......................................................................................25Figure 10: Algorithmic Module and Probe.....................................................................26Figure 11: How to compose information.......................................................................27Figure 12: details of kern:Abstraction concept.............................................................28Figure 13: kern:Environment concept as described in the kernel and environment parts of the ontology.............................................................................................................30Figure 14: Specific physical objects..............................................................................31Figure 15: The concept of Surface................................................................................32Figure 16: Relations between specific Physical Objects and specific Surface...............33Figure 17: Use of Surface to define movesOverGround capability...............................34Figure 18: Force and its specializations........................................................................35Figure 19: Functional view of systems..........................................................................36Figure 20: Highlighted functions...................................................................................37Figure 21: Robotic system............................................................................................38Figure 22: Some hardware and some drivers...............................................................38Figure 23: Specific interactions....................................................................................39Figure 24: Specific software.........................................................................................40Figure 25: Composition of Mission................................................................................42Figure 26: WorkFlow and MissionStateMachine............................................................43Figure 27: Objectives, constraints, plans and actions...................................................44Figure 28: Hierarchical Task Network...........................................................................45Figure 29: Different types of inter agent communications...........................................47Figure 30: robo:Robot is a kern:CompositeSystem and a kern:Agent...........................48Figure 31: robo:SurfaceVehicle and robo:GroundVehicle.............................................49



Delivered 14

23/03/2012

Page 7 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 32: The robo:pilots and robo:uses properties....................................................50Figure 33: simulation ontology.....................................................................................52Figure 34: different type of simulator...........................................................................53Figure 35: software and simulator................................................................................54Figure 36: Work flow.....................................................................................................55Figure 37: roles linked to a scenario.............................................................................56Figure 38: roles linked to problem................................................................................56Figure 39: roles linked to solutions...............................................................................57Figure 40: Roles involved in challenges........................................................................59Figure 41: Problem and solution...................................................................................60Figure 42: Target generation........................................................................................61Figure 43: Functional architecture of urban scenario...................................................72Figure 44: Sensors used for urban robot localisation....................................................73Figure 45: Sensors used for urban robot mapping and obstacle detection...................74Figure 46: Actuators managed by urban robot control.................................................74Figure 47: State machine for urban robot....................................................................74Figure 48: Highest level of abstraction for the air-ground scenario..............................77Figure 49: Instances of Agent.......................................................................................78Figure 50: Assignment of instances of Human to instances of Mission.........................78Figure 51: The instance GPSSensorOfR-Trooper1........................................................79Figure 52: The systems and architectures involved in the air-ground scenario............80Figure 53: Dynamic of the mission of an intruder.........................................................81Figure 54: Instances of Task.........................................................................................81Figure 55: Tasks for the missions of the army and the robots......................................82Figure 56: Implementation of tasks for intruders.........................................................82



Delivered 14

23/03/2012

Page 8 of 83

ARPEGE PROGRAM

2009 EDITION



1. PURPOSE OF THIS DOCUMENT

This document aims at:

• Presenting the third version of the ontology developed in the scope of the Proteus project.

• Demonstrating the relevance of this ontology by using it to describe the Proteus scenarios and the youth challenge.

It is the documentation of the Web Ontology Language (OWL) files developed in the scope of the PROTEUS project by:

• Nicolas du Lac from INTEMPORA,

• Jean-Loup Farges from Onera,

• Miniar Hemaissia-Jeannin from TRT,

• Juan Lahera-Perez from INRIA,

• Gaëlle Lortal from TRT,

• Stéphane Millet from Dassault Aviation,

• Bruno Patin from Dassault Aviation and

• Serge Stinckwich from GREYC.It is an open document (following CECILL B license) that is to be used from now on outside the PROTEUS scope. For the time being, the OWL version used is the first one. Rules are developed using the Semantic Web Rule Language (SWRL) that allows integration of rules and OWL.The intended audience of this document includes:

• Roboticians wishing to exchange information about robotic problems and robotic solutions through the PROTEUS platform. Indeed the language used by the platform to describe the simulations and the middleware configurations to be generated is derived from the ontology presented here.

• Developers of languages for the robotic domain. They could ground their languages over the ontology.

• Ontology developers. They could import all or a part of the ontology to define more specific concepts.

An important effort of the PROTEUS project has been devoted to the development of the ontology presented here. PROTEUS aims at facilitating transfer of knowledge of the mobile robotic domain from the academic world toward the industrial one and problems from the industrial world toward the academic one. The PROTEUS specification propose the following use case:



Delivered 14

23/03/2012

Page 10 of 83

http://www.w3.org/2004/OWL/

http://www.w3.org/Submission/SWRL/

ARPEGE PROGRAM

2009 EDITION



• A first user of the platform provides a problem to the platform,

• A second user gets the problem from the platform and designs a solution for this problem,

• The second user provides the solution to the platform,

• The first user gets the solution from the platform.This use case indicates that the second user has to understand the problem given by the first user and that the first user has to understand the solution given by the second user. Thus they have to share a common language; they have to agree to use a vocabulary in a way that is consistent with respect to a theory. Moreover, thanks to a computer science language consistent with the theory, artificial agents that commit to the theory can be designed for the purpose of simulation or test on the field of the solution developed by the second user. For those reasons the development of a theory grounding a vocabulary is required for the PROTEUS platform. Candidates formalisms for specifying this theory are Unified Modelling Language (UML) and ontologies. Ontologies compliant with description logics are known to offer greater support for automated reasoning and cleaner solutions for defining complex relationships than UML. Thus the theory associated to the PROTEUS vocabulary is specified through an ontology. Moreover, simplifying the ontology into UML structural diagrams is an approach for the development of a Domain Specific Language (DSL), that may facilitate the exchanges between users, the configuration of simulation and the projection on actual robots. In summary the ontology is:

• a way to formalize to vocabulary between different persons from different domains (computer programming, roboticians, physicians...) ,

• a way to indicate people how to submit a problem and restrict the work area of solution providers and

• a start base for the development of a DSL.Here after the tooling used is detailed as well as the two methods available to use the ontologies. There is a set of files down loadable from the project website and that allows their user to ignore any internet connection needs or almost (see “local version”). There is an online version that allows their user to download nothing at all (see “online version”).

Considering versioning, information are provided directly into ontologies themselves. The online version is often younger than the local version. Do take care as a user to verify that you are tackling with a version consistent with your needs and if questions are arising do contact those in charge ([email protected] or [email protected]).



Delivered 14

23/03/2012

Page 11 of 83

mailto:[email protected]

mailto:[email protected]

ARPEGE PROGRAM

2009 EDITION



1.1. TOOLING USED TO DEVELOP THE ONTOLOGY

The tool used throughout the project has been protégé developed at Stanford University in its 3.4.x flavour. The team in charge did not want to move to a new tool during the ontologies development in order to avoid delays due to tool knowledge updates. In this flavour, pprj files are used in order to allow protégé to store meta information necessary for the tool to locate the different dependencies. These files are obsoleted in the new protégé trunk.The existing ontology is verified through the different tools provided (e.g. pellet) meaning a complete consistency check (pellet module under reasoning index) and syntax (owl index).The different graphics issued in the following sections and coming from ontologies were created from the OntoViz plug-in of the protégé 3.4.4 version. From the produced files an adaptation was needed and run thanks to the GraphViz software suite.The following picture demonstrates the ontologies tree to be explained in the here after sections. It also explains what files to find in any of the folders.



Delivered 14

23/03/2012

Page 12 of 83

http://www.graphviz.org/

http://protegewiki.stanford.edu/wiki/OntoViz

http://clarkparsia.com/pellet/

http://protege.stanford.edu/

ARPEGE PROGRAM

2009 EDITION



1.2. LOCAL VERSION

Addresses to download the files are:

• http://www.anr-proteus.fr/sites/default/files/download/Ontology/R1.1.4.3-S11.17- ProteusCoreOntology.zip

• http://www.anr-proteus.fr/sites/default/files/download/Ontology/R1.1.4.3-S11.18- ProteusExtensionsOntology.zip

• http://www.anr-proteus.fr/sites/default/files/download/Ontology/R1.1.4.3-S11.19- ProteusScenarioOntology.zip

After uncompressing them, the tree structure should be like the one seen below.

Figure 1: tree organisation and content

Each of the folder should include a .pprj file that is able to load what it needs in the tree. If there are problems then the user has to reload the links using the corresponding utilities of the software used.



Delivered 14

23/03/2012

Page 13 of 83

http://www.anr-proteus.fr/sites/default/files/download/Ontology/R1.1.4.3-S11.19-ProteusScenarioOntology.zip

http://www.anr-proteus.fr/sites/default/files/download/Ontology/R1.1.4.3-S11.19-ProteusScenarioOntology.zip

http://www.anr-proteus.fr/sites/default/files/download/Ontology/R1.1.4.3-S11.18-ProteusExtensionsOntology.zip

http://www.anr-proteus.fr/sites/default/files/download/Ontology/R1.1.4.3-S11.18-ProteusExtensionsOntology.zip

http://www.anr-proteus.fr/sites/default/files/download/Ontology/R1.1.4.3-S11.17-ProteusCoreOntology.zip

http://www.anr-proteus.fr/sites/default/files/download/Ontology/R1.1.4.3-S11.17-ProteusCoreOntology.zip

ARPEGE PROGRAM

2009 EDITION



1.3. ONLINE VERSION

As it is, in order to be eventually referenced by other ontologies (e.g. LAAS robot knowledge representation), it is necessary to provide an ontology accessible through an online address and referencing each of its sub parts through the same methodology. Tools, such as protégé in either versions, are able to use such URI and present to their users the referenced ontologies. Addresses can be found in annex.

1.3.1 ACCESSING THE PROTEUS ONTOLOGY THROUGH PROTÉGÉ

1. If Protégé is not installed on the computer, download and install Protégé ( 3.4.4 from http://protege.cim3.net/ download/old-releases/3.4.4/installer/ ). If you intend to work behind a proxy server add the following as a single line in the Protege.lax file that is in the Protege installation directory: “lax.nl.java.option.additional=-Dhttp.proxySet=true -Dhttp.proxyHost=yourHost -Dhttp.proxyPort=yourPortNumber” where yourHost and yourPortNumber should be set according to the features of your proxy server

2. Run Protégé 3. Create a new projet choosing OWL/RDF files option 4. Import the Proteus ontology using the + button in the Ontology

Browser tab and giving the link :http://www.anr-proteus.fr/sites/default/file/download/Ontology/Proteus.owl

1.3.2 EXPLORING THE DESCRIPTION OF THE CHALLENGES PROVIDED THROUGH THE PROTEUS PLATFORM

Assuming that Protégé is already installed.

1. Run Protégé 2. Create a new project choosing OWL/RDF files option 3. Import the Proteus ontology and the description of provided challenges using

the + button in the Ontology Browser and giving the link ( http://www.anr-proteus.fr/sites/default/files/download/Ontology/ProteusServices.owl )

4. Open the SPARQL tab (see “Reasoning/SPARQL Query” Panel)5. Formulate a SPARQL query. For instance, for displaying the set of systems

describing problems and the sub-systems aggregated by those systems the query should be: SELECT ?Problem ?Aggregated WHERE {?Problem ?p expe:Problem . ?Problem kern:aggregates ?Aggregated . } . Finally click on Execute Query



Delivered 14

23/03/2012

Page 14 of 83

http://www.anr-proteus.fr/sites/default/files/download/Ontology/ProteusServices.owl

http://www.anr-proteus.fr/sites/default/files/download/Ontology/ProteusServices.owl

http://www.anr-proteus.fr/sites/default/files/download/Ontology/Proteus.owl

http://protege.cim3.net/download/old-releases/3.4.4/installer/

ARPEGE PROGRAM

2009 EDITION



2. GENERAL STRUCTURE

This document presents two main chapters; the chapter 3 devoted to the detailed description of the final version of the ontology and the chapter 4 devoted to the use of the ontology for describing the scenarios of the Proteus project.

Figure 2: ontologies stack

The structure of chapter 3 is based on the structure of the ontology which includes, as depicted here above, on one hand a kernel giving the basic concepts for describing dynamic systems moving in an environment and on the other hand several modules devoted to specific aspects of the Proteus platform; information, environment, mission, robot and simulation. The concepts defined in the kernel are not specific to the robotic domain. However those concepts are useful for defining concepts of the robotic domain. Links exist between these different modules that are presented below.The stack can be complemented by whatever new modules its user would see fit. As an example, the DEVS extension is quoted that is not included in the ontology core but that was derived from it due to other needs not to be discussed here.



Delivered 14

23/03/2012

Page 16 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 3: links between the core parts of the ontology

This chapter ends presenting the different rules as implemented using the SWRL.Chapter 4 gives a summary of the conclusions of this work.Chapter 5 gathers the annexes that provide definitions of the acronyms used in this document, a glossary of the classes of the kernel and specific robotic scenarios that were used to test the ontology. Those scenarios are:

• Urban scenario,

• Air-and-Land scenario.



Delivered 14

23/03/2012

Page 17 of 83

http://www.w3.org/Submission/SWRL/

ARPEGE PROGRAM

2009 EDITION



3. ONTOLOGY DETAILED DESCRIPTION

Thus, PROTEUS ontology is structured as a set of specialised modules built over a general purpose kernel. This chapter begins with the description of the kernel, then each module is presented. The general purpose kernel, as well as each module, corresponds to one specific OWL file and to one specific namespace. Table 1 indicates the namespaces used and their prefixes. Each namespace is a container that provides the context, associated to the kernel or to the specific module, for the content of the OWL file. Moreover a specific PROTEUS file integrates the kernel and the modules.

Figure 4: Components of an OWL ontology

The main components of an OWL ontology are shown on Figure 4. Those are on one hand the classes (each time it is encountered a class obeys the here before style) that encapsulate the meaning of concepts and on the other hand the properties (each time it is encountered a property obeys the here before style) that describe the kind of associations that are possible between classes. The presentation of the ontology is mainly based on graphs with nodes corresponding to classes and oriented arcs corresponding to properties. Class hierarchies may be created by making one or more statements that a class is a subclass of another class. The properties of this class are inherited by its subclasses. This is symbolized on graphs by specific arcs with a isa label. Property hierarchies may also be created by making one or more statements that a property is a sub property of one or more other properties. For



Delivered 14

23/03/2012

Page 18 of 83

ARPEGE PROGRAM

2009 EDITION



instance the has property, which is a generic composition property, can be specialised in hasPhysicalCaracteristics, which is a property that may apply only to physical objects.Classes can be defined more precisely by defining restrictions on inherited properties. Those restrictions, applied to a specific subclass, can specify cardinality or can specialize the range of the property. Finally at set of description logic rules involving several classes and several properties can be written in SWRL.A namespace prefix is systematically used for modifying the meaning of the name of a class or a property in function of the context of the OWL file it belongs to. For instance the property hasPhysicalCaracteristics, belongs to the kernel module and is always named kern:hasPhysicalCaracteristics.

Table 1 indicates the namespaces, their prefixes, limited to four letters, and the contents of corresponding OWL files.

Namespace Prefix Contentshttp://www.anr-proteus.fr/sites/default/files/download/Ontology/kernel.owl

kern General classes and properties.

http://www.anr-proteus.fr/sites/default/files/download/Ontology/Environment.owl

envi Classes and properties devoted to the description of the environment to be simulated for the verification or validation of a solution through a numerical experiment.

http://www.anr-proteus.fr/sites/default/files/download/Ontology/experiment.owl

expe Classes and properties devoted to the description of the use of the PROTEUS platform: problem, solution, verification and validation in simulation and by field tests.

http://www.anr-proteus.fr/sites/default/files/download/Ontology/information.owl

info Classes and properties devoted to the description of information processed or exchanged.

http://www.anr-proteus.fr/sites/default/files/download/Ontology/mission.owl

miss Classes and properties devoted to the description of the missions of the agents involved in a scenario.

http://www.anr-proteus.fr/sites/default/files/download/Ontology/Robot.owl

robo Classes and properties devoted to the description of the robot elements.

http://www.anr-proteus.fr/sites/default/files/download/Ontology/simulation.owl

simu Classes and properties devoted to the description of the simulation framework and the simulation tools used to test solutions.

http://www.anr-proteus.fr/sites/default/files/download/Ontology/Systems.owl

syst Classes and properties devoted to the description of systems.

http://www.anr-proteus.fr/sites/default/files/download/Ontology/Proteus.owl

prot No classes and properties are defined here it is only a way to verify and present the whole structure and to gather rules.

Table 1: Namespaces and namespace prefixes for PROTEUS ontology OWL files



Delivered 14

23/03/2012

Page 19 of 83

ARPEGE PROGRAM

2009 EDITION



3.1. THE KERNEL MODULE

The kernel ontology defines a set of basic concepts upon which all the extension concepts are developed. There are different families to be considered:

• Capability to compose system;

• Capability to exhibit boundaries to systems;

• Capability to exhibit system evolution through time;

• Capability to describe objects of the world, these objects being systems.

3.1.1 COMPOSITION OF SYSTEMS

Figure 5: composition of system

The aggregation of systems to create a new system goes through the definition of two disjoint concepts, atomic and composite. Whatever a kern:System, it is either kern:AtomicSystem or kern:CompositeSystem. This implies these two concepts are disjoint. When instantiating a system, it can be any of the three concepts. Instantiating kern:System means that the user does not want to decide if it is composite or atomic.

3.1.2 SYSTEM BOUNDARIES

Considering a system, it has to be defined how it interacts with other systems. The boundaries family has this goal.



Delivered 14

23/03/2012

Page 21 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 6: system boundaries

Kern:System interacts with its neighbours thanks to kern:Ports that emit and receive to and from other systems' ports. kern:Interaction may use kernel:Protocol to exchange kern:Information. However, interaction is not reduced to the exchange of information through a protocol. Indeed, interaction includes also purely physical concepts such as force. In such case, there is no associated protocol and no associated information. This is possible because there is no restriction on the cardinality of the relations kern:hasProtocol and kern transmitInformation.All the properties linking these concepts are not shown on this schematic for the sake of clarity.



Delivered 14

23/03/2012

Page 22 of 83

ARPEGE PROGRAM

2009 EDITION



3.1.3 SYSTEM EVOLUTION

In order to exhibit the system activity with respect to time, kern:EvolutionModel is introduced that defines the evolution of kern:Systems AND kern:interactions.

Figure 7: Evolution of kern:system

Thus kern:EvolutionModel provides life to kern:Interactions and kern:Systems making them change their kern:States and kern:EvolutionModel is a function of kern:Time.The following specializations are derived from the concept kern:Interaction:

• kern:Action : Actions are performed by agents that are either robots or humans. The property kern:performs indicates which actions are performed by a kern:Agent. Inversely, the property kern:isPerformedBy indicates which kern:Agent performs a kern:Action. For robots, actions are performed on external world (kern:DriverToHardwareInteraction) or on internal components (kern:ApplicationInteraction).

• kern:DriverToHardwareInteraction that kern:impacts only kern:Hardware.

• kern:HardwareToDriverInteraction that kern:impacts only kern:Driver.

• kern:InterAgentCommunication.



Delivered 14

23/03/2012

Page 23 of 83

ARPEGE PROGRAM

2009 EDITION



Notice that it exists kern:DriverToHardwareInteraction that are not actions but only data flow.

3.1.4 ABSTRACT VERSUS ACTUAL INFORMATION

For kern:Information it is necessary to distinguish between abstract and actual information meaning those used in a computer.

Figure 8: Relationship between abstraction and actual implementation

kern:Information is introduced to represent whatever pieces of knowledge can be described or exchanged or recorded. This knowledge can be either discussed between human beings (or living creature able to process and interpret percepts as well) and at this level is considered abstract because not manipulated formally or indeed not by computers and thus human artefacts such as robots. kern:Abstraction allows to ignore implementation details and to speak of knowledge at a generic level. kern:Data is an explicit computer implementation of it. It is trivial to state these two concepts are disjoint.



Delivered 14

23/03/2012

Page 24 of 83

ARPEGE PROGRAM

2009 EDITION



3.1.5 DESCRIPTION OF THE OBJECTS OF THE WORLD / ENVIRONMENT

The world is also to be defined and thus the following schematic.

Figure 9: objects of the world

the world is defined here as kern:Environment. There is nothing outside of it. It is thus the highest possible kern:PhysicalObject. A kern:PhysicalObject being a kern:System, it means that there are no ports to the unique kern:Environment linking it to other kern:PhysicalObjects. Every of the kern:PhysicalObject has to be included inside.The computing objects are those running onto kern:hardware. They kern:executesOn them. kern:Agent are always associated to computing objects in order to provide decision abilities at the very least. kern:Application is the piece of software actually capable of kern:executesOn on a kern:hardware.



Delivered 14

23/03/2012

Page 25 of 83

ARPEGE PROGRAM

2009 EDITION



3.1.6 SOME OTHER CLASSES

Table 1 gives an informal definition of other classes defined in the kernel part of the ontology.

Name Meaningkern:AlgorithmicModule It is an application that can be composed through the PROTEUS tooling.

kern:Probe It is one of the tool of the “simulator”. A probe is a definition of what variables will have to be accessed when executing the “simulator” in order to record their values.

Table 1: Informal definition of some other classes of kernel

These two concepts are very important as they allow the ontology to introduce piece of code not able to run alone on a hardware and the second one provides the methodology to extract information from system through its evolution in time.

Figure 10: Algorithmic Module and Probe

kern:Probe kern:observes kern:State. This kern:State belongs to a kern:System and, as seen above, evolves in time thanks to kern:EvolutionModel. kern:Probe becomes a kern:Application when it is needed to extract information from a kern:Software.



Delivered 14

23/03/2012

Page 26 of 83

ARPEGE PROGRAM

2009 EDITION



3.2. THE INFORMATION MODULE

The information ontology goal is to provide concepts to manipulate data during modelling work. As indicated in the kernel, it is necessary to distinguish between abstract and actual information meaning those used in a computer. Moreover this is the place where the different type definition are made.

3.2.1 ATOMIC VERSUS COMPOSITE NATURE OF KERN:DATA

Figure 11: How to compose information

As for kern:System, there is a need to compose information. This is done in the two parts of the information ontology with relationships due to the kern:implements property. In fact, concepts derived of kern:Abstraction are mathematical objects such as info:Set and info:CrossProduct. There is no direct use of these concepts into the actual implemented information. Due to computer aggregation methods, there are these two concepts, info:Collection able to group loosely chunks of kern:Data and info:ComposedData that kern:implements directly the info:CrossProduct concept.The different existing implemented definitions of the content of robotic system messages, such as info:GPS and many others, are specializations of info:ComposedData.



Delivered 14

23/03/2012

Page 27 of 83

ARPEGE PROGRAM

2009 EDITION



3.2.2 DETAILS OF KERN:ABSTRACTION

kern:Abstraction groups concepts that can be manipulated by other ontologies not taking into account any implementation details. At this level we can find definition of algebraic concepts , functional concepts and physical world related concepts.

Figure 12: details of kern:Abstraction concept



Delivered 14

23/03/2012

Page 28 of 83

ARPEGE PROGRAM

2009 EDITION



3.3. THE ENVIRONMENT MODULE

3.3.1 INTRODUCTION

The « environment » part of the Proteus ontology corresponds to the description of everything that can exist. Nothing is outside and everything lives in it. An alias for environment could be Universe or World in an ontologic meaning. This is the highest possible "container" for the physical objects to exist. Considering the scenario to be represented using this concept it expresses also the boundary we imagine for the problem. As an example, for a mobile on ground robot there is no need to represent anything concerning water. The difference between physical objects and the environment is that the envi:PhysicalInteraction are part only of this latter and propagated into it.This module aims at extending the concept defined in the kernel as shown in figure 13.



Delivered 14

23/03/2012

Page 29 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 13: kern:Environment concept as described in the kernel and environment parts of the ontology.

3.3.2 DIFFERENT TYPES OF ENVIRONMENT

The environment include many envi:PhysicalObject that are not belonging to the robotic domain. However some of those objects are very often in the kern:Environment together with robo:Robot (see the Robot Module below) and characterize the type of environment robots are evolving in. A minimal specific set of those objects includes:

• envi:Planet: it is a celestial body that is massive enough to be rounded by its own gravity.

• envi:Atmosphere: it is a layer of gases that may surround a planet and that is held in place by the gravity of the planet.

• envi:Waterbody: it is a significant accumulation of water.



Delivered 14

23/03/2012

Page 30 of 83

ARPEGE PROGRAM

2009 EDITION



• envi:SolidBody: it is a mass distribution with no deformation.

• envi:Building: it is an human-made structure used or intended for supporting or sheltering any use or continuous occupancy.

As shown on figure 14 it exists relations between specific objects:

• envi:hasAtmosphere with scope envi:Planet and range envi:Atmosphere indicates that some planets have atmosphere.

• envi:hasWaterbody with scope envi:Planet and range envi:Atmosphere indicates that some planets have water bodies such as oceans and seas.

Figure 14: Specific physical objects



Delivered 14

23/03/2012

Page 31 of 83

ARPEGE PROGRAM

2009 EDITION



3.3.3 SURFACE

The environment module defines the concept of envi:Surface. It is defined as a two-dimensional topological manifold that is a boundary of an object. As shown on Figure15 several specializations of the concept are defined :

• envi:LandSurface is defined as the envi:Surface of envi:Planet and of envi:SolidBody.

• envi:WaterSurface is defined as the envi:Surface of envi:Waterbody such as an ocean, a sea, a lake or an artificial reservoir.

• envi:Floor is defined as a walking envi:Surface of a room in a envi:Building.

• envi:Stairs is defined as a construction designed to bridge a large vertical distance by dividing it into smaller vertical distances, called steps.

Figure 15: The concept of Surface

Thus, there are relations between kern:PhysicalObject and envi:Surface:

• envi:Surface is a kern:PhysicalObject characterized by a cardinality restriction exactly 0 over the relation envi:hasSurface.

• envi:Surface envi:isSurfaceOf kern:PhysicalObject and

• kern:PhysicalObject envi:hasSurface envi:Surface.



Delivered 14

23/03/2012

Page 32 of 83

ARPEGE PROGRAM

2009 EDITION



Moreover, as shown in figure 16, relations more specific than envi:hasSurface are defined:

• envi:hasLandSurface

• envi:hasStairs

• envi:hasFloor Finally, some specific associations can be made between kern:PhysicalObjects:

• envi:hasAtmosphere indicating that a envi:Planet may have an envi:Atmosphere and

• envi:hasWaterbody indicating that a envi:Planet may have several envi:Waterbody.

• envi:hasBuilding indicating that a envi:Planet such as Earth have several envi:Building.

Figure 16: Relations between specific Physical Objects and specific Surface



Delivered 14

23/03/2012

Page 33 of 83

ARPEGE PROGRAM

2009 EDITION



3.3.4 AGENT CAPABILITY AND ENVIRONMENT

The envi:Surface concept and the specific kern:PhysicalObject defined in the environment and kernel modules are useful for specifying the motion capabilities of kern:Agent. This is performed thanks to relations of the robot module. Figure 17 presents the use of the relation robo:movesOverGround in order to define capability for kern:Human and robo:GroundVehicles.

Figure 17: Use of Surface to define movesOverGround capability

The use of the relation robo:movesOverWatersurface for defining kern:Human and robo:SurfaceVehicle motion capabilities as well as the use of two specializations of the relation robo:movesIn for defining kern:Human, UUV and UAV motion capabilities are easily derived from the above concepts.



Delivered 14

23/03/2012

Page 34 of 83

ARPEGE PROGRAM

2009 EDITION



3.3.5 PHYSICS

As shown on figure 18,the concept of envi:Force is defined together with the relation envi:accelerates. It is any influence that causes a free body to undergo a change in speed, a change in direction, or a change in shape. The relation envi:accelerates indicates the change of speed for a kern:PhysicalObject. Most relevant types of envi:Force are:

• envi:GravityForce is directly proportional to the kern:PhysicalObject mass.

• envi:NormalForce is the repulsive force of interaction between atoms at close contact. It is applicable in hard envi:Surface contact of kern:PhysicalObject.

• envi:Buoyancy is an upward acting envi:Force exerted by a fluid, that opposes an object's weight. This force is relevant for kern:PhysicalObject in envi:Waterbody or at BI.

• envi:AerodynamicForce is the resultant force exerted on a kern:PhysicalObject by an envi:Atmosphere in which the kern:PhysicalObject robo:movesInAtmosphere, and is due to the relative motion between the kern:PhysicalObject and the envi:Atmosphere.

Figure 18: Force and its specializations

Moreover, envi:Atmosphere and envi:Waterbody are related through a relation envi:hasCurrentInFluid to the concept envi:CurrentInFluid. It is the magnitude and orientation of flow within a fluid. For envi:Atmosphere it corresponds to the wind, for envi:Waterbody it corresponds to water current.



Delivered 14

23/03/2012

Page 35 of 83

ARPEGE PROGRAM

2009 EDITION



3.4. THE SYSTEM MODULE

3.4.1 SPECIALISATION OF SYSTEM

As shown on figure 19, systems ontology specializes the concept of kern:System. Those specializations correspond to specific models, kern:Model, describing functionally robots : syst:RoboticFunctionalSystem. The relations syst:hasImplementingHardware and syst:hasImplementingSoftware allow to link a functional system to its implementation.

Figure 19: Functional view of systems

Further specializations of robotic functional system are presented on figure 20. Those specializations are:

• syst:SecuritySystem that syst:protectsSystem syst:RoboticSystem.

• syst:ControlSystem that syst:controlsSystem syst:RoboticSystem and is specialized in syst:Open-Loop_ControSystem and in syst:Closed-Loop_ControlSystem. syst:Closed-Loop_ControlSystem is specialized in the different way automatic control theory is used to design controllers; syst:AdaptiveController, syst:DeadbeatController, syst:H_InfinityLoopSharingController, syst:IntelligentController, syst:ModelPredictiveController, syst:PI_Controller, syst:PID_Controller, syst:ProgrammableLogicController and syst:ProportionalController.



Delivered 14

23/03/2012

Page 36 of 83

ARPEGE PROGRAM

2009 EDITION



• syst:MissionManagementSystem.

• syst:PlatformManagementSystem.

• syst:MotionPlanningSystem.

Figure 20: Highlighted functions

3.4.2 SYSTEMS WITH HARDWARE AND DRIVERS

As shown on figure 21 the concept kern:CompositeSystem is specialized in syst:RoboticSystem that is specialized in:

• syst:ActuatorSystem that kern:aggregates only syst:ActuatorDriver or syst:ActuatorHardware, that kern:aggregates some syst:ActuatorDriver and that kern:aggregates some syst:ActuatorHardware.

• syst:CommunicationSystem that kern:aggregates only syst:CommunicationDriver or syst:CommunicationHardware, that kern:aggregates some syst:CommunicationDriver and that kern:aggregates some syst:CommunicationHardware.

• syst:PowerSystem.

• syst:SensorSystem that kern:aggregates only syst:SensorDriver or syst:SensorHardware, that kern:aggregates some syst:SensorDriver, that kern:aggregates some syst:SensorHardware and that is specialized in syst:ExteroceptiveSensorSystem and syst:ProprioceptiveSensorSystem. Those two concepts are further specialized.

• syst:StructuralSystem that is specialized in syst:ChassisSystem.



Delivered 14

23/03/2012

Page 37 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 21: Robotic system

As shown on figure 22 syst:ActuatorDriver, syst:ActuatorHardware, syst:CommunicationDriver, syst:CommunicationHardware, syst:SensorDriver and syst:SensorHardware are derived from kern:Driver or kern:Hardware. Those classes are further specialized in function of the type of actuator or sensor. A specific type of actuator hardware, syst:HardwareImplementationOfController, allows to describe the case where the software controls the hardware through a controller implemented with analogical electronics.

Figure 22: Some hardware and some drivers

3.4.3 OTHER SPECIFIC HARDWARE

Besides hardware of composite systems, the ontology describes three other kern:Hardware:

• syst:Computer,

• syst:ControlStationSystem and

• syst:StructuraSystem.



Delivered 14

23/03/2012

Page 38 of 83

ARPEGE PROGRAM

2009 EDITION



3.4.4 SPECIFIC INTERACTIONS

As shown on figure 23 the ontology specializes the concept of kern:Interaction in:

• syst:ApplicationInteraction that is further specialized in syst:ControlAndCommand.

• syst:NoiseSignal that hasNoiseModel kern:NoiseModel.

Figure 23: Specific interactions

3.4.5 SPECIFIC SOFTWARE

As shown on figure 24 the concept of kern:Application is specialized in other classes than kern:Driver:

• syst:RoboticMiddleware that syst:hostInteractions syst:ApplicationInteraction.

• syst:RoboticApplication.Finally the class syst:SystemInterface is a specialization of kern:Software that syst:managesMiddlewareMessage and that presents two sub-classes:

• syst:OutputSystemInterface that syst:publish syst:RoboticMiddleware.

• syst:InputSystemInterface that syst:suscribe syst:RoboticMiddleware.syst:MiddlewareMessage is an indirect specialization of info:ComposedData.



Delivered 14

23/03/2012

Page 39 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 24: Specific software

3.5. THE MISSION MODULE

3.5.1 COMPOSITION OF MISSION

The main concept of the mission module is miss:Mission. This concept corresponds to an operational mission. It can be used, on one hand, by the components of an architecture performing it and, on the other hand, by the performance assessment framework, simulation test or field tests, evaluating the architecture. The mission is composed of a set of concepts.

• miss:MissionStateMachine: this concept gathers the dynamic behavior of a mission. As shown by figure 26, it is a miss:FiniteStateMachine which is a kern:StateMachine which is an kern:EvolutionModel. Thus miss:MissionStateMachine is a specialization of concepts of the kernel.

• miss:WorkFlow: this concept corresponds also to the way the mission should be executed. It is less formal than miss:MissionStateMachine.

• miss:MissionObjective: this concept corresponds to textual or mathematical description of the finality, sequence of events and successfully end state of the mission for a specific scenario. It is an info:OperationalInformation that is a specialization of kern:Abstraction. Thanks to polymorphism, many other specializations of kern:Abstraction can be used for describing an objective, for instance kern:Expression, kern:LogicalExpression and kern:Constraint.



Delivered 14

23/03/2012

Page 40 of 83

ARPEGE PROGRAM

2009 EDITION



• miss:MissionType: this concept corresponds to textual description of the kind of mission for a specific Scenario. It is an info:OperationalInformation.

• info:Constraint: this concept corresponds to a textual or mathematical description of what is allowed and what is forbidden during the course of the mission. It is an info:Relation which is itself an info:Function. The info:Constraint concept is specialized in miss:OperationalConstraint and miss:EnvironmentalConstraint. miss:OperationalConstraint defines requirements on the way the mission should be conducted and on minimal mission achievement. miss:EnvironmentalConstraint describes the impacts of the environment on degrees of freedom for the agents involved in the mission.

It is clear that miss:MissionObjective, miss:MissionType and info:Constraint concepts are symbolic informations with a high level of semantic. For instance info:Constraint “to have a final 2D position in a 2 meters range from a target position” corresponds to a mathematical formula:

x t−x f 2 y t− y f

22

Information to be stored is:

• Identification of the variables; xt – X axis coordinate of target position , yt - Y axis coordinate of target position, xf – X axis coordinate of robot final position, yf

– Y axis coordinate of robot final position.

• Identification of the 2D distance concept, or alternatively a tree with nodes containing either a variable, either +, either -, either square, either square root.

• Identification of the relational operator <.

• Identification of the constant “2”.This type of information is much more symbolic than the info:ComposedData which is the most symbolic data of the information module.The composition is described by a set of properties. Thanks to the capability of OWL to describe hierarchies of properties, those properties are derived from more general properties:

• miss:hasMissionStateMachine : this property indicates that miss:Mission is composed by miss:MissionStateMachine. The property is a specialisation of kern:hasEvolutionModel.

• miss:hasWorkFlow : this property indicates that miss:Mission is composed by miss:WorkFlow.

• miss:hasObjective : this property indicates that miss:Mission is composed by miss:MissionObjective. This property is a specialisation of kern:has.



Delivered 14

23/03/2012

Page 41 of 83

ARPEGE PROGRAM

2009 EDITION



• miss:hasType : this property indicates that miss:Mission is composed by miss:MissionType. This property is a specialisation of kern:has.

• miss:hasConstraint : this property indicates that miss:Mission is composed by info:Constraint. This property is a specialisation of kern:has.

Figure 25 summarises the composition of the miss:Mission concept. Note that it has an evolution model which is the mission state machine. The composition of Mission in terms of resources of kern:Agent type is described thanks to the property miss:hasRessources.

Figure 25: Composition of Mission



Delivered 14

23/03/2012

Page 42 of 83

ARPEGE PROGRAM

2009 EDITION



Finally, a property miss:isDescribedBy is also defined for the relations between on one hand miss:WorkFlow and miss:MissionStateMachine and on the other hand between miss:Mission and miss:MissionStateMachine.

Figure 26: WorkFlow and MissionStateMachine



Delivered 14

23/03/2012

Page 43 of 83

ARPEGE PROGRAM

2009 EDITION



3.5.2 MISSION PLANNING AND EXECUTION

Additional concepts are needed to describe more precisely the mission objectives and constraints and their use by planning systems:

• miss:Task: this concept corresponds to a task as defined in Hierarchical Task Networks.

• miss:Plan: this concept corresponds to an organized set of actions intended in order to reach an objective or to perform a high level task. The property miss:isBuiltBy indicates that plans are built by agents.

Those concepts are linked to the objectives and constraints of the mission through a set of properties:

• miss:hasHighLevelTask : this property indicates that miss:MissionObjective may be specified through miss:Task. This task is qualified as a high level task because it can be decomposed in sub tasks corresponding to sub-objectives. The property is a specialization of kern:has.

• miss:isBuiltFrom : this property indicates that a miss:Plan can be computed taking into account miss:MissionObjective and kern:Constraints.

Figure 27 summarises the link between objectives, constraints, plans and actions.

Figure 27: Objectives, constraints, plans and actions

Figure 28 presents a summary of the concept of task in a hierarchical task network:

• miss:Task miss:hasDecomposition miss:Decomposition; each decomposition corresponds to a specific way to perform the task.



Delivered 14

23/03/2012

Page 44 of 83

http://en.wikipedia.org/wiki/Hierarchical_task_network

http://en.wikipedia.org/wiki/Hierarchical_task_network

ARPEGE PROGRAM

2009 EDITION



• miss:Decomposition miss:isDecompositionOfTask miss:Task; is the inverse of the previous relation.

• miss:Decomposition miss:hasReductionTask miss:Task; each decomposition include a set of sub-tasks.

• miss:Decomposition miss:hasPrecondition kern:Condition; each decomposition is applicable only if some conditions hold.

• miss:Operator is a miss:Task; the specificity of an operator is to be a task without decomposition, i.e. a leaf task in the oriented graph of the hierarchy.

The relations miss:induceActivity and miss:isExpectedToChangeState do not belong to the hierarchical task network formalism. However, those relations allows to link the planning domain with the evolution of the systems.

Figure 28: Hierarchical Task Network



Delivered 14

23/03/2012

Page 45 of 83

ARPEGE PROGRAM

2009 EDITION



3.5.3 MULTI AGENT MISSIONS

Multi agent missions implies specific kind of kern:Interaction corresponding to the exchange of information between agents involved in the mission. This type of Interaction is the concept kern:InterAgentCommunication. As shown on figure 29 the concept has several specialisations :

• miss:Negotiation: agents exchange information in order to reach an agreement. This concept is further specialized in miss:DistributedConflictSolving where the purpose of the agreement is resource sharing, for instance not being at the same place at the same time, and miss:DistributedTaskAllocation where the purpose of the agreement is a share of the work to be done.

• miss:CommunicationOfBeliefs: agents exchange information in order to have a shared view about the current situation. This view can be grounded either on deterministic or non deterministic formalisms. The concept is specialized in function of the topic of the belief:

◦ the topic of miss:CommunicationOfSelfStateEstimation is the state of the emitter agent,

◦ the topic of miss:CommunicationOfBeliefAboutOtherAgent is the state of the agents perceived by the emitter agent, this state can be expressed in a frame linked to the emitter agent, and

◦ the topic of miss:CommunicationOfBeliefAboutEnvironment is the state of all things and agents in the environment that do not participate to the mission; enemies, targets, landmarks, obstacles...

• miss:CoordinationSignal: agents exchange information at execution time in order to synchronize for the beginning or a critical step of the a shared task.

• miss:CommunicationOfIntents: agents exchange information about their current plans.



Delivered 14

23/03/2012

Page 46 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 29: Different types of inter agent communications

The inter agent communication is based on a protocol. Some protocols are specific to the robotic application. However it also exist protocols which are less specific and devoted to a type of communication. For instance, a property miss:hasTaskAllocationProtocol, indicates that miss:DistributedTaskAllocation is based on miss:TaskAllocationProtocol.



Delivered 14

23/03/2012

Page 47 of 83

ARPEGE PROGRAM

2009 EDITION



3.6. THE ROBOT MODULE

3.6.1 CLASSES

This module includes classes specializing kern:CompositeSystem:

• robo:GlobalPlatform that kern:aggregates some robo:Robot and kern:aggregates some kern:Human and kern:aggregates some syst:ControlStationSystem.

• robo:Robot , presented on Figure 30, that is also a kern:Agent and that kern:aggregates only syst:RoboticSystem and that robo:uses syst:RoboticMiddleware.

Figure 30: robo:Robot is a kern:CompositeSystem and a kern:Agent

robo:Robot is itself specialised in a set of concepts:

• robo:PilotedSystem, presented on Figure 32, that is characterized by the fact that kern:Human robo:pilots it.

• robo:UnmannedSystem also presented on Figure 32.

• robo:AirVehicle, presented on Figure 30, that robo:movesIn some envi:Atmosphere and that robo:movesInAtmosphere envi:Atmosphere.

• robo:GroundVehicle, presented on Figure 31, that robo:movesOver some envi:Surface and that robo:movesOverGround envi:Floor or envi:Stairs or envi:LandSurface.



Delivered 14

23/03/2012

Page 48 of 83

ARPEGE PROGRAM

2009 EDITION



• robo:SurfaceVehicle, presented on Figure 31,that robo:movesOver some envi:WaterSurface and that robo:movesOverWaterSurface envi:WaterSurface.

• robo:UnderwaterVehicle, presented on figure 30, that robo:movesIn some envi:Waterbody and that robo:movesInWaterbody envi:Waterbody.

• robo:HybridVehicle, presented on figure 30, that robo:movesInAtmosphere envi:Atmosphere, robo:movesInWaterbody envi:Waterbody, robo:movesOverGround envi:Floor or envi:Stairs or envi:LandSurface and robo:movesOverWaterSurface envi:WaterSurface.

Figure 31: robo:SurfaceVehicle and robo:GroundVehicle

On one hand robo:PilotedSystem and robo:UnmannedSystem are disjoint. On the other hand robo:AirVehicle, robo:GroundVehicle, robo:SurfaceVehicle, robo:UnderwaterVehicle and robo:HybridVehicle are all disjoint with each other. Usually an instance of robot belongs to two classes; one class characterizing its autonomy and the other class characterizing its motion capabilities. Finally, robo:GroundVehicle is specialized in two disjoint classes:

• robo:Car-likeVehicle that kern:aggregates exactly 1 syst:WheelSystem and kern:aggregates exactly 1 syst:EngineSystem.

• robo:DifferentialVehicle that kern:aggregates exactly 2 syst:EngineSystem.

3.6.2 PROPERTIES

This module includes specific properties:

• kern:Agent robo:movesIn kern:PhysicalObject. It is specialised, on one hand, in robo:AirVehicle or robo:HybridVehicle robo:movesInAtmosphere envi:Atmosphere and, on the other hand as



Delivered 14

23/03/2012

Page 49 of 83

ARPEGE PROGRAM

2009 EDITION



kern:Human, robo:UnderwaterVehicle or robo:HybridVehicle robo:movesInWaterbody envi:Waterbody.

• kern:Agent robo:movesOver kern:Surface. It is specialised, on one hand, in kern:Human, robo:GroundVehicle or robo:HybridVehicle robo:movesOverGround envi:Stairs, envi:Floor and envi:LandSurface and, on the other hand as kern:Human, robo:SurfaceVehicle or robo:HybridVehicle movesOverWaterSurface envi:WaterSurface.

• kern:Human robo:pilots robo:PilotedSystem as indicated on Figure 32.

• kern:Robot robo:uses syst:RoboticMiddleware Figure 32.



Delivered 14

23/03/2012

Page 50 of 83

Figure 32: The robo:pilots and robo:uses properties

ARPEGE PROGRAM

2009 EDITION



3.7. THE SIMULATION MODULE

The goal of this module is to create the concepts necessary for the PROTEUS platform to be able to tackle with simulation, simulator and the like. Inputs considered were two folds.

• The first input comes from the previous step of the modelling work. This allows to complete the part dedicated to the theory of modelling and simulation;

• The second input is obtained below from end-users needs and specification that introduced definitions concerning simulation (Table 21 groups them).

English def. MeaningExternal algorithmic module It is a software that can be composed through the PROTEUS tooling.

Simulator It is an application that in PROTEUS context must be generated by the platform and that after a configuration phase is executed

Probe It is one of the tool of the “simulator”. A probe is a definition of what variables will have to be accessed when executing the “simulator” in order to record their values.

Simulation Result of the “simulator” execution got through the “probes” put into the “simulator” either statically or dynamically.

Metric A “metric” is the composition of one or multiple “probes”' recordings associated to a validity domain in order to allow a measure of performances. A “metric” can be related to multiple records provided by multiple “simulations”. This is often the case of statistical approach to assessment.

Table 2: definitions used to introduce some of the concepts

The section is decomposed following the different above definitions

• “simulator” concept in the ontology;

• presentation of the “simulator software” and its parts;These different elements are closely linked to the specification done during the elaboration of the PROTEUS platform.

3.7.1 “SIMULATOR” CONCEPT

Simulator definition (see Table 2): It is an application that in PROTEUS context must be generated by the platform and that after a configuration phase is executed.

When considering such a definition coming from the PROTEUS specification, we are already considering a specialised concept with respect to our ontology. In fact we are speaking of software. In a first step it is important to explain what is the simulator concept.

1Definitions are provided in French and in English. We let here only the English definitions



Delivered 14

23/03/2012

Page 51 of 83

ARPEGE PROGRAM

2009 EDITION



A “simulator” is an “evolution model” with some specific structural aspects and properties. It is to be specialised due to the fact that to simulate is not specific to software but can be applied to scale models as an example. Figure 33 specifies the different concepts involved.

Figure 33: simulation ontology

simu:SimulatorEvolutionModel action is to kern:animates a kern:system that kern:models another one. The specific nature of simu:SimulatorEvolutionModel depends on the type of system considered. The common nature of the simulated systems is to be images of an actual existing and different system that is studied through the simulation.



Delivered 14

23/03/2012

Page 52 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 34: different type of simulator

You can have:

• simu:HardwareSimulator that kern:animates only kern:PhysicalObjects such as scaled aircraft into aerodynamic facilities as an example;

• simu:SoftwareSimulator that kern:animates only kern:SimulatedSystem such as game engine or VLE tooling;

• simu:HybridSimulator such as those stimulating inputs on existing equipments through software.

Considering the simu:SoftwareSimulator, it is itself a kern:software and it can collaborate with an kern:Application. It must be remarked that this statement means potential collaboration with other simulators.

3.7.2 SIMULATOR SOFTWARE AND PARTS

simu:SoftwareSimulator is the concept covering this topic. There are many details to consider here. What type of software is this simulator and what does it manipulates.



Delivered 14

23/03/2012

Page 53 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 35: software and simulator

The problem of simulation is to relate models' theories to software implementation. In order to do that, there is a need to specify the theories taken into account as well as their corresponding implementation. To do that, are introduced simu:AtomicModel and simu:AtomicAlgorithmicModule that are related through restrictions of kern:models. Another important point is to create libraries. It is done as kern:aggregates links simu:SoftwareLibrary to simu:AlgorithmicModule.



Delivered 14

23/03/2012

Page 54 of 83

ARPEGE PROGRAM

2009 EDITION



3.8. THE EXPERIMENT MODULE

The goal of this module is to describe the work flow attached to the robotician tasks, that is the different used steps that the PROTEUS platform tries to embody, the relationships between these steps and the objects manipulated during these steps. To do that, we first introduce schematics illustrating the work flow as understood in the project then the vocabulary in the following table.

3.8.1 SCHEMATICS2

Here is first introduced the work flow of problems and solutions. It is what is to be embodied in the dedicated web portal.

Figure 36: Work flow

2As this documentation needs to be self sufficient, we remind here elements that were introduced elsewhere by the project that is funding the ontology activity



Delivered 14

23/03/2012

Page 55 of 83

ARPEGE PROGRAM

2009 EDITION



There are roles to be introduced in this work flow.

Figure 37: roles linked to a scenario

In the day to day work of a roboticien, the goal is not to answer to a challenge but to work on his topics creating scenario and thus being a scenario provider. Below is defined what is a scenario.

Figure 38: roles linked to problem



Delivered 14

23/03/2012

Page 56 of 83

ARPEGE PROGRAM

2009 EDITION



Scenario allows to create problems. When someone is willing to present a problem then he is a problem provider. Problem content is defined below.

Figure 39: roles linked to solutions

Last part of the life cycle, the solution provider that is able to answer the problem presented above.

3.8.2 DEFINITIONS

English def. Meaning

Scenario Operational field in which the Problem is defined and built

Problem Definition of the architecture of one or more robots and their environment using the proteus main tool

Solution Subpart of interest in the software system of a robot. Its implementation is provided by a solution provider.

Problem Provider The Problem Provider defines the scenario, problem, configurations and metrics.

Configuration A configuration is composed of:

- initial state of the problem and solution

- list of external module libraries

- probe definitions

- simulator and middleware choices

Evaluation The evaluation of a solution consists in applying the metrics to the results of one or more executions (each execution corresponds to a configuration).

Probe A probe observes the state of systems and produces results.

Proteus Simulator Simulator which hosts a problem.



Delivered 14

23/03/2012

Page 57 of 83

ARPEGE PROGRAM

2009 EDITION



English def. Meaning

Solution Provider The Solution Provider provides a solution to a problem

Target it is the “simulator” that is generated by the platform and that includes everything needed by the “solution provider” to verify / assess its contribution.

Environment Simulator It is an “application” that inside the “simulator” takes in charge whatever is not the “robot(s)' system”.

Communication Middleware

It is an “application” that inside the “simulator” takes in charge the communications between the “robotic middleware” and the “environment simulator”

Table 3: definitions used to introduce some of the concepts

3.8.3 IMPLEMENTATION

The above introduced concepts need to be implemented in the ontology in order to allow their use. There are also details on how the simulator is generated. In the below description, some other concepts, properties and parameters are introduced induced by the implementation of those defined concepts.



Delivered 14

23/03/2012

Page 58 of 83

ARPEGE PROGRAM

2009 EDITION



• Actors of the life cycle

Figure 40: Roles involved in challenges

The life cycle of the RobotML platform is linked to those trying to create expe:Problem, the expe:ProblemProvider and trying to answer them, expe:SolutionProvider. To provide expe:Problem does not mean to organise a challenge, a competition. It is the specificity of expe:ChallengeProvider to do just that and thus to allow expe:Challenger to participate.



Delivered 14

23/03/2012

Page 59 of 83

ARPEGE PROGRAM

2009 EDITION



• Elements of the problem and the solution

Figure 41: Problem and solution

expe:Problem is a kern:CompositeSystem that kern:aggregates many different parts such as expe:RobotMLSimulator (the so-called PROTEUS simulator). This simulator (not indicated) kern:uses expe:Scenario and expe:Configuration, and simu:creates an expe:Simulation, using kern:Probe, which allows a expe:ProblemProvider to expe:evaluates an expe:Solution provided by a expe:SolutionProvider.

• Target generation

In the platform life cycle remains the definition of how the simulator is generated.



Delivered 14

23/03/2012

Page 60 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 42: Target generation

There we see that expe:RobotMLPlatformUser (which the solution and problem providers are) kern:hasActivity expe:ModellingActivity that kern:hasActions expe:GenerateSimulator and expe:EditModel.

3.9. RULES

A rule enforces the fact that if a system aggregates another system, then it cannot be atomic:kern:System(?x) ∧ kern:System(?y) ∧ kern:aggregates(?x, ?y) → kern:isAtomic(?x, false)A rule enforces the fact that if a physical object cannot be positioned in a referential that it defines:kern:isPositionedIn(?x, ?y) ∧ kern:definesAReferential(?x, ?z) → differentFrom(?y, ?z)A rule enforces the fact that if a system has a port emitting an interaction then this system triggers this interaction:kern:System(?x) ∧ kern:Interaction(?y) ∧ kern:Port(?z) ∧ kern:hasPort(?x, ?z) ∧ kern:emits(?z, ?y) → kern:triggers(?x, ?y)



Delivered 14

23/03/2012

Page 61 of 83

ARPEGE PROGRAM

2009 EDITION



3.10. EXPLANATION OF WARNINGS

Some warnings are detected when running ontology test. Each of those warnings are explained bellow:

• (at info:Real): Missing disjoints on primitive subclasses: info:FloatingPointNumber info:PhysicalData info:FixedPointNumber. A physical data is some kind of floating or fixed point number with an associated unit that is an abstraction. There is a disjunction between floating and fixed point numbers but there is no disjunction between those numbers and physical data. The unit is linked with the number only through the meaning that the software designed is giving to the number.

• (at kern:System): Missing disjoints on primitive subclasses: syst:ControllerComponent syst:ControlStationSystem kern:CompositeSystem kern:AtomicSystem kern:Software kern:PhysicalObject. There is no full disjunction of subclasses under system because systems can be characterized under three independent points of view. The compositional point of view indicates that a system is either atomic, it cannot be decomposed, or is composite. The physical point of view indicates that a system may be physical but that systems of pure software cannot be considered as physical. Finally the functional point of view classifies the systems under functional aspects. For instance an analogical controller system may belong to atomic, physical and controller component.

• (at robo:Robot): Missing disjoints on primitive subclasses: robo:UnmannedSystem robo:UnderwaterVehicle robo:PilotedSystem robo:GroundVehicle robo:HybridVehicle robo:SurfaceVehicle robo:AirVehicle. Robots are considered under two independent points of view. The first point of view is the motion capacity leading to a full disjunction between underwater, ground, hybrid, surface and air vehicles. The second point of view deals with the autonomy of the robot: there is a disjunction between unmanned and piloted. Because of the independence of the two point of view a full disjunction between subclasses is not possible.

• (at kern:Environment): This class has multiple asserted parents. Environment is a system that is a physical object with several bodies and that is also a composite system because it includes at least on one hand the problem and the solution and on the other hand the robot and the physical object referencing the motion of the robot.



Delivered 14

23/03/2012

Page 62 of 83

ARPEGE PROGRAM

2009 EDITION



• (at kern:SoftwareProbe): This class has multiple asserted parents. A software probe is a probe, a concept in itself, and is also a software. However a software is not necessarily a probe.

• (at robo:Robot): This class has multiple asserted parents. Robot is a system that is an agent, i.e. a subclass of physical object and that is also a composite system because it usually aggregates several robotic systems and because a solution is a system aggregated by a robot.



Delivered 14

23/03/2012

Page 63 of 83

ARPEGE PROGRAM

2009 EDITION



4. SYNTHESIS AND CONCLUSION

This report presents an ontology devoted to the description of mobile robotic scenarios in view of their numerical simulation or field test. This ontology is grounded on a kernel which provides basic concepts allowing the definition of ontological extensions.The main concepts of the kernel are the environment, the physical object, the frame, the interaction, the data, the information, the state, the evolution model, the activity, the system, the composite system and the atomic system. Agent and human concepts are defined as specialization of physical object. The system concept is also specialized in software and hardware is a specialization of physical object. Polymorphism is important for systems; a system can be composite or atomic but also physical object or software. Finally, specializations of the evolution model concept are given for recursive, differential and partial derivative equation models.The proposed ontological extensions deal with:

• information,

• environment,

• systems,

• mission,

• robots and robotic components,

• simulation and

• experiment.The information ontology defines concepts which are a specialization of abstraction or data. The main data concepts defined are primitive data, collection and composed data. Timestamped data is a composed data that have a data time data type. This data type is produced by clock, a specialization of hardware. Physical data is a special kind of primitive data, the real, that has a special kind of abstraction; the unit. Those two data concepts reflect requirements for the PROTEUS platform. The symbolic information concepts that are defined in the mission ontology are gathered under an abstraction named operational information.The environment ontology specializes the physical object concept in surface and fluidic body. Surface is specialized in land surface and water surface while fluidic body is specialized in atmosphere and water body. Constraints on interaction induced by the type of environment are described thanks to several specializations of the concept of force. Objects that are likely to be located in different types of environment such as building, floor and stairs are specializations of physical object or surface.



Delivered 14

23/03/2012

Page 64 of 83

ARPEGE PROGRAM

2009 EDITION



The systems ontology specializes the concept of system in controller component and control station system. Controller component is specialized in proportional, integral and derivative controller and in robotic functional system. Further specializations of robotic functional system are proposed. Moreover the concept of composite system is specialized in actuator system, communication system, power system, sensor system and structural system. Concepts of driver and hardware belonging to actuator system are specialized in actuator driver and actuator hardware respectively. The same type of relations are developed for sensors. Finally, this ontology specializes, on one hand, the concept of interaction in application interaction and in noise signal and, on the other hand, the concept of software in system interface.The mission ontology specializes the concept of state machine in mission state machine and the concept of operational information in mission, plan, task, mission objective, mission type and work flow. The concept of constraint is specialized in environmental constraint and operational constraint. The work flow is described by the mission state machine.The robots and robotic components ontology defines the robot concept as a specialization of agent. Among robot sub classes there are two disjunctions. The first one is between piloted system and unmanned system. The second one is between air vehicle, ground vehicle, surface vehicle, underwater vehicle and hybrid vehicle.The simulation ontology defines the simulator evolution model concept as a specialization of evolution model. Further specializations of the concept are proposed; hardware simulator, software simulator and hybrid simulator. Software simulators are composed of algorithmic modules that are software and systems.The experiment module specializes the concept of human in problem provider and solution provider. It also introduces problem and solution as specializations of system. Finally it introduces the concept of metric that allows to assess the quality of the solution.The proposed ontology is tested by trying to use it for description of an urban scenario and an air-ground scenario. The transcription from textual information to ontological description is time consuming resulting in an incomplete description for all examples.The urban scenario description indicates that concepts such as robot, human, robotic sub-system are useful. The concepts linked with the finite state machine evolution model are used but the model description is fastidious.The description of the air-ground scenario with the ontology indicates that the concepts of scenario, system, architecture, environment, mission, physical object, robot, human, localization sensor, evolution model and task are useful. A large number of physical objects and the absence of specification of cardinality of objects in general scenarios are obstacles for description with the ontology. However definition of instances that could be automatically generated, for instance randomly in a given



Delivered 14

23/03/2012

Page 65 of 83

ARPEGE PROGRAM

2009 EDITION



distribution, is a goal beyond the scope of the project. The link between instances of robots and their corresponding instance of evolution models is performed. However same phenomena does not exist for the link between events and corresponding physical objects. The concepts linked with the finite state machine evolution model are used but the model description is as fastidious as for the urban scenario.Concepts such as environment, physical object, sensor, actuator, mission and mission objective are useful.In the present scope of the work in the PROTEUS project the transcription of ontology concepts to the UML meta-model of DSL is manual. An automated generation to a simulator can only be performed from the DSL and not from the ontology. Thus, the user of the platform may work directly from a problem or a solution described in DSL. In that context the use of the ontology has to be limited to the points about which different users of the platform has to agree. The consistency of the agreed solution could then be checked with a reasoner, for instance Pellet.Globally, a common naming standard for scenarios and modules is used. For example, the string of four letters beginning of the name of the scenario is a prefix for the name of its instances. This naming procedure have the disadvantage of duplicating instances shared by several scenarios. On the long term, some research on instance naming standard has to be conducted for avoiding both duplication and anonymity of instances.In conclusion, the result of the test of the ontology indicates that many concepts of the ontology are well grounded. Those concepts should be used not only as a basis for a first version of a robotic domain specific language but also as a way of descovering the services provided by the Proteus platform. Finally introduction of additional concepts could be useful in some cases. The work on the ontology should continue outside Proteus with the objective to reach a simple and correct set of concepts and relations.



Delivered 14

23/03/2012

Page 66 of 83

ARPEGE PROGRAM

2009 EDITION



5. ANNEXES



Delivered 14

23/03/2012

Page 67 of 83

ARPEGE PROGRAM

2009 EDITION



5.1. ACRONYMS

• 2D: 2 Dimensional

• CECILL B: licence Cea Cnrs Inria Logiciel Libre compatible Berkeley software distribution

• DEVS: Discrete EVent System specification

• EIC: External Input Coupling

• EOC: External Output Coupling

• FSM: Finite State Machine

• GPS: Global Positioning System

• IC: Internal Coupling

• IO: Input Output

• IOFO: Input Output FunctiOn specification

• IORO: Input Output RelatiOn specification

• IMU: Inertial Measurement Unit

• INRA: Institut National de la Recherche Agronomique

• LAAS: Laboratoire d'Analyse et d'Architecture des Systèmes

• LIDAR: LIght Detection And Ranging

• OWL: Web Ontology Language

• PID: Proportional Integral and Derivative controller

• PROTEUS: Platform for Robotic modelling and Transformation for End-Users and Scientific communities.

• RDF: Resource Description Framework

• RobotML: Robot Modelling Language

• RTK: Real Time Kinematic

• SPARQL: Structured Protocol And RDF Query Language

• SWRL: Semantic Web Rule Language

• UAV: Unmanned Aerial Vehicle

• UML: Unified Modelling Language

• UUV: Unmanned Underwater Vehicle

• VLE: Virtual Laboratory Environment



Delivered 14

23/03/2012

Page 68 of 83

ARPEGE PROGRAM

2009 EDITION



5.2. CLASS GLOSSARY

• kern:Abstraction: An information that is coded in data.

• kern:Agent: A physical object that has activity, that performs things and that moves in physical objects and over surfaces.

• kern:AlgorithmicModule: A specific type of software.

• kern:Application: A software that executes on computer, that is composed of algorithmic modules and that can communicate through communication middlewares.

• kern:AtomicSystem: A system that is atomic.

• kern:Clock: A hardware that produces time stamps, that keeps track of time and that frames computers in terms of time.

• kern:CompositeSystem: A system that aggregates systems and that is not atomic.

• kern:Data: An information that can be saved in computer files and that implements abstractions.

• kern:Environment: A composite system and a physical object that has frame , that impacts evolution of physical object and that aggregates at least 2 systems.

• kern:EvolutionModel: A thing that animates a system or an interaction, that takes as input states or ports, that is a function of a time and that gives next state.

• kern:FileSystem: A software that manages computer files.

• kern:Frame: A thing that defines space time, that has an origin information and that is defined in a frame.

• kern:Hardware: A physical object that triggers hardware to driver interactions.

• kern:Human: An agent that is not modelled by a system, that does not model a system, that moves in water bodies, over floors, stairs, land surfaces or water surfaces, that pilots piloted systems, that cannot be deployed in software, hardware and hybrid simulators and consequently cannot become something with deployment.

• kern:Information: A thing that has sets and that is used by systems.

• kern:Interaction: A thing that has protocols, that has state, that impacts systems, that is animated by evolution models, that is carried by a connector, that is emitted on a port, that is received on a port, that has source system and that transmits informations.



Delivered 14

23/03/2012

Page 69 of 83

ARPEGE PROGRAM

2009 EDITION



• kern:OperatingSystem: An application that manages file systems.

• kern:PhysicalObject: A system that has surfaces, that has a three dimensional representation trough three dimensional objects, that has physical caracteristics given by physical data, that defines a frame, that evolves in physical objects and that is positioned in frames.

• kern:Port: A thing that emits interactions, that has data value, that has protocol, that is downstream of a connector, that is either input or output, that belongs to a system, that is the support of interaction, that is upstream of connectors and that receives interactions.

• kern:Probe: A thing that belongs to systems, that observes states and the produces informations.

• kern:Protocol: A thing that constrains informations.

• kern:Software: A system executes on hardware, that triggers some application interactions and that is software implementation of robotic functional system.

• kern:SoftwareProbe: An application and a probe that observes automata states and that produces data.

• kern:State: An abstraction that has at least one state variable in form of data and that is represented by something.

• kern:System: A thing that has ports, probes and states, that is animated by evolution models, that is either atomic or not, that is modelled by systems, that models systems, that triggers interactions, that uses informations, that can be deployed in software simulators, hardware simulators or hybrid simulators and that with deployment becomes a simulated system.

• kern:Time: A thing that belongs to frames and that is sample of time base.



Delivered 14

23/03/2012

Page 70 of 83

ARPEGE PROGRAM

2009 EDITION



5.3. SCENARIOS

In this chapter some robotic scenarios of the Proteus project are partially described using the concepts of the ontology.



Delivered 14

23/03/2012

Page 71 of 83

ARPEGE PROGRAM

2009 EDITION



5.3.1 URBAN SCENARIO

• Functional architecture

In this paragraph, we present a first instanciation of a subset of the Challenge 1 Urban Scenario with the ontology. Figure 45 illustrates the functional architecture of the scenario.We consider an “Environment” named “Pavin” in which 3 agents are present:

• the “Taxi” which is a “Robot”

• a “Pedestrian” and a “Client” which are a “Humans”The “Taxi” is also a particular type of “Robot”: a “UGV”. It is composed of “robotic subsystems” (robot functionalities):

1. “Localisation” which elaborates the localisation from current localisation and sensor inputs. Its output is connected to point 6 below

2. “Obstacle Detection” which detects obstacle and sends them to “Trajectory Planning” & “Monitoring and Integrity”

3. “Trajectory Planning” which extracts from environment databases the needed information for “Servoing”



Delivered 14

23/03/2012

Page 72 of 83

Figure 43: Functional architecture of urban scenario

ARPEGE PROGRAM

2009 EDITION



4. “Mapping” which adds knowledge to environment databases for “Trajectory Planning”

5. “Monitoring and Integrity” which elaborates commands for “Control”6. “Servoing” which elaborates commands for “Control”7. “Control” which elaborates actuator commands

Comment: The “triggersSystemInteraction” and “impactsSystem” relations are not homogeneous with other interaction concepts (“PhysicalInteraction”, “SoftwareInteraction” and so on). In our opinion, they should be as we would want to characterize the system interactions as we would type the other interactions. For example, we would like to say that some sensor system sends some state vector through some particular mean to another system. Regarding the representation of the environment for the robot operations. We introduced the following concepts:

• “GIS database” is an instance of an “Environment Model” and it represents the knowledge available with a Geographical Information System.

• “Augmented database” is also an “Environment Model”. It is “built from” the “GIS database” and tailored for being used by the “Trajectory Planning” algorithm. In the case of challenge 1, it would be an oriented graph topology of the different path usable by the “Taxi” augmented with image flows.

• Sensors and actuators

The following figures illustrates the “Taxi” sensors and their uses by (coupling with) the above robotic functionalities. The sensor list is:

• LIDAR

• Vision

• StereoVision,

• Odometer

• GPS

• RTK-GPS + IMU



Delivered 14

23/03/2012

Page 73 of 83

Figure 44: Sensors used for urban robot localisation

ARPEGE PROGRAM

2009 EDITION



Figure 45: Sensors used for urban robot mapping and obstacle detectionThe following actuators are managed by the Control function

• motors

• brakes

• steering wheel

• Dynamic aspects

Regarding the different robotic functionalities, we may add “States” to them, for example:

• for the “Pedestrian”: “Wander”

• for the “Passenger”: “Book a Taxi”, “Wait for the Taxi”, “Enter the Taxi”, “Wait for arrival”, “Get of the Taxi”

• for the “Taxi”: “Wait for booking”, “Go to Passenger Location”, “Pick Passenger”, “Go to Passenger Destination”, “Drop Passenger”

The ontology allows modelling Finite State Machine, however the instantiation result is not an example of clarity (see the example figure below). Moreover, at the moment a “System” does not have an “Evolution Model” which is problematic if we want to associate a FSM to the different robotic systems.



Delivered 14

23/03/2012

Page 74 of 83

Figure 46: Actuators managed by urban robot control

Figure 47: State machine for urban robot

ARPEGE PROGRAM

2009 EDITION



AutomataState Associated FSMActivity

GoToPassengerLocation GoingToPassengerLocation

PickPassenger PickingPassenger

GoToPassengerDestination GoingToPassengerDestination

DropPassenger DropingPassenger

WaitForBooking WaitingForBooking

Table 4: Association between AutomataState and FSMActivity

Passenger has activities that are not linked to automata state. Those Activities are: BookingTaxi, WaitingTaxi, EnteringTaxi and ExitingTaxi. Pedestrian has an activity that is CrossingStreet.

• Conclusion

In conclusion :

• Description of the static architecture is partly feasible (partly because we were not able to characterize the relations between robotic subsystems). The ontology should be modify in order to ensure that relations between robotic subsystems can be described in a consistently manner with relations between componants. Moreover, after modifying the ontology, it would be interesting to check that the data samples foreseen in the information ontology fit the needs in terms of data exchange between instances of DeviceSystem and instances of ManagerSystem.

• Description of the dynamic of the system would be partly possible through the use of FSM however UML formalism would be far more adapted to this task.



Delivered 14

23/03/2012

Page 75 of 83

ARPEGE PROGRAM

2009 EDITION



5.3.2 AIR-GROUND SCENARIO

• Introduction

At the highest level of abstraction the air-ground scenario is described by an instance of the concept Scenario named StabilityOperation. Thanks to the property describesConfAndInitialStateOf it is indicated that the scenario deals with some instances of the System concept:

• IntruderSystem,

• ArmySystem and

• MilitaryRobotTeamsin an Environment named StabilityOperationEnvironment. The property hasSubSystem allows to indicate that the MilitaryRobotTeams belongs to the ArmySystem. The figure 48 presents the highest level of abstraction for the air-ground scenario.

Figure 48: Highest level of abstraction for the air-ground scenario

• The environment and the physical objects

StabilityOperationEnvironment is an instance of AirEnvironment, GroundEnvironment, Indoor and Outdoor indicating that the scenario takes place in the air, on the ground and outside and inside buildings. Thanks to the property takesPlaceInto it is indicated that StabilityOperationEnvironment is the theater of three instances of the Mission concept:IntrudersMission,ArmyMission andRobotsMission.The air-ground scenario includes several instances of the concept PhysicalObject:

• DustRoad1

• DustRoadn



Delivered 14

23/03/2012

Page 77 of 83

ARPEGE PROGRAM

2009 EDITION



• House1

• Housen

• LoftBarn1

• LoftBarnn

• Road1

• Roadn

• Shed1

• Shedn

• Track1

• Trackn

• Tree1

• Treen

Figure 49: Instances of AgentSome of those instances may belong to a common more specific concept, for instance Tree1 and Treen, but nothing in the ontology allows to express this fact. Other instances belongs to concepts derived from PhysicalObject. The figure 49 presents instances of the concepts Robot and Human.

Figure 50: Assignment of instances of Human to instances of MissionFigure 50 shows that thanks to the property hasRessources, the instances of the concept Human are assigned to instances of the concept Mission.



Delivered 14

23/03/2012

Page 78 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 51: The instance GPSSensorOfR-Trooper1

Figure 51 presents the instance GPSSensorOfR-Trooper1 of the concept LocalizationSensor.The description of the environment and physical objects of scenario with the ontology is far from being complete. The main obstacles are:

• some cardinalities not specified by the textual version of the scenario, for instance the number of trees, and

• a large number of physical objects.



Delivered 14

23/03/2012

Page 79 of 83

ARPEGE PROGRAM

2009 EDITION



• The systems and their architectures

Figure 52: The systems and architectures involved in the air-ground scenarioThe figure 52 indicates that each instance of System has its corresponding instance of Architecture thanks to the property hasArchi.

• Dynamical aspects

Two individuals of the concept EvolutionModel, R-TrooperEvolutionModel and RmaxEvolutionModel, indicate available dynamical models for the air and ground platforms. The link between instances of Robot and corresponding instances of EvolutionModel is made with the property isAnimatedByEvolutionModel.One individual of the concept MissionStateMachine, IntruderExpectedBehavior, describes the behavior of the intruders. As shown by figure 53 individuals of AutomataInitialState, AutomataState, Transition and Event describe a simple behavior consisting in crossing until a loft barn or a shed is reached and then hiding.It is important to note that:

1. The description is quite fastidious.2. There is no direct link with the individuals LoftBarn1, LoftBarnn, Shed1

and Shedn.



Delivered 14

23/03/2012

Page 80 of 83

ARPEGE PROGRAM

2009 EDITION



Figure 53: Dynamic of the mission of an intruder

A more precise description of the dynamic of the missions is performed by defining instances of the concept Task. The figure 54 presents the instances of Task. Tasks are : ToKeepWatchOn, ToHide, ToCross, ToDetect, ToControl and ToEscape. FSMActivities induced by those Tasks are respectivelly: KeepingWatchOn, Hiding, Crossing, Detecting, Controlling and Escaping.



Delivered 14

23/03/2012

Page 81 of 83

Figure 54: Instances of Task

ARPEGE PROGRAM

2009 EDITION



Figure 55: Tasks for the missions of the army and the robotsThe figure 55 presents the link between tasks and the missions of the army and robots. Thanks to the property isDescribedBy, the instances ToDetect and ToKeepWatchOn are assigned to both ArmyMission and RobotMission while the instance ToControl is assigned to ArmyMission only.

Figure 56: Implementation of tasks for intrudersThe figure 56 presents the link between tasks and the mission of intruders. Thanks to the property isDescribedBy, the instances ToCrossing, ToHiding and ToEscaping are assigned to the IntruderMission. Thanks to the property hasFSMActivity, it is indicated that the Hiding and Crossing activities are performed reciprocally when the mission is in HidingState and CrossingState. The planning process that builds the behavior from the tasks is not described.

• Conclusion

The scenario capture exercise is far from being finished, however some temporary conclusions can be given:



Delivered 14

23/03/2012

Page 82 of 83

ARPEGE PROGRAM

2009 EDITION



• The choice of using only individual of classes of the ontology for describing scenarios may be a serious limitation. In some cases it could be interesting for the user to state that a set of randomly distributed individuals of a given class are to be generated.

• The amount of data to be gathered is large.

• The absence of link between Event and location of PhysicalObject forbids a deeper description of the causes of the events.



Delivered 14

23/03/2012

Page 83 of 83

Documents

Robotic Ontology and Modelling - 3rd version...ARPEGE PROGRAM 2009 EDITION ANR-09-SEGI-010 ROBOTIC ONTOLOGY AND MODELLING - 3RD VERSION Revision Date Author Modification Draft 1 12/11/09