Apports d’une approche à composants pour les architectures de contrôle de robots

les architectures de contrôle de robots

Robin Passama

Christophe Dony

Thérèse Libourel

David Andreu

Laboratoire d’Informatique de Robotique et de Microélectronique de Montpellier (LIRMM)

* Département Informatique ,^** Département Robotique Université Montpellier II

161 rue Ada, 34392 Montpellier cedex 5, France

{passama, dony, libourel, andreu}@lirmm.fr

RÉSUMÉ. Cet article présente une synthèse des principes d’organisation des architectures de contrôle de robots et des pratiques communément utilisées pour leur description. Il montre en quoi les approches à composants permettent de répondre à un ensemble de besoins liés à l’application de ces pratiques et de ces principes d’organisation. Enfin, il présente un langage à composants qui intègre l’ensemble des apports identifiés sous la forme de différentes catégories de composants.

ABSTRACT.This paper presents a synthesis of the principles of organization of robot control ar- chitectures and the practices commonly used to their description. It shows the contributions of component-based approaches in order to satisfy the emergents needs and practices during con- trol architecture description. Finally, it presents a component-based language which integrates identified contributions in the form of different component categories.

MOTS-CLÉS :Architecture de contrôle, Composants logiciels, Robotique

KEYWORDS:Control Architecture, Software Component, Robotics

. Volume /2006, pages à

1. Introduction

La robotique de service est un domaine actuellement en pleine expansion car elle se présente comme un marché dont les profits annoncés dans le futur sont colossaux.

La robotique de service englobe les toutes dernières générations de robots qui ap- portent aux humains - de façon mobile et autonome (ou semi-autonome) - une aide concrète dans une multitude de circonstances. La robotique de service permettra de développer, dans un futur proche, un ensemble d’activités comme la sécurité, la mé- decine assistée, la domotique, l’assistance aux personnes agées, etc. La complexité de conception de ces robots est sans commune mesure avec celle des chaines de montage automatisées, car les robots de services sont plus autonomes (autonomie décisionnelle, autonomie énergétique, autonomie d’action), tout en laissant la possibilité à l’homme d’en prendre le contrôle. Un des enjeux actuels est de fournir des méthodes et outils pour rendre la conception des robots plus rapide et de meilleure qualité. Cet enjeu est très large, car il couvre la conception des parties mécaniques, électroniques et informa- tiques d’un robot. Nous limitons notre réflexion à la conception et au développement des contrôleurs de ces robots, c’est-à-dire les logiciels embarqués qui donnent aux robots leur autonomie décisionnelle et leur autonomie opérationelle. Un contrôleur est une application complexe à développer car elle fait appel, le plus souvent, à des expertises variées (intelligence artificielle, planification, commande, navigation, mo- délisation de systèmes physiques, etc.). A l’heure actuelle, les roboticiens manquent de méthodologies et d’outils logiciels adaptés, pour réifier les expertises au niveau lo- giciel, les intégrer dans des architectures de contrôle et les rendre réutilisables. Afin d’assurer la “qualité de conception” des contrôleurs, il est également essentiel d’utili- ser des moyens de description permettant d’assurer, dans une certaine mesure, que le contrôleur, ou certaines de ses briques, vont fonctionner correctement. Les approches à composants sont particulièrement prégnantes pour la gestion de la réutilisation, de l’intégration, de la modularité et plus généralement de la qualité qualité des architec- tures logicielles durant un processus de développement.

Dans ce contexte, l’objectif de cet article est de faire une synthèse des démarches de conception d’architectures de contrôle en robotique, et de montrer en quoi une approche à composants satisfait plusieurs des préoccupations rencontrées. Nous illus- trerons une façon de mettre en œuvre l’ensemble des constats retenus à travers un langage à composants dédié. Proposer un langage dédié nécessite de comprendre la façon dont sont construites les architectures de contrôle. La section 2 présente les dif- férentes approches de conception en robotique et se conclut avec une synthèse des principes d’organisation de ces architectures. La section 3 présente les apports du gé- nie logiciel à composants pour la conception des architectures de contrôle. La section 4 présente le langage CoSARC, issu des réflexions menées dans les section précé- dentes. La section 5 conclut l’article et présente les travaux actuels et perspectives de ce travail.

2. Architectures de contrôle de robot : principes d’organisation

Selon F. Ingrand [ING 03], l’architecture d’un contrôleur (plus communément ap- pelée architecture de contrôle) définit les entités logicielles et matérielles (capteurs, actionneurs, noeuds de calcul, etc.) utilisées pour réaliser le système de prise de déci- sions d’un robot, ainsi que les modalités d’interaction entre ces entités.

2.1. Approches pour la conception d’architectures de contrôle

Historiquement, il existe deux approches majeures pour la conception d’archi- tectures de contrôle en robotique : une approche dite hiérarchisée et une approche dite comportementale. Les architectures hiérarchisées sont organisées en plusieurs couches superposées [GAT 98] [ALB 97] [ALB 02]. Une couche est une abstraction d’un “niveau de prise de décision”, décrit à partir d’un ensemble d’entités logicielles.

