Le Superviseur d’Adaptation pour la reconfiguration et l’adaptation locale

Le but de ce nouveau superviseur d’adaptation est, pour un sous-objectif choisi donné, de mettre en œuvre le mode de fonctionnement le plus adapté choisi, ou de reconfigurer localement un module.

Lors de la réception d’un sous-objectif, le superviseur d’adaptation attend que le superviseur contextuel définisse le meilleur mode de fonctionnement en fonction du contexte actuel du robot.

La figure8.6donne à l’aide d’un réseau de Petri une représentation simplifiée du comporte- ment du sous-objectif de suivi de chemin autonome.

LeSUIVI DE CHEMIN SMZ, considéré comme optimal, est activé lors du fonctionnement sain

du robot. Selon la faute rencontrée différentes solutions sont ensuite proposées :

– Une erreur localisée sur le module MCL (Erreur temps réel MCL) peut être corrigée par la RECONFIGURATION de celui-ci en diminuant le nombre de particules du filtre particulaire.

– Une défaillance complète du module SMZ, (SMZ HS) peut être compensée par l’activation duSUIVI DE CHEMINDVZ.

– Si la performance des capteurs ne leur permet pas de représenter l’environnement et que le résidusonar aveugle est activé, l’utilisation du module MCL n’est plus possible. Le choix d’un mode de fonctionnement dégradé est donc fait. (SMZ OU DVZSANS MCL)

– À l’inverse si la capacité des capteurs est retrouvée, (sonar OK),on peut retourner dans un mode de fonctionnement plus performant.

8.4 CONCLUSION 157

Figure 8.6– Représentation du superviseur adaptation en réseau de Petri

– Pour finir, si tous les sonars sont considérés comme hors-service (sonar HS) un mode de fonctionnement sans sonars est engagé. L’utilisation de ce mode autonome est discutable car il ne propose aucune sécurité mais compte tenu de la faible vitesse du robot, nous le considérons comme acceptable. L’interaction Homme-Robot ne sera donc utilisé que si le robot souffre d’un autre dysfonctionnement, par exemple un choc.

La figure 8.6 n’est qu’un modèle partiel car la représentation de tous les liens potentiels pouvant être créés lors du recouvrement asynchrone de capacités surchargerait inutilement le schéma. Ci-dessous sont listées les informations manquantes :

– La reconfiguration du module MCL est accessible du suivi de chemin avec DVZ.

– Le retour après recouvrement des capacités sonars du suivi de chemin avec DVZ sans MCL vers celui comprenant l’algorithme de localisation.

8.4

Conclusion

Ce chapitre a permis d’expliciter et de mettre en œuvre, dans le cadre d’une mission de livrai- son de courrier par un robot Pioneer P3-DX, la méthodologie de construction d’une architecture de contrôle tolérante aux fautes. Pour cela nous nous sommes appuyés sur l’analyse AMDEC préalable que nous avons menée. Celle-ci constitue la pierre angulaire du déploiement, au sein de l’architecture, des mécanismes de tolérance aux fautes, au travers des phases de détection,

diagnostic et recouvrement.

La détection a été intégrée au sein des modes de fonctionnement par l’intermédiaire d’un ensemble de Modules d’Observation dédiés permettant de détecter l’occurrence d’un dysfonc- tionnement.

L’analyse des signatures conduite à partir des résidus ainsi obtenus et des informations ras- semblées dans le tableau de synthèse AMDECpermet de diagnostiquer l’origine des dysfonction- nements, les modules fautifs. Le Module de Diagnostic détermine aussi leur état (opérationnel ou non) et le niveau de sévérité des défaillances.

Enfin le niveau décisionnel a été structuré de façon à déployer les mécanismes de recou- vrement adaptés au contexte fautif identifié. Pour cela un superviseur contextuel, qui peut être considéré comme l’élément central du processus décisionnel, choisit, en fonction des informa- tions contextuelles fournies par le niveau exécutif, et les règles de priorités, définies les actions à engager ainsi que le superviseur auquel elles doivent être appliquées. Celles-ci sont déployées, en fonction de la sévérité estimée de la défaillance au travers de trois superviseurs. Au super- viseur global dédié à la gestion la mission et des évènements à même de la remettre en cause s’ajoutent deux superviseurs pour faciliter la description fonctionnelle des objectifs. Le super- viseur local gère chacun des objectifs de la mission et l’adaptation du niveau d’autonomie de leurs sous-objectifs. Le superviseur d’adaptation met en œuvre pour chaque sous-objectif l’un des modes de fonctionnement potentiels.

