Les modes de fonctionnement non-autonomes

Plusieurs modes de fonctionnement impliquant une interaction Homme-robot ont été dé- veloppés dans le but de tenter de répondre aux problèmes que le dispositif robotique n’a pu résoudre de lui-même (permettant ainsi d’achever la mission en cours). Deux niveaux d’autono- mie interactifs ont été envisagées : la téléprogrammation et la téléopération que nous allons maintenant présenter.

7.2.2.1 Les modes de fonctionnement de téléprogrammation

La téléprogrammation permet à l’opérateur d’apporter s’il le peut une aide ponctuelle au robot. Le principal problème de ce type d’interaction est que l’opérateur a à priori une mauvaise connaissance du contexte d’évolution du robot. Pour intervenir de façon efficace il devra donc disposer d’informations pertinentes sur le fonctionnement antérieur du robot, son état courant et sur l’environnement dans lequel il se trouve actuellement.

La phase d’interaction homme robot en téléprogrammation présente donc dans un premier temps une phase de prise de connaissance pour l’opérateur. Celle-ci peut être faite en analysant le comportement antérieur du robot et/ou en prenant connaissance l’environnement réel du robot avec l’aides des moyens de téléopération et notamment d’une caméra. Dans un second temps, l’opérateur pourra définir l’action corrective qu’il souhaite mettre en place pour pallier les dysfonctionnements que le robot n’a pu surmonter.

Dans notre cadre expérimental, même si la liste des actions correctives en téléprogrammation reste évidement ouverte, les solutions adoptées sont les suivantes :

Localisation du robot - L’opérateur re-localise le robot et lui fournit sa nouvelle position sur la carte.

Définition d’un nouveau chemin - L’opérateur modifie le chemin que le robot doit suivre pour par exemple éviter un obstacle non prévu et lui communique les nouveaux points de pas- sage.

Diagnostic distant de modules fautifs - L’opérateur à partir des informations dont il dispose est arrivé à déterminer la ou les origines du dysfonctionnement. L’état des modules est mis à jour en conséquence dans la base de donnée.

Ces deux alternatives conduisent à définir un seul mode de fonctionnement téléprogramma- tion qui comme nous le voyons dans le tableau ne fait appel qu’à trois modules. Le module UDP qui en fonction de l’ordre de l’opérateur viendra soit mémoriser le chemin reçu, soit commu- niquer directement à NAV la nouvelle position du robot. Le module NAV mémorise la position courante du robot. Ces opérations étant effectuées robot à l’arrêt, le module P3D n’est présent que pour maintenir la liaison avec le micro-contrôleur.

Sous-objectif Niveau Liste des modules

autonomie actifs

Téléprogrammation Téléprogrammé NAV UDP P3D

Table 7.6– Module des modes de fonctionnement téléprogrammé

Après une opération de téléprogrammation l’opérateur devra choisir le nouveau mode de fonctionnement (autonome ou non) qui lui semble le plus judicieux pour que le robot achève sa mission avec les nouveaux paramètres fournit.

7.2.2.2 Les modes de fonctionnement de téléopération

Deux modes de fonctionnement en téléopération ont été développés (figure7.7) :

– Dans le premier l’évitement d’obstacle réactif par DVZ est maintenu tandis que l’opérateur définit le déplacement du robot. Le module DVZ utilise les données sonars fournies par le module UST pour valider le déplacement souhaitée par l’opérateur. On peut remarquer que dans ce cas de figure l’algorithme d’évitement d’obstacle SMZ ne peut être utilisé car il nécessite de connaitre à priori le chemin que doit suivre le robot.

– Dans le second seules les directives de l’opérateur sont appliquées au robot.

Pour chaque mode de fonctionnement de téléopération deux stratégies sont possibles pour l’opérateur. L’une, en mode articulaire, commande directement la vitesse de rotation de chacune des roues du robot à partir de deux joystick. L’autre, en mode cartésien, n’utilise qu’un seul

7.3 CONCLUSION 137

Sous-objectif Niveau Liste des modules actifs Autonomie

Téléopération avec évitement d’obstacle

Téléopération P3D UST ODO NAV UDP DVZ

Téléopération sans DVZ

Téléopération P3D ODO NAV UDP

Table 7.7– Module des modes de fonctionnement téléopéré

joystick qui défini le cap et la vitesse du robot qui sont convertis par le module UDP pour commander les roues.

L’ensemble des modes de fonctionnement pour le recouvrement viennent d’être définis. L’an- nexeBprésente les tableaux d’analyse AMDECrécapitulatifs de tous ces modes de fonctionne- ment où l’on trouvera pour chacun des modules utilisés les sévérités des différents modes de défaillances. Il est important de remarquer que les fautes rendant un module intrinsèquement fautif se retrouvent dans tous les modes de fonctionnement où ce module est impliqué. En re- vanche, les défaillances propagées sont dépendantes du mode de fonctionnement considéré et donc des modules impliqués.

7.3

Conclusion