Les entités logicielles d’une couche ne peuvent communiquer directement qu’avec les entités logicielles de la couche directement inférieure et celles de la couche directe- ment supérieure. Une couche contrôle les activités de la couche directement inférieure et ses activités sont contrôlées par la couche directement supérieure. La couche la plus haute dans la hiérarchie, encapsule les mécanismes de planification et de supervision.

La couche la plus basse encapsule les entités qui s’interfacent avec les entrées/sorties matérielles (capteurs et actionneurs). Les couches intermédiaires encapsulent les mé- canismes d’asservissement de la partie mécanique, d’observation de l’environnement, d’adaptation des asservissement actifs ou encore les mécanismes de navigation. L’in- formation se propage verticalement d’une couche à une autre, en traversant toutes les couches intermédiaires. Lorsqu’elle remonte à travers des couches (information sur l’état du robot ou de l’environnement), elle est transformée (e.g. fusion de données) en une information de plus en plus abstraite. Inversement, lorsqu’elle redescend à travers les couches (information sur la décision à appliquer) elle devient de moins en moins abstraite (jusqu’à devenir des données numériques transmises aux actionneurs).

Le principal problème des contrôleurs conçus avec de telles architectures, vient de leur manque de réactivité : l’information doit systématiquement traverser les couches in- termédiaires pour atteindre la couche où elle sera effectivement prise en compte, aug- mentant ainsi le nombre de traitements intermédiaires. Dans la plupart des cas, une couche ne peut être active que si les couches supérieures ne le sont pas, ce qui oblige à remettre le robot dans un état stable dès lors qu’il doit adapter son contrôle ou plani- fier une mission. L’avantage de ces architectures est que leur structuration en couches permet à l’homme de maîtriser et comprendre facilement leur fonctionnement.

Les architectures comportementales [BRO 86] sont constituées d’un ensemble d’en- tités logicielles autonomes qui s’exécutent en parallèle et qui sont appelées compor- tements réactifs. Un comportement réactif [AYE 95] perçoit un ensemble de stimuli (vu comme un vecteur d’état constitué à partir des données capteurs les plus à jour) et génère une réaction du robot (vue comme un vecteur de données de commande mo- teurs). Chaque comportement réactif possède une finalité propre pour le contrôle du

robot (e.g. “se diriger vers la source de lumière la plus proche”, “éviter les obstacles”).

Ces comportement réactifs peuvent générer, au même moment, des réactions qui sont contradictoires. Par exemple, si un comportement réactif fait que le robot est attiré par une source de chaleur et qu’un autre fait que le robot s’éloigne quand la tempéra- ture devient trop importante, les réactions qu’ils génèrent peuvent être opposées à un moment donné, l’une tendant à éloigner et l’autre à rapprocher le robot de la source de chaleur. C’est pourquoi ces architectures intègrent un mécanisme d’arbitrage (qui varie en fonction des architectures), qui permet au robot d’adopter un comportement global cohérent en fonction de la tâche courante qu’il a à accomplir. Ce mécanisme ré- cupère périodiquement l’ensemble des réactions générées par les comportements réac- tifs, et définit en fonction les données de commande à appliquer aux actionneurs. Dans les architectures comportementales, le comportement global d’un robot est émergent [BRO 98], issu d’une composition des comportements réactifs “atomiques” (somma- tion et pondération des vecteurs de commande générés). Le comportement global du robot est fortement réactif (car l’information n’est pas traitée par de nombreux inter- médiaires), mais difficilement compréhensible et maîtrisable par l’homme (à cause de sa nature émergente).

Architectures comportementales et architectures hiérarchisées sont construites à partir de “philosophies” de développement très différentes. Les architectures hiérar- chisées sont contruites avec la volonté de contrôler la façon dont le robot réalise sa mission, quitte à sacrifier certaines de ses capacités d’adaptation et une partie de sa ré- activité. Les architectures comportementales sont construites avec la volonté de laisser le comportement global du robot émerger de son interaction avec l’environnement, quitte à sacrifier (en partie) le contrôle que l’homme a sur lui pendant le déroule- ment de sa mission. Actuellement, les roboticiens tentent de faire un compromis entre ces deux approches, afin d’en tirer les bénéfices mutuels. Cette nouvelle approche est qualifiée d’hybride ou de mixte. Des exemples d’architectures mixtes sont celles du LAAS [ALA 98], les architectures ORCCAD [BOR 98], 3T [BON 95] et CLARATy [NES 01]. La plupart de ces architectures proposent de structurer les architectures de contrôle en une hiérarchie de couches, comme les architectures délibératives. Mais pour gagner en réactivité, elles permettent à l’information (données d’états ou données représentant les décisions) de “sauter” des couches, lorsque c’est possible. En parti- culier, les événements, détectés dans les couches basses, doivent pouvoir être trans- mis directement aux couches supérieures concernées par la réaction à l’événement, sans traverser les couches intermédiaires. En conséquence, les activités au sein d’une couche peuvent être sous le contrôle de plusieurs couches supérieures et contrôler plu- sieurs couches inférieures. D’autres architectures, notamment les architectures AURA [ARK 97], vont plus loin en intégrant dans leur couche basse une approche compor- tementale (comportements réactifs à partir desquel émerge un comportement global), en permettant aux couches supérieures de contrôler l’exécution de cette couche (ac- tivation/désactivation des comportements réactifs). L’autonomie des comportement réactifs est donc réduite au profit du contrôle de leurs activités par les entités des couches supérieures. Les architectures IDEA [MUS 02] et Chimera [STE 01] pro- posent également une forme d’organisation différente de celle en couche : les entités

