Pleading for open modular architectures - Lirmm

Organization 

This first national workshop is aimed at addressing important aspects of robot control 

architectures, with a specific emphasis on software aspects. It brings together researchers and 

practitioners from universities, institutions and industries, working in this field. It intends to be a 

meeting to expose and discuss gathered expertise, identified trends and issues, as well as new 

scientific results and applications around software control architectures related topics, through 

plenary invited papers. It consists of 19 invited talks, and 2 round tables. 

This 2-day event has been co-organized by LIRMM 1 and DGA 2 . The organizing committee 

wishes to thank the following organizations for their financial support for the workshop: 

• LIRMM CNRS-UM2, 

• University of Montpellier 2 (UM2), 

• STICS Research Department of UM2, 

• Robotics Department of LIRMM. 

Steering Committee 

• David Andreu, LIRMM, University of Montpellier 2, France - andreu@lirmm.fr 

• Aurélien Godin, ETAS, DGA, France – aurelien.godin@dga.defense.gouv.fr 

Local Organization 

Web 

First National Workshop on Control Architectures of Robots - April 6,7 2006 - Montpellier 

• Céline Berger, LIRMM, France - berger@lirmm.fr 

• Robin Passama, LIRMM, University of Montpellier 2, France – passama@lirmm.fr 

• Stéphanie Belin, LIRMM, France - belin@lirmm.fr 

1 Laboratoire d’Informatique, de Robotique et de Microélectronique de Montpellier : http://www.lirmm.fr 

2 Délégation Générale pour l’Armement : http://www.defense.gouv.fr/dga/ 

4

Theme 


Due to their increasing complexity, nowadays intervention robots, that to say those dedicated for 

instance to exploration, security or defence applications, definitely raise huge scientific and 

commercial issues. Whatever the considered environment, terrestrial, aerial, marine or even 

spatial, this complexity mainly derives from the integration of multiple functionalities: advanced 

perception, planning, navigation, autonomous behaviours, in parallel with teleoperation or robots 

coordination enable to tackle more and more difficult missions. 

But robots can only be equipped with such functions if an appropriate hardware and software 

structure is embedded: the software architectures will hence be the main concern of this 

workshop. 

As quoted above, the control architecture is thus a necessary element for the integration of a 

multitude of works; it also permits to cope with technological advances that continually offer 

new devices for communication, localisation, computing, etc. As a matter of fact, it should be 

modular, reusable, scalable and even readable (ability to analyse and understand it). Besides, 

such properties ease the sharing of competencies among the robotics community, but also with 

computer scientists and automatics specialists as the domain is inherently a multidisciplinary 

one. 

Numerous solutions have been proposed, based on the "classical" three layers architecture or on 

more "modern" approaches such as object or component oriented programming. Actually, almost 

every robot integrates its own architecture; the workshop will thus be a real opportunity to share 

reflections on these solutions but also on related needs, especially standardization ones, which 

are of particular importance in military applications for instance. 

Hence, this first national workshop on control architectures of robots aims at gathering a large 

number of robotics actors (researchers, manufacturers as well as state institutions) in order to 

highlight the multiple issues, key difficulties and potential sources of advances. 

David Andreu Aurélien Godin 

LIRMM DGA 

Robotics Department Angers Technical Centre 

5

Contents 

Organization………………………………………………………………………...……………4 

Theme…………………………………………………………………………………….….……5 

Program………………………………………………………………………………………..…8 

Papers 


Session “Institutions” 

DGA-ETAS……………………………………………………………………………………...10 

Pleading for open modular architectures in robotics 

A. Godin, O. Evain. 

DGA-SPART……………………………………………………………………………………18 

Integrating human/robot interaction into robot control architectures for defence applications 

D. Dufourd, A. Dalgalarrondo. 

ONERA-CERT………………………………………………………………………………….37 

ProCoSA: a software package for autonomous system supervision 

M. Barbier, J.F. Gabard, D. Vizcaino, O. Bonnet-Torrès 

DGA-GESMA……………………………………………………………………….…………..48 

Goal driven planning and adaptivity for AUVs 

H. Ayreault, F. Dabe, M. Barbier, S. Nicolas, G. Kermet. 

IFREMER…………………………………………………………………….…………………56 

Advanced Control for Autonomous Underwater Vehicles 

M. Perrier. 

Session “Industrials” 

THALES…………………………………………………………………………………….…..64 

Compared Architectures of Vehicle Control System (Vetronics) and application to an UXV 

J.P. Quin. 

INTEMPORA………………………………………………………………………………...…72 

RT-MAPS: a modular software for rapid prototyping of real-time multisensor applications. 

N. Dulac. 

ECA……………………………………………………………………………………………...76 

DES (Data Exchange System), a publish/subscribe architecture for robotics 

C. Riquier, N. Ricard, C. Rousset. 

ROBOSOFT……………………………………………………………………………….……85 

Modular distributed architecture for robotics embedded systems 

P. Pomiers, V. Dupourqué. 

ECA (CYBERNETIX)………………………………………………………………………….….91 

Remote operation kit with modular conception and open architecture: the SUMMER concept 

L. Walle. 

6


Session “Academics” 

LVR – Université d’Orléans………………………………………………………………….100 

A multi-level architecture controlling robots from autonomy to teleoperation 

C. Novales, G. Mourioux, G. Poisson. 

LAAS-CNRS…………………………………………………………………………………..120 

LAAS architecture: Open Robots 

F. Ingrand. 

LISYC - Université de Bretagne Occidentale……………………………………………….121 

Architectures logicielles pour la robotique et sûreté de fonctionnement 

L. Nanatchamda. 

INRIA Rhône-Alpes…………………………………………………………………………..131 

Orccad, a framework for safe control design and implementation 

D. Simon, R. Pissard-Gibollet, S. Arias. 

LIRMM-CNRS – Université Montpellier 2 ……………………………………….………...145 

Overview of a new Robot Controller Development Methodology 

R. Passama, D. Andreu, T. Libourel, C. Dony. 

LIP6 - Université Pierre et Marie Curie Paris VI………………………..…………….……164 

An Asynchronous Reflection Model for Object-oriented Distributed Reactive Systems 

J. Malenfant. 

LST - Université de Technologie de Belfort-Montbéliard …...…………………………….183 

Reactive Multi-Agent approaches for the Control of Mobile Robots 

O. Simonin. 

VALORIA – Université Bretagne Sud ………………………………………………………192 

Horocol language and Hardware modules for robots 

D. Duhaut, C. Gueganno, Y. Le Guyadec, M. Dubois. 

CEMAGREF…………………………………………………………………………………..203 

A Real-Time, Multi-Sensor Architecture for fusion of delayed observations: Application to 

Vehicle Localisation 

C. Tessier, C. Cariou, C. Debain, F. Chausse, R. Chapuis, C. Rousset. 

List of speakers………………………………………………………………………….……..208 

List of participants…………………………………………………………………….………209 

7

Program 

April 6, 2006 

8:30-9:00 Reception (coffee) 

Welcome LIRMM-DGA 

9:00- 9:30 

F. Pierrot (LIRMM Assitant Director) 

R. Zapata (Robotics Department Manager) 

9:30-12:30 Session « Institutions » 

9:30-10:00 DGA-ETAS A. Godin 

10:00-10:30 DGA-SPART D. Dufourd 

10:30-11:00 Coffee Break 

11:00-11:30 ONERA-CERT M. Barbier 

11:30-12:00 DGA-GESMA H. Ayreault 

12:00-12:30 IFREMER M. Perrier 

12:30-14:00 Lunch 

14:00-16:30 Session « Industrials » 

14:00-14:30 THALES J.P. Quin 

14:30-15:00 INTEMPORA N. Dulac 

15:00-15:30 ECA C. Rousset 

15:30-16:00 ECA(Cybernetix) L. Walle 

16:00-16:30 Robosoft P. Pomiers 


17:00-18:30 

Round table 

« Software control architecture: trends and issues » 

20:00 Diner 

April 7, 2006 


8:30-9:00 Reception (coffee) 

9:00-12:00 Session « Academic » 

9:00-9:30 LVR C. Novales 

9:30-10:00 LAAS F. Ingrand 

10:00-10:30 LISYC L. Nanatchamda 


11:00-11:30 INRIA D. Simon 

11:30-12:00 LIRMM R. Passama 

12:00-14:00 Lunch 

14:00-14:30 LIP6 J. Malenfant 

14:30-15:00 UTBM O. Simonin 

15:00-15:30 VALORIA D. Duhaut 

15:30-16:00 CEMAGREF C. Tessier 


16:30-18:00 

Round table 

« Software robot control architecture: what’s going on ? » 

8


Session « Institutions » 

9


Pleading for open modular architectures 

Abstract— Since first researches in the field of robotics architectures, 

many advances have been achieved. Nowadays softwares 

offer modular functionalities, which interests will be reminded 

in section I, and actually satisfy most of the needs, as shown in 

section II. However, none of the mentioned approaches managed 

to spread widely or succeeded in gathering works developed 

by the very numerous robotics actors, not even those that can 

already be considered mature. We argue here that the port of 

these works from an architecture to another is a major difficulty 

and that only an effort towards standardisation can help to 

overcome this drawback. 

I. REASONS FOR DEFENDING MODULAR OPEN DESIGNS 

We here define the architecture as the structured 

organisation of components (or “framework”), embedded on a 

system, that enables their simultaneous and correct execution, 

by offering the basic services needed for all of them. In this 

paper, we will more specifically consider software aspects. 

Modularity will be defined as the ability, for this software, 

to receive new components that were not included in the 

original release, thus enabling, a posteriori, to extend its 

functionalities. It will be moreover “open” if interfaces for 

writing these modules are public, so that a person different 

from the developper that originally implemented the code 

can produce some. For instance, Linux is such a system, in 

which hardware drivers can easily be added by third parties. 

And so is Windows: these two characteristics are effectively 

not contradictory with commercial or property policies and 

do not mean that the original sources must be unveiled. 

Recent articles on architectures often insist on their modularity. 

This must not only be considered a “commercial” 

announce but, indeed, softwares that satisfy this property 

offer many interests. First of all, as they are able to receive 

all sorts of modules, provided that the latter respect the 

defined interfaces, they can potentially attract many robotic 

actors and their adoption is eased. The direct corollary of 

wide-spread architectures is to provide this users community 

with a common framework, enhancing the possibilities of 

sharing and exchanging competencies. As a matter of fact, 

it also enables to validate concurrent approaches in the same 

conditions/environment for more relevant comparison results. 

Besides, modularity permits to focus one’s development 

only on particular aspects, while working algorithms can be 

re-used. Hence, there is no need anymore, when conducting 

a specific research, to redevelop an entire system to test it, 

but one can take benefit of an already existing complete 

Aurélien Godin, Olivier Evain 

French Department of Defence 

Angers Technical Centre / Vetronics & Robotics Group 

{aurelien.godin,olivier.evain}@dga.defense.gouv.fr 

10 

framework, in which to integrate and evaluate one’s own work. 

But interests are not limited to these ones. Indeed, the 

vehicle (more generally the platform) in which the modular 

framework will be embedded will allow a fast integration 

of different modules or their easy replacement. This is particularly 

interesting for all users. Laboratories take benefit 

from the flexibility of such structures, manufacturers can 

easily provide updates or new functionalities to their clients. 

Finally, end-users, such as the Department of Defence, can 

both take advantage of such open-targets to support their 

research programmes and, depending of the mission needs, to 

get reconfigurable operational systems. Recently, the French 

Ground Army confirmed that the MiniRoC concepts of ground 

robots, see [10], presenting such modular characteristics, was 

of great interest as they would allow soldiers to only take with 

them the absolutely necessary modules related to their actual 

task. 

By extension, if on the one hand open architectures compel 

to conform to given software interfaces, on the other hand they 

make no assumptions as regarding to the underlying hardware. 

Such frameworks are, ideally, completely independent from 

platforms, processors or electronics. Said another way, they 

offer the possibility to evolve as technologies progress : it 

remains up-to-date. For end-users essentially, it is a guarantee 

of durability and, consequently, it requires to train maintainers 

only for one type of software. This durability is however 

achievable only by ensuring backward compatibility, so that 

modules running on older versions of the software can be 

executed in latest releases. 

For the sake of exhaustivity, the same arguments that 

talk in favour of modular architectures on a single robot 

also are valid when tackling the multi-robots context, as 

it will help to gather an un-predefined number of agents 

within a collaborating team. This property is then known as 

extensibility or scalability. 

Thus, from the above discussion, the main requirements for 

an architecture to be modular can be summarised as: 

• permit normalized data exchange through the definition 

of public interfaces and common communication mechanisms; 

• enable extensibility by making no assumptions on underlying 

platform or candidate peripheral hardware; 

• be flexible by making no assumptions on missions that


will be given to the robot, since new ones will irremediably 

be imagined during system’s life. 

As will be discussed in section II, many architectures 

developed for about twenty years satisfy these characteritics. 

Besides, whereas the framework nature - reactive, deliberative 

or hybrid - is often a central concern, we will note here that 

modularity is independent from this issue, and that it can be 

ensured in all cases. 

II. PREVIOUS WORK 

A. Evolution in architectures conception 

In the second half of the 80s’, Brooks introduced an 

architecture that can maybe be considered the first modular 

one, [7]. Contrary to common software structures at that time, 

which often used sequencial treatments to achieve an action, 

an organisation based on layers is proposed. Each layer can 

operate in parallel and corresponds to a particular task to be accomplished, 

see figure 1. Nowadays designs have inherited this 

point of view as modules often implement specific behaviours. 

However, in Brooks’ system, layers interactions are based on 

the subsumption principle (upper layers can block and replace 

outputs of lower ones) and not on a real standardized data 

exchange. This may bring to a complex links organisation. 

Enhanced exchange schemes are present in most following 

works. Modules become real “independent computational 

units”, executing concurrently and that can use given communication 

services, imposed by the architecture, to exchange 

information. Compared to the subsumption architecture, the 

level of competence (i.e., the priority of the module) is not 

fixed a priori since all the blocks are considered equal. The 

choice for the appropriate output can be made, depending on 

the implementation, by a global referee or another module 

written by the system designer. DAMN, [18], is a remarkable 

Fig. 1. Whereas traditional approaches presented a sequential organisation 

(above schema), Brooks proposed a structure where layers, often corresponding 

to a given level of competence, can execute in parallel and influence the 

global robot behaviour by subsuming outputs of lower ones. Figures are taken 

from [7]. 

11 

example of the first category. Each block, called “behaviour” 

in the sense of Brooks’, issues votes in favour of a specific 

possible action that are then collected by an arbiter (figure 2). 

The final effective command is, schematically, a weighted sum 

of these votes. 

Fig. 2. The DAMN architecture as described in [18]. 

Another famous approach is the one developed at 

GeorgiaTech by Arkin, [5]. The principles are close to those 

of DAMN: behaviours, here called “motor schemas”, provide 

their commands to a process that sums and normalizes them 

using the potential fields method. A sligth difference is however 

introduced since a homeostatic control system is added: 

this can be thought as a bus that collects state variables from 

robot internal sensors and broadcast them to all of the motor 

schemas. Resulting monitoring information are used both to 

influence internal parameters of behaviours and their relative 

weights. The structure is synthesized on figure 3. 

Fig. 3. AuRA principle. This figure both shows the fusion process between 

two motor schemas and the homeostatic control system that regulates the 

performance of the overall architecture. 

However, theoretically, modularity does not only apply to 

behaviours (i.e., reactive modules) but also to deliberative capabilities 

of robots. If the complete AuRA framework already 

integrates a planning component (as well as a layer responsible 

for user-robot interaction that can convey human decisions), 

the reasoning capacities are fixed once for all. But there exists 

practical cases for which these capacities are more flexible.


An army is a typical example of an efficient organisation in 

which deliberative agents are not gathered in a centralized 

structure, as each soldier is not only able to act but also 

to learn, acquire experience, and use complex reasonings to 

succeed in his elementary task. And a robot architecture is, in 

some way, comparable: in both cases, an upper objective (the 

goal of the robot or of the army) can be achieved by getting 

elementary agents (modules or men) to work in a coordinated 

fashion (i.e., respecting rules imposed by the architecture or 

the hierarchy). Such comparisons naturally lead to propose 

new robot frameworks, in which deliberative capacities, and 

not only reactive behaviours, are also designed in a modular 

manner. 

Albus’ researches on 4-D/RCS 1 have been conducted based, 

partly, on these reflexions and lead to a node-oriented architecture. 

Each elementary component, called a node, integrates 

sensory processings and reactive parts, like “classical” modules, 

but can also simultaneously gather modeling, learning and 

reasoning capabilities, as shown figure 4. Each node is then 

arranged within a global hierarchy modeled on the military 

structure. A natural way of implementing this architecture is to 

grant more deliberative responsibilities to nodes that are placed 

high in the hierarchy, whereas lower nodes are rather dedicated 

to information processing. Furthermore, by construction, this 

framework is multirobot-ready: from a macroscopic point of 

view, a robot can itself be considered a node and teams 

of robots can hence be constituted the same way nodes are 

structured inside each robot. More detailed explanations can 

be found in [2]. 

Fig. 4. A typical 4-D/RCS node. 

The emergence of modern programming methods, i.e. 

object-oriented (OO) approaches, hugely contributed to ease 

the implementation of the above concepts. Inheritance and 

related mechanisms (polymorphism, methods over-writing) 

are directly useful to derive efficient modules and permit 

to easily extend robots capacities, whereas the encapsulation 

of properties and methods enables objects to share only the 

useful interfaces. But these approaches did not only reveal 

1 4-D/RCS is the architecture that is embedded on the Demo III Experimental 

Unmanned Vehicle (XUV), a project supported by the American DoD. This 

probably explains the origin of the parallel between robots architecture and 

military organisation. 

12 

interesting for programmers but also inspired the conception 

of recent architectures. The most appealing one is probably 

CLARAty in which the whole functional layer is thought 

as a hierarchy of objects. A simple example is shown on 

figure 5, whereas very detailed explanations, including coding 

considerations, can be found in [19]. One interest of OOconception 

is to provide all the mechanisms to build proper 

extensible interfaces, without imposing any limitations on 

the way objects are internally implemented. COSARC is a 

very recent example of this trend: it uses an extension of 

OO-methods (the component-based approach) to define four 

types of components which internal structure is described with 

Petri Nets, please refer to [4] for details. This is a relevant 

illustration of the ability of object-based languages to both ease 

the development of open frameworks, satisfying modularity 

requirements, and take benefit from any other recognized 

approach for the modelisation of components behaviour, here 

Petri Nets. 

Fig. 5. This example illustrates the object-oriented design of the functional 

layer of CLARAty. Note that, like all moderns frameworks, it also provides a 

decision layer, not shown here. But although most other architectures split the 

executive and planning levels, these functionalities are here gathered within 

the same layer, for consistency reasons. See [20] for a discussion on this 

point. 

As noted above, the same requirements of modularity and 

extensibility are needed in the multi-robots context. Here, the 

main constraint is to enable the adjonction and the removal of 

agents within the team. If some architectures, like 4-D/RCS, 

inherently have the capacity to manage several robots, they 

should also tackle the “fault-tolerancy” problem. That is to 

say, the lost of a robot or of the communication channel, 

during the mission, must not induce the failure of the whole 

team. Most of the time, specific coordination schemes are 

thus added to the upper layers of the architectures and run all 

the processes needed to manage a team (especially scalability 

mechanisms, communication strategies and task allocation). 

Among all approaches proposed, let us quote ALLIANCE and

TABLE I 

TECHNOLOGY READINESS LEVELS 

Low maturity 

1 Basic principles of technology observed & 

reported 

2 Technology concept and/or 

application formulated 

3 Analytical and laboratory 

studies to validate analytical predictions 

Medium maturity 

4 Component and/or basic sub-system 

technology valid in lab environment 

5 Component and/or basic sub-system 

technology valid in relevant environment 

6 System/sub-system technology model or 

prototype demo in relevant environment 

High maturity 


7 System technology prototype demo in an 

operational environment 

8 System technology qualified 

through test & demonstration 

9 System technology ‘qualified’ through 

successful mission operations 

M+. The first one mainly focuses on determining an efficient 

fault-tolerant scheme: details can be found in [17]. The 

second one, [6], offers an alternative based on negociations 

between the robots. It has been successfully integrated in the 

LAAS-CNRS framework, [1], that hence provides a complete 

open architecture gathering all functionalities, from reactive 

behaviours to decisional capacities, for a lonely robot or a 

team of agents. 

Besides, all above quoted works do not remain pure theorical 

concepts. Many of them have been ported on some 

vehicles and proved to be relevant potential candidates for 

real applications. 

B. Introducing Technology Readiness Levels 

Technology Readiness Levels (TRLs) were initially created 

by NASA in 1995 and were officialy adopted by the American 

Ministry of Defence (MoD) in 2001. This referential aims 

at assessing the maturity of technologies so as to reduce 

the risks related to acquisition programmes. It consists of 

nine levels, of increasing maturity, that apply to individual 

technologies (not to entire systems). The TRLs grid, copied 

from [8], is given in table I. 

Nowadays results and experimentations show that levels 

5/6 can currently be reached. 4-D/RCS framework has thus 

been ported to the American XUV (Experimental Unmanned 

Vehicle) and its ability to host functionnal modules could be 

demonstrated. Besides, Albus’ report [3] comforts us in our 

evaluation of the maturity of this architecture when asserting 

13 

that “the tests are designed to determine whether the Demo 

III XUVs have achieved technology readiness level six”. 

In France, the same encouraging conclusions can be drawn. 

All along SYRANO 2 project, industrials have shown their 

ability to deploy a modular architecture (although proprietary) 

on a prototype tank and their capacity to incrementally add 

new functionalities when they become available. Demonstrations 

with this vehicle took place in the military camp of 

Mourmelon, in a quasi-operational context, as related in [16]. 

Because only teleoperated functions have been used, not all 

possibilities of the architecture have been extensively tested, 

and these demonstrations “only” correspond to the TRL-5. 

However, a vehicle such as Syrano is TRL-6-ready as, in 

theory, advanced autonomous modules can be added the same 

way. Moreover results achieved by some laboratories comfort 

this point of view. For instance, experiments conducted by 

LAAS-CNRS in autonomous navigation demonstrated the 

ability of a robot to automatically explore an unknown area. 

During these tests, all functionalities were used: planning, 

supervision, autonomous modules management as well as 

human-robot interfaces (at least to send mission reports and 

receive high level orders from the operator). The multi-robot 

scheme is itself under ‘validation’ as, in some current projects, 

additional aerial information is provided by a Blimp UAV to 

assist the robot in its navigation task. 

Since 2004, this laboratory has also been running a robot 

equipped with the same architecture, [1], in Cité de l’Espace, 

Toulouse. This robot serves as a guide for visitors, interacting 

with them to retrieve their questions, then conducting them to 

the desired point. Since people are obviously neither roboticians 

nor technicians, the environment of the robot can be 

considered operational. This experiment can maybe not claim 

the TRL-7 title, which would require huge reliability, but 

definitely proves that this level is now achievable. 

Of course, qualitatively judging the architecture, on an 

experiment that takes into account the whole system, is quite 

difficult and its exact contribution to the overall performance is 

hard to deduce. But at least, this means that services expected 

from the software are functional and that internal communications 

between framework components work. When, moreover, 

the architecture has been ported on heterogeneous systems 

(the SYRANO one was previously integrated on a robot jeep, 

called DARDS, and is reused for a future demining system), 

it can be argued that modularity and portability have been 

validated. In conclusion, based on the observation of above 

quoted experiments, giving TRL-6 as the current achieved 

maturity level seems relevant. 

Some complementary methods also exist to assess the 

maturity of a whole system, System Readiness Levels. A brief 

review of SRLs ([9] and table II) confirms that these vehicles 

have reached levels 6-7, meaning that demonstrations have 

been conducted successfully in representative environment. 

2 SYRANO is a teleoperated prototype vehicle, with simple autonomous 

behaviours, for reconnaissance and detection of potential adverse targets. It 

aims at evolving in open areas.

1 User requirements 

defined 

2 System requirements 

defined 

3 Architectural design 

refined 

TABLE II 

SYSTEM READINESS LEVELS 

4 Detailed design 

is nominally complete 

5 Sub-systems verification 

in laboratory environment 

6 Sub-system verification 

in representative integration environment 

7 System prototype demonstration 

in a representative integration environment 

8 Pre-production system completed and demonstrated 

in a representative operational environment 

9 System proven through successful 

representative mission profile 

Nevertheless, the previous section raises a major concern, 

as it shows that numerous architectures have been develop 

concurrently: if each one, separatly, does satisfy the modularity 

requirements, components developed for one of them cannot 

be ported to another. A higher level of specification is still 

missing that would ensure interoperability, a property of real 

importance, especially in a military context. Consequently, 

as upcoming programmes can not systematically rely on a 

standard, they only correspond to SRL-2. It is thus quite 

urgent to emphasize the research effort on this point, as will 

be discussed in section III. We will first focus on a relevant 

American example, JAUS, then present some French research 

programmes that tackle the issue. 

A. American proposals 


III. TOWARDS STANDARDISATION 

1) History: In the last 20 years, a large number of unmanned 

systems have been developed by US companies in 

response to the American DoD, but most of them are taskspecific 

and non-interoperable. Therefore, in 1994, JAUGS, 

an effort to avoid the pitfalls of “eaches” in an expanding 

domain, was initiated. It was still limited to ground systems 

(the “G” actually stands for “ground”). 

In 1998, OUSD (Office of the Under Secretary of Defence) 

chartered a working group, consisting of members from the 

government, industry and academia, to develop an architecture 

for unmanned systems. It set itself five targets: 

• support all classes of unmanned systems ; 

• advocate rapid technology insertion ; 

• provide interoperable Operating Control Units (OCUs) ; 

• provide interchangeable/interoperable payloads ; 

14 

• provide interoperable unmanned systems. 

The resulting Joint Architecture for Unmanned Systems 

(JAUS), available for use by defence, academic and commercial 

sectors, is an upper level design for the interfaces within 

the domain of unmanned vehicles. It aims at being independent 

from technology, computer hardware, operator use and vehicle 

platforms, and isolated from mission. It is a component based, 

message-passing framework that specifies data formats and 

methods of communication between computing entities of 

unmanned systems. 

Its final goal is to reduce development and integration 

times, ownership cost, and to enable an expanded range of 

vendors by providing a framework for technology insertion. 

2) JAUS specifications: to date, two documents describe the 

JAUS architecture: the Reference Architecture specification 

(RA), [13], and the Domain Model (DM), [12]. 

a) Domain model: the analysis conducted in the DM 

on the five above targets, along with the study of military 

contracts constraints, urged to define five main requirements 

on messages within the architecture. Indeed they need to be 

independent from: 1. vehicle platform, 2. mission, 3. computer 

resource, 4. technology and 5. operator use. This document is 

also a tool with which customers/users can define both near 

and far term operational requirements, for unmanned systems, 

based on mission needs; and by defining far-term capabilities, 

the JAUS Domain Model can actually be considered a “road 

map” for developers to focus research and design efforts to 

support these future requirements. 

In a word, the domain model is a common language which 

contains three distinct elements : functional capabilities (FC), 

informational capabilities (IC), and device groups (DG). The 

first ones, all documented in DM so that to ease dialog 

between users and developers, are a set of capabilities with 

similar functional purposes. Eleven categories are identified, 

that permit to describe the abilities of an unmanned system: 

command, manœuvre, navigation, communication, payload, 

safety, security, resource management, maintenance, training 

and automatic configuration. In parallel with the functional description, 

Informational Capabilities provide a representation 

Fig. 6. JAUS domain model representation.


of what unmanned systems (should) know. They are groupings 

of similar types of information. Five categories are depicted in 

DM: vehicle status, world model, library, logistics, time/date. 

Finally, device groups are a classification of sensors and/or 

effectors that are used for similar functions. Functional and 

informational capabilities may interface with device groups, 

but the JAUS domain model does not define these interfaces. 

Figure 6 summarises the DM representation. 

b) Reference architecture specification: in the development 

cycle, the specification of capabilities described in the 

DM will always precede those that appear in the RA, whose 

main purpose is to detail all functions and messages that 

shall be employed to design new components. All currently 

defined messages as well as rules that govern messaging are 

also depicted in this second document. It is worth noting 

that messaging is the sole accepted method to communicate 

between components. 

The RA specification comprises three parts. First of them, 

the architecture framework provides a description of the structure 

of JAUS-based systems. Actually, unmanned systems are 

seen as a hierarchical topology, shown on figure 7. A system 

is a logical grouping of one or more subsystems, which are 

independent and distinct units. A node, in such a topology, is a 

‘black-box’ containing all the hardware and software necessary 

to provide a complete service, for example a mobility or 

a payload controller. A component is the lowest level of 

decomposition in the JAUS hierarchy: it is an executable task 

or process. All the components, which may be found within 

an unmanned system, are listed in this first part of the RA. 

The above defined topology is very flexible since the only 

requirement is that a subsystem be composed of component 

software, distributed across one or more nodes. Interoperability 

between intelligent systems is achieved by defining functional 

components with supported messages. Therefore, the only 

constraint to be JAUS-compliant is that all messages that pass 

between components, over networks or via airwaves, shall be 

JAUS-compatible messages. No other rules are imposed to 

system engineers. Besides, messages coming from or/and sent 

to non-JAUS components can have their own protocol. 

The definition and the format of those messages are the 

objects of the second and the third parts of the RA. In the 

second one, message definition, different classes of messages 

(command, query, inform, event setup, event notification) and 

message composition (classically, a header and a data fields) 

are defined. Messaging protocol is also depicted with the 

routing strategy, the way to send large data messages, the way 

to establish a connection between two components, as well 

as some various messaging rules. The third and final part of 

the RA, Message Set, presents the details of command code 

usage for each message (the command code is an information 

included in the message header). 

c) Other documents: additional documents support the 

JAUS standards: a Document Control Plan (DCP) and the 

Standard Operating Procedures (SOP), [14]. The first one 

defines the process to update the JAUS DM and RA whereas 

the second one establishes the charter and organisation for 

15 

Fig. 7. The reference architecture from JAUS. 

the JAUS working group. A compliance plan, [11], transport 

plan and user’s handbook are under development. 

3) Conclusion on JAUS: JAUS is not an architecture, as 

defined at the beginning of this article. It is rather a process 

to ease communication between users and developers and to 

standardise exchanges of data within software embedded in an 

autonomous system. However, nowadays, JAUS is mandated 

for use by all of the programmes in the Joint Robotics Program 

(JRP), [15], and numerous American manufacturers begin 

to follow the requirements. For example, the EOD 3 Man- 

Transportable Robotic System (MTRS), PackBot, produced by 

IRobot, is JAUS-compliant. Moreover, JAUS is now recognized 

as a technical committee within the SAE, Aerospace 

Council’s Aviation Systems Division (ASD), which name is 

AS-4 Unmanned Systems. 

B. French government effort 

For several years now, French DoD has been preparing a 

number of studies to get standards to emerge, so that future 

architectures embedded in military demonstrators be ready for 

interoperability needs. In the ground robotics field, two major 

research programmes have been, or are about to be, launched. 

At the end of year 2005, the “Démonstrateur BOA” programme 

was notified to an industrial group (TGS: Thales, 

GIAT Industries, SAGEM). Roughly, BOA is the equivalent of 

the American Network Centric Warfare. It aims at proposing 

new organisations for ground forces (including aerial devices 

operating to their profit) with a high degree of interoperability 

between the different units, through advanced communication 

means. UGVs and mini-UAVS will naturally be part of this 

structure since they represent a privileged way to retrieve 

information, even during high-intensity actions, without exposing 

soldiers, enabling new combat strategies such as indirect 

firing, see figure 8. Missions which they should respond to are 

manifold and heterogeneous, from urban fighting, to logistics 

or reconnaissance. Hence, the challenge: 

3 explosive ordnance disposal


Fig. 8. Official illustration of the BOA concept, showing candidate systems, 

data exchanges between them and consequent achievable missions. 

• integrating unmanned vehicles communications in an 

already very constraint electromagnetic environment; 

• enabling information sharing between robots and with 

human units; 

• getting highly reconfigurable robots/UAVs so that they 

can quickly be adapted to the actual mission. 

The third point can only be achieved through the use of a 

modular architecture. Moreover, since BOA is still a prospective 

concept, all possible missions are probably not exhaustively 

identified; finally, some specific functions, dealing with 

autonomous capacities of ground vehicles, will be provided 

by other programmes, the actors of which are not necessarily 

involved in BOA. These two supplementary aspects imply that 

the software framework be also open, to allow the desired 

extensibility. But the second above point is maybe the most 

critical. The diversity of information sources, and the number 

of actors that will access them, then encourages to adopt 

standards for data exchanges. 

As a consequence, the DoD insisted on the architecture 

part of the robots and vehemently required that modularity 

be achieved at all levels (software as well as hardware), that 

interfaces be open and can be communicated to third parties. 

The interoperability constraints were tackled by explicitely 

asking for the adoption of a standard for data exchanges: 

JAUS, if obviously not imposed, was quoted as an acceptable 

solution, so that to clearly illustrate DoD expectations. Finally, 

it is worth noting that information provided by unmmanned 

vehicles are often of the same nature (localisation, detection 

or intelligence data) than those conveied by Battlefield 

Management Systems, that will be of primordial importance 

in BOA. Robots are then natural candidates to feed these 

systems and analyzing data structures used for the latter can 

also be a relevant source of inspiration. 

Although all previous examples are taken from ground 

robotics fields, the open modular architecture is actually an 

important subject for the near future UAV systems. Currently, 

the French DoD is conducting two studies in parallel. The aim 

16 

for both is: “definition of an open, standardised, modular and 

evolutionary architecture for a generic and interoperable UAV 

system”. 

The problematic of an UAV system is large and very complex 

because of the multiple interfaces including the onboard 

(aircrafts, payloads, airworthiness, air traffic management. . . ), 

ground (command, control and exploitation station, recovery, 

launch. . . ) and system (communications, certification, subsystem 

interfaces, real time synchronization, critical software. . . ) 

constraints. The studies cover, from the time being, the three 

different UAVs system categories: tactical, MALE (Medium 

Altitude Long Endurance) and HALE (High Altitude Long 

Endurance). The main technical axes of the studies can be 

summed up with the following: 

• define the best configurable and generic architecture; 

• improve the system’s performances regarding new hard 

or software technologies; 

• interchangeability of payloads within the “plug and play” 

concept; 

• obtain secure, certifiable and everlasting architecture. 

An “open, standardized, modular and evolutionary” 

architecture is the challenge for the future French UAV 

systems programmes. Thanks to this, the interoperability will 

exist throughout the UAV system’s total cycle life (15 to 20 

years). 

However, one can still argue that these efforts towards 

standardisation are limited either to ground or to aerial vehicles, 

and that one still lacks a federative framework. This is 

mainly the goal of the OISAU research programme. Initiated 

by ground robotics experts of the DoD, this study for “open 

and interoperable autonomous systems” actually introduces no 

assumptions concerning the type of the candidate platforms, 

that can either be aerian, ground or even marine vehicles. For 

the first time, it explicitely gathers within a lone coherent 

programme all the requirements presented above, asking that 

the resulting architecture enable : 

• platform and hardware independency; 

• cost reduction thanks to standardisation (thus allowing 

acquisition and maintenance savings); 

• easy integration and replacement of functional modules; 

• ability to incrementally proceed to these integration or 

replacement to allow systems evolution. 

This programme is probably of a primordial importance in 

an effort to get operational robots, that can be introduced in 

armed forces. 

IV. CONCLUSION 

Indeed, many reasons, technical, commercial or practical, 

lead to increase the modularity of robots architectures. Along 

the past ten years, a number of solutions has been proposed 

and open extensible frameworks are actually available to 

robots developers and users. Some of these concepts have even 

been successfully ported on real systems, demonstrating their 

relevance and maturity.


However, the robotics community still lacks a real federative 

standard to get unmanned systems interoperable. As a matter 

of fact, following the American JAUS example, and since 

interoperability is of crucial importance for the introduction 

of robots within armed forces, the French DoD has decided 

to support the development of new normative frameworks. 

Besides, this effort concerns all fields of robotics, from ground 

to aerial vehicles, and is at the heart of current research 

programmes. A major objective of these works is to increase 

the technology and system readiness levels, i.e. to get more 

mature and reliable robots. 

But, if modularity and standardisation are necessary conditions 

for architectures to meet all the above discussed 

requirements, they are not sufficient. Until now, robots are 

not completely autonomous systems and, even in the future, 

a supervisory control will be at least kept. Nevertheless there 

still remains work to determine which role humans deserve and 

which level of autonomy will be granted to robots. And the 

conclusions of such a work will impact the needed exchanges, 

data structures and interfaces that have to take place between 

the framework components. That is, the basic characteristics 

that enable modularity will deeply depend on the role of the 

human in unmanned systems. 

ACKNOWLEDGMENT 

We would like to thank Agnès Lechevallier, French DoD, 

for her contribution on the UAV part. 

Special thanks go to Jérôme Lemaire, head of our department, 

for his help and valuable advice on the content of this 

paper. 

Also note that research works quoted in this paper would 

probably deserve much more attention than the one that could 

be granted here. They have all bring relevant results, when no 

breakthrough, to the field of control architectures. Please refer 

to the original articles for details and in-depth discussions on 

their specificities. 

REFERENCES 

[1] R. Alami, R. Chatila, S. Fleury, M. Ghallab and F. Ingrand, An 

Architecture for Autonomy, International Journal of Robotics Research, 

17(4), April 1998. 

17 

[2] J.S. Albus, 4-D/RCS: A Reference Model Architecture for Demo III, NIS- 

TIR 5994, National Institute of Standards and Technology, Gaithersburg, 

MD, March 1997. 

[3] J.S. Albus, Metrics and Performance Measures for Intelligent Unmanned 

Ground Vehicles, in proceedings of the Performance Metrics for Intelligent 

Systems (PerMIS) workshop, 2002. 

[4] D. Andreu and R. Passama, COSARC: COmponent based Software 

Architecture of Robot Controllers, in proceedings of the CAR’06 workshop, 

Montpellier, April 2006. 

[5] R. Arkin and T. Balch, AuRA: Principles and practice in review, Journal 

of Experimental and Theoretical Artificial Intelligence, vol. 9, no. 2-3, 

pp. 175-188, 1997. 

[6] S.C. Botelho and R. Alami, M+: a scheme for multi-robot cooperation 

through negotaited task allocation and achievement, in proceedings of 

IEEE International Conference on Robotics and Automation, vol. 2, pp. 

1234-1239, Michigan, May 1999. 

[7] R.A. Brooks, A robust layered control system for a mobile robot, IEEE 

Journal of Robotics and Automation, vol. RA-2, no. 1, pp. 14-23, April 

1986. 

[8] Future Business Group, Technology Readiness Levels (TRLs) guidance, 

FBG/36/10, January 11th 2005. 

[9] Future Business Group, System maturity assessment using System Readiness 

Levels guidance, FBG/43/01/01, v3.2, February 16th 2006. 

[10] L. Gillet and Y.L. Lunel, Des robots pour assister le combattant 

débarqué en zone urbaine : les démonstrateurs MiniRoC, L’armement, 

no. 85, March 2004. 

[11] JAUS, The Joint Architecture for Unmanned Systems, Compliance 

Specification, v. 1.1, March 10th 2005. 

[12] JAUS, The Joint Architecture for Unmanned Systems, Domain Model, 

volume I, v. 3.2, March 10th 2005. 

[13] JAUS, The Joint Architecture for Unmanned Systems, Reference Architecture 

SPecification, volume II, parts 1-3, v. 3.2, August 13th 2004. 

[14] JAUS, The Joint Architecture for Unmanned Systems, Standard Operating 

Procedures, v. 1.5, October 10th 2002. 

[15] JRP, Joint Robotics Program, Master Plan, FY2005. 

[16] J.G. Morillon, O. Lecointe, J.-P. Quin, M. Tissedre, C. Lewandowski, 

T. Gauthier, F. Le Gusquet and F. Useo, SYRANO: a ground robotic 

system for target acquisition and neutralization, in proceedings of SPIE 

Aerosense, Unmanned Ground Vehicle Technology V, vol. 5083, pp. 

38-51, September 2003. 

[17] L.E. Parker, ALLIANCE: An Architecture for Fault Tolerant Multi-Robot 

Cooperation, IEEE Transactions on Robotics and Automation, vol. 14, 

no. 2, pp. 220-240, 1998. 

[18] J.K. Rosenblatt, DAMN: A Distributed Architecture for Mobile Navigation, 

in proceedings of the 1995 AAAI Spring Symposium on Lessons 

Learned from Implemented Software Architectures for Physical Agents, 

H. Hexmoor & D. Kortemkamps (Eds.), Menlo Park, CA:AAAI Press. 

[19] R. Volpe, I.A.D. Nesnas, T. Estlin, D. Mutz, R. Petras and H. Das, 

CLARAty: Coupled Layer Architecture for Robotic Autonomy, technical 

report, Jet Propulsion Laboratory, December 2000. 

[20] R. Volpe, I.A.D. Nesnas, T. Estlin, D. Mutz, R. Petras and H. Das, The 

CLARAty architecture for robotic autonomy, in proceedings of IEEE 

Aerospace Conference, Montana, March 2001.


Integrating human / robot interaction into robot control 

architectures for defense applications 

Delphine Dufourd a and André Dalgalarrondo b 

a DGA / Service des Programmes d’Armement Terrestre 

10, Place Georges Clemenceau, BP 19, 92211 Saint-Cloud Cedex, France 

b DGA / Centre d’Essais en Vol, base de Cazaux 

BP 416, 33260 La Teste, France 

ABSTRACT 

In the near future, military robots are expected to take part in various kinds of missions in order to assist 

mounted as well as dismounted soldiers: reconnaissance, surveillance, supply delivery, mine clearance, retrieval 

of injured people, etc. However, operating such systems is still a stressful and demanding task, especially when 

the teleoperator is not sheltered in an armoured platform. Therefore, effective man / machine interactions and 

their integration into control architectures appear as a key capability in order to obtain efficient semi-autonomous 

systems. This article first explains human / robot interaction (HRI) needs and constraints in several operational 

situations. Then it describes existing collaboration paradigms between humans and robots and the corresponding 

control architectures which have been considered for defense robotics applications, including behavior-based teleoperation, 

cooperative control or sliding autonomy. In particular, it presents our work concerning the HARPIC 

control architecture and the related adjustable autonomy system. Finally, it proposes some perspectives concerning 

more advanced co-operation schemes between humans and robots and raises more general issues about 

insertion and a possible standardization of HRI within robot software architectures. 

Keywords: Ground robotics, human robot interaction, control architectures, defense applications, reconnaissance 

robot. 

1. INTRODUCTION 

Given recent advances in robotics technologies, unmanned ground systems appear as a promising opportunity for 

defense applications. In France, teleoperated vehicles (e.g. AMX30 B2DT) will soon be used for mine breaching 

operations. In current advanced studies launched by the DGA (Délégation Générale pour l’Armement i.e. the 

French Defense Procurement Agency) such as PEA Mini-RoC (Programme d’Etudes Amont Mini-Robots de 

Choc) or PEA Démonstrateur BOA (Bulle Opérationnelle Aéroterrestre), robotics systems are considered for 

military operations in urban terrain as well as in open environments, in conjunction with mounted or dismounted 

soldiers. To fulfill the various missions envisionned for unmanned platforms, the needs for human / robot 

interaction (HRI) increase so as to benefit from the orthogonal capacities of both the man and the machine. 

In section 2, we list several missions considered for military land robots and explain related issues concerning 

HRI. In section 3, we present an overview of existing paradigms concerning HRI and describe a few existing 

applications in the field of defense robotics. In section 4, we focus on an example concerning reconnaissance 

missions in urban warfare and present the work on the HARPIC architecture performed at the Centre d’Expertise 

Parisien of the DGA. Finally, in section 5, we raise more general questions about the introduction of HRI into 

control architectures and about a potential standardization of these interactions, before concluding in section 6. 

2.1. Missions for military robots 

2. OPERATIONAL CONTEXT 

Unmanned ground systems can now be considered as key technologies for future military operations. Firstly, 

they remove humans from harms way by reducing their exposition on the battlefield. Moreover, they can provide 

various services and avoid humans dull, dirty or difficult tasks such as surveillance or heavy load carrying. More 

generally, in the future, they should be used as force multipliers and risk reducer in land operations. 

Further author information: 

D.D.: E-mail: delphine.dufourd@dga.defense.gouv.fr, phone: +33 (0)1 47 71 45 86 

A.D.: E-mail: andre.dalgalarrondo@dga.defense.gouv.fr, phone: +33 (0)5 57 15 47 62 

18


Figure 1. A prospective view of future French network centric warfare. 

As a result, the range of missions for unmanned ground systems in the defense and security field is widening. 

Among them, let us mention reconnaissance and scout missions, surveillance, target acquisition and illumination, 

supply delivery, mule applications, obstacle clearance, remote manipulation, demining, explosive ordnance 

disposal, retrieval of injured people, communication relays, etc. These missions include different time steps from 

planning and deployement, mission fulfilment with human supervision and possible re-planning to reployment 

and maintenance, as well as training sessions. They take place on various terrains, ranging from structured urban 

environments to destructured (destroyed) places and ill-structured or unstructured open areas. Moreover, defense 

operations present a few specificities compared to civil applications. Unmanned vehicles will often have to deal 

with challenging ill-known, unpredictable, changing and hostile environments. In urban warfare for instance, 

robots will face many incertainties and they will have to intermix with friends, foes and bystanders. As a partner 

or as an extent of a warfighter, a robot must also conform to different constraints and doctrines: he must neither 

increase the risk for the team – which stands for ”surprise effect” cancelling and trap triggering for instance – 

nor impose an important workload to the human supervisor. Moreover, some decisions such as engaging a target 

cannot be delegated to a robot: it is crucial that man stay in the loop in such situations. Finally, robots will be 

inserted into large organizations (systems of systems designed for network-centric warfare – cf. Fig. 1) and will 

have to co-operate with other manned or unmanned entities, following a command hierarchy. Therefore, efficient 

and scalable man / machine collaboration appears as a necessity. 

2.2. Why introduce HRI into military operations ? 

On the one hand, it is desirable that robots should operate as autonomously as possible in order to reduce the 

workload of the operator and to be robust to communication failures with the control unit. For example, rescue 

operations at the World Trade Center performed using the robots developped for the DARPA (U.S. Defense 

Advanced Research Projects Agency) TMR (Tactical Mobile Robotics) program showed that it was difficult for 

a single operator to ensure both secure navigation for the robot and reliable people detection. 1 

On the other hand, technology is not mature enough to produce autonomous robots which could handle 

the various military situations on their own. Basic capacities that have been shown on many robots include 

obstacle detection and avoidance, waypoint and goal oriented navigation, detection of people, detection of threats, 

information retrieval (image, sound), localization and map building, exploration or coordination with other 

robots. Most of them can be implemented on a real robot with a good reliability in a reasonably difficult 

environnement but it is not enough to fulfill military requirements. For instance, so far, no robot has been able 

to move fully autonomously in the most difficult and unstructured arenas of the NIST (US National Institute 

of Standards and Technologies) in the context of search and rescue competitions. 2 Moreover, some high-level 

doctrines and constraints (such as discretion) may be difficult to describe and formalize for autonomous systems. 

Finally, humans and robots have complementary capabilities 3 : humans are usually superior in perception 

(especially in environment understanding), in knowledge management and in decision making while robots can 

be better than humans in quantitative low-level perception, in precise metric localization and in displacement 

in confined and cluttered space. Above all, robots can stand dull, dirty and dangerous jobs. Therefore, it seems 

19


that today’s best solutions should rely on a good collaboration between humans and robots e.g. when robots act 

as autonomously as possible but remain under human supervision. 

2.3. What kind of HRI is needed for military operations ? 

The modalities concerning human / robot interaction may vary depending on the situation, the mission or 

the robotic platform. For instance, during many demining operations, the teleoperation of the robot could be 

performed with a direct view of the unmanned vehicle. However, the teleoperation of a tracked vehicle like the 

French demonstrator SYRANO (Système Robotisé d’Acquisition et de Neutralisation d’Objectifs) is performed 

with an Operator Control Unit (OCU) set up in a shelter which could be beyond line of sight if the transmission 

with the robot is ensured. In urban environment, the dismounted soldier in charge of the robot may need to 

protect himself and to operate the robot under stressful conditions either in close proximity or at a distance 

varying from a few meters to hundreds of meters. Concerning the effectors and the functions controlled by the 

human / robot team, some missions could imply precise remote manipulation with a robotic arm or the use of 

specific payloads (pan / tilt observation sensors, diversion equipments such as smoke-producing devices...) while 

others would only include effectors for the navigation of the platform. Finally, some missions may be performed in 

a multi-robot and multi-entities context, using either homogeneous or heteregenous vehicles, with issues ranging 

from authority sharing to multi-robot cooperation and insertion into network-centric warfare organizations. 

Therefore, defining general HRI systems for robots in defense applications may be quite challenging. 

3. EXISTING HUMAN / ROBOT INTERACTION SYSTEMS 

3.1. Overview of existing paradigms for HRI 

Many paradigms have been developed for human robot interaction. They allow various levels of interaction with 

different levels of autonomy and dependance. To introduce our work concerning the HARPIC architecture as 

well as related work in the defense field, we attempt to briefly list below the main paradigms from the least 

autonomous (teleoperation) to the most advanced (mixed-initiative) where humans and robots can co-operate 

to determine their goals and strategies. 

Teleoperation is the most basic and mature mode. In this mode the operator has full control of the robot 

and must assume total responsibility for mission safety and success. This mode is suitable in complicated or 

unexpected situations which no algorithm can deal with. In return this mode often means a heavy workload for 

the teleoperator who needs to focus his attention on the ongoing task. With Supervisory control 4 the operator 

(called the supervisor) orders a subordonate (the robot) to achieve a predefined plan. In this paradigm, the 

robot is merely a tool executing tasks under operator monitoring. This interaction mode can adapt to low level 

bandwith and high level control but needs constant vigilance from the operator who must react in case of failures 

(to perform manual mission re-planning for example). This mode is only suitable for static environments where 

planning is really effective. Behavior-based teleoperation 5 replaces fine-grained control by robot behaviors which 

are locally autonomous. In comparison to supervisory control, this paradigm brings safety and provides the 

robot with the opportunity to react to its own environment perception (e.g. to avoid obstacles). Thus, it allows 

the operator to be more negligent. Adjustable autonomy 6 refers to the adjustment of the level of autononomy 

which has been initiated by the operator, by another system or by the system himself and while the system 

operates. The goal of this paradigm is generally to increase the negligence time allowed to the operator while 

maintaining the robot to an acceptable safety and effectiveness level. In Traded control 7 the operator controls 

the robot during one part of the task and the robot behaves autonomously during the other part of this task. 

This paradigm may lead to an equivalent of the kidnapped robot problem. While the robot is controlled by the 

operator, it can loose its situation awareness and face difficulties when coming back to autonomous control. In 

Shared control, 8 part of the robot functions are autonomous and the remaining are controlled by the operator. 

It is important to notice that this mode requires constant attention from the operator. If the robot is only in 

charge of some safety mechanisms, this paradigm is equivalent to the safeguarded teleoperation. Mixed-initiative 9 

is characterized by a continuous dialogue between the operator and the robot where both of them share decision 

and responsibility. Collaborative control 10 may be described as a restrictive implementation of mixed-initiave. 

In this approach, the human robot dialogue is mainly reduced to a predefined set of questions and answers. 

All this paradigms may be considered as subsets of the human / robot teaming domain with important 

overlapping. Therefore, many robotic experimentations use a mix of these paradigms, including our work on 

HARPIC and related projects described in the next section. 

20


3.2. Existing applications concerning defense applications 

Most applications for military unmanned ground vehicles are based on existing control architectures and the 

HRI mechanisms often reflect this initial approach. Most of these architectures are hybrid, but some of them 

are more oriented towards the deliberative aspect while others focus mostly on their reactive components. As 

a result, HRI mechanisms are sometimes more oriented towards high level interaction at the planning phase 

(deliberative) while others tend to be more detailed at the reactive level. 

For instance, the small UGV developed by the Swedish Royal Institute of Technology 11 for military operations 

in urban terrain is inspired from the SSS (Servo, Subsumption, Symbolic) hybrid architecture. The individual 

components correspond to reactive behaviors such as goto, avoid, follow me, mapping, explore, road-follow and 

inspect. During most tasks, only a single behavior is active but when multiple behaviors are involved, a simple 

superposition principle is used for command fusion (following the SSS principles). The activation or desactivation 

of a behavior seems to be achieved using the planning realized before the mission. The interface is state-based 

(modeled as a simple finite automata) so that the user can choose a task from a menu and make simple use 

of simple buttons to control a task. However, the authors do not describe precisely the planning module (the 

deliberative level) nor its relationship with the direct activation of behaviors (more reactive). Thus, it seems 

that the stress has been laid on the lower levels of the architecture (Servo, Subsumption). 

The software architecture of the US Idaho National Engineering and Environmental Laboratory (INEEL), 

which has been tested by the US Space and Naval Systems Center in the scope of the DARPA TMR (Tactical 

Mobile Robotics) project, 12 was partially inspired by Brooks’ subsumption architecture, which provides a 

method for structuring reactive systems from the bottom up using layered sets of rules. Since this approach 

can be highly robust in unknown or dynamic environments (because it does not depend on an explicit set of 

actions), it has been used to create a robust routine for obstacle avoidance. Within INEEL’s software control 

architecture, obstacle avoidance is a bottom-up layer behavior, and although it underlies many different reactive 

and deliberative capabilities, it runs independently from all other behaviors. This independance aims at reducing 

interference between behaviors and lowering overall complexity. INEEL also incorporated deliberative behaviors 

which function at a level above the reactive behaviors. Once the reactive behaviors are “satisfied”, the deliberative 

behaviors may take control, allowing the robot to exploit a world model in order to support behaviors such as 

area search, patrol perimeter and follow route. These capabilities can be used in several different control modes 

available from INEEL’s OCU (and mostly dedicated to urban terrain). In safe mode, the robot only takes 

initiative to protect itself and the environment, but allows the user to otherwise drive the robot. In shared mode, 

the robot handles the low-level navigation, but accepts intermittent input, often at the robot’s request, to help 

guide the robot in general directions. In autonomous mode, the robot decides how to carry out high-level tasks 

such as follow that target or search this area without any navigational input from the user. Therefore, this system 

can be considered as a sliding autonomy concept. 

The US Army Demo III project is based on the reference architecture 4D-RCS designed by the NIST (based 

on the German 4D and on the NIST former RCS architectures) which allows a decomposition of the robot 

mission planning into numerous hierarchical levels. 13 This architecture can be considered as hybrid in the sense 

that it endows the robot with both reactive behaviors (in the lower levels) and advanced planning capabilities. 

Theoritically speaking, the operator can explicitely interact with the system at any hierarchical level. The 

connections to the OCU should enable a human operator to input commands, to override or modify system 

behavior, to perform various types of teleoperation, to switch control modes (e.g. automatic, teleopration, single 

step, pause) and to observe the values of state variables, images, maps and entity attributes. This operator 

interface could also be used for programming, debugging and maintenance. However, in the scope of the Demo 

III program, only lower levels of the architecture have been fully implemented (servo, primitive and autonomous 

navigation subsystems) but they led to significant autonomous mobility capacities tested during extensive field 

exercises at multiple sites. 14 The OCUs feature touch screens, map-based display and context-sensitive pulldown 

menus and buttons. They also propose a complete set of planning tools as well as built-in mission rehearsal 

and simulation capabilities. In the future, the NIST and the Demo III program managers intend to implement 

more tactical behaviors involving several unmanned ground vehicles, thus adressing higher levels of the 4D-RCS 

hierarchy. This will enable the developers to test effectively the scalability and modularity of such a hierarchical 

architecture. 

The German demonstrator PRIMUS-D, 15 dedicated to reconnaissance in open terrain, is also compatible 

with the 4D/RCS achitecture. The authors provide various details about the data flows between subsystems, 

which gives indications about the way HRI components could interact and be linked with robot subsystems. 

Within PRIMUS OCU, all in- and outputs are organized in the segment “Man-Machine Interface” which enables 

the operator to perform mission planning, command and control of the vehicle. Inputs from the operator flow to a 

“coordination” segment which performs mainly plausibility checks, command management and command routing. 

21


Commands or entire mission plans are transmitted to the robot vehicle by the segment “communication”, if 

“coordination” decides that the command could be executed by the robot. An additional software module called 

“payload” manages the RSTA payload. Concerning the outputs from the robot, “communications” forwards 

received data depending on the data type to coordination (robot state information) or to “signal and video 

management”. On the robot side, command systems are received by a “communication” segment and forwarded 

to “coordination” for plausibility checks. If the command can be executed by the robot, the command will be 

pipelined to the next segment: either “payload” if it concerns the RSTA module or “driving” and “perception” 

if it is related to the navigation of the platform. The PRIMUS robot can be operated according to five modes: 

autonomous driving with waypoint navigation, semi-autonomous driving (with high-level commands such as 

direction, range and velocity), remote control (assisted with obstacle detection and collision avoidance), road 

vehicle and autonomous vehicle following. It can thus be considered as an adjustable autonomy concept, including 

simple or behavior-based teleoperation and autonomous modes. However, it is unclear how modular the system 

is and how new capabilities could be added to the system. 

In the scope of the DARPA MARS (Mobile Autonomous Robotic System) program, Fong, Thorpe and Baur 

have developed a very rich HRI scheme based on collaborative control where humans and robots work as partners 

and assist each other to achieve common goals. So far, this approach has been mainly applied to robot navigation: 

the robot asks human questions to obtain assistance with cognition and perception during task execution. An 

operator profile is also defined so as to perform autonomous dialog adaptation. In this application, collaborative 

control has been implemented as a distributed set of modules, connected by a message-based architecture. 10 The 

main module of this architecture seems to be the safeguarded teleoperation controller which supports varying 

degrees of cooperation between the operator and the robot. Other modules include an event logger, a query 

manager, a user adapter, a user interface and the physical mobile robot itself. 

Finally, concerning multirobot applications, the DARPA TMR program also led to the demonstration of 

multirobot capabilities in urban environment based on the AuRA control architecture, in relation with the MissionLab 

project. 16 This application relies on schema-based behavioral control (where the operator is considered 

as one of the available behaviors for the robots 17 ) and on a usability-tested mission specification system. The 

software architecture includes three major subsystems: 1) a framework for designing robot missions and a means 

for evaluating their overall usability; 2) an executive subsystem which represents the major focus for operator 

interaction, providing an interface to a simulation module, to the actual robot controllers, to premission specification 

facilities and to the physical operator ground station; 3) a runtime control subsystem located on each active 

robot, which provides an execution framework for enacting reactive behaviors, acquiring sensor data, reporting 

back to the executive subsystem to provide situation awareness to the team commander. A typical mission starts 

with a planning step through the MissionLab system. This mission is compiled through a series of langages that 

bind it to a particular robot (Pioneer ou Urbie). It is then tested in faster than real-time simulation and loaded 

to the real robot for execution. During execution, a console serves as monitor and control interface: it makes it 

possible to intervene globally on the mission execution (stop, pause, restart, step by step...), on the robot groups 

(using team teleautonomy, formation maintenance, bounding overwatch, by directing robots to particular regions 

of interest or by altering their societal personality), and on the individual robots (activating behaviors such as 

obstacle avoidance, waypoint following, moving towards goals, avoiding enemies, seeking hiding places, all cast 

into mission-specific assemblages, using low-level software or hardware drivers such as movement commands, 

range measurement commands, position feedback commands, system monitoring commands, initialization and 

termination). The AuRA architecture used in this work can be regarded as mostly reactive: this reactivity 

appears mainly through the robot behaviors while other modules such as the premission subsystem look more 

deliberative (but they seem to be activated beforehand). 

To conclude about these various experiences, most of these systems implement several control modes for 

the robot, corresponding to different autonomy levels: it seems that a single HRI mode is not sufficient for the 

numerous tasks and contexts military robots need to deal with. Most of them are based on well-known architectures 

(some of these architectures were originally designed for autonomous systems rather than semi-autonomous 

ones), leading to various HRI mechanisms. However, it is still difficult to compare all these approaches since 

we lack precise feedback (except for the few systems which were submitted to – heterogeneous but – extensive 

performance evaluations, e.g. teleoperation / autonomy ratio for Demo III, 18 MissionLab’s usability tests 19 or 

urban search and rescue competitions 20 ) and since they address different missions and different contexts (monorobot 

vs multi-robot, urban terrain vs ill-structured environments, etc.). Moreover, it is hard to assess their 

scalability and modularity in terms of HRI: for instance, does the addition of a new HRI mode compell the developer 

to modify large parts of the architecture, do they allow easy extensions to multi-robot and multi-operator 

configurations ? 

22


In the next section, we will describe our work on the HARPIC architecture so as to illustrate and give a 

detailed account of an adjustable autonomy development: this description will raise more general issues about 

scalability and modularity, thus leading to open questions concerning the insertion of HRI within robot software 

architectures. 

4. PRESENTATION OF OUR WORK ON HARPIC 

In November 2003, the French defense procurement agency (Délégation Générale pour l’Armement) launched 

a prospective program called “PEA Mini-RoC” dedicated to small unmanned ground systems. This program 

focusses upon platform development, teleoperation and mission modules. Part of this program aims at developing 

autonomous functions for robot reconnaissance in urban terrain. In this context, the Centre d’Expertise Parisien 

(CEP) of the DGA has conducted studies to demonstrate the potentialities of advanced control strategies for 

small robotic platform during military operations in urban terrain. Our goal was not to produce operational 

systems but to investigate several solutions on experimental platforms in order to suggest requirements and to 

be able to build specifications for future systems (e.g. the demonstrator for adjustable autonomy resulting from 

PEA TAROT). 

We believe that in short term robots will not be able to handle some uncertain situations and that the most 

challenging task is to build a software organization which provides a pertinent and adaptative balance between 

robot autonomy and human control. For a good teaming, it is desirable that robots and humans share their 

capacities along a two-way dialogue. This is the approximate definition of the mixed-initiative control mode but, 

given the maturity of today’s robots and the potential danger for soldiers, we do not think that mixed-initiative 

could be the solution for now. Therefore adjustable autonomy, with a wide range of control modes – from basic 

teleoperation to even limited mixed-initiative – appears as the most pragmatic and efficient way. 

Thus, based on previous work concerning our robot control architecture HARPIC, we have developped a man 

machine interface and software components that allow a human operator to control a robot at different levels of 

autonomy. In particular, this work aims at studying how a robot could be helpful in indoor reconnaissance and 

surveillance missions in hostile environment. In such missions, a soldier faces many threats and must protect 

himself while looking around and holding his weapon so that he cannot devote his attention to the teleoperation 

of the robot. Therefore, we have built a software that allows dynamic swapping between control modes (manual, 

safeguarded and behavior-based) while automatically performing map building and localization of the robot. It 

also includes surveillance functions like movement detection and is designed for multirobot extensions. 

We first explain the design of our agent-based robot control architecture and discuss the various ways to control 

and interact with a robot. The main modules and functionnalities implementing those ideas in our architecture 

are detailed. Some experiments on a Pioneer robot equipped with various sensors are also briefly presented, as 

well as promising directions for the development of robots and user interfaces for hostile environment. 

4.1. General description of HARPIC 

HARPIC is a hybrid architecture (cf. figure 2) which consists in four blocks organized around a fifth: perception 

processes, an attention manager, a behavior selector and action processes. The core of the architecture (the fifth 

block) relies on representations. 

Sensors yield data to perception processes which create representations of the environment. Representations 

are instances of specialized perception models. For instance, for a visual wall-following behavior, the representation 

can be restricted to the coordinates of the edge detected in the image, which stands for the wall to follow. 

To every representation are attached the references to the process which created it: date of creation and various 

data related to the sensor (position, focus...). The representations are stored with a given memory depth. 

The perception processes are activated or inhibited by the attention manager and receive information on the 

current behavior. This information is used to foresee and check the consistency of the representation. The attention 

manager has three main functions: it updates representations (on a periodical or on an exceptional basis), 

it supervises the environment (detection of new events) and the algorithms (prediction/feedback control), and it 

guarantees an efficient use of the computing resources. The action selection module chooses the robot’s behavior 

depending on the predefined goal(s), the current action, the representations and their estimated reliability. 

Finally, the behaviors control the robot’s actuators in closed loop with the associated perception processes. 

The key ideas of this architecture are: 

• The use of sensorimotor behaviors binding perceptions and low-level actions both internally and externally: the 

internal coupling allows to compare a prediction of the next perception (estimated from the previous perception 

and the current control) with the perception obtained after application of the control, in order to decide whether 

23


activation 

inhibition 

communication 

agent 

distant 

agents 

attention 

events 

behavior 

manager 

selection 

agent agent 

errors 

perception 

agents 

sensors 

representations 

current action 

behavior 

action 

selection 

agents 

actuators 

Figure 2. Functional diagram of the HARPIC architecture. 

the current behavior runs normally or should be changed; the external coupling is the classic control loop between 

perception and action. 

• Use of perception processes with the aim of creating local situated representations of the environment. No 

global model of the environment is used; however less local and higher level representations can be built from 

the instantaneous local representations. 

• Quantitative assessment of every representation: every algorithm is associated with evaluation metrics which 

assign to every constructed representation a numerical value expressing the confidence which can be given to it. 

We regard this assessment as important feature since any processing algorithm has a limited domain of validity 

and its internal parameters are best suited for some situations only. There is no perfect algorithm that always 

yields “good” results. 

• Use of an attention manager: it supervises the execution of the perception processing algorithms independently 

from the current actions. It takes into account the processing time needed for each perception process, as well as 

the cost in terms of computational resources. It also looks for new events due to the dynamics of the environment, 

which may signify a new danger or opportunities leading to a change of behavior. It may also trigger processes 

in order to check whether the sensors operate nominally and it can receive error signals coming from current 

perception processes. It is also able to invalidate representations due to malfunctioning sensors or misused 

processes. 

• The behavior selection module chooses the sensorimotor behaviors to be activated or inhibited depending on the 

predefined goal, the available representations and the events issued from the attention manager. This module is 

the highest level of the architecture. It should be noted that the quantitative assessment of the representations 

plays a key role in the decision process of the behavior selection. 

4.2. HARPIC implementation 

Fundamental capacities of our architecture encompass modularity, encapsulation, scalability and parallel execution. 

To fulfill these requirements, we decided to use a multi-agent formalism which fits naturally our need for 

encapsulation into independent, asynchronous and heterogeneous modules. The communication between agents 

is realized by messages. Object oriented languages are therefore absolutely suited for programming agents: we 

chose C++. We use POSIX Threads to obtain parallelism: each agent is represented by a thread in the overall 

process. For us, multi-agent techniques is an interesting formalism and although our architecture could be 

implemented without them it led to a very convenient and scalable framework. 

All the agents have a common structure inherited from a basic agent and are then specialized. The basic 

agent can communicate by sending messages, has a mailbox where it can receive messages and runs its own 

process independently from orther agents. Initially, all present agents have to register to a special agent called 

the administrator which records all information about agents (name, type, representation storage address...). All 

these data can be consulted by any agent. Then, when an agent is looking for another one for a specific job to 

24


do, it can access to it and to its results. It is for example what is happening when an action agent has to use a 

representation coming from a perception agent. 

Perception and action agents follow the global scheme. The action agent is activated by a specific request 

coming from the behavior selection agent. The selection agent orders him to work with a perception agent by 

sending its reference. The action agent sends in turn a request to the proper perception agent. Perception 

agents are passive, they only run upon request, perform a one shot execution and then wait for a new message. 

Furthermore, a perception agent can activate another agent and build a more specific representation using its 

complementary data. Many action and perception agents run at the same time but most are waiting for messages. 

Only one behavior (composed of a perception agent and an action agent) is active at the same time. Within 

a behavior, it is up to the action agent to analyze representations coming from the perception agent and to 

establish the correct control orders for the platform. 

The attention agent supervises the perception agents. It has a look-up table where it can find the types 

of perception agents it has to activate depending on the current behavior. It is also in charge of checking the 

perception results and of declaring new events to the behavior selection agent when necessary. The advantage 

of this organization is detailed in a previous paper. 21 

The selection agent has to select and activate the behavior suited for the robot mission. This agent may be 

totally autonomous or constitute the process that runs the human computer interface. In this work, it is the 

second case and this agent is detailled in paragraph 4.4. 

We use two specific agents to bind our architecture to hardware. The first one is an interface between the 

software architecture and the real robot. This agent awaits a message from an action agent before translating 

the instructions into comprehensible orders for the robot. Changing the real robot requires the use of a specific 

agent but no change in the overall architecture. The second agent acquires images from the grabber card at a 

regular rate and stores them in computer memory which can be consulted by perception agents. 

Finally, we use a specific agent for IP communication with distant agents or other architectures. This agent 

has two running loops: an inner loop in which it can intercept messages from other agent belonging to the same 

architecture, and an external loop to get data or requests from distant architectures. This agent surpervises the 

(dis)appearance of distant agents or architectures. It allows the splitting of an architecture on many computers or 

the communication between several architectures. For example, this agent is useful when agents are distributed 

between the robot onboard computer and the operator control unit. 

4.3. Agents for SLAM and path planning 

Map building is performed by a perception agent that takes laser sensor data and odometry data as input and 

outputs a representation which contains a map of the environment made of registered laser scans. The map 

building technique used combines Kalman filtering and scan matching based on histogram correlation. 22 This 

agent is executed whenever new laser data are available (e.g. 5 Hz), but it adds data to the map only when the 

robot has moved at least one meter since the last map update. 

Localization is performed by a perception agent that takes odometry, laser data and the map representation 

as input and outputs a representation containing the current position of the robot. In its current implementation, 

this agent takes the position periodically estimated by the mapping algorithm and interpolates between these 

positions using odometry data to provide anytime position of the robot. This agent is executed upon request by 

any other agent that has to use the robot position (e.g. mapping, planning, human computer interface...). 

Finally, path planning is carried out by an action agent that takes the map and position representations as 

inputs and outputs motor commands that drive the robot toward the current goal. This agent first converts the 

map into an occupancy grid and using a value iteration algorithm it computes a potential that gives for every 

cell of the grid the length of the shortest path from this cell to the goal. The robot movements are then derived 

using gradient descent on this potential from the current robot position. The path planning agent is used in the 

Navigation control mode of the operator control unit (described below). 

4.4. HCI agent 

In this implementation, our human computer interface is a graphical interface managed by the behavior selection 

agent of HARPIC. It is designed to use a small touch-screen of 320x240 pixels such as the one that equipped 

most personal digital assistant (PDA). With this interface, the user has to select a screen coresponding to one of 

the control mode he wants to activate or a screen showing the environement measures and representations built 

by the robot. These screens are described below. 

The Teleop screen corresponds to a teleoperation mode where the operator controls the translational and the 

rotational speed of the robot (see figure 3 (left)) by defining on the screen the end of the speed vector. The 

25


Figure 3. Interface for laser-based (left), image-based (center) teleoperation and goal navigation (right). 

Figure 4. Image screen in normal (left) and in low-light condition (right) with overlaid polygonal view. 

free space measured by the laserscanner can be superimposed on the screen and it appears in white color. The 

operator can also activate anti-collision and obstacle avoidance functions. Messages announcing obstacles are 

also displayed. This screen allows full teleoperation of the robot displacement (with or without seeing it thanks 

to the laser free space representation) as well as safeguarded teleoperation. As a result the operator has full 

control on the robot in order to trade with precise movement in cluttered space or with autonomous mobility 

failure. In return, he must keep defining the robot speed vector otherwise it stops and waits. A functionnality 

related to the reflexive teleoperation 12 concept also enables the operator to activate behaviors depending on the 

events detected by robot. Indeed, clicking on “wall” or “corridor” messages appearing on the screen makes the 

system trigger “wall following” or “corridor following” behaviors, thus activating a new control mode. 

The Image screen allows to control the robot by pointing at a location or defining a direction within the 

image acquired by the onboard robot camera. As the previous mode, this one enables full control or safeguarded 

teleoperation for the robot displacement. Two sliders operate the pan and tilt unit of the camera. When the 

GoTo XY function is enabled, the location selected by the operator in the image is translated into a robot 

displacement vector by projection onto the ground plane with respect to the camera calibration and orientation 

angles. The Direction function moves the robot when the operator defines the end of the speed vector on the 

26


Figure 5. Interface for agent (left), program (center) and robot (right) selection. 

screen. The selectable Laser function draws a polygonal view of the free space in front of the robot (in an 

augmented reality way) which is built from the projection of the laser range data in the image. This “Tron-like” 

representation allows to control the robot in the image whenever there is no sufficient light for the camera. 

Incidentally, this function provides a visual checking of the good correspondance between the laser data and the 

camera data. Figure 4 illustrates the effect of this function. If the GoTo XY or Direction functions are not 

enabled and if the robot is in any autonomous mode, this screen can be used by a operator to supervise the 

robot action by viewing the images of the onboard camera. However, it can stop the robot in case of emergency. 

The Navigation screen shows a map of the area already explored by the robot. In this control mode, the 

operator has to point out at a goal location in the map to trigger an autonomous displacement of the robot 

up to this goal. The location can be changed dynamically (whenever the previous goal has not been reached). 

The planning process is immediate (a few seconds). When new areas are discovered the map is automatically 

updated. As shown in figure 3 (right), the map is an occupancy grid where bright areas correspond to location 

which have been observed as free more often than darkest area. Three sliders can translate or zoom the displayed 

map. This is an autonomous control mode where the operator can select a goal and forget the robot. 

The Agents screen allows the composition and the activation of behaviors by selecting an appropriate pair 

of perception and action agents (see fig. 5 (left)). For example, it allows to execute behaviors like obstacle 

avoidance, wall following or corridor following with different perception or action agents (each one corresponding 

to a specific sensor or algorithm) for a same behavior. For example, a wall following behavior can result from a 

perception agent using the camera, from another one using the laserscanner and from various algorithms. This 

control mode corresponds to the behavior-based teleoperation paradigm. However this screen has been mainly 

designed for expert users and development purpose. It lacks simplicity but it will be easily reduced to a small 

number of buttons when the most effective behaviors set will be determined. 

The Prog screen corresponds to predefined sequences of behaviors. For example, it enables the robot to 

alternate obstacle avoidance and wall or corridor following when respectively an obstacle, a wall or a corridor 

appears in the robot trajectory (see fig. 5 (center)). This example is a kind of sophisticated wander mode. More 

generally, this mode allows automous tasks that could be described as a sequence of behaviors like exploration or 

surveillance where observation and navigation behaviors are combined. The list of these sequences can be easily 

augmented to adapt the robot to a particular mission. In this control mode, the robot is autonomous and the 

operator workload could be null. 

A MultiRobot screen allows the operator to select the robot which will be controlled by his control unit. 

Indeed, our interface and sofware architecture is designed to adress more than one robot. In a platoon with 

many robots this capacity may give way to the sharing of each robot data or representation and to the exchange 

of robot control between soldiers. 

The Local Map and Global Map screens show the results of the SLAM agents described in 4.3 (see fig. 6 (left 

and center)). The first one is a view of the free zone determined on each laser scan. The second one displays 

27

Figure 6. Interface for local map (left), global map (center) and moving object detection (right). 

the global map of the area explored by the robot and its trajectory. The circle on the trajectory indicates the 

location where the SLAM algorithm has added new datas. The current position of the robot is also shown on the 

map. As on some others screens, sliders allow the operator to translate and to zoom the display. These screens 

may be used when the robot is in any autonomous mode to supervise its movements. 

The Detection screen displays moving objects trajectory in the map built by the robot (see fig. 6 (right)). 

This screen stands for surveillance purpose. The algorithm used is based on movement detection on laser range 

data and Kalman filtering. This screen shows that this interface is not limited to displacement control of the 

robot but is able to be extended to many surveillance tasks. 

The transition between any autonomous or teleoperation screens causes the ending of the current action or 

behavior. These transitions have been designed to appear natural to the operator. However, when one of these 

modes is actived, it is still possible to use the screens that display robot sensors data or representations without 

disactivating them. This feature is valid for the operator control unit but also for other control units. Thus, 

in a soldier team images and representations from a given robot can be viewed by a team member that is not 

responsible for the robot operation. 

4.5. Experimentation 


The robot we used both in indoor and outdoor experiments is a Pioneer 2AT from ActivMedia equipped with 

sonar range sensors, color camera (with motorized lens and pan-tilt unit) and an IBEO laser range sensor. On 

board processing is done by a rugged Getac laptop running Linux and equipped with IEEE802.11 wireless link, 

frame grabber card and Arcnet card for connection to the laser (cf. figure 7). We also use another laptop with the 

same wireless link that plays the role of the operator control unit. The agents of the robot control architecture 

are distributed on both laptops. We did not use any specialized hardware or real-time operating system. 

Several experiments have been conducted in the rooms and corridors of our building and have yielded good 

results. In such an environment with long linear walls or corridors, the automous displacement of the robot 

using the implemented behaviors is effective. However, in this particular space, a few limitations for the SLAM 

process have been identified. They mainly come from the laser measurement when the ground plane hypothesis 

is not valid and in the presence of glass surfaces. 

The largest space we have experimented so far was the exhibition hall of the JNRR’03 conference. 23 Figure 

8 shows the global map and the robot trajectory during this demonstration. It took place in the machine-tool 

hall of the Institut Français de Mécanique Avancée (IFMA) and in the presence of many visitors. As could be 

seen on figure 8, these moving objects introduced some sparse and isolated edges on the map but did not disturb 

the map building process. The robot travelled an area about 60 × 60 m large with loops and abrupt heading 

changes. The robot displacement was mainly done in the safeguarded teleoperation mode because the building 

lacked main structures and directions for the robot to follow and because of the presence of people. 

28

Figure 7. The experimental platform. 

These experiments have revealed some missing functions in our interface (e.g. in mission map initialization, 

manual limitation of the space map, goto starting point behavior...) but no deep change requirement in the 

software architecture have been discovered. 

4.6. Future work 


Our human computer interface runs on a PC laptop with Linux and Qt C++ toolkit for the graphic interface. 

It is currently being implemented on a PDA with Linux and Qtopia environment. Moreover, new functions and 

behaviors are being integrated onto the platform such as exploration, go-back-home and assistance in narrow 

space crossing like doors. More mission-oriented behaviors such as surveillance and people or vehicle recognition 

would also enhance our system and make it more directly suited to operational contexts. In the meantime, we 

keep improving existing behaviors to make them as robust as possible. Development of extended multirobot 

capacities, interaction and cooperation are also planned as a second step. 

Concerning HRI, beyond considerations about ergonomy and usability of the interface, we consider working 

on semi-autonomous transition mechanisms between the various control modes, thus extending the simple 

reflexive teleoperation functionnalities described above. These transitions could be triggered by changes in the 

environment complexity for instance: knowing the validity domain of the behaviors, it seems possible to activate 

more adapted behaviors, to suggest a switch towards another mode 24 or to request the help of the human 

operator. This would also lead to more sophisticated interaction modes such as cooperative control. On-line 

evaluation of the overall performance of behaviors or autonomy modes 24 also appears as a promising direction, 

all the more so as such evaluation mechanisms are already integrated within our architecture. 25 

Finally, it could be interesting to introduce more direct human/robot interactions for the various kinds of 

agents (beyond the interface agent). Perception agents might benefit from human cognition in order to confirm 

object identification for instance. Action agents might request human assistance when the robot cannot deal 

autonomously with challenging environments, while the attention agent could be interested by new humandetected 

events which would warn the robot about potential dangers or opportunities. 

5. PERSPECTIVES AND OPEN ISSUES 

The various HRI mechanisms existing in the litterature, including our work on HARPIC, raise many general 

questions. For instance, generally speaking, how can we modify existing control architectures so as to introduce 

efficient HRI ? What features would make some architectures more adapted to HRI than others ? What kind of 

HRI is supported by existing architectures ? Is it possible to conceive general standard architectures allowing 

any kind of HRI ? What about scalability and modularity for HRI mechanisms ? Which HRI modalities can be 

considered as most efficient within defense robotics applications ? All these questions can still be considered as 

open issues. However, based on the examples described in the previous sections and on the recent advances in 

software technologies, we can provide a few clues concerning these topics. 

29

Figure 8. Map and robot trajectory generated during a JNRR’03 demonstration in the IFMA hall. Each circle on the 

robot trajectory represents the diameter of the robot which is about 50 cm. 

5.1. HRI within a robot control architecture 

5.1.1. HRI modes 


Humans and robots have different perception, decision and action abilities. Therefore, it is crucial that they 

should help each other in a complementary way. Depending on the autonomy control mode, the respective roles 

of the man and the robot may vary (see 26 for instance for a description of these roles according to the control 

mode). However, in existing interaction models, humans define the high-level strategies which are almost never 

transmitted to the robot: in the most advanced cases, the robot only knows task schedules or behaviors he must 

execute. 

We have already described eight different HRI modes in section 3.1. Some variants such as safeguarded 

teleoperation or reflexive teleoperation could also be mentionned. Moreover, other approaches have been proposed 

to characterize autonomy, e.g. ALFUS 27 or ANS, 28 which could lead to other HRI mode definitions. 

In the context of military applications, we have seen that adjustable autonomy can be considered as a promising 

mode. However, adjustable autonomy can lead to various mechanisms concerning control mode definitions 

and transition mechanims between modes: these complicated issues are currently being addressed in the scope 

of PEA TAROT (Technologies d’Autonomie décisionnelle pour la RObotique Terrestre) for example. 

5.1.2. Functions and functional levels concerned by HRI 

Any function of the robot may be concerned by HRI, whether it be perception, decision or action. In any 

architecture, a human robot interface can theoretically replace any component receiving information and sending 

commands. However, in many cases, it is not meaningful to make such a replacement since some of these 

components can be dealt with (automated or computed) by machines very effectively. Indeed, the control of a 

mobile robot can globally operate at three different functional levels. At the lower level, it represents a direct 

control on effectors with sensory feedback and/or a direct view on the robot (teleoperation). At the next level, 

30


the operator is in charge of the selection of tasks or behaviors. The upper level corresponds to the supervision 

where the operator takes part in the mission planning and monitors its execution. Depending on the design 

approach (respectively reactive, behavioral or deliberative), a control architecture can be modified in order 

to integrate a specific HRI operating either on the actuator commmands, on the behaviors or on the mission 

planning/execution. This order might be difficult to bypass. For instance, on a very deliberative architecture 

including a planning module dedicated to the robot management, it would not be desirable that a HRI could 

enable an operator to intervene at the actuator or the behavior level (if the latter exists). Indeed, it might 

seriously disturb the planning execution (leading to the kidnapped robot syndrom). 

Thus, within some architectures, interaction with other agents is only allowed at the highest levels. For 

instance, an extension of the three-tier architecture to the RETSINA MAS 2 only plans communications with the 

high-level reasoning layer. In specific contexts such as HRI in close proximity, the LAAS is currently developing 

sophisticated and dedicated interaction mechanisms (based on common human/robot goals) within the decisional 

layer of its architecture. 29 In DORO control architecture, 30 the user can interact with the higher module (the 

executive layer) during the planning phase (posting new goals, modifying planning parameters or the generated 

plan, etc.) and with the middle functional layer during the executive phase (e.g. deciding where the rover has 

to go or when some activities should stop). Nevertheless, the operator is not supposed to communicate with 

the lower physical layer. On the other hand, in simple reactive architectures like DAMN, command arbitration 

allows behaviors as diverse as human teleoperation and robot autonomous safety modules to co-exist. 31 Finally, 

in a hybrid architecture such as Harpic, where behavior chaining or planning are only considered as an advice, 

there is no major obstacle to the introduction (or the modification) of an HRI at any functional level. In 

general hierarchical architectures like NASREM, 32 4D/RCS 13 or 3T, 6 HRI is also planned at every level so 

that autonomous behaviors can possibly override human commands or conversely be interrupted through human 

intervention. 31 

Moreover, we can notice that hybrid architectures seem well adapted to the insertion of HRI thanks to the 

concept of sensorimotor behaviors, which are usually quite meaningful for humans. These behaviors also look 

like the “elementary actions” of the soldiers, which also makes them good candidates for defense applications. 

5.1.3. Human / robot interfaces 

Human / robot interfaces are key components of semi-autonomous robots and they can be considered as part 

of their architecture. Roughly speaking, interfaces must provide the operator with information (or raw measurements) 

collected by the robot sensors and allow him to send orders. The semantic level of information and 

commands may vary but today, they are still inferior to those currently manipulated by humans. The interface 

can however display global and high-level information built by other human actors (such as the tactical situation). 

More details can be found in 26 for instance concerning classical basic and additional services for human / 

robot interfaces. 

5.2. Constraints and limitations for the HRI design 

5.2.1. Security constraints 

In any given architecture, it seems possible (and sometimes necessary) to replace, double or duplicate a component 

(receiving information and sending commands) by a human/robot interface in the case when the human operator 

expertise or responsability is not possible to avoid, for instance to ensure people and goods security. For instance, 

a robot must not endanger people in its vicinity. 

5.2.2. Technical constraints about communication bandwidth and real time 

Every functional level can be associated with a frequency concerning order exchange and information feedback 

between the human operator and the robot, especially within dynamic environments. For instance, to control 

an actuator level using a video feedback, the communication flow between the human and the robot must be 

important and very steady. On the other hand, a control at the mission planning level can accomodate sparse and 

even irregular communications with low bandwidth. The choice of the software and hardware communication 

technologies between the interface and the command receiver/information provider systems will depend on this 

constraint. 

31


5.2.3. Constraints concerning ergonomics and human capacities 

In the multirobot case or more generally when robots outnumber humans, it is not conceivable that robots should 

only be controlled at the actuator level since human operators will suffer from a heavy workload. Higher level 

commands (at the behavior or mission levels) are necessary. Moreover, it might be useful to reduce (filter) the 

information provided to the interfaces (e.g. within limited reality concepts) and to endow robots with autonomous 

behaviors so that they can carry on the mission on their own when they have not received any order. 

The notion of user profile could be also used to adapt the content of an interface as well as its level of 

control so that it becomes better suited to a given human operator. 10 This process may refer to adaptation 

to the operator preferences, capacities or states (using pulse monitoring, temperature...). The interface should 

also adapt to the environment, e.g. by simplifying displays, showing only the most important information in 

emergency situations or selecting the information depending on the context. 

5.2.4. Harware constraints 

At the hardware level, a human / robot interface is made both of an information output and order input device. 

The standardization constraint of an interface will mainly lie in the fact that one must avoid to use devices 

whose integration and ergonomy have not been specifically designed and adapted to a particular application 

such as a pilot joystick containing all degrees of freedom and buttons corresponding to the robot functions. In 

the near future, the most standard interface will probably composed of a keyboard and a screen (tactile screen) 

or possibly a simple joystick. A specific interface can be simulated by a standard one (i.e. a tactile screen), 

despite a reduced ergonomy and probably a decreasing efficacity of the operator when sending orders. 

5.2.5. HRI dependence from missions, platforms, payloads and interface devices 

Concerning general HRI modes, independence seems quite challenging since context may induce very different 

HRI needs. For instance, dismounted soldiers will probably not be able to bear as much workload as mounted 

soldiers sheltered in an armoured control unit. They may also operate in close vicinity with the robot which 

will lead to specific collaboration schemes due to security reasons for instance (which might be similar to service 

robotics approaches) while remote operation of robot will imply other relationships with the robot, with awareness 

problems similar to those encountered urban search and rescue (USAR) challenges. 

Each mission and each environment can be associated to specific platform, payload and HRI device categories. 

In a dynamic and hostile environment, a dismounted soldier should use a simple, intuitive and small 

interface, which will be quite different from the one used by his unit commander in his command and control 

shelter. However, all these equipments can be built based on the same software technologies and on common 

communication interfaces. 

5.3. New software technologies for HRI 

Like usual systems in everyday life, military systems are evolving from very centralized computing towards 

distributed computing. Future warriors will be equiped with numerous sensors, will wear “smart” clothes and 

will team with various semi-autonomous systems. They will rely on technologies such as “ubiquitous, ambient 

and pervasive computing”. Well-accepted and efficient computing needs to be context-sensitive, taking into 

account individual, collective as well as social dimensions. 

Generally speaking (beyond robotic applications), multi-agent systems (MAS) enable coordination between 

distributed operations, creation of open systems with increasing complexity and increasing abstraction levels. 

This paradigm was developed around notions such as autonomy, interaction, organization and emergence to 

emphasize the relationship between the user and the system. Practically speaking, MAS combine several emerging 

technologies: distributed computing such as “grid-computing” (investigating how to use distributed and 

dynamically accessible computing resources in an efficient way), artificial intelligence, constrained programming, 

learning, data mining, planning, scheduling and web semantics. Thus, MAS make it possible to move from a 

traditional, centralized, closed and passive structure to a decentralized, open and pro-active conception. They 

are characterized by notions such as extensibility, portability, robustness, fault or failure tolerance and reliability. 

Real-time issues as well as complex, constrained and embedded systems are still not fully adressed in the 

MAS community. However, agents can be created to adress specific capabilities. Concerning real-time issues, 

numerous studies propose anytime algorithms providing results which are all the more satisfying as the algorithm 

execution time increases. These algorithms can be interrupted anytime, the quality of the result depending on 

the time allocated to their execution. Within HARPIC, this capability has been implemented using several 

agents dedicated to the same task, corresponding to algorithms with different costs. The selection of a specific 

agent thus depends on the available computing time and on its cost. 25 

32


As a result, it seems that the numerous capacities and technologies involved in MAS are well suited to new operationnal 

concepts such as network-centric warfare, where humans and manned systems are supposed to interact 

with semi-autonomous and robotic entities. The multi-agent paradigm also appears as an interesting framework 

for the development of robot control architectures designed for defense applications. Indeed, multi-agent systems 

enable to build bottom-up applications, without being constrained with evolving technical requirements. The 

conception of military systems (or systems of systems) whose life cycle may turn out to be long could thus benefit 

from the multi-agent paradigm. Indeed, agents can be considered as services which can be used by the system 

depending on its current needs. 

Multi-threading and object-oriented languages can also facilitate the development of software architecture for 

robots, especially in a multi-agent framework. Beyond the similarity between the object and the agent concepts, 

the object-oriented language C++ has allowed us to develop common structures for agent hierarchies, inheriting 

from mechanisms such as communication by messages between the agents. For example, without resorting to 

multi-agent systems, the conceptors of the CLARAty architecture (considered as NASA future architecture) have 

also opted for an object-oriented approach in order to facilitate code reusability and extension. 33 Indeed, this 

approach favors a hierarchical an modular decomposition of the system at different levels of abstraction. For 

instance, a class can provide a locomotion fonction which will be more and more specialized as it comes closer 

to the effectors (wheels, tracks...). This approach could also favour a hierarchical decomposition of the HRI, 

depending on the precision of the information or orders exchanged between both entities. 

As for most parts of the software architecture, the development of HRI mechanisms will probably rely on 

various tools and tool sets. These tools are likely to be unified within integration platforms including both 

architecture and environment and containing all the necessary functionalities to create interfaces and interaction 

modes, ranging from specification assistance to simulation and validation tools (see 16 for instance). 

5.4. HRI scalability 

Scalability can be viewed as an extension capability avoiding: 

• extensive studies concerning the design of the architecture when adding new functionalities; 

• incompatibilities, disturbances or dead-lock between system components; 

• reduced performances which could be due to coordination issues between the system components or to communication 

bottlenecks. 

To tackle (and possibly solve) this problem, military organizations rely on specialized yet adaptive unities for 

every activity (based on human adaptation capabilities), communication and local negociation or re-organization 

capabilities for every component, as well as a strong hierarchy wherein orders and reports flow rapidly. 

Specialization, communication and hierarchy are quite easy to reproduce on software systems. Adaptation 

(including learning), negociation and re-organization remain more open issues. Some of these capabilities have 

been developed for communication purposes for example, where QOS (quality of service) or transmission bandwidth 

are negociated depending on the quality of the medium. They are also at the core of an emblematic 

advanced project by IBM concerning “Autonomic Computing”, where a MAS-based system aims at delegating 

to software systems part of their own management, using self-healing and self-analysing agents. Moreover, agent 

hierarchization and priorizing mechanisms have already been implemented on MAS, which appear as a promising 

paradigm in terms of adaptation, negociation and re-organization. Indeed, such capabilities are part of the 

motivations for creating MAS. 

Concerning the information or the representations which are to be manipulated within future large systems 

and systems of systems (containing both humans and robots), it seems difficult today to plan everything in 

advance. It should be possible to define the detail level for every entity. The information which could be delivered 

by entities of higher, similar or lower hierarchical ranks should be submitted to queries and answers, according 

to context-dependent rules or hierarchical decisions. One could thus envision future military network-centric 

systems as some kinds of web-services endowed with hierachical rights and improved security. 

5.5. HRI standardization 

Current design approaches concerning robot software architectures may not exploit the full possibilities for HRI 

(e.g. a given architecture may not adapt to any HRI mode): the emergence of reference and standardized architectures 

might help to reduce these specificities. Moreover, standards for architectures and for associated HRI 

would probably facilitate the extension of current systems, the specification and development of new architectures 

as well as the validation of their design. 

33


However, HRI standardization goes beyond the simple fact of using standard technologies. It requires modular 

conception and component scalability as well. Thus, important issues remain regarding HRI design. Is it 

possible to build generic logical views of control architecture with associated HRI components, including the 

communication mechanisms between these components ? Is there a limitation in this standardization taking into 

account the wide range of missions for robots or the various HRI modes ? 

Concerning the specific components that should appear in generic logical views of architectures including HRI, 

it seems that depending on the approach, new components may arise. For instance, in the context of service 

robotics, LAAS has defined interaction agents (representing interacting humans at the robot decisional level) as 

well as task delegates (monitoring task execution towards the goal and the level of engagement of interaction 

agents through specific observors). 29 In the case of Fong’s approach about collaborative control, 3 specific 

segments have also been added such as a query manager or a user adapter. The challenge would thus consist in 

building views which would remain general enough to avoid specific solutions (related to specific contexts) and 

at the same time that would remain detailed enough so as to be useful during the specification, developement 

and validation phases of new architectures. 

At the software level, the standardization of human / robot interfaces including communication with surrounding 

systems is not very different from the standardization of any human / machine interface communicating 

with a wider application: this subject has been extensively studied in the field of distributed computing. For 

instance, the 3-tier architecture aims at dividing an application into three layers : a presentation layer, a processing 

layer and a data access layer. The presentation layer, i.e. the display and the dialog with the user can 

be based on HTML (using a web navigator) or on WML (using a GSM). Architectures such as SOAP (service 

oriented architectures), which have become popular through Web-services, make it posible to create services 

(software components with a strong inner coherence) with weak external coupling. These architectures rely on 

standards such as XML (Extensible Markup Language) for data description, WSDL (Web Services Description 

Language) for the description of service interfaces, UDDI (Universal Description Discovery and Integration) for 

service index management and SOAP (Simple Object Access Protocol) for service calling. 

In military information systems, standards (16 or 22 links, MIDS...) have already been developed to exchange 

numerical messages, concerning tactical situations for instance. In MAS, interaction languages between agents 

have been specified within the multi-agent community, e.g. KQML or ACL (Agent Communication Language) 

from the FIPA (Foundation for Intelligent Physical Agents). 

These technologies and the associated mechanisms could be used for software standardization purposes, for 

instance within networks where robots would interact with human operators and various other systems. It seems 

that these standards could also be considered as references for future HRI purposes in the defense field. 

For example, in a very prospective approach, similarly to common approaches used in the web-services, could 

it be interesting to integrate a service index at the battlefield network level, allowing the negociation of services 

between all entities? Will we see robots and soldiers naturally sharing information, helping each other to do 

their job and fulfill their mission ? 

6. CONCLUSION 

In this article, we first listed some operational missions which could involve unmanned vehicles and explained 

various needs for HRI. In the next section, we mentionned a few robotic systems designed for military applications 

and described the HRI component within their software architectures. Then we presented our work concerning 

the development of an effective software enabling to control a reconnaissance robot: we have created a robot 

control architecture based on a multiagent paradigm which allows various levels of autonomy and interaction 

between an operator and the robot. According to the state of the art in robot autonomy in hostile environment 

we think that adjustable autonomy is one of the most pertinent choice for the next generation of military robots. 

Our work shows that many control modes with seamless transitions can be fairly integrated in a quite simple 

operator control unit. It has also confirmed the good behavior of our software architecture HARPIC and the great 

advantage of the flexible multiagent approach when adding many functions. Moreover, this kind of interface is a 

good mean to experiment, evaluate or demonstrate autonomous robot behaviors and HRI, which will hopefully 

allow us to gather more military requirements and to improve the specification of future systems. Finally, based on 

the lessons learned from the development of this software architecture and from other related work, we discussed 

more general issues concerning the adaptation of existing architectures to HRI and the possible standardization of 

HRI within reference architectures. We also proposed a few guidelines for the practical development of softwares 

for architectures which would be suited to HRI. 

To conclude, military contexts offer a wide range of situations for robots and tackling these issues could 

lead to numerous innovations in the field of HRI. Even though some of these problems are currently addressed 

34


in prospective programs launched by the DGA such as PEA Mini-RoC, PEA TAROT or PEA Demonstrateur 

BOA, there is still a major effort to be done in order to meet tomorrow needs. 

ACKNOWLEDGEMENTS 

The work concerning HARPIC was entirely performed within the Geomatics-Imagery-Perception department of 

the Centre d’Expertise Parisien of the DGA. The authors would like to thank S. Moudere, E. Sellami, N. Sinegre, 

F. Souvestre, D. Lucas, R. Cornet, G. Calba, C. Couprie and R. Cuisinier for their contributions to the software 

development of this work. They are also very grateful to D. Filliat, M. Lambert, E. Moline and D. Luzeaux 

who shared their reflexions about autonomy and human / robot interaction and helped to improve the HARPIC 

system. 

REFERENCES 

1. S. Pratt, T. Frost, A. M. Shein, C. Norman, M. Ciholas, G. More, and C. Smith, “Applications of tmr 

technology to urban search and rescue: lessons learned at the wtc disaster,” in SPIE AeroSense, Unmanned 

Ground Vehicle Technology IV, (Orlando, USA), 2002. 

2. I. R. Nourbakhsh, K. Sycara, M. Koes, M. Yong, M. Lewis, and S. Burion, “Human-robot teaming for 

search and rescue,” in Pervasive Computing, 2005. 

3. T. Fong, C. Thorpe, and C. Baur, “Collaboration, dialogue, and human-robot interaction,” in Proceedings 

of the 10th International Symposium of Robotics Research, (Lorne (Victoria, Australia)), November 2001. 

4. P. Backes, K. Tso, and G. Tharp, “The web interface for telescience,” in IEEE International Conference on 

Robotics and Automation, ICRA’97, (Albuquerque, NM), 1997. 

5. M. Stein, “Behavior-based control for time-delayed teleoperation,” Tech. Rep. 378, GRASP Laboratory, 

University of Pennsylvania, 1994. 

6. G. Dorais, R. Bonasso, D. Kortenkamp, B. Pell, and D. Schreckenghost, “Adjustable autonomy for humancentered 

autonomous systems on mars,” in 6 th International Joint Conference on Artificial Intelligence 

(IJCAI), Workshop on Adjustable Autonomy System, 1999. 

7. D. Kortenkamp, R. Bonasso, D. Ryan, and D. Schreckenghost, “Traded control with autonomous robot as 

mixed initiative interaction,” in 14 th National Conference on Artificial Intelligence, (Rhode Island, USA), 

july 1997. 

8. T. Röfer and A. Lankenau, “Ensuring safe obstacle avoidance in a shared-control system,” in Seventh International 

Conference on Emergent Technologies and Factory Automation, EFTA’99, (Barcelonna, Spain), 

1999. 

9. G. Ferguson, J. Allen, and B. Miller, “TRAINS-95: Towards a mixed-initiative planning assistant,” in 

Third International Conference on AI Planning Systems, AIPS-96, 1996. 

10. T. Fong, C. Thorpe, and C. Baur, “Collaborative control: a robot-centered model for vehicle teleoperation,” 

in AAAI Spring Symposium on Agents with Ajustable Autonomy, Technical report SS-99-06, (Memlo Park), 

1999. 

11. H. I. Christensen, J. Folkesson, A. Hedstr ´ ’om, and C. Lundberg, “UGV technology for urban navigation,” in 

SPIE Defense and Security Conference, Unmanned Ground Vehicle Technology VI, (Orlando, USA), 2004. 

12. E. B. Pacis, H. R. Everett, N. Farrington, and D. Bruemmer, “Enhancing functionnality and autonomy in 

man-portable robots,” in SPIE Defence and Security Conference, Unmanned Ground Vehicle Technology 

VI, (Orlando, USA), 2004. 

13. J. Albus, “4D/RCS: a reference model architecture for intelligent unmanned ground vehicles,” in SPIE 

AeroSense Conference, Unmanned Ground Vehicle Technology IV, (Orlando, USA), 2002. 

14. J. A. Bornstein, “Army ground robotics research program,” in SPIE AeroSense Conference, Unmanned 

Ground Vehicle Technology IV, (Orlando, USA), 2002. 

15. G. Schaub, A. Pfaendner, and C. Schaefer, “PRIMUS: autonomous navigation in open terrain with a tracked 

vehicle,” in SPIE Defense and Security Conference, Unmanned Ground Vehicle Technology VI, (Orlando, 

USA), 2004. 

16. R. C. Arkin, T. R. Collins, and Y. Endo, “Tactical mobile robot mission specification and execution,” in 

Mobile Robots XIV, pp. 150–163, (Boston, MA), September 1999. 

17. K. S. Ali and R. C. Arkin, “Multiagent teleautonomous behavioral control,” in Machine Intelligence and 

Robotic Control (MIROC), 1(1), pp. 3–17, 2000. 

18. B. A. Bodt and R. S. Camden, “Technology readiness level 6 and autonomous mobility,” in SPIE AeroSense 

Conference, Unmanned Ground Vehicle Technology VI, (Orlando, USA), April 2004. 

35


19. Y. Endo, D. C. MacKenzie, and R. C. Arkin, “Usability evaluation of high-level user assistance for robot 

mission specification,” in Special Issue on Human-Robot Interaction of the SMC Transactions: Part C, 2004. 

20. J. Scholtz, B. Antonishek, and J. Young, “Evaluation of human-robot interaction in the nist reference 

search and rescue test arenas,” in Performance Metrics for Intelligent Systems (PerMIS’04), 2004. 

21. D. Luzeaux and A. Dalgalarrondo, Hybrid architecture based on representations, perception and intelligent 

control, ch. Studies in Fuziness and Soft Computing: Recent Advances in Intelligent Paradigms and Applications. 

ISBN-3-7908-1538-1, Physica Verlag, Heildelberg, 2003. 

22. T. Röfer, “Using histogram correlation to create consistent laser scan maps,” in IEEE International Conference 

on Robotics Systems (IROS-2002), (EPFL, Lausanne, Switzerland), 2002. 

23. “Quatrièmes journées nationales de recherche en robotique (jnrr’03),” (Clermont-Ferrand, France, 

http://lasmea.univ-bpclermont.fr/jnrr03/), 8-10 October 2003. 

24. M. Baker and H. A. Yanco, “Autonomy mode suggestions for improving human-robot interaction,” in IEEE 

Conference on Systems, Man and Cybernetics, October 2004. 

25. A. Dalgalarrondo, Intégration de la fonction perception dans une architecture de contrôle de robot mobile 

autonome. PhD thesis, Université de Paris-Sud, Centre d’Orsay, janvier 2001. 

26. A. Dalgalarrondo, “De l’autonomie des systèmes robotisés,” in Technical report, ref. CTA/02 350 

108/RIEX/807, 2003. 

27. H.-M. Huang, K. Pavek, J. Albus, and E. Messina, “Autonomy levels for unmanned systems (alfus) 

framework: An update,” in SPIE Defence and Security Conference, Unmanned Ground Vehicle Technology 

VII, (Orlando, USA), 2005. 

28. G. M. Kamsickas and J. N. Ward, “Developing ugvs for the fcs program,” in SPIE AeroSense, Unmanned 

Ground Vehicle Technology V, (Orlando, USA), 2003. 

29. R. Alami, A. Clodic, V. Montreuil, E. A. Sisbot, and R. Chatila, “Task planning for human-robot interaction,” 

in Joint sOc-EUSAI conference, October 2005. 

30. A. Finzi and A. Orlandini, “A mixed-initiative approach to human-robot interaction in rescue scenarios,” 

in International Conference on Automated Planning and Scheduling (ICAPS), Printed Notes of Workshop 

on Mixed-Initiative Planning and Scheduling, pp. 36–43, 2005. 

31. T. Fong, C. Thorpe, and C. Baur, “Multi-robot remote driving with collaborative control,” in IEEE Transactions 

on Industrial Electronics, 50(4), August 2003. 

32. J. Albus, R. Lumia, J. Fiala, and A. Wavering, “NASREM: the nasa/nbs standard reference model for 

telerobot control system architecture,” in Technical report, Robot System Division, National Institute of 

Standards and Technology, 1987. 

33. F. Ingrand, “Architectures logicielles pour la robotique autonome,” in Quatrièmes Journées Nationales de 

Recherche en Robotique (JNRR’03), (Clermont-Ferrand, France), October 2003. 

36

Abstract 

ProCoSA: a software package 

for autonomous system supervision 

Magali BARBIER 1 – Jean-François GABARD 1 

Dominique VIZCAINO 2 – Olivier BONNET-TORRÈS 1,2 

1 

ONERA/DCSD – 2 av. Edouard Belin – 31055 Toulouse cedex 4 - FRANCE 

{ Magali.Barbier, Jean-Francois.Gabard, Olivier.Bonnet }@onera.fr 

2 

SUPAERO/LIA – 10 av. Edouard Belin – 31055 Toulouse cedex 4 - FRANCE 

Dominique.Vizcaino@supaero.fr 

Autonomy is required onboard uninhabited vehicles that move in partially known and dynamic environments. This 

autonomy is made possible thanks to the use of embedded decisional software architectures. This paper presents ProCoSA, an 

asynchronous Petri net-based tool that enables implementing such architectures. It allows procedure programming and 

execution in autonomous systems. Vehicle behaviours are modelled using Petri nets; a Petri net player runs the model and 

manages links with other software components. Several decisional architectures developed using ProCoSA for different types 

of vehicles - Autonomous Underwater Vehicle (AUV), autonomous Uninhabited Aerial Vehicle (UAV) and autonomous 

Uninhabited Ground Vehicles (UGVs) - are described in this paper, together with associated experiments and results. 

1. Introduction 


Research on autonomy is performed for Uninhabited 

Ground Vehicles (UGVs), Uninhabited Aerial Vehicles 

(UAVs), Autonomous Underwater Vehicles (AUVs) and 

space vehicles. Autonomy is characterised by the level of 

interaction between the vehicle and a human operator: the 

higher level the operator’s decisions are, the more 

autonomous the vehicle is. Between tele-operation (no 

autonomy) and full autonomy (no operator intervention), 

there are several ways to allow a vehicle to control its own 

behaviour during the mission [1]. 

Autonomous vehicles that move in partially known and 

dynamic environments have to deal with asynchronous 

disruptive events. Hence the need for implementing 

onboard decision capabilities that allow the vehicle to 

perform the mission even when the initial plan prepared 

offline is not valid any more. Decision capabilities, which 

guarantee the adaptability of the vehicle to variable 

environmental conditions, must be implemented in a 

dedicated architecture able to manage the components of 

37 

the whole control loop {perception, situation assessment, 

decision, and action}. The capacity to integrate 

environmental information given by sensors and to evaluate 

the current state is indeed essential for the vehicle to assure 

its own safety and the desired level of autonomy. 

In an embedded decisional software architecture, a high 

level function is required to control mission execution: it 

supervises the nominal execution and triggers reactions to 

disruptive events. This function includes interactions with 

the physical system through dedicated control algorithms 

and deliberative task management. 

The supervision function considered in this paper, 

sometimes called mission execution control function, does 

not include offline mission preparation, task allocation on 

computers, actuator control, nor replaces the underlying 

real time operating system. Its central role is shown on 

Figure 1.

Decision 

Planning 

Navigation 

Guidance 


Operator 

Supervision 

Vehicle 

Situation Monitoring 

and Assessment 

Perception 

Figure 1 – Central role of the supervision function 

The embedded decisional software architecture has to 

integrate all the data relative to the mission (its objectives), 

vehicle behaviour monitoring, connection to deliberative 

software programs, communication with the ground station 

and other vehicles, and reaction to disruptive events. The 

main features required for such an architecture are: 

robustness, reliability, modularity, flexibility, genericity - 

regarding to mission, vehicle and environment -, 

independence from software components, easy interfacing. 

Several types of architectures exist in the literature. In 

this paper, we focus on the ProCoSA software package, 

used by ONERA for controlling and monitoring highly 

autonomous systems. 

2. ProCoSA software package 

ProCoSA, which stands for “Programmation et Contrôle 

de Systèmes à forte Autonomie”, was first developed in 

1993 at ONERA while performing research in the field of 

mobile robotics. Several enhancements and its rewriting in 

an interpreted language led in 1999 to its official 

registration. 

ProCoSA was designed in order to provide the 

developer with an integrated package putting together and 

synchronising the various functions achieving system 

autonomy, among which: 

• data processing (sensor data, situation assessment data, 

operator’s input); 

• nominal mission monitoring and control (vehicle and 

payload control actions); 

• decision (management of disruptive events, replanning). 

These functions are often developed as separate 

subsystems. They have to co-operate in order to fulfil the 

autonomous system behaviour requirements for the 

specified missions. More precisely, the needs are the 

following: 

• offline tasks: specification of the nominal and nonnominal 

procedures, including co-operation between 

procedures and software programs, software program 

coding for embedded operation; a software program 

includes a set of functions that can be called by 

procedures; 

38 

• online tasks: procedure execution, event monitoring, 

and management of the dialog with the operator. 

ProCoSA is based on the Petri net graphical and 

mathematical modelling tool for discrete event systems. It 

includes the following components: 

• EdiPet, a graphical user interface for Petri nets, is used 

both by the developer for procedure design and by the 

operator for execution monitoring; 

• JdP is the Petri net player of ProCoSA: 

. it executes the procedures: looking for the 

occurrence of events, it fires the event-triggered 

transitions of the Petri nets and runs associated 

actions; 

. it supervises the dialog between procedures and 

software programs; 

. it manages the communication with systems 

outside the vehicle. 

• Tiny, a Lisp interpreter specially dedicated to 

distributed embedded applications, is the development 

language of JdP. The communication protocol for the 

exchange of data is socket-based (TCP/IP). 

Tiny and JdP were respectively developed at the 

computer science and automatic control departments of 

ONERA. Prolexia Company developed EdiPet. 

The following subsections describe: 

• the Petri net formalism used in ProCoSA; 

• the Petri net player (JdP); 

• EdiPet; 

• the property verification process. 

2.1. ProCoSA Petri nets 

A Petri net [2] is a bipartite graph with 

two types of nodes: P is a finite set of places and T is a 

finite set of transitions. Arcs are directed and represent the 

forward incidence function F: P × T → N (from a place to a 

transition) and the backward incidence function 

B: P × T → N (from a transition to a place) respectively. 

The marking of a Petri net is defined as a function from 

P→ N, and symbolised by tokens: a given marking is 

associated to a given state of the system modelled by the 

Petri net. The evolution of tokens within the net is achieved 

trough transition firing (Figure 2), which obeys transition 

firing rules: 

• a transition is enabled if its input places contain at least 

the number of tokens given by the F forward incidence 

function; 

• an enabled transition can be fired, and if it is fired, this 

number of tokens is removed from its input places; 

• a number of tokens given by the B backward incidence 

function is added in its output places. 

Petri nets allow sequencing, parallelism and 

synchronisation to be easily represented.

Figure 2 – Example of a Petri net transition firing sequence: 

t1 t2 t1 t3 

Petri nets used by ProCoSA are interpreted nets: triggering 

events and actions are attached to transitions: an enabled 

transition is now fired iff the associated triggering event 

occurs, and the associated actions are executed. They also 

are “safe” nets: only unary arcs are used, and places should 

not contain more than one token. Special places, called 

“global places”, have been introduced in order to ease 

synchronisation between nets while preserving modularity: 

a global place is “shared” between different nets, thus 

enabling the behaviour modelled by a given net to take into 

account a state of the system modelled in another net. This 

feature is particularly suitable for handling disruptive 

events. Timers can be programmed within ProCoSA: a 

special action enables a timer variable to be instantiated, 

which allows actions with a limited duration to be 

modelled. Finally, the hierarchical modelling features 

offered by ProCoSA enable the developer to structure the 

whole application in a generic way: at the highest 

description level, nets model generic behaviours, regardless 

of the characteristics of a given vehicle; at the lowest level, 

they model the sequences of elementary actions to be 

performed by vehicle or payload. This modular approach 

eases a quick adaptation to system changes (e.g. taking into 

account a new payload). 

Several types of actions can be associated to transitions: 

• activation of a Petri net (a Petri net is activated when it 

receives its initial marking); 

• deactivation of a Petri net (when a Petri net is 

deactivated, it looses its marking); 

• emission of an event; 


39 

• emission of a request towards JdP (e.g. a timer 

initialisation); 

• emission of a message towards a software program. 

Several parameters can be associated to an event and 

used by the actions associated to the transition. This 

enables to establish a limited data flow between the 

different software programs activated by the Petri nets: 

when a software program ends, it sends an event towards a 

Petri net (usually the one that launched it) with a set of 

output parameters. Those parameters can be immediately 

transferred by the receiving transition to the next software 

program activated by this transition. 

2.2. The JdP Petri net player 

JdP was developed in Tiny language. Tiny is a Lisp 

interpreter designed for distributed embedded applications 

and includes a library implementing the TCP/IP 

communication protocol. An important feature of ProCoSA 

lies in the fact that there is no code translation step between 

the Petri net procedures and their execution: they are 

directly interpreted by the Petri net player, thus avoiding 

any supplementary error causes. 

When a ProCoSA application is launched, JdP first 

reads the Petri net structures and establishes the socket 

connections with EdiPet (if used during the execution 

phase) and software programs. Specified Petri nets are 

activated (they receive their initial markings), and the 

internal JdP loop is ready to receive the incoming events. 

2.3. EdiPet graphical user interface 

Prolexia Company developed the EdiPet graphical user 

interface (Figure 3). This tool is used both for the 

development of a ProCoSA project and for execution 

monitoring. The set of Petri nets, the set of software 

function names and their relations define a project in 

EdiPet. EdiPet thus allows: 

• the connections inside the whole project between JdP, 

nets and software programs; 

• the graphical creation of Petri nets; several editor 

windows display and allow to modify attributes 

associated to each object (net, place, transition, event, 

action); 

• the generation of relevant interfaces between Petri nets 

and software programs; EdiPet generates the function 

prototypes, which have then to be filled by the software 

developer; 

• the display of the net states during execution; when 

activated (which means that one token is present), 

places and transitions are displayed in red. 

During the execution phase, EdiPet can be used in the 

ground station of the autonomous vehicle, as far as a 

communication link is established.


Figure 3 – EdiPet graphical user interface 

The example shown on Figure 4 and Figure 5 models a 

simple project for the supervision of a UAV. The objective 

of the mission is to join a sequence of waypoints. Several 

payloads are available onboard, and the activation of a 

given payload is associated to each waypoint. The 

MISSION Petri net models the main mission phases: roll, 

takeoff, climb, transits to each waypoint, approach and 

landing. The GUI software program simulates the guidance 

of the vehicle. In the nominal execution, the DEC 

decisional software program gives the next waypoint to 

join. The EVENTS Petri net models two examples of nonnominal 

reactions. If a payload fails, MISSION is 

deactivated, DEC is called and computes another list of 

waypoints that do not use the faulty payload. The 

replanning transition of the MISSION net is then fired and 

the vehicle continues the mission with the new list of 

waypoints. In case of engine failure, MISSION is also 

deactivated, DEC is called and computes the nearest 

emergency site. The EVENTS net supervises directly the 

transit to this site by calling GUI. 

Figure 4 – Example of EdiPet project 

40 

Figure 5 – Examples of EdiPet Petri nets 

2.4. Verification process 

ProCoSA includes a verification tool, which makes use 

of well known Petri net analysis techniques to check that 

some “good” properties are satisfied by the procedures, 

both at the single procedure level and at the whole project 

level (that is to say taking into account inter-net 

connections). 

The following properties are checked: 

• place safety (not more than one token per Petri net 

place); 

• detection of dead markings (deadlocks); 

• detection of cyclic firing sequences (loops). 

The principle of this analysis lies on the automatic 

generation of the reachability graph, which contains all the 

possible reachable states of each net and of the whole set of 

interconnected nets. As nets are safe, this set is necessarily 

finite, and its analysis permits to deduce the above 

properties.

3. Applications 

Several projects are ongoing with ProCoSA: 

• with DGA/GESMA on an Autonomous Uninhabited 

Vehicle [3]; 

• with EADS DS SA on an Uninhabited Aerial Vehicle 

[4]; 

• at SUPAERO, a French Engineer School, on 

Uninhabited Ground Vehicles, for team operation [1]. 

3.1. AUV project 


GESMA, in co-operation with ONERA and 

PROLEXIA, develops a software architecture with four 

levels of autonomy from tele-operated mission to fully 

autonomous goal driven mission. Tele-operation is seen as 

level 0: the operator uses a control box to move the vehicle. 

Main tests of the vehicle were performed within this level: 

battery, communication, sonar, and other sensors. At the 1 st 

autonomy level, an ordered set of elementary controls 

prepared by the operator describes the mission. Sixteen 

controls combining monitoring and modification of main 

variables (duration, speed, heading, immersion, and 

altitude) have thus been implemented. In May 2005, sea 

trials conducted with the Redermor AUV successfully 

validated the pilot software program. At the 2 nd autonomy 

level, a mission is defined by a set of segments (straight 

line trajectories). 

A ProCoSA based architecture has been implemented 

for the 3 rd autonomy level: the mission is defined by a set 

of mission areas where a survey procedure is performed. At 

the end of these operations, the vehicle joins the end area. 

The environment is defined by bathymetry, currents, 

forbidden areas and non-navigable water data. The 

planning software program has then to compute the 2D 

itinerary (the order to join the mission areas), the 4D 

trajectory between mission areas, and the survey planning. 

3.1.1. Experimental configuration and 

decisional architecture overview 

Experiments are conducted with the Redermor AUV 

(Figure 6). Three computers and thirteen distributed Can 

interfaces with computation capabilities are installed on the 

platform. Serial link, Can Bus, I2C and Ethernet 

connections are available for payload integration and data 

exchange. OA1 computer is in charge of complex vehicle 

functions, supervision and mission planning; it thus 

includes the decisional software architecture. OA2 and 

OA3 computers are used for sonar payload controls and 

treatments like Computer Aided Detection and 

Classification algorithms for mine warfare. The embedded 

architecture is shown on Figure 7. 

41 

Data 

manager 

GDD 

events 

OA1 

EVT 

state 

sensors Drivers 

Figure 6 – Redermor AUV 

Planning PLN 

Petri Player 

ProCoSA 

Guidance GUI 

commands 

Pilot IDC 

mission 

controls 

Data server 

OA_NAVIO 

Petri nets 

vehicle 

behaviour 

OA2, OA3 

Payload drivers 

and treatments 

events 

CAN bus Drivers actuators 

Figure 7 – AUV embedded architecture 

For mission supervision, the decisional architecture in 

OA1 computer includes: 

• the Petri net player of ProCoSA; 

• vehicle behaviour modelling through Petri nets, for 

nominal and non-nominal situations; 

• four software programs connected to ProCoSA: 

planning (PLN), guidance (GUI), dynamic data 

manager (GDD) and event listener (EVT); 

• the pilot program software (IDC) that computes controls 

sent to the engine; 

• the data server (OA_NAVIO) developed by GESMA 

that carries out bi-directional communication links with 

the hardware architecture. 

3.1.2. Nominal scenario 

The behaviour of the vehicle during the execution of a 

mission is described in eleven Petri nets. This description is 

hierarchical (Figure 8): 

• In Mission net, at level 1, two places model the stop and 

the ongoing states of the mission; 

• Mission_Phases net at level 2 models main phases of 

the ongoing mission: planning initialisation, the loop 

structure enabling the vehicle to join each mission area 

(transit to the area and survey) and transit to the end 

area;

• Three Petri nets model level 3: Transit_to_Area net for 

transiting to the next mission area and Operation net for 

survey achievement; Initialisation net runs itinerary and 

operation planning when starting the mission; 

• Level 4 is devoted to computation: Itinerary_Planning 

net computes an itinerary for the saved mission taking 

into account non-navigable areas; Trajectory_Planning 

net computes a trajectory between two areas modelled 

by their centroid waypoint; Operation_Planning net 

asks for vehicle state and computes the operative 

sequence; both a trajectory and an operative sequence 

are composed of linear trajectory followings and course 

changes; 

• Level 5 executes the mission: Trajectory net asks for the 

next trajectory and runs it; Survey net asks for the 

operative sequence and runs it; Planning_and_ 

course_change net computes the required gyrations and 

heading following sequence and executes it. 

Initialisation 

Initialisation 


Mission 

Mission 

Mission Phases 

Mission Phases 

Transit to Area 

Transit to Area 

Operation 

Operation 

PLN 

Itinerary 

Itinerary 

planning 

planning 

PLN 

Trajectory 

Trajectory 

planning 

planning 

PLN 

Operation 

Operation 

planning 

planning 

GDD GDD GDD 

Trajectory 

Trajectory 

GDD 

GUI 

Survey 

Survey 

GDD 

GUI 

Software programs 

PLN: planning 

GUI: guidance 

GDD: data manager 

Planning 

Planning 

and 

and 

course 

course 

change 

change 

PLN GUI 

Figure 8 – Hierarchy of Petri nets 

3.1.3. Non-nominal scenario 

Many events can affect AUV missions and require 

onboard replanning. At present, three types of events are 

implemented: 

• an alarm event forces the vehicle to move directly to the 

end area: a new itinerary to avoid non-navigable areas 

and a new trajectory are computed; 

• when arriving on an objective area, the real current is 

different from the predicted one and invalidates the 

already-computed survey: a new operative sequence is 

thus computed; 

• the operator asks for a local operation of inspection, for 

example to inspect a suspicious object. A specific 

operative sequence is planned before the vehicle 

resumes its mission. 

These events are considered in the architecture through 

three new Petri nets. The Decision net implements the 

decisions that the vehicle must make according to the type 

of event, e.g. return to the end area in case of an alarm 

event. The Action net executes the decisions; it can run 

nominal nets. The Inspection net executes the inspection 

asked by the operator. 

42 

3.1.4. Lab bench tests 

A bench test has been developed to test the whole 

decisional architecture. The OA_NAVIO data server has 

been connected to on the one hand a Redermor simulator, 

and on the other hand the IOVAS interface. The simulation 

of several missions allowed to validate the desired 

behaviour of the vehicle (Petri nets), the decisional 

functions of PLN, the management of dynamic data in 

GDD, the guidance and the pilot of the vehicle (GDD and 

IDC) and the reception of disrupted events (EVT) together 

with the supervision on IOVAS operator interface (Figure 

9). Nominal and non-nominal scenarios were both 

successfully simulated. 

Figure 9 – Supervision of a simulated AUV mission. 

Survey area is blue, forbidden area is red, planning trace is 

yellow, vehicle simulated trace is green. 

3.1.5. Sea experiments 

Recent sea experiments have been conducted in 

Douarnenez Bay. Three missions were carried out. The 

vehicle is followed by acoustic means, and only a few 

points are currently available (Figure 10). Vehicle 

immersion, transit to the survey area, line following at a 

given altitude and return to the end area were successfully 

performed. These experiments validated the embedded use 

of ProCoSA. Emphasis should now be put on guidance 

accuracy, perception function, classification of disruptive 

events, situation monitoring and assessment functions. 

Figure 10 – Supervision of a real AUV mission. 

Acoustic vehicle trace is green.

3.2. UAV project 


EADS and ONERA are involved in a national project 

that aims at testing an architecture designed for mission 

supervision in a UAV and demonstrating the relevance of 

such architectures in future uninhabited vehicles. As all 

categories of UAVs have to perform their missions in 

complex environments with the same types of constraints, 

the embedded architecture has to be generic, i.e. not 

dedicated to a given mission, environment or vehicle. As 

the mission may be disrupted by internal or external events, 

e.g. failures, weather situation, interfering aircraft, and 

threats, onboard plan monitoring and replanning are 

required in order to deal with nominal or disruptive events, 

avoid systematic return to base and proceed with the 

mission as well as possible given the new constraints. 



Experiments are conducted on a light plane, a Dyn’Aero 

MCR-4S (Figure 11). Two computers are devoted to the 

control part of the plane, and a third one to the decision 

part, i.e. mission management. The first control computer is 

directly linked to the plane sensors and actuators (e.g. the 

automatic pilot) and to the ground station, while the second 

one acts as an interface between the previous real time 

control computer and the decision computer: it sends 

formatted frames and interprets elaborated orders. 

Figure 11 – Light plane used for experiments in UAV 

project 

The role of the software decisional architecture 

implemented on the decision computer through ProCoSA 

(Figure 12) is thus to monitor the main mission phases of 

the nominal scenario, to manage the dialog with the 

operator (payload use), and to generate control decision 

when disruptive events occur. In order to elaborate the prespecified 

events used by ProCoSA from the telemetry 

frame data, an additional interface software layer was 

developed (Figure 13). 

43 

decision computer 

ProCoSA 

JdP 

Petri Player 

Petri 

nets 

EdiPet 

subsystem 

software 

connection 

decision 

computation 

environment 

database 

interface software 

mission 

database 

dialog windows 

frame receipt 

event 

processing 

frame 

emission 

UAV 

database 

frames 

Figure 12 – UAV embedded decisional software 

architecture 

Figure 13 – Example of the “ready for takeoff” event 

elaboration 

3.2.2. Nominal scenarios 

control 

computer 

A four-level mission modelling architecture was 

defined in order to guarantee a generic approach: 

• level 0: initialisation of the communication protocols 

between ProCoSA and the other software layers; 

• level 1: global state of the mission and modes 

monitoring (nominal - non nominal); 

• level 2: main nominal phases of the mission (from preflight 

tests and takeoff to touchdown and end-of-flight 

tests); 

• level 3: sub-phases of the mission. 

Level 3 corresponds to less generic procedures, i.e. 

more specific to the vehicle type or to mission and payload 

characteristics. The Petri net shown on Figure 14 details the 

linking of the different steps within the operational area: 

this net clearly shows the looped structure enabling the set 

of pre-programmed tasks to be achieved, and includes 

communication requests to the operator. ProCoSA timers 

are used to limit the time allowed for the operator’s answer.


Figure 14 – Modelling of the linking of operational tasks 

3.2.3. Non-nominal scenarios 

In order to be able to apply a generic approach to deal 

with disruptive events, they were classified in four 

categories: 

• catastrophic events lead to mission abortion, and cannot 

be recovered; when such an event occurs, the 

processing of any other kind of events is aborted and no 

further incoming event can be processed; example: 

engine total failure; 

• safety-related events lead to modifying the flight profile 

or the flight plan - e.g. change route for a while - which 

may induce delays or new constraints on the use of the 

payload; examples: interfering aircraft, new forbidden 

area, turbulence... 

• mission-related events only have consequences on the 

mission itself; replanning amounts to adapt the mission 

to the new constraints, e.g. remove waypoints; 

examples: camera failure, violated temporal constraint, 

new mission goal... 

• communication-related events are related to 

communication breakdowns between the UAV and the 

ground; such events result in the UAV being fully 

“autonomous” therefore it has to proceed with the 

mission as planned; example: telemetry failure. 

According to this classification, one Petri net was 

designed for each disruptive event category: an example is 

given by the engine failure Petri net shown on Figure 15: 

one can note the use of the ProCoSA “global places” 

feature (see section 2.1), which enables to adapt the 

44 

reconfiguration actions to the current state of the mission. 

This reconfiguration process is achieved through software 

function activation requests, which enable to build a set of 

control orders to be sent to the control computer 

Figure 15 – Engine failure reaction modelling 

3.2.4. Ground and flight tests 

Two series of field tests are planned in March and May 

2006. A test series will be organised as a two-step process: 

during the first week, ground tests will be conducted in 

order to prepare and simulate the scenarios, which will be 

run on the plane. Flight tests will be conducted during the 

second week, with a pilot and an operator onboard the 

plane. 

The nominal scenario will be tested first. Non-nominal 

scenarios implying a unique disruptive event will be 

considered afterwards, and eventually scenarios including 

two or three cumulative disruptive events. 

A double check process will be achieved during each 

flight test. Flight data (telemetry frames) and the 

corresponding Petri net states will be registered onboard. 

The ProCoSA layer of the decision computer will be 

duplicated on the ground station that will also receive the 

real-time telemetry frames, thus enabling system state to be 

monitored on the ground. 

3.3. UGVs project 

The computer science and automation lab (LIA) at 

SUPAERO and the Systems Control and Flight Dynamics 

Department (DCSD) at ONERA are involved in a cooperation 

on mobile robotics to answer a national need to 

integrate robots into military operations. The project goal is 

to operate several autonomous robots. In these studies, the 

choice of a centralised architecture was made. 



Robots used in the project are Pekee robots, developed 

by Wany Robotics (Montpellier, France). They feature


three individual racks for computer cards (for 

communication via WiFi, and/or camera and image 

management), a shock detection sensor and are surrounded 

by an Infra Red sensor ring (Figure 16). 

Figure 16 - A Pekee robot. Note the WiFi antenna, the IR 

sensor ring and the camera, as well as two occupied racks 

Two libraries were developed: 

• the movement library stores elements such as free 

translation and rotation but also half-controlled 

displacements such as translation until obstacle or 

controlled movements such as following a wall, a 

corridor, a sinuous route... 

• the picture library is based on openCV primitives and 

allows in particular the detection of obstacles and 

localisation of markers. 

These library elements constitute a set of services that 

the agent may use in order to achieve the mission goals. 

Several groups of students worked on these 

experiments. The last objective was to implement the 

control of the basic moves for two robots in a known 

environment. The mission (Figure 17) consists in virtually 

changing the position of several coloured rings following a 

defined order. As robot moves are independent, a planning 

algorithm was developed to manage area occupancy 

conflicts. 

start areas 

Pekee robots 

bottleneck 

area 

load areas 

Figure 17 – UGVs mission 

The control architecture for each robot heavily relies on 

ProCoSA. The architecture is composed of three layers 

(Figure 18): 

• the ProCoSA layer models actions chronology; it is 

centralised; 

45 

• the interface layer translates ProCoSA orders into robot 

controls and robot sensor data into ProCoSA events; it 

is written using the Visual C++ development tool; 

controls are mainly related to speed and heading; 

• the robot layer executes controls and sends sensor data 

coming from IR sensors and camera image. 

ProCoSA 

events 

orders 

Visual C++ 

interface 

sensor data 

controls 

Figure 18 – UGV architecture 

3.3.2. Lab tests 

Pekee Robot 

Eight elementary moves have been modelled: they 

allow the robot to move in the labyrinth and to take into 

account the bottleneck area (go forward, go backward, turn 

right, turn left, follow right wall, follow left wall, enter 

bottleneck, exit bottleneck). Only one robot could enter this 

area at the same time. Seven Petri nets were developed, 

three per robot and one for their synchronisation, i.e. the 

management of the conflict in the bottleneck area according 

to the plan algorithm. 

The mission was successfully executed by robots. This 

validated the use of ProCoSA for synchronising a tworobot 

mission. 

3.3.3. Generic supervision approach 

Some work [5] is carried out on designing a more 

generic supervision architecture that would take advantage 

of the modular nature of the robot and run the controller 

and the diagnosis module (Figure 19). 

Figure 19 - Robot embedded architecture 

Figure 20SEQARABIC proposes a Petri net model for 

the controller. The initial planning creates the plan. The 

execution phase runs the plan that in its turn executes 

actions from the libraries. A replanning step is triggered at


the occurrence of a disruptive event: the robot is set in a 

reaction mode (safety mode) while the event is analysed. 

The consequences of the event are then dealt with during 

the repair that recreates the plan. Once the repair is 

calculated, it is adjusted so as to smoothly switch from 

reaction to repaired plan execution. 

Figure 20 - ProCoSA plan controller 

3.3.4. Future experiments 

The mission will consist in a search and rescue 

operation in a partially known urban environment. The 

team is composed of two aerial robots and two terrestrial 

robots. The robots have knowledge of possible routes to 

move in the environment. The uncertainty parameters, such 

as obstacles barring expected paths, robot or service 

failure... are handled through event firings that trigger 

replanning phases on parts of the plan. 

The experimental set-up uses four Pekee robots, a labyrinth 

modelling the environment and a transparent pane to bear 

the “aerial” robots (Figure 21). The two aerial robots are 

characterised by a downward camera in order to detect 

ground obstacles and deliver accurate global localisation 

for ground robots. All communications are WiFi-based. 

46 

Figure 21 - Experimental set-up. Note the two aerial robots 

on the Plexiglas pane with downward camera 

4. Conclusions 

The current version of ProCoSA allows designing 

decisional embedded software architecture: Petri nets 

describe the execution logic for the various specified 

autonomous vehicle behaviours, including both nominal 

mission phases and reactions to disruptive events. It also 

manages connections with software programs associated to 

specific functionalities such as situation assessment, 

planning, guidance. Those behaviours are directly 

interpreted and executed by the Petri net player, without 

any intermediate code translation step, and on-line 

execution monitoring is possible with EdiPet. Significant 

validation steps can be achieved during the design phase 

thanks to Petri net formal analysis properties. 

ProCoSA software has been successfully used in 

several projects for the control of autonomous vehicles. 

First sea experiments validated its use in embedded 

architecture. Aerial tests are planned by the end of this 

year. Research on its implementation in several mobile 

robots composing a team is ongoing. 

The main objective of the proposed embedded 

decisional software architecture is to supervise mission 

execution whatever occurs. It thus deals with 

environmental uncertainties: reactions to disruptive events 

are implemented in Petri nets that call deliberative tasks. 

Deliberative tasks and mission data are independent of 

ProCoSA and that point offers modularity and genericity to 

the whole architecture. Indeed, specificity of the vehicle is 

taken into account in databases and in the interfaces 

connected to the control computer. 

Current results point out several possible ways of 

improvement: 

• a perception function that studies and develops methods 

to elaborate and update real world sensor data, would 

help to take appropriate decisions; of course, good data 

quality is required as well; 

• a situation monitoring and assessment function that 

estimates the system parameters and predicts their

evolution could help to anticipate the arrival of 

disruptive events; this should also increase security 

level for the vehicle; image processing is also a difficult 

task to implement onboard; 

• a generic study of all types of events, their classification 

and identification of associated reactions are necessary 

in all autonomous system, as emphasised in UAV 

experiments; 

• all studies drew attention on the necessity of enhanced 

planning algorithms for autonomous vehicles; research 

have to be conducted to improve proposed algorithm 

with regard to duration constraints; mission objectives 

could also be selected onboard (objective planning 

function) according to collected environmental data; 

• all possible communications between the ground 

operator and the vehicle have to be defined properly, 

especially the operator’s decisions and the associated 

reactions onboard. This communication protocol gives 

the vehicle its level of autonomy. An onboard 

architecture adapting its autonomy level according to 

the types of disruptive events could also be considered; 

• simulation remains essential to valid autonomy 

architecture before its implementation; the use of a 

bench test before sea experiments in the AUV project 

led to architecture validation during the first 

autonomous missions; 

• studies on the collaboration between several 

autonomous vehicles have to continue, as this is the 

main point in future operational theatres; 

• the operator’s role evolves as the autonomy level 

increases, and ground systems have to evolve as well, 

e.g. with implementation of decision support systems. 

References 


[1] B.T. Clough, Metrics, Schmetrics ! How the heck do 

you determine a UAV’s autonomy anyway ? 

Performance Metrics for Intelligent Systems 

Workshop, 2002, Gaithersburg, MA, USA. 

[2] Murata, T. (1989). Petri nets: properties, analysis and 

applications. IEEE. 77 (4), pp. 541-580. 

[3] F. Dabe, H. Ayreault, M. Barbier, S. Nicolas, Goal 

Driven Planning and Adaptivity for AUVs, UUST 05 

Unmanned Untethered Submersible Technology, 21-24 

August 2005, Durham, NH, USA. 

[4] M. Barbier, J.F. Gabard, J.H. Llareus, C. Tessier, J. 

Caron, H. Fortrye, L. Gadeau, G. Peiller, 

Implementation and Flight Testing of an Onboard 

Architecture for Mission Supervision, 21 st IUAVS 

International Unmanned Air Vehicle Systems 

Conference, April 3-5, 2006, Bristol, UK. 

[5] O. Bonnet-Torrès and C. Tessier, Cooperative Team 

Plan: Planning, Execution and Replanning, AAAI'06 

Spring Symposium on Distributed Schedule and Plan 

Management, March 2006, Stanford, CA, USA. 

47

Abstract 


GOAL DRIVEN PLANNING AND ADAPTIVITY FOR AUVS 

Hervé Ayreault, Frederic Dabe 

GESMA, Groupe d’Etudes Sous-Marines de l’Atlantique 

BP42 – 29240 Brest Armées – France 

{herve.ayreault, frederic.dabe}@dga.defense.gouv.fr 

Magali Barbier 

ONERA, Office National d’Etudes et de Recherches Aérospatiales, Toulouse Center 

BP 4025 – 31055 Toulouse cedex 4 – France 

Magali.Barbier@onera.fr 

Stéphane Nicolas, Gaël Kermet 

PROLEXIA, 865 avenue de Bruxelles – 83500 La Seyne-sur-mer – France 

{snicolas, gkermet}@prolexia.fr 

Environmental knowledge is increasing every 

day but it is neither comprehensive nor 

perfect. For unsupervised long mission, it is 

difficult to mitigate with these environmental 

uncertainties. Therefore, an embedded system 

is required to allow automatic re-planning 

with respect to real environmental data 

collected during the mission. In order to 

achieve this re-planning function, the 

information system must be able to deal with 

the goals that led to the initial mission 

planning. 

GESMA, in cooperation with ONERA and 

PROLEXIA, develops a software architecture 

with four levels of autonomy from 

teleoperated mission to fully autonomous goal 

driven mission. The 3 rd level is described in 

this paper; at this level, the mission is defined 

by a set of objective areas where a survey 

procedure is performed. The onboard 

hardware architecture is implemented on three 

computers whereas the software architecture 

has been developed around ProCoSA. The 

Man Machine Interface on one hand 

facilitates the offline preparation of a mission 

and on the other hand supervises the online 

tracking of the vehicle. Planning algorithms 

48 

online compute new itineraries and 

trajectories according to the occurrence of 

critical events. On-going tests are performed 

both by simulation and at sea. 

The paper will present the different autonomy 

levels of the onboard architecture, the way 

there are implemented on the AUV, 

optimization algorithms, operators MMI and 

results of on-going tests. 

Introduction 

Research on autonomy for unmanned vehicles 

is performed in robotic, aerial and spatial 

fields. The autonomy is characterized by the 

level of interaction between the vehicle and 

the operator (human in general): the more 

abstract the operator decisions are, the more 

autonomous the vehicle is. There are between 

teleoperated vehicles (no autonomy) and fully 

autonomous vehicles (no operator 

intervention) several ways to allow a system 

to control its own behavior during its mission 

[1].

When the vehicle moves in a partially known 

and dynamic environment, one way to make 

the vehicle autonomous is to implement 

onboard decisional capabilities. They allow 

the vehicle to perform its mission even when 

the initial plan prepared offline is no more 

valid. Decision capabilities, which guaranty 

the adaptivity of the vehicle, must be 

implemented in an architecture in order to 

close the loop {perception, situation 

evaluation, decision, and action}. The 

capacity to integrate environmental 

information via sensors and to evaluate the 

current state is indeed essential for the vehicle 

to assure its own safety and a minimum level 

of autonomy. 

Figure 1 - Redermor AUV 


GESMA works on autonomy projects for 

several years. One is devoted to the 

development of an autonomous system for the 

execution of missions in a partially known 

environment. The choice was made to 

implement several levels of increasing 

autonomy while conducting in parallel sea 

trials to validate each implementation. Sea 

trials are conducted with the Redermor AUV. 

In this project, ONERA develops the onboard 

decisional architecture, whereas PROLEXIA 

develops the man machine interface. 

49 

The paper first describes the selected levels of 

autonomy in relation with the type of mission 

to be performed. The second paragraph 

describes the architecture for one high 

decisional autonomous level. A man-machine 

interface to prepare the mission and to 

supervise it is thus presented in the third 

paragraph. The fourth chapter introduces the 

event generation by data acquisition and 

treatment. The main decisional task (fifth 

part) is the computation of a new plan when 

the current plan fails: optimization algorithms 

are implemented to allow the online reaction 

to events; therefore, the goal driven 

deliberative planning products a plan of 

actions based on a set of high level goals and 

constraints. On-going tests given in the sixth 

part highlight the interest of the architecture 

when event occurs and modify the security, 

the mission goal or the measurement process. 

We conclude about this research which could 

conduct to an operational product. 

Selected levels of autonomy and missions 

The teleoperation is seen as the 0 level: the 

operator uses a control box to move the 

vehicle. Main tests of the vehicle have been 

performed within this level: battery, 

communication, sonar, and other sensors… 

At the 1 st level, an ordered set of elementary 

controls prepared by the operator describes 

the mission. 16 controls combining the 

following and the modification of main 

variables have thus been implemented. Main 

variables are duration, speed, heading, 

immersion, altitude and examples of control 

are “follow the current heading during X 

seconds”, “go to the X immersion with the 

same heading”, “turn until the X heading”. 

Then, the onboard system, through a 

commands interface software program, online 

computes consigns sent to the actuators of the 

vehicle. 

At the 2 nd level, operator defines a set of 

segments (straight line trajectories). Onboard, 

a planning software computes the course 

changes between the end of a segment and the

eginning of the next one. A guidance 

software program computes 1 st level 

elementary controls to follow the different 

parts of the obtained plan. An emergency plan 

is also regularly updated to allow the vehicle 

to join one of the pre-defined recuperation 

areas if an emergency event occurs. 

At the 3 rd level, the mission is defined by a set 

of mission areas where a survey procedure is 

performed. The environment is defined by 

bathymetry, currents, forbidden areas and 

non-navigable water data. The planning 

software program has then to compute the 2D 

itinerary (the order to join the mission areas), 

the 4D trajectory between mission areas, and 

the survey planning. The guidance is similar 

to the one of the 2 nd level, and the navigation 

to the one of the 1 st level. As for the 2 nd level, 

in order to be adaptive, the onboard 

architecture must be able to react to events, 

which modify the initial planning. 

The full autonomy is seen as the 4 th level: the 

vehicle does its best to perform the global 

mission without communication with the 

operator. In real situation, this autonomous 

level is currently not applicable for the whole 

duration of a mission. Some critical decisions 

have to be validated by an operator; some 

delicate tasks also require human 

intervention. However, the needs in terms of 

autonomy vary during a mission, and a 

solution could be to adjust the level according 

to the evaluated situation. For example, the 4 th 

level is required when communication links 

are – intentionally or not – cut off. These 

adjusts could thus be performed by the 

vehicle or by the operator [2]. 

This paper focuses on the 3 rd autonomy level. 

Onboard architecture 


3 computers and 13 distributed Can interfaces 

with computation capabilities are installed on 

the platform. Serial link, Can Bus, I2C and 

Ethernet connections are available for all 

types of payload integration and data 

exchange. 

The 13 Can interfaces are dedicated to the 

vehicle itself and support the 0 and 1 st level 

50 

functions, for example fins controllers, or 

battery monitoring. 

One of the computers (OA1) is in charge of 

complex and real time vehicle functions. The 

supervision and mission planning is 

implemented in an other computer (OA2). 

Levels 2, 3 and 4 are executed on that 

platform. 

Two computers (OA2 & OA3) are used for 

sonar payload controls and treatments like 

Computer Aided Detection and Classification 

algorithms for mine warfare. This program 

has already been tested and can generate Mine 

Like Contacts as events for future replanning. 

The mission control software has Ethernet 

interfaces and a specific driver allows 

communication with the Can bus. It has a 

modular design in order to facilitate 

development, integration and tests. Its 

architecture separates physically the 0 and 1 st 

level from the others. On figure 2, the yellow 

boxes model the decisional architecture, the 

blue box models the direct relationship 

between this architecture and the action level, 

the green box models the computation of 

consigns (1st level program), and the pink 

box models the event generation by data 

acquisition and treatment. The bottom boxes 

model the communication with the hardware 

architecture. 

Data 

manager 

GDD 

OA1 

Sensors 

OA2 mission 

EVT 

events 

status 

Planning optimization PLN 

Petri player 

ProCoSa 

Guidance GUI 

commands 

Interface of commands 

IDC 

consigns 

Data server of GESMA 

OA_NAVIO 

events 

Petri nets 

Vehicle 

behavior 

OA2 and OA3 

Payload 

drivers and 

treatments 

Can big boxes 

Drivers CAN Bus Drivers Actuators 

Figure 2 - Onboard architecture


The decisional architecture is based on the 

ProCoSA program [3], which was developed 

for programming and execution monitoring of 

autonomous systems. Behavior of the vehicle 

during the mission is described by Petri nets 

[4] (directed graphs with two kinds of nodes, 

called places and transitions); in ProCoSA, 

places represent the considered behavior 

internal states and transitions indicate the 

phenomenon that change the behavior 

execution state. The Petri Player of ProCoSA 

is the complex automate which runs the 

system in accordance with Petri nets and 

computation software such as the planning 

and guidance programs. 

Man-Machine Interface 

The Man Machine Interface, named IOVAS, 

provides several graphical tools to prepare, 

check and supervise missions of different 

kinds of vehicles: AUVs, ships. 

The preparation tool (Figure 3 and Figure 4) 

allows to graphically define the vehicles 

configuration and constraints and to design 

the tasks sequence to be executed by each of 

them. Each task definition is dynamically 

checked with the environment data (altitude 

to ground, forbidden areas, current) and with 

the vehicle’s constraints like max autonomy, 

max immersion, min altitude, max speed etc. 

The preparation tool displays bathymetric 

lines, currents (arrows) and forbidden areas to 

help the operator to prepare the mission. 

During the preparation process, at any time, 

the operator can validate the mission by 

running the planning algorithm. The predicted 

trajectory is then displayed over the map. 

Two levels of tasks can be defined: 

− 1 st level tasks: definition of elementary 

controls like “Follow heading ALPHA at 

an immersion Z for time T”. 

− 3 rd level tasks: definition of objectives (in 

our case geographic areas to survey with 

associated payloads). 

51 

Figure 3 - Preparation interface 

Figure 4 - MMI environmental data 

The supervision tool (Figure 5) is used to 

track the vehicles positions in real-time using 

data coming from acoustic links, short base 

line tracking system or GPS serial links. 

It displays each vehicle’s trajectory and 

detailed status if available (heading, 

immersion, altitude, energy). The real 

trajectories can be compared in real time with 

the planned ones.

Figure 5 - Supervision interface 


Events generation, Data treatment 

AUV mission planning is performed for 

specific tasks or goals. Its efficiency depends 

on its capacity to integrate environmental 

information and sensors status and is 

therefore related to AUV security insurance, 

mission optimization and data quality 

insurance. 

For AUV security, the mission planning must 

consider bathymetry, known obstacles, 

density variation. Currents are also important 

information to guaranty the energy 

consumption and therefore the feasibility of 

the mission (AUV must have enough energy 

to come back). Bathycelerimetry distribution 

might also influence the acoustic 

communication for supervised mission. 

Mission optimization is important for mission 

efficiency which is a high operational 

requirement. Assuming that the mission is 

defined by a set of operation areas, the 

optimization can be as simple as calculating 

the geometric shortest path or as complex as 

computing a path while optimizing energy 

consumption related to tides and currents. 

Data quality is relative to exhaustivity, 

accuracy and confidence. The mission 

planning must guaranty perfect sonar 

coverage and overlap whatever the 

bathymetry is. It must take into account 

52 

navigation errors due to seabed characteristics 

(Doppler doesn’t like mud) or too strong 

currents that might induce unstability. 

Another requirement would be to have 

heading perpendicular to sand ripples for 

sonar acquisition. 

Therefore, many events can affect AUV 

mission and require onboard re-planning. At 

that time, GESMA efforts mainly focus on 

two different kinds of events. 

− Real time currents assessment is one of 

them as it might influence survey heading 

and energy consumption. Different 

solutions to get current values are 

evaluated like parameters identification, 

DVL/ADCP sensor, and electromagnetic 

probe. 

− Regarding mine warfare, it is very 

important to increase the level of 

efficiency of Computer Aided Detection 

algorithms. Onboard re-planning for 

multi-aspect sonar acquisition of mine like 

contacts is one of the main GESMA 

objectives in a near future. Mission replanning 

to take into account low level of 

efficiency due to environmental 

conditions (sand ripples or reverberation 

for examples) will be the next step. 

Planning algorithms 

The objective of the planning function is to 

compute the movements of the vehicle for the 

achievement of the mission. This computation 

is performed offline during the preparation of 

the mission to allow the operator to see its 

feasibility and the estimated vehicle behavior. 

Onboard and online, the function gives 

autonomy to the vehicle. A global online 

computation of all the movements by only 

one algorithm hasn’t been considered for 

several reasons: the number of constraints is 

high and could lead to a complex algorithm, 

the computation duration has to be relatively 

short, some problems could be locally solved. 

The decision was then taken to develop 

several planning algorithms.

As the mission is defined by a set of 

objectives, the first algorithm computes an 

itinerary that is it orders the objectives. In this 

2D search, objectives are modeled by their 

geometric centroid waypoint. A mission 

graph is built with the objective waypoints, 

the start and the end waypoints. The costs of 

the edges are computed taking into account 

the current and the non-navigable areas. For 

each pair of waypoints in the mission graph, a 

Dijkstra algorithm finds iteratively the 

shortest path which is built on a sort of 

reduced visibility graph that allows avoiding 

known obstacles (Figure 6). The cost matrix 

is not symmetric because of the current. A 

Little algorithm [5] looks then for a 

Hamiltonian path of lowest cost in the 

mission graph. 

mission graph 

waypoint 


obstacles 

mission graph 

waypoint 

Figure 6 - Shortest path between two waypoints of the mission 

graph 

The second algorithm computes the actions to 

achieve a survey operation. The operative 

sequence is composed of linear trajectory 

followings and course changes. To consider 

sonar constraints, the survey is made at steady 

altitude. The main direction of the survey 

depends on the direction of the estimated 

current. 

The third algorithm computes the 4D 

trajectory between each pair of the itinerary. 

The itinerary is followed at nominal steady 

speed. Between each pair of objective areas, 

we assume that the vehicle follows a steady 

immersion, even when it avoids nonnavigable 

areas (Figure 7). This modeling 

allows limiting the risk due to the bathymetry 

uncertainties. The trajectory avoids nonnavigable 

areas with relevant course changes. 

The slope of the ascents and descents 

53 

considers the constraints of the vehicle. If the 

maximum slope can’t be respected, course 

changes are added to the trajectory. 

-20 

-40 

-60 

-80 

-100 

0 

0 10000 20000 30000 40000 50000 60000 

survey 1 

survey 2 

obstacle avoidance 

survey 3 

Figure 7 - Trajectory immersion (m.) vs. trajectory length (m.) 

for a 3 objectives mission 

The itinerary and operation planning 

algorithms are also implemented in the Man 

Machine Interface to allow an operator to 

prepare a mission. Figure 8 shows the 

application of the planning function on the 2D 

map of the MMI. Objective areas in blue are 

surveyed, forbidden areas in red and nonnavigable 

areas (coastline in red, coast area in 

green) are avoided. Numerous tests have 

validated the planning function in typical and 

untypical missions. 

Figure 8 - Example of planning computation 

The previous planning function gives its 

autonomy to the vehicle when used in 

response to the occurrence of events which 

invalid the current plan (either initial or 

already recomputed). Events are managed by 

the onboard architecture, which calls the 

different planning algorithms according to 

their level of criticity and the current status of 

the vehicle.

On-going tests 


In May 2005, the level 1 was successfully 

validated at sea. It was a very important step 

as this level has direct interaction with the 

vehicle itself. It guaranties an easy software 

integration of all other levels that are already 

evaluated by simulation. 

The 3 rd level architecture has been validated 

by simulation, in nominal and re-planning 

situations. Three types of events have been 

successfully simulated: 

− An alarm event forces the vehicle to move 

directly to the end waypoint: a new 

itinerary to avoid non-navigable areas 

then a new trajectory are computed. 

− When arriving on an objective area, the 

real current is different from the predicted 

one and invalidates the already-computed 

survey: an operative sequence is 

computed taking into account new data. 

− The operator asks for a local operation of 

inspection, for example to inspect a 

suspicious object. A specific operative 

sequence is planned then the vehicle 

resumes its mission. 

The 3 rd level will be tested at sea in March 

and April 06. An example of test will concern 

the current. False current data will be used to 

generate the initial planning. Once on the 

survey zone, real time measurement should 

start the re-planning process. 

Conclusion and future work 

If goal driven planning has proven to be 

feasible in simulation, the recent 

developments made by GESMA, ONERA 

and PROLEXIA push towards a fully 

operational system taking into account: 

− Environmental data from hydrographic 

database and standards, 

− A modular embedded architecture with 

evolutionary potential for onboard 

supervision and re-planning, 

54 

− A user friendly MMI giving advanced 

operator functions for goal mission 

preparation and supervision. 

GESMA future works on autonomy will 

mainly focus on REA AUVs. Their missions 

are mainly characterized by the following 

points: 

- The efficiency of the mission relies on 

the quality of the environmental data 

collected and the percentage of 

surveyed area. 

- The REA AUVs are obviously 

operated in unknown environment (or 

even hostile for some military 

purpose).This lead to increased 

security and autonomy compare to 

survey mission. 

As a response to these difficulties, GESMA 

will conduct works on: 

- Re-planning capacity (adaptativity) 

that will take into account 

performance mapping. This 

performance mapping will assess in 

real time the quality of the collected 

environmental data. If a given 

threshold is not achieved, a new path 

planning is generated to improve the 

overall performance. 

- Real time goal optimisation. Compare 

to classical goal driven mission in 

mine warfare, in the case of REA, the 

goal are modified in real time taking 

into account the collected 

environmental data like currents, 

bathymetry, and water density. For 

example, near shore mission can not 

be geographically limited in advance 

by an operator and the AUV needs to 

find the best reliable path to get as 

near as possible to the beach.


References 

[1] Clough, B.T. (2002). Metrics, Schmetrics ! How 

the heck do you determine a UAV’s autonomy 

anyway ? Performance Metrics for Intelligent Systems 

Workshop. Gaithersburg, MA, USA. 

[2] Goodrich, M.A., D.R. Olsen, J.W. Crandall and 

T.J. Palmer (2001). Experiments in adjustable 

autonomy. Workshop on Autonomy Delegation and 

Control. IJCAI 2001. Seattle WA. 

[3] http://www.cert.fr/dcsd/cd/PROCOSA 

[4] Murata, T. (1989). Petri Nets: properties, analysis 

and applications, Proceeding of the IEEE, 77(4), 541- 

580. 

[5] Little, J.D.C, K.G. Murty, D.W. Sweeny and C. 

Karel (1963). An algorithm for the Traveling Salesman 

Problem, Operations Research 11 pp. 972-978. 

55


ADVANCED CONTROL FOR AUTONOMOUS UNDERWATER VEHICLES 

Michel PERRIER 

Underwater Systems Department 

Ifremer Mediterranean Center 

mperrier@ifremer.fr 

ABSTRACT 

Ifremer operates manned and unmanned submarines for scientific exploration since many years. The need 

for more classical survey AUV (Autonomous Underwater Vehicles) has arisen within Ifremer’s scientific 

programs these past years. The maturity of the AUV technology has permitted to set-up and launch an 

operational program for a fleet of coastal survey AUVs within Ifremer. R&D activities performed by 

Ifremer since many years on advanced control, diagnosis and embedded software architecture, find in this 

new generation of operational Underwater Vehicles a real field of application. 

This paper describes current development on on-board supervision software architecture aiming at 

increasing the security of an AUV and its environment, while improving its performance. 

KEYWORDS: AUV, Intelligent Control, Embedded Architecture. 

1. INTRODUCTION 

Ifremer has been engaged for many years in underwater technologies and in the operational use of 

underwater systems within the French oceanographic fleet. Development of the deep sea ROV victor 6000, 

and a complete upgrade of the well-known manned submersible nautile, are some of the major activities 

undertaken recently by the Underwater Systems Department within Ifremer. 

In parallel to these operational vehicles, and in order to be ready with a new generation of underwater 

systems, R&D activities have been pursued in a wide spectrum of areas, and in particular within AUV 

technologies domain. 

In the context of deep water technology development, numerous projects mainly targeted for offshore 

applications have been conducted recently by Ifremer with European industrial and research partners. This 

effort started in 1998 with the development of the supervised AUV sirene designed for accurate launch and 

deployment of a benthic station [1]. The technology developed in this project has then been applied to the 

swimmer project [2] aiming at developing an hybrid AUV, designed as a shuttle for carrying a classical 

ROV and deploying it once docked on a pre-installed bottom-station. 

The successful development of these projects conducted in going further within the domain of autonomous 

intervention in the frame of the alive project aiming at the development of an Intervention-AUV (I-AUV) 

capable of advanced control for autonomous docking using vision- and sonar-based control. During this 

project, a significant breakthrough in both optical dynamic positioning in a local environment and precise 

autonomous docking was made [3][4]. 

Beyond these technological advances, the need for a more classical survey AUV has arisen within 

Ifremer’s scientific programs. This has led to the set-up and launch of an operational program for a fleet of 

coastal survey AUVs. 

The industrial capability to provide survey vehicles was broad enough in 2002 to justify the launch of an 

international tender for a generic vehicle, which would allows Ifremer to retain control over the continuing 

56


development of other specific technologies related to navigation and positioning, communication, data 

exploitation and modular payload development. 

Requirements and basic specification 

2. AUV PROGRAM AT IFREMER 

Scientific needs have arisen for multi-sensor underwater surveys. This is particularly true in the fields of 

physical oceanography, marine geology and fish stock evaluation in the continental shelf and margin 

regions where socio-economical demands are fuelling the need for more detailed surveys. Those needs 

have led Ifremer in 2002 to launch an AUV program with the aim of using autonomous vehicles for 

operational scientific survey by 2005. 

The analysis of scientific requirements, collected from several French and European oceanographic 

institutes, has led to the specification of a 600 to 800kg, 3000m depth-rated, modular vehicle with more 

than 100km range capabilities, and around 200kg payload capacity. For coastal applications this vehicle 

must be operated by a limited crew team from small (


Figure 1. the aster x AUV © Ifremer 

Control subsystem, networking and data logging 

The VCC (“Vehicle Control Computer”) system is an industrial rack-mounted Compact PCI computer with 

built-in expansion capability. The vehicle I/O uses a combination of distributed and local devices. There are 

digital and analogue input/output, including an Ethernet network switch and serial link. 

A dedicated board provides a Network Time Protocol (NTP) service to other network nodes, and allows 

subsystem synchronisation by generating TTL sequences. Time synchronisation is obtained from the PPS- 

GPS, when satellite lock is available. All data logging performed by the VCC reflects this GPS referenced 

time in UTC. Two Ethernet 100Mb port connections to a network switch are provided to the payloads for 

data communication. 

A 10GB hard-drive stores software executables, mission plans, and vehicle data log files. All critical 

vehicle mission information is logged to the hard-drive during operation, at a configurable desired rate. The 

lists of parameters to be logged are modified on the SCC (“Surface Control Computer”) and archived with 

the mission plan files for future reference. At the end of a mission, data log files are uploaded to the SCC 

and also stored with the mission plan files. 

Surface control and display systems 

For flexibility the surface consoles are portable. They contain the following equipment: 

• The SCC (“Surface Control Computer”). 

• Positioning system 

• DataLinc 2.4 GHz Ethernet radio. 

The SCC has interfaces with the following equipment: 

• Umbilical Telemetry 

• Acoustic Telemetry 

• Radio Telemetry 

• Surface Positioning System 

The operator interface displays vehicle information in both graphical and text forms as appropriate. 

Mission programming 

Mission plans are defined by ASCII text files containing mission task verbs : built-in keywords and 

comments. The built-in keywords are “entry label” and “goto” which together can be used for "looping" 

and "jumping" within a mission. The task verbs fall into two categories: geographic and other. Geographic 

tasks are closely tied to a geographical position (latitude & longitude). Other types of tasks are not closely 

bound to position and include for example the ability to turn equipment on or off for specific parts of the 

58

mission. Each geographic task has a configurable vertical mode (depth or altitude), a vertical setpoint, a 

speed mode and a speed setpoint. Using a series of task verbs with differing depth or altitude setpoint, it is 

possible to plan a mission with virtually any 3D trajectory. The current list of geographic task verbs 

includes “target”, “line_follow” and “circle”, but can easily be expanded by editing a grammar definition 

file and including the necessary configuration to make the AUV carry out the new task. 

The MIMOSA software (“MIssion Management and Operation for Subsea Autonomous vehicle”), 

currently under development and test at Ifremer, will be an optimised tool proposed to the scientific users 

of the AUV for mission description and programming. 

Mission plan files are generated and simulated at the surface console (for final validation), then 

downloaded to the vehicle using any suitable data link, including the Ethernet radio modems. 

Description 


3. ON-BOARD SOFTWARE ARCHITECTURE 

The controller of the vehicle is based on ISE’s ACE (“Automated Control Engine”) system and on the 

already proven architecture used on the “Theseus” vehicle by ISE [6]. The primary capabilities of vehicle 

control software are mission execution, guidance, control, fault detection and energy management. In order 

to provide these capabilities the system is broken down into subsystems. Each subsystem is assigned a 

specific task, which is self-contained, testable and less complex than the system as a whole. The 

subsystems further break down tasks into ACE software components. This approach maximises flexibility 

of the control system. When change is necessary, often only one ACE component is affected in the 

subsystem. 

The VCC (“Vehicle Control Computer”) design is hierarchical with the mission plan manager at the top 

and the low level control loops which control the planes and the thruster at the bottom. The interconnection 

between subsystems is implemented by event propagation. External access to events, to inject or read 

values, is provided by various existing message-passing interfaces. The main subsystems are: 

• Mode Manager: top level system for controlling the overall state of the vehicle, enabling subsystems 

appropriately and includes mission execution control as well as fault management and responses. 

• Guidance: receives trajectory information and waypoint positions from the mission plan manager, as 

well as vehicle position information from the positioning sub-system. 

• Positioning: interfaces with the vehicle navigation sensors and outputs the vehicle position in latitude 

and longitude. 

• Energy Management: monitors past and predicted future energy usage and generates fault conditions to 

abort or modify the mission when problems occur. 

• Control: closed-loop planes position control and closed-loop speed control. 

• Telemetry: Data is transferred between the SCC and VCC via the Telemetry module. The telemetry 

system has been specifically developed to use an acoustic modem, as well as packet radio and Ethernet 

links. 

• Logging: Any data can be logged on the vehicle computer at a configurable desired rate. 

Emergency sub-system summary 

For security aspects, the vehicle is fitted with several devices such as a weight recovery, a self- powered 

Novatech Model ST-400AR strobe light, a self-powered ORE 4336B acoustic pinger/transponder and a 

self-powered Novatech RF-700AR. radio beacon. 

The fault manager system detects vehicle faults and takes pre-defined fault action. These actions can be 

programmed in a look-up table and can be different for various mission phases. Examples of fault 

responses for the vehicle include “STOP and surface”, “STOP and park on the bottom”, “Change mission 

step”, or “Ignore the fault and continue”. 

59


4. DESIGN OF ON-BOARD SUPERVISION CONTROLLER 

R&D activities background 

Ifremer has been involved in ADVOCATE and ADVOCATE II European projects conducted from 1998 to 

2005 which aimed to design and develop modular embedded software architecture for intelligent and 

advanced control of autonomous systems like AUV [7]. 

One of the main objective of these projects was to specify and design a modular software architecture able 

to be plugged onto an existing control architecture. Main efforts have been put on the specifications of the 

interface between existing and new software architecture. This study resulted in the definition of protocols 

of data exchange, nature of data to be exchanged, and level of interaction of the supervision and diagnosis 

software architecture over the existing piloting one. 

The goal of this new software architecture is to detect and diagnose malfunctioning in the monitored 

vehicle in terms of subsystems (sensors, actuators, payload, energy source,...) or behaviour (mission 

execution, high-level control, diagnosis and decision). This architecture and its intelligent components has 

been successfully demonstrated at the end of the ADVOCATE II project on the Atlas Elektronik GmbH 

AUV MiniC in April 2005 [8]. 

Description of PSE 

The outcomes of this project have been exploited by Ifremer for improving the on-board control 

architecture of the aster x AUV by designing the PSE software module (PSE is the French acronym for 

“Embedded Supervised Piloting”). 

PSE is designed as an on-board supervision module able to monitor the functioning of the AUV and its 

subsystems (sensors, actuators, energy source), and to monitor and supervise the mission plan execution 

with the objective to verify the nominal execution of the programmed mission plan and modify locally or 

globally the mission plan when the actual AUV behaviour and functioning is different from the nominal 

one. 

The abnormal situations can be numerous. For instance: 

• Malfunctioning or failure of a subsystem (sensor, actuator,..) 

• AUV behaviour is not the expected one (unforeseen evolution of the environment characteristics like 

underwater current for instance) which can lead to undesired situations such as increasing the energy 

consumption, missing a “rendezvous” in the mission (geographical, temporal,..) 

• Detection of an obstacle 

The specification of PSE has been made in such a way that its activation/deactivation does not impact the 

nominal functioning of the vehicle architecture. In any case, the “last word” is always given to the fault 

management system of the AUV in charge of critical faults management. The PSE objective is to limit or 

avoid undesired mission abortion when the encountered situation is not a real critical one, and when a 

modification of the mission plan or the vehicle configuration can optimise the use of the AUV evaluated 

through the scientific data collection. 

Internal design of PSE 

The PSE module is built around an expert system. All data generated by the AUV or useful for its 

monitoring are handled by PSE: sensors and actuators data, payload status, energy monitoring system, 

mission plan execution,...all types of data are supported by PSE (numerical and non numerical data). 

A rules database, subdivided into “Diagnosis rules” and “Decision rules” with different activation and 

analysis methods managed by a dedicated and powerful inference engine are defined. “Diagnosis rules” 

perform the diagnosis on the situation and produce input data for the “Decision rules” in charge of 

60


determining the best recovery actions to overcome the diagnosed abnormal situation. The set of recovery 

actions contains: 

• Modification of one or several parameters of the nominal mission : for instance, increase the vehicle 

speed in order to be on-time for an imperative “rendezvous”, change the vehicle altitude for increasing 

the quality of the data collected by the payload sensors,... 

• Suspension of the nominal mission plan for execution of a local trajectory (obstacle avoidance for 

instance) and then resume the initial mission 

• Short-cut the nominal mission plan for instance when energy consumption is higher than planned 

• Change the nominal mission plan for a new one (built by PSE or taken from the PSE knowledge 

database) 

Once the recovery actions is determined thanks to the activation of the Decision rules, PSE initiates a 

dedicated dialogue with the vehicle controller in order to apply its decision. 

Configuration of PSE 

The configuration of PSE consists in “programming” the intelligence of PSE: the different set of rules for 

diagnosis and decision, as well as the integration of additional intelligent processes and functions integrated 

within PSE as external functions. For instance, it is planned to integrate automatic mission planning 

algorithms, obstacle avoidance algorithms or advanced diagnosis modules [9]. 

The NEMO software suite 

PSE is part of a complete software suite called NEMO which consists, in addition to the on-board PSE 

module, in a set of different tools dedicated to development, configuration, analysis, and monitoring: 

• Configuration module. Allows to configure PSE: management of the diagnosis and decision rules, 

configuration files, selection of the monitored data, selection of the logged data,... This stage results in 

the production of “PSE configuration files” to be downloaded into the PSE module for execution on 

the AUV 

• Analyser module. Allows to replay and analyse logged data. These data are not the AUV data already 

logged in the VCC, but the internal data produced and manipulated by PSE. For instance, the rules 

fired by the inference engine and the diagnosis and decisions performed during the mission execution. 

• Monitoring module. Used for the supervision and control of the internal/external functioning of PSE 

when a communication link exists with the AUV or when running on the simulation platform. A 

dedicated man-machine interface is then used for displaying the evolution of the internal state of PSE 

(diagnosis and decision rules, data,...) 

Current development and objectives 

A simulation platform is currently under development and will be progressively used for testing and 

validating the PSE module and the associated NEMO suite tools. This simulation platform consists in the 

duplication of the complete computers configuration of the real AUV: SCC and VCC, communication link. 

Within the platform, the AUV behaviour is simulated thanks to a dynamic model of the real vehicle. The 

vehicle state obtained from this model are then injected in a sensor simulation software providing a set of 

message data having the same format than the real sensing devices. This allows to use in the platform the 

same VCC software, with in particular the same protocol and communication links, than on the real 

vehicle. 

The development of the complete NEMO software suite is currently on-going, and will be completed by the 

end of 2006. Progressive integration and test of its software components will be performed on a simulation 

platform of the aster x AUV, allowing to test critical situation without any risk for the real vehicle. First 

implementation and tests of the PSE module on the real AUV are planned for the end of 2006. 

61


5. CONCLUSION 

The PSE supervision module, part of the NEMO software suite, aims to supervise and monitor the aster x 

AUV during the execution of mission. The PSE module will be able to detect any malfunctioning in the 

AUV subsystems, or any abnormal situations during the execution of the programmed mission plan. The 

level of interaction of the PSE module with the vehicle control architecture relies on real-time adaptation of 

mission parameters, or modification of the mission plan itself. 

Preliminary results concerning the first use of the PSE module are expected to be obtained on the 

simulation platform of the aster x vehicle by the end of 2006. Progressive integration and test of PSE on the 

real AUV itself will be conducted later on. 

6. REFERENCES 

[1] Rigaud V., Semac D., Drogou M., Opderbecke J, Marfia C. “From SIRENE to SWIMMER – Supervised 

Unmanned Vehicles: Operational Feedback from Science to Industry”, ISOPE’99, Brest, May 31 – June 4 1999. 

[2] Chardard Y, Rigaud V. “SWIMMER French Group Developing Production Umbilical AUV”, Offshore 

Magazine, October 1998, pp 66-67 

[3] Marty P., (2004), “ALIVE : an Autonomous Light Intervention Vehicle”, Advances In Technology For 

Underwater Vehicles Conference, Oceanology International 

[4] M. Perrier, L. Brignone, “Optical Stabilization for the ALIVE Intervention AUV”, ISOPE 2004, May 2004, 

Toulon 

[5] Ferguson J. “Explorer - A Modular AUV for Commercial Site Survey” Underwater Technology 2000, Tokyo, 

May 23rd - 26th, 2000. 

[6] Ferguson J. “The Theseus Autonomous Underwater Vehicle – An AUV Success Story”, Unmanned Underwater 

Vehicle Showcase 98 Conference Proceedings, Southampton Oceanography Centre, Southampton, UK, pp 99 

[7] ADVOCATE Consortium, “ADVOCATE: ADVanced On-board diagnosis and Control of Autonomous 

sysTEms”, IPMU’2002 (Information Processing and Management of Uncertainty in Knowledge Based System), 

1-5 July 2002, Annecy 

[8] M. Perrier, J.Kalwa, “Intelligent Diagnosis for Autonomous Underwater Vehicles using a Neuro-Symbolic 

System in a Distributed Architecture”, OCEANS Europe 2005, Juin, Brest, France 

[9] M. Perrier, “Autonomous robot health monitoring using neuro-symbolic system “, ISORA 2004, Juin 2004, 

Séville 

62


Session « Industrials » 

63


Compared Architectures of Vehicle Control System (Vetronics) 

and application to UXV 

Jean-Philippe QUIN 

Thales 

ABSTRACT 

Many architecture of electronic system, vetronics, does exist already in the civilian 

area (automotive and more) and in the military field (MBT, IFV, fighters, subs, 

frigates…). These architectures do control either the dynamics of the vehicle, or the 

situation awareness and C4I communication. 

They integrate an onboard human presence able to play a significant part in the 

system management and to fix any incoming failure. 

What is relatively new for UXV (UXV stands for UAV, UGV and UUV) architecture is 

evident: the non-presence of human, letting the system operating by itself in every 

functional mode and with only a weak link to human control. This article is mainly 

UGV oriented but common features with others robots may be found here. 

All things considered, the basic architecture of an UXV must be designed with the 

actual basics (multiplexed, redundant…), COTS/MOTS components, and specific 

functional modes due to this particularity. This a must due to cost, time-to-market, 

buts with a common problem in military field, obsolescence. 

An interesting question is the nature of UXV: does it have to be a specifically 

designed robot, without any possibility to be human driven or is it a manned vehicle 

with a robotized option as needed? 

This presentation will take several models to explain what could be architecture for 

UXV and how recent development in automotive industry can be used in UXV or for 

generic AFV, with adaptation. 

This paper presents a short historical development of automotive, then a compared 

architecture with a common view, with vetronics for UXV, and a conclusion with 

future trends. 

64


A SHORT HISTORY of AUTOMOTIVE and VETRONICS 

The 20-70’s age. 

In the olden times of automotive, architecture was quite simple: linking a button to an 

actuator, linking mechanically a wheel-drive to the wheels, a throttle pedal to the 

engine through a cable, a braking pedal to the brake drums and discs by hydraulics 

pipes. A one to one model. 

The 80-00’s age. 

New criteria appeared: the growing need of new functions leaded by marketing 

efforts, profitability and security pushed to a new design with a better level of safety. 

And the complexity of electric harness was not yet sustainable if 2000 cars must be 

manufactured a day, as quality problems where beginning to be unresolved. 

Considering this new aspect, options offered as ABS, air conditioning, electric 

powered windows are at an upper level of complexity due either to the wiring, the first 

problem, or the need of a global system approach. 

Design and integration of CAN and VAN buses was perceived as the best solution 

but many bad designs lead to problems, specifically in H1 class. 

In parallel, military systems as fighters, subs, frigates and eventually tanks, were 

starting to use own standards, which were after standardizing problems, working but 

at a high cost. MIL-1553B is an example. Just note that debugging tools where very 

poor, not designed for system level. A difficult approach due to the non-deterministic 

control of CAN, still a problem. 

The 00-X0 age. 

Automotive manufacturers understand now, that a global approach is a must: many 

standards as control buses appeared as Flexray, Most, Lin. The physical link is 

copper or fibber optic based, the cost of a connection point is under 1 €. 

Global system approach link the engine, brakes, airbags, steering wheel, suspension 

to provide a high level of security and certainly a must for quality, reliability. What is 

the cost paid by a manufacturer obliged to call back one million of vehicles and the 

bad perception given to the customer (2005). 

In parallel, this kind of problem must not happen in a military system, especially in a 

weapon equipped system. Just imagine a nuke bomber having a serious problem in 

the navigation and attack system during a mission… 

Another new trend in automotive is energy management. As new functions appear, 

de-icing the rear-window, modulated AC with partial zones, navigation equipments, 

electric assistance to the steering wheel or even xenon lights, led to a conclusion: the 

car in traffic messing condition or cold weather, is not able to provide the convenient 

level of energy. Many ways to resolve this issue. 

• Dual batteries, one for common use, the other for engine starting 

• 42 V instead of 12 V combined with alterno-starter (a combination of alternator 

and starter) 

• Hybrid engine as used on Prius or DPE 1 , with energy braking recuperation. 

Note that this last concept is already in use on Leclerc MBT turret. 

1 DPE: Démonstrateur à Propulsion Electrique : a contract conducted by GIAT industries to develop an 

hybrid 6x6 fighting vehicle. 

65


It has to be pointed up that these approaches may be combined. Military vehicle 

should use such energy management in the next vehicle generation but reliability is 

at the corner. Global architecture and subsystems as batteries have to be evaluated 

with respect to the critical issue of a military mission under a GAM-T1 specification 

(temperature, shocks, acceleration) and now, environment. Automotive industry has 

the same problem, but only multiplied by a million time… 

In conclusion, a parallel approach between what is now available on the civilian 

market and what is needed for UXV and military vehicles of any nature is relevant 

with an adaptation of specification: COTS/MOTS can be used with caution. 

COMMON ARCHITECTURE DESIGN 

The following draft the design architecture of a 90’s car. 

Four buses dynamics, security, MMI and body. The last one is only half speed of the 

others due to the functional needs. 

The BSI is the common computer acting as central intelligence and the gateway 

controller. A same architecture can be applied to UXV, with a suppression of the MMI 

function and the airbags feature, if the vehicle will no be used by humans. 

Others functions must be analyzed deeper as rear-view mirrors control or door 

security, depending on the UXV is a pure robot or a robotized vehicle. 

Of course, this analysis is not applicable to UAV or UUV. 

New cars are more and more designed for shared control between the driver and the 

car. The following picture emphasize on brake-by-wire technology. From now, a 

degradation mode in braking system oblige the manufacturers, by legislation, to link 

directly the pedal to the brake. It is the same issue for the driving wheel. 

66


Chief 

Station 

Head Up 

Display 

Chief 

Power & AC 

Management 

ETHERNET 

Pilot 

Station 

Head Up 

Display 

Pilot 

BGIT 

PC2 

Supervisor 

VIDEO 

SOUND 

Distribution 

VME 

COM COM 

Gyrostabilised 

Gimball 

MAST & 

Mechanic Devices 

This is the architecture of the Syrano (right of the design) robot based on 1553B bus. 

Not car architecture but looking like for guidance and pilot functions very close from 

ESP. Difference is seen on the left side of the picture: human control through radio 

link, not a human in the vehicle (here it is an armored vehicle on a Wiesel 2 tracked 

chassis, a 4 tons class). 

Controlling a vehicle at any distance (10 km at max for Syrano) is an issue. Not the 

topic of this article, but a the big issue: teleoperation, semi-autonomy, autonomy, 

many words about a real problem: how to deal with a 60km/h vehicle running in all 

terrain navigation without being a little bit concerned about. 

Let us see about automotive control, as an inside driver. 

VME 

Bus Manager 

& Supervisor 

VIDEO 

SOUND 

Concentration 

Things are changing on automotive: many new cars have an electric handbrake 

(BMW, Renault…) and electric brakes, what can be seen as the ultimate 

development, is pushing. 

The other trend is wheel drive assistance. We started with nothing in olden time, a 

tractor view. We have now hydraulic and electric assistance, with a force modulated 

1553B 

Mast 

Computer 

PC2 VNH 

67 

M2 

Computer 

GUIDANCE PILOT 

EFFECTORS 

Con. Box 

3D LASER 

Sensor 

Perception 

Computer 

SENSORS 

Con. Box 

INU 

POWER 

MANAGEMENT 

& 

DISTRIBUTION


with respect to speed, dynamic attitude and either condition as parking. As said 

above, the engine control is already done by wire. This control needs a sensor to 

measure the position and the speed of the action on the driving wheel as well as 2D 

inertial attitude of the vehicle for ESP function, 3D for SUV. 

The combination of these controls enables the control of vehicle dynamics through 

the well-known ABS, ESP and other ASB derivative functions. An ABS system need 

the tuning of other 500 parameters, how many for an ESP system? 

All these sub-systems can be used in a UXV, more specifically for an UGV. As the 

sub-system can be controlled through a bus it can easily be used on an UGV. 

APPLICATION to UGV 

Either bus architecture, or use of already existing sub-systems is applicable to UGV. 

The idea is to see how a generic modern vehicle can be robotized at a lower cost 

with a double function, be human driven or be robot driven. Examples given for 

mobility control. 

BUS 

CAN bus is now used in military vehicle (VBCI of GIAT industries and Renault Truck 

Defense) or in the FRES program (UK) of the MilCan, an adapted version of the 

civilian standard. 

The main adaptation is to change the non-deterministic control of CAN to a 

deterministic one due to “hard” real-time behavior. This evolution has two interests: 

guarantee of a fast responding system in a determined slot of time, and make easier 

the integration of the system as a deterministic system: what you order is what is 

done in a timed schedule. 

BRAKES 

Security even for an UGV is mandatory, so braking control is. 

The left part of the drawing presents the primary and secondary brake lines for 

security purpose. On the right, the assistance to the driver on the brake pedal is done 

with the vacuum booster. If adapting a pneumatic valve on a side of the diaphragm, 

one can control easily the braking force without any mechanical actuator and allowing 

a human braking of the vehicle simply by disabling the valve, left it closed. 

68


ABS is to be added to the control of the robot, including emergency braking: these 

functions are fully compatible with an UGV. One can use the odometers on each 

wheel, without any extra cost. 

DIRECTION 

Hydraulics with pump, pipes and a non-linear comportment is going to be more and 

more replaced by electric assistance for the driving wheel. 

Electric assistance is under the control of a computer linked to sensors: position and 

velocity. This is used to lower the force needed on the driving wheel but also to be 

combined with trajectory control (ESP function) as well as parking aid. 

The idea, for UGV, is to revert the electric assistance using the motor but inverting 

the mechanical gearbox as there is no force on the driving wheel as no driver. The 

amplifier may be used without any change, just be controlled by another computer, 

the robot one. A simple by-pass switch insures the commutation between human and 

robot drive. 

But to add more agility to a wheel-based robot, it is better to disable the ESP 

function. Many reasons and a legal one: ESP must not control the direction while in 

action. 

Nevertheless, a direct control of the direction while braking, with an ABS at less of 3 rd 

generation, and by controlling same side brakes of the vehicle offers a better 

dynamic control. 

For a robot there is no limitation for comfort in lateral G’s as far as the dynamic 

stability is insured. What is done with 2 axes inertial unit, what can be found with 

Fog’s or integrated silicium device. For robotic purpose, an independent INU seems 

to be more convenient. 

GAS PEDAL 

Nothing more to say that new cars, and all diesel engines have a drive-by-wire to 

control the throttle. And the pedal has a position sensor. The control of such a 

device is evident. 

GEAR BOX 

Typical “analogical” gearbox is presented here. Based on hydraulics, pump, valves, 

sensors and very particular devices. 

69


Evolution is on the way. 

Automatic and Manual gearbox 

Manual automatic and now robotized gearboxes are on actual and coming vehicles. 

The best for UGVs, and for drivers, is of course the robotized gearbox as the last 

Quickshift from Renault. 

As far it may be controlled trough paddles, any embedded computer may control it. 

The main issue is to get specific sensors outputs as engine speed, the gear engaged 

etc… 

From now, we have a complete car able to be transformed to an UXV. But what is 

needed to transform a car to UXV to be fully under control? Intelligence. A great word 

as far we now. 

70


Control and Command 

As seen before, all components are present in the automotive world. 

UXV, and specifically UGV need more: a shared control between operator and the 

robot. A mandatory design for robots is a mode oriented one. The robot has to be in 

already designed modes, no more, no less. A steady state in any condition. 

DEGRADED 

MODES 

NOMINAL 

MODES 

LEARNING 

MODES 

Modes transition (simplified) 

HARMONIZATION 

MODES 

Modes are designed to control the robot in any situation: nominal mode is the normal. 

Degraded mode is operating as any incoming failure occurs. In this latest state, robot 

control must deal with diverse situation without any help, as in automotive world 

where a car is supported by human assistance. The most complex mode. 

Steady state means a known level of control in any situations and is the graal for 

robotics control. Situation uncertainty is the common view and to control it, a robust 

architecture must be implemented. 

Robot control has to be understood as a balanced system: a fully controlled system, 

under human supervision or an autonomous one, able to care with any happening 

hazard such as fixed obstacle, and more as moving obstacle, or deceptive obstacle 

as ponds, moving trees… And this is the only matter addressed for mobility, mission 

is another issue. 

Robotics research is a passion and the most that can be done at now, is to propose 

what can be named a «shy» system. 

The present UGV science is not still able to do everything, but must be able to protect 

the robot itself and to support for what it is built, the mission as the only and final 

requirement. 

71


Intempora S.A. 

“Real Time, Multisensor, Advanced Prototyping Software” 

The RT Maps software allows to easily connect any type of sensors and actuators, to 

acquire, record, process and transmit every data, in real time. 

• A generalized digital recorder, a 

platform for acquisition, recording and 

processing of all data types, in real time. 

• A software associating a simple and 

intuitive interface and a robust technology. 

• A multisensor measurement instrument, 

powerful, precise and adaptative. 

• A capacity to date, read again and exchange 

with precision quantities of information. 

72 

• A development platform to create 

one’s components and add them 

to the many others provided. 

• A link between data, allowing their fusion 

and their transmission towards actuators. 

• A methodology allowing to program 

graphically and easily complex applications. 

• A link between theory and practice, 

experimentations and applications. 

RT Maps 

• A tool to master the most innovative projects... 

Have a good real time !

A New Multisensor Technology 

In 2000, the Carsense European project, gathering 

industries (FIAT, BMW, Renault, Thales, Ibeo) and research 

labs (INRIA, LIVIC...) looked for a digital data logger and 

chose a solution developed by the «Centre de robotique de 

l’Ecole des Mines de Paris»: RT Maps. The objective was the 

perception of the objects around a moving vehicle. It was 

the first use of RT Maps. RT Maps is now adopted by important 

industrial groups (Renault, PSA, Valeo...) and by national 

and European projects (Arcos, Puvame, REACT...). 

Time and measurement play an essential part in the industrial 

and robotics applications: hence RT Maps precisely dates all 

data at their time of acquisition. This dating process provides 

a complete data flow control during the data processing and 

replaying. During the tests, situations and behaviors can 

be recorded and analysed later. Reproducing a situation is 

thus possible. RT Maps makes easy the link between real and 

virtual worlds. 

Connect, record and compare all types of sensors 

and actuators 

Any device suitable for connection with a computer, can be 

dealt with by RT Maps. Information from the sensors is acquired; 

processed data is sent to the actuators; inbetween, a 

working space is dedicated to the user. Connections between 

various elements are achieved graphically without any difficulty. 

The substitution of a sensor by another is thus done 

quickly. Comparison of information obtained according to 

various types of sensors or technologies is straightforward: 

video cameras, analogical and numerical ways, CANbus, 

GPS, radars, laser... A recorder allows the simultaneous recording 

of various tracks of information. Information is stored 

in STDB, Synchronized Timestamped Databases. When 

replayed, the sequence is reproduced identically thanks to 

the data timestamps. It is possible to play information at the 

desired speed: accelerated, slowed down, step by step... 

A controled investment 


The graphical interface allows a fast installation and an 

easy evolution of the different applications. Functional 

bricks (in the form of components) and data (STDB) are 

exchangeable and reusable. The test and experimention 

phases are simple and fast to implement. While allowing 

to save a considerable amount of time, RT Maps’ use 

reduces the development costs and the « time to market 

». In perfomance and efficiency, RT Maps’ potential 

warranties a fast and convincing return on investment. 

RT MAPS, INTRODUCTION 

References et partners 

73 

A «diagram» example in RT Maps’ workspace. It represents a complete 

application. Various sensors are connected, allowing to send, 

in real time, information towards an actuator ( here a wheel). All this 

information is posted simultaneously. 

Fuse data in real time and prototype effectively 

Data fusion of information from various sensors, different or 

not, increase the reliability and robustness of the results. It 

also allows the use of less expensive sensors. Several assumptions 

can be easily tested in order to satisfy the most 

complex needs. It is easier to perform more tests in simulated 

situation with real data, to identify problems and to 

correct them progressively, before engaging the product in 

real conditions of experimentation or production. 

Preserve and share knowledge and data 

It is always difficult to collect data corresponding to the real 

situations. With RT Maps, such sequences can be preserved 

and easily exchanged thanks to the STDB. They are reusable 

at will. RT Maps allows the users to build important data 

banks in order to capitalize and share all the experiments. 

Team work and project management are really simplified. 

New releases and updates 

Intempora permanently improves RT Maps. Updates are regularly 

posted on the Internet site and accessible to all the 

users under maintenance contract. Major release are the results 

of important technological, functional and/or ergonomic 

improvements. The migration towards each higher version 

is easy. The investments of each user are thus preserved; 

data bases and diagrams remain valid and can benefit of 

the new tools and available evolutions. The third version of 

RT Maps is installed and used by our clients since june 2005.


The studio : graphical programming 

The Studio is RT Maps’ graphical interface. Applications are 

represented by diagrams made of components which can be 

parametrized. Efficient and simple to use, the Studio is one 

of the many advantages of the software: a few minutes are 

enough to set up a complex application. Components, libraries, 

diagrams, data bases and scénarii can be exchanged 

and integrated. 

Components and connections 

The components, symbolized by blue boxes, are set 

up by simple drag and drop onto the scene. They 

interface the sensors, represent the algorithms and 

connect the actuators. The mouse allows to draw 

«lines» connecting the output of a component to the 

input of another. The dataflows are then etablished. 

Setting 

Many parameters are accessible by dialogboxes. The setting 

determines the component’s behavior. 

Documentation 

A simple click is enough to insert a comment in a diagram 

or to get help. 

Modularity 

When the user wishes to remplace or add a component in a 

diagram, it does it graphically, without any coding. 

Recording and replaying 

A «record» button launches the recording process. The 

VCR allows to play back the data bases. The replay speed 

and direction can be chosen. A cursor allows to select the 

position in the timeline. 

Master 

Slaves 

RT MAPS, TECHNOLOGY 

74 

Embedded technology 

The programming graphical interface can be removed for 

a «hidden» use of the software. The orders of construction 

and parameter setting of diagrams are passed 

through scripts. Specific graphical interfaces can be 

developed to execute applications : they replace the usual 

workspace. 

Synchronized distributed operation 

RT Maps V3 breaks a technological barrier by allowing the 

operation of distributed and synchronized platform on several 

machines. A «master» system manages the whole application. 

A single clock supervises and synchronizes those of the various 

«slaves». The «Master» clock can be the one of the «master» 

host or coming from an external source: clock of an acquisition 

board, GPS clock... 

RT Maps technology is independant of the operating system 

used, even in a distributed configuration. Thanks to this new 

flexibility, RT Maps can satisfy the processing needs of the most 

demanding applications.

The library: components ready to be employed 

The RT Maps libraries are sets of components which provide 

elementary functions necessary to most applications: 

- Data acquisition 

- Standard protocole decoding 

- Data processing 

- Real time displaying 

- Data recording and replaying 

- Data exportation 

- Interfacing with third party software 

- Communication 

The software supports the majority of the market’s available 

sensors. Intempora provides many modules to interface sensors/actuators 

of very different natures and performances. If an 

hardware is suitable for connection with a computer, its integration 

in a RT Maps application is possible. 

Exemples of supported sensors: 

Webcams, DV camcorders, FireWire DCAM digital cameras, 

analog and digital cameras, stereo-vision devices, GPS, inertial 

measurements units, radars, laser telemeters, CAN bus, 

analog and digital input/output devices, microphones… 

Exemples of supported actuators: 

Analog and digital controls, electric motors, step by step motors, 

brake or other car system, barriers, hooters, light, variable 

messages indicators… 

New developed components are regularly added to the 

libraries. 

Intempora 


More Informations 

Please contact us ! 

Marketing: Gilles MICHEL 

Technical aspect: Nicolas du LAC 

Tel: +33 1 41 90 03 59 

Web Site: www.intempora.com 

Email: info@intempora.com 

The SDK extension: breaking the limits 

The «Software Development Kit» allows the user to 

create its own components. The programming is done 

in C++; it is facilitated by the skeletons’ code and macro. 

Moreover, a complete API (Application Programming 

Interface) allows you to reach all the engine’s function 

and to remain independant of the operating system 

(file system or real time programming for example). 

Unless specify otherwise, each component runs 

in its own thread. The developer is released from 

the problems of data protection and inherent 

concurrent accesses of multithreads applications. 

Many data exchanges policies between components 

are integrated (circular buffers, unblocking, D-sampling, 

etc...), thus offering the behavior choice fitting to each 

application type (recording, real time processing, data 

conversion, control...). The user can, for example, include 

the variables parameter setting or make dynamic the inputs/ 

outputs number suggested by the graphic component. 

The SDK includes the API’s complete documentation and 

examples or skeletons code for the specific components 

development. Finally, integrated assistants are included 

into the development environments (such as Microsoft’s 

Visual Studio ). They facilitate the generation of compilation 

projects. 

RT Maps, a responsible and durable choice, 

an opening towards new projects and a renewed effectiveness... 

75 

Test RT Maps Version 3…

DES (Data Exchange System), a publish/subscribe architecture for robotics. 

Abstract 


C. Riquier, N. Ricard, C. Rousset 

ECA 

Rue des Frères Lumière 

83130 La Garde 

This paper presents ECA software architecture for robotics projects such as Miniroc or AUVs. 

This architecture is made of two parts: 

- Software architecture is the tool to exchange data between processes � the DES: Data 

Exchange System. 

- Functional architecture is the organization of processes in order to fulfill robot 

functions. 

This paper presents the DES layer and gives an example of utilization. 

The DES is based upon a publish/subscribe design. 

A Process is a publisher of the data it “creates”, and a subscriber to the data it needs. It 

doesn’t need to know which process will publish the data it needs, neither which will use the 

data it publishes. Communications are based upon TCP/IP channels directly between the 

publishers and the subscribers. A “Mediator” manages all communications between 

processes. All processes ask what they want and tell what they can give. The Mediator tells 

everyone who can give what they want. Then all communication links are established directly 

between processes. At anytime, a process can ask something more, or stop sending a data. The 

Mediator also deals with process disappearance or arrival. 

The same data can be published by several publishers with different priorities. Data can have 

a period of validity. 

Processes can be on different computers and they don’t need to know where the other 

processes are. 

This architecture allows modular hot plug of payloads on robots. 

76


I - INTRODUCTION 

Several years ago (last century in fact !), all ECA robots were based upon point to point 

client-server architectures. Most of them had only two processes: one for HMI and one 

embedded in the vehicle. 

Around year 2000, according to the increasing complexity of robots (more sensors, more 

autonomous behaviors, more computers, …), the need of a distributed, reusable and flexible 

architecture arises. 

Among available concepts of architecture, we chose the “Publish – Subscribe” one. The first 

chapter compares three kinds of possible architecture. 

The first “Publish – Subscribe” architecture we developed was named “BDC” (Broadcast 

Data Center). Our first AUVs were built around it. After two years of utilization, and 

according to robots more and more demanding for “real time” performances, we specified 

some improvements of the BDC which has been renamed “DES”. 

This paper only describes the DES architecture which now equipped our AUVs and 

“Miniroc” ground robots (military robots for DGA). 

The last chapter of the document illustrates the utilization of the DES, with an example 

extract from the Miniroc architecture. 

II – COMPARISON OF SEVERAL COMMUNICATION ARCHITECTURES 

Distributed real-time applications have unique communication requirements. Real-time 

applications must handle different kinds of data flow, such as repetitive updates, single-event 

transactions, and reliable transfers; many nodes intercommunicate, making data flow 

complex; and dynamic configuration changes occur as nodes leave and join the network. 

Strict timing requirements further complicate the entire design. 

Traditional client-server architectures route all communications through a central server. This 

makes them ill-suited to handle real-time data distribution. Publish-subscribe architectures, 

designed to distribute data to many nodes simultaneously and anonymously, have clear 

advantages for real-time application developers: they are more efficient, handle complex 

communication flow patterns, and map well to underlying connectionless protocols such as 

multicast. 

Distributed application developers have several choices for easing their communications 

effort: 

• Client-server, either in the traditional form of a central server node intermediating for a set 

of clients or its updated manifestation – distributes objects and object brokers 

• Publish-subscribe, in the form of middleware that distributes data – publications – 

anonymously among applications in one-to-many patterns. 

II.1 Client-Server Architectures 

Client-server communications generalize the data flow by allowing one server node to 

connect simultaneously to many client nodes. Thus, client-server is a many-toone 

architecture. It works well when the server has all the information. Examples of client-server 

applications include database servers, transaction processing systems and central file servers. 

When the data is produced by multiple nodes for consumption by multiple nodes, clientserver 

architectures are inefficient because they require an unnecessary transmission step: 

77


instead of direct peerto-peer, the data must go through the server. The transmission to the 

server also adds unknown delay to the system. Furthermore, the server can become a 

bottleneck and presents a single point of failure. Multiple-server nets are possible, but they are 

very cumbersome to set up, synchronize, manage, and reconnect when failures occur. This 

resolves bottleneck and point-of-failure exposures, however it only increases inefficiencies 

and bandwidth consumption. 

II.2 Object Brokers 

CORBA and DCOM are the best-known examples of distributed object architectures. 

Distributed objects architectures are middleware that abstract the complex network 

communication functions and promote object re-usability, two features that substantially 

reduce the programming effort. Object brokers do not address several distributed realtime 

application data flow characteristics, however: they offer little support to control the 

properties governing deterministic data delivery (especially important for signal data) and are 

cumbersome and unwieldy when programming dynamic, many-to-many flow patterns. This 

largely derives from the distributed objects inherent and fundamental reliance on a broker 

to route requests and its object management requirements. 

II.3 Publish-Subscribe 

The publish-subscribe architecture is designed to simplify one-to-many data-distribution 

requirements. In this model, an application "publishes” data and "subscribes" to data. 

Publishers and subscribers are decoupled from each other too. That is, 

• Publishers simply send data anonymously, they do not need any knowledge of the number 

or network location of subscribers. 

• Subscribers simply receive data anonymously, they do not need any knowledge of the 

number or network location of the publisher. 

An application can be a publisher, subscriber, or both a publisher and a subscriber. 

Publish-subscribe architectures are best-suited to distributed applications with complex data 

flows. 

The primary advantages of publish-subscribe to applications developers are: 

• Publish-subscribe applications are modular and scalable. The data flow is easy to manage 

regardless of the number of publishers and subscribers. 

• The application subscribes to the data by name rather than to a specific publisher or 

publisher location. It can thus accommodate configuration changes without disrupting the data 

flow. 

• Redundant publishers and subscribers can be supported, allowing programs to be replicated 

(e.g. multiple control stations) and moved transparently. 

• Publish-subscribe is much more efficient, especially over client-server, with bandwidth 

utilization. 

Publish-subscribe architectures are not good at sporadic request/response traffic, such as file 

transfers. However, this architecture offers practical advantages for applications with 

repetitive, time-critical data flows. 

78


III –DES: Data Exchange System 

III-1 – General Principles of Publish – subscribe architectures 

Several main features characterize all publish-subscribe architectures: 

Distinct declaration and delivery. Communications occur in three simple steps: 

• Publisher declares intent to publish a publication. 

• Subscriber declares interest in a publication. 

• Publisher sends a publication issue. 

Named publications: PS applications distribute data using named publications. Each 

publication is identified by a name by which a publisher declares and sends the data and a 

subscriber declares its interest. 

Many-to-many communications support: PS distributes each publication issue 

simultaneously in a one-to-many pattern. However, the model’s flexibility helps developers 

implement complex, many-to-many distribution schemes quite easily. For example, different 

publishers can declare the same publication so that multiple subscribers can get the same 

issues from multiple sources. 

Event-driven transfer. PS communication is naturally event-driven. A publisher can send the 

datum when it is ready. A subscriber can block until the datum arrives. The publish-subscribe 

services are typically made available to applications through middleware that sits on top of 

the operating system’s network interface and presents an application programming interface 

(see Figure 1). The middleware presents a publishsubscribe API so that applications make just 

a few simple calls to send and receive publications. The middleware performs the many and 

complex network functions that physically distribute the data.. 

Figure 1. Generic Publish-Subscribe Architecture 

79


III – 2 – DES overview 

All processes of the architecture are called “Agents”. 

There is one special agent which is essential: the MEDIATOR 

It is the “heart” of the DES. This Deamon is connected with all the agents running in the 

system. Any time a new data flow is required or an existing data flow disappear, the Mediator 

send to the concerned agents the pieces of information they need to establish or destroy the 

data flow. So the Mediator neither sends nor receives any data flow. It just establishes them 

directly from publisher(s) to subscriber(s). 

The figure 2, shows the sequence of life of a data flow: all the transitions between the steps of 

life are supervised by the Mediator. 

The figure 3, shows the data flow itself once it is established (in the state “Publication” of the 

figure 2). 

Figure 1 : sequence of life of a data flow 

80


DES 

Subscriber 

Three over system processes can be used: 

Mediator 

deamon 

Publication of the data 

Figure 2 : data flow publication 

SWC: SoftWare Controller : 

This service is a daemon which starts all the agents (including the Mediator), monitors them 

(from the OS point of view). Some of the agents are defined as “critic”. If one of the critical 

agents crashes, the SWC halts all the system properly. 

DRC: Data Recording Center 

This service is a special agent which subscribes to all the data you have configured, and 

records them with the date. 

NTS: Network Time Synchronization 

This service is not really part of DES architecture but it is required for dating of data, as soon 

as the architecture is distributed among several CPUs. We use the NTP (Network Time 

Protocol) implementation provided with the OS. 

III – 3 - Different ways to exchange data through DES 

DES 

Publisher 

The basic principle of publish subscribe is that the subscriber does not decide when to receive 

the data. It receives it when the publisher publishes it. 

However the DES has a middle layer between data reception and the call from agent 

functions, which allows several ways to exchange data. 

The event publication: 

The publisher publishes its data. The subscriber DES layer receives it and run the associated 

callback of the subscriber agent. This allows you to synchronize the subscriber treatments on 

reception of data. You typically use this to synchronize a perception and guidance agent on 

the reception of the sensor acquisition agent. 

81


The unsynchronized publication: 

The publisher publishes its data. The subscriber DES layer receives it and store it. The 

subscriber agent can access the data when it needs it. Only the last data received is stored. 

You typically use this to get some parameters that you don’t need to use when they are 

published, but only when you start your own treatments. It also allows you to get a data which 

has been published before your agent was started. For example, the kind of robot you are on, 

or the parameters of the current camera when you want to do some visual treatments on it. 

The event publication with FIFO: 

Same principle than the event publication but all received data are stored in a FIFO buffer and 

one event per data is generated, even if your precedent treatment is not completed. For 

example the subscription to a fire order need to receive all the order sequence (FIRE followed 

by a CONFIRM). 

The unsynchronized publication with FIFO: 

Same principle than the event publication, but all received data are stored in a FIFO buffer, 

and each time the agent request a data, the oldest received data is returned. 

The event publication with a validity period: 

The publisher defines a time of validity (T) on its data. An event is generated in subscriber 

agent when the data is received. Another event is generated T sec after the reception and the 

data is turned invalid. For example the mobility commands published to the agent dealing 

with the robot drive are using a validity period. 

The unsynchronized publication with a validity period: 

The publisher defines a time of validity (T) on its data. The data is available for the subscriber 

during T sec after the reception. After that delay, if the subscriber accesses the data, an invalid 

access is returned. 

The multiple publications without priority: 

Several publishers can publish the same data. If you don’t define any priority, all published 

data from all publishers are received by the subscriber (all the precedent kinds of publication 

can be used). 

The multiple publications with priorities: 

Several publishers can publish the same data with different priorities. Only the data from the 

higher priority publisher, is received by the subscriber. 

82


IV – DES Use Example 

A typical illustration concerns the mobility commands of a mobile robot. 

In our architecture the agents interfacing with hardware are named”EV” (for Virtual 

Equipment). 

The example consists in: 

- the “Laser EV” : 

o it acquires the laser rangefinder data 

o it publishes them periodically, event driven by the hardware acquisition. 

- the “Vehicle EV” : 

o it subscribes to all the commands the vehicle is waiting for. 

o it publishes all the data coming from the vehicle 

- a “Guidance Agent” : 

o it subscribes (event driven subscription) to EV laser data. Thus, the guidance 

treatments and the mobility command publication are synchronized on the 

laser data publication. 

o it subscribes to the odometry data (unsynchronized subscription) : when the 

agent receive a laser data, it accesses to last receive odometry data and utilizes 

dates of data to resynchronize odometry with laser data. 

o it publishes mobility commands 

- a “Teleoperation Agent” : 

o it acquires the operator HMI commands 

o it publishes them periodically only if the operator want to take over manually 

the control of the vehicle. 

Let’s focus on mobility commands data flow: 

- two publishers are able to publish these commands with different priorities : 

o higher priority for téléopération : the operator can supervise the autonomous 

guidance and take the hand over if a problem occurs. 

o lower priority for autonomous guidance 

- the data published have a validity period, so : 

o the vehicle stop in case of communication loss with the HMI. 

o The lower priority publisher take the hand back, when the higher priority 

publisher stop to publish 

On this very little example, let’s imagine some evolutions: 

- You want to decrease the number of CPU � copy your payloads applications on the 

vehicle CPU and plug your laser on the vehicle CPU. Everything is still working 

without any recompilation neither configuration. 

- You want to use your payload on another robot � plug your all payload on the 

Ethernet switch of the other robot, and give it the address of the new vehicle Mediator. 

If the new vehicle does not already have a DES Virtual Equipment, you just need to 

develop the hardware interface. 

83


Payload CPU 

Guidance 

Agent 

Laser 

EV 

Laser 

Figure 4: example of data flow 

84 

HMI CPU 

Teleoperation 

Agent 

Vehicle 

EV 

Vehicle 

Vehicle CPU 

Mediator


Modular Distributed Architecture for Robotics 

Embedded Systems 

Pierre Pomiers, Vincent Dupourqué 

Robosoft, Technopole d'Izarbel, 64210 Bidart, France 

Tel: +33 5 59 41 53 66 

Fax: +33 5 59 41 53 79 

E-mail: pierre@robosoft.fr 

Abstract 

Tomorrow, advanced transportation robotic applications have to be able to cope with various situations and 

perform many different tasks in a dynamic and changing environment. Furthermore, finding concrete 

applications in a wide range of user oriented industrial products, such systems, embedding several 

computing units, have to cope with an increasing demand of interactivity and to support number of noncritical 

pieces of hardware and software. This whole set of different capabilities needs to be performed 

reliably and safely over long time periods. To this aim not only advanced programming techniques, but also 

appropriate control architectures are required. For these reasons, Robosoft proposes both a set of hardware 

and software components developed from our own experience in the field of automatic transportation of 

people and goods, which can be easily adapted to robotic solutions for outdoor risky interventions. 

1 Overview 

Most papers concerned with real-time embedded application design present experimental tests showing that 

theoretical results, obtained from formal analysis, match real-time behavior of embedded system. But they 

do not consider critical aspects of integrating, or interfacing, with other non-real-time compatible processes 

such as complex high-level control system or user-end applications. To override the complexity of 

computing such application algorithms, the control software is built using a dedicated software 

environment: iCORE. iCORE relies on the SynDEx 1 data flow graph formalism (introduced by INRIA) 

which objective is to provide rapid prototyping and error free implementation procedures for distributed 

and heterogeneous application. 

From this flexible and reliable development approach, we present how our advanced mobile 

systems could be easily used and customized for implementing outdoor applications, and guaranteeing 

integrity during risky interventions. Each point of the method is mainly discussed through one of the 

Robosoft transportation products: the robuCAB. It is a car-like mobile platform designed specifically for 

urban applications as well as automated transport. Last, in order to illustrate the possible robot operating 

mode, we will focus on software modules covering various needs: autonomous navigation, fleet 

management, remote control, specific HMI... 

2 iCORE development environment 

Robotics solutions, we describe here, make use of custom control architectures (composed of one Intel x86 

Linux/RTAI machines and from one to 8 Motorola MPC555 based control boards 2 ) with CAN buses as 

communication media. This section covers both the development and embedded targets environment. 

1 Synchronized Distributed Executive 

2 cb555 boards manufactured by Robosoft as part of his own control system products 

85


2.1 iCORE: an approach based on SynDEx methodology 

The application development method discussed here makes use of both SynDEx tools and Robosoft 

kernels. Developed by INRIA, SynDEx V6 is a graphical interactive software (see Fig. 1) with on-line 

documentation (refer to [3]), implementing the AAA 3 methodology. Here is the list of services offered by 

the couple SynDEx and Robosoft proprietary kernels: 

• specification of an application algorithm as a conditioned data-flow graph (or interface with the 

compiler of one of the Synchronous languages ESTEREL, LUSTRE, SIGNAL through the common 

format DC) 

• specification of a multi-component as a graph 

• heuristic for distributing and scheduling the algorithm on the multi-component with response time 

optimization 

• visualization of predicted real-time performances for the multi-component sizing 

• generation of dead-lock free executives for real-time execution on the multi-component with optional 

real-time performance measurement. These executives are built from a processor-dependent executive 

kernel. SynDEx comes presently with executives kernels for various digital signal processors, 

microprocessors and micro-controllers. 

The distributing and scheduling heuristics as well as the predicted real-time diagram, help the user to 

parallelize his algorithm and to size the hardware while satisfying real-time constraints. Moreover, as the 

executives are automatically generated with SynDEx, the user is relieved from low level system 

programming and from distributed debugging. This allows optimized rapid prototyping and dramatically 

reduces the development cycle of distributed real-time applications. 

3 Algorithm Architecture Adequation 

Fig. 1: Application design example using SynDEx CAD 

86


The SynDEx development system described above is able to generated executive binaries for various types 

of target including the ones that compose the Robosoft control platform. Robosoft control architecture 

typically embeds one or more MPC555 based boards and an Intel x86 Real-time Linux computer. 

2.2 Robosoft cb555 control board 

The Robosoft cb555 [4] board (see Fig. 2) is a stand-alone four axis controller designed for critical 

industrial process handling. Including a 32-bit PowerPC architecture, it provides high computation 

performance (refer to Table 1 for a detailed description of boards IO capabilities). 

Fig. 2: The cb555 Robosoft control board 

2.3 Robosoft emPC and wsPC computers 

Table 1: Robosoft control board connectors description 

The context of real-time embedded applications programming is quite different from the classical one, user 

usually meets. This notion of "real-time" is not present in normal Linuses. Such real-time dedicated 

mechanisms can be added by installing an RTOS 4 on top of Linux standard kernel [1] [2]. Robosoft based 

both emPC and wsPC product ranges (resp. for embedded and workstation computers) on RTAI version 

which is widely used in embedded industry for prototyping and which is supported by very active 

companies. 

RTAI basic principle is rather simple. RTAI provides deterministic and preemptive performance in 

addition to allowing the use of all standard Linux drivers, applications and functions. To this aim, RTAI 

decouples the mechanisms of the real-time kernel from the mechanisms of the general purpose Linux 

kernel so that each can be optimized independently and so that the real-time kernel can be kept small and 

simple. In our case, the primary function of RTAI kernel is to provide real-time tasks with direct access to 

the raw hardware, so that they can execute with minimal latency and maximal processing resource, when 

required. 

3 The robuCAB implementation 

The robuCAB platform (see figure 3) is a mobile robot offering great transportation capabilities, able to be 

driven over urban environments (such as cities, campuses...). Consequently, this platform perfectly fits a 

wide range of missions: autonomous transportation, tele-operation, fleet supervision... The platform control 

is handled by a heterogeneous architecture composed with both cb555 boards and an embedded PC. Figure 

3 shows how hardware units are organized: two cb555 controllers dedicated to low-level critical loops, 

while the embedded PC focuses more on advanced algorithms and interfaces with asynchronous devices 

such as wireless network, GPS, laser scanner... Real-time communications sequences between cb555 

4 Real-Time Operating System 

87


boards and PC rely on a CAN bus, while higher level communications (toward supervisors, network 

databases, web server, as well as any other non-real-time devices) are realized trough classical Ethernet 

links or serial lines. 

Fig. 3: The robuCAB platform 

Fig. 4: robuCAB control architecture 

Thanks to a very modular hardware and software structure, robuCAB can handled a wide set of application. 

As an illustration, let us focus on figure 5. It represents the structure of a supervised transportation 

application. Several software levels are depicted, from the most critical 1kHz task to the fully aperiodic 

web oriented processes: 

• 1kHz control loops driving the four independent motors and the two independent steering jack servos 

• a 100Hz loop dedicated to speed and steering profile computing 

88


• an asynchronous level (running under Linux) handling both DGPS and LMS 5 

• aperiodic supervision processes with both web page and database update (running over one or more 

computers connected to a network) 

Relying on iCORE environment (merging the best of SynDEx programming methodology and Robosoft 

modular proprietary kernels), these software levels implementation lead to highly predictable and safe 

application executions, as well as safe (non-blocking) interactions between software levels. 

Fig. 5: robuCAB application structure 

4 iCORE approach: a decisive step to both hardware and software modularity 

Over the robuCAB example, we show that fairly complex and exhaustive software applications may be 

implemented, covering all the needs required for transportation missions. The iCORE approach, we 

5 LMS SICK laser scanner 

89


propose, appears to be very well adapted to robotics software development and, moreover, bring a very 

interesting modular concept. With iCORE approach, modularity is twofold. 

First, relying on SynDEx methodology, iCORE provides users with hardware modularity. This 

means that once an application is written for a given architecture (composed with a set of cb555, PC and 

CAN buses), it is able to run on an extension of this architecture without any modification. Hence, 

extending the computing capabilities of a robotics platform is totally effortless: application is automatically 

redistributed in order to handle the new architecture resources. 

Secondly, iCORE approach also provides user with software modularity. As shown on figure 1, in 

our context, an application is designed as a block diagram. Each block contains either a basic feature (from 

iCORE kernels) or another set of blocks implementing a more complex feature. Thus, iCORE approach 

make software part be easily reusable: simply by copying and pasting blocks subsets. 

Fig. 6: Example of possible platform modularity 

Figure 6 gives a striking illustration of possibilities offered by iCORE modularity. On the left side, 

a four-wheeled platform is shown, composed with two pods. Each pod is driven by the same piece of 

control software (running on its own cb555). Hence, programming control for a six-wheeled version (with 

three pods) is nothing but duplicating a diagram subset and adding a new cb555 into architecture graph. 

Code distribution and execution will require no other step. The same way, assuming a 6-DOF robot arm 

control has been previously realized using iCORE approach, adding such an arm to the 6-wheeled platform 

is nothing but merging the two application diagrams together and modifying the architecture description in 

order to fit the right set of cb555 boards and PC. 

Conclusion 

Relying on this flexible and reliable development methodology, the iCORE approach, we present here, 

bring an efficient help to users and researchers, interested in overriding application implementations 

complexity. Thanks to his own experience, Robosoft has adapted robotic solutions for the field of 

automatic transportation of people and goods, leading to a dedicated product range: rugged hardware 

components (cb555 and various types of embedded PC), as well as a set of realtime software components 

(control loops, I/O primitives, laser and wire guidance, obstacle detection, ...). As shown over the given 

examples, iCORE approach allow user to easily implement and customize transportation applications. 

Finally, making use of programming methodology introduced by SynDEx, iCORE guarantee applications 

executions integrity during risky interventions. 

References 

[1] E. Bianchi, L. Dozio, P. Mantegazza. 

DIAPM RTAI Dipartimento di Ingegneria Aerospaziale - Politecnico di Milano 

Real Time Application Interface. 

[2] RTLinux 

The Realtime Linux. 

[3] Thierry Grandpierre, Christophe Lavarenne, Yves Sorel. 

Modèle d'exécutif distribué temps réel pour SynDEx. 1998.. 

[4] MOTOROLA SEMICONDUCTOR TECHNICAL DATA. 

MPC555 Product Preview PowerPC TM Microcontroller, MOTOROLA INC., 1998. 

90


Remote operation kit with modular conception and 

open architecture : the SUMMER concept 

L. WALLE, Defence R&D & Europe business manager 

ECA – Defence & Offshore, Land systems 

Bât Apollo 4 r Rene Razel 91892 ORSAY CEDEX, 

� lw@eca.fr � http://www.eca.fr 

Abstract 

The article presents an original command and control architecture, realized for French MoD 

(DGA), aiming at operating any robot through a low level controller acting as an abstraction layer 

between actuators and high level orders, whilst ensuring liability of the remotely operated 

system as well as allowing high level mechanisms to help the operator in assisted mode or to 

plan semi or fully autonomous mobility actions while the operator concentrates on its inspection 

or observation mission, with the ability to keep the control of the machine in any case. 

The Man Machine Interface has also been a big achievement for this project since profile 

settings allow all controls to be fully configurable and being instantly modified, adjusted, new 

functions added. 

Lastly, a brief description of the company is provided to know more about ECA. 

A. Reasons for modularity : the Summer concept aim 

Cybernetix company has been developing since years several prototypes aiming at inspecting 

and observing the suburb region as well as operating remotely in case of harsh or hostile 

environments. 

One of our current realizations concerns a global solution for French MoD (DGA/ETAS) able to 

remote operate different types of vehicles with the same command & control architecture and 

the readiness and mechanisms to implement autonomy functions as well as testing new MMI 

configurations. The following pictures show the variety of vehicles to be adapted. 

All photos courtesy of DGA 

Picture 1 : Summer vehicles 

The problem therefore is of different kind : 

o size : because the range of vehicles goes from a truck pillar to a quad, solution has to 

be compact, 

o ruggedness : because it must operate in all-terrain, 

91


o liability : because this is for use in fine by military force for strategic operations 

eliminating the possibility for any error, 

o modular : because the kit must be adapted and fitted for different platforms and 

components must be replaced or added easily 

o open : because the final objective is to find the right architecture and set of sensors so 

many tests must be done, the task of implementation must be eased as much as 

possible, 

o adaptive : because as a prototype, several configurations and improvements or 

modifications must be done in a short time to make it usable. 

To find the right compromise between all of these constraints has been the objective of the study 

phase, as well in terms of forecasting what will be needed in the next future as in terms of ease 

of use for pilots, not specialists in using computers and a powerful but complicated MMI. 

The results are shown in the next paragraphs. 

B. Command & Control architecture 

Components 

The command & control architecture is composed of several subsystems : 

� the Command & Control system (C²S) i.e. the place from which the operator is giving the 

orders or supervising what’s happening. This subsystem is then subdivided into mobility & 

mission dedicated work stations. Further details on this will come in the next chapter. 

� the on-board layers : a cPCI computer architecture is used to provide all services needed 

from the interpreter to the physical command of the actuators, it is divided into the 

following components : 

o a communication interface that deals with transmission protocol between C²S and 

low level on-board calculator. Thus, a change in the protocol from cyclic to acyclic 

transmission, or change in the delivery rate of cyclic packets will result only in a 

change in this layer (and the same in C²S of course), 

o a supervisor (SUP), in charge of all security aspects managements and arbitration 

of possible conflicts between the components. 

o a low level controller (LLC), whose role is the management of all automatons for 

remote operation, meaning placing the commands in correct…. 

o a platform controller (PFC), that acts as an abstraction layer between the platform 

and low level orders. This layer has the responsibility to provide the link from 

orders to physical command of the actuators through the various installed boards 

(analog and digital I/O, counters, serial links, …). This is the only specific part of 

the architecture, platform dependent, that need to be adapted for each different 

type of vehicle (apart from specific transmission). 

o a high level controller (HLC) who can communicate with the LLC to get information 

from the platform to run value-added algorithms and give back orders to the LLC 

for driving the robot or simply give feedback to the user via the MMI through the 

SUP to help in the driving or alert if an automatic obstacle detection is activated for 

example. To prevent any malfunction caused by a high level function and also 

maximizing the calculation power needed for the algorithms, a physical calculator 

is provided for high level functions to ensure in case of hang up of a function or a 

module, or in case of severe software failure, the low level will so be still alive and 

allow the user to keep control of the platform. 

92

The following scheme sums up the interaction between all components of the system. 

Automatons 


Low level Controller 

Automatons management 

State info 

Command Control System 

TC 

Communication interface 

Security 

Commands 

Filtered 

commands 

InfoSys 

Supervisor 

Components 

exchanges 

management 

Security / liability 

Platform Controller 

TM 

System 

Commands 

States + PF Commands 

Vehicle specific command 

management 

Directions 

Alerts/Malfunctions 

States + assisted commands 

Measures 

Actuators/ Sensors Drivers 

Picture 2 : the Command & Control architecture 

High levelController 

Autonomy modules 

Driving help 

After identification, the functions have been analyzed to elaborate the state machines. Below is an 

example of such an automaton, showing the interactions and data exchange between components. 

93

Pilote Expérimenté:Télépilote 


Envoi TC 

INTERF:InterfaceComm 

Mise en route 

Choix Mode 

Resultat Etat Mode 

Transmission TC Systèmes 

SUPV:Superviseur CHN:ControleurHautNiveau CBN:ControleurBasNiveau 

Demande identification 

Activation modules 

Compte rendu 

Transmission TC Mobilité 

[OrdreActivation]ActivationModule 

InfoModule 

[OrdreArrêt]ArrêtModule 

demande Identification 

Configuration 

Compte rendu 

[ordreActivation]configuration 

[OrdreArrêt]configuration 

Picture 3 - Automaton example, high level module activation 

C. Implementation 

Hereafter are shown the low and high level computers, cPCI architecture based with all 

acquisition or communication cards (analog and digital I/O, counters, RS232, 485, 422). 

Picture 4 : Low level (left) and High (right) level computers 

94


In terms of on-board sensors, we can detail on the vehicle : 

- 4 driving cameras (1 in the front, 1 back, 2 laterals) 

- Observation camera (zoom control) 

- Pan & tilt unit with shock absorbers 

- 6 DOF Inertial sensor giving speed and acceleration in XYZ directions 

- Differential GPS 

- Inclinometers in axial and transverse directions 

- Odometry (ultrasound radar) 

In the central unit, some space is left to provide additional sensors, and a dedicated connector is 

available, providing needed digital and analog I/O as well as various types of power supply 

(+12V, +5V, …), ensuring a quick connection and the test of any sensor within a short time. 

Concerning transmissions, the protocol used for TeleCommands (TC) and TeleMeasures (TM) 

is RS422 @19.2Kbds. At this rate, the maximum transmission lag is 100ms, sufficient for driving 

a vehicle at 50km/h (max). The installed system is analog and the range of reception is about 

500m. To avoid any lose of control of the platform, in case of transmission loss after a threshold 

period (to prevent from micro-cuts), an immediate stop is activated. The security chain 

comprises also an independent emergency stop besides normal ES, watchdog, immediate 

stops, … It uses the UHF band within the range [400..450] MHz. 

The modular conception allows also the use of a digital transmission system with a range of 

5kms with a relay system instead of the analog one. The only procedure to conduct is to connect 

a single plug containing all cables on the vehicle, to connect also the cables in the control station 

and to change the transmission profile in the interface, easily done through the tactile screen. 

Concerning the videos, 2 communication links are provided to send PAL format videos at full 

rate: 

- 1 for mobility purpose consisting of a proprietary card connected to 1 to 4 cameras, 

allowing any configuration of the pictures, thus making possible to drive having the front 

video whilst keeping in the corners the lateral views to be alerted in case of danger. When 

activating the reverse gear, the main picture switches from front to back camera. 

- 1 for the observation camera intended to be used by the navigator. 

The range [2.2..2.4] GHz is used for videos. 

D. Adaptive and modular MMI implementation 

Picture 5 : from mock-up to realization 

95


The building of a Man Machine Interface for such a complex system is obviously an iterative 

process that has been conducted together with the final client to find the best compromise 

between ergonomics presentation, making the interface user-friendly whilst guarantying an 

access to security organs at any time through dedicated areas of the tactile screen and 

mechanisms (dead-lever on joystick, watchdog, emergency stop on loss of transmission, …). 

The picture 4 illustrates the matching between the various mock-up versions presented as well 

in terms of architecture as for the graphic aspect of the buttons and its disposition and pasting 

through the different screens. 

The composition below presents the various functions of the MMI. 

Picture 6 : MMI operated 

96


E. Profile management 

The aim of the profile management tool is to allow the user to configure his environment. The adopted 

philosophy is a Windows one. It uses the registry principles, with a list view containing the different 

categories, and all controls beneath. 

The following pictures illustrate the realization. 

Depending on the mode the MMI is used, different privileges are granted, thus preventing hazardous 

modifications from inexperienced users. The visibility of the parameters is so following the mode, a lock 

indicates a category that cannot be modified. 

All elements can be customized, from video size to position of the bitmaps, or alarm thresholds, aso… 

Picture 7 : profile customization 

97


F. Company profile 

ECA (http://www.eca.fr) is a high tech company located in Toulon, south of France, specialized in 

defence and civil robotics, industrial automation, systems and information. Established in 1936, ECA has 

six offices in France and four subsidiaries. Two of them are located in France (HYTEC specialized in 

Remote control systems for inspection and intervention in hostile environments, and ECA AERO- which 

is focused on automated systems for aeronautics), one in England (ECA CSIP oriented in automated 

systems for harsh environments (Remote technology, Defence, Environmental Systems)), and one in 

Turkey (OD ECA Support and equipment for defence). 

ECA employs currently around 300 people. The main customers are 

military clients with more than 20 national marines, and companies 

oriented in aeronautic, automobile, offshore oil and gas, nuclear 

power activities. ECA is the market leader for sub sea robotics for 

mine warfare. 

ECA also builds ground robots for 

French Army and intends to re-use the 

technology in civil applications: beach-cleaning activity has been identified 

as a major application. To define the prototype, ECA provides the 

knowledge for all the electronic parts (sensors and the artificial intelligence), 

the engine and the frame. As soon as the studies are completed and the 

prototypes developed, ECA uses the acquired expertise to develop and 

manufacture small series of repetitive products. 

ECA has significant means in terms of Research & Development, including mechanical, hydraulic, 

electronic and information engineering and design as well as specialised workshops (optics, 

magnetism...) permitting the company to conceive and fabricate demonstrators or prototypes. 

ECA collaborates with a number of research organisms and universities in France and abroad to 

maintain very high level of innovation in its systems. 

The Parisian premises of ECA, formerly known as Cybernétix – Homeland & Security branch, will be in 

charge of the project, has the following activities : 

� With a unique know-how in remote-operated systems and mobile robots for 

interventions in hostile environments. ECA offers standard systems and 

equipment as well as turnkey solutions. The strategy of ECA as a robotics and 

automation specialist, is based on the complementarity between technological 

research & production of robotized equipment and systems in market “niches” 

with strong potential. 

ECA develops and manufactures autonomous and remote-controlled mobile 

robots for the French Defence and Civil Security Services, operations in difficult 

environments and industrial applications. ECA offers innovative solutions for 

extending human actions at inaccessible depth (acoustic guided AUV- 

Autonomous Underwater Vehicle- for sub sea applications: bringing significant 

savings in installation and maintenance operations) or in hostile environments 

(remote controlled mobile robots especially dedicated to handling and 

neutralizing explosives as well as operations in nuclear, bacteriological or 

chemical fields ). Designed to carry remote controlled inspection and intervention 

operations in complete safety for the operator, these robots can easily be 

transported in a car or by helicopter or ships. They are equipped with different 

type of manipulators and monitoring systems (measurements systems, camera 

and vision systems, location systems, etc.) depending on the application. ECA 

has also an important background on big transport systems for containers manipulation, through 

several European RTD projects. 

98


Session « Academic » 

99

A multi-level architecture controlling robots from autonomy to teleoperation 

Abstract 

Cyril Novales, Gilles Mourioux, Gerard Poisson 

Laboratoire Vision et Robotique, 63 av. de Lattre de Tassigny, F-18000 Bourges 

Cyril.Novales@bourges.univ-orleans.fr 

This paper presents a specific architecture based on a multilevel formalism to control either 

autonomous or teleoperated robots that have been developed in the laboratory vision and robotics. This 

formalism separates precisely each robot functionalities (hardware and software) and provides a global 

scheme to position them and to model data exchanges among them. Our architecture was originally built 

from the classical control loop. Two parts can thus be defined: the Perception part which manages the 

processing and the models construction of incoming data (the sensor measurements), and the Action part 

which manages the processing of controlled outputs. These two parts are divided in several levels and 

depending on the robot, the control loops that have to be performed are located at different levels: from 

the basic one (i.e. level 0) composed by the jointed mechanical structure and level 1 which performs 

actuators servoing, to the highest one (i.e. level 5) which manages the various missions of the robot. The 

higher the level is, the shorter the loop reaction time has to be. Each level clusters, for their respective 

part, specific modules which perform their own goals. This general scheme permits to integrate different 

modules issued from various robot control theories. This architecture has been designed to model and 

control autonomous robots. Furthermore, a third part, called “teleoperated part”, can be added and 

structured in levels similarly to the two other parts. Distant from the robot, this teleoperated part is 

managed by a human operator who controls the robot at various levels: i.e. from the first level (the basic 

remote control) to the upper one (where the operator only controls the robot mission). 

Hence, this architecture merges two antagonist concepts of robotics, i.e. teleoperation and 

autonomy, and allows a sharp distribution between these two fields. Finally, this architecture can be used 

as a main frame to build its own control architecture, using only a few clusters with dedicated modules. 

Some examples and experimental results are given in this paper to validate the proposed formalism. 

Introduction 


When turning a robot on, the problem of its autonomy is quickly addressed. However, several type 

of autonomies can be considered: energetic autonomy, the behaviour autonomy or smart autonomy. The 

designer has to choose the way he will give autonomy to his robot. He has mainly two orientations: 

“reactive” capacities or “deliberative” capacities. These two capacities are complementary to let a robot 

perform a task autonomously. The designer must built a coherent assembly of various functions achieving 

these capacities. This is the role of the control architecture of the robot. To design an autonomous robot 

implies to design a control architecture, with its elements, its definitions and/or its rules. 

One of the first author who expressed the need for a control architecture was R.A. Brooks [1]. In 

1986, he presented an architecture for autonomous robots called “subsumption architecture”. It was made 

up of various levels which fulfil separately precise function, processing data from sensors in order to 

control the actuators with a notion of priority. It is a reactive architecture in the sense that there is a direct 

link between the sensors and the actuators (Figure 1). This architecture has the advantage to be simple 

and thus easy to implement, nevertheless, the priorities given between the different actions to perform are 

fixed in time and do not allow an important flexibility. 

100


Figure 1 - « Subsumption Architecture » 

Then other various architectures were developed based on different approaches, generally 

conditioned by the specific robot application that the architecture had to control. 

The architecture 4-D/RCS developed by the Army Research Laboratory [2] has the main 

characteristic to be made up of multiple calculative nodes called RCS (Real time Control System). Each 

node contains four elements, performing the 4 following functionalities: Sensory Processing, World 

Modeling, Behavior Generation and Value Judgment. Some nodes contribute to the perception, others 

contribute to the planning and control. These nodes are structured in levels, in which one can find the 

influence of the reactive behaviors in the lower levels and of the deliberative behaviors in the higher 

levels. The general management is carried out via communications using a specific language NML 

(Neutral Messaging Language) and according to the decision made by the Value Judgment modules. 

The Jet Propulsion Laboratory developed in collaboration with NASA its own control architecture 

called CLARAty [3]. Its principal characteristic is to free itself from the traditional diagram on 3 levels 

(Functional, Executive, Path-Planner) and to develop a solution with only 2 levels which represent the 

functional level and the decisional level. A specific axis integrates the concept of granularity of the 

architecture for compensating the difficulties of understanding due to the reduction of the number of 

levels (Figure 2). One of the interests of this representation is to work at the decisional level only on one 

model emanating from the functional level. The decomposition in objects of this functional level is 

described by UML formalism (Unified Modeling Language) that allows an easier realization of the 

decisional level. 

Figure 2 – Two level Architecture 

The LAAS architecture (Laas Architecture for Autonomous System) [4] is made up of 3 levels: 

decisional, executive and functional (Figure 3). Its goal is to homogenize the whole mobile robotics 

developments and to be able to re-use already designed modules. 

101


Figure 3 – LAAS Architecture 

All the modules of the functional level are encapsulated in a module automatically generated by 

GenoM. These have to interact directly with the actuators and other modules of the functional level. The 

higher level is a controller of execution (Request & Ressources Checker). Its main function is to manage 

the various requests emitted by the functional level or the decisional level. The operator acts only at the 

decisional level by emitting missions which depend on the information incoming from the lower levels. 

This architecture has an important modularity even if the final behavior is related to the programming of 

the controller of execution. 

R.C. Arkin describes and uses a hybrid control architecture, called AuRA for Autonomous Robot 

Architecture [6], including a deliberative part and a reactive part. It is made up of two parts, each using 

distinct method to solve problems (Figure 4). The deliberative part which uses methods of artificial 

intelligence contains a mission planner, a spatial reasoner and plan sequencer. The reactive part is based 

on sensors. A “schema controller” controls the behavioral processes in real time, before they were sent to 

a “low-level control system” for execution. The deliberative level stays in standby mode and is activated 

only if an impossibility is generated by the reactive part of the task execution. The levels are 

progressively activated according to the needs. 

Figure 4 - AuRA Architecture 

102


A. Dalgalarrondo [7] from the DGA/CTA proposed another architecture. It presents a hybrid 

control architecture including four modules: perception, action, attention manager and behavior selector 

(Figure 5). It is based on sensor based behaviors chosen by a behavior selector. The “perception” module 

carries out models using processing which are activated or inhibited by the “attention manager” module. 

The “action” module consists of a set of behaviors controlling the robot effectors. A loop is carried out 

with the information collected by the perception part. This is particularly necessary for low level actions. 

Figure 5 – DGA Architecture 

The “attention manager” module is the organizer of the control architecture: it checks the validity 

of the models, the occurrence of new facts in the environment, the various processing in progress and 

finally the use of the processing resources. The “behavior selector” module must choose the robot 

behavior according to all information available and necessary to this choice: the fixed goal, the action in 

progress, representations available as well as the temporal validity of information. 

The DAMN architecture (Distributed Architecture for Mobile Navigation) results from work 

undertaken at the Carnegie Mellon University (Figure 6). Its development was a response to navigation 

problems. The principle is as follows: multiple modules share simultaneously the robot control by sending 

votes which are combined according to a system of weight attribution. Then, the architecture makes a 

choice of controls to send the robot, by a fusion of the possible solutions [20]. 

Figure 6 – DAMN Architecture 

This architecture proposes the dominating presence of only one module which decides the 

procedure to follow. This forces to concentrate all the evolution capabilities of the robot. This mode of 

control does not make it possible to understand or anticipate the probable behavior of the robot with 

respect to a unexpected situation. 

Kim Hong-Ryeol & Al, have suggested a five hierarchical level for an architecture that he 

patented in 2005 [8]. The physical level represents the robot, the higher level is the function level; it is an 

assembly of software components. The “Executive level” is level 3 and is composed of “local Agents” 

which are managed by the “real time manager”. The upper level is the “planning level” which includes 2 

103


on-line and off-line modes. On the upper level of the architecture is the “design level” which represents 

the possibility for the designer to carrying out modifications of the architecture interactively. 

Principle of the proposed architecture 

The architecture, propose here, is based on the same architectures principles that have been 

suggested since the Nineties. It relies on the concept of levels initially developed by R. Brooks and which 

appear in architectures proposed by AuRA or LAAS. Similarly to the latter one, we have an upstream 

flow of information from the robot corresponding to its perception, and a downstream flow going down 

towards (to) the robot and corresponding to the control part. The specificity is to structure this robot 

control architecture in levels similarly to communication architectures such as the OSI/ISO (Figure 7). 

Each level can communicate with the higher or lower level by data transfers which follow a predefined 

format and processing according to the given robot application. 

Figure 7 – Architecture of Open System Interconnection (ISO) 

However, contrary to communication architectures where data must imperatively flow through all 

levels, in the proposed architecture, data will be able to either pass through the levels to be treated, or to 

be transmitted directly to the same level from the upstream part to the downstream part. Thus, data do not 

have to follow a unique path. They can be routed via multiple paths to perform various control loops. 

Even when affecting different levels, all these control loops have a common path through the articulated 

mechanical system (AMS) (Figure 8). The Articulated Mechanical System corresponds to the physical 

part of a robot. 

104


Figure 8 – Data flow inside a robot 

The control loops are interwoven and pass through a more or less great number of levels. The 

loops of a low level are faster than the loops of a higher level, because data are processed successively by 

a lesser number of levels. We then find the concepts of “deliberative” levels in the higher levels and 

“reactive” levels in the lower levels. 

Figure 9 – Robot = AMS part + Perception part + Action part 

An autonomous robot as a whole is then modelled by an Articulated Mechanical Structure 

surmounted by two parts: an upstream part corresponding to the perception of this AMS, and a 

downstream part corresponding to the action on this AMS. These two parts are divided into levels along 

which the various control loops are closed (Figure 9). Each level of each part must be clearly specified to 

allow the designer of the robot to place the respective control loops (articular control, Cartesian control, 

visual control...). This architecture is embedded in the robot: it defines the autonomous architecture of the 

robot. 

105

The autonomous parts 

Basic levels 


Let us start from a basic control loop of a robot: a reference signal, compared with the sensor 

measurements, is sent in a correction module before being applied to the entry of the robot actuators 

(Figure 10a). When analysing the electromechanical part (the Articulated Mechanical Structure), two 

other distinct parts in this control loop are identified: the perception part composed with sensors and their 

controls, and the action part which gathers all processing steps (i.e. typically articular controls - PID) 

applied to data that are then sent to the AMS (Figure 10b). 

Figure 10 a- classic representation of a servoing loop b- our representation 

We call level 0 the articulated mechanical structure. Servoings and sensors are located at the same 

level, immediately above the articulated mechanical structure; they constitute the level 1 of our 

architecture. This level corresponds to the shortest – and the fastest – loop of the robot. 

At this level, we will find various loops functioning in parallel; for example articular servoings of 

each robot articulation. We thus define one module for each servoings/sensor system and modules are 

clustered in each level of each part (action and perception part). 

The basic levels correspond to levels 0 and 1. The cluster of the level 1 of the perception part 

gathers the modules sensors, their respective controls and filters. The cluster of the level 1 of the action 

part gathers the modules of articular servoings (Figure 11). The setting points of the servoings represent 

the inputs of the cluster of the level 1 of the action part. The outputs of the cluster of level 1 of the 

perception part are all the filtered sensors measures. These measures are also transmitted to the modules 

of the cluster of level 1 of the action part in order to carry out the servoings. Typically, data from the 

exteroceptive sensors are simply processed and transmitted to the upper level of perception, and data from 

the proprioceptive sensors are transmitted to servoings (cluster action of the same level). 

Figure 11 – The level 0 and 1 of the architecture 

106


Level 2: the pilot 

To feed the input of level 1 of the action part, the servoings setting points should be continuously 

provided. This is the role of the ‘Pilot’ cluster: it generates these setting points (e.g. articular) based on a 

trajectory provided as an input. This trajectory is expressed in a space (e.g. Cartesian space) different 

from that of the setting points. It is also a “setting point” but from a higher level, so we do not called thus. 

This trajectory describes, in time, the position parameters, kinematic parameters and/or dynamic 

parameters of the robot in its workspace. The function of the pilot is to convert these trajectories into 

setting points to be performed by the servoings. Typically, the pilot contains the Inverse 

Geometrical/Kinematics/Dynamic Models of the robot (generally, only one of them is present, according 

to the robot application). In our architecture, this pilot is positioned on level 2 in the action part. 

However, this ‘Pilot’ cluster does not only contain one IKM module; it can also contain modules 

which give the robot the possibility to take into account information of its environment. According to the 

concept of our architecture, this information comes from this level 2 and from the perception part: this is 

the cluster of the ‘Proximity Model’ of the robot environment. This ‘Proximity Model’ cluster contains 

various modules which transform filtered measurements (coming from the ‘Sensor’ cluster of level 1 

perception) into a model in the same space as that of the trajectory (e.g. Cartesian space). This 

transformation is performed on line using sensors measures; no temporal memorizing is carried out. The 

‘Proximity Model’ obtained is thus limited to the horizon of sensor measures. Typically, this ‘Proximity 

Model’ cluster contains modules which apply the Direct Geometrical/Kinematics/Dynamic Model of the 

robot to the proprioceptive data, and which express the exteroceptive data in a local frame centred on the 

robot (Figure 12). 

Level 2 

Level 1 

Level 0 

Action Part Perception Part 

Pilot 

Asservissements 

Servoings Sensors Capteurs 

A.M.S. ROBOT 

Proximity 

Model 

Figure 12 – The second level provide the second control loop 

Depending on the robot application, the 'Pilot' cluster uses data resulting from the cluster 

‘Proximity Model’ to carry out – or not – corrections on the reference trajectory provided to it as input. 

Typically, for a mobile robot, that consists in reflex avoidances of obstacles detected on the trajectory. 

For a manipulator robot, this consists in a loop of servoings in Cartesian space. 

Because of its path in an additional layer, this loop of level 2 is a fortiori longer – and thus slower 

– than the loop of the level 1. Moreover, this loop does not exist on all robotic applications. There are 

manipulator robotics applications which use IKM and DKM modules for the 2 clusters of level 2, without 

any connection between them: there is no Cartesian servoings and the processing of Cartesian 

position/velocity is carried out in an open loop. The level 1 - the articular servoings loop - carries out the 

motion alone. 

107


In a dual way, there are robot applications where the control is carried out only in Cartesian space; 

that is represented in our architecture by the absence of loop on level 1. The control loop is performed 

only after the DKM/IKM model in the level 2. Mixed modes of articular and Cartesian servoings can also 

be represented in this architecture. 

Level 3: the navigator 

The ‘Pilot’ cluster must receive its trajectory from the upper level of the action part. We call 

‘Navigator’ the cluster positioned on this level 3. It must generate the trajectories for the ‘Pilot’ cluster 

based on data received from the upper level. These input data are of a geometrical type, still in a Cartesian 

space, but not necessarily in the robot frame. Moreover, these data do not integer dynamics or kinematics 

aspects; contrary to the trajectory, there is not a strict definition of the velocity, the acceleration or the 

force during the time for the AMS. These input data are called path – continuous or discontinuous – in 

Cartesian space. We allow to set on this path temporal constraints such as indicative time of route or 

indicative minimal/maximal speed on specific point of the path. 

The ‘Navigator’ cluster must translate a path into a trajectory. The path does not take into account 

physical constraints of the AMS, but the trajectory that it delivers must integer them. Indeed, the path 

received by the navigator is closer to the task to be performed by the robot than to the mechanical 

constraints of the AMS. The navigator is situated at the interface between the “request” and the 

“executable”: it is the most noticeable level of the proposed architecture. According to the robot 

applications, the modules gathered in this cluster are based on various theoretical methods. 

On the top of the mechanical constraints of the AMS, this ‘Navigator’ cluster must generate a 

trajectory in concordance with the robot environment. Therefore, it needs information modelling its 

environment and coming from the same level, i.e. the cluster of level 3 of perception part. This perception 

cluster models the local environment of the robot beyond the range of its sensors in order for the 

‘Navigator’ to test the validity of the trajectories before to deliver them to the ‘Pilot’. This cluster is called 

the “Local Model” of the environment. It uses the displacement of the robot to locally model the 

environment around the robot (Figure 13). 

Figure 13 – The third control loop in the level 3 

This level 3 makes it possible to integrate various modules based on various theories in the 

‘Navigator’ cluster as well as in the ‘Local model’ cluster. Depending on the robot application, the 

108


control loop at this level may exist or not. When it exists, it crosses 6 clusters and it is longer – and slower 

– than the control loops of lower levels. 

Level 4: the path-planner 

The ‘Navigator’ receives as input a path resulting from the cluster of the level 4 of the action part, 

the ‘Path Planner’. This cluster generates the path using as input a goal, a task or a mission. This 

functionality is performed in a long run in order to project the path on a large temporal horizon. We are 

located in a high control loop of the architecture which corresponds to the “deliberative” levels of similar 

architectures. To be valid, this path must imperatively be placed in a known environment. The pathplanner 

use information resulting from the perception part of the same level: this cluster named ‘Global 

Model’ of the environment must provide to the path-planner an a priori map. Hence, the path-planner can 

validate its path on this pre-established map. This map does not need to be accurate with the metric 

direction (absence of obstacle, errors of dimension or orientation, presence of icons out of the scale...) but 

must be correct topologically (closed area, connexity, possible way-out, inaccessible areas...). This model 

can be either built on-line, by using data resulting from the lower level (“Local Model” cluster), or preestablished 

and updated by the lower level (Figure 14). 

Level 4 

Level 3 

Level 2 

Level 1 

Level 0 


Path Planner 

Navigator 

Pilot 

Level 5: the mission generator 

Global 

Model 

Local Model 

Proximity 

Model 



A.M.S. ROBOT 

Figure 14 – The level 4 

Preestablished 

map 

The ‘Mission Generator’ is the cluster of the highest level of the action part. It must generate a 

succession of goals, tasks or missions for the ‘Path-planner’, according to the general mission of the 

robot. It is the “ultimate” robot autonomy concept: the robot generates itself its own attitudes and its own 

actions by using its own decisions. The ‘Mission Generator’ cluster does not really have any input. It only 

needs general information on its environment, its state and its possible attitudes. This is provided by the 

109

cluster of the perception part of the same level. This cluster is a ‘General Model’ of the robot and its 

environment and could be based on a data base (Figure 15). 

Level 5 

Level 4 

Level 3 

Level 2 

Level 1 

Level 0 



Mission 

Generator 

Path Planner 

Navigator 

Pilot 



A.M.S. ROBOT 

Figure 15 – The level 5 

General Model Data Base 

Global 

Model 

Local Model 

Proximity 

Model 

Preestablished 

map 

This level is the higher control loop of the proposed architecture and does not have any entry, as it 

corresponds to the highest decisional autonomy level. According to the robot application, this level is 

based on modules related to artificial intelligence. Although it must project its missions on a very large 

temporal horizon, reaction time of this level is slow (this loop has multiple levels to cross). However, this 

level of autonomy corresponds to the “smart” or “clever” attitude of the robot. The remaining part of the 

robot autonomy is dispatched on the lower levels of the architecture: the projection of the motion 

according to the obstacles is in the navigator, the reflex action is in the pilot level, the servoings level 

ensures the accuracy of the gesture... 

The autonomous part of the architecture 

The whole architecture, made up of 2 parts divided into 5 levels, represents the autonomy of the 

robot. In fact, these autonomous parts of the architecture are embedded in the robot: the two parts – 

‘Action’ and ‘Perception’ – and the Articulated Mechanical Structure (level 0) constitute the robot itself. 

The ‘Perception’ part corresponds to the upstream data flow from the AMS and the ‘Action’ part 

corresponds to the downstream data flow to the AMS. Connections on each level ensure the feedback 

loops of variable length allowing the control of the robot. 

This architecture makes it possible to model any autonomous robot whatever its application or its 

degree of autonomy. Its functioning is ensured by modules that are located in the different clusters. 

Depending on the applications, all modules are not required for all clusters and data flows may vary. 

Reversely, to produce a specific robot for a dedicated application, this architecture can be used in order to 

specify each module in each cluster, before carrying out the programming and the implementation. 

110

The teleoperated part 


This architecture makes it possible to model and control a robot which has various degrees of 

autonomy. But it does not make it possible to take into account the remote control of a robot. Indeed, the 

tele-operation is considered as antagonist to autonomy. A robotized system is regarded either as 

autonomous or as tele-operated. In the proposed architecture, we have leveled the autonomy of a robot in 

several degrees of autonomy. In a similar way, we propose to level the tele-operation of a robot. This 

leveled tele-operation complements the levels of autonomy of a robot, substituting itself to the missing 

degrees of autonomy. 

Hence, we define a third part, called ‘Tele-operation’, distant to the robot (Figure 16). In order to 

modulate the degree of the tele-operation, this part is also organised in levels similarly to the one defined 

for the ‘Action’ and ‘Perception’ parts. Each level of the ‘Tele-operation’ part receives data resulting 

from the corresponding levels of the ‘Perception’ part and can replace the corresponding level of the 

‘Action’ part by generating in its place data necessary to the lower level of the ‘Action’ part. 

Figure 16 – The third ‘distant’ part: the tele-operation 

Thus, several possible levels of tele-operation can be identified: 

- The level 1 of tele-operation makes it possible for a human operator to actuate directly (in open 

loop mode) the Articulated Mechanical Structure. This level receives data from the level 1 of the 

‘Perception’ part. This allows any operator to replace the autonomous loop of level 1. This is a remote 

control in open loop where the robot does not have any autonomy (Figure 17). 

Figure 17 – The tele-operation supplying the level 1 of the action part 

- The level 2 of the tele-operation uses information of the ‘Proximity Model’ to make it possible 

for a human operator to replace the level 2 of the ‘Action’ part, called the ‘Pilot’. It thus delivers setting 

points necessary to the level 1 to control the robot. This level of tele-operation is higher than previous, 

and can preserve the level 1 autonomous loop of the robot (Figure 18). Notice that there is no flow of 

111


information between level 1 and level 2 of the tele-operation; the reason being that they are excluded 

mutually: when there is a tele-operation of the robot, it is made either from level 1 or from the level 2. 

Figure 18 – The tele-operation supplying the level 2 of the action part 

- The level 3 of the tele-operation allows an operator to generate a trajectory for the ‘Pilot’, hence 

taking the role of the ‘Navigator’. The human operator who carries out this task uses data resulting from 

the ‘Local Model’ of the ‘Perception’ part. Thus, he acts in place of the loop of level 3 of autonomy. The 

operator tele-operates the robot still using the lower degrees of autonomy (2 and 1). For example, when a 

reflex reaction pilot is implemented in the level 2 of the ‘Action’ part, this one will act autonomously if 

the human operator sends a non-acceptable trajectory by the robot (Figure 19). 

Figure 19 - The tele-operation supplying the level 3 of the action part 

- The level 4 of the tele-operation makes it possible for the human operator to send a path to the 

‘Navigator’ using the ‘Global Model’ of the ‘Perception’ part. He thus replaces the autonomous loop of 

the level 4 and is assisted in the control of the robot by the lower degrees of autonomy (Figure 20). 

112


Figure 20 - The tele-operation supplying the level 4 and assisted by the lower levels of autonomy 

- Finally, the level 5 of the tele-operation gives the possibility to an human operator to choose a 

task or a mission carried out by the robot autonomously, thanks to its levels of autonomy 4 to 1 (Figure 

21). 

Figure 21 - The tele-operation supplying the level 5 of action part 

113


Depending on the robot applications, only one level (or no level) of tele-operation is used by a 

human operator. However, the human operator can also choose his level of tele-operation according to the 

course of the robot mission. This dynamic evolution of the tele-operation gives the possibility to keep the 

human control on all the levels of an autonomous robot. To allow a dynamic evolution between the 

degrees of autonomy and tele-operation, a multiplexer module in each cluster of the ‘Action’ part is 

needed. This multiplexer module drives the input data either from the tele-operation or from the data 

coming from the upper autonomous level. 

This dynamic evolution of autonomy/tele-operation degree also gives an operational security for 

the autonomous robot: currently, a human operator can take over the robot when it cannot solve problems 

on its own or because of material or software failures. 

Of course, according to the tele-operation level where the human operator acts, the man-machine 

interface is different. It can be simple a keyboard/joystick for the lower levels, a graphic environment for 

the median levels or a textual analyser for the higher level. Finally, nothing prohibits the tele-operation to 

be ensured by computers instead of a human operator. 

The complete PAT Architecture 

The PAT architecture that we are proposing is based on 3 parts, the “Perception”, “Action” and 

“Tele-operation”, layered in 5 levels. As it has been shown, this PAT architecture forms a frame (Figure 

22). A robot designer places on the PAT frame the modules that he needs to carry out the mission. He 

also determines the flow of data between the modules. 

Robotics is also a technology of integration and the designer has to use various hardware and 

software modules. For example, he must integer a GPS sensor or a DC-power variator on which he can 

access only to the inputs and the outputs according to the builder specifications. Heterogeneous devices 

can be placed in the PAT architecture. The designer organizes them in priority and after, he places the rest 

of the modules (generally software). Each module is then developed afterwards according to the software 

(OS, languages, RT kernel…) and the hardware (CPUs, networks…) choices. The choice of the theory for 

each module is totally free: different theories/methods can be used and combined in the architecture (e.g. 

SLAModels, reactive behaviours based on neural networks, and a navigator based on heuristics can be 

used). 

114


T1 

Servoings 

Sensors 

T2 

Pilot Navigator 

Proximity 

Model 

Local 

Model 

Figure 22 - PAT Architecture (frame) 

115 

T3 T4 

T5 

Path 

Planner 

Global 

Model 

Mission 

Generator 

General 

Model


Example of a mobile robot: “Raoul” 

Several robots have been developed in our lab (LVR-Bourges); each of them had different 

hardware and software platforms. The PAT architecture was used to design, develop and control these 

totally different robots. 

Raoul is an autonomous mobile robot, able to run in an unknown environment, finding alone a 

trajectory to perform and avoiding collision with static or mobile obstacles. Raoul is built on a Robuter 

platform (Robosoft) with an additional computer (PC/RT-Linux) and exteroceptive sensors: two Sick 

telemeters laser range and one goniometer laser. 

The PAT architecture was implemented on Raoul with the following modules (Figure 23): 

Figure 23 – Architecture of the mobile robot Raoul 

‘A1_Servo’ is the module for the servoing of the 2 motorized wheels. Robuter platform is a 

standard differential wheels robot. This module uses the measures incoming from the proprioceptive 

sensors (motor ticks, odometry) ‘P1_proprio’. We can notice that these two modules, which forms the 

articular servoings loop, are implemented in the Albatros Robuter CPU. We cannot modify them; we have 

only access to inputs (setting points) and outputs (odometry, linear speed…). 

‘P1_Sicks’ is the module driving the front and the rear laser range telemeters. Data that it delivers 

for the upper level is a list of polar distances depending to the angle of measurements. 

‘P1_Gonio’ is the module driving the absolute laser goniometer. It delivers an absolute 

position/orientation in the plane. 

The ‘Pilot’ cluster contains two modules. ‘A2_IKM’ module converts the desired motion of the 

robot in setting points for the servoings. ‘A2_React’ module performs the desired trajectory avoiding 

unforeseen obstacles using the two local maps made by ‘P2_MapF’ and ‘P2_MapB’ modules in the 

116


‘Proximity Model’ cluster. ‘A2_React’ is based on DVZ formalism [9] and provides the robot with a 

reflex behavior to avoid obstacles. 

The ‘Local model’ cluster contains the module ‘P3_Map’ which uses the method developed by J. 

Canou to built a global map on-line using the motion of the mobile robot to feed and refresh it [20]. The 

‘A3_Geom’ module of the ‘Navigator’ cluster is a very simple module: it only places pre-processed 

trajectories of the robot in the local map. It deletes trajectories which intersect obstacle and choose the 

nearest trajectory from the desired path. 

The ‘A4_Fwd’ uses the absolute position of the mobile robot to generate a straight path of 1 meter 

in front of the robot. It does not take into account any obstacle of the environment. The ‘P4_PosAbs’ 

module is only a calculation of the absolute position of the robot. A global map has not been integrated in 

this cluster. With this level 4, our goal is to validate the following concept: with only level 2 and level 3 

control loops, a mobile robot is quite autonomous to be able to evolve in a totally unknown environment. 

With this implementation, Raoul mobile robot is able to run in an unknown environment, avoiding 

static and mobile obstacles. It is able to make maneuvers (backward-forward) to escape from dead end 

zones. 

Example of the tele-operated robot: “OTELO-1” 

Otelo is a European project (IST-2001-32516) leaded by the LVR laboratory on the teleechography 

using a light robot. During this project, 3 dedicated robots have been developed. Otelo1 robot 

is a fully tele-operated robot holding an echography probe. It can follow the motions than a medical 

expert realizes at distance with the input device. The expert receives ultrasound image, modifies the probe 

holder orientation and makes a diagnosis at a distance [20]. 

Otelo1 is programmed with the following architecture (Figure 24): 

Tele-operation 

T3 

T3_GUI 

T3_InDev 

Level 2 

Level 1 

Level 0 

Pilot 

Servoings 

Level 3 

Robot 

A2_IGM 

Action Perception 

A1_Servo 

A.M.S. 

Local 

Model 

P1_Proprio 

Figure 24 – Architecture of the tele-operated robot Otelo1 

Sonographer 

P3_Cprs 

‘A1_Servo’ module performs the position servoings of the 6 axes of Otelo1 robot. This dedicated 

robot is technologically complex: it has 3 DC-motors, 3 step-motors, incremental encoders, analog 

absolute encoders, lvdt, force sensor and various digital I/Os like optical switches. ‘P1_Proprio’ module 

dives all the inputs. In fact, these two modules have its software distributed in many visual-C++ 

functions/objects, using functionalities of the advanced PMAC boards. The level 1 ensures the articular 

servoings of the 6 axes of the robot. 

117 

Proximity 

Model 

Sensors

An ultrasound probe of a sonographer is held by the robot. However, companies manufacturing 

ultrasound devices with advanced functionalities restrict the access to the transducer signal; they only 

deliver ultrasound dynamic images. The ultrasound device is thus considered as an isolated device 

covering 3 levels of the ‘Perception’ part. The 2D ultrasound image is considered as a local model of the 

environment and it compressed by the ‘P3_Cprs’ module. 

The compressed ultrasound image is transmitted to the ‘T3_GUI’ module of the level 3 of the 

‘Tele-operation’ part. This module prints the dynamic image (on a screen) for the medical expert. He uses 

a virtual probe as an input device, the ‘T3_InDev’ module which transmits trajectories to the ‘Pilot’ 

cluster. The ‘Pilot’ cluster contains the ‘A2_IGM’ module which translates trajectories in articular setting 

points for the level 1. 

Otelo1 was tested during trans-continental experiments (Cyprus-Spain or Morocco-France) using 

various communication links (ISDN, Satellite, Internet), and has proved the validity of the teleechography 

concept in the medical environment. 

Another robot Otelo3 based on a different mechanical structure is currently being developed in the 

lab and we are implementing some autonomous abilities to perform motions when problems occur on the 

transmission links (lacks or delays). To achieve that goal, we close the loop of the level 3 is closed and 

modules are added in the clusters of level 3 and 4. 

Conclusion 

The main objective of the PAT architecture was to clearly specify the domain of application of 

each theory or method developed in robotics. This architecture allows to use together several different 

methods. 

We used the common concept of level and push it to its extremity to exit of the scheme 

reactive/deliberative. We have designed the PAT architecture in order to accept a maximum of robotic 

methods either in control or in perception. The main consequence is that the PAT architecture is 

sufficiently generic to model any robot, mobile or not, autonomous or tele-operated. The second strong 

asset of the PAT architecture is to give the possibility to manage the tele-operation AND the autonomy of 

a robot. This mixed mode can be graduated and dynamically modified. 

All the robot developments of the laboratory use this PAT architecture, even if the mechanical 

structure, the hardware and the software are different. We are thus building a library of modules for the 

various levels of the architecture which can be used in any other robotic applications. When we fix a 

common hardware and software frame (CPU, languages, OS, RT-kernel, network links…), this library 

becomes available to an open community where each user can develop his/her own modules or use 

existing modules. 

Bibliography 


[1] Brooks R.A., “A robust layered control system for a mobile robot”, IEEE Journal of Robotics and 

Automation, vol. 2, n°. 1, pp. 14–23, 1986. 

[2] Albus J. S., “4D/RCS A Reference Model Architecture for Intelligent Unmanned Ground 

Vehicules”, Proceedings of the SPIE 16th Annual International Symposium on Aerospace/Defense 

Sensing, Simulation and Controls, Orlando, FL, April 1 – 5, 2002 

[3] Volpe R., et al., “CLARAty: Coupled Layer Architecture for Robotic Autonomy.” JPL Technical 

Report D-19975, Dec 2000. 

[4] Alami R., Chatila R., Fleury S., Ghallab M., and Ingrand F., “An architecture for autonomy”, The 

International Journal of Robotics Research, Special Issue on Integrated Architectures for Robot Control 

and Programming, vol. 17, no 4, pp. 315-337, 1998. 

118


[5] Rosenblatt J., “DAMN: A Distributed Architecture for Mobile Navigation”, In proceedings of the 

1995 AAAI Spring Symposium on Lessons Learned from Implemented Software Architectures for 

Physical Agents, AAAI Press, Menlo Park, CA, 1995. 

[6] Arkin R.C. “Behavior-based Robotics”, MIT Press, 1998 

[7] Dalgalarrondo A., “Intégration de la fonction perception dans une architecture de contrôle de robot 

mobile autonome”, Thèse de doctorat, Université Paris-Sud, Orsay, 2001. 

[8] Hong-Ryeol K., Dae-Won K., Hong-Seong P., Hong-Seok K.and Hogil L. “Robot control software 

framework in open distributer process architecture”, Korean and World patent, WO2005KR01391 

20050512, IPC1-7: G06F19/00, May 2005. 

[9] R. Zapata, "Quelques aspects topologiques de la planification de mouvements et des actions 

reflexes en robotique mobile", Thèse d'état, Université Montpellier II, juillet 1991. 

[10] Joseph Canou, Gilles Mourioux, Cyril Novales and Gérard Poisson, “A local map building process 

for a reactive navigation of a mobile robot”, ICRA’2004, IEEE International Conference on Robotics and 

Automation, April-Mai 2004, New Orleans. 

[11] Gilles Mourioux, Cyril Novales and Gérard Poisson, “A hierarchical architecture to control 

autonomous robots in an unknown environment”, ICIT’2004, IEEE International Conference on 

Industrial Technology, December 2004, Hammamet. 

[12] European OTELO project : “mObile Tele-Echography using an ultra Light rObot”, IST n°2001- 

32516, leaded by the LVR (Sept. 2001 – Sept 2004), consortium : LVR (F), ITI-CERTH (G), Kingston 

Universite (UK), CHU of Tours (F), CSC of Barcelona (E), Ebit (I), Sinters (F), Elsacom (I) and Kell (I). 

119

Abstract 


LAAS architecture: Open Robots 

F. Ingrand 

LAAS-CNRS 

L’architecture LAAS pour systèmes autonomes a été développé durant un grand nombre 

d'années et est mise en oeuvre sur l'ensemble de nos robots mobiles. Il faut noter que les aspects 

généricité et programmabilité de cette architecture permettent une mise en oeuvre rapide et une 

bonne intégration des systèmes utilisés(GenoM, OpenPRS, Exogen et IxTeT). Nous présenterons 

cette architecture et les outils qui forment la suite des logiciels Open Robots: 

• Le niveau décisionnel: Ce plus haut niveau intègre les capacités délibératives par 

exemple : produire des plans de tâches, reconnaître des situations, détecter des fautes, 

etc. Dans notre cas, il comprend : 

• un exécutif procédural OpenPRS qui est connecté au niveau inférieur auquel il 

envoie des requêtes qui vont lancer des actions (capteurs/actionneurs) ou 

démarrer des traitements. Il est responsable de la supervision des actions tout en 

étant réactif aux événements provenant du niveau inférieur et aux commandes de 

l’opérateur. Cet exécutif a un temps de réaction garanti. 

• un planificateur/exécutif temporel (dans notre cas IxTeT- eXeC, extension de 

IxTeT) qui sera chargé de produire et exécuter des plans temporels. Ce système 

doit être réactif et prendre en compte les nouveaux buts ainsi que les échecs 

d’exécution (échec d’une action et time-out). 

• Le niveau fonctionnel : Le plus bas niveau comprend toutes les actions et fonctions de 

perception de base de l’agent. Ces boucles de contrôle et traitements de données sont 

encapsulées dans des modules contrôlables (développés avec GenoM). Chaque module 

fournit des services et traitements accessibles par des requêtes envoyées par le niveau 

supérieur ou un autre module. Le module envoie en retour un bilan lorsqu’il se termine 

correctement ou est interrompu. Ces modules sont complètement contrôlés par le niveau 

supérieur et leurs contraintes temporelles dépendent du type de traitement qu’ils ont à 

gérer (servo- contrôle, algorithmes de localisation, etc.). 

• Le niveau de contrôle des requêtes : Situé entre les deux niveaux précédents, le R2C « 

Requests and Replies Checker » vérifie les requêtes envoyées aux modules fonctionnels 

(par l’exécutif procédural ou entre modules) et l’utilisation des ressources. Il est 

synchrone avec les modules (il connaît toutes les requêtes envoyées et tous les bilans 

retournés et construit en ligne l’état du niveau fonctionnel). Il agit comme un filtre qui 

éventuellement rejette des requêtes en fonction de l’état et d’un modèle formel donné par 

l’opérateur spécifiant les états autorisés ou interdits. Les bilans retournés par le niveau 

fonctionnel sont transmis à l’exécutif procédural après mise à jour de l’état interne. Les 

contraintes temporelles sont de type temps réel dur. 

120


Architectures logicielles pour la robotique et sûreté de fonctionnement 

L. Nana 

Laboratoire d’Informatique des SYstèmes Complexes (LISyC), EA3883 

Université de Bretagne Occidentale 

20 Avenue Le Gorgeu 

C.S. 93837 – BP 809 

29238 BREST Cedex 3 

Résumé 

La sûreté de fonctionnement, bien qu'ayant atteint une 

certaine maturité du point de vue du matériel, nécessite 

des solutions adaptées au niveau du logiciel, et doit être 

prise en compte tant au niveau des langages destinés à la 

programmation robotique qu'au niveau de la conception 

et de la mise en oeuvre des environnements de 

programmation robotique. La sûreté de fonctionnement 

logicielle est d'autant plus importante que le logiciel 

prend une place de plus en plus importante dans les 

systèmes robotiques. 

Nous proposons dans cet article, de faire le point sur les 

architectures logicielles pour la robotique et d'examiner 

plus particulièrement sa prise en compte dans des 

applications robotiques. 

Mots Clef 

Langages de programmation de missions, architectures 

logicielles, robotique, sûreté de fonctionnement logicielle. 

1 Introduction 

Le logiciel prend une place de plus en plus importante 

dans les systèmes robotiques. Dans cet article, nous nous 

intéressons à la sûreté de fonctionnement logicielle dans 

les langages et architectures logicielles pour la 

programmation de missions robotiques. En effet, les 

systèmes robotiques sont par essence des systèmes 

critiques. L’intégration et l’adaptation de mécanismes de 

sûreté de fonctionnement, en particulier logiciels, à ces 

systèmes, est donc d’un intérêt indéniable. 

Dans la deuxième section de cet article, un bref aperçu 

des langages et architectures robotiques est présenté. La 

troisième section est quant à elle consacrée à l’utilisation 

de mécanismes de sûreté de fonctionnement du logiciel 

dans le cadre d’applications robotiques. La quatrième et la 

cinquième sections relatent deux expériences en matière 

de conception et de réalisation d’architectures logicielles 

pour des applications robotiques sûres, à savoir 

l’architecture associée au langage PILOT (Programming 

nana@univ-brest.fr 

121 

and Interpreted Language Of actions for Telerobotics) et 

une architecture de réalisation de mission de l’IFREMER. 

La première a été conçue et mise en oeuvre au sein du 

LISyC et s’applique principalement à la robotique 

mobile. La deuxième est quant à elle relative aux 

applications robotiques sous-marines. Cet article se 

termine par une conclusion en sixième section. 

2 Bref aperçu des langages et architectures 

robotiques 

2.1. Les langages de programmation de 

misions 

Les langages de programmation de missions se situent à 

haut niveau par rapport aux langages de programmation 

de robots plus classiques, consacrés à la programmation 

détaillée des mouvements des effecteurs. Ils s'appuient sur 

l'existence d'actions élémentaires fournies par une couche 

inférieure pour permettre la spécification des applications 

robotiques en terme d'ordonnancement des actions 

élémentaires. A ce jour, trois techniques ont été 

développées dans la conception de langages de 

programmation de missions : l'extension de langages 

généralistes (tels que C, ADA ou LISP) avec des librairies 

orientées robotique, la création de langages spécifiques au 

domaine de la robotique, et la modification de langages de 

contrôle tels que LUSTRE et SIGNAL. 

L'inconvénient de la première approche est l'inadéquation 

du point de vue de la spécification et du déterminisme de 

l'exécution. La deuxième présente des intérêts multiples. 

Les langages sont plus proches des langages de 

spécification, capturent mieux la sémantique du domaine 

et produisent par conséquent des programmes plus clairs 

et plus concis. De nombreux langages dédiés à la 

programmation d'applications robotiques manufacturières 

ont ainsi été créés dès la fin des années soixante-dix : LM, 

VAL, etc. Leur pouvoir d'expression est toutefois très 

orienté vers le contrôle de bras manipulateurs, ce qui 

compromet leur extensibilité à un domaine d'application 

plus vaste tel que celui de la robotique mobile. Dans la


même catégorie, d'autres langages, plus génériques dans la 

mesure où ils ne sont pas dédiés à un seul type de robot, 

ont été créés dans le monde de la recherche. C'est par 

exemple le cas du langage de manipulation des actions 

robotiques et des buts intermédiaires utilisé par le soussystème 

C-PRS du niveau décisionnel de l'architecture 

robotique du LAAS. Toutefois, ces langages ne prennent 

pas en compte, dans leur sémantique, les aspects 

cinématiques et dynamiques spécifiques à la robotique tels 

que l'enchaînement de trajectoires. Les langages de 

contrôles ont une expressivité beaucoup plus proche de la 

programmation de missions robotiques que celle des 

langages généralistes. 

2.2 Les architectures robotiques 

La communauté robotique reconnaît qu’aucune 

architecture n’est parfaite pour répondre à toutes les 

tâches, et que différentes tâches ont différents critères de 

succès qui conduisent à différentes architectures. Les 

architectures de programmation robotique peuvent être 

regroupées en quatre grandes catégories: 

- les architectures centralisées classiques 

- les architectures hiérarchiques, 

- les architectures comportementales et 

- les architectures hybrides. 

Les premiers travaux concernant les architectures de 

contrôle robotique étaient inspirés de l’intelligence 

artificielle [27], c’est-à-dire organisés autour de processus 

décisionnels et d’un état symbolique du monde et du 

robot. Les architectures conçues suivant cette philosophie 

font partie de la catégorie des architectures centralisées 

classiques. Elles placent la planification au centre du 

système et partagent l’axiome suivant lequel le problème 

central en robotique est la cognition, c’est-à-dire, la 

manipulation de symboles pour maintenir et agir sur un 

modèle du monde, le monde étant l’environnement avec 

lequel le robot interagit. Parmi les architectures 

centralisées, nous pouvons citer: le système de 

planification STRIPS du robot Shakey [28] dans lequel le 

plan est statique et le monde supposé inchangé au cours 

de l’exécution du plan, les architectures Blackboard [18] 

qui accumulent des données sur le monde et prennent des 

décisions immédiates basées à la fois sur les objectifs à 

priori variables et un monde changeant. Pour une tâche 

donnée, si le système peut modéliser le monde 

suffisamment bien, et si le monde obéit à son (ses) 

modèle(s), et si le système peut récupérer l’information 

pour l’intégrer dans le cœur de la planification centrale, 

alors une architecture centralisée classique constitue un 

bon choix pour la réalisation de la tâche. Les architectures 

centralisées conviennent bien aux tâches pour lesquelles la 

réactivité et le réflexe ne sont pas des critères essentiels. 

Les architectures hiérarchiques décomposent la 

programmation des applications en niveaux de plus en 

plus abstraits. Chaque niveau a pour rôle de décomposer 

une tâche que lui a recommandée le niveau supérieur, en 

tâches plus simples qui seront ordonnées au niveau 

122 

inférieur. Le niveau le plus haut gère les objectifs globaux 

de l’application, alors que le niveau le plus bas commande 

les actionneurs du robot. L’instance la plus connue de ce 

type d’architecture est NASREM (Nasa/nbs Standard 

REference Model) [24]. Dans la même famille, nous 

pouvons citer l’architecture du LIFIA [17] et 

l’architecture SMACH de l’I3S (Informatique, Signaux et 

Systèmes de Sophia-Antipolis) [35]. Les architectures 

hiérarchiques telles que NASREM font encore 

l’hypothèse que le meilleur moyen d’interagir avec le 

monde est à travers la manipulation et le raisonnement au 

sujet de modèles du monde, bien qu’elles reconnaissent 

qu’il doit y avoir différents modèles du monde pour 

raisonner au sujet des différents aspects du monde. Ce que 

peut réaliser un tel système, en utilisant des modèles 

prédictifs du monde, c’est une très haute précision. 

Chaque couche a un modèle de ce qui va se produire dans 

le monde, étant donné un ensemble d’entrées et de sorties, 

et il revient aux couches inférieures de s’assurer que ce 

qui était attendu se réalise précisément. Les architectures 

hiérarchiques sont appropriées pour des tâches qui 

s’exécutent dans un environnement prévisible et qui 

requièrent une haute précision. Leur principal défaut est la 

taxonomie des modules du système, a priori imposée 

artificiellement, qui sert à les restreindre plutôt qu’à les 

supporter. En effet, la façon dont chaque module dans le 

système est structuré n’est pas définie par les besoins de la 

tâche, mais par l’endroit où il s’insère dans l’architecture. 

Les architectures hiérarchiques ont généralement une 

réactivité assez faible: compte tenu de la décomposition 

systématique de la programmation, la chaîne allant des 

capteurs aux actionneurs en passant par les processus 

décisionnels capables de répondre à des changements de 

l’environnement est complexe, entraînant des temps de 

réponse longs. 

Les architectures comportementales sont nées au milieu 

des années 80 avec l’architecture “subsomption” proposée 

par Brooks [5]. Elles sont issues de l’observation de 

comportements animaux simples, et sont basées sur l’idée 

qu’un comportement complexe et évolué d’un robot peut 

émerger de la composition simultanée de plusieurs 

comportements simples. Brooks définit un comportement 

élémentaire comme “un traitement prenant des entrées 

capteurs et agissant sur les actionneurs”. L’architecture 

DAMN (Distributed Architecture for Mobile Navigation) 

proposée par Rosenblat [31] à l’Université de Carnegie 

Mellon est une autre variante des travaux de Brooks. Les 

travaux de Brooks ont mis en évidence l’atout de ce type 

d’architecture: la rapidité de la réaction du système face 

aux événements extérieurs ou à des situations spécifiques. 

Les architectures comportementales ont fait leurs preuves 

dans de nombreuses et parfois spectaculaires 

expérimentations concernant la robotique mobile, car la 

réactivité qui les caractérise permet d’aborder la 

navigation dans un environnement dynamique. Toutefois, 

la complexité des applications reposant sur cette approche 

va rarement au delà de la navigation. En effet, plusieurs


comportements sont souvent en concurrence pour le 

contrôle des actionneurs et on ne peut pas, à priori, 

assurer la stabilité d’exécution de la loi de commandes 

complexes telles que celles requises pour le contrôle de 

bras manipulateurs. Ces approches présentent une autre 

limitation: les comportements étant préétablis, le système 

s’accommode difficilement d’un changement de mission 

impromptu. 

Face aux lacunes des deux précédentes catégories 

d’architectures, certains chercheurs ont proposé des 

architectures hybrides qui allient les capacités réactives 

des architectures comportementales et les capacités de 

raisonnement propres aux architectures hiérarchiques. Ces 

architectures peuvent être suffisamment souples et 

puissantes pour que leur domaine d’utilisation en terme de 

variété de robots contrôlés et de type d’application justifie 

leur commercialisation. Parmi elles, nous pouvons citer: le 

CONTROLSHELL [33] vendu par la société 

californienne RTI (Real-Time Innovations), l’architecture 

du LAAS [ALA 98] qui a fait ses preuves dans les 

domaines de la robotique mobile, que ce soit sur les 

plates-formes HILARE ou dans l’expérience MARTHA, 

ou encore l’architecture ORCCAD (Open Robot 

Controller Computer Aided Design system) de l’INRIA 

[6][19]. L’architecture ORCCAD a la particularité d’être 

indépendante du système à piloter. Elle autorise également 

la spécification et la validation de missions en robotique. 

3 Sûreté de fonctionnement dans les langages 

et architectures robotiques 

3.1 Bref aperçu des mécanismes de sûreté de 

fonctionnement 

La sûreté de fonctionnement est une propriété importante 

aux différents niveaux du processus de contrôle et de 

commande tant en ce qui concerne la télérobotique, qu'au 

regard des systèmes automatisés de production. Elle 

touche aux différents aspects de la réalisation d'une 

mission, partant de la conception du plan à son exécution 

sur le système commandé, en passant par le processus 

d'interprétation du plan ou de génération de l'exécutable. 

Deux approches principales sont souvent utilisées pour la 

mise en oeuvre de la sûreté de fonctionnement: la 

prévention des erreurs et la tolérance aux fautes 

[22][20][21]. La prévention des erreurs vise à écarter à 

priori les fautes et les erreurs qui mettent en cause la 

fiabilité du système, et ceci avant toute utilisation 

régulière de ce dernier. Pour atteindre cet objectif, les 

principaux moyens sont l'utilisation de méthodes et de 

langages de spécifications formels et l'utilisation de tests. 

La tolérance aux fautes est quand à elle basée sur le 

principe suivant lequel la prévention des erreurs, bien que 

bénéfique, ne permet pas de garantir une élimination 

totale des erreurs dans le système. Elle a pour but de 

123 

permettre au système de se comporter de façon 

satisfaisante même en présence de fautes. 

3.2 Solutions pour la sûreté de systèmes 

La prise en compte de la sûreté de fonctionnement 

logicielle dans la conception d’architectures et de 

langages robotiques reste encore limitée de nos jours. Un 

certain nombre de travaux ont toutefois été effectués dans 

ce domaine. 

Au niveau des langages, les langages de contrôle 

disposent d'une sémantique rigoureusement établie 

(sémantique opérationnelle) et d'outils de simulation et/ou 

de vérification et/ou d'analyse, ce qui représente une plus 

value primordiale pour la sûreté des applications 

robotiques. Leur utilisation dans un contexte robotique 

nécessite toutefois des adaptations. 

Zalewski et al. [38] ont souligné la complexité des 

solutions actuellement fournies pour la vérification des 

systèmes de contrôle informatiques qui restreint leur 

applicabilité à des systèmes simples, alors que la 

complexité des applications critiques est habituellement 

élevé et continue à s’accroître drastiquement avec les 

progrès des technologies informatiques. Ils ont étudié 

deux approches principales. 

La première approche est basée sur l’« Analyse d’Arbres 

de Fautes » (AAF) et l’ « Analyse de Mode de Défaillance 

et d’Effet » (AMDE). Il s’agit de techniques d’analyse de 

sûreté utilisées avec succès dans des systèmes 

conventionnels (non basés sur l’informatique). Elles sont 

utilisées lors de la conception du système et se focalisent 

sur les conséquences de défaillances des composants. Des 

adaptations ont été proposées pour l’analyse des systèmes 

de logiciels sûrs [23]. Zalewski et al ont proposé une 

méthode d’analyse informelle de sûreté de systèmes basés 

sur le logiciel utilisant l’AAF [38]. Une application à 

l’industrie nucléaire a été effectuée [25]. L’avantage de 

cette solution est que les techniques sous-jacentes sont 

déjà bien utilisées pour de nombreuses applications 

industrielles, ce qui permet aux ingénieurs de sûreté de 

s’adapter facilement à leurs nouvelles versions. 

L’inconvénient est que ces techniques sont pour la plupart 

plutôt informelles. Une adaptation de ces solutions aux 

logiciels orientés objet a également été proposée par 

Zalewski et al. Elle fait l’hypothèse que les modèles 

orientés objets des composants logiciels sont fournis avec 

leurs spécifications formelles. Cette approche a été 

appliquée à une étude de cas de contrôle de feux de 

circulation ferroviaire. 

La deuxième approche est basée sur l’utilisation de 

méthodes formelles et semi formelles et de modèles 

initialement développés pour le domaine logiciel: logique 

temporelle, réseaux de Petri, LOTOS, modèles actionévénements, 

etc. Zalewski et al ont combiné dans un seul 

système intégré, via une interface commune, des outils


d’ingénierie traditionnels tels que ceux reposant sur UML, 

avec des outils de méthodes formelles tels que des outils 

de « model checking » ( Statecharts, etc.) [2]. 

Garbajosa et al ont proposé et mis en oeuvre un outil 

pouvant servir comme partie frontale pour le test des 

systèmes et acceptant des descriptions de tests en langage 

naturel, afin d’affranchir les ingénieurs du test de la 

nécessité d’avoir une parfaite maîtrise des systèmes 

physiques pour lesquels les tests sont définis et des 

techniques de programmation, qui leurs sont peu 

familiers [10]. 

Rutten a proposé une trousse à outils pour la 

programmation sûre d’applications robotiques [32]. Cette 

dernière est basée sur la synthèse de contrôleurs [30]. 

Différents autres travaux basés sur l’utilisation des 

techniques d’intelligence artificielle ont été effectués pour 

le diagnostic de faute [39] et la supervision [13]. 

3.3 Mise en œuvre dans les langages et 

architectures robotiques 

Seabra Lopes et al proposent dans [34], une architecture 

pour l’assemblage de tâches qui fournit à différents 

niveaux d’abstraction, des fonctions pour 

l’ordonnancement des actions, le contrôle de leur 

exécution, le diagnostic et le recouvrement d’erreur. La 

modélisation des défaillances d’exécution faite à travers 

des taxonomies et des réseaux de causalité joue un rôle 

central dans le diagnostic et le recouvrement. 

Dans l’architecture de subsomption les comportements 

sont modélisés chacun par une (ou plusieurs) machine(s) à 

états finis augmentée(s). Cette modélisation permet 

l’application de méthodes de vérification, mais aussi la 

mise en œuvre de mécanismes de tolérance aux fautes par 

l’exploitation des suppresseurs et des inhibiteurs. 

Dans l’architecture du LAAS le niveau décisionnel est 

réactif aux comptes-rendus d’exécution des niveaux 

inférieurs. Ces comptes-rendus peuvent être exploités 

pour la mise en œuvre d’actions de recouvrement. 

L’architecture ORCCAD de l’INRIA est une des 

architectures qui mettent un accent sur la sûreté des 

applications [36]: 

o Exécution temps réel rigoureuse des lois de 

commande. 

o Utilisation du langage synchrone ESTEREL pour la 

spécification de la partie contrôle. 

o Utilisation des outils de vérification formelle pour la 

partie contrôle des applications. 

L’aspect sécuritaire dans la réalisation de missions 

robotiques a également été l’une des motivations 

principale du projet « Architecture Logicielle pour la 

124 

Interpréteur 

Mémoire partagée 

Socket 

Interface Homme Machine 

Serveur 

Exécution 

ROBOT 

Générateur 

des règles 

Évaluateur 

Liaison sans fil 

FIG. 2 – Système de contrôle PILOT 

robotique mobile et téléopérée » qui a conduit à la 

création du langage PILOT et de son architecture 

logicielle. Dans la section suivante, nous présentons les 

travaux réalisés dans ce contexte pour la sûreté de 

fonctionnement des applications robotiques. Une brève 

description de l’architecture de contrôle du langage 

PILOT est d’abord effectuée. L’approche de sûreté et les 

solutions mises en œuvre dans le cadre de cette 

architecture sont ensuite abordées. 

4 Mécanismes de sûreté de l’architecture 

PILOT 

4.1 Architecture logicielle PILOT 

Le système de contrôle de PILOT (FIG. 1) est l'interface 

entre l'utilisateur et la machine pilotée (Robot Cible) [9] 

[26]. Il comporte six modules: une Interface Homme 

Machine (IHM), un Serveur de Communication, un 

Générateur de Règles, un Evaluateur, un Module 

d'Exécution ou Driver et un Interpréteur. Ces modules 

sont exécutés en parallèle et communiquent par socket et 

par mémoire partagée. Le système de contrôle peut 

s'exécuter soit en mode centralisé, soit en mode distribué. 

Le choix du mode d'exécution est effectué de façon 

statique (avant la compilation). L'IHM fournit des moyens 

pour la construction de plans, la création dynamique 

d'actions (sans recompilation du code), et la modification 

du plan avant et au cours de l'exécution de ce dernier. Elle 

intègre également des moyens pour la supervision de 

l'exécution du plan. L'IHM stocke le plan dans une zone


de mémoire partagée avec l'interpréteur. Ce dernier lit le 

plan en mémoire partagée et envoie des ordres (demande 

d'évaluation de précondition d'une action, ordre de 

démarrage de l'action, etc.) aux autres modules afin de 

réaliser l'exécution du plan. Le serveur de communication 

gère les communications inter modules. Le rôle du 

générateur de règles est de transformer les chaînes de 

caractères des règles de préconditions et de surveillance 

en arbres binaires. Il stocke le résultat dans une zone de 

mémoire partagée avec l'évaluateur. Ce dernier évalue les 

règles de précondition et de surveillance à partir des 

arbres binaires correspondants. Le module d'exécution 

réalise l'interface entre le robot et le système de contrôle. 

Il traduit les ordres de haut niveau du plan en ordres de 

bas niveau compréhensibles par la machine téléopérée. Le 

module d'exécution supporte différents protocoles de 

communication (connexion série, Ethernet, FDDI). 

4.2 Sûreté de fonctionnement avec PILOT 

4.2.1 Mécanismes internes 

Les actions PILOT comportent des règles de 

précondition et de surveillance. Ces règles constituent 

des moyens de sûreté pour l'application PILOT. En effet, 

une action ne peut être exécutée que si sa précondition est 

vraie. De même, lorsqu'une règle de surveillance est 

satisfaite, le traitement associé est effectué (le traitement 

par défaut est l'arrêt de l'action). Ce mécanisme est 

équivalent au mécanisme des exceptions et constitue une 

solution pour la mise en oeuvre de la tolérance aux fautes. 

Si nous considérons par exemple l'action avancer pour un 

robot mobile équipé de détecteurs d'obstacles, une règle 

de précondition pourrait être le test d'absence d'obstacle. 

L'une des règles de surveillance serait par exemple le test 

de présence d'obstacle avec comme traitement associé 

l'arrêt de l'exécution de l'action. 

Les plans PILOT sont modifiables au cours de leur 

exécution, ce qui est un atout majeur pour la tolérance aux 

fautes. En effet, l'opérateur peut, en cas de 

dysfonctionnement dans l'exécution d'un plan, apporter 

des modifications permettant au système de revenir dans 

un état de fonctionnement satisfaisant (poursuite de la 

mission ou arrêt dans un état sûr). 

La nature interprétée du langage et la possibilité de 

modifier des plans en cours d'exécution rendent possible 

l'exécution de plans incomplets. On peut ainsi lancer 

l'exécution d'un plan sans fin de séquence principale ou 

contenant une structure parallèle dont l'exécution ne peut 

se terminer en l'état parce qu'elle est incomplète. Afin de 

pallier cet inconvénient, l’environnement de contrôle de 

PILOT a été doté d’un mécanisme d’édition dirigée par 

la syntaxe permettant de garantir la validité syntaxique du 

plan à chaque phase de sa construction (insertion, 

modification, suppression de primitives). Cette approche 

permet de préserver les avantages de la possibilité de 

125 

modifier dynamiquement des plans: terminaison de plans 

bien assurée, etc. 

L’édition dirigée par la syntaxe ne prend pas en compte la 

validité sémantique du plan lors de sa modification au 

cours de l'exécution. Une approche basée sur le 

formalisme de « synthèse des contrôleurs » a été 

incorporée dans l’architecture de contrôle afin de 

sécuriser les modifications en cours d'exécution, 

notamment par la gestion d'aspects tels que la suppression, 

l'insertion ou la suppression de primitives. Grâce à ce 

travail, il est désormais possible d'effectuer des actions de 

compensation ou de recouvrement d'erreurs « sécurisées » 

en cours de mission. 

4.2.2 Mécanismes liés au processus de 

développement 

Les différents modules du système de contrôle du langage 

PILOT ont été modélisés à l'aide d'automates d'états 

finis et des algorithmes d'interprétation ont été définis 

pour les différentes primitives du langage. Ces éléments 

fournissent une bonne base pour la prévention d'erreurs 

(application de méthodes de vérification formelle). Ils 

permettent en outre d’éviter des erreurs dues à la 

distorsion de l'information tout au long du processus de 

développement logiciel. 

Afin d’augmenter la robustesse du système PILOT des 

approches de tests statique et dynamique ont été 

appliquées à son interpréteur qui est l’un de ses modules 

les plus critiques. La nature réactive des applications 

robotiques augmente la complexité des opérations de test, 

car l'on doit, en plus des facteurs usuels, prendre en 

compte les événements difficilement maîtrisables générés 

par le robot. Un autre point important est la prise en 

compte des dommages éventuels que peuvent engendrer 

des tests effectués directement sur le robot. Un simulateur 

de robot simple a donc été construit pour les opérations de 

test. 

Le test statique a consisté, d'une part, en la lecture du 

code source dans le but de détecter les erreurs de 

programmation et, d'autre part, en l'analyse du code 

source par rapport aux algorithmes d'interprétation et la 

sémantique de PILOT. 

Le test dynamique a, quant à lui, consisté en la définition 

de jeux de tests et en leur application au code binaire de 

l'interpréteur. Les données de test ont été définies en 

combinant une approche fonctionnelle au retour 

d'expérience des tests déjà effectués. Pour la définition de 

l'échantillon représentatif des données de test, nous avons 

adopté une approche incrémentale. La séquence vide a 

d'abord été testée, puis les autres primitives du langage 

ont été testées individuellement. Trois combinaisons des 

primitives du langage ont ensuite été considérées: 

• Combinaison en longueur par l'accroissement du 

nombre d'éléments dans les séquences du plan. 

• Combinaison en largeur par l'accroissement du

nombre de branches dans le parallélisme, la 

préemption ou la conditionnelle. 

• Combinaison en profondeur par l'accroissement du 

niveau d'imbrication. 

Afin d'avoir un ensemble borné de jeux de tests, nous 

avons émis un ensemble d'hypothèses: les actions du 

même type sont interchangeables, l'ensemble des 

séquences résultant de la combinaison de paires 

quelconques de primitives est représentatif de l'ensemble 

des séquences comportant deux ou plus de primitives 

excepté pour les problèmes de mémoire, etc. 

Chacune des approches de test appliquées à l'interpréteur 

a permis de détecter des erreurs de différentes natures 

(erreur de conception dans la gestion des interruptions 

logicielles et dans la gestion de la terminaison des actions 

continues, erreurs de programmation, etc.). Ces erreurs 

ont été corrigées et très peu de dysfonctionnements ont été 

observés dans l'utilisation de l'interpréteur depuis ce 

travail. 

Bien que les techniques de test statiques et dynamiques 

décrites ci-dessus se soient révélées très utiles dans la 

détection et la correction d'erreurs dans les programmes 

d'interprétation, leur utilisation ne permet pas de garantir 

la conformité de l'interprétation des plans à la sémantique 

Préparation de 

mission et 

Exploitation de 

données 

Navire/ 

Laboratoire 

Scientifique 

Données plongée 

(Synthèse technique) 

Navire 

Opérationnel 

Engin 

Autonome 

- Cartographie 

- Données 

Scientifiques 

- Trajectoires et 

actions 

- Validation 

opérationnelle 

Superviseur de 

Surface 

- Checklist 

- Diagnostic 

a) Pont 

b) Fibre optique 

c) Lien acoustique 

- Configuration 

engin 

Contrôleur Engin 

FIG. 2 – Architecture globale 


Trajectoire et actions 

“mission” 

Diagnostic 

Intelligent 

de Surface 

Configuration “plongée” 

Diagnostic 

Intelligent 

Engin 

Données 

archivées 

Données 

126 

opérationnelle du langage PILOT. Un travail 

complémentaire a été fait pour pallier cet inconvénient. Il 

a consisté à modéliser les algorithmes d'interprétation 

et à vérifier leur conformité par rapport à la 

sémantique opérationnelle du langage afin de corriger 

les éventuels dysfonctionnements et de régénérer le code 

de l'interpréteur à partir du modèle validé. Les réseaux de 

Petri colorés (RdPC) ont été utilisés pour la modélisation 

et la vérification. Le support logiciel utilisé a été 

Design/CPN (http://www.daimi.aau.dk/DesignCPN). 

Les RdP et plus particulièrement les RdP colorés ont été 

choisis pour différentes raisons. Leur nature graphique 

offre la convivialité souhaitée dans le but d'utiliser 

ultérieurement le modèle comme médium de 

communication entre les différentes personnes impliquées 

dans le développement du logiciel de contrôle, afin 

d'éviter des erreurs dues à la distorsion de l'information. 

Ils permettent de représenter relativement simplement les 

différents concepts de l'algorithmique et de la 

programmation. La disponibilité d'outils, pour la 

simulation et la vérification des modèles, a également été 

un critère important. 

La modélisation a permis de constater que des 

simplifications sont envisageables tant au niveau de la 

représentation interne d'un plan, qu'au niveau des 

algorithmes d'interprétation, et d'appliquer ces dernières 

au système de contrôle. Des plans de tests ont été générés 

en s'appuyant sur l'approche adoptée au cours du test 

dynamique des algorithmes d'interprétation. La simulation 

de l'exécution de ces plans a permis de détecter des 

problèmes de terminaison. Cette dernière ne permettant 

d’explorer, dans la pratique, qu’une partie des chemins 

d’exécution, un travail complémentaire a été effectué. A 

partir des RdPC modélisant les algorithmes 

d'interprétation et d'un plan de test, le graphe des 

marquages accessibles correspondant aux chemins 

d'exécutions possibles est généré à l'aide de l'outil 

Design/CPN. Le graphe des marquages et le plan de test 

sont ensuite transmis au programme de vérification qui 

examine, pour chacun des chemins d'exécution, la 

satisfaction de la sémantique opérationnelle du langage. 

Une extension de l’environnement Design/CPN a été 

effectuée pour intégrer notre programme de vérification. 

Après cette présentation des mécanismes de sûreté offerts 

par l’environnement PILOT et des approches de tests et 

de vérification adoptées pour renforcer sa robustesse, 

nous présentons, dans la section suivante, l’étude et 

l’intégration de mécanismes de sûreté de fonctionnement 

dans une architecture globale de préparation, de 

supervision et d’exécution de missions d’engins sousmarins 

autonomes (Fig. 2.). Ce travail s’est effectué en 

collaboration avec la Division Robotique de l’IFREMER 

Toulon. Nous présenterons les solutions proposées pour la 

sûreté ainsi que les propositions faites pour leur mise en 

œuvre aux différents niveaux de l’architecture.

5. Mécanismes de sûreté pour des missions 

d’engins sous-marins autonomes 

5.1 Niveau préparation de mission 

Deux approches sont abordées pour la sûreté: la 

vérification de propriétés et la tolérance aux fautes. Nous 

les abordons dans les sous-sections qui suivent. 

5.1.1 Vérification de propriétés 

Actions de 

l’engin 

Description 

« informelle » 

de la mission 

Système de 

Spécification 

formelle 

Données Cartographiques 


Caractéristiques de l’engin 

Propriétés spécifiques 

Description 

formelle de 

la mission 

Contraintes 

Système de 

vérification 

formelle 

FIG. 3 – Système de spécification et de vérification 

Résultat 

Il s’agit de vérifier l’adéquation entre les contraintes 

issues de la spécification de la mission et les 

caractéristiques de l’engin et de l’environnement 

(accessibilité de la zone à explorer, précision des capteurs 

et de la trajectoire, fréquence d’acquisition des mesures, 

durée de la mission, énergie, limites de vitesse et 

d’altitude, capteurs et charges utiles adaptées à la mission, 

temps de calibration, maintien - si nécessaire - de l’engin 

dans la zone à explorer), de vérifier la cohérence, en 

terme d’enchaînement d’actions et de logique d’exécution 

de la mission spécifiée par le scientifique (par exemple, 

certaines exécutions ne peuvent être faites en parallèle, les 

post-conditions d’une action et les préconditions de 

l’action suivante peuvent être incompatibles), et 

d’effectuer des diagnostics sur l’engin, le système de 

contrôle, et leurs modèles éventuels (les données des 

plongées précédentes pourront être utilisées pour ajuster 

certains paramètres du diagnostic). La phase de diagnostic 

pourra permettre, par exemple, de vérifier la terminaison 

de la mission. 

La figure 3 montre la structure du sous-système de 

spécification et de vérification proposé à ce niveau. 

Différents outils sont envisageables pour la conception et 

la spécification. Nous pouvons citer l’environnement 

STOOD de TNI-Europe qui permet par ailleurs de générer 

des programmes pour différents systèmes de vérification. 

Au niveau de la vérification, les approches de « modelchecking 

» et de démonstration peuvent être explorées. 

Différents outils sont disponibles. Certains outils 

s’appuient sur l’approche synchrone très utilisée pour la 

127 

conception de systèmes réactifs dont font partie les 

systèmes robotiques: outils commerciaux tels que SCADE 

et ESTEREL [8], SILDEX [11], environnement CELL 

CONTROL spécialisé pour les automatismes industriels 

de ATHYS [12]. D’autres formalismes graphiques de 

spécification et de vérification, synchrones et dédiés au 

contrôle commande tels que STATECHARTS [16], 

SYNCCHARTS [3] et GRAFCET [1], ou asynchrones 

tels que les Réseaux de Petri, offrent également des 

possibilités intéressantes. 

L’approche de démonstration a également donné lieu à 

différents outils de preuves (prouveurs) [14]: Isabelle 

[29], HOL [15], Coq [7], PVS [37], Boyer-Moore [4]. La 

plupart de ces systèmes utilisent des logiques d’ordre 

supérieur qui sont extrêmement souples et expressives. 

5.1.2 Tolérance aux fautes 

Il s’agit ici de prendre en compte les défaillances 

envisageables afin de permettre, au niveau de la définition 

de la mission, de prévoir des actions de recouvrement. 

L’environnement de conception de plans de missions 

devra fournir des moyens permettant d’intégrer les 

réactions aux défaillances (mécanismes de recouvrement). 

Dans l’élaboration du plan de mission, on pourra prévoir 

2 cas de figures: 

• Introduction de la redondance pour pallier certaines 

défaillances, par exemple modification de la 

trajectoire initiale suite à la détection d’un obstacle. Il 

s’agit dans ce cas de créer un plan de « repli » pour la 

partie jugée critique. La gestion d’un tel aspect 

dépend également de la richesse du système de 

contrôle qui peut déjà être équipé d’un mécanisme 

automatique de contournement d’obstacle. 

• Classement des actions par niveau de « criticité » de 

façon à prendre les actions de compensation 

appropriées en cas de dysfonctionnement (abandon et 

passage à l’action suivante, abandon de la mission, 

saut à une action spécifique ou à un point particulier 

du plan de mission, …). 

L’approche proposée pour l’intégration de mécanismes de 

traitement d’erreur consiste, après construction du plan de 

mission standard (c’est-à-dire ne prenant pas en compte la 

gestion de fautes autres que celles spécifiées lors de la 

création des actions), à spécifier pour chaque action ou 

primitive le traitement de fautes correspondant. La 

primitive est sélectionnée et les conditions de fautes, ainsi 

que les réactions associées sont définies. Le système de 

spécification se sert alors du plan et des données saisies 

pour générer le fichier de plan de mission incorporant le 

traitement de fautes. 

Au niveau des actions, les conditions et traitements de 

fautes initiaux de l’action sont étendus en cas de besoin 

pour prendre en compte de nouvelles conditions de fautes 

et leur associer les traitements souhaités. Les conditions 

de fautes sont des expressions logiques basées sur des


valeurs de capteurs, les états d’exécution d’actions ou de 

primitives et les états de fautes reçus du système de 

contrôle « bas niveau ». 

Les réactions associées aux conditions de fautes sont: 

l’arrêt de l’action ou de la primitive (il faudra tenir 

compte du caractère interruptible ou non de l’action) et/ou 

le saut vers un point du plan et/ou l’exécution d’une 

séquence à définir. 

5.2 Niveau superviseur de surface 

Deux aspects sont considérés à ce niveau, la supervision 

de la mission et la vérification de propriétés relatives au 

déroulement de la mission. 

Il s’agit, pour la supervision de mission, de récupérer des 

informations relatives au déroulement de la mission et de 

les rendre disponibles, par affichage à l’écran et 

éventuellement stockage dans un fichier accessible par 

l’utilisateur, afin de permettre à l’opérateur de prendre des 

décisions notamment en cas de dysfonctionnement. Les 

données récupérées sont les valeurs de capteurs, les états 

d’exécution des actions, les états de défaillances 

éventuelles (alarmes, etc.). 

En ce qui concerne la vérification de propriétés, un 

Système de Diagnostic Intelligent (SDI) permet 

d’effectuer des vérifications plus élaborées sur le 

déroulement de la mission. Il est formé de modules de 

diagnostic intelligent ayant chacun sa spécificité (par 

exemple une technique particulière d’intelligence 

artificielle ou la gestion d’un type de fautes particulier), et 

d’un module de décision. Le module de décision est 

chargé, d’une part, de collecter les informations utiles au 

diagnostic et de les transmettre aux modules de diagnostic 

intelligent appropriés, et, d’autre part, d’effectuer la 

synthèse des informations de diagnostic reçues des 

différents modules de diagnostic intelligent afin de 

transmettre, aux modules le requérant (par exemple, le 

système contrôlé ou un autre module réalisant par 

exemple une trace des défaillances), les informations sur 

les anomalies détectées ou les ordres de correction. 

Les différents diagnostics et recouvrements envisagés au 

niveau des SDI sont les suivants: 

• Diagnostic de défaillance des effecteurs, 

• Diagnostic de défaillance des liens de 

communication, 

• Contrôle des batteries (autonomie), 

• Contrôle de la précision de la trajectoire, 

• Contrôle de la précision/qualité des données 

mesurées, 

• Contrôle du logiciel de contrôle embarqué (cas 

de défaillance partielle). 

Pour la défaillance totale du logiciel de contrôle 

embarqué, des procédures de recouvrement sont 

prédéfinies. De même, le contrôle de l’ordinateur de 

surface et de son logiciel est assuré par l’opérateur. 

128 

Le diagnostic de défaillance des effecteurs des AUVs peut 

être considéré comme un problème de classification 

ordinaire. La disponibilité d’expertises humaines et 

d’exemples oriente cependant vers le choix d’une solution 

basée sur le mixage des approches symboliques et 

neuronales. En ce qui concerne le recouvrement de ces 

défaillances, il n’existe pas pour l’instant de base 

d’exemples. Il s’agit d’un problème de contrôle, pour 

lequel la théorie automatique classique ne peut être 

appliquée, dont le recouvrement est plus lié aux stratégies 

de contrôle qu’aux approches de contrôle. Etant donné 

que la sélection des stratégies de contrôle peut dépendre 

de plusieurs contraintes quelquefois difficiles à mesurer 

ou exprimer, la théorie de contrôle de la logique floue 

semble être une solution intéressante. 

Le diagnostic des liens de communication et le contrôle de 

la batterie de l’AUV sont des problèmes similaires. Ils 

correspondent davantage à des problèmes de gestion de 

risques qu’à des méthodes de diagnostic pur. Par 

conséquent, l’objectif n’est pas uniquement d’effectuer un 

diagnostic par l’étude d’une situation statique donnée, 

mais au contraire d’observer l’évolution de cette situation 

dans le temps, et puis d’évaluer le risque d’avoir une 

défaillance ou une situation de conflit. Les outils basés sur 

des méthodes probabilistes tels que les réseaux Bayésiens 

sont particulièrement bien adaptés à ce type de problème. 

5.3 Niveau contrôleur d’engin 

Le sous-système de sûreté au niveau contrôleur engin 

comporte un Système de Diagnostic Intelligent dont le 

principe est le même que celui du niveau Supervision de 

Surface, un gestionnaire de modes, un gestionnaire de 

fautes, un gestionnaire d’énergie, un système 

d’archivage et un module de conversion. Un protocole 

robuste est utilisé pour le transfert de la mission entre la 

surface et l’engin, afin de se prémunir contre toute 

corruption de données et contre l’exécution de missions 

incomplètes. La mise à jour du plan doit être possible à 

tout moment à travers une liaison acoustique (mode 

immergé), radio ou télémétrique (modes surface et « sous 

surface »). Contrairement au SDI de Surface, dont le rôle 

est celui d’un agent chargé d’analyser / diagnostiquer les 

fautes, de fournir à l’opérateur une synthèse des résultats 

des diagnostics et, éventuellement, de lui proposer des 

actions à entreprendre pour pallier les défaillances 

(l’opérateur est seul chargé d’envoyer les ordres d’actions 

correctives à l’engin), le Système de Diagnostic 

Intelligent de l’Engin a un fonctionnement autonome. Sur 

la base des diagnostics qu’il aura effectués, il proposera 

directement les actions correctives au Système de 

Contrôle de l’Engin. Le gestionnaire de mode contrôle 

l’ensemble des transitions d’états du véhicule. Le 

gestionnaire de fautes détecte les fautes du véhicule et 

prend les actions sur fautes prédéfinies. Les réponses sur 

fautes possibles sont: « stop et surface », « change l’étape 

de la mission », « ignore la faute et continue ». Le 

gestionnaire d’énergie gère l’énergie du passé et prévoit 

l’énergie du futur. Lorsque l’énergie atteint certains


niveaux de « commutation », un événement 

d’avertissement et un événement d’alarme sont 

déclenchés. Le sous-système d’archivage mémorise les 

données relatives à la mission. Il transmet au Système de 

Diagnostic Intelligent Engin (SDIE) des informations lui 

permettant de vérifier la cohérence des données et de 

détecter d’éventuelles anomalies. Le module de 

conversion se charge de convertir les actions de 

recouvrement demandées par le SDIE en une séquence 

adaptée aux modules destinataires, et de convertir les 

informations émanant des autres modules dans un format 

adapté au SDIE. 

6. Conclusion 

En ce qui concerne la sûreté de fonctionnement logicielle, 

la majorité des travaux porte sur le diagnostic et le 

traitement de fautes à l’aide de techniques d’intelligence 

artificielle. Seules quelques architectures logicielles 

intègrent ou ont donné lieu à l’utilisation de méthodes 

formelles. De même, les mécanismes de tolérance aux 

fautes logicielles sont peu exploités. L’utilisation 

croissante de la programmation distribuée dans ces 

architectures, nécessite pourtant d’incorporer des 

mécanismes tels que la réplication très souvent prise en 

compte au niveau matériel. L’on peut également noter le 

peu de report d’expériences en matière de tests rigoureux 

dans la réalisation de ces architectures qui, bien que dû 

peut-être à la perception même des activités de tests, 

traduit un manque d’intérêt en la matière. Ces activités de 

test sont pourtant très importantes dans le processus de 

développement de logiciels sûrs. 

De façon globale, les éléments susmentionnés renforcent 

la nécessité d’un effort dans l’application de techniques 

relatives à la sûreté de fonctionnement à conception et la 

mise en oeuvre d’architectures robotiques. 

Les travaux réalisés dans le cadre de la conception de 

l’architecture logicielle PILOT ont apporté des solutions 

génériques pour la sûreté de fonctionnement 

d’applications robotiques: mécanisme d’édition dirigée 

par la syntaxe, recouvrement d’erreur à travers la 

possibilité de modification de missions en cours 

d’exécution, mécanisme de sécurisation de modifications 

en cours d’exécution. Les approches de tests statique et 

dynamique et les méthodes formelles (modélisation et 

vérification à l’aide de RdP colorés) appliquées à 

l’interpréteur de plans peuvent également s’appliquer à 

d’autres environnements de programmation de mission. 

Dans le cadre de l’étude de mécanismes de sûreté pour 

l’architecture de programmation de missions d’AUV une 

approche pour la gestion des fautes été proposée. L’idée 

novatrice dans cette approche est la hiérarchisation de la 

gestion des fautes, et la spécification par extension qui 

permet, d’une part, d’étendre la gestion initiale de fautes 

intégrée à l’action, évitant ainsi la redondance des 

traitements, et, d’autre part, d’avoir une gestion de fautes 

associée à chaque primitive. Les solutions proposées aux 

différents niveaux de l’architecture globale de préparation 

de mission sont applicables à d’autres environnements 

129 

similaires voire à des applications robotiques dans des 

domaines non maritimes (robotique mobile terrestre ou 

manufacturière). 

Références 

[1] ADEPA, Le Grafcet, Cépaduès Editions, Paris, 

France, 1992. 

[2] Al-Daraiseh, A., Zalewski, J. and Toetenel, H. 

Software engineering in ground transportation 

systems. In Proceedings of the SCI’01, 5 th world 

multiconference on systemics, cybernetics and 

informatics. Orlando, FL., July, 2001. 

[3] André C., Representation and analysis of reactive 

behaviors: A synchronous approach, In CESA'96, 

IEEE-SMC, Lille, France, 1996. 

[4] D.J.B. Bosscher, I. Polak and F.W. Vaandrager. 

Verification of an audio control protocol. In H. 

Langmaak, W. P. de Roever and J. Vytopil, editors. 

Proceedings of the third School and Symposium on 

Formal Techniques in Real-Time and Fault-Tolerant 

Systems, volume 863 of Lecture Notes in Computer 

Science, pages 170-192, Springer-Verlag. 

[5] Brooks R. A., A robust layered control system for a 

mobile robot, IEEE Journal of Robotics and 

Automation, pages 14-23, Mars 1986. 

[6] Castillo E., D. Simon, B. Espiau and K. Kapellos, 

Computer-aided design of a generic robot controller 

handling reactivity and real-time control issues, 

Rapport de recherche 1801, INRIA, November 1992. 

[7] Devillers M.C.A., W.O.D. Griffioen, J.M.T. Romijn 

and F.W. Vaandrager. Verification of a leader election 

protocol: formal methods applied to IEEE 1394. 

Report CSI-R9728, Computing Science Institute, 

Nijmegen, 1997. 

[8] Dima C., A. Girault, C. Lavarenne, and Y. Sorel. Offline 

real-time fault-tolerant scheduling. In 9 th 

Euromicro Workshop on Parallel and Distributed 

Processing, PDP’01, pages 410-417, Mantova, Italy, 

février 01. 

[9] Fleureau J.L., L. Nana Tchamnda, L. Marcé and L. 

Abalain, Remote-controlled vehicle using PILOT 

Language, In ANS'99, Pittsburgh, Pennsylvania, 

American Nuclear Society, 1999. 

[10] Garbajosa J., O. Tejedor and M. Wolff. Natural 

language front end to test systems. Annual review in 

Automatic Programming, vol. 19, pp. 261-267, 1994. 

[11] Girault A. Sur la répartition de programmes 

synchrones. Thèse de Doctorat, INPG, Grenoble, 

France, Janvier 1994. 

[12] Girault A. Elimination of redundant messages with a 

two pass static analysis algorithm. Parallel computing, 

28(3):433-453, mars 2002. 

[13] Gomez P., S. Romero, P. Serrahima and I. Alarcon, 

A real time expert system for continuous assistance in 

process control: a successful approach, Annual Review 

in Automatic Programming, vol. 19, pp. 371-375, 

1994.


[14] Groote J. F., F. Monin and J.C. Van de Pol. Checking 

verification of protocols and distributed systems by 

computer. In D. Sangiorgi and R. de Simone, 

Proceedings of Concur’98, Sophia Antipolis, LNCS 

1466, pages 629-655, Springer-Verlag, 1998. 

[15] Goldschlag D. M. Verifying safety and liveness 

properties of a daily insensitive fifo circuit on the 

Boyer-Moore prover. International Workshop on 

Formal Methods in VSLI Design, 1991. 

[16] Harel D., STATECHARTS: A visual approach to 

complex systems, Science of Computer Programming, 

8(3), 231-274, 1987. 

[17] Hassoun M. and C. Laugier, Reactive motion 

planning for an intelligent vehicle, In Intelligent 

Vehicles'92 Symposium, pages 259-264, Detroit, july 

1992. 

[18] Hayes-Roth B., A blackboard architecture for 

control, Artificial Intelligence, 26:pp. 251-321, 1985. 

[19] Kapellos K., D. Simon and B. Espiau, Control laws, 

tasks, procedures with ORCCAD; application to the 

control of an underwater arm, In 6th IARP 

(International Advanced Robotic Program), La Seyne 

sur Mer, France, 1996. 

[20] Kermarrec Y., L. Nana and L. Pautet, Implementing 

recovery blocks in GNAT: a powerful fault tolerance 

mechanism and a transaction support, In ACM, 

editor, Proceedings of the TRI-Ada'95 Conference, 

Anaheim, California, Novembre 1995. 

[21] Kermarrec Y., L. Nana, L. Pautet, « Providing faulttolerant 

services to distributed Ada 95 applications », 

In ACM, editor, Proceedings of the Tri Ada'96 

conference, Philadelphia, USA, Décembre 1996. 

[22] Laprie J. C., « Sûreté de fonctionnement des 

systèmes informatiques et tolérance aux fautes: 

concepts de base », TSI, 4(5):419-429, Septembre 

1985. 

[23] Leveson, N., Cha, S.S., Shimeall, T. J., 1991. Safety 

and verification of Ada programs using software fault 

trees. IEEE Software 8(7), 48-59, 1991. 

[24] Lumia R., J. Fiala and A. Wavering, The NASREM 

robot control system and testbed, IEEE Journal of 

Robotics and Automation, 5(1), pp. 20-26, 1990. 

[25] Maier T., FMEA and FTA to support safety design of 

embedded software in safety-critical systems. In 

Proceedings of the ENCRESS conference on safety 

and reliability of software based systems. Belgium, 

1995. 

[26] Nana Tchamnda L., J.L. Fleureau and L. Marcé, A 

control system for PILOT: software architecture and 

implementation issues, ANS'01, ANS 9th International 

Topical Meeting on Robotics and Remote Systems, 

Seattle, Washington, March, 2001. 

[27] Nilsson N., A mobile automation: an application of 

artificial intelligence techniques, In Proc. Int. Joint 

Conf. on Artificial Intelligence, pp. 509-520, 1969. 

[28] Nilsson N., Shakey the robot, Technical Report 323, 

SRI, Menlo Park, CA. 

130 

[29] Paulson L. C. On two formal analyses of the 

Yahalom protocol. Technical report 432, Computer 

Laboratory, University of Cambridge, 1997. 

[30] Ramadge P. J., Wonham W. M., « The control of 

discrete event systems », Proceedings of the IEEE, 

Special issue on dynamics of discrete event systems, 

vol. 77, no. 1, pages 81-98,1989. 

[31] Rosenblatt J., DAMN: A distributed architecture for 

mobile navigation, Journal of Experimental and 

Theoretical Artificial Intelligence, 9(2/3), pp. 339-360, 

1997. 

[32] Rutten E., A framework for using discrete control 

synthesis in safe robotic programming », Rapport de 

recherche, INRIA, 2000. 

[33] Schneider S., V. Chen, G. Pardo-Castellote and H. 

Wang, ControlShell: A software architecture for 

complex electro-mechanical systems, International 

Journal of Robotics Research, Special issue on 

Integrated Architectures for Robot Control and 

Programming, 1998. 

[34] Seabra Lopes L. and L.M. Camarinha-Matos, 

Learning to diagnose failures of assembly tasks, 

Annual Review in Automatic Programming, vol 19, 

pp. 97-103, 1994. 

[35] Tigli J.Y., Vers une architecture de contrôle pour 

robot mobile orientée comportement, SMACH, Thèse 

de Doctorat, Université de Nice - Sophia Antipolis, 

Janvier 1996. 

[36] Turro N., MaestRo: Une approche formelle pour la 

programmation d'applications robotiques, Thèse de 

doctorat, Université de Nice - Sophia Antipolis, 

Septembre 1999. 

[37] Vitt J. and J. Hooman. Assertional specification and 

verification using PVS of the Steam Boiler Control 

System. In J.-R. Abrial, et al., editors, Formal Methods 

for Industrial Applications: Specifying and 

Programming the Steam Boiler Control. Volume 1165 

of Lecture Notes in Computer Science, 1996. 

[38] Zalewski, J., W. Ehrenberger, F. Saglietti, J. Gorski 

& A. Kornecki, Safety of computer control systems: 

challenges and results in software development, 

Annual Review in Control, vol. 27, pp. 23-37, 2003. 

[39] Zhang J., A. J. Morris and G. A. Montague, Fault 

diagnosis of a cstr using fuzzy neural networks, 

Annual Review in Automatic Programming, vol 19., 

pp. 153-158, 1994.

ORCCAD, a framework for safe robot control design and 

implementation 

Daniel Simon, Roger Pissard-Gibollet and Soraya Arias 

INRIA Rhône-Alpes, 655 avenue de l’Europe 

38330 MONTBONNOT ST MARTIN, FRANCE 

http://sed.inrialpes.fr/Orccad/ 

Abstract 

Robotic systems are typical examples of hybrid systems where continuous time aspects, related to control laws, must 

be carefully merged with discrete-time aspects related to control switches and exception handling. These two aspects 

interact in real-time to ensure an efficient nominal behaviour of the system together with safe and graceful degradation 

otherwise. In a mixed synchronous/asynchronous approach, ranging from user’s requirements to run-time code, Orccad 

provides formalised real-time control structures, the coordination of which is specified using the ESTEREL synchronous 

language. CAD tools have been developed and integrated to help the users along the steps of the design, verification, 

implementation and exploitation processes. 

1 Motivation 


A fully fledged robotic system includes various subsystems coming from various fields of science and technology like 

mechanical engineering, automatic control, data processing and computer science. The goal of the control architecture is 

to organise coherently all these subsystems so that the global system behaves in an efficient and reliable way to match the 

end-user’s requirements. 

Robotics primarily deals with physical devices like arms or vehicles. These devices are governed by the laws of 

physics and mechanics. Compared with virtual, purely computing systems, they exhibit inertia and their models are never 

perfectly known. Usually their behaviour can be described by differential equations where time is a continuous variable. 

Their state can be measured using sensors of various kind which themselves are not perfect. Control theory provides a 

large set of methods and algorithms to govern their basic behaviour through closed-loop control ensuring the respect of 

required performance and crucial properties like stability. 

Robots of any type interact with their physical environment. Although this environment can be sensed by exteroceptive 

sensors like cameras or sonars, it is only partially known and can evolve through robot actions or external causes. Thus 

a robot will face different situations during the course of a mission and must react to perceived events by changing its 

behaviour according to corrective actions. These abrupt changes in the system’s behaviour are relevant of the theory of 

Discrete Events Systems. 

Besides the logical correctness of computations the efficiency and reliability of the system relies on many temporal 

constraints. The performance of control laws strongly depend on the respect of sampling rates and computing latencies. 

Corrective actions must be usually executed within a maximum delay to insure the mission success and the system’s 

security. The optimisation of computing resources is still a relevant problem especially for remote autonomous robots like 

planet rovers[29] or underwater vehicles[31] where both on-board space and energy are severely limited. 

Therefore robotic systems belongs to the class of hybrid reactive and real-time systems in which different features need 

to use different methods and tools to be programmed and controlled. The ORCCAD[5] environment is aimed to provide 

users with a set of coherent structures and tools to develop, validate and encode robotic applications in this framework. 

131

2 The Orccad architecture 

2.1 Basic statements 


The formal definition of a robotic action is a key point in the ORCCAD framework. It is based on the following basic 

statements : 

• In many cases the physical tasks to be achieved by robots can be stated as automatic control problems, which can 

be efficiently solved in real-time by using adequate feedback control loops. Let us mention that the Task-Function 

approach[33] was specifically developed for robotic systems; 

• The characterisation of the physical action is not sufficient for fully defining a robotic action : starting and stopping 

times must be considered, as well as reactions to significant events observed during the task execution; this will be 

further used to design complex missions through actions composition. 

• Since the overall performance of the system relies on the existence of efficient real-time mechanisms at the execution 

level, particular attention must be paid to their specification and their verification. 

From the users and programmers point of view, the specification of a robotic application must be modular, structured 

and accessible to users with different domain of expertize. The end-user concerned with a particular application must be 

provided with high level formalisms allowing to focus on mission specification and verification issues; the control systems 

engineer needs an environment with efficient design, programming and simulation tools to express the control laws which 

then are encapsulated for the end-user. 

2.2 The Orccad approach 

In ORCCAD, two entities are defined in order to capture the aforementioned requirements. The Robot-Task (RT) models 

basic robotic actions where control aspects are predominants. For example, let us cite hybrid position/force control of a 

robot arm, visual servoing of a mobile robot following a wall or constant altitude survey of the sea floor by an underwater 

vehicle. The RT characterises in a structured way closed loop control laws, along with their temporal features related to 

implementation and the management of associated events. These events are : 

• preconditions, which can be associated with measurements and watchdogs 

• events and exceptions of three types : 

– synchronisation signals reports the occurence of a particular state in a RT, they can be used to synchronise 

different RTS; 

– type 1 exceptions are locally processed in the RT, e.g. by tuning a parameter of the control law; 

– type 2 exceptions signal that the RT cannot run to completion and must be switched for a new one, chosen by 

the supervision controller; 

– type 3 exceptions are fatal for the application and must, as far as possible, drive the system in a safe recovery 

state. 

• postconditions are emitted when the RT successfully terminates. 

For the mission designer this set of signals and associated behaviours represents the abstract view of the RT, hiding 

all specification and implementation details of the control laws (Figure 1). The characterisation of the interface of a RT 

with its environment in a clear way, using typed input/output events, allows the composition of them in an easy way 

in order to construct more complex actions, the Robot-Procedures (RPs) : The RP paradigm is used to logically and 

hierarchically compose RTs and RPs in structures of increasing complexity. Usually, basic RPs are designed to fulfil a 

basic goal through several potential solutions, e.g, a mobile robot can follow a wall using predefined motion planning, 

visual servoing, or acoustic servoing according to sensory data availability. RPs design is hierarchical so that common 

structures and programming tools can be used from basic actions up to a full mission specification. 

These well defined structures associated with synchronous composition, thanks to the use of the ESTEREL language 

[4], allows for the systematisation and thus the automatisation of the formal verification on the expected controller behaviour. 

This is also a key to design automatic code generators and partially automated verification. Formal definitions of 

RPs and RTs together with associated available formal verification methods may be found in [24]. 

132


Drivers 

3 Specification of Robot-Tasks 

Control 

Observer Observer 

UnStableCam 

Control 

Suspend 

Timeout 

Resume 

Control law (Discretized time) 

START 

ABORT 

Reactive shell 

T2_UnStableCam 

T3_SENSOR_FAILED 

Good_End 

STARTED 

External view (Discrete events) 

Figure 1: Encapsulation of the control law in a reactive shell 

The design of the robot controller begins with the design and test of basic actions when the necessary actions do not preexist 

in the RT library. Let us now illustrate the design and validation process of a RT through an example of underwater 

robotics taken from [38], where the goal of the KeepStableCam RT consists of the stabilisation of an underwater vehicle 

using visual servoing. 

Modular Specification in Continuous Time In fact, it should be emphasised that the RT designer may select easily the 

adequate models and tuning parameters in ORCCAD, since they belong to some predefined classes in an object-oriented 

description of the control available through the graphical interface depicted by figure 2. The control algorithm is designed 

as a block-diagram, where elementary algorithmic modules are connected through input/output ports, e.g. StableCam 

in Figure 2a. The value of parameters must be set to instantiate the design. It is also necessary to enter the localisation of 

data processing codes (C files). 

The particular Physical-Resource module (VORTEX here) provides a gateway towards the physical system through its 

Driver ports. A complete description of more complex RTs and of sensor-based tasks may be found in [38]. 

Figure 2: a)Functional and temporal attributes of a Module – b) Specification of the reactive behaviour of a RT 

133


Timed-Constrained Specification The resulting specification defines the action from a continuous time point of view, 

i.e independently of time discretization and other implementation related aspects which are considered in a next design 

step. The passage from the above continuous time specification to a description taking into account implementation 

aspects is done by associating temporal properties to modules, i.e. sampling periods, assumed worst case execution time 

(WCET), communications and synchronisations between the processes. 

Modules can be synchronised in several ways : 

• explicitly periodic modules are connected to a system clock through a hidden input port ; 

• an input port can be synchronised on an output port of another module, thus inheriting its period ; 

• it can be synchronised on an external source, e.g. an interrupt coming from a vision processing system. 

In default mode, for basic control purpose, the designer specifies a single-loop, single-rate controller where all the 

algorithmic modules are gathered in a single real-time task for which a single sampling period is defined. 

More complex timing behaviours, e.g. multi-rate control, make use of more or less tight synchronisations between 

modules and clocks. In many cases simple design rules can be used to get a correct (deadlock free) timing diagram 

[37]. For more complex designs the synchronisation and timing diagram can be built interactivelly and a Petri net model 

of the synchronisation skeleton of the RT is automatically extracted from the timed block-diagram. Thus its logical 

correctness and timing analysis (using the provided WCET of modules) can be done using the underlying model in the 

(max,plus) algebra [36]. Finally feedback scheduling can be specified and implemented provided that some additionnal 

instrumentation (for variable clocks generation and accurate online execution time measurement) has been included in the 

real-time platform ([40]). 

Specification of the reactive behaviour The logical behaviour of the RT is automatically encoded in ESTEREL through 

a graphical window (Figure 2c) (here we specify that the UnStableCam signal must be treated as a type 2 exception). 

Thanks to the strong typing of events and exceptions the code generator was proved to be correct and thus guarantees 

that crucial properties like safety and liveness are true [24]. Besides user’s defined signals (pre and post-conditions, 

exceptions), the code generator builds a large ESTEREL file where hidden system signals are also declared. These signals 

will be used at run time to spawn, suspend or resume all the real-time threads necessary for the execution of the RT. 

4 Design and Analysis of Procedures 

After all necessary basic actions have been designed and validated, the user now wants to use them in more complex 

procedures to perform a useful underwater inspection mission [38]. Here is the detailed specification of the KEEPSTABLE 

procedure in order to enlighten the specification and analysis process proposed for basic actions composition. 

4.1 Synchronous programming 

However, even if these tools provide efficient run-time code they remain difficult to be directly used. They require 

expertise from designers and programmers who, as a consequence, spend time in programming tricks rather than being 

concentrated on the specification and validation of actions and applications. Therefore, more friendly CAD systems, built 

over basic tools like C, ESTEREL or VxWorks, must be provided to improve both programmer’s efficiency and programs 

reliability. 

From the verification side, the compositionally principle must preserve the coherence between underlying mathematical 

models, in order to be able to perform formal computations at any level. As an example, the use of the single ESTEREL 

[4] synchronous reactive language as a target for automatic translation is a way of preserving a logical structure whatever 

the complexity of the application. 

A consequence of this point of view is that the basic entities have to be carefully studied and also that composition 

operators should have a proper semantics. 

The formal definition of a robotic action is a key point in the ORCCAD approach. The Robot-Task (RT) models 

basic robotic actions where control aspects are predominants, like the hybrid position/force control of a robot arm or 

the visual servoing of a mobile robot. The characterisation of the interface of a RT with its environment through typed 

input/output events allows to compose them easily in order to construct more complex actions, the so called Robotprocedures 

(RP), while hiding most implementation details. In its simplest expression, a RP coincides with a RT, while 

the most complex one might represent an overall mission. Briefly speaking, it specifies in a structured way a logical 

134


and temporal arrangement of RTs in order to achieve an objective in a context-dependent and reliable way, providing 

predefined corrective actions in the case of unsuccessful execution of RTs. 

These formally defined structures[26] associated with synchronous composition, thanks to the use of the ESTEREL 

language, allows to systematise and therefore to automatise formal verification about the expected controller behaviour. 

In complement of two other features of ORCCAD i.e. the object-oriented model and the possibility of automatic code 

generation, this capability of verification is a key point for meeting the requirements of safety in the programming of 

critical applications. 

4.2 Procedure specification 

do 

SEQ(do 

KeepStableUS 

until Stabilized 

; 

loop 

PAR(when T2_Stabilized when T2_UnsStableCam 

do 

do 

KeepStableCam KeepStableUS 

until UnStableCam until Stabilized) 

end loop 

) 

until Stop 

Figure 3: Specification of a Procedure using : a) the GUI – b) the MaestRo language 

The KEEPSTABLE procedure aims at stabilising the underwater vehicle in spite of perturbations. The vehicle can be 

stabilised in two ways : it can be remotely locked on its target using either visual servoing or acoustic sensors. Here 

visual servoing (running the KeepStableCam RT) is considered as the nominal mode. However, if the camera loses the 

target, the controller must switch to sounders stabilisation (degraded mode) running the KeepStableUS RT until being 

able to recover the vision tracking mode. This redundancy is useful to increase the safety and efficiency of the system and 

such a situation where several RTs are exceptions of each other is a typical structure in our procedures. Once again, the 

ESTEREL language is used to specify that actions are run in sequence or in parallel, or must preempt each other. Thanks 

to the structure of ORCCAD programs, the specification of this procedure can be written in two ways which both avoid 

the end-user to write himself the full source ESTEREL file : 

• The Robot-Procedure Editor displays the external view of selected RTs and RPs. The user just has to add some 

statements to express, e.g., sequencing (;), parallelism (||), or escape mechanisms (trap-exit) to complete the specification 

(these additional statements are highlighted in Figure 3a). As the designer only access the external views, 

he cannot jeopardise the properties of the previously defined actions. 

135


• The MAESTRO language [10] has been developed to target ESTEREL (Figure 3b). This language has been designed 

to be more “natural” for robotic practitioners. At compile time it expands in ESTEREL statements and also performs 

some preliminary verifications like liveness. 

In this example the alternance between the two RTs is specified inside a parallel statement (PAR), in which each RT 

is guarded by a T2 exception emitted by the other RT. As these exceptions are mutually exclusive the two RTs cannot run 

simultaneously : anyway this property will be formally verified in the next section. 

At compile time the control code of this procedure is translated into an automaton which output functions are automatically 

filled with calls to the underlying RTOS, thus alleviating the burden of the programmer while preserving formal 

verification capabilities. 

Robotic applications are built incrementally by adding new RTs and RPs which behaviour, e.g. synchronisation, are 

encoded in the same way. The next example describes a RP used to synchronise the motions of the underwater vehicle 

and of its associated arm. 

MovePA10 

4.3 Logical Behaviour Verification 

Prr_Start_MoveArm 

MoveArm 

Inspect 

T2_Unstable 

T1_Centered 

KeepStableUS 

VKeepStable 

KeepStableCam 

T2_Stabilized 

Prr_Start 

Stop 

Prr_Start_VKeepStable 

Figure 4: Structure of a RP synchronising the arm and the vehicle 

First, the satisfaction of crucial properties can be checked. Concerning the safety property (any fatal exception must 

always be correctly handled) the process is as follows : knowing the user’s specification defining the fatal exceptions 

and the associated processing, a criterion is automatically built to define an abstract action. The abstraction of the global 

procedure automaton with respect to this criterion is then computed. The absence of the “Error” action in the resulting 

automaton proves that the safety property is verified. 

The liveness property (the RP always reaches its goal in a nominal execution) is proved in a similar way. The “Success” 

signal is emitted at the end of all successful achievements of a RP. The abstraction of the procedure automaton crossed 

with an adequate criterion built with this signal must be equivalent by bi-simulation to a one state automaton with a single 

action, the “Success” one. 

Conflicts detection : We are interested here in checking that during the RP evolution, there does not exist instants 

where two different RTs are competing for using a same resource of the system. Here, the physical resource controlled 

by the RTs (the underwater vehicle) is considered as well as the software resources used by the controllers (real-time 

tasks). For example, one wants to verify that the RTs KEEPSTABLECAMERA and KEEPSTABLEUS never compete to 

apply different desired force inputs to the vehicle thrusters during all the RP evolution. The global automaton is reduced 

to the only interesting signals Activate... and CmdStopOK.... Thus by clicking on the conflicts button one can 

check that these two signals alternate during the RP life insuring that a control law can be started only after confirmation 

that the previous one is stopped and that the transition is as fast as possible to ensure the system’s stability (Figure 5). 

Finally, the conformity of the RP behaviour with respect to the requirements is verified. For example, we want to 

certify that the vision-servoing and acoustic-servoing RTs can alternate for an arbitrary number of time during the life of 

the stabilisation procedure. This property can be checked by observing the abstract view given by the ORCCAD graphical 

interface (figure 6) : after minimisation and abstraction through behavioural bi-simulation ([6], the original automaton 

136


Figure 5: Checking for conflicts a) using explicit automata b) using observers 

(which has 17 states and 168 transitions) becomes small enough to be visually analysed. As expected, the procedure 

begins with the KeepStableUS RT (arc 1) : then, the two RTs altern in a loop, following arcs 2 and 3. The occurrence 

of the Stop signal is the only way to exit the procedure (arcs 4 and 5). The user just have to click on the name of signals 

which are relevant for the property to be checked to launch the verification process. 

5 Implementation 

5.1 Switching mechanism 

Raising a type 2 exception or a ”well-finished” signal request the embedding RP to smoothly stop the running RT and 

starting the next one, according to its own recovery program. Switching between two RTs must insure that : 

• The control laws are not conflicting, i.e. the degrees of freedom of the system are all controlled, and only once. 

• The boundary conditions of the successive control laws must be compliant, in some cases it would be necessary to 

insert a special purpose transition RT to gain a full control of the transition process [34]; 

• The configuration of the set of real-time tasks is valid before starting the new control law. 

• The switching time must be small w.r.t. the plant’s time constants. Ideally, the delay during which the system is not 

controlled should be in the range of one sampling period. 

The steps of the switching mechanism have been identified as follow : 

• Upon reception of a type 2 exception or postcondition from the running RT, choice of the next one to start, starting 

of the transition phase; 

• Initialisation of the new real-time tasks and instantiation of the communication ports. According to the load of the 

processor, it may be necessary to decrease the sampling period of the running RT (degraded mode allowing to keep 

the system under control); 

• After fulfilment of the preconditions of the second RT, stopping the first control law and starting the second one. 

This delay must be minimised to fit in one sampling period; 

137


Figure 6: An abstract view of KeepStable 

• Suspension or destruction of the former real-time tasks 

In practice it appears that such a complex mechanism is very difficult to set up and port on different targets. Indeed, 

according to the properties of the used control laws and plant, it is always not necessary to use the fully-fledged smooth 

transition protocol ; in particular a simpler transition procedure has been implemented and succesfully experimented in 

the framework of vision based tasks ([2]). 

5.2 Design and code generation toolset 

Figure 7 pictures the compilation process and integrated tools. The ORCCAD structures are instantiated as C++ classes 

(or C structures) using virtual system calls, provided by the kernel. For a single processor implementation, all ESTEREL 

files corresponding to the RTs and RPs logical behaviour are gathered (i.e. put in parallel) in a single file which can be 

further compiled into various formats. The SC format (sorted boolean equations) is post-processed in C and encapsulated 

in a high priority real-time thread. 

The application is finally compiled and linked with run-time libraries to make the down-loadable code. Currently 

ORCCAD targets VxWorks and RTAI as hard real-time systems and Solaris and Linux as soft real-time systems (using 

Posix threads). Note that building a real-time simulator running on the same target can be easily done using the same 

code generation toolset : this is simply done by calling a numerical integrator (itself calling a model of the robotic 

system) in the drivers of the Physical Ressource [39]. However running the full simulation in real-time requires using an 

oversized processor to get enough computing power. Various dedicated run-time interfaces are also provided to monitor 

the execution of the controller. 

138


Code generation 

Control tasks specification Procedure specification 

Real−time analysis 

Petri nets 

(max,plus) 

C/C++ code generator 

virtual OrcObjects 

C/C++ files 

Compilation with 

run−time libraries 

Binaries 

Graphical Interfaces 

Modules RTs RPs 

C files Esterel files 

Control laws 

RT behaviours 

Mission specification 

VxWorks RTAI/Linux Linux/Posix 

Solaris 

Monitoring 

Parameterization 

Exploitation 

Automaton (SCC) 

XES simulation 

source code animation 

Esterel compiler 

Figure 7: Code generation and associated tools 

139 

Diagnosis 

Properties 

Observers 

Robot modeling (ODE) 

Numerical Integrator 

tuning 

SC format 

Simulator

5.3 Real-time structures 

At compile time, the ESTEREL source file is translated into an automaton encoded in C. Input and output functions are associated 

to allow the automaton to receive and emit signals. These functions are used to interface the synchronous reactive 

program with the asynchronous execution environment, i.e. the operating system. As the compiler knows nothing about 

the environment, the output functions are empty and must be filled by the user to make the program effective. Moreover, 

as ESTEREL is unable to do numerical computations, all calculations related to the execution of control algorithms are 

called as external procedures. Thus it is necessary to design an execution machine [1], the general structure of which is 

given by Figure 8a. Signals are collected to build the current event which is given to the automaton. Output actions calling 

extern calculation procedures must be carefully interfaced with the RTOS. Writing by hand this execution machine would 

be tricky and error prone. 

Input 

Processing 

Event 

Generator 

Current 

Input Signals 

AUTOMATON 

Synchronous 

Actions 

Output 

Processing 

Reactive Machine 

Information Storage 

Execution 

Manager 

Asynchronous 

Machine 

Asynchronous 

Actions 

Robot_Procedure 

Clocks 

Generation 

Observers 

Parameters 

TM 

obs1 

Robot_Task 1 

Parameters 

TM1 

Robot_Task 2 

Parameters 

TM2 

Controller 

. 

. 

. 

TM 

obs2 

Controller 

TM 

obs4 

Controller 

TM3 

Parameters 

TM 

obs3 

Logical signals 

Control signals 

Sémaphore 

Controller 

FIFO 

Manager 

Outputs 

Automaton 

Inputs 

Output 

Asynchronous Interface 

Synchronous 

Figure 8: a) Structure and b) Implementation of the execution machine 

Thanks to the ORCCAD structures this machine can be automatically generated by the system (Figure 8b). A main 

“system” task sets up the whole system and in particular generates the needed clocks used to trigger the periodic calculation 

modules. Real-time threads are made periodic by blocking their first input port on a semaphore which is released by 

clock ticks. 

The automaton is the highest priority task : it is awakened by the occurrence of input signals related to pre-conditions, 

exceptions, and post-conditions. In reaction, it tells the RTOS what modules must be spawned, resumed or suspended. 

Although this automaton is crucial for a safe and successful behaviour of the application, it spends most of time waiting 

for input events during the periodic execution of control algorithms managed by the RTOS. Typically, a transition of the 

automaton takes a few microseconds while the duration of robotic actions may range from seconds (e.g. manipulation 

tasks for a robot arm) to hours (e.g. mapping mission for an autonomous underwater vehicle). 

6 Related work 


Many robotics controllers software inspired from Component-Based Software engineering have been developped (Claraty 

[30], Cosarc [32], Oscar [22], Orca [7], Orocos [8], HRPOpen [23]). All these approches are done by research teams, often 

dedicated to a single robot type (mobile robot, humanoid robot or robotic arm) and are not adopted by a big community. 

To tackle the control robotics software complexity, it is mandatory to pool resources and efforts. However although 

ORCCAD has been primarily developed and used for robot control purpose it belongs to a more general family of model 

driven design methods and tools for computer controlled systems [11] [15]. 

140


Some other layered approaches in robot control show architectural similarities with our. In the fields of synchronous 

programming applied to robotics let us cite [28] where data and control flows are gathered using the SIGNAL synchronous 

data-flow language. Using the same formalism for numerical calculations and tasking management allows for checking 

the temporal coherency of data in the whole application. However, if SIGNAL is well suited to specify signal processing 

algorithms, long computations like computing the explicit dynamics of a robot arm should be done by external functions 

written in a host language like C. 

ControlShell (now Constellation) [35] proposes an architecture quite similar to ORCCAD. At the level of control 

actions it allows for the construction of models of components such as PIDs or trajectory generators which can be gathered 

through a block-diagram oriented GUI. Event-driven aspects are handled by hand-made (and thus quite simple) Finite 

State Machines for which formal verification methods are not provided. 

Besides this commercial offer, the OROCOS project’s aim is to build open source software for robot control, from 

the lowest, real-time servo control, over intelligent sensor processing, to high-level human-machine interfacing. The 

emphasis is on building components, not on designing architectures [8]. However the proposed framework, ranging from 

control design to real-time code generation, also enforces the separation of data flow (periodic control laws computation) 

and execution flow controlled via Finite State Machines. 

7 Summary and perspectives 

In this paper we have described the ORCCAD approach to formalize control structures in controllers for robotics and 

others embedded systems. In this approach, the Robot-Task, where a discretized control law is encapsulated in a logical 

behavior, is a hybrid structure at the frontier between continuous and discrete time aspects. The formalization of these 

structures allows for the formal verification of programs and automatic down-loadable code generation. 

In such control systems, the interleaving of events and activities in a real life mission accounts for our hierarchical 

design and verification process, where complex actions are designed from already validated basic blocks lying at a lower 

level. The ESTEREL synchronous language was found to be effective to specify and encode the coordination of actions, 

from the low level logical management of real-time tasks up to the application layer. To further ease the specification 

process, ORCCAD provides friendly user interfaces: 

• Starting from the specifications given through the ORCCAD GUI, the user is provided with control oriented predefined 

structures. Automatic code generation allows him to take advantage of real-time tools and synchronous 

languages with a moderate programming effort. These structures are also a key for a partial automatization of the 

verification process. 

• The ESTEREL compiler does not provide the interface functions with the environment. To avoid messy and error 

prone low level interfacing work, ORCCAD automatically generates the execution machine managing both the 

synchronous automaton and the asynchronous real-time threads. Thus the user can concentrate on application 

specification and validation rather than low level programming tricks. 

• However, compiling reactive programs into explicit automata is subject to size explosion, and behavioral verification 

through visual inspection of automata becomes impossible for industrial size problems, even after reduction and 

bisimulation. An ongoing work consists of the identification of classes of relevant properties to be encoded in 

generic observers : after parameterisation these properties can be checked by the compiler itself (e.g. figure 5b). 

A dual approach consists in using a discrete events controller synthesis algorithm to build a safe-by-construct 

controller from the desirable properties, e.g. from a fault tolerance specification. 

ORCCAD has been used in laboratory applications such as programming the BIP 2000 biped control laws [3], real-time 

simulation of a teleoperation platform [39], high level programming of an underwater robotic system [25] and feedback 

scheduling experiments [40]. 

The Orccad concepts and tools have been selected to support the development of a set of ESA projects. In particular, 

in the MUROCO (Multiple Robot Controller [18]) project the Orccad structuring of Events, Actions and Tasks, as well as 

the utilisation of Esterel as a mission specification language are used in a dedicated tool developed by TRASYS Space. Up 

to 63 actions are composed in twelve tasks to specify the full ExoMars mission ranging from ’deployment’ to ’travelling’ 

and ’experiment cycle’ activities. In the VIMANCO on-going project [19], TRASYS in cooperation with INRIA and 

KUL aims at improving the autonomy, safety and robustness of space robotics system using vision. The developments 

include the implementation of a Vision Software Library allowing Vision Control for space robots, for which the Orccad 

controller is foreseen for the real time execution of the vision based tasks. 

141

From a software engineering perspective the Orccad approach allows for the design of robot software controllers using 

existing theory (Control and Discrete Events theories) and software tools based on existing technologies already used for 

the embedded and real-time domains (RTOS, Object Oriented languages, Synchronous languages,. . . ). Starting from 

existing paradigms, our goal is to provide an effective software framework and associated tools well suited for robotic 

applications and more generally for control and real-time co-design. 

We think that the current ORCCADapproach is still valid but that the software tools must be upgraded and constantly 

updated. The current release has not been re-engineered for eight years, although many partial improvements (e.g. realtime 

multitasking) have been developed and tested but not cleanly integrated. 

Orccad tools must evolve according to the improvements of software engineering such as Model Driven Architecure 

MDA (e.g. [15] for computer-based control) or Synchronous language [12], [13], [9]). However this necessary evolution 

can still be based on existing design and control architectures dedicated to the application field. 

In the middleware domain, using modern software enginering now lead to the emergence of a large community willing 

to adopt standards (e.g. see the success of the ObjectWeb consortium [21]) : using such tools have increased drastically 

software productivity. Among other initiatives the recently created Object Management Group (OMG [16]) robotics 

corner aims at the elaboration of OMG standards (UML, Corba are OMG standards for example) to ease the integration 

of robotic systems using modular components. 

The work around robotics standardisation must be done in connection with the embedded and real-time community. 

In particular this community is involved in several collaborative projects to adapt UML and/or MDA standards taking into 

account performance and real-time constraints (e.g. [27], [20], [17], [14]). Designing a common architecture based on 

such standards adopted by a large community could be now the cornerstone for efficiently sharing robot control software 

development and practice. 

References 


[1] C. André, A. Ressouche, and J.M. Tanzi. Combining special purpose and general purpose languages in real-time 

programming. In IEEE Workshop on Programming Languages for Real-Time Industrial Application, Madrid, 1998. 

[2] S. Arias. Formalisation et intégration en vision par ordinateur temps réel. PhD thesis, Université de Nice Sophia 

Antipolis, 1999. 

[3] C. Azevedo, N. Andreff, and S. Arias. BIPedal walking:from gait design to experimental analysis. Mechatronics, 

14/6:639–665, 2004. 

[4] G. Berry. The esterel v5 language primer. Technical report, http://www-sop.inria.fr/esterel.org/, 2000. 

[5] J.J. Borrelly, E. Coste-Manière, B. Espiau, K. Kapellos, R. Pissard-Gibollet, D. Simon, and N. Turro. The ORCCAD 

architecture. Int. Journal of Robotics Research, 17(4):338–359, april 1998. 

[6] A. Bouali and R. de Simone. Symbolic bisimulation minimisation. In Computer Aided Verification, number 663 in 

Lecture Notes in Computer Science. Springer, 1993. 

[7] A. Brooks, T. Kaupp, A. Makarenko, S. Williams, and A. Oreback. Towards component-based robotics. In Intelligent 

Robots and Systems IROS, pages 163–168, august 2005. http://orca-robotics.sourceforge.net/. 

[8] H. Bruyninckx. Open robot control software: the OROCOS project. In IEEE International Conference on Robotics 

and Automation ICRA, Seoul, may 2001. http://orocos.org/. 

[9] J-L Colaço, B. Pagano, and M. Pouzet. A conservative extension of synchronous data-flow with state machines. In 

ACM International Conference on Embedded Software (EMSOFT’05), Jersey city, New Jersey, september 2005. 

[10] E. Coste-Manière and N. Turro. The MAESTRO language and its environment: Specification, validation and control 

of robotic missions. In 10th IEEE/RSJ International Conference on Intelligent Robots and Systems, Grenoble, 1997. 

[11] J. El-khoury, D. Chen, and M. Törngren. A survey of modelling approaches for embedded computer control systems 

(version 2.0). Technical Report TRITA - MMK 2003:36,ISSN 1400 -1179, ISRN KTH/MMK/R-03/11-SE, Royal 

Institute of Technology, KTH, Stockholm, Sweden, 2003. 

142


[12] D. Garlan. Software architecture: a roadmap. In Conference on the future of Software engineering, pages 91–101, 

Limerick, Ireland, june 2000. 

[13] D. Garlan and D. Perry. Software architecture: practice, potential, and pitfalls. In 16th International Conference on 

Software Engineering, 1994. 

[14] S. Gérard, N. Voros, C. Koulamas, and F. Terrier. Efficient system modeling for complex real-time industrial networks 

using the ACCORD/UML methodology. In International Workshop on Distributed and Parallel Embedded 

Systems DIPES, october 2000. 

[15] D. Henriksson, O. Redell, J. El-Khoury, M. Törngren, and K-E. ˚Arzén. Tools for real-time control systems co-design 

— a survey. Technical Report ISRN LUTFD2/TFRT--7612--SE, Department of Automatic Control, Lund Institute 

of Technology, Sweden, April 2005. 

[16] http://robotics.omg.org/. 

[17] http://www.carroll-research.org. 

[18] http://www.esa.int/esaMI/Aurora/SEMQA7A5QCE 0.html. 

[19] http://www.irisa.fr/lagadic/actions-internationales-fra.html. 

[20] http://www.ist-compare.org/. 

[21] http://www.objectweb.org/. 

[22] http://www.robotics.utexas.edu/rrg/research/oscarv.2/. 

[23] F. Kanehiro, H. Hirukawa, and S. Kajita. OpenHRP: Open architecture humanoid robotics platform. International 

Journal of Robotics Research, 23(2):155–165, 2004. 

[24] K. Kapellos. Environnement de programmation des applications robotiques réactives. PhD thesis, Ecole des Mines 

de Paris, Sophia Antipolis, 1994. 

[25] K. Kapellos, D. Simon, S. Granier, and V. Rigaud. Distributed control of a free-floating underwater manipulation 

system. In 5th Int. Symp. on Experimental Robotics, Barcelon, 1997. 

[26] K. Kapellos, D. Simon, M. Jourdan, and B. Espiau. Task level specification and formal verification of robotics 

control systems: state of the art and case study. Int. Journal of Systems Science, 30(11):1227–1245, 1999. 

[27] F. Loiret and D. Servat. Insights on real time systems architecture modelling for a software engineering viewpoint. 

In 17th Euromicro Conference on real-time systems ECRTS05, Palma de Mallorca, june 2005. work in progress 

session. 

[28] Marchand, E., E. Rutten, H. Marchand, and F. Chaumette. Specifying and verifying active vision-based robotic 

systems with the SIGNAL environment. Int. Journal of Robotics Research, 17(4):418–432, 1998. 

[29] L. Matthies, E. Gat, R. Harrison, B. Wilcox, R. Volpe, and T. Litwin. Mars microrover navigation: Performance 

evaluation and enhancement. Autonomous Robots, 2(4):291–311, 1995. 

[30] A. Nesnas, R. Simmons, D. Gaines, C. Kunz, A. Diaz-Calderon, T. Estlin, R. Madison, J. Guineau, M. McHenry, 

I. Shu, , and D. Apfelbaum. CLARAty: Challenges and steps toward reusable robotic software. submitted to 

International Journal of Advanced Robotic Systems, 2006. http://keuka.jpl.nasa.gov/main/. 

[31] A. Pascoal. The AUV MARIUS: Mission scenarios, vehicle design, construction and testing. In 2nd IARP workshop 

on Underwater Robotics, Monterey, CA, may 1994. 

[32] R. Passama and D. Andreu. COSARC : Component based software architecture of robot controllers. In 1st National 

Workshop on Control Architecture of Robots: software approaches and issues, Montpellier, 2006. 

[33] C. Samson, M. Le Borgne, and B. Espiau. Robot Control: the Task-Function Approach. Oxford Science Publications. 

Clarendon Press, 1991. 

143


[34] A. Santos, B. Espiau, P. Rives, D. Simon, and V. Rigaud. Sensor-based control of holonomic autonomous underwater 

vehicles. Technical Report 2609, INRIA Research Report, july 1995. 

[35] S. Schneider, V. Chen, G. Pardo-Castellote, and H. Wang. Controlshell: A software architecture for complex electromechanical 

systems. Int. Journal of Robotics Research, 17(4):360–380, 1998. 

[36] D. Simon and F. Benattar. Design of real-time periodic control systems through synchronisation and fixed priorities. 

Int. Journal of Systems Science, 36(2):57–76, 2005. 

[37] D. Simon, E. Castillo, and P. Freedman. Design and analysis of synchronization for real-time closed-loop control in 

robotics. IEEE Trans. on Control Systems Technology, 6(4):445–461, july 1998. 

[38] D. Simon, K. Kapellos, and B. Espiau. Control laws, tasks and procedures with ORCCAD: Application to the control 

of an underwater arm. Int. Journal of Systems Science, 17(10):1081–1098, 1998. 

[39] D. Simon, M. Personnaz, and R. Horaud. Teledimos telepresence simulation platform for civil work machines : 

real-time simulation and 3D vision reconstruction. In IARP Workshop on Advances in Robotics for Mining and 

Underground Applications, Brisbane, Australia, october 2000. 

[40] D. Simon, D. Robert, and O. Sename. Robust control/scheduling co-design: application to robot control. In RTAS’05 

IEEE Real-Time and Embedded Technology and Applications Symposium, pages 118–127, San Francisco, March 

2005. 

144


Overview of a new Robot Controller 

Development Methodology 

R. Passama 1,2 , D. Andreu 1 , C. Dony 2 , T. Libourel 2 

1 Robotics Department 

2 Computer sciences Department 

LIRMM, 161 rue Ada 34392 Montpellier, France 

E-mail : {passama, andreu, dony, libourel}@lirmm.fr 

Abstract - The paper presents a methodology for the development of robot software controllers, based on actual 

software component approaches and robot control architectures. This methodology defines a process that 

guides developers from the analysis of a robot controller to its execution. A proposed control architecture 

pattern and a dedicated component-based language, focusing on modularity, reusability, scalability and 

upgradeability of controller architectures parts during design and implementation steps, are presented. Finally, 

language implementation issues are shown. 

Keywords: Software Components, Control Architecture, Integration, Reuse, Object Petri Nets. 

I. INTRODUCTION 

Robots are complex systems whose complexity is continuously increasing as more and more 

intelligence (decisional and operational autonomies, human-machine interaction, robots cooperation, 

etc.) is embedded into their controllers. This complexity also depends, of course, on the mechanical 

portion of the robot that the controller has to deal with, ranging from simple vehicles to complex 

humanoid robots. Robot controllers development platforms and their underlying methodologies are of 

great importance for laboratories and IT societies, because there is an increasing interest in future 

service robotics. Such platforms help developers in many of their activities (modelling, programming, 

model analysis, test and simulation) and should take into account preoccupations like the reuse of 

software pieces and the modularity of control architectures as they correspond to two major issues. 

The goal of our team is to provide a robot controller development methodology and its dedicated 

tools, in order to help developers overcoming problems during all steps of the design process. So, we 

investigate on the creation of a software paradigm that specifically deals with controller development 

preoccupations. From the study of robot control architectures presented in the literature, we identified 

four main different practices in control architecture design approaches that must be considered. 

The first practice is the structuring of the control activities. There are different approaches. One 

approach consists in decomposing the control architecture into hierarchical layers, like in LAAS 

architecture [ALA, 98], 4D/RDC [ALB, 02], ORCCAD [BOR, 98] and some others. Each layer within 

the robot controller has a “decision-making system”, as each layer only ensures part of the control 

(from low level control to planning). Such a decomposition impacts on the reactivity of the robot 

controller. The lower the layer is, the higher is the time constraint of its execution. The upper the 

layer is, the higher is the priority of its reaction. This hierarchical approach has been extended to 

hybrid architectures. For instance, AURA [ARK, 97] proposes to mix it with a behavioural approach 

in order to improve reactivity. In doing so, the interaction scheme is not limited to interactions 

between adjacent layers (for reactivity purposes): some data can be simultaneously available to 

several layers, or an event, can be directly notified to the upper layers (without passing through 

intermediary ones), etc. In behavioural approaches, like the subsumption architecture [BRO, 86] or 

145


similar ones (AURA for example), interactions between basic behaviours are complex, even if those 

interactions are not explicit and that they are taken into account by means of an “external” entity (for 

instance, the entity that computes the weighting of commands generated by individual low level 

behaviours). 

The second practice is the decomposition of the control architecture into sub-systems that 

incorporate the control of specific parts of a robotic system. This practice is reified in IDEA agents 

architectures [MUS, 02] and Chimera development methodology [STE, 96]. This organizational view is 

orthogonal to the hierarchical one: each sub-system can incorporate both reactive and ‘long term’ 

decision-making activities and so can be ”layered” itself. 

The third practice is to separate, in the architecture description, the “robot operative portion” 

description from the “control and decision-making” one. This practice is often adopted at 

implementation phase, except in specific architectures like CLARATY [VOL,01], in which the “real 

world” description is made by means of objects hierarchies. These two portions of a robot, its 

mechanical portion (including its sensors and actuators) and its control one, are intrinsically 

interdependent. Nevertheless, for reasons of reusability and upgradeability, the controller design 

should separate, as far as possible, two aspects: the functionalities that are expected from the robot on 

the one hand, and, on the other, both the representation of the mechanical part that implements them 

and that of the environment with which it interacts. One current limitation in the development of 

robot software controllers is the difficulty of integrating different functionalities, potentially 

originating from different teams (laboratories), into a same controller, as they are often closely 

designed and developed for a given robot (i.e. for a given mechanical part). Hence, upgradeability and 

reusability are aims that are currently almost impossible to achieve since both aspects of the robot 

(control and mechanical descriptions) are tightly merged. The reuse of decision-making/control 

systems parts is also a big challenge, because of the different approaches (behavioural or hierarchical) 

that can be used to design it. 

Finally, the fourth practice is to use notations to describe the controller’s parts and to formalize 

their interactions. Model-based specifications are coupled with formal analysis techniques in order to 

follow a “quality-oriented” design process. The verification of properties like invariants or the 

research of “dead-lock free” interactions are examples of benefits of such a process. 

A robotic development methodology and its platform should propose a way to develop a control 

architecture using all these practices, as they correspond to complementary preoccupations. We 

identified five different preoccupations: description of the real world, description of the control (in the 

following this term will include decision-making, action, perception, etc.), description of interactions, 

description of the layers of the hierarchy, description of subsystems. The software component 

paradigm [SZY,99] helps dealing with these preoccupations in many ways (separation of protocols 

description from computation description, deployment management, etc.). Component based 

approaches propose techniques to support easy reuse and integration and they sometimes rely on 

formal languages to describe complex behaviour and interactions (aiming at improving quality of the 

design), like architecture description languages [MED, 97] for example. 

In the following sections, we present the CoSARC (Component-based Software Architecture of 

Robot Controllers) development methodology, based on actual component models. It defines a 

process that guides developers during analysis, design, implementation and deployment phases. It is 

based on two concepts: a control architecture pattern for analysis, presented in section 2, and a 

component-based language, presented in section 3. It integrates robot controller preoccupation 

management and takes into account actual practices by promoting the use of Objects Petri Nets. The 

146


component execution and deployment model is shown in section 4. This paper concludes by citing 

actual work on, and perspectives of, the CoSARC methodology. 

II. CONTROL ARCHITECTURE PATTERN 

The CoSARC methodology provides a generic view on robot control architecture design by means 

of an architecture pattern. The proposed pattern is adaptable to a large set of hybrid architectures. It 

provides a conceptual framework to the developers, useful for controller analysis. The analysis phase 

is an important stage because it allows outlining of all the entities involved in the actions/reactions of 

the controller (i.e. the robot behaviour) and the interactions between them. It is made by following 

concepts and organization described in the pattern. It takes into account robot controller description 

depending on robot’s physical portion (operative portion), to make the analysis more intuitive. The 

pattern also deals with design subjects, by defining the properties of layers of the hierarchy and the 

matching between layers and entities. 

The central abstraction in the architecture pattern is the Resource. A resource is a part of the robot’s 

intelligence that is responsible for the control of a given set of independently controllable physical 

elements. For instance, consider a mobile manipulator robot consisting of a mechanical arm 

(manipulator) and a vehicle. It is possible to abstract at least two resources: the ManipulatorResource 

which controls the mechanical arm and the MobileResource which controls the vehicle. Depending on 

developer’s choices or needs, a third resource can also be considered, coupling all the different 

physical elements of the robot, the Mobile-ManipulatorResource. This resource is thus in charge of the 

control of all the degrees of freedom of the vehicle and the mechanical arm (the robot is thus 

considered as a whole). The breaking down of the robot’s intelligence into resources mainly depends 

on three factors: the robot’s physical elements, the functionalities that the robot must provide and the 

means developers have to implement those functionalities with this operative part. 

A resource (cf. Fig. 1) corresponds to a sub-architecture decomposed into a set of hierarchically 

organised interacting entities. Presented from bottom to top, they are: 

• A set of Commands. A command is in charge of the periodical generation of command data to 

actuators, according to given higher-level instructions (often setup points) and sensor data. 

Commands encapsulate control laws. The actuators which are concerned belong to the set of 

physical elements controlled by this resource. An example of a command of the 

ManipulatorResource is the JointSpacePositionCommand (based on a joint space-position control law 

that is not sensible to singularities, i.e. singular positions linked to the lining up of some axis of 

the arm). 

• A set of Perceptions. A perception is responsible for the periodical transformation of sensor data 

into, potentially, more abstract data. An example of a perception of the ManipulatorResource is the 

ArmConfigurationPerception that generates the data representing the configuration of the mechanical 

arm in the task space from joint space data (by means of the direct geometrical model of the arm). 

• A set of Event Generators. An event generator ensures the detection of predefined events 

(exteroceptive or proprioceptive phenomena) and their notification to higher-level entities. An 

example of an event generator of the ManipulatorResource is the SingularityGenerator; it is able to 

detect, for instance, the singularity vicinity (by means of a ‘singularity model’, i.e. a set of 

equations describing the singular configurations). 

• A set of Actions. An action represents an (atomic) activity that the resource can carry out. An 

action is in charge of commutations and reconfigurations of commands. An example of action of 

147


the ManipulatorResource is the ManipulatorContactSearchAction, which uses a set of commands to 

which belongs the ManipulatorImpedanceCommand. This command is based on an impedance 

control law (allowing a spring-damper like behaviour). In a more “behavioural oriented” design 

an action could activate and deactivate sets of commands and manage the summing and the 

weighting of the command data they send to I/O controllers. 

Robot Controller Reaction priority 

Mission 1..1 

Manager 1..1 

Global Supervisor 

1..* 

Resource 

1..1 

high 

Resource Supervisor 

1..* 

Mode 

1..* 

Action 

1..* 

* 

Command Perception 

1..* 

Event 

Generator 

1..* 1..* 

Input/Output Controller 

* 

Event 

Generator 

medium 

Time constraints 

Figure 1: Control architecture pattern (UML-like syntax), and properties of the layers. 

• A set of Modes. Each Mode describes the behaviour of a resource and defines the set of orders 

the resource is able to perform in the given mode. For example, the MobileResource has two 

modes: the MobileTeleoperationMode using which the human operator can directly control the 

vehicle (low-level teleoperation, for which obstacle avoidance is ensured), and the 

MobileAutonomousMode in which the resource is able to accomplish high-level orders (e.g., ‘go to 

position’). A mode is responsible for the breaking down of orders into a sequence of actions, as 

well as the scheduling and synchronization of these actions. 

• A Resource Supervisor is the entity in charge of the modes commutation strategy, which depends 

on the current context of execution, the context being defined by the corresponding operative 

portion state, the environment state and the orders to be performed. A robot control architecture 

consists of a set of resources (Fig. 1). The Global Supervisor of a robot controller is responsible 

for the management of resources according to orders sent by the operator, and events and data 

respectively produced by event generators and perceptions. Event generators and perceptions not 

belonging to a resource thus refer to physical elements not contained in any resource. In the given 

example, we use such resource-independent event generators to notify, for instance, ‘low battery 

level’ and ‘loss of WiFi connection’ events to some resources as well as to the global supervisor. 

The lowest level of the hierarchical decomposition of a robot controller is composed of a set of 

Input/Output controllers. These I/O controllers are in charge of periodical sensor- and actuatordata 

updating. Commands, event generators, and perceptions interact with I/O controllers in 

order to obtain sensor data, and commands use them to set actuator values. Other upper layer 

entities, like actions for instance, can directly interact with I/O controllers to configure their 

activities (if necessary). 

148 

low 

low 

medium 

high 

Reactivity 

loop 

Control 

relationship


Organization inside resources and robot controller follow a hierarchical approach. Each layer 

represents a ”level of control and decision” in the controller activities. The upper layer incorporates 

entities embedding complex decision-making mechanisms like modes, supervisors and mission 

managers. The intermediate layer incorporates entities like control schemas (commands), observers 

modules (event generators, perceptions) and reflex adaptation activities (inside actions). The lowest 

layer (I/O controllers) interfaces upper layers with sensor, actuators and external communication 

peripherals, and helps standardizing data exchanges. The semantic of layers hierarchy is based on the 

“control” relationship: a given layer controls the activities of lower layers. Two design properties 

emerge from this hierarchical organization. The first one is that upper layers must have a higher 

priority of reaction than lower layers, because their decision is more important for the system at a 

global scope. The second one is that lower layers have greater temporal constraints to respect, 

because they contain reflex and periodic activities. Managing these properties together is very 

important for the “real-time” aspect of the control architecture and has to be considered in our 

proposition. 

A. General concepts 

III. COMPONENT-BASED LANGUAGE 

The CoSARC language is devoted to the design and implementation of robot controller 

architectures. This language draws from existing software component technologies such as Fractal 

[BRU, 02] or CCM [OMG, 01] and Architecture Description Languages such as Meta-H [BIN, 96] or 

ArchJava [ALD, 03]. It proposes a set of structures to describe the architecture in terms of a 

composition of cooperating software components. A software component is a reusable entity subject 

to “late composition”: the assembly of components is not defined at ‘component development time’ 

but at ‘architecture description time’. 

The main features of components in the CoSARC language are internal properties, ports, 

interfaces, and connections. A component encapsulates internal properties (such as operations and 

data) that define the component implementation. A component’s port is a point of connection with 

other components. A port is typed by an interface, which is a contract containing the declaration of a 

set of services. If a port is ‘required’, the component uses one or more services declared in the 

interface typing the port. If a port is ‘provided’, the component offers the services declared in the 

interface typing the port. All required ports must always be connected whereas it is unnecessary for 

provided ones. The internal properties of a component implement services and service calls, all being 

defined in the interfaces typing each port of a component. Connections are explicit architecture 

description entities, used to connect ports. A connection is used to connect ‘required’ ports with 

‘provided’ ones. When a connection is established, the compatibility of interfaces is checked, to 

ensure ports connection consistency. 

Components composition mechanism (by means of connections between their ports) supports the 

“late composition” paradigm. The step when using a component-based language is to separate the 

definition of components from software architecture description (i.e. their composition). Components 

are independently defined/programmed and are made available in a ‘shelf of components’. According 

to the software architecture to be described, components are used and composed (i.e. their ports are 

connected by means of connections). The advantages of such a composition paradigm is to improve 

the reusability of components (because they are more independent from each other than objects), and 

the modularity of architectures (possibility to change components and/or connections). Obviously, the 

reuse of components is influenced by the standardization of interfaces typing their ports (which define 

the compatibility and so, the composability of components), but this is out of the scope of this paper. 

149


In the CoSARC language, there are four types of components: Representation Components, Control 

Components, Connectors and Configurations. Each of them is used to deal with a specific 

preoccupation of controller architecture design and implementation. We present the specificities of 

these types in the following sub-sections. 

B. Representation Components 

This type of component is used to describe a robot’s “knowledge” as regards on its operative part, 

its mission and its environment. Representation components are used to satisfy the “real-world 

modelling” preoccupation, but their use can be extended to whatever developers considers as the 

knowledge of the robot. They can represent concrete entities, such as those relating to the robot’s 

physical elements (e.g. chassis, and wheels of a vehicle) or elements of its environment. They can 

also represent abstract entities, such as events, sensor/actuator data, mission orders, control or 

perception computational models (in this context, those models are mathematical models that describe 

how to compute a set of outputs based on a given set of inputs, like for instance control laws and 

observers), etc. When a developer wants to represent the fact that a specific model is applied on a 

specific (operative) part of the robot, it just has to connect those two representation components: that 

corresponding to the computational model with that related to the operative part. For example, Fig. 2 

illustrates how to apply a control law to a given vehicle. 

Representation components are ‘passive’ entities that only act when one of their provided services 

is called. They only interact according to a synchronous communication model. Internally, 

representation components consist of object-like attributes and operations. Operations implement the 

services declared in provided ports and they use services declared in interfaces of required ports. 

Representation components are incorporated and/or exchanged by components of other types, such as 

control components and connectors. Representation components can also be composed between 

themselves when they require services of each-other. Indeed, a representation component consists of a 

set of provided ports that allows other representation components to get the value of its “static” 

physical properties (wheel diameter, frame width, etc.) and/or to set/get the current value of its 

“dynamic” properties (velocity and orientation of wheels, etc.). 

port 

VehiclePhysicalPropertiesConsultation 

VehiclePosition 

ControlLaw 

Vehicle 

typing VehicleDynamicPropertiesAccess 

interface 

VehicleActuatorsValueComputation 

Representation component 

Figure 2: Example of two connected representation components 

Fig. 2 shows a simple example of composition. The representation component called 

VehiclePositionControlLaw consists of: 

• a provided port, typed by the VehicleActuatorsValueComputation interface, through which another 

component (a representation or a control component) can ask for a computation of the value to 

be applied to the actuator. 

• and two required ports. The first one is typed by the VehiclePhysicalPropertiesConsultation 

interface, the second one by the VehicleDynamicProperties interface. These interfaces are 

150


necessary for the computation as some parameters of the model depend on the vehicle on which 

the corresponding law is applied. The corresponding ports are provided by the representation 

component Vehicle. VehiclePositionControlLaw and Vehicle are so composed by connecting the two 

required ports of VehiclePositionControlLaw with the two corresponding provided ports of Vehicle. 

C. Control Components 

A Control Component describes a part of the control activities of a robot controller. It can represent 

several entities of the controller, as we decompose the controller into a set of interconnected entities 

(all being components), like for example: Command (i.e. entity that executes a control law or a 

control sequence), Perception (i.e. entity in charge of sensor signal analysis, estimation, etc.), Event 

Generator (i.e. entity that monitors event occurrences), Mode Supervisor (i.e. entity that pilots the use 

of a physical resource in a given mode as teleoperation, autonomous, cooperation), Mission Manager 

(i.e. entity that manages the execution of a given mission), etc. A control component incorporates and 

manages a set of representation components which define the knowledge it uses to determine the 

contextual state and to make its decisions. 

Control components are ‘active’ entities. They can have one or more (potentially parallel) activities, 

and they can send messages to other control components (the communication being further detailed). 

Internal properties of a control component are attributes, operations and an asynchronous behaviour. 

Representation components are incorporated as attributes (representing the knowledge used by the 

component) and as formal parameters of its operations. Each operation of a control component 

represents a context change during its execution. The asynchronous behaviour of the control 

component is described by an Object Petri Net (OPN) [SIB, 85], that models its ‘control logic’ (i.e. the 

event-based control-flow). Tokens inside the OPN refer to representation components used by the 

control component. The OPN structure describes the logical and temporal way the operations of a 

control component are managed (synchronizations, parallelism, concurrent access to its attributes, 

etc.). Operations of the control component are executed when firing OPN transitions. This OPN based 

behaviour also describes the exchanges (message reception and emission) performed by the control 

component, as well as the way it synchronizes its internal activities according to these messages. Thus 

the OPN corresponds to the reaction of the control component according to the context evolution 

(received message, occurring events, etc.). 

We chose OPN both for modelling and implementation purposes. The use of Petri nets with objects 

is justified by the need of formalism to describe precisely synchronizations, concurrent access to data 

and parallelism (unlike finite state machines) within control components, but also interactions 

between them. The use of Petri nets is common, for specification and analysis purposes, in the 

automation and robotic communities. Petri nets formal analysis has been widely studied, and provides 

algorithms [DAV, 04] for verifying the controller event-based model (its logical part). Moreover, Petri 

nets with objects can be executed by means of a token player, which extends its use to programming 

purposes (cf. section 4). 

Fig. 3 shows a simplified example of a control component behaviour that corresponds to a 

command entity, named VehiclePositionCommand. It has three attributes: its periodicity, the Vehicle 

being controlled and the applied VehiclePositionControlLaw. The Vehicle and the 

VehiclePositionControlLaw are connected in the same way as described in Fig.3, meaning that the 

VehiclePositionCommand will apply the VehiclePositionControlLaw to the Vehicle at a given periodicity. 

Such decomposition allows the adaptation of the control component VehiclePositionCommand to the 

Vehicle and VehiclePositionControlLaw used (i.e. the representation components it incorporates). It is 

thus possible to reuse this control component in different control architectures (for vehicles of the 

same type). 

151


This control component’s provided port (Fig. 3) is typed by the interface named 

VehiclePositionControl that declares services offered (to other control components) in order to be 

activated/deactivated/configured. Its required ports are typed by one interface each: 

VehicleMotorsAccess which declares services used to fix the value of the vehicle’s motors and 

MobileWheelVelocityandOrientationAccess which declares services used to obtain the values of the 

orientation and velocity of the vehicle’s wheels. These two interfaces are provided by ports of one or 

more other control components (depending on the decomposition of the control architecture). 

The (simplified) OPN representing the asynchronous behaviour of VehiclePositionCommand shown in 

Fig. 3, describes the periodic control loop it performs. This loop is composed of three steps: 

- the first one (firing of transition T1) consists in requesting sensors data, 

- the second one (firing of transition T2) consists in computing the reaction by executing MotorData 

computeVehicleMotorControl(Velocity,Orientation) operation (cf. Fig. 1) and then by fixing the values of 

the vehicle motors (token put in FixMotorValue black place), 

- and the third one (firing of transition T3) consists in waiting for the next period before a new 

iteration (loop). Grey and black Petri net places both represent, respectively, the reception and 

transmission of messages corresponding to service calls. For example, grey places startExecution and 

stopExecution correspond to a service declared in the VehiclePositionControl interface, whereas the black 

place RequestVelAndOrient and the grey place ReceiveVelAndOrient correspond to a service declared in 

the VehicleWheelVelocityandOrientationAccess interface. 

VehiclePositionControl 

: Executor 

In StartExecution() 

In StopExecution() 

VehiclePositionCommand 

VehicleMotorsAccesss 

: Sender 

Out 

FixMotorsValues(MotorCommandData) 

Attributes: 

int period; 

VehiclePositionControlLaw law; 

Vehicle v; 

Operations: MotorData computeVehicleMotorControl (Velocity, 

Orientation) 

//state change and initialization operations 

Asynchronous Behaviour: 

startExecution 

stopExecution 

 

[period,∞] 

VehicleWheelsVelocityAndOrientationAccess 

: Requester 

Out RequestVelAndOrien( ) 

In ReceiveVelAndOrient(Velocity, Orientation) 

Figure 3: Simple example of a control component 

152 

T3 

T1 

T2 

RequestVel 

AndOrient 

ReceiveVel 

AndOrient 

FixMotors 

Value

D. Connectors 


Connections of control components are reified into components named connectors (that allow the 

assembly). Connectors contain the protocol according to which connected control components 

interact. Being a component, a connector is an entity definable and reusable by a user. It implements a 

protocol that potentially involves a large number of message exchanges, synchronizations and 

constraints. Once defined, connectors can be reused for different connections into the control 

architecture. This separation of the interaction aspect from the control one appears to be very 

important in order to create generic protocols adapted to domain specific architectures. One good 

practical aspect of this separation is that it leads to distinguish interactions description with control 

activities description, whereas describing both aspects inside the same entity type would reduce the 

reusability. 

A connector incorporates sub-components named roles (as attributes). Each role defines the 

behaviour’s part that a control component adopts when interacting through the protocol defined by 

the connector. We then say that a control component “plays” or “assumes” a role. For example, the 

connector of Fig. 4 describes a simple interaction between a RequesterRole and a ReplierRole. The 

control component assuming the Requester role sends a request message to the control component 

assuming the Replier role, which then sends the reply message to the Requester (once the reply has 

been computed). For each role it incorporates, a connector associates one of its required or provided 

ports. A connector’s port is typed by an interface that defines the message exchanges allowed 

between the connector on one side and the control component to be connected on the other side. Fig. 

4 shows that the connector has one provided port (left) typed by the Requester interface and one 

required port (right) typed by the Replier interface. The Replier interface defines the message 

exchanges between the connector and the VehicleIOController control component. VehicleIOController 

receives a request from the connector, computes it internally, and then sends the reply. The 

connection between the control components and the connector has been possible because of the 

compatibility of ports: an interface typing a connector’s port (provided or required) must be 

referenced by the interface of the control component’s port to which it is connected. Fig. 2 shows that 

VehicleWheelsVelocityAndOrientationAccess interface references the Requester interface which allows the 

connection of VehiclePositionCommand’s port; VelocityAndOrientationAccess interface references the 

Replier interface which allows the connection of VehicleIOController‘s port (cf. Fig. 4). Finally, 

compatibility of control components ports is verified according to interface names. Fig. 4 shows that 

the connection has been possible because VehicleWheelsVelocityAndOrientationAccess service is required 

and provided by the two control components ports connected (i.e. each interface has the same name). 

Vehicle 

Position 

Command 

Requester 

In sendRequest(any) 

Out receivedReply(any) 

VehicleWheelVelocityandOrientationAccess 

RequestReplyConnection 

RequesterRole 

ReplierRole 

Replier 

Out receiveRequest(any) 

In sendReply(any) 

Vehicle 

I/O 

controller 

Figure 4: Simple connector example, connecting two control components 

153


A connector can be a very adaptive entity. First, the number of roles played by components can be 

parameterized. Connector’s initialisation operation is useful to manage the number of roles played, 

according to the number of control components ports to be connected by the connector and according 

to their interfaces. A cardinality is associated with each role to define constraints on the number of 

role instances. For example, the ReplierRole has to be instantiated exactly one time, and the 

RequesterRole can be instantiated one or more time. The second adaptive capacity of connector is the 

ability to define generic (templates-like) parameters that allow to parameterize the connector with 

types. This is particularly important to abstract, as far as possible, the connector description from data 

types used in message exchanges. In Fig.2, the connector has two generic parameters: anyReq, 

representing the list of the types of the parameters transmitted with the request and anyRep, 

representing the list of types of the parameters transmitted with the reply. RequestReplyConnection is 

parameterized as follows: anyReq is valued to void, because no data is transmitted with the message; 

anyRep is valued with the Velocity and Orientation types pair, because these are the two pieces of 

information returned by the reply. Protocols being describes into a composition of roles, roles are 

parameterized entities too. 

Requester< anyReq, anyRep> Trasmitter < anyReq, anyRep> 

In sendRequest(anyReq) 

Out receiveReply(anyRep) 

Out transmitRequest(Id,anyReq) 

In transmitReply(Id, anyRep) 

RequesterRole 

Port 

sendRequest transmitRequest 

exported 

by the 

connector 

< anyReq> 

 

< anyRep> 

 

 

receiveReply 

transmitReply 

Trasmitter < anyReq, anyRep> Replier< anyReq, anyRep> 

In transmitRequest(Id,anyReq) 

Out transmitReply(Id, anyRep) 

Out receiveRequest(anyReq) 

In sendReply(anyRep) 

ReplierRole 

transmitRequest receiveRequest 

 

< anyReq> 

Port 

exported 

< Id> < anyRep> 

by the 

connector 

Ports internal 

to the connector 

transmitReply 

Figure 5: RequesterRole and ReplierRoles 

sendReply 

A role is a sub-component, part of a connector, that itself has ports, attributes, operations and an 

asynchronous behaviour, like control components (Fig. 5). But unlike, control components, roles 

description is completely bounded to connectors one. A role has a provided or a required port 

exported by the connector to make it “visible” outside the connector (and then, connectable with 

control component’s ports). Other ports of roles are internal to the connector (Fig. 4) and are 

connected by the connector’s initialization operation. A role implements the message exchange 

between the port of the connected control component and its (own) associated port, as well as the 

message exchange with the other role(s) of the connector (i.e. exchanges inside the connector). 

Constraints described in the OPN of the ReplierRole (Fig. 5) ensure that only one request will be sent 

by the Requester until it receives a reply, and that the Replier will process only one request until it 

sends the reply to the Requester. The OPN of ReplierRole ensures that only one request will be proceed 

at a time by the component assuming this role. It also describes the way it identifies and memorizes 

the requester in order to send it the reply. A specific object of type Id, that contains all necessary 

configuration information to this end, can be transmitted during messages exchanges. RequesterRole 

sends its own identifier object to the ReplierRole, with transmitRequest message (the state of the Id is 

“informing”). The ReplierRole uses this Id to identify its clients and then sends it the reply computed 

by the control component behaviour. In this case, the Id is used to configure communications (its state 

is “routing”), and not as registering data. When more than one RequesterRole exists, each has a port 

typed by the Transmitter interface that is connected to the corresponding provided port of the unique 

ReplierRole. Then their Id are used by the replier to select the receiver of the computed reply. The 

initialization of role Id is made by the initialization operation of the connector. 

154

The RequestReplyConnection connector can be used to establish connections between different 

control components, if the interaction to be described corresponds to this protocol, and if ports are 

compatible. To design a mobile robot architecture, we defined (and used several times) different types 

of connectors supporting protocols like EventNotification or DataPublishing. 

Connectors being also modelled by Petri nets, it allows to build the OPN resulting from the 

composition of control components (i.e. the model resulting from the composition of all their 

asynchronous behaviours). Thanks to this property, developers can analyze inter-component 

synchronizations, allowing then to check, for example, that those interconnections do not introduce 

any dead-lock. 

E. Configurations 

Once the control architecture (or part of it) has been completely modelled, the result is a graph of 

the composition of control components (composition done by means of connectors). The CoSARC 

language provides another type of component, named Configuration, that contains this graph. It 

allows developers to incorporate a software (sub-)architecture into a reusable entity. Configurations 

can be used to separate the description of sub-systems, each one corresponding to a resource of the 

robot. The global control architecture can be represented by configuration. At design phase, a 

configuration can be considered as a control component because it has ports that are connectable via 

connectors. Ports of a configuration export ports of control components that the configuration 

contains (dotted lines, Fig. 6). At runtime, any connection to those ports is replaced by a connection 

to the initial port, i.e. to that of the concerned control component. Fig. 6 shows an example of a 

configuration: the MobileSubSystem, corresponding to the sub-architecture controlling the vehicle part 

of a mobile robot. It exports the provided port of the MobileSupervisor and the required ports of 

VehiclePositionCommand and VehicleObstacleEventGenerator. Since a configuration can contain others 

configurations, it allows developers to describe the controller architecture at different levels of 

granularity. 

configuration 


Mobile 

Supervisor 

Mobile Resource 

Action 

Vehicle 

Move To 

Position 

Vehicle 

Autonomous 

Mode 

Vehicle 

Position 

Command 

Vehicle 

Obstacle 

Event 

Generator 

Control components 

placement 

container 

processing node 

Containers priority 

Figure 6: Managing architecture organization: description of the MobileResource by means of a 

configuration and description of its deployment. 

The CoSARC language provides structures to describe the deployment of a configuration. This 

description is made of two phases: 

155


- the hardware description phase (graphs of nodes, communication networks) allows to define 

operating system (OS) resources available to execute components, 

- the component placement phase allows to define the different OS processes (named 

containers) executing one or more control components and to define the scheduling of these 

processes on each node. At the deployment stage, configurations incorporate the description used 

to install and configure components. 

This mechanism allows to treat the deployment of an architecture independently of the control 

behaviour it defines. We chose to treat the organization of a control architecture into layers 

(hierarchy) during the deployment phase. A container is the unity that is useful to (parts of) layer’s 

description. The relationships between layers are translated into container execution configuration: 

container’s process execution priorities are set depending on layer’s relationship (the upper is the 

layer represented by the container, the higher is its priority of reaction). One future research is to find 

a multi-criteria scheduling algorithm (dealing with temporal constraints in addition to containers 

priorities) which will be more adapted to the management of layers hierarchy, in order to ensure 

maximal reactivity of low layers without sacrificing pre-emption of upper layers. 

IV. DEPLOYMENT & EXECUTION MODEL 

The CoSARC language is not only a design but also a programming language. Then, it needs a 

framework to execute components. This framework is a middleware application that runs on top of an 

OS. It provides standardized access to OS functionalities, and a set of functionalities specific to the 

CoSARC components execution. It is also in charge of configuration deployment (i.e. the deployment 

of control components and connectors corresponding to the description made) by creating containers 

and by managing their scheduling on each processing node. 

Threaded Threaded 

Operation 

Threaded 

Operation Operation 

parallel operation 

programming 

token 

emission 

operation 

ending 

events 

Token 

Player 

Interaction 

Engine 

time 

events 

token 

reception 

Figure 7: Container’s internal structure 

Timer 

Timer 

Timer 

timer 

programming 

A container is in charge of the execution of a set of control components and the set of all 

the roles played by these components. Any number of control components and roles can be placed 

into one container, and many containers can be deployed on the same processing node. It supports 

OPN execution and roles communications by the mean of two software processes that interact 

with an asynchronous communication model (Fig. 7): the Token Player (TP) and the Interaction 

156


Engine (IE). The TP is a kind of OPN inference engine that executes the byte code in which is 

compiled the OPN resulting from the composition of all the asynchronous behaviours of roles and 

control components contained in the container. During its execution, it can program threads for 

parallel operation execution and timers for timed transition management. During execution, the 

TP communicates with the Interaction Engine (IE) for emission and reception of external messages. 

The IE manages run-time communications of control components that are contained in the 

corresponding container. These communications between control components are configured 

depending on the connection of the roles they play. At run-time the IE of a given container exchanges 

messages with IE of others containers according to roles connection information. Given a container, 

its IE unpacks received messages to give corresponding tokens to the Token Player. And vice-versa 

its IE packs up tokens arriving from its TP to send the corresponding messages (Fig. 8). 

Figure 8: container communications 

In the next subsections we first present components deployment model and we focus on OPN 

execution mechanism in the second one. 

A. Deployment Model Overview 

Container Container 

TP Token 

Inference 

Token 

reception 

Token 

unpacking 

IE 

Message 

transmission 

The execution of CoSARC components is completely configured by their deployment. The 

description of configuration deployment is useful to describe precisely components execution issues. 

It is used to configure containers priorities, but it also helps determining where and how OPN are 

executed. The deployment is realized by the following steps: 

• The component placement step consists in creating each container on nodes and placing 

components code inside containers, corresponding to deployment description (Fig.6). 

• The role assignment step consists in defining where roles are executed. This is automatically 

deduced from the preceding step by applying the following rule: when a control component plays a 

role, this role is executed in the same container as the control component. Fig.9 shows that 

VehiclePositionCommand and RequesterRole are placed inside the same container. A connector can be 

then distributed among different containers. 

• The behaviour execution model definition step consists in producing a global OPN that will be 

executed by the TP. A container OPN model can be made of the disjoined union of the complete 

control component behaviour. A complete behaviour is an OPN model of the fusion of a control 

component’s and role’s asynchronous behaviours. This fusion is deduced from each connection 

between a control component and a role it plays: each place concerned with message exchanges, of a 

157 

Token 

Inference 

IE 

Token 

packing 

TP 

Token 

emission


control component’s OPN, is merged with the corresponding place of a role’s OPN, according to port 

connection and interface matching. The resulting OPN, executed by a container, is thus made of as 

many “complete behaviours” as control component it has to execute. These behaviours can 

communicate between each others (if connections between their roles exist) and they can 

communicate with behaviours contained in other containers. Fig. 9 gives an example of this step: it 

shows that, for example, places P1 and P3 are merged, because they are bind to the same sendRequest 

service of the Requester Interface. 

VehiclePositionCommand 

Vehicle 

I/O controller 

P11 

P12 

P1 

P2 

P3 

P4 P6 

Requester Role 

RequestReply 

Connection 

P5 

Replier Role 

P10 P7 

P9 

P8 

Figure 9: deployment of containers - OPN byte code compilation. 

P1–P3 

P2–P4 

• The container communication configuration step consists in defining communications between 

(and inside) Interaction Engines of containers, according to connections between ports of roles (Fig. 

4). For example, the RequesterRole r1 and the ReplierRole r2 are connected by their ports typed by the 

Transmitter interface. The interaction described in the two Transmitter interfaces (Figs. 4, 5) implies 

that r1 sends transmitRequest message to r2 and that r2 sends transmitReply message to r1 (once their 

ports are connected). 

Configuring communications supported by Interactions Engines is made in different steps. First it 

requires to determine relations between Interactions Engines. This is deduced by applying the 

following operation: 

foreach port p of a role r executed by a container c 

foreach port p’ of a role r’ executed in container c’ 

if p connected with p’ 

configure message reception and emission between c and c’ 

with information of p and p’ interfaces. 

end 

end 

Second, it consists in defining the system communication supports (pipe, TCP/IP, etc.) used to 

make IE communication effective. This is done in accordance with connector deployment. If a 

connector is deployed on one container, the communication is local to the IE, so the IE directly route 

tokens without using OS communication support. If it is deployed on two or more containers placed 

on the same processing node, the communication relies on OS process communication procedures 

158 

P9–P12 

P8 

Container 1 

P10–P11 

P7 

Container 2 

P5 

P6


(e.g. Mailbox). If the connector is deployed then a network communication protocol has to be used 

(e.g. TCP/IP). For the moment, we don’t consider network distribution problems. 

Finally, it consists, for each IE, in doing the matching of the message reception and emission points 

on one hand, and respectively input and output places of OPN played by the TP on the other hand. 

This information is directly extracted from ports description (ports reference input and output places 

associated to message transmission). The IE can then, packs tokens arriving from the token-player 

into emitted messages, and unpacks token from message arrivals. 

Vehicle 

Position 

Command 

Token 

Player 

Container 2 

P5 

P6 

 

Figure 10: Configuring containers communications with connector and deployment information. 

Fig. 10 shows an example of the configuration of the interaction engines of container 1 and 2 

according to the connector used and its deployment. We can see that IE of container 1 packs tokens 

coming from the place P5 into a transmitRequest message and sends the message to container 2. The IE 

of container 2 unpacks the token from the message and puts it to the place P7. 

B. OPN Execution Model Overview 

RequestReplyConnection 

Requester 

Role 

Processing Node 

Replier 

Role 

transmitRequest(Id,void) 

Interaction 

Engine 

transmitReply(Id, 

Interaction 

Engine 

Container 1 

 

Vehicle 

I/O 

controller 

 

Token 

Player 

P8 

Container 2 Velocity, Orientation) Container 1 

Basically there are two main approaches for implementing a discrete-event controller specified by 

means of a Petri net [VAL, 95]. For the first one, by means of a procedural language, a collection of 

tasks are coded in such a way that their overall behaviour emulates the dynamics of the Petri net. For 

the second one, the Petri net is considered as a set of declarative rules. Then an inference engine 

which does not depend on the particular Petri net to be implemented operates on the data structure 

representing the net. This inference engine is the Token player that propagates tokens with respect to 

the semantic of OPN formalism. The TP also executes functional calls contained in condition and 

action parts of OPN’s transitions. Operations can be threaded when their execution is too long and 

may block the inference for a too long time. The TP also programs timers when it needs time events 

to be monitored (time-out, periodic, delay events) to deal with timing notations on transitions. When 

timer or thread execution is finished, they send corresponding internal events to the TP. The argument 

to use a TP instead of a direct compilation into a programming language, is that the state of the OPN 

during execution is reified, allowing then to put in place introspection (dynamic study of OPN state) 

and reflexive (dynamic change of the OPN state) mechanisms. Introspection is useful to reason, at 

run-time, about sequences of events, in order to detect a problem and elaborate a diagnosis. 

Reflexivity is useful to correct (or modify) the OPN state, one diagnosis is done. 

159 

P7


The Token Player inference mechanism [PAS, 02] is event based: PNO tokens are propagated in the 

PN control structure, as far as possible according to OPN propagation rules, and then stands for new 

events to reactivate the inference mechanism. In order to optimise the OPN inference, its structure is 

compiled into an equivalent executable structure (Fig. 11). The principle is to decompose transitions 

into an optimised graph of transition nodes (test, joint, time and action nodes are only used if 

required); the propagation mechanism is applied on this resulting graph. 

 

conditions 

actions 

[t1, t2] 

test test 

Figure 11: compilation of a transition into an executable structure 

The propagation mechanism propagates tokens as far as possible within this resulting graph. The 

TP starts from new marked places of the PNO and propagates tokens of each new marked place 

through transitions, i.e. the deepest as possible within the equivalent graph. For example, in Fig. 11, 

the token will be propagated to the first node ("test"). In the case of a successful test, the token will be 

blocked before the "Joint" node until a token arrives in the adjacent "test" node and satisfies this test. 

When done, the two tokens are used to verify test associated to the "Joint" node. If this step is passed, 

tokens continue their propagation to the "Time" node and stands for the time event to occur (if 

specified). Once the time event has occurred, the propagation will continue to the "Action" node, 

where operations will be executed (as well as eventually new token creations). When new tokens 

have been created and put into one or more post-places, these places are considered to be newly 

marked ones. 

When the propagation is not possible anymore (i.e. there is no newly marked place), the OPN 

inference mechanism is in a “stable state”. A “stable state” is a state in which token propagation is 

waiting for event occurrences to be pursued (Fig. 12). So, in a stable state, the token player stands for 

internal events (time event or parallel operation ending) and/or external events (message arrival) that 

will reactivate token propagation. For instance, when an external event occurs a new token is created 

and put into the corresponding Input Place; such newly marked place leads the propagation to start 

again. 

The right part of Fig. 12 depicts the propagation of tokens from newly marked place. When all 

tokens have been propagated from such place to its post-transitions, this place is no more considered 

as a newly marked place. If a transition is fired (action is executed) then new tokens are created and 

put down into post-places which become then newly marked places. When all the post-transition of a 

given place have been treated, then the token player checks if new internal events occurred. If none, 

the propagation pursues with another newly marked place. On the other hand, if an internal event has 

occurred, it is treated before pursuing with the newly marked places. When all the newly marked 

160 

 

Joint 

Time =[ t1, t2] 

Action


places have been considered and in lack of internal event occurrences, the token player reaches a 

“stable state”. 

In this inference mechanism, we distinguish internal and external events: internal events are 

monitored more frequently than external ones (Fig. 12). This distinction is made because of the nature 

(meaning) of the events. For reactivity purposes, internal events, and particularly time events, must be 

handled as quickly as possible. Indeed, such events can correspond to watchdogs for example. 

External events result from message arrivals and represent communications between component 

instances. Internal reactivity (reaction and propagation) is considered as having priority over external 

request. When tokens are put into output places, these tokens are given to the Interaction Engine in 

charge of sending them as parameters of messages. 

Stable State : 

Wait 

internal or external 

event reception 

managing new 

events 

yes no 

new 

internal 

event ? 

no 

no 

for T, a post-transition of 

this newly marked place P. 

propagates all new 

tokens from P to T. 

Figure 12: Simplified Token Player inference mechanism 

For determinism and performance purposes, the token player relies on: 

- A real time operating system which allows to manage time events thanks to real time clocks, and to 

define precisely component instances process execution priorities. 

- The determinism of the executed structure that is possible thanks to OPN transition firing priorities. 

- The efficiency of the propagation mechanism. It allows to avoid polling of the OPN (cyclic 

execution) and consequently optimises its execution (and processor use). 

- The robustness of the inference mechanism which guarantees that no evolution will take place if an 

incoherent or a non-pertinent event occurs. 

Actually, the TP has been developed and tested in order to validate inference mechanism. A 

complete and real-time version of container’s execution mechanism is under development. 

Representation components are translated into objects and their types are translated into classes. Each 

of these classes implements the object interfaces corresponding to the interfaces typing the provided 

ports. Each required port is translated into a specific attribute that references the object interface 

corresponding to the interfaces typing the required ports. Connections of representation component 

ports are also manageable by means of a specific connection object. 

161 

still newly 

marked 

places ? 

yes 

another posttransition 

of P ? 

yes


V. CONCLUSION 

We have presented the CoSARC methodology, which is devoted to improving quality, modularity, 

reusability and the upgradeability of robot control architectures, along all the architecture life cycle, 

from analysis to execution. To this end, the methodology relies on two aspects: an architecture pattern 

and a component-based language. The proposed architecture pattern helps in many way for the 

organization of control activities, by synthesizing main organization principles. It also gives a way for 

identifying control activities and their interactions with respect to material elements of the robot. It is 

also specifically dedicated to the reification and the integration of human expertise (control laws, 

physical descriptions, modes management, observers, action scheduling, etc.). The CoSARC 

language deals with design, implementation and deployment of control software architecture. It 

supports four categories of components, each one dealing with a specific aspect during control 

architecture description. Moreover, it has the added benefit of relying on a formal approach based on 

Object Petri Nets formalism. This allows analysis to be performed at the design stage which is a great 

advantage when designing the control of complex systems. 

Current works concern the development of the CoSARC execution environment and of the 

CoSARC language development toolkit. 

REFERENCES 

[ALA, 98] Alami, R. & Chatila, R. & Fleury, S. & Ghallab, M. & Ingrand, F. An architecture for autonomy, 

International Journal of Robotics Research, vol. 17, no. 4 (April 1998), p.315-337. 

[ALB, 02] Albus, J.S. & al., 4D/RDC: A reference model architecture for unmanned vehicle systems. Technical 

report, NISTIR 6910, 2002. 

[ALD, 03] Aldrich, J. & Sazawal, V. & Chambers, C. & Notkin, D. Language support for connector 

abstraction, in Proceedings of ECOOP’2003, pp.74-102, Darmstadt, Germany, July 2003. 

[ARK, 97] Arkin, R.C. & Balch, T. Aura : principles and practice in review. Technical report, College of 

Computing, Georgia Institute of Technology, 1997. 

[BIN, 96] Binns, P. & Engelhart, M. & Jackson, M. & Vestal, S. Domain Specific Architectures for Guidance, 

Navigation and Control. International Journal of Software Engineering and Knowledge Engineering, vol. 6, no. 

2 (June 1996), pp.201-227, World Scientific Publishing Company. 

[BOR,98] Borrely, J.J. & al. The Orccad Architecture. International Journal of Robotics Research, Special 

issues on Integrated Architectures for Robot Control and Porgramming, vol. 17, no. 4 (April 1998), pp.338-359. 

[BRO,98] Brooks, R. & al.. Alternative Essences of Intelligence. in Proceedings of American Association of 

Artificial Intelligence (AAAI), pp. 89-97, July 1998, Madison, Wisconsin, USA. 

[BRO, 86] Brooks, R.A. A robust layered control system for a mobile robot. IEEE journal of Robotics and 

Automation, vol. 2, no. 1, pp.14-23, 1986. 

[BRU, 02] Bruneton, E. & Coupaye, T. & Stefani, J.B. Recursive and Dynamic Software Composition with 

Sharing. In Proceedings of the 7th International Workshop on Component-Oriented Programming (WCOP02) 

at ECOOP 2002, June 2002, Malaga, Spain. 

[DAV, 04] David, R. & Alla, H. Discrete, Continuous and Hybrid Petri Nets. Ed. Springer, ISBN 3-540-22480- 

7, 2004. 

[MED, 97] Medvidovic, N. & Taylor, R.N. A framework for Classifying and Comparing Software Architecture 

Description Languages. In Proceedings of the 6th European Software Engineering Conference together with the 

5th ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE), Springer-Verlag, 

pp. 60-76, 1997, Zurich, Switzerland. 

[MUS, 02] Muscettola, N. & al.. Idea : Planning at the core of autonomous reactive agents. In Proceedings of 

the 3rd Int. NASA Workshop on Planning and Scheduling for Space, 2002. 

162


[OMG, 01] OMG. Corba 3.0 new components chapters. OMG TC Document formal 2001-11-03, Object 

Management Group, December 2001. 

[PAS, 02] Passama, R & Andreu, D. & Raclot, F. & Libourel, T. J-NetObject :Un Noyau d'Exécution de 

Réseaux de Petri à Objets Temporels. Research report LIRMM n°02182, version 1.0, LIRMM, France, 

December 2002. 

[SIB, 85] Sibertin-Blanc, C. High-level Petri Nets with Data Structure, in proceedings of the 6th European 

workshop on Application and Theory of Petri Nets, pp.141-170, Espoo, Finland, June 1985. 

[STE, 96] Stewart, D. B. The Chimera Methodology: Designing Dynamically Reconfigurable and Reusable 

Real-Time Software Using Port-Based Objects, International Journal of Software Engineering and Knowledge 

Engineering, vol. 6, no. 2, pp.249-277, June 1996. 

[SZY, 99] Szyperski, C. Component Software: Beyond Object Oriented Programming, Addison-Wesley 

publishing. 

[VAL, 95] R. Valette. Petri nets for control and monitoring: specification, verification, implementation. In 

workshop « Analysis and Design of Event-Driven Operations in Process Systems, Imperial College, Centre for 

Process System Engineering, London, 10-11 April 1995. 

[VOL, 01] Volpe, R. & al. The CLARATy Architecture for Robotic Autonomy, in Proceedings of the IEEE 

Aerospace Conference (IAC-2001), vol. 1, pp.121-132, Big Sky, Montana, USA, March 2001. 

163


An Asynchronous Reflection Model for 

Object-oriented Distributed Reactive Systems 

Jacques Malenfant 1 

Université Pierre et Marie Curie-Paris6, UMR 7606, 

8 rue du Capitaine Scott F-75015 Paris, France 

CNRS, UMR 7606, 8 rue du Capitaine Scott F-75015 Paris, France 

Jacques.Malenfant@lip6.fr 

Abstract. Today’s distributed and embedded systems challenge the traditional procedural 

approach to reflection. Central to this approach is the use of an “implements” relationship 

to realize the connection between the meta and the base level. This restricted view of reflection 

is inappropriate in distributed or embedded computing, where part of the system to 

reflect upon cannot be captured in an “implements” relationship, either because we lack a 

centralized state or an essential ingredient lies outside the system. We introduce a novel asynchronous 

reflective model, ARM, where the connection between levels use an asynchronous 

publish/subscribe communication model. We show not only that this model is better suited 

to distributed and reactive systems, but that it also generalizes the possible forms of reflection 

by adopting and adapting to B. Smith’s “right combination of connection and detachment” 

between the base and the metalevel. ARM is applied to the reflective control of modular 

robots, which dynamic physical reconfigurability must be paralleled by a software reconfigurability 

offered by reflection. ARM then uses reactive objects founded on the GALS 

approach (globally asynchronous, locally synchronous), which implements synchronization 

by future values. A hybrid deliberative/reactive framework inspired by intelligent robotic 

control systems is implemented using the ARM[GALS] for Java platform. 

Keywords: reflection, object-oriented systems, distributed systems, embedded & reactive 

systems, event-based computing, AI robotics. 

1 Introduction 

Today’s distributed and embedded systems operate for long periods of time, while large variations 

in the level of available resources are observed. Sustaining an acceptable level of performance in 

such contexts requires dynamic adaptation of applications. Reflection [39] has been proposed both 

as a conceptual framework and as an architectural blueprint to achieve dynamic adaptation of 

applications, yet these new systems challenge the traditional procedural approach to reflection. 

In this paper, we consider the problem of controlling modular robots. A modular robot is one 

that is made of a large number of homogeneous and simple robotic entities, which can be physically 

assembled and reconfigured during the mission. Examples of such robots are CONRO [38] and M- 

TRAN [48]. The key concept behind modular robotics is that the shape provides for the function. 

Modular robots are morphologically reconfigurable to adapt to their mission: open field motion, 

go over obstacles, motion within pipes or between close walls, etc. We currently participate in a 

modular robot project called MAAM (Molecule := Atom | Atom + Molecule) where modules called 

atoms are build from a spherical kernel to which six orthogonal legs are attached. Legs can move in 

a cone and they can bind to each others to form molecules (see Figure 1). Because the morphology 

of the robot defines its function, we claim that a parallel reconfigurability of the software controlling 

the robot is necessary to dynamically implement the control of the new function. 

Modular robots are examples of distributed embedded systems for which we introduce a novel 

reflection model called Asynchronous Reflection Model, or ARM. We apply this new model to 

the software reconfiguration and dynamic adaptation of MAAM atoms. ARM aims at breaking 

the limits of procedural reflection to apply to distributed or embedded systems. It is seeking for 

generality and genericity, being parameterized both by the kind of base level supporting entities 

164


Fig.1. The MAAM atom and molecule. 

(components, active objects, reactive objects, and so on) and by the form of reified representation 

chosen to match the need for adaptation of the application. Hence, ARM should rather be seen 

as a generator ARM[·](·) of reflection models. 

We also present a Java implementation of ARM, which is based on an hybrid active and 

reactive object model. In this implementation, reactive objects use a synchronous approach to 

real-time [18], which meshes well with the event-based computation model of ARM. However, we 

preserve active objects, better suited to program the metalevel entities. We therefore have adopted 

the globally asynchronous but locally synchronous (GALS) approach. The control of individual 

atoms is seen as a synchronous program, which can communicate with other atoms and the metalevel 

using asynchronous events. Our active and reactive objects implement synchronization using 

future values, a premiere in this context to our knowledge. For the MAAM project, we have developed 

a hybrid deliberative/reactive framework inspired from work in AI robotics [2], within the 

ARM[GALS] for Java platform. A first deliberative metamodel for the dynamic adaptation of 

atoms has also been implemented. 

The rest of the paper is organized as follows. In the next section, we introduce procedural 

reflection and then discuss its limitations in order to argue in favor of a novel asynchronous approach 

to reflection. In Section 3, we introduce the ARM model and its implementation in Java. Next, 

we address the problem of MAAM distributed real-time control by introducing our GALS model, 

its integration with ARM to give the ARM[GALS] platform for Java, and its use to develop the 

deliberative/reactive framework used to program MAAM atoms. We then compare our approach 

to the related work and finally give conclusions and some perspectives of this work. 

2 Motivations 

2.1 Procedural reflection 

Dating back to the seminal work of Smith, reflection is “an entity’s integral ability to represent, 

operate on, and otherwise deal with its self in the same way that it represents, operates on and deals 

with its primary subject matter” [40]. Reflective behavior is implemented by a metalevel, “the most 

identifiable feature of reflective systems”, placed in a meta relationship with a base level. Although 

Smith did not impose any particular way to realize this relationship, his 3-Lisp language [39] and 

most of its descendents have adopted an “implements” relationship, where the metalevel interprets 

or otherwise processes the base level using traditional data structures of language processors reified 

into the language of the base level, thus enabling reflective computations. 

The restriction of reflection to systems where the metalevel is in an “implements” relationship 

with the base level has been called procedural reflection by Jim des Rivières [14] and it has been 

defined as follows by Bobrow, Gabriel and White [5] in the context of reflective programming 

languages: 

“Reflection is the ability of a program to manipulate as data something representing the 

state of the program during its own execution. There are two aspects of such manipulation: 

165


introspection and intercession. Introspection is the ability for a program to observe and 

therefore reason about its own state. Intercession is the ability for a program to modify 

its own execution state or alter its own interpretation or meaning. Both aspects require 

a mechanism for encoding execution state as data; providing such an encoding is called 

reification. 

To be more precise, reification encompasses both defining a representation (e.g. a class hierarchy) 

and obtaining objects at run-time that actually represent the current state of the computation. 

To be effective, introspection and intercession must operate on reified data that are continuously 

updated. Causal connection is the property of the link between the base and the metalevel imposing 

that any changes to one level leads to a causal effect on the other. 

2.2 Limits of procedural reflection 

The “implements” relationship exhibits many desirable properties, such as a full causal connection. 

When using metacircular interpreters as metalevel, it becomes easy to reify since everything is 

already represented by the metacircular interpreter as data structures in the base level language. 

However, it has the major drawback of introducing a full coupling between the two levels. Indeed, 

when adopting this kind of relationship, the meta in some sense is the base level, an observation 

that Danvy and Malmkjaer have formalized under the single-threadedness property of 3-Lisp like 

reflective languages [13]. 

The single-threadedness property says that, at any time, only one of the base or the metalevel 

is actually running. A usual corollary assumption permeating all reflective code is that nothing 

happens at the base level during reflective computations, and therefore modifications to the base 

level through its metalevel representation take effect before any computation steps can be carried 

over at the base level. In other words, metalevel and base level computations steps are synchronous 

with each other in the sense that they are totally ordered and happening in “mutual exclusion”. 

Except for some attempts in AI and agent-oriented programming, this view of reflection has 

permeated the vast majority of the reflective languages, middleware and systems proposed to date. 

Only a few recent reflective languages and middleware begin to timidly introduce alternatives (see 

§6). Unfortunately, this vision does not scale outside the traditional sequential programming field 

where it was first realized. Smith has often argued against such a restriction of reflection in an 

AI perspective, where his theory would apply to the relation between an intelligent entity and 

the world into which it operates [41]. Today, the challenge for this choice of the “implements” 

relationship to connect the base and metalevel comes from attempts to apply reflection into the 

distributed and embedded computing paradigms, where this relation fails to cope with the very 

nature of actual systems. 

In distributed computing, the “implements” relationship goes against the absence of a global 

state and the inherent characteristics of a system made of independent computing nodes. As a 

result, most attempts to introduce reflection in distributed systems either restrict themselves to 

reflect upon individual (sequential) entities independently [45,46,30,22,28,35,47,11,31,29], where 

a procedural approach can be applied, or reify only very particular aspects (e.g. message sending, 

stubs, ...) upon which local reflective computations can be introduced. Little work has been done 

to introduce reflection in embedded systems (however, see [21]); difficulties are similar to the ones 

while of AI applications foreseen by Smith, since they need reflection upon the “outside world” 

that indeed cannot be put in an “implements” relationship with the metalevel. 

2.3 Advantages of an asynchronous non-implementing approach 

To achieve its full generality, reflection must go beyond the traditional procedural approach and 

propose new ways to view reification and to implement the connection between the base level 

and its metalevel. In this paper, we propose that the publish/subscribe event-based computation 

model is better suited to implement the connection between the meta and the base level. We 

therefore introduce an asynchronous reflective model where the communication between levels 

166


uses asynchronous events and we claim that this model provides the means to adopt and adapt to 

the “right combination of connection and detachment” [39] necessary to reflect in general. 

Of course, developing a reflective kernel upon a publish/subscribe middleware is not a real challenge. 

The crucial point concerns the revolution in the resulting form of reflection and therefore 

what this new form allows us to do that was not possible in the traditional procedural reflection 

approach. Generally speaking, using asynchronous events and distinguishing the metalevel representation 

from the data structures of the language processor go around the old discussions about 

the concurrency versus the non-concurrency between the base and the metalevels. Being relieved 

from its execution role, the metalevel can execute concurrently with the the base level. 

More substantially, rejecting the strict synchrony imposed by procedural reflection to the benefit 

of a more finely-shaded semantics more or less synchronized, more or less fault-tolerant, or 

respecting different notions of causality between events, allows us to introduce a corresponding 

finely-shaded notion of causal connection. This corresponds exactly to what Smith was argueing 

for when requiring an equilibrium between connection and detachment among levels. The importance 

of this aspect appears clearly in real-time systems where strict deadlines must be met 

even when calling for reflective computations. These reflective computations must be sufficiently 

detached from the real-time base level to maintain the timeliness of the system. 

Asynchronous reflection opens a wide spectrum of possible reified representation to be explored 

according to the form of introspection and intercession to be implemented. When relieved from 

the constraints of acting as the execution state of the language processor, reified representation 

can be defined as a model, in its very sense, i.e. an abstraction chosen for its proper goal. In the 

complex world of distributed embedded systems, it is illusive to hope for complete models, taking 

into account all aspects of the base level. In asynchronous reflection, incompleteness, fuzziness, 

or even randomness in representation can be smoothly integrated in models. Given the needs for 

adaptation, the model is defined by necessity, for the reified representation and for the means to 

construct the model, to instrospect and to intercede with the base level. A model is constructed 

by the metalevel by aggregation and processing of events received from the base level. The model 

needs not be unique. Models can easily be composite, thanks to the publish/subscribe technology. 

Using its autonomous execution, the metalevel can also perceive events coming from other base 

level entities and even events coming from sensors collecting information from the non-computerized 

“outside” world, thus enabling truly distributed and embedded reflection. Autonomous execution 

also allows the metalevel to probe its environment to collect the necessary information. Unlike 

reflection à la 3-Lisp, the metalevel can take the lead in adaptation instead of waiting for requests 

from the base level. 

The flexibility of publish/subscribe communication can also be recruited to provide a wide 

spectrum of connection/detachment possibilities. Events coming from the base level entity associated 

to the metalevel can be followed with a finer granularity than the ones coming from other 

entities or from the sensors. This can be done using the content-based filtering capabilities of 

message-oriented middleware. For example, to reflect upon the tactics and strategies of a robot 

football player, the metalevel need not be informed of the precise state of all the mechanisms controlling 

the movement of the robot. Moreover, in asynchronous procedural reflection, the grain of 

observable computational steps can be organized hierarchically (bigger steps being an aggregation 

of finer steps) so that the choice of notification granularity can be made on a per entity basis. This 

provides exactly the kind of tradeoffs Smith was looking for when he was talking about “the right 

combination of connection and detachment”. 

Furthermore, as filters can be modified dynamically, the connection/detachment tradeoffs need 

not be decided once and for all but rather adapted to the current situation. For example, at some 

point in time, the metalevel may want to ignore the level of remaining energy in the robot batteries, 

and inhibit the related events. But when the energy level crosses some threshold, the metalevel can 

switch into a mode where such events are sollicited and taken into account to adapt the behavior 

of the base level (robot). More generally, some sort of meta-events can mark thresholds crossing 

leading to a modification in the granularity of observation from the metalevel. 

Finally, the very nature of reified representations will drastically change in this new settings. 

The experience we got when applying reflection to adapt systems dynamically [27], as well as the 

167


Entity StructuralMeta 

BehavioralMeta 

basicBehavioralMeta 

Fig.2. Kernel entities of ARM. 

inherits−from 

instance−of 

meta−of 

work in multi-agent systems show the necessity of prevision and planning for intercession. To adapt 

an application to the level of physical resources available is a control problem in the sense of classical 

control theory. Poor control policies can severely deteriorate the performance. To repetitively adapt 

to rapidly varying physical parameters can lead to a form of trashing where the system does nothing 

else but adapt itself. This well-known problem in control theory can be tackled by an appropriate 

choice of metalevel representation upon which viable policies, if not optimal, can be computed and 

then applied when interceding with the base level. Our asynchronous reflection model therefore goes 

towards a marriage of reflection and control to succeed in the dynamic adaptation of applications. 

Of course, the major disadvantage of our asynchronous approach to reflection is the loss in 

reactiveness of the metalevel. Very fine-grained adaptations, to the level of instructions in the base 

level program, will not be efficiently implementable in the asynchronous approach. There are two 

counter-arguments to this. First, the kind of adaptability needed in distributed and embedded 

systems has often to do with variations of resources or context that happen infrequently compared 

to the rythm of instruction scheduling and execution but frequently compared to the duration of the 

whole program execution (sometimes years of continuous execution for some embedded systems). 

Second, nothing prevents a dual model, where a more traditional procedural reflection tightly 

integrated with the base level for language-oriented adaptation combines with an asynchronous 

reflection metalevel catering for environmental adaptation. 

As a matter of fact, asynchronous reflection does not abolish procedural reflection, because 

intercession with a base level program still needs a reification of the program to be effective. 

Full procedural reification is not always necessary for all kinds of adaptation however. Reflective 

middleware such as reflective virtual machines can provide the necessary APIs to adapt the base 

level. In Java, for example, the possiblity to modify the code by hotswap as provided by the 

Java Platform Debugging Architecture (JPDA) [23] or code manipulation capabilities provided by 

reflective JIT compilers [34] can give enough flexibility to attack a wide spectrum of adaptation 

problems. 

3 The Asynchronous Reflection Model 

3.1 Kernel entities 

The kernel of ARM is largely inspired from the ObjVlisp model of Cointe and Briot [7, 12], to which 

are added behavioral meta-objects in the line of Ferber [15]. The kernel is therefore built around 

three core structural meta-entities, Entity, StructuralMeta and BehavioralMeta, and a first 

behavioral meta-entity, hereafter called basicBehavioralMeta, which role is to be the behavioral 

meta-entity of all kernel entities, i.e. the three structural meta-entities (“classes”) and itself. We 

have avoided the classical names Object, Class and MetaObject in order to emphasize the fact 

that ARM extends the procedural reflection of ObjVlisp with a more generic model for the reified 

representation of a computational entity from which many different specific representations can be 

developed. 

Accordingly, we will use the word entity instead of object. ARM can be applied to several 

different kinds of base level entities: sequential objects, active objects, reactive objects, components, 

168


etc. To emphasize this genericity, we will use the notation ARM[·] to introduce the fact that ARM 

is rather a generator of reflective kernels for given choices of the kind of base level entities. ARM 

need not be directive but rather liberal in the way it can be extended to apply to specific contexts 

and to implement specific applications. It therefore focuses more on APIs and relationships between 

entities than their actual content. 

The figure 2 puts on the main “inheritance”, “instantiation” and “meta-of” relationships of the 

ARM kernel. These relationships must be understood with a specific semantics in the context of 

ARM, which can have nothing to do with their traditional meaning. Being instance here must 

be understood as “having as structural meta-entity”, while inheritance must be understood as 

extending a structural meta-entity and the “meta-of” relationship as “having as behavioral metaentity”. 

Specific kernels generated from ARM with a given reified representation are responsible 

for giving a precise semantics to these relationships. In a procedural kernel, for example, they 

would take back their traditional meanings. 

The graph of Figure 2 subsumes the one of ObjVlisp. Entity describes the common structure 

and behaviors of entities, while StructuralMeta describes the structure and behaviors common 

to all structural meta entities. Being an itself entity, StructuralMeta inherits from Entity. Being 

itself the first structural meta-entity, it is constructed in such a way that it is its own instance, i.e. 

it possesses the structure and behaviors of a structural meta-entity. 

Adding to the relationships isomorphic to those of ObjVlisp, we have everything that have to 

do with BehavioralMeta. BehavioralMeta is the structural meta-entity for all behavioral metaentities, 

and therefore is an instance of StructuralMeta. Being also an entity, it inherits from 

Entity. The first behavioral meta-entity, basicBehavioralMeta, is instance of BehavioralMeta 

and it is the behavioral meta-entity of all kernel entities, including itself. 

The main flow of events that appear between the three different kinds of entities in order to 

implement the causal connection between the two levels are the following: 

– notification of state changes or other semantically important modifications from the base level 

entity to its behavioral meta-entity allows the latter to construct or refine its model of what is 

currently going on at the base level; 

– request for reflective computations can flow from the base level entity to its behavioral metaentity, 

often to initiate an adaptation phase; 

– requests from the behavioral meta-entity to the base level occur when adaptation are made; 

– adaptation can also lead to modify the structural description of a base level entity, and therefore 

we have events flowing from the behavioral meta-entity to the structural one to implement these 

modifications; 

– accordingly, structural modifications can lead to events flowing from the structural meta-entity 

to the base level object to harmonize the structure of the latter with the description held by 

the former. 

Besides the requests from the behavioral to the structural meta-entities, all other communication 

flows go across level boundaries, and are therefore comparable to the classical procedural 

reflection operations “reify” and “reflect”. Hence, the problem of designation of reified entities 

versus base level entities is posed. This aspect needs a more thorough study with the foundations 

of ARM to which we plan to return in future work. 

3.2 Generalization of the reified representation concept 

The reified representation is central to the metalevel. It is generally decomposed into a structural 

part and a behavioral part. The interest of this decomposition is that the structural part can often 

be shared among several base level entities (aka classes for objects), while the behavioral part, 

which accounts for the run-time state of base level entities, is not sharable by its very nature. 

To get some point of reference, in sequential procedural reflection, the reified representation 

is implemented by classes (well-known) and by behavioral meta-objects. This representation comprises 

a description of the structure of base level entities, by a list of instance variables (with their 

types and other modifiers) and a description of the behavior by a list of methods that can be 

169


applied by the base level entities. The behavioral representation comprises the execution state of 

the base level entities, typically the current continuation and the current environment (given that 

the continuation embodies the environments of all subcomputations waiting still for a result of a 

method call). In distributed procedural reflection, the local behavioral representation comprises 

elements used to manage the concurrency such as the queue of incoming messages and threads. 

Being open to several choices in representation that can even live together in one application, 

ARM is conceptually a generator of specific reflective models, noted ARM[·](RR), given a 

choice RR of reified representation. The kernel defines a set of abstract “classes” for the reified 

representation that impose its constraints. ARM can therefore be concretely viewed as a model 

parameterized by a set of concrete classes derived from the representation abstract classes. 

The design of this set of abstract classes results from an induction process aiming at making 

what transcends different representations appear. In this process, we have currently looked at three 

different forms of representation: one based on a classical procedural approach ARM[·](P), one 

based on a deterministic finite-state automaton approach ARM[·](DFA), and finally one based 

on a statechart approach ARM[·](SC) where it is possible to have several levels of granularity 

in a clear semantic framework. The analysis of these three approaches has lead to the following 

minimal concepts of a reified representation: 

– the set of possible states of the base level entity, 

– a behavior that a base level object can apply to go from one state to another, 

– the set of behaviors that a base level entity can apply, 

– the activation of a base level object, and 

– a possible state for a base level object. 

The first three concepts are comprised in the structural part of the reified representation, while 

the activation concept is the hearth of the behavioral part as it will gather all the information about 

the run-time properties of an entity. The state concept can give us an account for the current state 

of an entity, thus being part of the behavioral part. On the other hand, the set of possible states 

can sometimes be defined in extension as the set of all possible individual states, hence leading to 

see the state concept as part of the structural representation too. 

ARM represents these concepts as the five entities State, StateSpace,Behavior, Behaviors 

and Activation. For the sake of homogeneity, these can be considered as entities of the same kind 

as base level entities, but we do not impose that, as we will see in the ARM for Java platforms 

where they are abstract classes (partially) describing plain Java objects. The figure 4 provides the 

UML model of the kernel entities and reified representation for the ARM for Java platform. 

These concepts map easily to different choices of reified representation. For example, the state 

of an entity can be a vector of instance variable values (for traditional objects), a state in an 

automaton (for the DFA approach), or a (possibly composite) state in the statechart approach. 

The set of possible states can be the cartesian product of set of admissible values (product type) 

for traditional objects, or sets of states defined in extensions for DFA or statcharts. A behavior 

can be seen as a method in traditional objects, but also as a transition in a DFA or a statechart. 

Accordingly, the set of behaviors can be either a method dictionary (procedural reflection) or the 

set of all transitions in the automaton (DFA or statechart). 

3.3 Events of the communication protocol 

The communication protocol between levels implies the use of asynchronous events. Besides events 

that implements more traditional method invocations, ARM also needs events to notify the metalevel 

of changes at the base level. One can imagine two general well-known approaches to notifying 

the metalevel. First, the base level can notify its state changes. Be it a differential description of 

the new state from the current one, this can lead to quite large events if the state of the entity 

comprises a large amount of data. A second approach notifies the actions taken at the base level, 

from which the metalevel model can reconstruct the new state given the current state. 

These two notification modes are equally interesting in our context. The notification of actions 

can use a small amount of data if the parameters are of primitive data types only. On the other 

170


active 

#uniqueOID : String 

+start() 

+run() 

+process(e:Event) 

+publish(e:Event) 

 

ActiveObject 

+publishWithFuture(e:Event) : Future 

+publishWithFutureValue(e:Event) : FutureValue 

Future 

#no : long 

+touch() 

+set() 

1 

0..* 

FutureValue 

+getValue() : Serializable 

+setValue(v:Serializable) 

MethodRequest 

BoundedBuffer 

+isEmpty() : Boolean 

+isFull() : Boolean 

+insert(item:ObjectMessage) 

+remove() : ObjectMessage 

+isProcessable(servant:ActiveObject) : Boolean 

 

1 1 

-futureNo : long 

 

Callable 

+setServant(s:ActiveObject) 

+guard() : Boolean 

+apply() 

javax.jms 

1 

#senderOID : String 

SynchronousMethodRequest 

#destinationOID : String 

ObjectMessage 

(from javax.jms) 

0..* 

Event 


+setProperties(msg:Message) 


Fig.3. Active objects. 

1 

1 

SynchronizedEvent 


 

hand, reconstructing a new state can be computationally intensive in some cases. The notification 

of state changes can be data intensive if it entails the communication of a large amount of data, but 

has a low computational cost. From another point of view, in distributed settings, notification of 

state changes is much more robust to loss of events than action notification. To let users choose the 

most appropriate form of notification for individual entities, ARM provides both a StateEvent 

generic state notification event and an ActionEvent generic action notification event. 

4 A Java implementation of ARM for active objects 

4.1 Asynchronous active objects as base level entities 

A concurrent and distributed declension of ARM is implemented in the Java J2EE platform 

upon the basis of active objects communicating with asynchronous events and synchronizing using 

future values. In fact, the base level computational model upon which ARM for Java is founded 

is borrowed from Nierstrasz’s Hybrid language [33]. Asynchronous active objects (AAO) represent 

the unit of concurrent and distributed computation, around which islands of unshared passive 

objects aggregate. Passive objects cannot communicate directly with objects (passive or active) 

that are not part of their island; they have to use their proprietary active object to do so. The 

implementation is inspired from the design pattern Active Object formalized by Schmidt [37]. 

The figure 3 gives a UML class diagram of our packageactive. The core functionality is implemented 

by the classActiveObject, which is a thread (inherits fromThread) and which implements 

distributed message passing and notification using the Java Message Service (JMS) asynchronous 

communication API. All events used by ARM inherits from the classEvent. An event has a sender 

and a destination; while queued by the receiver, a boolean method isProcessable tells whether 

the event is processable given the current state of the servant object. 

Events can either carry data or activate methods in receivers. Method requests are executable 

events that implement the interface Callable. A callable event has a guard method which tests 

the processability of the event given the state of the servant. The servant is set by setServant 

upon enqueue of the event. When processable, the event become candidate to a dequeue and is 

applied using the method apply. 

171


A method request can be unsynchronized (MethodRequest) or synchronized (Synchronized- 

MethodRequest). Synchronization is implemented using futures or promises [20,25], a well-known 

synchronization method in asynchronous communication. When a synchronized event is published, 

an instance of FutureValue is created to represent the return value (resp. an instance of Future 

representing the return signal, when there is no value but just a synchronization signal to be sent 

back) in the sender. When the event has been processed, the receiver returns the result (resp. the 

signal) to the sender. When the sender tries to access the result (or the signal) using the getValue 

(resp. touch) method, there are two possibilities. If the value (resp. the signal) has already been 

received, the sender gets that value (resp. that signal) and continue its execution. If not received 

yet, it waits for the value (resp. signal) and resumes its execution only when the value arrives. 

Events sent to active objects are queued into the object bounded buffer (class BoundedBuffer). 

The basic behavior of an active object is to repeatedly remove a processable event from its bounded 

buffer, and to process it. When none of the events are processable, or when there is no awaiting 

event at all, the active object becomes dormant until a processable event comes in. 

To send events through JMS, active objects first put them into an instance of javax.jms. 

ObjectMessage and then send them using the JMS API. Communication in JMS is organized in 

topics. The package active uses the topic called "active/Future" to deliver future values (or 

signal) between active objects. Three other JMS topics are introduced to organize the communication 

in ARM: "arm/Entity" for the communication between entities, "arm/SMeta" for the one 

between base level entities and their structural meta-entity, and "arm/BMeta" for the one between 

base level entities and their behavioral meta-entity. 

4.2 ARM for Java kernel 

The figure 4 gives a UML class diagram for the kernel entities and for the representation abstract 

classes of ARM[AAO](·) for Java. Besides the fact that Entity inherits from the class 

ActiveObject of the active package, we can identify relationships already defined in the model. 

Entities are represented by asynchronous active objects. Their main behavior appears in how they 

process incoming events, which is defined by the method process. A structural meta-entity provides 

you with methods to add (addbehavior), delete (deleteBehavior) or look up (lookup) 

behaviors. It also provides you with methods to get the initial state (getInitialState) for an 

instance of the structural meta, as well as a mapping from state events to states (mapToState) of 

their instances. A behavioral meta-entity provides you with a way to add a new base level entity to 

be the meta of (addBaseLevelEntity), and to delete an existing one (deleteBaseLevelEntity). 

Because structural (and behavioral) meta-entities are also entities, they are also represented 

by asynchronous active objects. A bootstrap, implemented by the static method bootstrap of 

StructuralMeta creates the three corresponding entities for the kernel, as well as the basic behavioral 

meta-entity. 

We have also defined a package representation containing the five classes corresponding to 

the representation entities in ARM. These classes are abstract and minimal. Only the essential 

relationships between them are defined; further refinements are deferred to specifically generated 

kernels. Notice that an activation for an entity is obtained by calling the method activate defined 

on the StateSpace of the entity. 

Finally, ARM defines the two abstract classes ActionEvent and StateEvent. An action event 

holds at least the name (the method name or the transition identifier) of the behavior which 

activation led to the notification of the event. 

5 Application to AI robotics 

5.1 Control architecture for AI robotics 

AI robotic control systems are founded on the organization of the three basic primitive functions: 

sense, plan and act [32]. After a long domination from the hierarchical paradigm, where the emphasis 

is put on the creation of an exhaustive model of the environment used by planning, AI 

172


arm 

Entity 

+reifiedEntity : StructuralMeta 

#struturalMetaOID : String 

#behavioralMetaOID : String 

+process(e:Event) 

StructuralMeta 

-reifiedStructuralMeta : StructuralMeta 

#name : String 

#superName : String 

+bootstrap() 

+lookup(name:String) : Behavior 

+getInitialState() : State 

+mapToState(e:StateEvent) : State 

+addBehavior(b:Behavior) 

+deleteBehavior(name:String) 

events 

representation 

StateSpace 

+containsState(s:State) : Boolean 

+isInitial(s:State) : Boolean 

+mapToState(e:StateEvent) : State 

+getInitial() : State 

+activate() : Activation 

Behaviors 

 

ActiveObject 

+lookup(name:String) : Behavior 

+addBehavior(b:Behavior) 

+deleteBehavior(name:String) 

StateEvent ActionEvent 


0..* 


+reifiedBehavioralMeta : StructuralMeta 

+reifiedBasicBehavioralMeta : BehavioralMeta 

+addBaseLevelEntity(entityOID:String, init:State) 

+deleteBaseLevelEntity(entityOID:String) 

0..* 

0..* 


State 

+nextState(e:ActionEvent) : State 

#smetaOID : String 

+getCurrentState() : State 

meta-of 

0..* 

Activation 

+invokeBehavior(name:String, args:Serializable) 

Behavior 

+invoke(s:State, args:Serializable) : State 

Fig.4. Kernel and representation entities of ARM. 

robotics has been faced to the difficulty of creating such a complete model and to plan actions 

from such complex data structures within strict deadlines to cope with the real-time nature of 

robot operations. 

Using lessons from ethology, Brooks [9] has proposed the reactive paradigm, which abandons 

planning in favor of very simple reflexes associating directly a reaction to each possible perceptions 

of the robot, without any memory of past perceptions and reactions. In this paradigm, the intelligence 

of the robot is emerging from the combination of a possibly large number of elementary 

reflexes. The absence of memory is grounded in Gibson’s argument saying that “the world is its 

own best representation” [32, quoted in] which should be accessed only through perception. The 

173 

0..*


S 

E 

N 

S 

O 

R 

S 

B 

I 

level 1 behaviors 

1 2 

A 

level 0 behaviors 

Fig.5. Behaviors and subsumption: given perceptions, B can Inhibit the input 1 of A; similarly C can 

Suppress (replace) the output 2 of A. 

reactive paradigm leads to the design of robots capable to react very rapidly to stimuli coming from 

their ecological niche. Reflex behaviors are implemented using three types of behavior modules: 

1. perceptors, which role consists in reading sensors and producing stimuli (or the absence thereof) 

looked for by the robot (e.g. a spot of light in an image), 

2. reactors, which role consists in computing the parameters of reactions given the actual stimuli 

and their intensity, and 

3. actuators, which role is to transform the reaction parameters into orders to the physical actuators 

of the robot. 

When composed, higher-level behaviors can inhibit lower-level behaviors, in much the same 

way our intelligent behaviors most of the time inhibit our animal ones. That’s what is called 

subsumption in the reactive paradigm. To do that, modules are added to connect perceptors, 

reactors and actuators, which allow us to inhibit stimuli from perceptors or reaction parameters 

computed by rectors. The figure 5 illustrate these possibilities. 

The successes of the reactive paradigm in the beginning of the nineties have given the first 

hope for operational situated intelligent robots. Unfortunately, the lack of a model of the robot 

environment and even more of planning soon appeared as a position far too extreme. Reactive 

control can become quite complex when trying to cope with some abnormal situations (looping, 

for instance), where planning could provide an answer. The emergent behavior of a large reactive 

robot can be very difficult to predict or to alter. Hybrid deliberative/reactive architectures have 

been introduced to get the best of both worlds. A reactive level takes care of robot reflexes in order 

to react in real-time to events from the environment, while a deliberative level can run in parallel 

to construct a model of the environment and to plan for future actions or to repair current faulty 

actions (such as looping). One possibility is to have the deliberative level producing new reactive 

programs to be used for a while at the reactive level until some goal has been reached or some 

abnormal situation is detected, and then to change for another reactive program. 

5.2 A globally asynchronous but locally synchronous model 

In our MAAM project, we aim at using reflection and ARM to implement the reactive part at 

the base level and the deliberative part at the metalevel. To do so, we have to provide a real-time 

computational model for the base level entities of ARM. Generally speaking, robotic systems are 

examples of the family of reactive systems. Reactive systems are those which main function is to 

react continuously to events occuring in their environment in order to produce reactions, often in 

the form of orders executed by actuators to act upon their environment. This distinguishes them 

from more traditional transformational systems, which compute outputs from inputs. Furthermore, 

reactive systems must cope with an environment which cannot wait, and they are generally intended 

to be deterministic. This distinguishes them from more general interactive systems. Typical reactive 

systems are plant control systems. 

One of the most interesting approach to program reactive systems is the synchronous approach 

[18], which is based on a few simple hypothesis: 

174 

C 

S 

A 

C 

T 

U 

A 

T 

O 

R 

S


– events from the environment occur at discrete time instants, 

– at each instant, the system computes reactions from all of the events perceived at that instant, 

– the time to compute reactions is small compared to the time between two successive discrete 

instants, and 

– reactions can lead to the emission of events, which are perceived instantaneously by all reactive 

processes at the next discrete time instant, along with environmental events. 

The major advantages of the synchronous approach to reactive programming is the expressive 

power of synchronous parallel composition, the potential for efficient implementation, and the 

availability of formal verification methods [19]. The appropriateness of the synchronous programming 

approach to robot control justifies its choice for MAAM atoms. However, if synchronous 

programming is well adapted to the control of individual atoms, Halbwachs and Baghdadi [19] 

note that it is not so well adapted to the case of distributed embedded systems where the intrinsic 

asynchronism must necessarily be taken into account. Currently, researchers are looking at globally 

asynchronous but locally synchronous (GALS) architectures to cope with distributed embedded 

systems. In such architectures, local synchronous processes are composed with each others using 

asynchronous communication [19]. 

We have chosen the GALS approach for our MAAM atoms. Unfornatunately, if the synchronous 

approach matches very well the reactive part of MAAM atoms, it is not really appropriate to 

implement the more AI-oriented deliberative functions. Hence, the GALS model we have chosen 

for MAAM is a composition of both asynchronous active objects and synchronous reactive ones, 

composed using a publish/subscribe communication model. Schmidt and O’Ryan [36] have shown 

that publish/subscribe communication can have a level of performance that is compatible with 

distributed embedded programming, therefore justifying our choice. 

The mix of active and reactive objects within one system raises the issue of synchronization 

mechanisms between both kind of entities. In the ARM for Java platform, we have used futures to 

implement synchronization between the asynchronous active objects. The mode of synchronization 

is not readily adoptable for reactive objects. Obviously, the waiting entailed by the traditional 

semantics of the touch and getValue operations is not appropriate for reactive objects given 

their real-time constraints. To solve the problem, we have simply noticed that active wait, which 

is usually considered as a bad practice in concurrent programming, is in fact the usual practice 

in real-time systems. Hence, we have adopted an active-wait semantics for reactive objects when 

synchronizing using futures. Futures are seen as any other stimuli upon which behavior modules 

can be fired (waiting). But if at some synchronous reactive cycle an awaited future is not available, 

other behaviors can continue their execution to keep up with the real-time deadlines while waiting 

for synchronization on other behaviors. 

5.3 A Java implementation of ARM[GALS] 

Most implementations of the synchronous approach re tightly integrated with synchronous languages, 

which are not appropriate to program robot deliberative functions. Few synchronous systems 

exist to date in Java 1 , the language we have chosen for MAAM as a compromise between the 

real-time nature of the reactive level and the AI-bound nature of the deliberative level. We have 

therefore chosen to implement a minimal extension of ouractive package to introduce synchronous 

reactive objects with their semantics of synchronization on futures. 

The figure 6 shows the new class diagram of the active package. In such an object-oriented 

settings, it would have been interesting to derive a class ReactiveObject from ActiveObject. 

Unfortunately, this would have caused difficulties when inheriting. Decoupling active and reactive 

behaviors would naturally lead to two classes in the ARM kernel: Entity and ReactiveEntity. 

Because of the single inheritance of Java, it is hard to satisfactorily implement theReactiveEntity 

class because it would have to inherit both from Entity and from ReactiveObject. We have 

therefore chosen to keep just one class ActiveObject with two modes of operation chosen upon 

instantiation: synchronous and asynchronous. 

1 SugarCubes [43] is a notable exception, but its implementation is too resource consuming for the MAAM 

atom light-weight electronic. 

175


active 

#operatingMode : int 

#uniqueOID : String 

+start() 

+run() 

+runAsynchronous() 

+runSynchronous() 

 

ActiveObject 

+processAsynchronous(e:Event) 

+processSynchronous(es:Event[]) 

+publish(e:Event) 

+publishWithFuture(e:Event) : Future 

+publishWithFutureValue(e:Event) : FutureValue 

1 

Future 

#no : long 

+touch() 

+set() 

SynchronousFuture 

+touch() 

+set() 

0..* 

FutureValue 



BoundedBuffer 

+isEmpty() : Boolean 

+isFull() : Boolean 

+insert(item:ObjectMessage) 

+remove() : ObjectMessage 

+removeAll() : ObjectMessage[] 

FutureEvent 

+getNo() : long 


SynchronousFutureValue 

+touch() 

+set() 

1 

0..* 

1 



MethodRequest 

javax.jms 

#senderOID : String 


 


#destinationOID : String 

ObjectMessage 

(from javax.jms) 

0..* 

 

Clock 

Event 


+setProperties(msg:Message) 

 

Callable 

+setServant(s:ActiveObject) 

+guard() : Boolean 

+apply() 

Fig.6. Reactive objects. 

1 

1 

SynchronizedEvent 


SynchronousMethodRequest 


 

The asynchronous mode of operation is the genuine ARM for Java behavior described in the 

preceding section. The synchronous mode is the one of reactive objects. In this mode, a clock 

object (class Clock) rythms the execution of reactive object threads. At each given period of 

time, the clock releases all the threads waiting. When released, the threads execute one reactive 

cycle, which consists in taking all events waiting in their bounded buffer and to process them 

according to their reactive behavior. When the processing is done, the threads put themselves on 

a wait for the next release signal from the clock. Futures are now considered as any other events 

for reactive objects, thus instance of the class FutureEvent. The classes SynchronousFuture and 

SynchronousFutureValue implement the active-wait semantics of futures for the synchronous 

mode of operation of reactive objects. Active objects keep the traditional semantics with Future 

and FutureValue 

5.4 Hybrid reactive/deliberative model 

In our MAAM atoms, robot control is defined as a combination of reactive schemas, themselves 

being sets of perceptor, reactor and actuator modules. From a programmer point of view, we have 

implemented a complete reactive framework under ARM[GALS] for Java platform, which class 

diagram appears in Figure 8. The robot programmer has only to: 

1. design his/her reactive schemas, taking possible subsumptions into account, 

2. create the corresponding modules with classes inheriting from our framework classes, 

3. create the classes for signals among modules by inheriting from our class Signal, and 

4. create a class of reactive object, say Robot, inheriting from our class AbstractRobot, after 

which reactive behavior instances will have to be registered (using addBehaviorModule, 

addConnector, . . . ). 

To organize the reactive behaviors, we propose to have reactive schemas (Schema) composed of 

reactive modules (ReactiveModule), which themselves comprise behavioral modules (Behavior- 

Module). A reactive schema represents a logical function in the robot; it can be the basis for 

176 

1 

1


active 

arm 

reactiveframe 

ActiveObject 

#modules : Hashtable 

#schedule : Vector 

#signalsIn : Vector 

#signalsOut : Vector 

Schema 

#externalSignals : Vector 

+addReactiveModule(m:ReactiveModule) 

+addExternalSignal(s:Signal) 

+setScheduling(schedule:Vector) 

+launch() 

+inhibit() 

Entity BehavioralMeta MethodRequest 

ReactiveModule 

+checkSchedulable(genSigs:Vector, connSigs:Vector) : Boolean 

+react() 

connector 

1 

1..* 

BehaviorModule 

#handlers : Vector 

+addHandler(h:Handler) 

+react() 

Perceptor 

Connector 

-signal : Signal 

+react() 

Inhibitor 

1 

1..* 

Signal 


#data : Object 

+set(data:Object) 

+getData() : Object 

SignalModule 

Reactor Actuator 

+react() 

Derivator 

Suppressor 

+react() 

1..* 

1 

1 

1 

metareactive 

reaction 

AbstractRobot 

#signals : Hashtable 

+createSignal(name:String) 

+addSchema(s:Schema) 

+setScheduling(schedule:Vector) 

+processSynchronous(es:Event[]) 

+handle() : Object 

1 

Handler 

+conditionsAreChecked() : Boolean 

+guard(response:Object) : Boolean 

+react() 

MetaRobot 

SetScheduling 

ChangeModule 

SignalHandler 

#conditions : Condition 

1 

Scheduler 

#signals : Hashtable 

#schemas : Hashtable 

#schedule : Vector 

+createSignal(n:String) 

+addSchema(s:Schema) 

+buildScheduling() : Vector 

+conditionsAreChecked() : Boolean 

1..* 

Condition 

#conditions : Vector 

#notConditions : Vector 

+addSignal(s:Signal) 

+addNotSignal(s:Signal) 

+check() 

1 

+areChecked() : Boolean 

PHandler 

RHandler AHandler 

Fig.7. Reactive framework under ARM[GALS] for Java. 

adaptation by dynamic addition or subtraction of schemas in the robot reactive program. Behavior 

modules can be perceptors (Perceptor), reactors (Reactor) and actuators (Actuator). 

Schemas and behavior modules can be connected to each other using connectors (Connector), 

which comprise inhibitors (Inhibitor), suppressors (Suppressor) and derivators (Derivator). A 

schema must form an directed acyclic graph. The scheduling of behavior modules is implemented 

by a topological sort of that graph. Behavior modules in schemas are partially scheduled up to the 

connections to other schemas. The complete schedule of a robot instance is made when all schemas 

are known. When actually running, the robot simply executes all of its behavior modules, in turn, 

as scheduled within one cycle of synchronous reaction. A complete rescheduling is done when one 

or more schemas are added or subtracted by the robot metalevel. The deliberative part of the 

framework is currently implemented by one abstract class MetaRobot, which main purpose is to 

do the scheduling of its base level robot. The class Scheduler implements the above scheduling 

algorithm. 

The figure 8 shows how our deliberative/reactive framework integrates with ARM[GALS]. The 

classAbstractRobot inherits fromEntity, using the synchronous operating mode, from which base 

level robot entities are created (e.g. robot1 and robot2). A class BMetaRobot defines behavioral 

177


Entity StructuralMeta 

META 

BASE 


basicBehavioralMeta 

bmrobot1 

BMetaRobot 

AbstractRobot 

bmrobot2 

inherits−from 

instance−of 

meta−of 

robot1 robot2 

Fig.8. MAAM robots under ARM[GALS] for Java. 

meta-entities for robot (e.g. bmrobot1 and bmrobot2). The adaptation protocol put in place by 

AbstractRobot and BMetaRobot proceeds as follows: 

1. at each synchronous cycle, notifications from the base level robots are sent to the behavioral 

meta, 

2. the behavioral meta integrates these notifications into its reified model of the base level; 

this possibly fires an adaptation request sent to the base level as an event representing 

setScheduling or changeModule method request (the time needed to execute this adaptation 

must stay within the duration of a cycle to match the synchronous hypothesis), 

3. the adaptation request is processed by the base level. 

The adaptation request cannot be processed as other events in the synchronous processing 

cycle. Modifications are better handled when the base level is in some kind of renewal state, which 

needs the lowest possible amount of work to do the adaptation. For synchronous programs, this 

can either be at the beginning or at the end of a cycle. Depending on the priority to be given to 

adaptation compared to meeting the deadlines, the programmer can chose either policies. 

6 Related work 

In parallel with the industrial adoption of publish/subscribe communication for distributed programming, 

as the JMS API testifies, some work have introduced event-based communication in 

reflective operating systems and middleware [4,3, 24,44] and more generally in systems trying to 

implement forms of dynamic adaptability [27]. We should also mention work in computer-human 

interaction, like the MVC, as well as the Observer and State design patterns that have popularized 

the concept and the use of notification in general. This work, as well as their counterpart in 

reflection [6, 16] have inspired our work on ARM. 

Among reflective languages, LEAD++ [1] proposes an approach with tends towards ARM 

ideas, without breaking with procedural reflection though. The use of events has also inspired 

Dynascope [42], a supervision system, which Sosi˘c read out as reflective. One can see in this 

system a precursor of the Java Platform Debugger Architecture (JPDA) [23]. MetaXa [17] uses 

events to reflect upon a Java-like virtual machine, but stays close to procedural reflection. 

In object-oriented concurrent and distributed programming, most of the reflective languages 

restrict themselves to local reflection where the metaobject can be a processor for the base level 

(see [8] for a review of this wide area). Other systems have retricted themselves to the reification 

of very specific aspects of their implementation, such as stubs and proxies, upon which reflective 

computations can be locally implemented. All of these sticks to procedural reflection. 

The actor and agent research community has identified and begins to explore ideas similar to 

the ones developed in ARM. Without sharing the inspiration for agents, ARM can clearly share 

much of the implementation ideas with that area. Very few papers build bridges between reflection 

and control theory, Pii Lunau offering a notable exception [26], yet taking a procedural point of 

view. 

178


The synchronous approach to reactive systes is generally associated with synchronous languages, 

like Esterel. The objective of a synchronous language is to offer a way to describe how events must 

be processed during a cycle of the logical clock. Several of these languages use the logical concurrent 

composition between computational activities an event emission. Robotic control architectures, like 

the deliberative/reactive ones pursue essentially the same goals. This is why we have not chosen 

to implement our base level entities using a synchronous language or system, like Rejo [43]. 

Arkin’s book [2] is the reference in the area of reactive architectures in AI robotics. We did 

not find a reference implementation of these ideas in Java. In AI robotics, there is a tendency for 

everyone, that we unfortunately had to pursue, to reimplement his own framework. However, most 

of the work we had access to use a manual scheduling of behavior modules. 

Halstead has proposed futures as a synchronization abstraction in MultiLisp [20], which has 

then been improved by Liskov and Shrira with promises [25]. Halbwachs and Baghdadi [19] propose 

to emulate different synchronization schemes in the synchronous approach, something we actually 

do with our implementation of futures for synchronous reactive systems. Caromel and Roudier 

[10] have proposed a reactive extension to the Eiffel// language, but they use an asynchronous 

approach to reactive systems borrowed from the Electre asynchronous reactive language. 

7 Conclusion 

ARM[·](·) is a new generic reflection model that we have argued in this paper to be much better 

suited to address the challenges of today’s distributed and embedded systems. ARM is inspired 

from the ObjVlisp model to which behavioral meta entities are added. However, the traditional 

language processor role of the metalevel is abandonned in favor of a much more general role 

of model construction and controlled adaptation of the base level. The traditional procedural 

reified representation is also traded for the much more general concept of reification model, where 

incompleteness, fuzziness and probabilistic account of the base level can be used to capture the 

necessary properties of the base level to enable the wide-range of reflective capabilities needed in 

distributed and embedded systems. 

ARM has been developed and applied to a modular robotics project called MAAM, where 

the physical reconfigurability of the robots has to be paralleled by an equivalent software reconfigurability. 

To that end, we have designed and implemented the ARM[GALS] for Java platform. 

This platform uses a globally asynchronous but locally synchronous approach to the design of distributed 

embedded systems. In our platform, asynchronous active objects mesh with synchronous 

reactive objects to implement a hybrid deliberative/reactive framework typical in AI robotics. This 

implementation proposes to use futures for synchronization in GALS systems, a premiere to our 

knowledge. 

Numerous perspectives are open by this work. Asynchronous reflection poses a large number of 

profound questions, such as the possibilities offered by new forms of reified representations, and the 

relationship between the kinds of adaptation and the required level of precision, synchronization, 

fault-tolerance and causality that must be imposed on events notifying state changes in the base 

level to the metalevel. Another important issue is the marriage of control theory and reflection 

that must be done to keep away from undesirable adaptation policies which would do nothing but 

repeatedly adapt the system to rapidly varying level of available physical resources for example. 

IBM has launched the autonomic computing initiative where such issues have a deep impact. 

8 Acknowledgements 

Simon Denier, student at the INSA of Rennes, has contributed to this work during his summer stay 

in 2002 and then during a semester research period in 2003. The MAAM project, led by Dominique 

Duhaut from the Université de Bretagne sud, is funded by the French CNRS under the ROBEA 

program. 

179


References 

1. N. Amano and T. Watanabe. An Approach for Constructing Dynamically Adaptable Component- 

Based Software Systems using LEAD++. In Cazzola, Stroud, and Tisato, eds, Elec. Proceedings of the 

OOPSLA’99 Workshop on Object-Oriented Reflection and Software Engineering, OORaSE’99, pages 

1–16, 1999. 

2. R. Arkin. Behavior-Based Robotics. MIT Press, 1998. 

3. G.S. Blair, A. Andersen, L. Blair, G. Coulson, and D. Sánchez. Supporting Dynamic QoS Management 

Functions in a Reflective Middleware Platform. IEE Proceedings — Software, 147(1):13–21, February 

2000. 

4. G.S. Blair, G. Coulson, P. Robin, and M. Papathomas. An Architecture for Next Generation Middleware. 

In Proceedings of the IFIP International Conference on Distributed Systems Platforms and 

Open Distributed Processing, Middleware’98. IFIP, Springer-Verlag, 1998. 

5. D.G. Bobrow, R.P. Gabriel, and J.L. White. CLOS in Context — The Shape of the Design Space. 

In A. Paepcke, editor, Object-Oriented Programming: the CLOS Perspective, chapter 2, pages 29–61. 

MIT Press, 1993. 

6. M. Braux and J. Noyé. Changement dynamique de comportement par composition de schmas de 

conception. In J. Malenfant and R. Rousseau, editors, Proceedings of “Langages et Modèles à Objets, 

LMO’99”, page ?? Hermès, 1999. 

7. J.-P. Briot and P. Cointe. A Uniform Model for Object-Oriented Languages Using the Class Abstraction. 

In Proceedings of the International Joint Conference on Artificial Intelligence, IJCAI’87, pages 

40–43, 1987. 

8. J.-P. Briot, R. Guerraoui, and K.P. Lohr. Concurrency and Distribution in Object-Oriented Programming. 

ACM Computing Surveys, 30(3):291–329, September 1998. 

9. R. A. Brooks. A Robust Layered Control System for a Mobile Robot. IEEE Journal of Robotics and 

Automation, 2(1):14–23, March 1986. 

10. D. Caromel and Y. Roudier. Reactive Programming in Eiffel//. In J.-P. Briot, J. M. Geib, and 

A. Yonezawa, editors, Proceedings of the Conference on Object-Based Parallel and Distributed Computation, 

pages 125–147. Springer-Verlag, 1996. 

11. S. Chiba and T. Masuda. Designing an Extensible Distributed Language with a Meta-Level Architecture. 

In Proceedings of ECOOP’93, number 707 in Lecture Notes in Computer Science, pages 482–501. 

Springer-Verlag, July 1993. 

12. P. Cointe. Metaclasses are First Class: the ObjVLisp Model. Proceedings of OOPSLA’87, ACM Sigplan 

Notices, 22(12):156–167, December 1987. 

13. O. Danvy and K. Malmkjaer. Intensions and Extensions in a Reflective Tower. In Proceedings of the 

ACM Symposium on Lisp and Functional Programming, LFP’88, pages 327–341. ACM, 1988. 

14. J. des Rivières and B. C. Smith. The implementation of procedurally reflective languages. In Proceedings 

of the ACM Symposium on Lisp and Functional Programming, LFP’84, pages 331–347. ACM, 

August 1984. 

15. J. Ferber. Computational Reflection in Class Based Object-Oriented Languages. In Proceedings of 

OOPSLA’89, ACM Sigplan Notices, volume 24, pages 317–326, October 1989. 

16. L.L Ferreira and C.M.F. Rubira. Reflective Design Patterns to Implement Fault Tolerance. In J.-C. 

Fabre and S. Chiba, editors, Proceedings of the OOPSLA’98 Workshop on Reflective Programming in 

C++ and Java, pages 81–85. UTCCP Report 98-4, U. of Tsukuba, Center for Computational Physics, 

October 1998. 

17. M. Golm and J. Kleinöder. MetaXa and the Future of Reflection. In J.-C. Fabre and S. Chiba, editors, 

Proceedings of the OOPSLA’98 Workshop on Reflective Programming in C++ and Java, pages 1–5. 

UTCCP Report 98-4, University of Tsukuba, Center for Computational Physics, October 1998. 

18. N. Halbwachs. Synchronous Programming of Reactive Systems – A Tutorial and Commented Bibliography. 

In A. J. Hu and M. Y. Vardi, editors, Proceedings of Computer Aided Verification, 10th 

International Conference, CAV’98, number 1427 in LNCS, pages 1–16. Springer, 1998. 

19. N. Halbwachs and S. Baghdadi. Synchronous Modelling of Asynchronous Systems. In A. L. 

Sangiovanni-Vincentelli and J. Sifakis, editors, Proceedings of Embedded Software, Second International 

Conference, EMSOFT 2002, number 2491 in LNCS, pages 240–251. Springer, October 2002. 

20. R. H. Halstead, Jr. Multilisp: A Language for Concurrent Symbolic Computation. ACM Transaction 

on Programming Languages and Systems, 7(4):501–538, October 1985. 

21. Y. Honda and M. Tokoro. Soft Real-Time Programming through Reflection. In A. Yonezawa and 

B. Smith, editors, Proceedings of the International Workshop on New Models for Software Architecture 

’92, Reflection and Meta-Level Architectures, pages 12–23. RISE (Japan), ACM Sigplan, JSSST, IPSJ, 

November 1992. 

180


22. Y. Ichisugi, S. Matsuoka, and A. Yonezawa. RbCl: A Reflective Object-Oriented Concurrent Language 

without a Run-Time Kernel. In A. Yonezawa and B. Smith, editors, Proceedings of the International 

Workshop on New Models for Software Architecture ’92, Reflection and Meta-Level Architectures, pages 

24–35. RISE (Japan), ACM Sigplan, JSSST, IPSJ, November 1992. 

23. Sun Microsystems, Java Platform Debugger Architecture Home Page. 

http://java.sun.com/products/jpda, 2002. SDK release 1.4. 

24. F. Kon, M. Romàn, P. Liu, J. Mao, T. Yamane, L.C. Magalh aes, and R.H. Campbell. Monitoring, 

Security, and Dynamic Configuration with the dynamicTAO Reflective ORB. In J. Sventek and 

G. Coulson, editors, Proceedings of the IFIP International Conference on Distributed Systems Platforms 

and Open Distributed Processing, Middleware 2000, number 1795 in LNCS, pages 121–143. Springer- 

Verlag, April 2000. 

25. B. Liskov and L. Shrira. Promises: linguistic support for efficient asynchronous procedure calls in 

distributed systems. In Proceedings of the ACM SIGPLAN 1988 conference on Programming Language 

design and Implementation, PLDI’88, pages 260–267. ACM Press, 1988. 

26. C.P. Lunau. A Reflective Architecture for Process Control Applications. In Proceedings of ECOOP’97, 

number 1241 in LNCS, pages 170–189. Springer-Verlag, June 1997. 

27. J. Malenfant, M.-T. Segarra, and F. André. Dynamic Adaptability: the MolèNE Experiment. In 

A. Yonezawa, editor, Proceedings of the Third International Conference on Metalevel Architectures 

and Separation of Crosscutting Concerns, Reflection 2001, volume 2192 of LNCS, pages 110–117. 

Springer-Verlag, September 2001. 

28. H. Masuhara, S. Matsuoka, T. Watanabe, and A. Yonezawa. Object-Oriented Concurrent Reflective 

Languages can be Implemented Efficiently. Proceedings OOPSLA ’92, ACM SIGPLAN Notices, 

27(10):127–144, October 1992. 

29. H. Masuhara, S. Matsuoka, and A. Yonezawa. Implementing Parallel Language Constructs using a 

Reflective Object-Oriented Language. In G. Kiczales, editor, Proceedings of the First International 

Conference on Reflection, Reflection’96, pages 79–92. Xerox PARC, 1996. 

30. S. Matsuoka, T. Watanabe, and A. Yonezewa. Hybrid Group Reflective Architecture for Object- 

Oriented Reflective Programming. In Proceedings of ECOOP’91, number 512 in LNCS, pages 231–250. 

Springer-Verlag, July 1991. 

31. J. McAffer. Meta-Level Programming with CodA. In Proceedings of ECOOP’95, number 952 in LNCS, 

pages 190–214. Springer-Verlag, August 1995. 

32. R.R. Murphy. Introduction to AI Robotics. MIT Press, 2000. 

33. O. Nierstrasz. Active Objects in Hybrid. Proceedings of OOPSLA’87, ACM Sigplan Notices, 

22(12):243–253, December 1987. 

34. H. Ogawa, K. Shimura, S. Matsuoka, F. Maruyama, Y. Sohda, and Y. Kimura. OpenJIT: An Open- 

Ended, Reflective JIT Compiler Framework for Java. In E. Bertino, editor, Proceedings of ECOOP 

2000, number 1850 in LNCS, pages 362–387. AITO, Springer-Verlag, 2000. 

35. H. Okamura, Y. Ishikawa, and M. Tokoro. AL-1/D: A Distributed Programming System with Multi- 

Model Reflection Framework. In A. Yonezawa and B. Smith, editors, Proceedings of the International 

Workshop on New Models for Software Architecture ’92, Reflection and Meta-Level Architectures, pages 

36–47. RISE (Japan), ACM Sigplan, JSSST, IPSJ, November 1992. 

36. D. C. Schmidt and C. O’Ryan. Patterns and Performance of Distributed Real-time and Embedded 

Publisher/Subscriber Architectures. Journal of Systems and Software, 66(3):213–223, June 2003. 

37. D.C. Schmidt, M. Stal, H. Rohnert, and F. Buschmann. Pattern-Oriented Software Architecture: 

Patterns for Concurrent and Networked Objects. Wiley & Sons, 2000. 

38. W.-M. Shen, B. Salemi, and P. Will. Hormone-Inspired Adaptative Communication and Distributed 

Control for CONRO Self-Reconfigurable Robots. In IEEE Transactions on Robotics and Automation, 

October 2002. 

39. B.C. Smith. Reflection and Semantics in Lisp. In Proceedings of the 14th Annual ACM Symposium on 

Principles of Programming Languages, pages 23–35. ACM, January 1984. 

40. B.C. Smith. Discussion session. First Workshop on Reflection and Metalevel Architectures in Object- 

Oriented Programming, OOPSLA/ECOOP’90, October 1990. 

41. B.C. Smith. What do you mean, meta? In J.-P. Briot, B. Foote, G. Kiczales, M.H. Ibrahim, S. Matsuoka, 

and T. Watanabe, editors, Informal Proceedings of the First Workshop on Reflection and Metalevel 

Architectures in Object-Oriented Programming, OOPSLA/ECOOP’90, October 1990. 

42. R. Sosi˘c. Introspective computer systems. Electrotechnical Review, 59(5):292–298, December 1992. 

43. J.-F. Susini. Implementation de l’approche reactive en Java : les SugarCubes v2. In Actes de 

Modélisation des Systèmes Réactifs, MSR’99. Hermès, 1999. 

44. N. Wang, M. Kircher, and D.C. Schmidt. Towards a Reflective Middleware Framework for QoS-Enabled 

CORBA Component Model Applications. In Proceedings of the Reflective Middleware Workshop, RM 

2000, 2000. Electronic proceedings. 

181


45. T. Watanabe and A. Yonezawa. Reflection in an Object-Oriented Concurrent Language. Proceedings 

of OOPSLA’88, ACM Sigplan Notices, 23(11):306–315, November 1988. 

46. T. Watanabe and A. Yonezawa. An Actor-Based Metalevel Architecture for Group-Wide Reflection. 

In J.-P. Briot, B. Foote, G. Kiczales, M.H. Ibrahim, S. Matsuoka, and T. Watanabe, editors, Informal 

Proceedings of the First Workshop on Reflection and Metalevel Architectures in Object-Oriented 

Programming, OOPSLA/ECOOP’90, October 1990. 

47. Y. Yokote. The Apertos Reflective Operating System: The Concept and its Implementation. Proceedings 

OOPSLA’92, ACM SIGPLAN Notices, 27(10):414–434, October 1992. 

48. E. Yoshida, S. Murata, S. Kokaji, A. Kamimura, K. Tomita, and H. Kurokawa. Get Back In Shape! A 

Hardware Prototype Self-Reconfigurable Modular Microrobot that Uses Shape Memory Alloy. IEEE 

Robotics & Automation Magazine, 9(4):54–60, 2002. 

182


¦��£�¥��¡�� 

¢¡¤£¦¥¨§¨©��¢¡��§�©��£¦��¡¤��§�£¦�� 

�§��¡�¥��§¨ ��©��¡� ��§�� 

�� 

��¢�� 

��¨�� 

�� 

�� 

�� 

�¤�� 

�� 

�� 

�� 

�� 

��¨��¨��¨�� 

��¢��¦��¦�� 

��¢��¦�� 

��¨�� 

��¨�� 

��¢�� 

��¢�� 

��¢��¨��¤�� 

��¤�� 

�� 

� 

�� 

� �� 

�� 

�� 

� 

�� 

� �� 

�� 

�� 

��¢�� 

��¨��¦�� 

��¢��¢�� 

�� 

�� 

� �� 

�� 

�� 

�� 

��¢�� 

� �� 

�� 

�� 

�� 

��¦��¢�� 

�� 

�� 

��¤��¨�� 

183 

��¨��¦�� 

��¨�� 

��¨�� 

�� 

�� 

� �� 

��¦�� 

��¨�� 

� �� 

�� 

�� 

�� 

��¤�� 

�� 

�� 

� � �� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

��¦�� 

�� 

�� ¢�� 

�


� ��¤�� 

�� 

��¢�� 

��¨�� 

��¦��¢�� 

�� 

� �� 

�� 

��¤�� 

��¨�� 

�� 

� �� 

�� 

��¨�� 

� �� 

�� 

��¨��¨��¢�� 

�� 

� �� 

�� 

�� 

��¨�� 

� �� 

�� 

��¦�� 

� �� 

��¢��¤��¢�� 

�� 

��¤�� 

� ��¤�� 

� � � �� 

�� 

�� 

�� 

��¢��¨�� 

�� 

��¨�� 

�� 

� �� ¤�� 

�� 

� �� ¢�� 

��¤�� 

�� 

��¨�� 

�� 

��¨�� 

�� 

��¨�� 

� �� 

��¤�� 

�� 

�� 

�� 

��¨��¦�� 

�� 

�� 

�� 

�� 

��¤�� 

�¤�� 

��¨�� 

� �� 

�� 

�� 

��¤�� 

�� 

��¢�� 

�� 

�� 

�� 

184 

Complexity 

of Agent 

Architecture 

deliberative 

reactive 

Individual Intelligence 

(direct communication) 

Collective Intelligence 

(swarm intelligence, 

indirect communication) 

Number of Agents 

� �� 

�� 

�� 

�� 

�� 

�� 

�� 

� �� ¢��¤�� 

� 

� � 

��¢�� 

��¦�� 

��¨�� 

�� 

�� 

� � 

�� 

�� 

�� 

��¤�� 

�� 

� �� 

�� 

��¨�� 

��¨��¤�� 

� 

��¨�� 

� � � �� 

�� 

� 

� �� 

�� 

��¦��¨��¦��¨�� 

�� 

��¨��¨�� 

�� 

�� 

�� 

��¦�� 

��¦�� 

�� 

� 

�� 

� �� 

�� 

�� 

� 

��¨��¤��¨�� 

��¦��¦�� 

��¨��¤�� 

��


�� 

�� 

��¨�� 

��¦��¦�� 

��¦��¨�� 

� 

��¤��¨��¤�� 

�� 

�� 

� �� 

�� 

� � � �� 

�� 

� �� 

�� 

�� 

� �� 

�� 

� � ��¤�� 

��¢�� 

�� 

��¦�� 

� �� 

�� 

�� 

��¤�� 

�� 

�� 

� 

�� 

�� 

��¦�� 

��¤�¦��¦�� 

��¤�� 

�� 

�� 

�¨�� 

�¤�� 

�� 

� 

�� 

�� 

� 

�� 

�� 

�� 

� 

�� 

�¤�� 

��¢��¤�� 

��¢��¨�� 

� 

�� 

�� 

�� 

��¤��¢�� 

��¢�� 

�� 

�� 

� �� 

�� 

� � 

��¦�� 

�� 

�� 

�� 

�� 

��¨�� 

�� 

�� 

� �� 

185 

left attractive 

signal 

¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡ 

£¢£¢£¢£¢£¢£¢£¢£¢£ 

£¢£¢£¢£¢£¢£¢£¢£¢£ 

¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡ 

paralyzed 

robot 

¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡ 

£¢£¢£¢£¢£¢£¢£¢£¢£ 

£¢£¢£¢£¢£¢£¢£¢£¢£ 

¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡ 

¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡ 

£¢£¢£¢£¢£¢£¢£¢£¢£ 

£¢£¢£¢£¢£¢£¢£¢£¢£ 

¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡¢¡ 

right attractive 

signal 

carriage 

� ��¤�� 

�� 

�� 

� �� 

�� 

��¢��¤�� 

�� 

�� 

��¦��¨�� 

�� 

� �� 

��¤�� 

�� 

��¢��¢��¦�� 

��¨�� 

�� 

� �� ¦�� 

��¦�� 

�� 

�� 

� 

��¦��¤�� 

��¤�� 

�� 

�� 

�� 

�� ¢�� 

�� 

�� 

��¦��¨�� 

��¦�� 

��¨��¨�� 

�� 

� �� 

�� 

� �� 

�¤��¤��¤�� 

�� ¥¤ �� 

�� 

�� 

��¨��¤��¢�� 

��¤�� 

�� 

� �� 

�� 

�� 

��¨��¤�� 

� �� 

��¨��¢��

Stopped 

destination 

reached 

destination 

not reached 

Emission of two attractive 

signals (left and right) 

wrong 

direction 

(deviation) 

Update values to emit 

(left and right side) 

updated 

�� 

� �� 

�� 

� � 

�� 

� �� 

�� 

�� 

¦ 

��¤�� 

� � � �� 

��¢�� 

��¦��¨�� 

�� 

��¤�� 

��¦�� 

��¦��¦�� 

�� 

��¨�� 

�� 

� � ��¢�� 

�� 

��¨��¨��¨�� 

�� 

�� 

� ��¤��¨�� 

� 

�� 

��¨�� 

�� 

� 

�� 

�� 

�� 

��¨�� 

�� 

�� 

��¢�� 

�� 

�� 


�� ¨��¦��¨§�� 

� � � ��¨��©�� ¨�� 

�� 

�� 

��¨�� 

��¢�� 

�� 

��¦�� 

��¦��¨��¨�� 

��¦�� 

��¦�� 

� �� 

� 

�� ¤�� 

186 

Random walk 

(with obstacle 

avoidance) 

signal 

perception 

perception 

carriage arm 

or mobile robot 

Move towards 

signal origin with 


contact 

no signal 

Move towards arm / 

mobile robot with 


Push forward with a 

force in proportion to 

signal intensity 

no perceived 

arm or robot 

no 

contact 

� �� 

�� 

� 

�� 

��¢��¢�� 

� � � �� 

�� 

��¢�� 

�� 

�� 

��¨��¤�� 

�� 

��¨�� 

�� 

� �� 

��¨��¢�� 

� � 

��¤��¢�� 

��¦�� 

� �� 

�� 

��¢��¨�� 

��¨�� 

��¦��¨�� 

� � 

��¢��¢�� 

�� 

�� 

�� 

��¤�� 

��¦��¨�� 

� �� 

��¦�� 

� �� 

��¢�� 

��¢��¤�� 

��¤�� 

��¤��¢�� 

�� 

� �� 

�� 

�� 

�� 

��¨��¢��¦�� 

� � �¦�� 

�� 

�� 

�� 

� �� 

�� 

��


� ��¤�� 

�� 

�� 

��¦�� 

�� 

�� 

��¤��¢�� 

��¢��¤�� 

��¨��¨�� 

��¨�� 

�� 

�� 

�� ¢�� 

187 

Paralyzed Robot 

(or a person) 

reactive 

mobile 

robots 

left 

force 

signals : f(d) 

+ 

Mechanical 

combination 

reactive 

mobile 

robots 

right 

force 

vision 

Path deviation: d 

reactive 

MAS 

move 

� ��¤�� 

�� 

��¢�� 

��¢�� 

��¢�� 

��¨��¦�� 

�� 

�� 

� �� 

�� 

�� 

��¢�� 

��¦��¦�� 

�� 

��¢�� 

�� 

�� 

� 

��¤�� 

��¤�� 

�� ¤�� 

�� 

� 

��¨�� 

�� 

��¦�� 

� �� 

��¤�� 

�� 

��¨�� 

�� 

�� 

��¨��¤�� 

�� 

��¨��¤�� 

�� 

��¢�� 

��¤�� 

�� 

��¦�� 

�� 

�� 

��¨�� 

�� 

�� 

��¢��¢��¨�� 

��¢��¢��

� �� ¢�� 

�� 

�� 

��¦��¤��¨�� 

�� 

�� 

��¨�� 

��¤��¨��¢�� 

��¨��¨�� 

�� 

��¨�� 

��¨��¨��¤��¨�� 

� �� 

��¢��¢�� 

��¦�� 

�� 

��¢�� 

�� 

�� 

��¦�� 

��¤�� 

� 

�� 

�� 

� �� 

�� 

�� 

�� 

� �� 

�� 

� �� 

�� 

�� 

��¨�� 

�� 

� �� 

��¦�� 

�� §��§�� 

��¤�� 

� �� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

��¢�� 

�� 

� �� 

�� 

� �� 

�� 

�� ¢�� 

�� 

� � � 


188 

b 

a 

c 

neighbor agents 

Signals (I) 

perception 

of neighbors 

perception 

(sat. P) 

neighbors 

evaluation 

action 

selection & 

emissions 

Agent 

Environment 

a. Actions b. 

�� 

��¨�� 

�� 

�� 

�� 

�� 

��¨�� 

�� 

��¥�� 

�� 

�� 

��¨�� 

�� 

�� 

��¢��¢�� 

�� ¨�� 

�� 

�� 

� �� 

�¨�� 

� �� 

��¦��¦�� 

��¨�� 

�� 

�� 

�� 

�� ¤�� 

� 

��¨��¨��¨�� 

�� 

�� 

�� 

��¨��¢��¦�� 

�� 

�� 

��¦�� 

� �� 

�� 

�� 

�� 

�� 

�� 

�� 

��¨��¦�� 

� ��¤�� 

�� 

��¦�� 

�� 

��¤�� 

��¦�� 

��¨�� 

� �� 

�� 

� �� 

��


�� 

��¥�� 

�� 

� 

� �� 

�� 

�� 

�� 

�� 

� 

� �� ¨�� 

� �� 

�� 

� �� 

�� 

� �� 

�� 

� �� 

�� 

� �� 

�� 

� �� 

�� 

� ��¥�� 

�� 

� �� 

�� 

�� 

� �� 

�� 

�� 

�� 

�� 

� 

� �� 

�� 

� �� 

�� 

� �� 

�� 

� �� 

�� 

�� 

� �� 

�� 

�� 

��¨�� 

� �� 

�� 

�� 

�� 

� �� 

�� 

�� 

� ��¥�� 

�� 

� �� 

�� 

� �� 

�� 

�� 

� ��¢�� 

�� 

� �� 

�� 

� �� 

�� 

�� 

��¥�� 

� �� 

�� 

� � � �� 

�� 

189 

�� 

�� 

�� 

�� 

�� 

�� 

��¢��¢�� 

��¤�� 

�� 

��¤�� 

��¦�� 

�� 

�� 

��¦�� 

� � � � �� 

��¤�� 

� � � �� 

�� 

��¦�� 

�� 

� �� 

�� 

��¤�� 

� �� 

��¦�� 

� �¤�� 

�� 

� � �� ¦�� 

�� 

��¨��¤�� 

��¤�� 

�� 

�� 

� �� 

�� 

� ��


� �� 

��¨��¢��¦��¤� 

��¨��¢�� 

�� 

��¨�� 

�� 

�� 

�� 

�� 

�� 

� �� 

��¦�� 

��¨��¨�� 

�� 

�� 

�� 

��¨��¨�� 

�� 

� �� 

��¦�� 

�� 

��¦�� 

�¨��¢�� 

��¨�� 

�� 

��¢�� 

��¦��¨�� 

��¢��¤��¦�� 

��¨�� 

�� 

� �� 

��¢�� 

��¨��¢��¢�� 

��¤�� 

�� 

�� 

�� 

� �� 

�� 

�� 

�� 

�� 

��¨�¨��¨��¦�� 

��¦�� 

�� 

��¦��¤�� 

�� 

�� 

��¢�� 

�� 

��¦�� 

� �� 

�� 

�� 

�� 

��¦�� 

�� 

��¢�� 

� �� 

� �� 

�� 

�� 

190 

�¨�� 

�� 

� 

� �� 

�� 

�� 

��¤�� 

�� 

¤ ��¤�� 

�� 

��¤�� 

�� 

�� 

�� 

��¤�� 

�¨��¢�� 

�� 

�� 

�� 

�� 

�� ¤��¤�� 

��¤�� 

�� 

�� 

��¤�� 

�� 

�� 

§�� 

��¢��¤�� 

� �� 

�¤�� 

�� 

��¦��¨�� 

¤ �� 

�� 

� � �� 

��¤�� 

� � �� 

��¨�� 

�¤�¤��¨�� 

��¤�¤�¤�� 

�� 

� 

�� 

�� 

� � � � �� 

�� 

� �� 

�� 

�� 

�� ¤�� ¨�� 

� 

�¤�� §�� 

��¦�� 

�� ¤ �� 

�� 

�� 

¤ �� 

��¨��¢��¦�� 

� �� 

�� 

¤ �� 

��¤�� 

��¨��¤�� 

��¨�� 

�� 

�� 

�� 

�� 

�� 

��¦�� 

�¨�¦� �� 

�� 

�� 

��¨�� 

¦£�� 

��¤�� 

� �� 

�� 

�� 

�� 

� � ��¤�� §�� 

�� 

�� 

�� 

�� 

��¤�� 

�¤�� 

�� 

��¤� 

�� §�� ¤ �� 

�� 

� � �� 

�¨�� 

�� 

¤ �� 

��¢�� 

�� 

� ��¤�� 

�� 

� �� ¢�� 

�� 

�� §�� 

�


�� 

�� 

�� 

� 

�� ¨�� 

�¤�� 

�� 

�� 

��©��¤�� 

�� 

� �� 

�� 

�¤�� 

��¨��¢��¤�� 

�� 

�� ¤ ��¢�¤��¢�� 

�� 

�� ©�� 

�� 

�� ¤��¨�� 

�¨� 

�� 

�¤��¨��¨�� 

� �� 

�� 

� � � �� ¤�� 

�� 

� �� 

�� 

�� 

§�� 

��¨��¢�¤�� 

� �� ¤�� 

�� ¤�� 

�� 

�¤�� §��¢�� 

�� 

�¤�� 

�� 

�� 

�� 

�� 

�� 

¤ 

� �� 

��¨�� 

� �� 

� 

�� 

��¨�� 

�� 

�� 

� �� 

�� 

� �� 

� 

�� 

��¦��¨��¦�� 

� �� 

�� 

� �� 

��¤��¨�� 

� 

� �� 

�� 

��¦��¤�� 

�� ¢�� ¨�� 

�� 

� �� 

�� 

��¤� �� ¤� �¨� �� 

� 

� �� ¦�� 

�¨�� 

�� 

��¨�� 

� 

�� 

� ��¢��¦��¤� � �� 

�� 

��¦�� 

��¨�� 

�� 

��¨�� 

�� 

� � �� 

��¤�� 

� �� 

�� 

�� 

�� 

�� 

�� 

�� 

��¤�� 

� �� 

�� 

�� 

�� 

�� 

��¤��¨�� 

�� 

�� 

�� 

�� 

191 

�� 

�� 

§�� 

��¤�� 

� � �� 

�� 

��§�� 

�� 

� �� ¤�� 

�� 

�� ¤ �� 

�� 

� 

�¨�� 

� � �� 

� �� ¨��¢�� 

��¦� 

��¢�� 

� 

�¨��¤��¨�� 

�� 

�� 

�� ¨�� 

��¨� 

�� 

�� 

�� 

�¤�� 

�¨� �¨�� 

��¨� 

�� ¨�� 

�� 

�� 

�� 

�� 

�� 

�� 

� 

�� 

�� 

� 

�� 

�� 

�� 

�� 

� 

�� 

�� 

��¤��¤�� 

� 

��¢�� 

� � �� 

�� 

� 

�� 

��¨�� 

� ��¨��¤�� §�� 

�� 

�� 

��¢� � �� 

� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

� 

�� 

�� ¤ �� 

��¨�� 

��

Abstract 

Horocol language and Hardware modules for robots 

Dominique Duhaut, Claude Gueganno, Yann Le Guyadec, Michel Dubois 

Valoria 

Université de Bretagne Sud 

Lorient Vannes, Morbihan, France 

dominique.duhaut@univ-ubs.fr 

This work inserts in the general field of collective robotics. In this paper, we present the results on the design and the 

conception of (1) our robotics component called Atom, (2) the informal semantics of the HoRoCoL language. The 

expressivity of the language is illustrated on a simple example. 

At the hardware level, we propose a versatile architecture easily adaptable for most mechatronic systems. The 

hardware is based on a processing unit developed around a CPU + FPGA computing system communicating through 

bluetooth. On this hardware we build a software architecture, where each robot embeds its own description in an 

XML file. Control interfaces or programming tools are self-reconfigurable, depending of the XML description of the 

robot. That enables quick technology transfer for many mechatronics applications. 

At the software level, we present the Horocol language for programming a society or teams of robots. An example 

shows the principal features of the Horocol language. This language has been developed to offer a solution to express 

the behaviours of a set of teams of robots or agents. We focus on the originality of this language which is in the 

instructions for programming the team coordination. 

Introduction 


This project takes place in the more general field of reconfigurable modular robotics. We can mention several 

various experiments. The M-TRAN (Modular Transformer - AIST) described in [1], is a distributed selfreconfigurable 

system composed of homogeneous robotic modules. CONRO (Configurable Robot - USC), is a robot 

made of a set of connectible, autonomous and self-sufficient modules [2]. ATRON, is a lattice based selfreconfigurable 

robot [3], and also, PolyPod (Xeros) [4], I-Cube (CMU) [5], Hydra . These robots generally consist 

in modules working together and where each module is permanently linked to at least one other. 

Programming such reconfigurable systems is a difficult task [6]. This field covers very different concepts like : 

methods or algorithms (planning, trajectory generation...), or classically, architectures for robot control, usually 

hierarchical : centralised [7], reactive [8], hybrid [9, 10, 11]. Some languages are developed in order to implement 

these high level concepts [12, 13]. Different paradigms are also proposed: functional [14, 15, 16], deliberative or 

declarative [17, 11, 18] and synchronous [12]. In any way, we can schematically summarise the difficulties of robot 

programming in two great characteristics: 

• programming of elementary actions (primitives) on a robot is often a program including many process running 

in parallel with real-time constraints and local synchronisation 

• interactions with the environment are driven via traditional features: interrupt on event or exception and 

synchronisation with another element. 

The recent introduction of teams of robot, where cooperation and coordination are needed, introduces an additional 

difficulty : programming the behaviour of a group of robots or even a society of robots [19, 20, 21, 22]. In this case 

(except in the case of a centralised control) programming implies to load a specific program on to each robot because 

of the different characteristics of robots : different hardware, different behaviours and different programming 

languages. These distinct programs must in general be synchronized to carry out missions of group (foraging, 

displacement in patrol, ...) and have reconfiguration capabilities according to a map of cooperation communication. 

192

From the human point of view it is then difficult to have simultaneously an overall vision of the group on three 

levels: the social level where we look for the global behaviour of any robot, the team level where we focus on a 

specific group of robot and the individual robot level. 

The definition of our general language HoRoCoL is driven by these three levels of team programming: Social, 

Group, Agent. Social and Agent programming are very classical, the original part of this work is on the Group 

programming where we introduce two original instructions : ParOfSeq/SeqOfPar and the where instruction. 

This paper presents the design of our robotics modular component, called Atom, and preliminary results on the 

prototypeand introduces the HoRoCoL language. 

Hardware level 

This section is a quick presentation of some mechanical aspects of the basic module (atom) and next, a description of 

the hardware and embedded software. Some informations on the progress of this project can be found in. The priority 

was given to the high-level tools and the communication middleware, . 

Mechanical design 

One atom is composed of six legs which are directed towards the six orthogonal directions of space. They allow the 

atom to move itself and/or dock to another one. The carcass of the atom consists of six plates molded out of 

polyurethane. A carcass weights approximately 180g. The first walking prototype of atom is shown here. 

Fig1. -The fisrt prototype of Maam robot -The CPU Board -The CPU Organisation 

The CPU has to 

- control 12 axis (2 DOF for one leg) : each leg is driven by two servo--motors and a servo--motor is controlled 

by a PWM (Pulse Width Modulation) signal. The servo includes a motor, an angle reducer and a P.I.D. 

regulator. 

- control the docking of two legs : the mechanic system under consideration provides a flip-flop control. The 

same control must alternatively couple then uncouple the two atoms. 

- identify the legs at the touch of the ground : an atom may have 3 or 4 legs touching the ground at the same 

time. The presence of pincers at the tip of the leg make the installation of a sensor hard. We extract this 

information from the inside of the servo by processing some control-signals of the PID regulator. 

- line up 2 legs : the mechanical connection between two atoms requires the lining up of two legs. We propose an 

infrared transmitter/receiver system. The search for an optimal position needs the use of 6 analog--to--digital 

converters for each atom. It may be useful to activate or deactivate the transmitter if necessary: that leads to 

add 6 digital outputs in our system. 

- communicate with another atom or with a host computer: this aspect is discussed in the next section. 

We also have the following general constraints for robotic and embedded systems: 

- mechanical: the electronic is embedded in a robotic atom; it must fit in a cube which edges < 50 mm. 

- adaptation: emergence of new requirements due to unforeseen problems during the development of robotic 

atom must not question the general architecture. 

Embedded electronic 


193


The architecture represented by the diagram in Fig 1 takes the previous enumeration of functions and constraints into 

account. The Embedded electronics is built around a Triscend TE505 CSoC. The TE505 integrates a CPU 8051, a 

FPGA with 512 cells and an internal 16KB RAM. It is completed by an AD convertor card and external bluetooth 

module for radio--communication 

This solution gives a suitable answer for previous constraints. The micro-controller provides usual functions of a 

computing architecture: central unit, serial line, timers, internal memory. With the FPGA we can realise the 

equivalent of an input/output card with low level functionalities. It provide most of classical combinatory and 

sequential circuits (latches, counters, look--up--tables, comparators With the 512 cells build in the TE505 we could 

carry out the twelve PWM-commands, as well as the command of A/D converter (MAX117) in a pipeline mode and 

also other input/output. So we can command each axis by just writing in one register and control the level of the Ir 

receptor simply by reading in a register that is refreshed in real time. 

Low level Software 

Because managing a team of robots with effectiveness suppose to guess the actual robots reachable in the area, to 

learn the capabilities of each one, to be able to distribute an application between them, and, possibly to remotecontrol 

any of them, we developed the following architecture. 

The host computer searches for the bluethoot robots 

accessible and build the first map of communication 

between them. 

A specific interface allows to make a direct use of the 

commands avaliable on each robot 

The host computer receives all the XML files coming from 

the robots. These files describes the commands and sensors 

available on the robot. 

It is also possible to use the generic interface to program 

the all set of robots using the Horocol language (decribed 

further). 

194

After a compilation, the program can be loaded in each 

robot connected to the system. In each robot a local 

language interpreter will run its own part of the code. 

Horocol Language 

This general procedure permit to program with a unify 

system a all set of robot making by this a multi-agent 

programming language : Horocol. 

Fig 2 : Ambient Robotics presentation 

In Horocol we distingush three levels of programmind : social programming, coordination programming and agent 

programming 

Social programming 

Is used to express the general behaviour of the sets of agent. It gives a general description of « what set of agent is 

doing what ». It is a meta langage of behaviour. It offers a high level point of view to the programmer who describes 

its calculation in term of composition of event, directed parallel programs synchronized by areas. Areas stands for a 

set of agents, virtually or physically distributed over a network of computers or a set of mechatronics agents, running 

the same goal. 

Main structure 


Horocol : := *import file.xml ;* 

programHorocol program_name { 

agents_set_declaration // Declaration section 

* global_instruction ; * // Programming section 

} 

import is used to express what which real robots are used in this program. 

We assume that an agent (robot) is define by a set of 3 files: 

• primitive.xml which describe the elementary actions that can perform the agent (for instance in the next example 

myRobot will be able to : “findTheBall() or searchNeighbourg() …” 

195

• langage.xml which describe the kind of program that can execute the agent (robot). This language can be a 

standard programming language (Java, C++, …) or a specific language for an industrial robot. In our case it is 

the interpeter described in Fig2 which is the target language. 

• horocolSystemBasics.xml which describe the list of system features available for this agent (robot) like 

communication, synchronisation... This file will allow a Horocol engine to know if it is possible to generate 

from an Horocol program a specific program for this agent (robot). 

These 3 files are supposed merged in a file file.xml. In the case of a set of heterogeneous robot then there will be 

several different file.xml : one by kind of robot. 

Declaration section 

[A] agents_set_declaration : := *agents_type_declaration* [A1] 

*agent_list * [A2] 

*[social_variable]* [A3] 

*[social_event]* [A4] 

Agents, variables and events are declared at the global scope. Agents list is the list of all 

agents participating to the program. Variables and event declared at global scope are supposed 

visible by any agent. The public variables of the agents (define in files.xml) are also 

supposed visible by all agents. 

[A1] agents_type_declaration ::= type agents_type_identifier use file.xml; 

This construction defines type of agents and make the link with the real external agents/robots. 

[A2] agent_list ::= agent_type_identifier identifier=newAgent([agent_type_identifier]); 

This is the declaration of all the agents participating in this code. The newAgent order express 

the begining of the robot life for this appication. It is not necessarily implementable it 

can be reduce to “power on” a robot. 

[A3] social_variable ::= type_indication identifier_list [limited( agents_list, agents_type)] [= expression]; 

[A4] social_event ::= event identifier_list; 

Programming section 


Classical variable are allowed (int, float, boolean …). This defines public variables visible 

by all agents of the system named social variables. 

The keyword limited express that for the agents in agents_list or agents_type the variable 

is “read only”. 

It is possible to declare public events. Social event are supposed to be visible from all 

agents declared in this program. 

[B] global_instruction ::= global_noninterrupt_action [B1] 

| global_interrupt_action [B2] 

| global_parallel [B3] 

| global_variable_assignment [B4] 

| global_if [B5] 

| global_loop [B6] 

[B1] global_noninterrupt_action ::= [ local_program ] 

196


[B2] global_interrupt_action ::= ° local_program ° 

This defines a program that is executed from the first to the last instruction without possibility 

to end its execution. This construction is only usefull in [ B3] construction. 

This defines a program that can be ended during its execution. The way of finishing a program 

is not defined by Horocol because it depend on the type of real agents used. Basically 

we can consider two kinds of ending. First the system kills the program. The second way is 

to send a message to this program to ask it to finish, this technique will be preferred when 

security is needed (shared variable, robot …). 

[B3] global_parallel ::= || (*global_instruction,* global_instruction ) 

This construction allows to begin at the same time two (at least) different programs over 

the set of all agents. At this point an agent will execute the first code possible for him. This 

means that in the case of a || (P1,P2,P3,P4) then there is 4 programs running in parallel. 

An agent will execute the first program that he is able to execute in the list beginning by P1 

end ending by P4. The ||(P1,P2,P3,P4) instruction is terminated when all the programs 

P1, P2, P3, P4 are terminated. 

[B4] global_variable_assignment ::= identifier = expression 

[B5] global_if ::= if (test) { local_program } else {local_program} 

[B6] global_loop ::= while (test) { local_program } 

These are very classical assignment to social variables or If and While instructions 

. 

Coordination or Group Programming 

The coordination programming gives the description of how a specific set of agent will execute the code and how it 

is distributed over this set of agents. This is the most original part of the language. It contains two different original 

constructions. 

First original part : the couple seqofpar and parofseq express the way in which the code is executed : synchronously 

(seqofpar) or independently in parallel (parofseq). 

Second original part : the where instruction express the pre condition to be satisfied for an agent to execute a code. 

[C] local_program : := 

*[global_variable_assignment]* [B4] 

| *[agent programming]* [C1] 

[C1] agent programming :: = 

.method() [D1] 

| seqofpar(agent_type_list) { [LP1] 

[protected_declaration] [D2] 

*where_without_event* [D3] 

} 

| parofseq(agent_type_list ){ [LP2] 

[protected _declaration] [D2] 

*where_with_event* [D4] 

} 

197

Coordination programming in Horocol language takes three different forms : a classical 

specific method called to a specific agent [D1], or one of the two constructions “seqofpar” 

[LP1] or “parofseq” [LP2] detailed below. 

[D2] protected _declaration ::= 

type_indication identifier_list [ limited( agents_list, agents_class)] [= expression] ; 

| event identifier_list ; 

[LP1] Instruction 

It is possible to declare protected scope variables or events (inside a seqofpar or parofseq). 

In this case they are visible only to the subset of all agents executing this part of code. 

seqofpar: 

sequence of parallel 

seqofpar(agent_type_list) can be understood as : “apply seqofpar to all agents having the type « agent_type » in the 

following”. In this construction « agent_type » are defined in [A1]. The seqofpar is a control structure for which 

each line of the internal program (where_without_event) will be executed synchronously over all agents concerned 

by this branch. Synchronously execution means that agents execute one instruction at the same time than the others. 

[D3] where_without_event ::= 

where (test) { 

[private_declaration] [D5] 

* local_instruction ; * [E] 

} 

[LP2] Instruction 

where indicates who is concerned by the “local_instruction”. This construction can be understood 

like : “for all agents satisfying the condition expressed by the test execute the following 

local_instuction”. Remark also that it is possible to define private variables [D5] or 

events which are visible only by the agent executing this branch an duplicated in each of 

them (i.e. duplicated in each agent satisfying the condition test). Because this kind of instruction 

is in a seqofpar this means that each instruction [F1] to [F11] of the local instructions 

[E] is executed locally at the same time on each agent satisfying the test. In this case 

we speak of synchronous multi-agent programming. 

parofseq: 

concurrency of sequence 

Here all agents concerned by the code (where_with_event) are executing their code in parallel and no instruction 

synchronisation between them is made. This means that all agents execute its own code independently from the 

others. The only instruction synchronisation is at the end of the parofseq because this instruction is considered 

terminated when all the agents concerned by the internal code have finished their execution. 

[D4] where_with_event ::= 

where (test ){ 

[private_declaration] [D5] 

* local_instruction ; * [E] 

[react 

* when_event ; *] [D6] 

} 

[D5] [private_declaration] 


Declaration of private variable or event at a private level. These elements are only visible 

by the agent executing this code and are duplicated in each agent. 

198

[D6] when_event ::= when test => * local_instruction ; * 

Agent programming 

The react part is used to express reactive multi-agent programming. It works like exceptions 

in standard languages. Each time that an event (supposed visible by the agent executing 

this code) is emitted (by the emit [F7] instruction) then the react part is activated and 

looks if a specific program is linked to it. If it is the case then this program is executed else 

the normal program continues at the point where the event arrived. 

If during the execution of local_instruction an other event is raised the this second event is 

queued until the end of the code actully running in the react part. After what it will be 

treated by the react part. Nevertheless, it is possible to use Horocol to simulate preemption 

and priority. 

The agent programming will describe the code executed at low level by the agents. To the set of instructions defined 

in [E] we have to add local agent primtives which are defined in the file.xml imported in the beginning of the 

Horocol program. 

[E] local_instruction : := 

basic_primitive() [F0] 

. basic_primitive() [F1] 

| if (test) { local_instruction }{ local_instruction } [F2] 

| while (test) { local_instruction } [F3] 

| loop local_instruction end loop [F4] 

| exit [F5] 

| variable_assignement [F6] 

| emit event [F7] 

| resume [F8] 

| restart [F9] 

| reevaluate [F10] 

[F0] basic_primitive() 

Again classical specific method applied to the concern agent. 

[F1] . basic_primitive() 

Again classical specific method call to a specific agent identical to[D1]. 

[F2] if (test) { local_instruction } else { local_instruction } 

standard. 

[F3] while (test) { local_instruction } 

standard 

[F4] loop local_instruction end loop 

standard 

[F5] exit 

used to exit from a loop …end loop [F4] or while [F3] instruction. 

[F6] variable_assignement 


Identical to [B4] 

[F7] emit event | emit event (*type var,* type var) 

This instruction emits an event that can be declared at the social level [A4] or protected if 

declared in [D2] or private if declared in [D5]. When an event is emitted then the react part 

[D6] of the program is executed. 

199

[F8] resume 

[F9] restart 

[F10] reevaluate 


This instruction can be present only in when_event [D6] part. Its execution will restart the 

execution of the corresponding local_instruction [E] program at the instruction where was 

emmited the event that stops its execution to enter in the react part. 


execution of the corresponding local_instruction [E] program at the first instruction. 


execution of the seqofpar or parofseq instruction. The idea is to check is the agent stills 

have the properties expressed in the where test of [D3] or [D4] 

Example of Horocol programming 

Let’s consider an example in which we simulate the behaviour of a robot team playing football. Let’s say that there is 

4 players, one goal keeper and one coach in the team. A general clock will calculate the end of the play. 

import myRobot.xml; 

import clock.xml; 

programHorocol footballVersion1 

type football use myRobot.xml; // the football type is builded by the decscription of my robots 

type clock use clock.xml; // a general clock type 

football a1,a2,a3,a4,a5,coach = newAgent( football ); // define 6 agent variables member of the team 

clock watch= newAgent( clock); // and on agent for the clock 

event coachGivesOrder, timeOut; // two global events one for the coach, one for the clock 

int coachStrategy; // the global variable defining the strategy of the team 

int time limited (football); // variable impossible to modify for agent having type football 

{ 

// init part here we suppose that each football agent will receive his assignment (player, goal keeper, coach) 

parofseq(football, clock){ 

int playersOrganisation ; // this variable is visible for all members of this section 

where (football.isPlayer()){ // only football agents satisfying isPlayer() primitive execute this 

section 

football x; // this local variable is in each player of this section 

loop 

findTheBall(); // call to a primitive of the agent defined in myRobot.xml 

if (foundBall ) { moveToBall(); shootBall(); } 

else { localMove(playersOrganisation); 

x =searchNeighbourg(); // search an other agent to speak with 

playersOrganisation = x.exchangeInformation(); // discuss with this agent 

} // this make possible change in the team organisation 

end loop; 

react // if an event is raised the previous section stops and this part is executed 

when timeOut => resetBehaviour() ; restart; // end of the game start again 

when coachGivesOrder => setMyself( coachStrategy); reevaluate; // change my behaviour 

}; 

where (football.isGoalKeeper()){ // executted by the football agent verifying isGoalKeeper() 

loop 

findTheBall(); …. 

coach.exchangeInformation();// direct talk between the goal keeper/coach: local synchronisation 

end loop; 

react 

200

} 

} 

when timeOut => resetBehaviour() ; restart; 

when coachGivesOrder => setMyself( coachStrategy); reevaluate; 

}; // according to the coach decision the goal could change his behaviour and become a player 

where (football.isCoach()){ 

int coachConclusion ; // local variable used by the coach to analyse the situation 

loop 

if (time0) { waitOneSecond(); time =time-1;}; 

emit timeOut; // raise the timeout then all the agents will react to this event and end the game 

}; 

Mapping Horocol on a set of real robots 

By these example we see how the Horocol programs are linked to the real robot by the use is the import and use 

constructions. 

The idea of Horocol is to assume that some primitive actions are available for each type of agents. Then when we 

write an Horocol program we manipulate these primitives under some parallel : ||, seqofpar or parofseq constructions. 

In fact, depending on the hardware structure of the robots, we have no guaranties that these parallel constructions are 

really possible to implement. For instance if the robots are very simple : contact sensor, ligth sensor no 

communication (think of a Lego Mindstorm robot) then constructions like : seqofpar or a direct call to a specific 

robot [F1] are not possible. 

To know if it is possible to compile the Horocol program in a equivalent code running on the real robot the Horocol 

compiler will use the informations included in the XML file. This file is including three levels of information : 

- the robot primitive, 

- the syntax of the language used to program this robot, 

- the horocol system primitives avaliable on this physical target. 

The compiler checks first with the information stored in the horocol system if all the basics features exist to 

implement : social or protected variable, parallel constructions, direct information exchange. 

The second phase is to check if all the primitive used in the Horocol for the associated type are present in the robot 

primitive. 

Finnaly a purely syntactic rewriting transform the Horocol source code in the specific robot language. Of course this 

last pass is specific to each robot language so it needs to be rewrited for each kind of target. In our case we tested this 

transformation for the local interpreted language mentioned in fig 2. 

CONCLUSION 


The Horocol language proposed here allow the description of multi-agents, multi robots behavior at three different 

levels : social, coordination and agent. The originality of Horocol is in the instructions : parofseq/seqofpar for 

synchronous programming coupled to the where instruction for precondition evaluation coming with the reevalute 

to check for dynamical. Coupled to the distributed hardware it offers a solution to distributed mechatronics systems. 

201

References 


[1] S. Murata, E. Yoshida, A. Kamimura, H. Kurokawa, K. Tomita, S. Koraji, "M-TRAN: Self-Reconfigurable Modular Robotic System" in 

IEEE/ASME transactions on mechatronics, Vol.7 No.4 2002 

[2] M. Rubenstein, K. Payne, W-M. Shen, "Docking among independent and autonomous CONRO self-reconfigurable robot" in ICRA 2004 

[3] M.W. Jorgensen, E.H. Ostergaard, H. Hautop, "Modular ATRON: Modules for a self-reconfigurable robot" in proceedings of 2004 IEE/RSJ 

International conference on Intelligent Robots an Systems (IROS 2004). 

[4] http://robotics.standford.edu/users/mark/polypod.html 

[5] C. Unsal and P.K. Khosla, "A multi-layered planner for self-reconfiguration od a uniform group of I-cube modules", IEEE/RSJ, IROS conference, 

Maui, Hawaii, USA, pp 598-605, Oct. 2001. http://www-2.cs.cmu.edu/~unsal/research/ices/cubes 

[6] T. Lozano-Perez & R. Brooks “An approach to automatic robot programming” Proceedings of the 1986 ACM fourteeth annual conf on 

computer science 1986, ACM Press 

[7] J. S. Albus & all. NASA/NBS “Standard Reference Model for Telerobot Control System Architecture (NASREM)”. NBS Technical Note 

1235, National Bureau of Standards, Gaithersburg, MD, 1987. 

[8] P. Hudak & all “Arrows, robots, and functional reactive programming” LNCS 159-187 Spinger Verlag 2002 

[9] R. Alur & all, "Hierarchical Hybrid Modeling of Embedded Systems" Proceedings of EMSOFT'01: First Workshop on Embedded Software, 

October 8-10, 2001 

[10] F. F. Ingrand & all “PRS: a high level supervision and control language for autonomous mobile robots”, IEEE Int Cong on Robotics and 

Automation Minneapolis, 1996 

[11] D. Paul Benjamin & all “Integrating perception, language an problem solving in a cognitive agent for mobile robot” AAMAS’04 july 19-23 

2004, New-York 

[12] I. Pembeci & G. Hager “A comparative review of robot programming languages” report CIRL – Johns Hopkins University august 14, 2001 

[13] C. Zielinski “Programming and control of multi-robot systems” Conf. On Control and Automation Robotics and Vision ICRARCV’2000 dec 

5-8 2000, Singapore 

[14] J. Armstrong “The development in Erlang”, ACM sighpla international Conference on Functional Programming p 196-203. 1997 

[15] M.S. Atkin & all “HAC: a unified view of reactive and deliberative activity”. Notes of the European Conf on Artificial Intelligence 1999 

[16] G. King “Tapir: the Evolution of an Agent Control Language” American Association of Artificial Intelligence 2002. 

[17] M. Dastani & L. van der Torre “Programming Boid-Plan agents deliberating about conflicts along defeasible mental attitudes and plans” 

AAMAS 2003 

[18] J. Peterson & all “A language for declarative robotic programming” Int Conf on Robotics and Automation ICRA 1999 

[19] E. Klavins “A formal model of a multi-robot control and communication task” IEEE Conf on Decision and Control, 2003 

[20] E. Klavins “A language for modeling and programming cooperative control systems” Int Conf on Robotics and Automation ICRA 2004 

[21] D.C. Mackenzie & R. Arkin “Multiagent mission specification and execution” Autonomous Robot vol 1 num 25 1997 

[22] F. Mondada & all “Swarm–bot: for concept to implementation”, IEEE/RSJ Int Conf on Intelligent Robots and Systems IROS 2003 

202


A Real-Time, Multi-Sensor Architecture for fusion of delayed 

observations: Application to Vehicle Localisation 

C. Tessier, C. Cariou, C. Debain 

CEMAGREF 

24, avenue des Landais 

BP 50085, 63172 Aubière, France 

e-mail: cedric.tessier@cemagref.fr 

Abstract— This paper presents a software framework called 

AROCCAM that was developed to design and implement 

data fusion applications. This architecture permits to build 

applications in a very short time unburdening the user of sensor 

communication. Moreover, it manages unsynchronized sensors 

and delayed observations in an elegant manner that permits to 

the user to fuse those information easily, taking into account 

the environment perception date. 

In this paper, a fusion methodology for delayed observations 

is first presented in order to point the problem of latency 

periods in a fusion system. These latency periods are then taking 

into account within our embedded architecture needing only a 

little effort from user. Finally, benefits of AROCCAM architecture 

are demonstrated via a real-time vehicle localisation 

experiment carried out with an outdoor robot. 

I. INTRODUCTION 

Nowadays, more and more vehicles are equipped with 

intelligent systems. These systems have to realize particular 

tasks such as: vehicle localisation, automatic guidance, obstacle 

avoidance, pedestrian detection,. . . . To accomplish their 

tasks, they process sensor data. However, it is necessary to 

write piece of softwares to communicate with sensors. This 

task is tedious and most of all a lack of time. A solution to 

this problem is to use an embedded architecture. Such architectures 

permit to facilitate the development of algorithms 

by managing the communication between those algorithms 

and sensors. For instance, they can collect sensor data and 

control sensors without blocking algorithm mechanism. 

The architecture proposed here has to respect several 

requirements: 

• management of unsynchronized data and sensors latency, 

• recording and replaying of sensor data in real-time, 

• engineering requirements: re-usability, integration, 

maintenance, processing efficiency 

• user requirements: easy of use, programming error 

detection. 

When a system uses a single sensor, it can only sense a 

partial and incomplete part of the environment. By contrast, 

a multi-sensor approach is a way to improve environment 

perception. It’s necessary to notify that a sensor provides an 

observation of the environment at a particular time. Another 

sensor provides a similar information at another time. The 

F. Chausse, R. Chapuis 

LASMEA - UMR 6602 

24, avenue des Landais 

63177 Aubière, France 

e-mail: chausse@lasmea.univ-bpclermont.fr 

203 

C. Rousset 

ECA 

Rue des Frères Lumière BP 24 

83078 Toulon Cedex 09, France 

e-mail: cro@eca.fr 

difficulty of a multi-sensor system is to fuse sensor data with 

different dates. 

• In some works [1], [2], [3], sensor data are fused 

without taking into account the fact that information 

are unsynchronized. 

• In other works [4], the data sampling frequency is 

increased in order to consider that all information are 

synchronized each other. Unfortunately, this assumption 

is false since each sensor has a latency time, which can 

not be taken into account by this way. 

Data fusion systems become more and more used, which 

motivated us to design an architecture to answer the problem 

of unsynchronized sensor data taking also into account sensor 

latency. 

This paper is organized as follows. Section II depicts 

the works related to embedded architecture, emphasising 

assets and drawbacks of each approach. In section III, our 

architecture is described by presenting each module and 

their objectives. Functionalities that ease the development 

of embedded software are also enumerated. Section IV 

details the latency periods of observations: where they arise 

from? the consequences of fusion of delayed observations. 

A solution is suggested to deal with such observations in a 

data fusion system. Finally, a typical application involving 

our solution is given in the last section: real-time vehicle 

localisation. 

II. RELATED WORKS 

Since several decades, different embedded architectures 

have been developed, each answering to requirements of a 

particular field of applications. However, all these architectures 

are agree with the necessity to be divided in several 

components. 

For instance, the LAAS architecture [5] has three hierarchical 

levels, having different temporal constraints and 

manipulating different data representations. The main asset 

of such a decomposition is the realisation of prototype 

software applications in a very short time. In the same manner, 

SCOOT-R [6], [7] the acronym for “Server and Client 

Object Oriented for the Real-Time”, offers a framework 

for distributing tasks on multi-processing unit architecture. 

This software is in charge of communication between each


processing unit. This permits to realise time-consuming 

applications by distributing tasks on several computers. 

Another feature pointed up in the SCOOT-R architecture 

is the real-time aspect. It consists in giving the sensor data 

to the algorithm as soon as it’s available. In the case of 

this architecture, a communication between each components 

must be implemented, since it is a distributed application. In 

order to solve the problem of communication time in a realtime 

software, a real-time network is used. Moreover, the 

real-time aspect of the mechanism of SCOOT-R components 

obliges each component to work in a very short time not to be 

declared as defective. Unfortunately, the determination of the 

processing time of sensor data is sometimes not possible. The 

upper limit of the processing time can always be evaluated. 

In general, vision algorithms like road detection [8] can take 

more than 100ms per images. This reduce the utilisation 

of this architecture to mighty processing unit and to avoid 

time-consuming algorithms. In the same manner as SCOOT- 

R, RT-MAPS [9], [10], is divided into several components 

and date sensor data with an accurate clock as well. In that 

particular case, the aim of the dating is to use RT-MAPS 

like a numeric videotape recorder. Note that this date is the 

reception date of the sensor data. In a first time, it can record 

all data in a synchronized dated database. Then, it’s possible 

to replay all these data later. The asset of this function is that 

it permits to improve an algorithm by testing it on the same 

databank or to compare several algorithms. Now, having 

compared several architectures for embedded applications, 

let’s analyse the main functions of our architecture before 

discussing latency problem. 

III. AROCCAM 

In our architecture called AROCCAM, the acronym for 

“Architecture d’ordonnancement de capteurs pour la création 

d’algorithmes modulaires”, we pointed up the modular and 

simple aspect. As we want an easy to use architecture, 

AROCCAM is only divided into three components (Figure 

1). 

• A driver module is responsible for the communication 

with external entities like sensors, softwares, 

computers,. . . There is a particular driver module for 

a particular communication bus (IEEE, CAN network, 

Ethernet network, Serial ports,. . . ). 

• A brik module is an application algorithm. Thanks 

to a subscription to driver modules, a brik module 

receives directly sensor data without having to know 

the communication protocol. In general, the user has to 

write piece of software only in this area. 

• The heart module is the final component. This component 

has not to be modified or adapted by the user. 

It is responsible for the communication between driver 

modules and brik modules, the threads creation, memory 

management, . . . 

Moreover, like RT-MAPS, our architecture dates accurately 

each sensor data gathered. This permits to the user 

to replay all the recorded sensor data at the desired speed. 

In order to replay exactly the sensor data in the same way 

204 

Localisation 

brik 

Control 

brik 

Obstacle 

avoidance 

brik 

Brik modules 

Heart module 

− Threads creation 

− Communication between 

drivers and briks 

− Memory management 

Driver modules 

CAN 

IEEE Ethernet RS232 

1394 

Fig. 1. AROCCAM Software Architecture. 

that they were recorded (order of sensor data reception and 

interval time between two sensor data), the date of each 

sensor data corresponds to the reception date of the data 

by AROCCAM during recording. 

After having described components involved in our architecture 

and their objectives, let’s now analyse in details the 

problem of delayed observations fusion. 

IV. A FUSION METHODOLOGY FOR DELAYED 

A. Presentation 

OBSERVATIONS 

The real-time aspect of embedded architectures is a feature 

pointed up. This feature consists in giving the sensor data to 

the algorithm as soon as it is available. However, as it was 

suggested by [11], most of the sensors have a latency time. 

Such architectures remain real-time sensor data collecting 

softwares but are not real-time environment perception softwares. 

As sensor latency time can’t be suppressed, it’s therefore 

impossible to realise the real-time architecture last proposed. 

It means that the user must take these latenesses into account. 

In [12], a solution is suggested to the user. In this paper, we 

propose an elegant manner to manage this problem without 

making the development of an application algorithm more 

complex. 

In the next section, is described in details the kind of 

latency periods that can appear. 

B. Observation and latency period 

The aim of the software that must be implemented in our 

architecture is to realize a particular task. In this section, 

we take the example of an accurate real-time positioning 

of a car on a digital map [13]. In this case, the vehicle is 

equipped with a video camera, oriented in the direction of 

the road, aiming at detecting the road. Then this detection 

permits to locate the vehicle thanks to a digital map listing 

road configurations. 

An information that permits to participate to the achievement 

of the software task is called here an observation. 

It can be a sensor data or the processing result of this 

data. These observations are fusioned in the software. Let’s

analyse in details the process to obtain an observation (Figure 

2) in our example. 

Environment 


sensor latency communication time 

ta tc 

Perception 

Communication 

tp 

processing time 

Processing 

Fig. 2. The latency periods for obtaining an observation. 

tobs 

Observation 

(result) 

In general, the process to obtain an observation can be 

divided into three steps, each of them requiring a process 

time: 

• perception. The sensor captures at time ta a perception 

of the environment. Modern systems use smart sensors, 

i.e. an analog sensor linked to a local controller. The 

local controller gets the analog information, performs 

the analog to digital conversion, and sends the results 

through a digital bus like RS232 or CAN or Firewire. In 

the following of this paper, the word sensor will refer to 

a smart sensor. The time required by the local controller 

to prepare the result corresponds to the sensor latency. 

• communication. As explained just above, it consists in 

sending the result through a digital bus at time tc. 

• processing. At time tp, the embedded architecture, like 

AROCCAM, receives the sensor data. As our architecture 

works in real-time, we consider that the sensor data 

is dated as soon it’s available by the computer. However, 

this information is not directly useable for the algorithm 

task. This last one has to process these data to extract a 

worth observation. The time required to treat the sensor 

data is the processing time. 

In all embedded architectures, dating sensor data accurately, 

consists in timestamping those data with the date tp 

like we do. However, the application algorithm can only 

fuse observations with the same date: the perception date. 

Sometimes, the data sheet of the sensor or directly the sensor 

during the experiment provides the sensor latency. When 

there is no information, a temporal calibration of sensors has 

to be done. Unfortunately, it’s not always possible to estimate 

accurately all these parameters. We suggest to timestamp the 

observation with the date ta and include with this date the 

dating precision. 

C. Consequences of delayed observations fusion 

To illustrate the fusion of delayed observations, let’s keep 

our example of vehicle localisation. For vehicle localisation 

task, the estimated position is valuable only at a specific time. 

The robotic community calls this characteristic, the spatiotemporal 

localisation. It means that the estimated vehicle position 

is function of time. For each result produced by those 

systems, a time imprecision induced a spatial imprecision. A 

spatial time induced error of 10cm is given by an imprecision 

time 

205 

of 1.5ms at 250km/h or 15ms at 25km/h. To build an 

accurate localisation system, it’s necessary to keep in mind 

the observations latency times. 

D. Fusion of delayed observations 

The aim of the system is to compute a result: the state 

vector, and this vector is function of time. In the previous 

section, the latency periods for obtaining an observation 

have been detailed. The problem here, is the fusion of a 

delayed observation with a particular state vector. It means 

that an observation received by system has to be used to 

update a particular state vector: the one that describes the 

system at observation’s date. AROCCAM offers an optimal 

estimation of the state vector at any time. 

V. EXPERIMENTATION AND RESULTS 

The following section describes experimentations that 

were carried out to validate our approach. Thus, an outdoor 

localisation system was chosen. 

A. Description 

A terrestrial robot was used for the experiments. This 

research platform, of the Research Federation TIMS (Technologie 

de l’information, de la mobilité et de la sûreté), 

(Figure 3), was initially equipped with an on-board PC 

running Linux RTAI. Several sensors was added to it for 

the realisation of the system. 

The objectives of this system is to locate the vehicle with 

2m accuracy using only low-cost sensors. 

Fig. 3. The “RobucarTT” with its sensors 

Magnetometer 

Low−cost GPS 

Doppler radar 

Gyrometer 

1) Sensors: Sensors used in this system are presented in 

Table I. The GPS system and the magnetometer permits to 

initialize the system: vehicle position and orientation. Then, 

two proprioceptive sensors: a Doppler radar and a gyrometer, 

and the GPS are used to locate the vehicle. A particle filter 

is employed to estimate the vehicle position. 

Table I lists not only sensors but also their latency period 

and their acquisition frequency. These latency periods take 

into account the latency period of the sensor and also the

TABLE I 

PROBABILITY VALUES FOR PERCEPTIVE TRIPLETS 

sensor latency period acquisition frequency 

magnetometer 5ms 16Hz 

low-cost GPS 6 − 100ms ⋆ 10Hz 

Doppler radar - 10 − 77Hz 

gyrometer - 20Hz 

⋆ : supplied directly by the sensor. 

communication time on the bus that links the sensor to 

the computer. We can also notice that all these sensors 

are not synchronized since they are affected by different 

latency period and different acquisition frequency. The use 

of AROCCAM seems to be necessary. 

2) Vehicle progress model: In this part, we focus on small 

displacements. Assuming the flatness of the environment 

where the robot is running, position and attitude of the 

vehicle are resumed to the position of the vehicle in the 

2D plane (Oxy) defined by x(t) and y(t) and orientation 

of the car with respect to the (Ox) axis given by θ(t). 

Measurements from the vehicle are the average speed V (t) 

given by the Doppler radar and angular speed ω(t) given by 

the gyrometer. 

Figure 4 shows the vehicle state (position and orientation) 

at two particular moments: tk and tk+1. 

y k+1 

y 

k 

O 

y 

ICC 

R 

M k 

α 

x k 

θ k 

d 

∆ d 

M k+1 

x k+1 

θ k+1 

∆ θ 

Fig. 4. Small displacement between two successive positions. 

Relation between vehicle displacement ∆d and average 

speed V is given by: ∆d ≈ d = T e · V where T e is the 

sampling period. In the same way, relation between vehicle 

rotation ∆θ and angular speed ω is given by: ∆θ = T e · ω. 

Thus, the vehicle progress model is: 

⎧ 

⎨ 

⎩ 


xk+1 = xk + ∆d · cos(θk + ∆θ/2) 

yk+1 = yk + ∆d · sin(θk + ∆θ/2) 

θk+1 = θk + ∆θ 

3) Why use AROCCAM: It’s necessary to use the AROC- 

CAM architecture in this system since: 

• sensors are unsynchronized: equation (1) supposed 

that the two proprioceptive sensors supply synchronized 

observations. 

x 

(1) 

206 

• sensors have a latency period. 

An elegant solution to solve these difficulties is to use the 

architecture suggested in this paper. 

B. Experimentation results 

The scenario used to validate our architecture is presented 

in figure 5. As we can see, the trajectory is complex and 

contains several curves. This path have been obtained by 

a manual run. During the experiment, successive absolute 

positions giving by a GPS RTK (THALES Navigation) with 

2cm accuracy, are recorded. The position estimated by our 

method is compared each time with the GPS-RTK reference 

trajectory by computing the difference (error) between them. 

Error (m) 

1.8 

1.6 

1.4 

1.2 

1.0 

0.8 

0.6 

0.4 

End 

Fig. 5. Trajectory realised in the experiment. 

Begin 

0.2 

0.0 

with AROCCAM 

without AROCCAM 

0 20 40 60 80 100 120 140 

Time (s) 

Fig. 6. Localisation error with two architectures. 

On the following figure (figure 6), the localisation error is 

depicted for two experimentations: 

• In red line: localisation error with the use of AROC- 

CAM, taking into account the latency periods. 

• In blue line: localisation error with a classical embedded 

architecture. 

We can notice that, as expected, latency periods affect the 

localisation system results. In our example, a maximal error 

of 20cm is added to the system when a classical architecture 

is used. These results permit to show the benefit given by 

our approach.


VI. CONCLUSION 

This paper has proposed an embedded architecture for 

the fusion of delayed observations. A fusion methodology 

has first been designed. First a description of the latency 

periods from the sensor to the data fused in the algorithm has 

been presented. The consequences of delayed observations 

fusion have been explained though the example of the vehicle 

localisation and a method has been suggested by the use of 

AROCCAM. Finally, a vehicle localisation application has 

been proposed to illustrate our architecture. 

Even though the AROCCAM architecture allows to reduce 

errors in fusion of unsynchronized information, our aim here 

is to draw conclusions not from the demonstration but from 

the process of building embedded applications. We think 

that the AROCCAM architecture offers an elegant and easy 

manner to build fusion algorithm. The benefit was really 

substantial: during all the programming and debugging process, 

we never had problem with thread communication, realtime 

multithread management, transmission of data between 

different system,. . . All these aspects were dealt with by our 

software architecture. 

Moreover several other applications were developed under 

AROCCAM with no difficulties and good results. 

REFERENCES 

[1] Gianluca Ippoliti, Leopoldo Jetto, Alessia La Manna, and Sauro 

Longhi. Improving the robustness properties of robot localization 

procedures with respect to environment features uncertainties. In International 

Conference on Robotics and Automation (ICRA), Barcelona, 

Spain, April 2005. 

[2] C. Kwok, D. Fox, and M. Meila. Real-time particle filters. IEEE, 

Sequential State Estimation, 92(2), 2004. 

[3] David Filliat. Cartographie et estimation globale de la position pour 

un robot mobile autonome. PhD thesis, LIP6/AnimatLab, Université 

Pierre et Marie Curie, Paris, France, December 2001. Spécialité 

Informatique. 

[4] Marc-Michael Meinecke and Marian-Andrzej Obojski. Potentials and 

limitations of pre-crash systems for pedestrian protection. In International 

Workshop on Intelligent Transportation, Hamburg/Germany, 

March 15-16 2005. 

[5] Rachid Alami, Raja Chatila, Sara Fleury, Matthieu Herrb, Felix 

Ingrand, Maher Khatib, Benoit Morisset, Philippe Moutarlier, and 

Thierry Siméon. Around the lab in 40 days... In IEEE International 

Conference on Robotics and Automation, San Francisco, USA, 2000. 

[6] Khaled Chaaban, Paul Crubillé, and Mohamed Shawky. Computer 

Science, chapter Real-Time Framework for Distributed Embedded 

Systems, pages 96–107. Springer-Verlag GmbH, 2004. 

[7] Khaled Chaaban, Paul Crubillé, and Mohamed Shawky. Real-time 

embedded architecture for intelligents vehicles. In Proceeding of the 

5th Real-time Linux workshop, Valencia, Spain, November 2003. 

[8] P. Jeong and S. Nedevschi. Efficient and robust classification method 

using combined feature vector for lane detection. Ieee transactions on 

circuits and systems for video technology, 15(4):528–537, 2005. 

[9] Iyad Abuhadrous, Fawzi Nashashibi, and Claude Laurgeau. Multisensor 

fusion (gps, imu, odometers) for precise land vehicle localisation 

using rtmaps. In 11th International Conference on Advanced 

Robotics ICAR, 2003. 

[10] Fawzi Nashashibi. Rtm@ps: a framework for prototyping automatic 

multisensor applications. In IEEE Intelligent Vehicles Symposium, 

October 3-5 2000. 

[11] Mikael Kais, Laurent Bouraoui, Steeve Morin, Arnaud Porterie, and 

Michel Parent. A collaborative perception framework for intelligent 

transportation system applications. In Intelligent Transportation Systems 

Conference ITSC, Vienna, Austria, September 13-16 2005. 

[12] Iyad Abuhadrous. Systéme embarqué temps réel de localisation et 

de modélisation 3D par fusion multi-capteur. PhD thesis, Ecole des 

Mines de Paris, january 2005. 

207 

[13] Jean Laneurit, Roland Chapuis, and Frédéric Chausse. Accurate 

vehicle positioning on a numerical map. International Journal of 

Control, Automation, and Systems, 3(1):15–31, March 2005.


List of speakers 

Name Organism Title 

H. Ayreault DGA-GESMA Goal driven planning and adaptivity for AUVs 

M. Barbier ONERA-CERT 

N. Dulac INTEMPORA 

D. Dufourd DGA-SPART 

D. Duhaut VALORIA 

A. Godin DGA-ETAS 

ProCoSA: a software package for autonomous 

system supervision 

RT-MAPS: a modular software for rapid 

prototyping of real-time multisensor 

applications 

Integrating human/robot interaction into 

robot control architectures for defence 

applications 

Horocol language and Hardware modules for 

robots 

Pleading for open modular architectures in 

robotics 

F. Ingrand LAAS-CNRS LAAS architecture: Open Robots 

J. Malenfant LIP6 

L. Nanatchamda LISYC 

C. Novales LVR 

R. Passama / D. Andreu LIRMM-CNRS 

M. Perrier IFREMER 

P. Pomiers ROBOSOFT 

J.P. Quin THALES 

N. Ricard / C. Rousset ECA 

D. Simon INRIA 

O. Simonin UTBM 

C. Tessier CEMAGREF 

L. Walle 

ECA 

(CYBERNETIX) 

208 

An Asynchronous Reflection Model for Objectoriented 

Distributed 

Reactive Systems 

Architectures logicielles pour la robotique et 

sûreté de fonctionnement 

A multi-level architecture controlling robots 

from autonomy to teleoperation 

Overview of a new Robot Controller 

Development Methodology 

Advanced Control for Autonomous Underwater 

Vehicles 

Modular distributed architecture for robotics 

embedded systems 

Compared Architectures of Vehicle Control 

System (Vetronics) and application to an UXV 

DES (Data Exchange System), a 

publish/subscribe architecture for robotics 

Orccad, a framework for safe control design 

and implementation 

Reactive Multi-Agent approaches for the 

Control of Mobile Robots 

A Real-Time, Multi-Sensor Architecture for 

fusion of delayed observations: Application to 

Vehicle Localisation 

Remote operation kit with modular conception 

and open architecture: the SUMMER concept


List of participants 

Name Surname Organism E-mail 

Afilal Lissan URCA-CReSTIC lissan.afilal@univ-reims.fr 

Andreu David LIRMM-CNRS andreu@lirmm.fr 

Arias Soraya INRIA soraya.arias@inrialples.fr 

Ayreault Hervé DGA-GESMA herve.ayreault@dga.defense.gouv.fr 

Barbier Magali ONERA-CERT barbier@cert.fr 

Benlazreg Ibrahim LIRMM-CNRS benlazre@lirmm.fr 

Boisgerault Sébastien EMP sebastien.boisgerault@ensmp.fr 

Briand William LIRMM-CNRS briandwilliam@hotmail.com 

Chausse Frédéric LASMEA chausse@lasmea.univ-bpclermont.fr 

Christ Guillaume DCN guillaume.christ@dcn.fr 

Delaunay Claire clairedelaunay@gmail.com 

Dony Christophe LIRMM-CNRS dony@lirmm.fr 

Dufourd Delphine DGA-SPART delphine.dufourd@dga.defense.gouv.fr 

Duhaut Dominique VALORIA dominique.duhaut@univ-ubs.fr 

Dulac Nicolas INTEMPORA nicolas.dulac@intempora.com 

El Jalaoui Abdellah LIRMM-CNRS eljalaou@lirmm.fr 

Fabiani Patrick ONERA-CERT patrick.fabiani@onera.fr 

Fraisse Philippe LIRMM-CNRS fraisse@lirmm.fr 

Franchi Eric ECA ef@eca.fr 

Godary Karen LIRMM-CNRS godary@lirmm.fr 

Godin Aurélien DGA-ETAS aurelien.godin@dga.defense.gouv.fr 

Hygounenc Emmanuel DCN emmanuel.hygounenc@dcn.fr 

Ingrand Felix LAAS-CNRS felix@laas.fr 

Joyeux Sylvain LAAS-CNRS sylvain.joyeux@m4x.org 

Kapellos Konstantinos TRASYS konstantinos.kapellos@trasys.be 

Kheddar Abderrahmane AIST/CNRS kheddar@ieee.org 

Lacroix Simon LAAS-CNRS Simon.Lacroix@laas.fr 

Lapierre Lionel LIRMM-CNRS lapierre@lirmm.fr 

Libourel Thérèse LIRMM-CNRS libourel@lirmm.fr 

Malenfant Jacques LIP6 Jacques.Malenfant@lip6.fr 

Moline Eric DGA-CEP eric.moline@dga.defense.gouv.fr 

Morillon Joel THALES joel-g.morillon@fr.thalesgroup.com 

Mourioux Gilles LVR Gilles.Mourioux@bourges.univ-orleans.fr 

Nanatchamda Laurent LISYC nana@univ-brest.fr 

Novales Cyril LVR Cyril.Novales@bourges.univ-orleans.fr 

Parodi Olivier LIRMM-CNRS parodi@lirmm.fr 

Passama Robin LIRMM-CNRS passama@lirmm.fr 

Perrier Michel IFREMER Michel.Perrier@ifremer.fr 

Pissard-Gibollet Roger INRIA Roger.Pissard@inrialpes.fr 

Pomiers Pierre ROBOSOFT pierre@robosoft.fr 

Quin Jean-Philippe THALES jphquin@aol.com 

Ricard Nicolas 

ECA nr@eca.fr 

Rousset Christophe ECA cro@eca.fr 

Simon Daniel INRIA Daniel.Simon@inrialpes.fr 

Simond Nicolas EMP nicolas.simond@ensmp.fr 

Simonin Olivier UTBM olivier.simonin@utbm.fr 

Tessier Cédric CEMAGREF cedric.tessier@cemagref.fr 

Trapier Manoel LIRMM-CNRS trapier@lirmm.fr 

Villenave Dominique ROBOSOFT dominique.villenave@robosoft.fr 

Walle Laurent ECA (CYBERNETIX) laurent.walle@cybernetix.fr 

Zapata René LIRMM-CNRS zapata@lirmm.fr 

209

Pleading for open modular architectures - Lirmm

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?