Cette première phase de notre méthodologie de développement d’une architecture de contrôle tolérante aux fautes, a permis de définir l’ensemble des modes de fonctionnement que nous avons retenu pour mener à bien la mission de livraison de courrier au sein du laboratoire. Au total douze modules ont été décrits et développés. Ils ont été projetés à travers trois niveaux d’autonomie pour définir huit modes de fonctionnement différents plus ou moins performants. La démarche AMDECqui a été déployée sur chacun d’eux a permis de mettre en évidence, pour chacun des modules impliqué, leurs modes de défaillance ainsi que les niveaux de sévérité asso- ciés.

Avec l’aide des informations rassemblées nous allons maintenant pouvoir aborder le déve- loppement proprement dit de l’architecture tolérante aux fautes pour laquelle nous mettrons en place, au sein de COTAMA, les mécanismes nécessaires à la détection d’une défaillance, au diagnostic de la faute et au processus de recouvrement.

Chapitre

8

Tolérance aux fautes : Mise en œuvre

Architecturale

La phase préliminaire de notre méthodologie a permis de mettre en avant, d’étudier, et d’analyser l’impact des dysfonctionnement potentiels de notre système robotique sur son com- portement. La seconde phase que nous allons maintenant détailler, va permettre de détecter et diagnostiquer puis de réagir à l’occurrence de ces défauts lors de la réalisation de la mission pour construire une architecture tolérante aux fautes.

L’architecture logicielle COTAMA dispose des mécanismes fondamentaux nécessaires au dé- ploiement de la tolérance aux fautes. D’une part, la modularité déployée au niveau exécutif lui permet d’ors et déjà de supporter des processus de détection et de diagnostic « au fil de l’eau », sans pour autant les intégrer dans une logique structurante. D’autre part, ses capacités décision- nelles, déployées sous la forme de machines à états, autorisent la mise en œuvre de la réaction nécessaire. Cependant celle-ci reste pour l’instant noyée au milieu des moyens permettant de gérer l’évolution de la mission proprement dite.

Pour pallier ces insuffisances, nous proposons de modifier la composition de l’architecture COTAMA pour la structurer au regard des moyens de détection, de diagnostic et de réaction nécessaires à la mise en œuvre d’une architecture tolérante aux fautes.

Ces modifications, que nous détaillerons plus en avant tout au long de ce chapitre, se tra- duisent au travers de la figure8.1par l’introduction d’un ensemble de nouveaux modules (gri- sés) :

– La phase de détection de défaillances sera assurée, au niveau exécutif, par un ensemble de modules dédiés, lesModules d’Observation qui permettront de générer les informations qui seront utilisées lors de la phase de diagnostic.

– La phase de diagnostic est réalisée, toujours au niveau exécutif, par leModule de Diag- nostic. Celui-ci centralise les informations collectées par les Modules d’Observation et détermine l’origine des défaillances.

– Sur sollicitation du Module de Diagnostic, la phase de recouvrement est déployée au ni-

veau décisionnel, à travers plusieurs superviseurs. Tout d’abord le Superviseur Contex- tuel détermine, en fonction du contexte actuel de la mission (modules opérationnels) et de la sévérité des défaillances détectées, le type de réaction à mettre en œuvre. Puis, en fonc- tion de la gravité de la situation précédemment identifiée, plusieurs superviseurs (Global, Local et Adaptation) peuvent être activés pour choisir le recouvrement à mettre en œuvre. Cette nouvelle décomposition de l’architecture met en évidence la présence de deux circuits évènementiels concomitants. Le premier (partie gauche de la figure) correspond aux évènements directement liés à la gestion de la mission. Le second (partie droite) correspond au processus de tolérance aux fautes mis en place.

Figure 8.1– Architecture COTAMA après modification

Nous allons maintenant aborder le déploiement du processus de détection au travers de la mise en place d’un ensemble de Modules d’Observation.

8.1

Phase de détection : Les Modules d’Observation

Le concept de module d’Observation a déjà été employé dans plusieurs tra- vaux du domaine [Brandstötter et al., 2007,Steinbauer and Wotawa, 2005,Grosclaude, 2004,

Borrelly et al., 1998]. Cependant, dans notre étude, nous nous inscrivons dans le cadre d’une démarche globale et intégrée. Celle-ci s’appuie sur le résultat de l’AMDEC qui a permis d’iden- tifier l’ensemble des défaillances pertinentes à scruter et qui sont rassemblées dans la colonne

8.1 PHASE DE DÉTECTION: LESMODULES D’OBSERVATION 141

(Causes des défaillances/fautes/informations) des tableaux de synthèse7.1. Il faut donc trou- ver, pour chacune d’entre elles, le mécanisme permettant sa détection qui sera ensuite déployé au sein du Module d’Observation correspondant. Chaque module d’observation monitore un en- semble de défaillances potentielles et permettra donc de diagnostiquer l’occurrence des fautes identifiées par la démarche AMDEC.

Dans la suite de l’exposé nous allons balayer les différents Modules d’Observation néces- saires. Classés selon la typologie structurelle définie dans la section4.4.1, nous préciserons pour chacun d’eux la stratégie de détection mise en œuvre ainsi que ses entrées/sorties.