logicielles sont regroupées en sous-systèmes (agents dans IDEA) qui encapsulent le contrôle d’une partie identifiée de la partie opérative d’un robot (mécanique, capteurs et actionneurs). Par exemple, un sous-système de vision encapsule le contrôle des ca- méras embarquées et les traitements réalisés sur les flots d’images ; un sous-système de locomotion contrôle le véhicule (déplacement, navigation) qui permet au robot de se déplacer dans l’environnement. Un robot est, in fine, constitué d’un ensemble de sous-systèmes en collaboration. Chaque sous-système encapsule des mécanismes de supervision, voire de planification dans IDEA, ainsi que les mécanismes d’asservisse- ment et d’observation classiques. Cette forme d’organisation est orthogonale à celle en couche, car un sous-système peut être décrit à partir d’entités logicielles apparte- nant à plusieurs couches différentes. Les architectures CLARATy [NES 01] ont pour originalité de formaliser une pratique de programmation courante en robotique, qui consiste à réifier les connaissances que le contrôleur possède sur le “monde réel” (e.g.

données représentant l’environnement et leurs traitement associés ; propriétés phy- siques, géométriques et cinématiques de la partie matérielle du robot). Celà permet, en particulier, de séparer la description du “monde réel”, de celle des activités que le robot a pendant sa mission (la façon dont il prend et applique des décisions à par- tir de ces connaissances). C’est un biais très intéressant pour organiser la conception d’une architecture de contrôle et celà permet, de plus, de réutiliser indépendamment les entités représentant les connaissances, de celles en charge du contrôle des activités du robot, constitutives des couches (qui sont plus spécifiquement liées à la finalité du robot considéré).

2.2. Synthèse : caractéristiques des entités logicielles

Nous distinguons deux sortes d’entités logicielles dans une architecture de contrôle : les entités de contrôle et les entités de représentation. Chaque couche d’une architec- ture est constituée d’un ensemble d’entités logicielles, que nous qualifions d’entités de contrôle. La diversité de ces entités est importante, allant d’un asservissement, d’une observateur d’état ou d’un comportement réactif, jusqu’à des mécanismes de planifi- cation ou de supervision de mission. Une entité de contrôle met en œuvre un cycle perception - décision - action, contrôlé par des intentions et dont l’activité peut être observée via les observations qu’il génère (cf. figure 1).

Les perceptions d’une entité de contrôle correspondent à des observations pro- venant des couches inférieures (des entrées/sorties matérielles pour la couche logi- cielle la plus basse). L’entité de contrôle s’appuie sur ses perceptions afin connaitre les états “observés” de l’environnement et de la partie matérielle contrôlée, ou l’état des activités des couches inférieures. A partir de ses perceptions et en fonction de son état d’exécution interne, elle définit un contexte d’exécution courant. La déci- sion est le mécanisme via lequel une entité de contrôle détermine le comportement qu’elle doit adopter en réaction à l’évolution de son contexte. Par exemple, pour des entités de la couche la plus basse, le mécanisme de décision est vu comme le cal- cul périodique de la correction à apporter aux mouvements d’un robot, en fonction

décision

perceptions actions

observations intentions

connaissances

(mesures capteur, données reconstituées, événements, etc.)

(commandes actionneurs, ordres symboliques, etc.)

connaissances connaissances

connaissances connaissances

Couche supérieure

Couche inférieure

Figure 1. Modèle d’une entité logicielle

d’une loi de commande. Dans les couches les plus hautes, la réaction calculée peut être le résultat de l’exécution de mécanismes de planification ou d’apprentissage. Les actions que l’entité de contrôle doit entreprendre sont définies par le mécanisme de décision. Les actions émisent par une entité de contrôle correspondent à des inten- tions reçues par les couches inférieures. Elles permettent de contrôler ou d’influencer les activités des couches inférieures. Par exemple, pour une entité de la couche la plus basse, une action peut simplement consister à fixer la valeurs des commandes envoyées aux actionneurs. Pour une entité d’une couche plus haute, une action peut passer par de nombreuses interactions avec les entités de plus bas niveau dans le but par exemple de reconfigurer/arrêter/démarrer des asservissements. Chaque entité de contrôle reçoit un ensemble d’intentions des entités des couches supérieures, qui vise à contrôler/influencer son cycle perception - décision - action ou à lui demander des observations (état qu’elle observe, suivi de ses activités, etc.).

Les entités de contrôle échangent à l’exécution, des connaissances qui représentent, à différents niveaux d’abstraction, l’état observé ou souhaité du robot et de l’environ- nement. Elle partagent également des connaissances propres à leur activités, typique- ment des connaissances sur la partie mécanique du robot. Par exemple, si deux entités de contrôle décrivent un asservissement sur un même élément mécanique, comme un bras manipulateur, alors elles partagent la même connaissance “statique” de ce bras (propriétés physiques, géométriques et cinématiques). Cette connaissance est reifiée dans des entités que nous nommons entités de représentation, qui sont de nature dif- férente de celle des entités de contrôle. Elle permettent de décrire les données et trai-

