En robotique, l’élimination des fautes regroupe l’ensemble des moyens pouvant être mis en œuvre lors du cycle de développement du robot, pour détecter et corriger les fautes encore présentes.
3.3.1 Test et simulation
Ce cadre d’évaluation du fonctionnement d’un robot fait appel à deux approches complémen- taires. D’une part la simulation est utilisée pour s’assurer du bon fonctionnement des composants matériels et logiciels. D’autre part des campagnes spécifiques de tests expérimentaux permettent de valider le fonctionnement du robot dans son ensemble. Cette dernière démarche reste diffi- cile à mettre en œuvre (hors de la robotique industrielle) faute des moyens et de l’infrastructure nécessaires à son déploiement.
A notre connaissance, un des seuls exemples ayant donné lieu à publication est celui du pro- jet RAXDS1 qui s’appuie sur l’architecture REMOTEAGENT[Bernard et al., 2000]. La simulation et le test intensif ont été déployés pour chercher à détecter l’ensemble des fautes d’un système spatial robotisé. Six bancs d’essai ont été mis en œuvre tout au long du processus de développe- ment, et ont permis de conduire pas moins de 600 tests. Les auteurs soulignent la pertinence de telles campagnes intensives d’évaluation mais en reconnaissent la difficulté d’application. Entre autre ils pointent le problème lié à l’exhaustivité du test.
En effet, cette exhaustivité est purement utopique dans des systèmes robotiques d’une telle complexité. La simulation et le test restent majoritairement focalisés sur les composants et al- gorithmes les plus critiques. La validation formelle permet cependant de s’inscrire dans une perspective plus globale et générique pour garantir un ensemble de propriétés de bon fonction- nement à l’aide d’outils mathématiques.
3.3.2 Validation formelle
La validation formelle rassemble un ensemble de techniques utilisant des outils mathéma- tiques, souvent sophistiqués, pour valider le comportement d’un système sur un ensemble de propriétés données. Cette dimension doit être prise en compte dès le début de la conception du système en choisissant des modèles mathématiques adaptés à la formalisation et à la preuve des propriétés visées pour le système étudié.
Certains outils de conception (présentées section3.2.2) d’architectures de contrôle intègrent donc à la fois des moyens de modélisation pour construire le système et de vérification formelle pour éliminer les fautes.
Par exemple, l’architecture ORCCADest une des architectures mettant l’accent sur l’élimina- tion des fautes en intégrant dans ses outils de conception des moyens de validation formelle. Elle fait appel au langage ESTEREL pour la spécification de la partie contrôle des applications [Espiau et al., 1995] ce qui permet l’utilisation des outils de vérification formelle associés à ce langage synchrone. Un autre langage synchrone, le langage RMPL (Reactive Model-Based Pro- gramming Language) [Williams et al., 2003b] a été développé pour permette une programma- tion basée modèle. Il a été utilisé dans le noyau d’exécution TITANmis en place sur la sonde DS1 de la NASA [Williams et al., 2003a] afin de permettre le diagnostic des fautes au sein des sys- tèmes autonomes réactifs. L’architecture LAASs’appuie quand à elle sur le langage à composants BIP(Behavior-Interaction-Priority) [Basu et al., 2006] pour assurer la validation formelle de pro- priétés de sûreté (absence de blocage par exemple) pour le contrôle d’exécution du niveau fonc- tionnel [Basu et al., 2008]. Dans [Rutten, 2001] l’auteur propose aussi une méthode pour la pro- grammation sûre d’applications robotiques s’appuyant, pour synthèse des contrôleurs, sur l’utili- sation d’une boite à outils faisant appel au langage synchrone SIGNAL[Le Guernic et al., 1991]. D’autres langages formels sont utilisés en robotique lors de la conception comme par exemple le langage Symbolic model checking SMV [Burch et al., 1992]). Dans [Simmons et al., 2000] un mécanisme de traduction du système robotique étudié permet de le décrire formellement en
3.4 PRÉVISION DES FAUTES 43
langage SMVpour qu’il puisse être analysé grâce à des outils dédiés. Dans l’architecture CIRCA [Goldman et al., 2000], le planificateur SSP (STATESPACEPLANER) utilise les automates tempo- risés [Alur, 1998] pour vérifier la vivacité d’un plan et le corriger en ligne si nécessaire.
Malheureusement, la validation formelle définit un cadre de développement et de modé- lisation spécifique et contraignant qui impose des limitations aux architectures. La plupart du temps les langages formels, de par leur spécificité, ne sont pas directement utilisés lors du pro- cessus de conception de l’architecture. Il est possible d’obtenir, dans un second temps, après une étape de modélisation, une représentation formelle du comportement du système robotisé afin de pouvoir le valider.
Par rapport à la simulation, la validation formelle présente l’immense avantage de pouvoir as- surer qu’une propriété attendue, correctement formulée, est satisfaite quelques soient les confi- gurations comportementales envisageables du système analysé. Cependant la complexité com- portementale des robots et la dimension temporelle associée induit une explosion combinatoire des états qui limite fortement la portée de la validation formelle. Par ailleurs, les fautes de type capteurs, actionneurs, ou encore celles dues à une mauvaise représentation de l’environnement sont rarement prises en compte dans les travaux actuels.
Malgré toutes les techniques que nous venons de balayer pour la prévention et l’élimina- tion des fautes il est impossible d’éviter leur occurrence lors du fonctionnement d’un système robotisé. L’exhaustivité des méthodes d’élimination est encore une utopie, et de plus certaines fautes ne peuvent être évitées. Il est donc indispensable de disposer de moyens permettant de les identifier avant de pouvoir les détecter, les diagnostiquer et de réagir à leur présence.
3.4
Prévision des fautes
À notre connaissance peu de travaux ont étudiés les fautes affectant des robots autonomes et leurs impacts sur le déroulement de leur mission. Différentes démarches sont pour autant discernables. L’analyse de relevés sur de longues périodes d’expérimentation et l’utilisation d’ap- proches globales pour l’identification des fautes pouvant affecter un système robotisé. Ces tra- vaux sont complétés avantageusement par l’étude des niveaux de sévérité des fautes identifiées.
3.4.1 Analyses statistiques
Les travaux menés par Murphy [Carlson and Murphy, 2005] et son équipe, déjà évoqués en section 1.1, relèvent de ce type de démarche. En effet ils étudient le comportement d’un grand nombre de robots, le plus souvent dans des conditions d’utilisation réelles, au travers des rapports d’études disponibles. L’analyse statistique ainsi produite permet de proposer une taxonomie des fautes, d’en identifier les plus fréquentes, et de connaitre leur impact sur le fonctionnement du système robotisé.
Tomatis dans [Tomatis et al., 2002] présente un robot-guide ROBOX développé pour conduire la visite guidée du musée de Neuchâtel (Suisse). Dans [Tomatis et al., 2003] les au-
teurs présentent l’analyse de fiabilité de leur robot guide après un trimestre d’exploitation et souligne la fragilité du contrôleur développé.
Bien que pertinente et très enrichissante ce type d’approche expérimentale a postériori reste marginale et ne s’intègre qu’en fin du cycle de conception d’un robot. L’utilisation d’une dé- marche a priori, comme l’AMDEC, déployée dès le début de la phase de conception du robot est nécessaire pour l’élaboration d’une architecture tolérante aux fautes.
3.4.2 Application de l’AMDEC en robotique
L’AMDECqui pourtant fournit un cadre d’analyse des défaillances d’un système éprouvé dans de nombreux domaines scientifiques, a peu été appliquée, à notre connaissance, en robotique.
On trouve un exemple d’application de l’AMDECdans le cadre d’un projet de diagnostic de fautes en ligne d’un robot BEARCAT [Nikam and Hall, 1997]. Il a été mené par plusieurs élèves de Master [Kanakaraju, 2000, Vishnuvardhanaraj, 2000] de l’université de Cincinnati sous la conduite du Professeur Hall. Son but est de permettre d’avoir un accès en ligne, depuis un na- vigateur internet, à un système de diagnostic performant permettant à un opérateur d’analyser l’état du robot. Une variante de l’AMDEC, le PFMEA (Potential Failure Mode and Effects Analysis) est utilisée pour structurer et diriger le diagnostic humain en se basant sur les informations d’er- reurs retournées par le robot. Les solutions envisagées pour pallier l’occurrence de défaillances restent purement matérielles.
Dans [Guiochet and Baron, 2004], l’auteur combine la méthodologie AMDEC et le langage UML pour maitriser la sécurité de systèmes robotiques médicaux. L’analyse réalisée permet d’identifier les risques liés à la téléopération d’un robot esclave TER. Les modes de défaillance sont alors classifiés selon leurs origines et un ensemble de solutions est proposé pour concevoir un nouveau robot plus sécurisé.
Nous allons maintenant évoquer l’analyse de sévérité des fautes qui fait partie intégrante de la démarche AMDEC et qui s’inscrit comme l’un des paramètres central du mécanisme de tolérance aux fautes déployé au sein des architectures robotiques.
3.4.3 Analyse de la sévérité des fautes
L’évaluation par niveaux de la sévérité des fautes au sein de contrôleurs robotiques peut prendre différentes formes.
Dans [Brandstötter et al., 2007] les auteurs proposent une discrimination simpliste de seule- ment deux classes de fautes, celles dont l’origine est connue et où une solution de recours a été modélisée, et celles sans origine déterminée où le robot doit être arrêté.
Dans [Ji et al., 2003] un contrôleur adaptatif hybride met en œuvre 3 niveaux de sévérité en fonction des solutions de recouvrement adoptées. Si la faute est considérée comme peu im- portante, un contrôle robuste est utilisé pour maintenir la performance du système. En présence d’une faute de niveau intermédiaire, un nouveau contrôleur est choisi et inséré dans la boucle
3.5 TOLÉRANCE AUX FAUTES 45
de commande. Enfin en cas de faute fatale, le système est stoppé.
Dans l’architecture PROCOSA [Barbier et al., 2006], dans le contexte du vol d’un drone, les auteurs déterminent 4 niveaux d’erreurs en fonction de l’incidence sur la mission en cours. Ils distinguent les évènements :
– qui conduisent à adapter la mission sans pour autant la remettre en cause
– qui identifie la coupure de communication forçant le système à passer en autonomie totale – liés à des problèmes de sécurité exigeant un changement de plan de vol
– catastrophiques imposant l’abandon de la mission en cours
Enfin récemment [Olive, 2010] décrit les mécanismes de tolérance aux fautes déployés par la société Thalès au sein de satellites pour lesquels quatre niveaux de sévérité sont utilisés. Le plus faible correspond à des fautes sans impact sur les performances des sous-systèmes du satellite (erreur de parité, etc.) où le recouvrement peut se faire localement et de façon autonome. Le niveau suivant correspond aux fautes, sans conséquence sur le déroulement de la mission, mais nécessitant la commutation autonome vers une unité redondante. L’antépénultième niveau correspond à la perte de performance d’un sous-système. Dès lors le processeur impliqué est remplacé. Le niveau le plus critique est rencontré en cas d’alarmes multiples provenant du niveau précédent ou en présence de dysfonctionnements matériels critiques. La mission doit alors être interrompue et le satellite est positionné en mode sécurité. Le recouvrement est ensuite réalisé depuis le centre de commande sur Terre.
Ces nombreux exemples transcrivent de fait un lien plus ou moins direct entre le niveau de sévérité d’une faute et les solutions de recouvrement envisageables.
L’application de l’AMDECainsi que de l’ensemble des moyens de prévisions des fautes restent peu fréquent dans le contexte de la robotique. Pourtant ce type d’analyse nous semble cruciale pour connaitre les fautes pouvant potentiellement affecter le système robotisé. Nous pensons que cette étape est indispensable à la mise en place d’un processus de tolérance aux fautes ciblé et cohérent.