Soutenance mémoire
Test
La sûreté de fonctionnement d’un système est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service que le système leur délivre [Laprie 1996]. Divers moyens, qu’il faut utiliser de manière combinée, sont proposés par ce domaine et se classent dans quatre grandes catégories : prévention des fautes, tolérance aux fautes, élimination des fautes et prévision de fautes. Nos travaux considèrent en particulier l’élimination des fautes. Ce moyen comprend trois étapes : vérification, diagnostic et correction. La vérification peut être statique, c’est-à-dire sans activation du système – par exemple une preuve mathématique – ou dynamique, c’est-à-dire avec activation du système. Le test est défini comme la vérification dynamique d’un système effectuée à l’aide d’entrées valuées. Le test consiste à exécuter un système en lui fournissant des entrées de test, puis à vérifier si les sorties correspondent à celles attendues afin d’élaborer un verdict d’acceptation ou de rejet. L’élaboration de ce verdict est appelé le problème de l’oracle. Le test peut être pratiqué sur toutes les abstractions – modèles exécutables, logiciels ou matériels – et sur toutes les décompositions – du test unitaire où une petite partie, par exemple une procédure ou une classe, du système est testée, jusqu’au niveau système. Le test peut viser à évaluer différentes caractéristiques du système sous test (test de robustesse, test fonctionnel, test de performance, test 1.2. Test 11 de non régression etc.). Pour qu’une faute soit révélée, il faut que les entrées du test activent la faute, que celle-ci se propage sous forme d’erreur jusqu’à affecter le service et le faire dévier du comportement attendu. Cette déviation s’appelle une défaillance. Apparaissent là deux enjeux principaux :
— sauf cas trivial, un ensemble infini d’entrées est possible, il faut donc sélectionner un sous ensemble jugé représentatif ;
— les résultats du test devant être analysés, il faut élaborer un oracle.
Représentation de l’environnement
Afin de représenter son environnement, un robot peut utiliser une carte d’occupation. Cette dernière est une représentation binaire de l’environnement dans laquelle chaque cellule est étiquetée en deux catégories : traversable ou non traversable. Le modèle qualitatif de l’espace libre est une extension de la carte d’occupation dans laquelle les cellules ne sont plus étiquetées binairement mais de manière continue à l’aide d’un nombre – probabilité, nombre flou ou encore estimation de rugosité – qui décrit si la cellule d’un terrain est plus ou moins traversable. Le modèle numérique de terrain est une représentation plus adaptée aux terrains accidentés – typiquement les sols non plats dans des environnements extérieurs – que celles citées au-dessus. Le terrain est représenté sous forme d’un ensemble d’élévations calculées au fur et à mesure de la navigation du robot et sur un repère cartésien. Cette représentation est obtenue à l’aide de la fusion des diverses données en trois dimensions (3D) datées et localisées. Celles-ci peuvent être obtenues à l’aide d’un banc de stéréo-vision, d’une caméra de profondeur ou bien par nappe laser 3D qui bascule afin d’avoir une représentation de l’environnement tout autour du robot (voir figure 1.2). Une description de ces représentations est consultable dans [Lacroix 2002].
Fautes dans les systèmes autonomes
Un système autonome qui évolue dans un environnement non structuré, ou comprenant des humains, est particulièrement soumis aux fautes externes, également appelées situations adverses ; ces fautes venant s’additionner aux fautes internes de conception. Comme vu section 1.2 une faute, une fois activée, produit une erreur qui peut se propager dans le système et provoquer une défaillance du service. Avec le déploiement de systèmes autonomes au contact des humains, ces fautes peuvent avoir des conséquences graves. En 2016 en Chine, Little Chubby, un robot éducatif, blesse un enfant lors de la foire Hi-Tech. La même année, un robot K5 destiné à la sécurité, renverse un enfant dans un centre commercial aux États-Unis, ne lui laissant heureusement que quelques égratignures. Un an plus tard, le même modèle chute dans une fontaine. Un autre exemple catastrophique est donné par l’accident fatal impliquant une voiture autonome de la marque Tesla en 2016 aux États-Unis. Les causes de ces accidents sont diverses : du problème de la perception pour l’incident de 2016 impliquant le robot K5, au problème couplant la perception et la faute humaine pour l’accident de la voiture autonome, à un incident de communication avec l’interface du robot pour Little Chubby. Ces problèmes renvoient aussi à la robustesse, qui est la capacité pour un système de traiter correctement une situation inattendue (par exemple un humain de petite taille dans le cas du robot K5, ou une remorque réfléchissante pour le cas Tesla). Dans [Carlson 2003] les auteurs ont collecté un total de 97 défaillances sur un ensemble de 13 robots mobiles de 7 modèles différents sur une période de 2 ans, dans des environnements intérieurs et extérieurs. Parmi ces 13 robots, 9 sont des robots industriels commercialisés ; 4 autres étant destinés à la recherche. Les auteurs comptabilisent une défaillance si le robot, ou l’équipement utilisé avec le robot, est dans l’incapacité fonctionner correctement. Le niveau d’autonomie des systèmes considérés n’est pas clairement donné, mais il semble qu’il s’agisse de robots télécommandés avec peu d’autonomie, ce qui explique la définition de défaillance utilisée. Il n’est donc traité que des cas d’arrêt complet du robot ou de dégradation importante dans l’accomplissement du service, et non de problèmes liés à la performance par exemple. Un temps moyen avant défaillance (Mean Time Before Failure (MTBF) en anglais) de 8.3 heures en moyenne est obtenu, ce qui implique une confiance assez faible en ces systèmes.
Modules robotiques sous test et simulés
Le logiciel du robot Mana est organisé conceptuellement suivant une architecture hiérarchisée en trois niveaux (voir les différentes architectures en section 1.3.2) : un niveau décisionnel, un niveau exécutif et un niveau fonctionnel. Nous nous concentrons ici sur le niveau fonctionnel des services de navigation. Dans le cas de Mana, il correspond à six modules robotiques. Trois d’entre eux correspondent au pilotage des capteurs et actionneurs du robot, et les trois autres implémentent les fonctions plus haut niveau de la navigation. La figure 2.1 représente l’articulation entre ces modules, dans le cadre d’une plateforme de simulation MORSE représentative de ce que les développeurs utilisent à des fins de prototypage et de mise au point. Le pilotage des capteurs et actionneurs est géré par MORSE, en remplaçant les modules réels par des modules de simulation. Ainsi, les modules Rflex (contrôleur de roues et odométrie), Velodyne (capteur laser 3D) et Pose (capteur de position) sont simulés. Les autres modules fonctionnels sont exactement ceux déployés sur le robot réel et vont constituer notre système sous test (SUT, d’après l’abréviation anglaise). Il s’agit de : DTM (cartographie 3D), POM (agrégateur de position) et P3D (planification locale présentée section 1.3.3.3). Ces trois modules sont développés avec GenoM (pour une description de GenoM voir section 1.3.2). Ils communiquent à l’aide de l’intergiciel pocolibs, via des posters qui sont des espaces de mémoire partagée. Le système sous test, comportant ces trois modules et les diverses librairies dont ils ont besoin, représente environ 35 000 lignes de code. Ce système est réaliste du point de vue de la complexité d’un service de navigation locale qui planifie une trajectoire pour atteindre un point objectif en évitant les éventuels obstacles, trous et terrains trop accidentés pour le robot. Pour rappel, le module P3D reprend les principes d’un algorithme développé par la NASA pour l’exploration martienne. Il considère un ensemble d’arcs projetés à partir de la position perçue du robot dans son modèle numérique de terrain et évalue ces arcs selon un critère risque/intérêt. L’algorithme est mature et ce service de navigation a été utilisé lors de nombreuses expériences sur terrain extérieur par des chercheurs en robotique du LAAS. Le système sous test est également réaliste du point de vue du caractère indéterministe de la navigation. L’algorithme de sélection d’arcs est déterministe, mais son intégration au sein d’une architecture fortement concurrente, typique des robots complexes, induit de l’indéterminisme à l’exécution. Tout changement temporel au niveau de l’exécution des processus de perception, décision et action peut entraîner des changements drastiques sur la trajectoire construite itérativement. Dans le monde réel, on a de plus des aspects incontrôlables de l’environnement (par exemple du vent dans la végétation, qui impacte la carte perçue). Ainsi, il n’est pas possible de reproduire à l’identique l’exécution d’une mission donnée, que ce soit dans le monde réel ou en simulation. En plus des modules robotiques, deux fichiers principaux de configuration sont nécessaires dans la plateforme. Le premier spécifie les limites physiques du robot utilisé afin que P3D puisse calculer les trajectoires (Robot model sur la figure 2.1). Le deuxième est utilisé par MORSE (Simulation config), en spécifiant notamment l’avatar du robot, ses capteurs et en mettant à disposition le chemin où est stocké le monde virtuel à simuler (world.blend). L’avatar du robot Mana, ainsi que les modules de simulation des capteurs et actionneurs, correspondent à une approche de simulation basse fidélité du point de vue des aspects physiques. On ne simule pas les réactions entre les roues du robot et le terrain, l’inertie du robot ou encore des zones glissantes. L’avatar reçoit des consignes en vitesse de P3D et se déplace directement en fonction de celles-ci sans passer par le mouvement des roues. Le moteur de jeu de Blender, sur lequel est basé MORSE, peut proposer une simulation plus fine des interactions physiques, mais à un coût de calcul et de développement plus important des modules de simulation. En pratique, le prototypage de la navigation sous MORSE a adopté une approche basse fidélité, que nous conservons dans le cadre de notre étude sur le test. Nous reviendrons ultérieurement, dans le chapitre 3, sur l’impact de ce choix pour la reproductibilité des fautes. Enfin, dans la plateforme, un script contrôle l’exécution de la simulation (Execution controller sur la figure 2.1). Il initialise, transmet la mission au système sous test et communique avec lui lors de la simulation.
|
Table des matières
Introduction générale
1 Contexte et concepts fondamentaux
1.1 Introduction
1.2 Test
1.2.1 Sélection et production des entrées de test
1.2.2 Oracle de test
1.3 Systèmes autonomes
1.3.1 Notion d’autonomie
1.3.2 Architecture
1.3.3 Navigation
1.3.4 Fautes dans les systèmes autonomes
1.4 Test des systèmes autonomes
1.4.1 Modèles des entrées de test
1.4.2 Procédés de génération des entrées de test
1.4.3 Oracle de test
1.5 Mondes virtuels et simulateurs
1.5.1 Simulateurs
1.5.2 Génération procédurale de mondes
1.6 Conclusion
2 Premières expériences et étude des niveaux de difficulté
2.1 Introduction
2.2 Modules robotiques sous test et simulés
2.3 Plateforme de test
2.3.1 Définition du domaine d’entrée de test
2.3.2 Génération des mondes et missions
2.3.3 Collecte des données
2.3.4 Analyse des données
2.4 Conception des expériences sur les niveaux de difficultés
2.4.1 Questions de recherche
2.4.2 Description des expériences
2.5 Résultats
2.5.1 Contrôlabilité des niveaux de difficulté (Q1)
2.5.2 Indéterminisme (Q2)
2.5.3 Étude d’une version fautive de la navigation (Q3)
2.6 Conclusion
3 Étude de la reproductibilité de fautes en simulation
3.1 Introduction
3.2 Archivage et suivi de versions du logiciel de navigation de Mana
3.3 Conception de l’étude
3.3.1 Questions de recherche
3.3.2 Détails de l’approche pour répondre aux questions de recherche
3.4 Résultats empiriques
3.4.1 Vue d’ensemble des fautes et de leur reproductibilité (RQ1)
3.4.2 Entrées : mondes, missions et données de configuration (RQ2, RQ3)
3.4.3 Données d’observation et procédures d’oracle (RQ4)
3.4.4 Obstacles à la validité de cette étude
3.5 Conclusion
4 Application au cas d’un robot agricole
4.1 Introduction
4.2 Présentation du robot
4.3 Environnement de simulation
4.4 Les entrées
4.4.1 Analyse de cas d’utilisation
4.4.2 Modélisation : diagramme de classes et grammaire formelle
4.4.3 Génération et mise en forme des entrées de test
4.5 Données d’observation et oracle
4.5.1 Données d’observation
4.5.2 Oracle
4.6 Résultats du test aléatoire
4.6.1 Vue globale
4.6.2 Comparaison test nominal et test aléatoire
4.6.3 Indéterminisme
4.6.4 Aide au diagnostic
4.6.5 Corrélations avec paramètres de génération
4.6.6 Recommandations issues des tests
4.7 Conclusion
Conclusion générale et perspectives
Télécharger le rapport complet