tements sur lesquels s’appuient les mécanismes perception/décision/action des entités de contrôle (connaissances échangées et connaissances internes).

2.3. Synthèse : modèle d’organisation des architectures de contrôle

Les principes d’organisation essentiels des architectures de contrôle sont synthé- tisés dans un modèle générique (cf. fig. 2). Ce modèle montre une décomposition d’une architecture de contrôle en un ensemble de couches hiérarchisées (sans pour au- tant fixer le nombre de couches). Une couche est constituée d’entités de contrôle qui peuvent contrôler les activités des entités de contrôle des couches inférieures et dont les activités sont contrôlées par les entités de contrôle des couches supérieures. Des critères permettent de caractériser la hiérarchisation des couches. Plus une couche est haute dans une architecture, plus les mécanismes de décision utilisés par les entités de contrôle qu’elle contient, sont complexes. En conséquence plus une couche est haute dans l’architecture et plus les connaissances manipulées par les entités de contrôle qu’elle contient sont abstraites. A partir de ces critères, il est possible de définir des contraintes sur l’organisation des couches :

– Plus une couche est haute dans une architecture, et plus sa priorité de réaction (application de son cycle perception/décision/action) à un changement de contexte est importante : une décision prise dans une couche doit être répercutée prioritairement sur les décisions prises dans les couches inférieures. Ceci s’explique par le fait qu’une couche haute possède, de par sa nature, une vision plus globale qu’une couche basse, du déroulement de la mission du robot, et les décisions qu’elle prend sont par consé- quent plus importantes, pour le déroulement de la mission du robot.

– Plus une couche est basse dans une architecture, et plus les contraintes tempo- relles qui s’imposent à son exécution sont fortes. En effet, les échelles de “temps de réaction” (temps d’application d’un cycle percetion - décision - action) des entités de contrôle varie en fonction de chaque couche. Dans une couche basse, les asservisse- ments et les observateurs ont des comportements périodiques basés sur une échelle de “temps de réaction” suffisamment petite pour assurer le contrôle permanent de la partie matérielle du robot (le plus souvent de l’ordre de quelques millisecondes). Dans les couches intermédiaires, se trouvent les entités de contrôle en charge de l’adapta- tion/configuration des asservissements et observateurs actifs. Ces entités de contrôle ont des comportements le plus souvent apériodiques et leur échelle de “temps de réac- tion” est plus grande que celle de la couche basse (de l’ordre de quelques dixaines de millisecondes). Dans les couches les plus hautes, se trouvent les entités de contrôle en charge de la planification et de la supervision de missions, qui ont des comportements apériodiques dont l’échelle de “temps de réaction” est grande (de l’ordre de plusieurs secondes, voire plusieurs minutes).

Dans ce modèle, basé sur une approche hybride, les interactions prennent dif- férentes formes typiques. Une entité de contrôle peut émettre une observation vers des entités de contrôle appartenant à une ou plusieurs couches supérieures, simul- tanément (e.g. notification d’événement, diffusion de données, écriture de mémoire

Couche basse Couche haute

+ : Complexité des mécanismes de délibération ; Abstraction des connaissances ; Priorité de réaction

+ : Contraintes temporelles de réaction

Couche Physique

Interaction entre entités de

contrôle Entité de

contrôle Sous-système Couche

intermédiaire

Figure 2. Organisation au sein des architectures de contrôle

partagée). Une entité de contrôle peut avoir une perception associée à un ensemble d’observations provenant de couches inférieures, ce qui peut nécessiter un protocole d’interaction adapté à un mécanisme fusion de données (e.g. gérant l’étiquetage et le regroupement temporel des messages échangés). A partir des observations reçues chaque entité de chaque couche décide des observations quelle émet et décide de sa réaction (d’une décision “rapide” dans les couches basses, vers une décision “longue”

dans les couches hautes). La réaction se traduit par l’envoie d’un ensemble d’actions aux entités de contrôle des couches inférieures. Une même action correspond à une intention reçue par une (e.g. démarrage d’un asservissement) ou plusieurs entités de contrôle (e.g. mise en compétition de comportements réactifs de même finalité). Une intention reçue peut également correspondre à des actions provenant de plusieurs en- tités des couches supérieures. C’est la forme d’interaction qui par exemple caractérise les protocoles utilisés dans les architectures comportementales : plusieurs comporte- ments réactifs autonomes (conceptuellement situés dans la même couche) génèrent périodiquement des vecteurs de données commandes (qui correspondent à leur ac- tions) et l’échange de ces vecteurs avec l’entité en charge du mécanisme d’arbitrage nécessite un protocole d’interaction adapté (e.g. protocole de vote dans AURA, pro- tocole de gestion d’une mémoire partagée suivant une approche subsumption). Gérer

l’hybridation des architectures de contrôle demande en premier lieu de gérer des in- teractions de natures et de complexités variables.