Il est important de noter que les réseaux de Petri associés aux superviseurs ne sont que des représentations comportementales car ils sont codés sous la forme de machines à états plus gé- nériques dans l’architecture COTAMA. Le développement actuel de l’architecture ne correspond pas exactement à la structuration proposée dans ce chapitre. En effet, pour en faciliter le déve- loppement, le module de diagnostic et le superviseur contextuel sont pour l’instant regroupés au sein d’un même module appeléModule Global d’Observation (MGO).

Nous disposons maintenant, pour la mission de livraison de courrier, d’une architecture to- lérante aux fautes. Pour clore ce document nous allons détailler et analyser son fonctionnement expérimental.

Cinquième partie

Expérimentation de l’architecture

tolérante aux fautes

Chapitre

9

Description et analyse d’une mission

Cette partie va dans un premier temps énoncer les conditions expérimentales mises en œuvre avant de détailler chacun des points significatifs du déroulement de la mission. Ensuite, avant de conclure, une évaluation du comportement de l’architecture tolérante aux fautes est proposée.

9.1

Conditions expérimentales de la mission

Dans le but de réaliser une mission courte permettant de détecter l’occurrence d’un maxi- mum de défaillances et d’analyser les réactions de recouvrement engagées nous avons décidé de déployer une mission encadrée par des conditions d’évolution spécifiques. Les différents évène- ments qui viendront troubler sont déroulement sont donc scriptés. Ils sont soit introduits volon- tairement dans le code pour perturber le fonctionnement de l’architecture à des dates précises, soit déclenchés manuellement sur le robot ou son environnement. Pour faciliter l’exécution de cette mission et pallier à des soucis récurrents de portée et de précision des sonars, l’expérimen- tation est réalisée HIL (Hardware In the Loop). Le robot est donc posé sur cales pour permettre aux roues de tourner dans le vide et de faire fonctionner le système actionneurs/capteurs. Par conséquent, les sonars sont simulés, à l’aide d’une carte de l’environnement et de la position courante estimée du robot, tandis que les autres capteurs (odométriques et bumpers) et les actionneurs sont réels.

L’objectif de la mission est de récupérer, au sein du laboratoire, un objet au niveau d’un bureau A et de le livrer au bureau B. La figure9.1présente la trajectoire expérimentale suivie par le robot. Elle singularise sur la carte un ensemble de points, numérotés de 1 à 10 où des évènements pertinents ont été observés et qui seront expliqués en détails par la suite. Lors du déplacement, la vitesse du robot est de 0,3 m/s. La période de la boucle de contrôle de chaque sous-objectif est de 0,1 s.

Figure 9.1– Trajectoire expérimentale du robot

Pour pouvoir suivre le fonctionnement du robot dans son environnement et interagir avec lui, un opérateur suit le fonctionnement du robot à l’aide d’une interface simple développée spécifiquement pour l’expérience HIL. Elle permet deux types d’interactions :

– visualiser l’environnement du robot, ses déplacements, les localisations odométriques et de Monte-Carlo estimées. Par ailleurs, certaines informations utiles lors des phases de test sont aussi disponibles telles que les rayons des sonars, les référentiels utiles à l’évitement d’obstacle et la position du rabbit du suivi de chemin.

– agir sur le robot, c’est-à-dire pouvoir à distance définir sa position actuelle, le chemin qu’il doit suivre, ou le téléopérer à l’aide d’un (cartésien) ou de deux (articulaire) joysticks1_.

La photographie9.2présente le poste de travail où sont réalisées les expériences HIL. L’or- dinateur portable sous RTAI linux qui accueille l’architecture tolérante aux fautes est embarqué sur le robot pour le contrôler. Il est relié par le biais de sa connexion Wifi et de l’intranet du laboratoire à un ordinateur fixe qui supporte l’interface de visualisation et de téléopération.

9.2 RETOUR SUR LA MATRICE DES RÉSIDUS ET LE TABLEAUAMDEC 163

Figure 9.2– Poste de travail pour l’expérimentation HIL

Après avoir présenté le contexte expérimental, et avant de détailler le déroulement de la mission, nous souhaitons maintenant focaliser brièvement notre discours sur les éléments per- tinents de la matrice de résidus qui a été définie, et sur lesquels nous appuyions largement le processus de tolérance aux fautes.