Architecture du LAAS

Le LAAS (Laboratoire d'Analyse et d'Architecture des Systèmes, Toulouse, France) propose un environnement logiciel constitué d'outils pour modéliser, programmer, exécu- ter et dans une certaine mesure valider, des architectures de contrôle [27]. Cet environne- ment s'appuie sur un modèle (cf. g. 2.8) qui dénit un découpage d'une architecture de contrôle en trois couches (appelées niveaux dans cette proposition) :

 Le niveau fonctionnel constitue l'interface entre les entités des couches supérieures et la partie physique du système. Il est le siège des fonctions de base du système : fonctions sensori-motrices, fonctions d'asservissement (e.g. navigation), fonctions de traitement (e.g. planicateur de trajectoire, segmentation d'image). Toute fonc- tion est encapsulée dans un module (non donné aux entités logicielles constituant la couche fonctionnelle), généré par l'outil GenoM [28]. Un module ore un en- semble de services accessibles via des requêtes asynchrones (permettant de le dé- marrer/arrêter/paramétrer), chaque service orant un rapport de n d'exécution (i.e. bilan d'exécution). Un module est en charge d'une ressource physique ou lo- gique et dispose des fonctions nécessaires au contrôle de cette ressource, ainsi qu'un contexte d'exécution propre.

 Le niveau de contrôle d'exécution, est en charge de vérier les requêtes envoyées aux modules du niveau fonctionnel et l'utilisation des ressources du robot. Il agit comme un ltre qui peut refuser certaines requêtes (provenant de l'opérateur ou d'un module) en fonction du contexte du robot (actions en cours, ressources utilisées, etc.) et d'un modèle déni par l'opérateur. Ce niveau sert principalement à assurer certaines qualités de robustesse et de sûreté de fonctionnement au contrôleur.  Le niveau décisionnel contient les mécanismes de décision du robot, en particulier

la production et la supervision de plans et la réaction à des situations particulières (e.g. pannes matérielles). Ce niveau comprend deux entités : un exécutif procédu- ral et un planicateur/exécutif temporel. Le planicateur/exécutif temporel gère la planication de la mission globale du robot (production de plans pour réaliser les missions) sur un horizon à long terme. Il peut également replanier une mission en prenant en compte l'ajout et la suppression dynamique de buts (par l'opérateur) et les échecs d'exécution (e.g. time-out ou échec d'une des actions dénies dans le plan). L'exécutif procédural est responsable de la supervision des missions envoyées par les opérateurs humains. Pour cela il interagit avec le planicateur/exécutif tem- porel an que celui-ci génère le plan permettant de réaliser la mission reçue. Une fois ce plan généré, l'exécutif procédural est chargé d'exécuter les actions dénies dans le plan de mission. Pour cela il interagit avec les modules du niveau fonctionnel via le niveau de contrôle d'exécution (qui ltre ses requêtes et les bilans d'exécution des modules fonctionnels). A la n de la réalisation d'une action (terminaison d'un module fonctionnel), il envoie au planicateur/exécutif temporel un bilan notiant un succès ou un échec de l'action courante.

Le modèle d'organisation des architectures de contrôle proposé par le LAAS est basé sur les principes d'organisation des architectures délibératives hiérarchisées. En eet, les mécanismes de délibération (planication et supervision de plans) du niveau décision- nel y sont centraux. A l'image des dernières architectures délibératives hiérarchisées telle que 4D/RCS [24], il existe des mécanismes d'adaptation à diérents endroits : dans la

2.3 Architectures en robotique

Figure 2.8  Modèle d'organisation de l'architecture de contrôle du LAAS [27]

hiérarchie des modules fonctionnels (adaptation des modules fonctionnels utilisés par un module fonctionnel plus global), dans l'exécutif procédural (adaptation, dans une certaine mesure, des modules fonctionnels utilisés pour réaliser une action) et dans le planica- teur exécutif procédural (reformulation sur échec d'action). La décision d'adaptation du comportement du robot peut être prise aux plus hauts niveaux décisionnels (planica- tion), mais peuvent également résulter d'actions réexes programmées dans des modules de la couche fonctionnelle. L'autre constat est que l'information ne fait pas de saut entre les couches, par exemple directement de la couche fonctionnelle vers la couche décision- nelle, elle passe automatiquement par la couche de contrôle d'exécution. On remarque néanmoins que l'interaction entre la couche décisionnelle et la couche fonctionnelle est quasi-directe, la couche de contrôle d'exécution n'existant que pour assurer sûreté et ro- bustesse du contrôle. On pourrait donc voir, in ne, ce modèle d'organisation comme étant à deux couches. Tout ceci rend dicile le classement de ce modèle d'organisation dans la catégorie des architectures délibératives, ou dans celle des architectures mixtes.

L'organisation d'une architecture développée suivant l'approche du LAAS est relati- vement rigide puisqu'elle décrit les couches d'une architecture de contrôle de façon mo- nolithique. En eet, si l'utilité de chaque couche est établie, les diérents types d'entités utilisées au sein de la couche fonctionnelle ne sont pas explicitement identiés. Les types d'entités des couches décisionnelle et exécutive sont pré-xées, et le modèle est fourni avec un ensemble de composants prédénis pour chacun de ces types, l'utilisateur n'ayant qu'à les congurer. Nous pensons que cette vision très agrégée est un frein pour l'identica- tion des diérentes entités. Une vision à grain plus n des diérents niveaux, favoriserait l'identication et la la réutilisation de leurs entités constitutives. Ces propos doivent être nuancés en prenant en compte le fait que la couche fonctionnelle peut être organisée en

Chapitre 2 : Les architectures logicielles de contrôle une hiérarchie de modules en interaction. Identier les diérents types de modules (e.g. asservissement, perception, navigation, etc.) et leurs interactions typiques permettrait de mieux comprendre la façon dont le contrôle est organisé.

Le modèle d'architecture est adapté au développement de systèmes robustes, capables de poursuivre leur mission après des pannes partielles ou des échecs. Il est supporté par un outillage très complet et spécialisé, facilitant la mise en ÷uvre et la validation de certains aspects (mais qui d'autre part, limite la modularité).

 Le planicateur/exécutif temporel IXTET-EXEC permet de générer et exécuter des plans temporels ; il est capable de prendre en compte dynamiquement de nouveaux objectifs de missions et les échecs d'exécution. Il est basé sur des techniques de résolution de problèmes de contraintes (CSP).

 L'exécutif procédural PRS/Propice permet de superviser la réalisation d'actions ; il est réactif aux événements provenant de l'opérateur ou de la couche inférieure.  Le contrôleur d'exécution R2C reconstitue dynamiquement l'état des ressources du

robot (en fonction des requêtes et bilans d'exécution qu'il contrôle) ; il permet de ltrer les requêtes en fonction de cet état et d'un modèle formel des états acceptés ou non.

 L'outil Genom [28] permet de générer les modules du niveau fonctionnel à partir d'une description formelle (basée sur des machines à état nis) du comportement des modules.