La figure 2 montre également le principe d’organisation “systémique”, orthogonal à celui en couches. L’architecture de contrôle dans sa globalité est un système qui se décompose en un ensemble de sous-systèmes. Un (sous-)système agrège un ensemble d’entité de contrôle, en fonction de leurs finalités et des éléments matériels qu’elles contrôlent. Il abstrait donc une partie d’une architecture de contrôle, afin de rendre possible la description d’interaction entre sous-systèmes à différents niveaux de granu- larité. Un sous-système peut être agrégé dans un autre (sous-)système, qui représente le contrôle d’une partie matérielle plus importante (par exemple, les sous-systèmes de vision et de manipulation devraient pouvoir être agrégés dans un sous-système repré- sentant le robot mobile dans sa globalité).

2.4. Besoins émergents

Décrire et implanter une architecture en suivant ce modèle d’organisation pose un ensemble de questions qui correspondent à autant de besoins :

– Comment décrire/implanter les couches et leur hiérarchisation ? En particulier, comment intégrer dans la description des couches, les informations nécessaires à la gestion des contraintes liées à leur hiérarchisation ? (priorité de réaction et contraintes temporelles de réaction).

– Comment décrire les entité de contrôle, avec quelle notation décrire leurs com- portements ? En particulier, il semble nécessaire d’utiliser une notation qui permette d’utiliser des techniques pour la vérification/validation de propriétés comportemen- tales.

– Comment proposer un modèle d’organisation “systémique”, tout en conservant une organisation en couches ? Il est nécessaire de pouvoir décrire des architectures de contrôle à différents niveaux de granularité et de permettre la réutilisation de parties d’architectures.

– Comment différencier les entités représentant les connaissances qu’à le contrô- leur sur le “monde réel”, des entités de contrôle qui composent le système de prise de décision ?

– Comment décrire et réutiliser les interactions aussi indépendamment que pos- sible des entités de contrôle ? Dans les architectures de contrôle, les protocoles d’in- teraction utilisés caractérisent le style architectural choisi. Par exemple, le style des architectures AURA repose sur l’utilisation d’un protocole de vote (pour les interac- tions entre mécanisme d’arbitrage et comportements réactifs), d’un protocole de no- tification d’événements (pour l’émission les observations) et d’un protocole d’envoi de requêtes (pour l’émission des actions) . Un même style pouvant être utilisé pour différentes architectures, les protocoles utilisés devraient être pleinement réutilisables à travers toutes ces architectures.

3. Apports des architectures à composants

L’utilisation de techniques de génie logiciel, pour la conception d’architectures de contrôle de robot, reste à ce jour marginale. Pourtant le génie logiciel à composants [SZY 99] apporte des réponses à la plupart des besoins existants. Globalement, une ap- proche à composants amène, au même titre qu’une approche à objets, la lisibilité des architectures logicielles (i.e. la mise en correspondance explicite entre les concepts

“métiers” et les composants logiciels). Elle favorise également la réutilisation des composants et la modularité des architectures, à travers le modèle de composition ap- pelé “assemblage tardif”. L’assemblage tardif est le mécanisme qui consiste à mettre en relation les composants logiciels en connectant leurs ports. La différence fonda- mentale entre ce mécanisme de composition et celui traditionnel des objets, est que la composition n’est définie qu’après la création des instances de composants et non au moment de la définition de leurs types (qui définissent uniquement les contraintes quant aux possibilités d’assemblage). Au delà de ces avantages généraux, certaines approches à composants possèdent des propriétés particulièrement prégnantes pour la conception et le développement des architectures de contrôle :

– Les notions de composants composites dans les modèles de composants comme Fractal [BRU 02] et de configurations dans les ADLs [MED 97], sont adaptées à la description d’une organisation “systémique” des architectures. Ces deux notions re- posent sur un mécanisme de composition appelé agrégation, qui consiste à encapsuler une architecture logicielle (i.e. un assemblage de composants, dynamique ou non) dans un composant réutilisable. Un (sous-)système étant vu comme un agrégat d’en- tités de contrôle et de sous-systèmes, le mécanisme d’agrégation des composants est adapté à leur description.

– La notion de connecteur, issue des ADLs comme Wright [ALL 97] et ArchJava [ALD 03], permet de réifier des protocoles d’interaction entre composants sous la forme d’entités réutilisables. Un connecteur est une entité de première classe, ce qui permet aux développeurs de créer et de réutiliser de nouveaux protocoles.

– Plus généralement, nous constatons que dans les ADLs, chaque préoccupation durant le processus de conception d’une architecture est gérée à partir d’une entité de première classe spécifique. En généralisant cette approche à notre contexte, la sé- paration de la préoccupation de description du “monde réel” de celle de description des activités du robot, est possible en fournissant deux entités de première classes différentes (entités de représentation et entités de contrôle). Celà permet de gérer in- dépendamment la nature respective de ces entités, en leur définissant des propriétés propres et des modèles d’exécution adaptés.

– Plusieurs modèles et langages à composants fournissent les moyens de décrire et de réaliser le déploiement d’une architecture logicielle, à l’image de MetaH [BIN 96]

ou du CCM [MAR 01]. Ils permettent en particulier de représenter le déploiement d’une architecture “logique” sur l’infrastructure (matérielle et système) sur laquelle elle s’exécute. Cette phase, souvent appelée projection, permet de configurer l’archi- tecture “logique” en fixant certaines de ses propriétés en fonction des services offerts par le système d’exploitation ou l’intergiciel. Le déploiement est le moment adéquat

pour gérer les propriétés liées à la hiérarchisation des couches. En effet, les priorités de réaction et les contraintes temporelles de réaction, associées aux couches, peuvent être traduites sous la forme de propriétés de niveau système, qui nourrissent un mécanisme d’ordonnancement adapté. Le concept de conteneur comme environnement d’exécu- tion de composants (issu de propsition comme CCM [MAR 01]), permet de fixer les propriétés systèmes pour un groupe de composants au moment de leur déploiement.

Un conteneur semble donc être la bonne “unité” pour représenter une couche et y associer des propriétés liées à sa hiérarchisation. Celà permet également de gérer la hiérarchisation d’une architecture à un moment différent (déploiement) de la descrip- tion “systémique” (conception).

– Des ADLs comme Wright [ALL 97] reposent sur l’utilisation d’une notation formelle pour décrire le comportement des composants ainsi que leurs interactions.

L’intéret de ces approches est qu’elles proposent des techniques d’analyse, permettant de vérifier des propriétés sur des composants (e.g. invariants) ou de valider des compo- sitions (e.g. absence d’inter-blocage). Une description basée sur une notation formelle est un premier pas vers une meilleure qualité des applications logicielles, aspect par- ticulièrement important pour les contrôleurs de robots. Cette notation doit permettre de décrire les comportements et interactions des entités de contrôle et et de gérer en particulier des activités concurrentes et leur synchronisation. La notation des réseaux de Petri à Objets (RdPO) [SIB 85], déjà utilisée dans des modèles à objets concur- rents [SIB 98], possède des avantages non-négligeables dans notre contexte. Elle est manipulable sous une forme graphique, ce qui a tendance à faciliter leur utilisation comparé à d’autres notations formelles comme CSP dans Wright [ALL 97]. Les pro- priétés formelles et les techniques d’analyse des réseaux de Petri ont, de plus, déjà été largement étudiées, tout comme leur utilisation pour la modélisation de problèmes en automatique et en robotique. Enfin, un RdPO peut être vu comme du code informa- tique, exécutable via un interpréteur : la notation RdPO peut donc être vue comme un langage de programmation. La possibilité de transformer un modèle RdPO en code équivalent est un facteur de qualité important, car cela assure que le code exécuté suit strictement les spécifications (par opposition à une approche où les développeurs doivent “écrire” le code correspondant au modèle comportemental, ce qui n’assure en rien que sa conformité aux spécifications comportmentales).

A partir de l’ensemble de ces constats, nous proposons un langage à composants, dédié à la conception et au développement d’architectures de contrôle, qui synthétise l’ensemble des apports.

4. Le langage CoSARC

Le langage CoSARC (Component-based Software Architcture of Robot Control- lers) fournit un cadre pour la description d’architectures de contrôle et pour la pro- grammation de leurs composants. Tout composant (cf. fig. 3) possède des propriétés internes et des ports. Les propriétés internes d’un composant permettent de définir son implantation, il s’agit par exemple d’attributs et d’opérations. Un port représente

Composant

Propriété Interne

1..*

1..*

Attribut Méthode Interface

Typé par

* 1..1

Connexion 1..* 1..*

connecte

2..*

*

Port

Nature = {fourni, requis}

Figure 3. Modèle des composants CoSARC

un point de connexion d’un composant, via lequel il peut être assemblé et qui relie ses propriétés internes avec les messages qu’il émet et reçoit. Un port est dit fourni lorsque le composant propose à d’autres composant d’utiliser un de ses services, il est dit requis lorsque le composant utilise un service proposé par un autre composant, pour s’exécuter. L’offre ou l’utilisation d’un service est exprimée via une interface (contrat textuel) qui type le port. Les composants sont assemblés par l’établissement de connexions entre leur ports fournis et leur ports requis. Lorsqu’une connexion est établie, la vérification de la conformité des interfaces typant les ports connectés est réalisée, afin d’assurer que l’assemblage est valide. Si ce n’est pas le cas, l’assemblage est refusé. A partir de ce modèle simple, plusieurs sortes de composants ont été défi- nies, afin de gérer indépendamment chaque préoccupation identifiée : les composants de représentation, les composants de contrôle, les connecteurs et les configurations.

– Les composants de Représentation sont utilisés pour décrire les entités représen- tant les connaissances que le contrôleur possède sur le “monde réel”, par exemple : les événements détectés dans l’environnement, une carte de l’environnement, des don- nées de positionnement, des données capteurs et actionneurs, les éléments matériels des robots (bras manipulateur, véhicule, capteurs) et leurs propriétés (géométriques, physique, cinématiques). Les services qu’ils fournissent et requièrent sont essentielle- ment des fonctionnalités de calcul (e.g. calculs basés sur des modèles mathématiques) ou des fonctionnalités d’accès à leurs attributs. Un composant de représentation est une entité passive, c’est-à-dire qu’il ne peut avoir d’activité que pendant l’utilisation d’un des services définis par un de ses port fournis. Les connexions entre ports des composants de représentation établissent un protocole d’interaction synchrone (pré- fixé).

– Les composants de Contrôle sont utilisés pour décrire les entités de contrôle constitutives des couches. Par exemple, ils servent à représenter des activités telles que : l’observation d’états de l’environnement ou de la partie matérielle du robot,

la génération de plans, les asservissements, la gestion des modes de fonctionnement (téléopération, autonomie, coopération multi-robot), l’adaptation des commandes ac- tives, la navigation, etc. Un composant de Contrôle est un composite qui agrège un ensemble de composants de représentation (sous forme d’attributs) qui définissent les connaissances dont il a besoin, en rapport avec les activités qu’il doit mettre en œuvre.

En plus des attributs et des opérations, il a pour propriété interne un comportement asynchrone décrit par un RdPO. Ce comportement décrit le flot de contrôle de ses acti- vités internes (accès concurrent à ses attributs, appels à ses opérations potentiellement parallèles, synchronisation entre les messages qu’il reçoit et ses activités internes).

Les composants de contrôle sont des entités actives, dans le sens où ils peuvent avoir plusieurs activités internes parallèles et que ces activités ne découlent pas forcément directement de l’utilisation d’un de leur services (e.g. activité en “tâche de fond”).

L’assemblage des composants de contrôle est réalisé par la connexion de leurs ports via des connecteurs.

– Les connecteurs sont des composants également vus comme des connexions, spécifiquement utilisés pour la description de protocoles d’interaction. Un connecteur réifie un protocole et le rend réutilisable dans différents assemblages. Par exemple, il représente un protocole de notification d’événements, un protocole de diffusion de données, un protocole de téléopération, un protocole de vote, etc. Lorsqu’une connexion est établie par le biais d’un connecteur, les ports des composants de contrôle ainsi connectés vont être rattachés à un des rôles définis par le connecteur : on dit alors que le composant de contrôle joue le rôle correspondant. Un rôle définit un comportement asynchrone, décrit par un RdPO, qu’adopte un composant de controle, afin d’intéragir de la façon convenue dans le protocole. Par exemple, le connecteur de notification définit deux rôles : le notifieur de l’événement et l’abonné à l’événement.

A l’exécution, le comportement asynchrone défini dans un rôle, permet de “complé- ter” le comportement asynchrone du composant de contrôle qui joue ce rôle (méca- nisme basé sur la fusion des RdPO). Le comportement d’un composant de contrôle est donc “complété” en fonction des rôles qu’il joue effectivement (i.e. de leur im- plantation dans les connecteurs utilisés). A chaque rôle est associée un port (et donc un interface), qui définit les échanges de messages entre le composant jouant le rôle et le connecteur. Les interfaces des composants de contrôle sont définies en fonction des interfaces des rôles, ce qui couple le composant de contrôle à un rôle donné mais le rend plus indépendant des connecteurs utilisés pour le connecter (n’importe quel connecteur proposant de jouer ce rôle).

– Les configurations sont les composants utilisés pour décrire et réutiliser des (sous-)systèmes. Une configuration agrège un ensemble de composants de contrôle assemblés via un ensemble de connecteurs (i.e. une architecture logicielle). Un port d’une configuration exporte un port d’un ou plusieurs des composants de contrôle qu’elle agrège et il est typé par l’interface du ou des ports exportés. Une configura- tion est donc assemblable de la même façon qu’un composant de contrôle (i.e. via des connecteurs) ce qui permet d’adopter une approche “systémique”. Le déploie- ment d’une configuration sur une infratructure matérielle/système est représenté via des concepts spécifiques : les noeuds de calcul et les conteneurs. Les composants

de contrôle sont placés dans des conteneurs (environnements d’exécution pour des composants de contrôle et pour les rôles qu’ils jouent), qui sont eux-mêmes exécutés sur des noeuds de calculs physiques. Un conteneur, qui correspond à un processus système, permet de représenter de façon explicite les couches d’une architecture de contrôle, et de fixer les propriétés liées à la hiérarchisation des couches. A l’heure actuelle, la priorité de réaction est traduite sous la forme de priorités système entre conteneurs, mais nous souhaitons dans le futur, définir un mécanisme d’ordonnan- cement multicritères qui prenne en compte, en plus, les contraintes temporelles de réaction des couches. Notre approche consiste donc à adopter en premier lieu une ap- proche “systémique” afin de décrire les assemblages entre composants de contrôle à différents niveaux de granularité, puis dans un deuxième temps, une approche “hiérar- chique” pour déterminer les contraintes d’exécution liées à la gestion de la réactivité.

5. Conclusion

L’analyse des diverses proposition hsitoriques relatives à la conception d’archi- tecture de contrôle en robotique a abouti à la synthèse d’un modèle générique, qui exprime les concepts essentiels liés à la définition des entités logicielles et les prin- cipes guidant leur organisation. A partir de ce modèle, nous avons extrait les besoins liés à la conception de ces architectures et nous avons montré en quoi les approches à composants peuvent satisfaire à ces besoins. Enfin nous avons présenté un langage à composants original, qui traite spécifiquement chaque préoccupation durant le pro- cessus de développement d’un contrôleur et favorise réutilisabilité et modularité.Ce langage sert de base à une méthodologie de développement complète (analyse à exécu- tion). L’environnement d’exécution du langage est spécifié et partiellement implanté.

La méthodologie comme l’environnement font l’objet de publications en cours.

6. Bibliographie

[ALA 98] ALAMIR., CHATILAR., FLEURYS., GHALLABM., INGRANDF., « An architec- ture for autonomy », International Journal of Robotics Research, vol.17, n^◦4 p.315-337, , 1998.

[ALB 97] ALBUS J., LUMIAR., FIALAJ., WAVENINGA., « NASREM : The NASA/NBS standard reference model for telerobot control system architecture », rapport, 1997, Robot System Division, National Institute of Standards and Technologies.

[ALB 02] ALBUSJ.,AL., « 4D/RDC : A reference model architecture for unmanned vehicle systems », rapport, 2002, NISTIR 6910.

[ALD 03] ALDRICHJ., SAZAWALV., CHAMBERSC., NOTKIND., « Language support for connector abstraction », Proceedings of ECOOP’2003, pp.74-102, 2003.

[ALL 97] ALLENR., « A formal Approach to Software Architecture », PhD thesis, Canergie Mellon University, May 1997.

[ARK 97] ARKINR., BALCHT., « AURA : principles and practice in review », rapport, 1997, College of Computing, Georgia Institute of Technology.

[AYE 95] AYERS J., « A reactive ambulatory robot architecture for operation in current and surge », Proceedings of the Autonomous Vehicle in Mine Countermeasures Symposium.

Naval Postgraduate School, pp.15-31, 1995.

[BIN 96] BINNSP., ENGELHARTM., JACKSONM., VESTALS., « Domain Specific Software for Guidance, Navigation and Control », International Journal of Software Engineering and Knowledge Engineering, vol. 6, no.2, , 1996.

[BON 95] BONNASSOR., KORTENKAMPD., MILLERD., SLACKM., « Experiences with an architecture for intelligent, reactive agents », rapport, 1995, NASA Johnson Space center.

[BOR 98] BORRELY J., COSTEMANIER E., ESPIAU B., KAPELLOS. K., PISSARD- GIBOLLETR., SIMOND., TURRON., « The Orccad Architecture », International Journal of Robotics Research, Special issues on Integrated Architectures for Robot Control and Programming, vol 17, no 4, p. 338-359, , 1998.

[BRO 86] BROOKSR., « A robust Layered control system for a mobile robot », IEEE journal of Robotics and Automation, vol. 2, no. 1, pp.14-23, , 1986.

[BRO 98] BROOKSR., BREAZEALC., IRIER., KEMPC., MARJANOVICM., SCASSELLATI

B., WILLIAMSONM., « Alternative Essences of Intelligence », Proceedings of American Association of Artificial Intelligence (AAAI), p. 89-97, July 1998.

[BRU 02] BRUNETON E., COUPAYE T., STEFANI J., « Recursive and Dynamic Software Composition with Sharing », Seventh International Workshop on Component-Oriented Programming (WCOP02) at ECOOP 2002, Malaga, Espagne, Juin 2002.

[GAT 98] GATE., « On three-layer Architectures », A.I. and mobile robots, D. Korten Kamp

& al. Eds. AAAI Press, , 1998.

[ING 03] INGRANDF., « Architectures Logicielles pour la Robotique Autonome », Journées Nationales de la recherche en Robotique JNRR’03, Octobre 2003.

[MAR 01] MARVIE R., MERLEP., GEIB J., LEBLANC S., « OpenCCM : une plateforme ouverte pour composants CORBA », Actes de la deuxième conférence française sur les Systèmes d’Exploitation (CFSE’2), Paris, France, Avril 2001, p. pages 1-12.

[MED 97] MEDVIDOVIC N., TAYLOR R., « A framework for Classifying and Comparing Software Architecture Description Languages », SPRINGER-VERLAG, Ed., 6th European Software Engineering Conference together with th 5th ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE), pages 60-76, Zurich, switzerland, 1997, p. 60-76.

[MUS 02] MUSCETTOLAN., DORAISG., FRYC., LEVINSONR., PLAUNTC., « Idea : Plan- ning at the core of autonomous reactive agents », Proceedings of the 3rd International NASA Workshop on Planning and Scheduling for Space, 2002.

[NES 01] NESNASI., VOLPER., ESTLINT., DASH., PETRASR., MUTZD., « Toward Deve- lopping Reusable Software Components for Robotic Applications », International Confe- rence on Intelligent Robots and Systems, October 2001.

[SIB 85] SIBERTIN-BLANCC., « Hign Level Petri Nets with Data Structure », 6th european workshop on Application and Theory of Petri Nets, 1985.

[SIB 98] SIBERTIN-BLANC C., « CoOperative Objects : Principles, Use and Implementa- tion », Concurrent Object Oriented Programming and Petri Nets, computer science XX, , 1998, G. Agha & F. de Cindio Eds.

[STE 01] STEWART D., « Designing software components for Real-Time Applications », 2001 Embeded System Conference, San Francisco, 2001.

[SZY 99] SZYPERSKI C., Component Software : Beyond Object Oriented Programming, Addison-Wesley, 1999.